Editorial license. (etiquette for Windows programers) (Editorial)
by Clifton Karnes
I've had it with rude, crude, and socially unattractive Windows programs. You know the ones I'm talking about. They install themselves all over your hard disk, polluting your WIN.INI with entries, filling your WINDOWS and SYSTEM directories with files, and sometimes even defiling your root director. They're impossible to move or delete, so I've decided to complain.
What I'm going to do is give developers six golden rules for Windows programs. It's worth mentioning that I'm looking at this problem from the point of view of both a user and a programmer. And I have to tell you that I've sinned myself. As a programmer, I've broken most of these rules, but the end user inside has turned me around. I've seen the light, and I will sin no more. So here's the law, from one of the converted.
1. Don't place files in any directory except your program's own directory and subdirectories. This is by far the most important rule. Not only should all your files go in your program's directory and subdirectories, but all your INI files should go there as well and not in the WINDOWS subdirectory. If you have several separate programs that will be installed in different subdirectories and that need to share DLLs, put them in a directory you own, and mark the location with an environment variable so your other programs will know where to find them.
2. Don't add entries to WIN.INI. Use your own INI file, and place it in your program's directory.
3. Include explicit instructions for the user on how to uninstall your program manually. If you've followed rules 1 and 2, uninstalling will simply be a matter of deleting the program's directory and all its subdirectories.
4. If your application puts files in any directory other than its own (and following rules 1 and 2, it shouldn't), include an uninstall program.
5. If possible, keep hard-wired references to directories your program uses out of INI files. This may be difficult, but if you follow all of the rules above plus this one, a user not only can delete a program easily but can move it to another disk by just dragging the main directory.
6. Don't require that your program's executables be on the user's path. You may suggest this as a convenience, however.
Those are the golden six, but until all developers see the light and start following these guidelines, we'll still have problems. So what are we supposed to do? Well, there are several commercial programs that help you remove programs. Perhaps the most useful is Uninstaller 2 from MicroHelp. It looks at your system intelligently to determine which files a program is using and then zaps them. This tool can be dangerous, however, so I recommend it only to experts.
Another option is the INI Tracker found in The Norton Utilities 8.0. This program makes snapshots of your system files and your WINDOWS and SYSTEM directories, as well as any other directories you tell the program to watch. This is a very useful tool.
My favorite tools, however, are two tired-and-true batch files I wrote shortly after Windows 3.0 arrived on my hard disk, BEFORE.BAT and AFTER.BAT. These programs make a snapshot of your system before and after you do an install and then compare the two snapshots. I've published these before in COMPUTE, and I've recently updated both programs to make them faster. If you're interested, look for them in B&A.ZIP in COMPUTE's forum on America Online-they're free. Whatever you do, you'll need at least one of these tools to do battle against all those inconsiderate Windows programs out there.