Can I get it without the bugs?
Standard installers are a great solution to the problems I've talked about so far, at least in principle: application developers get an installation component for free and users get a standard, recognizable installation procedure. Everyone comes out a winner.The first standard installer I saw was on Commodore's Amiga; the company designed a very nice standard installer and encouraged everyone to use it. These days the standard installer on the Mac is pretty decent, and there are also some very popular third-party installers.
Package management systems
On the plus side, packet management systems are largely automated, and thus hidden from the user. Competition and development among these systems is in full swing -- bad for users today but with good potential in a few years. You can look forward to the day when clear design features have been identified and standardized.
While most standard installers are pretty good, none of them are perfect. Many contribute to the same problems you see with widespread use of installers. The Mac OS X installer has a particularly nasty bug that deserves special mention. It destroys symbolic links (aliases or shortcuts, for you non-UNIX folks). If any file it wants to install is anywhere in a path that, at the beginning of installation, contains a symbolic link, the installer replaces the link with an empty directory. It does so silently, without warning, and you cannot disable this feature. As a result, a lot of developers who might otherwise use the standard installer (a big benefit for users, one would hope) are stuck using others, whether commercial or written in-house. Either way, users lose.
Even with the bugs, standard installers are a benefit to users and developers alike. The next step is to take these components seriously enough to debug them. If a platform's standard installer is relatively free of bugs, a user has little reason to learn other installers.
Make it better next time
While considering the benefits of taking installers more seriously, I propose that all standard installers utilize self-containment. Self containment, inherited from the NeXT, is one of the particularly nice features on Mac OS X. Rather than store an application's installation data in a single database, OS X allows each application to be loaded as a self-contained file hierarchy containing all its associated files. From the user perspective, this is the same old installation procedure -- just drag the icon to your hard disk -- but the back-end results are far more organized and effective.
On the Mac, preference data is normally saved in a per-user preference directory (on OS X) or in the systemwide preference directory (on OS 9 and earlier). However, each application's preferences are stored separately. You can even delete an application's preference file if you want to; applications are expected to run correctly even if their preference files are missing.
Programs on a Windows system, by contrast, are supposed to store all their installation data in a single, centralized, often-corrupted database, also known as the registry. This technical decision can make managing Windows systems truly nightmarish. It's hard enough to keep a program and its preferences in separate databases, but separating the program from data it needs to even start running is awful.
A centralized file like the Windows registry is vulnerable to damage from any program. If it's damaged almost every program has trouble running. You can't reliably identify the preferences for a given program, since they may or may not have been stored in a likely area. The database is full of keys created for specific functions, even though you no longer need many of those functions. My laptop has hundreds of registry keys created to identify progress in restoring provided third-party software packages during installation. Chances are that no program other than the factory-restore CD will ever look at these keys, but they haven't been deleted. I have no way to find out what program might need them, so I just have to leave them there.
This lack of self-containment is one of the most persistent hassles to users. You know it's bad when you can't expect to reload your operating system without allocating an extra day or two to reload all your applications, find and reload all relevant patches, and so on. Self-contained programs, on the other hand, give users a great deal of freedom in installing and removing software without requiring special tools. (And it pays to remember that every special tool you need to perform a task is a possible point of failure.)
The fact is, your program has no business modifying my operating system. A system's OS should be modified with great care, if at all. Installers have become unnecessarily complex over the years. Most are trying to solve a number of unrelated problems at once, while they're often unable to perform their primary task reliably. The solution is obvious: stop trying to reinvent the wheel. Instead, invent a standard installer that's bug free and built using the best-of-breed features that are already out there.
This week's action item: Try copying an application from one computer to another. Does it work? Why not?
- Read The cranky user's follow-up column on the hazards of installation , "All I want is a quick, easy install, Part 1" (developerWorks, June 2004).
for yourself how easy it is to integrate a third-party installer into
your application, with Janel Barfield's introduction to "InstallShield Multi-Platform Edition 4.0" (developerWorks, November 2001).
- For the flipside (that is, user) perspective, follow along as Anthony Young-Garner of IBM shows you how to customize an InstallShield-based installation of WebSphereŽ Application Server (developerWorks, November 2001).
- Along with InstallShield, check out Aladdin Systems' Stuffit InstallerMaker, one of the better known third-party installation components for developers.
- Of course, remember that Microsoft also has a chunk of this market, with its platform
specific Windows Installer.
- Read Mikko Kontio's new column, Architectural Manifesto as he lays out a blueprint for better software products, starting
from the ground up (developerWorks, April 2004).
- Find articles about every aspect of building for the World Wide Web in the developerWorks Web Architecture zone.
- Visit the Developer Bookstore for a comprehensive listing of technical books, including hundreds of Web development titles.