Why software installation may be hazardous to your computer's health

With the installer usually the first part of an application that a user sees, why is software installation such a notoriously buggy procedure? This month, in The cranky user column, Peter chronicles the ups and downs of installation, from the golden era of the floppy disk to the rise of the standard installer. He also offers some user-centered advice on building installers that work the way users want them to.

Users have been installing programs directly onto computers for a long time now. Once upon a time the only software on your hard drive was the OS; external application programs were accessible only through distribution media, typically a floppy disk. But, the addition of internal storage brought the possibility of storing applications directly on the computer, where you could get at them whenever you wanted.

Early Mac systems enshrined the simplest installation procedure ever: just copy the program to the hard drive. You would click on the application icon, drag it into your hard drive, and the Mac OS would take care of the rest. The Mac's handling of resources allowed crucial supporting data to be part of the application's main file, making this installation method viable for most application software.

Some programs required more support files, though, which complicated the installation procedure. Generally, you would just have to drag an entire folder to the hard disk. But if the program came on two disks (not so uncommon in those days) you might have to copy files from both disks to the same place. This led to confusion and error, which gave rise to finding a better way.

Enter the installer. This was a special program that installed all the bits of a program correctly for you. The installer would copy one disk and then prompt you for the next one. It would copy files into the right folders. It would tell you when installation was complete and instruct you to restart. The installer did everything. In theory, the installer should have made life easier for end users. It should have been the key to a veritable utopia, where everything could be installed with one or two clicks of the mouse. But it wasn't.

Are you messin' with my OS?

One rule of thumb in user-centered design is: Just because you can, doesn't mean you should.

The downside of installers is the same thing that makes them great: an installer can do nearly anything. No matter how complicated the installation procedure, the developer can safely assume the user won't see it. Unfortunately, this leads, time and again, to the compulsion to do something interesting. The worst expression of this compulsion is also the most common: the developer decides to modify the operating system instead of just running under it.

For example, it's cheap and easy to add system extensions, so a lot of programs these days require these (or similar modifications) as part of the installation procedure. In most cases, the extensions aren't really necessary, and in some instances they're downright irritating. Take the Macintosh version of the MYOB accounting package, for instance. MYOB requires a system extension to compress files. The file compression extension could have been left in with the application, or built into it, but it's installed systemwide. The program could save files uncompressed without the extension, but as it is you're left with no choice. As a result, if you upgrade your OS, you have to reinstall one part of the application separately -- and you can't make backups until you do!

But the tinkering doesn't stop there. Rather than install all the application files in a single directory, some developers install some of them in a separate, specially named directory. This makes it easier for future programs to overwrite files with incompatible versions, but it can also lead to excess baggage in your hard drive.

For example, the long history of 8.3 filenames on DOS and Windows systems means that many files are given terse and illegible names, even on modern systems where there's no name length issue to worry about. The System32 directory on my laptop contains 2,235 files. What's "nscompat.tlb"? I don't know. It was installed at 1:30 on February 10; I assume it's important. Three other files were installed at the same time. I don't know what they are, either. They were installed along with a video game, but its installer log doesn't mention them. For all I know, my System32 directory held a newer version and the game overwrote it silently. That happens a lot.

These days, every new application I put on my computer wants to tweak my OS to its own specifications. That is the reason that one of the most time-honored troubleshooting suggestions for both Mac and Windows systems is "do a clean install." Reloading the entire OS is sometimes the only way to fix mystery problems that you otherwise cannot debug. On the other hand, a clean install can create its own problems -- for example, if the system install puts in an older version of a core library that has since been updated.