Today I did something that I’ve been saying I will do for a long time. I retired my CSV editor, Killink.
I love my MacBook Pro. It’s an awesome machine and OS X is a great operating system. However, I have encountered 2 problems when dealing with my Windows-base network. First problem is accessing Windows 2003 file shares and the other problem is resolving machine names on the local network.
I still haven’t solved the second problem but today I came across the solution for the first. This blog posting by Drew McLellan gives the step by step instructions for accessing Windows 2003 file shares from Mac OS X. Thanks Drew!
After resolving the Windows Server 2003 file share access problem I turned my attention to fixing the DNS issue I’m having. I’m able to ping the IP address of machines on my Local Area Network but I’m not able to resolve the machine names. I have a local DNS running on Windows Server 2003 but for some odd reason OS X is not using it to resolve names. So I decided to use a stop-gap approach for the time being.
I modified the /etc/hosts file to include the address of the machines with a static IP address. After all, these are the only machines I need access to from OS X. Here are the steps I followed:<ul>
<li>Sign in as an administrator (or an account belonging to the sudousers group)</li>
<li>Launch a terminal shell (Applications > Utilities > Terminal if you are using Finder or type terminal in Spotlight)</li>
<li>Run the command sudo vi /etc/hosts</li>
<li>Scroll to the end of the file</li>
<li>Type i to enter insert mode</li>
<li>Press the enter key to start a new line (my vi skills are weak as it has been years since I have used it - there is probably a better way to append to the end of a file)</li>
<li>Enter the IP address, press the tab key, then enter the name machine</li>
<li>Press the esc key to get out of insert mode</li>
<li>Press :wq to save the changes and quit vi</li>
</ul>That’s is. The machine name will now resolve to the IP.
Last month I mentioned Windows automatic update was maxing out the CPU on my computer after I installed PowerPoint 2007. It seems I’m not the only one dealing with the annoying issue. Here is a suggested workaround to the infamous svchost issue.
Also, here is another newsgroup thread talking about the issue that might be helpful to some.
Update: The workaround mentioned above does not prevent wuauclt and svchost from using 100% of the CPU but it does make the computer responsive again. Prior to applying the workaround the computer would be unusable for long periods of time.
I learned a valuable lesson today about naming configuration files for my programs. When I started building.NET applications I followed the .NET convention for naming program configuration files: MyProgram.exe.config
These days I write less .NET applications and more native Windows applications using Delphi. I continue using the .NET naming convention for configuration files for all my programs even native Windows applications. This hasn’t been a problem until today.
Today I embedded a manifest into a program and when I ran the program I got the following error message:
This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.
Without the manifest the program ran fine, but the program failed each time the manifest was included. I first thought a problem was with the manifest. I review the manifest over, and over, and over again. I even used a manifest from another application that does not have the problem. After banging my head on the wall for a couple of hours I found the source of the problem, and it wasn’t the manifest at all.
Like all my programs, this particular program creates a configuration file using the .NET naming convention MyProgram.exe.config. But in this one case the configuration file is stored in the same directory as the program file, and here in lies the problem.
Apparently Windows XP, and I assume Vista as well, expects the program configuration file to be based on some specific config file schema when the manifest is embedded in the program file even if the program is a native Windows program. I knew this to be true with .NET applications but I didn’t realize the same is true for native Windows applications.
I have not spent time figuring out the expected schema. I suspect it is the .NET config file schema, but I now follow a new naming convention. I do not name my config files MyProgram.exe.config any more. Instead I use MyProgram.config, which does not have any negative side effects when stored in the same directory as the program file.
Update: If you want to use the .NET config file naming convention for your native Windows application, your .config file must be an XML, and the root element must be . Other root elements might be allowed but I know works.
Yesterday I had a need to install PowerPoint 2007. Typically I install something like this in a virtual machine to avoid problems with other applications but yesterday I was in a rush so I installed PowerPoint 2007 in my “production” VM. The Office 2007 installation gave me the option to keep my Office 2003 applications and install only PowerPoint 2007. “Groovy!” I thought. Well, it turns out not to be so groovy.
After installing PowerPoint 2007 and doing what I needed to do, I launched Outlook 2003. As Outlook 2003 was loading the Office 2007 installer popped up and attempted to install something. I cancel the installer and Outlook 2003 finally loads. I checked my mail, read a few messages, and clicked Reply to author a response to a new message. Here’s where the problem started.
I have Outlook configured to use Word as the editor for messages. When I tried to reply to a message Outlook locked up. Not only did the application lock up but the entire operating system locked up. I had no choice but to power off.
Rebooting didn’t help either. Outlook 2003 did not properly load, and I had a new problem. Microsoft’s automatic update was now maxing out the CPU. To regain control over the machine I killed the automatic update process.
After dealing with this mess I believe I found a work around. After installing PowerPoint 2007 and before launch Outlook 2003, launch Word 2003. If your experience is similar to mine you will notice Word 2003 loads without the XP theme. After about 30 seconds Word 2003’s UI switches to the XP theme. It is after this point that Outlook 2003 is once again able to use Word 2003 as its editor.
I can’t guarantee this will work for you but it did work for me. I’m now able to use Outlook 2003 once again.
The only problem that remains is the automatic update for Windows. It still maxes out the CPU and the process must be manually killed. I can handle doing this until I have time to re-build a new “production” VM.
Update: I found this wordaround to the maxed out CPU problem.
I’m adding a new feature to Killink to allow the user to integrate the application with Windows Explorer. Not a difficult task. Just involves making some registry settings. But one registry setting I need to make must go under HKEY_CLASSES_ROOT, and this hive is under administrative control in Vista.
This isn’t such a big deal if I am using an installer. Installers will typically ask for elevated permissions to perform the install. But I’m trying to provide a version that does not require an installer. This means my application will have to ask for elevated permissions when the user clicks the option to integrate with Explorer. It also means I need to display the shield icon indicating that elevated permissions are required to perform the task.
This really has me bummed out because it means more work (and learning). Now I have to learn up to ask for elevated permissions within the application.
Here are a few Delphi (BDS) Live Templates I created for writting SQL Server script:
Create SQL Server Table
Create table for SQL Server.
Create |TableName| table.
PRINT 'Create |TableName| table'
IF (EXISTS (SELECT name FROM sysobjects WHERE (name = N'|TableName|') AND (type = 'U')))
DROP TABLE [dbo].[|TableName|]
CREATE TABLE [dbo].[|TableName|] (
|*|CONSTRAINT [PK_|TableName|_1] PRIMARY KEY CLUSTERED
|*|)WITH (IGNORE_DUP_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY]
GRANT SELECT ON [dbo].[|TableName|] TO [public]
Create Foreign Key Reference
Create foreign key constraint for SQL Server.
<![CDATA[ALTER TABLE [dbo].[|PrimaryTableName|] WITH CHECK ADD
CONSTRAINT [FK_|PrimaryTableName|_|SecondaryTableName|] FOREIGN KEY([|ColumnName|])
REFERENCES [dbo].[|SecondaryTableName|] ([|ColumnName|])
According to the Microsoft blogger Somasegar, Windows Vista will support more than 7,000 new native APIs.
Here is a trivia for you. We have added more than 7,000 new native APIs for Windows developers in Windows Vista. Examples of some of the exciting new areas where we have exposed new APIs include the new integrated search capability and the new peer-to-peer functionality. To get the whole story, please check out the Windows Vista Developer Story at the Vista Developer Center.
Further proof the native windows code is here for a while.
I’m one of those rare developers who have moved from .NET managed code to native Windows code over the last year. After living in the managed code world for years, I’ve returned to native windows coding and I find I am doing more and more native Win32 work each month for customers. Sure the products White Peak Software is writing are native Windows applications but recently customers have been asking White Peak Software to develop native Win32 custom software. The most common reason? The desire to eliminate the dependency on the .NET Framework.
I often hear, “We don’t know if the server hosting your program will have the .NET Framework installed,” or “The end users do not have .NET installed on their desktops so we need something that will run without .NET.”
Now don’t get me wrong. I love .NET. It’s a great framework, but there is something to be said for native Windows applications. And there are still many cases where a native Windows application should be written instead of a .NET equivalent. For instance, I feel .NET applications are ideal for in-house development typically found in corporations, and I feel commercial applications are typically better served as a native Windows application. Of course there are always exceptions to my general thinking, hence the recent resurgence seen at White Peak Software in customer requests for custom native Windows applications.
Don’t believe me? Think everything running on the Windows platform should be managed code? Well, individuals at Microsoft know that native Windows applications are staying around for a while. When the IE Lead Project Manager Christopher Vaughan was recently asked if components of the new IE7 would be implemented in managed code his response was, “No, IE7 remains purely native code throughout. I think as we develop future versions of IE you’ll see a larger focus on managed code, most likely to enable great plug-ins of that type for our platform. One thing people shouldn’t expect is that IE8 be re-written in managed code. For a variety of reasons, native code is where we’ll stay for a while.”
Ever wish you could contribute to the Visual Studio and .NET Framework documentation? Now you can through the MSDN Wiki. The Wiki is already growing with a number of community contributed edits.
CNet news is reporting that Apple has announced Boot Camp, a new software package that makes it possible to run Microsoft Windows on the new Intel-based Macs. How awesome is that! It’s one step closer to making me want to buy a Mac. Now what would be really awesome and close the deal for me is to have “Devco” create a Delphi compiler for the Mac OS and make it easy for me to port my VCL applications to Mac.