Top Dozen Setup Tips

The following sections describe my top dozen setup tips.

Use a Commercial Setup Program

Back in the bad old days of Windows 3.1 programming, I used to write my own setup programs. The advantage to this approach was that the setup process was fairly simple back then and I could get the setup program to do anything I wanted without fooling around with the limited capabilities of the commercial setup programs available at the time. That situation is no longer true. As I noted earlier, the setup process required by Windows is now so complicated that it isn't practical to write your own setup programs anymore. Do yourself a favor and do your users a favor: use a commercial setup program. Let somebody else deal with the gory details.

When choosing a commercial setup program, I would place more emphasis on reliability than on other considerations such as popularity, price, or advanced features. The single worst technical support problem you can have is dealing with a setup program that crashes. Nothing is more useless than a setup program that crashes. Whatever you do, don't assume that using a commercial setup program means that you don't have to test your setup program. Making this assumption can be a costly mistake.

Make the Setup an Early Deliverable

Let me put it another way: do a ton of user testing. Instead of making the setup a late deliverable, make it an early deliverable. The ideal time to create the setup program is to have it in time for alpha testing so that the setup program is part of the testing and QA process. You have to do it anyway, so why fool around?

Your goal should be to expose the setup program to as many different users and as many different system configurations as possible. Users will do the most amazing things with a setup program if you give them the opportunity. You'll probably have to make several user interface changes so that users can get through the process without problems. And, again, you shouldn't assume that using a commercial setup program means that the setup program will be trouble-free. Setup programs do crash, and when they do, it's a disaster. The result of the setup must be a functioning program. A setup program that installs correctly on one system might not on another.

When your testers are able to install your program without any problems, without any help, and without crashing, you might actually have a usable setup program. But if you try to pull this off at the last minute, chances are you won't make it.

Consider Setup as Part of the User Interface

You should consider the setup user interface to be part of your program's user interface. It's certainly not any less important. This means that you should apply the same user interface objectives described in this book to the setup program. You want to make sure that the setup program uses consistent terminology; that it can be used and understood by beginning users; that its features are visible and simple; that it uses appropriate default values; that it doesn't have any unnecessary dialog boxes or message boxes; that the error messages are clear, consistent, and specific; that it works in all video modes; and that the Help system is helpful. If you perform user testing, consider making the program setup part of the test.

You need to instruct your testers to look for setup problems. Don't take it for granted that they will; my experience indicates otherwise. Any setup problems found during testing should result in a program change of some kind. Ideally, you should be able to change the setup program or the main program to eliminate the problem. At the very least, you should document the problem in the readme file so that users have a chance to deal with the problem on their own. For example, suppose during testing you discover that your program is incompatible with a certain type of video card. Your first effort should be to change your program to make it compatible. If that's not possible, your next effort should be to have the setup program check for that video card and report the incompatibility during installation. Lastly, you should at least document the problem in the readme file. If you do none of these steps, you are certain to get a technical support call from every user that has that video card.

Understand the Logo Requirements

As I discussed in Chapter 1, the logo requirements were created to help you make sure that your program conforms to what the user expects. They are not arbitrary hoops you need to jump through. Although using a commercial setup program will make it easier for you to create a setup program that conforms to the logo requirements, you should still understand the logo requirements and what they are trying to accomplish.

To quickly summarize the logo requirements, your program must use new Microsoft installer technology, which makes it easy to meet the other install/uninstall requirements. Your setup program must provide a graphical 32-bit setup that works in an attended and/or silent scenario, detects software versions, creates working shortcuts, supports CD-ROM AutoPlay, supports Add/Remove Programs, and checks operations in advance. Your setup program must provide and register a fully automated uninstaller that appears in Add/Remove Programs and that when run, removes all program files, references in the Start menu, registry entries, and removes itself as well.

Let's look at some of the more interesting setup logo requirements and recommendations.

Use Microsoft installer technology (required)

The Microsoft installer technology greatly facilitates satisfying the logo requirements for Windows 98 and Windows 2000. The Microsoft installer technology is supported by the major commercial setup program vendors.

Provide attended and/or silent installation and provide a fully automated uninstaller (required)

Automated network installation provides administrators the ability to perform the installation by using the network instead of dealing with individual computers.

Detect versions when installing (required)

The setup program must be able to detect the Windows version and install the appropriate program version.

Maintain user settings across version changes (best practice)

User settings must be maintained across upgrades. Furthermore, the user should be able to install multiple versions of your program. Installing a new version of a program should not conflict with or break other versions. Providing the user the ability to run multiple versions of a program is why the program's version number should be part of the path for its registry settings.

Support AutoPlay of CD-ROMs (required)

Programs distributed on CD-ROM must use the AutoPlay feature to begin setup or to launch the program the first time the program is run. It's up to you whether AutoPlay is enabled on subsequent insertions of the CD-ROM.

Register uninstaller and make it appear in Add/Remove Programs (required)

The uninstaller must be properly registered and must appear in the Add/Remove Programs applet in Control Panel.

Remove all program files during uninstall (required)

All files and folders copied to the hard disk must be removed, including .fts and .gid files generated by the help engine. User data files and resources that other programs might use, such as sharable DLLs, sharable fonts, and sharable registry entries, should remain on the hard disk.

Remove all references from the Start menu during uninstall (required)

The uninstaller must remove all shortcuts placed anywhere in the Start menu by the setup program.

Remove registry entries during uninstall (required)

The uninstaller must remove all registry entries created by the program, with the exception of entries that might be shared by other programs.

Remove uninstaller during uninstall (required)

The uninstaller must remove itself. The Microsoft installer technology simplifies this problem since it is a system component and must not be removed.

Do not write to Windows system directories (recommended)

The setup program should not write anything to the Windows system or system32 directories. In particular, it should not place shared DLLs or executables in the Windows system directories. Instead, use the \Program Files\Common Files\companyname folder for shared program files, and use Microsoft update packs for system files.

Use Microsoft update packs to upgrade system components (recommended)

If the program requires updated system DLLs or other core components, ship a self-extracting executable provided by Microsoft that handles installation of these components. Microsoft distributes new DLLs by means of component update packs only. You should distribute these self-extracting executables from Microsoft rather than the latest DLLs themselves.

Do not decrement or remove core components during uninstall (required)

The uninstaller must not decrement or remove any core component, in particular MFC DLLs, Open Database Connectivity (ODBC), and Data Access Objects (DAO) DLLs.

Do not add to Win.ini or System.ini (required)

Your program must not add information to Win.ini or System.ini.

Do not register hard-coded paths (best practice)

Installers and programs should make use of the registry REG_EXPAND_SZ string type; the %SystemDrive%, %SystemRoot%, %windir%, %ProgramFiles%, %Temp%, and %UserProfile% environment variables; and the API function ExpandEnvironmentStrings. Do not hard-code paths to the Windows system root or to the drive containing Windows in the registry because users can remap their drives under Windows NT.

Install programs to the Program Files directory (required)

Your setup program's default installation directory (or directories) must be in the Program Files folder. Do not install executables or DLLs in the root directory.

Query the registry for directory names (required)

Your program should not assume that directory names such as My Computer will be in English or will be unchanged by the user. Your program should query the registry directly to obtain the proper language-specific directory names.

Don't Overlook the Uninstall

A guide to Mount Everest once pointed out that you are not done when you get to the summit. In fact, you are at most halfway done, assuming you want to get home alive. Similarly, installation is only half the battle—safely uninstalling is the other half. And, from the point of view of system robustness, it is the critical half. After all, it's pretty difficult to corrupt Windows by incorrectly adding a file (assuming it is a newer version), but it's very easy to corrupt Windows by incorrectly deleting a file.

Be sure to provide an uninstall, make sure the uninstall satisfies the logo requirements, and be sure to test it as part of the QA process. Your users will appreciate it.

Check the Minimum System Requirements

All programs have minimum system requirements. Installing a program to a computer that doesn't satisfy the minimum requirements means that either the performance will be less than satisfactory or the program flat out will not run at all. The setup program should verify that the user's system satisfies these minimum requirements before performing the installation so that the user can know about any problems ahead of time. Ideally, the program itself should also check for system-related problems that might arise after installation, such as running in an incompatible video mode or missing hardware.

Some system requirements are showstoppers. If the system is running the wrong version of Windows, is missing required software or hardware, or doesn't have enough free hard disk space to copy the program files, the setup program should identify the problem, explain how to solve the problem, and allow the user to fix the problem or stop the installation.

A common setup mistake is to start the installation when there is insufficient disk space. There's nothing more annoying than having a setup program chunk away for 10 minutes only to report that it failed due to insufficient disk space. Let the user know ahead of time. If there is not enough hard disk space, the setup program should suggest that the user stop the installation rather than forcing the user to stop the installation. Why? Because sometimes it can be difficult to know how much space is required to complete an installation. For example, suppose that the user has enough space to install a program and nearly completes the installation process but abandons it at the end to fix some problem. If the user tries to install again, there will still be enough space to complete the job but the reported free disk space will have dropped because of the abandoned setup. The user should still be able to install and ignore any warnings at this point. If not, the user will have to uninstall before reinstalling. This is not fun.

For less serious problems, the goal should be to notify the user of the problem but not prevent the installation. For example, suppose that the system is currently using an incompatible video mode. No problem, since this is a temporary, easily correctable problem. Go ahead and install the program, but notify the user to change video modes before using the program. Of course, the program itself should insist on this as well.

Manage Your Version Resources

An important step in making sure that your software components are properly configured is to make sure all the components you create and use have properly managed version resources. Make sure that all executable files you create have version resources, and be sure to advance the version number with each release.

Use the Registry, not Initialization Files

Although the standards have recommended using the registry instead of initialization files ever since the registry became part of Windows, I have to admit that it took me a while to understand why. After all, initialization files are easy to understand, modify, and program, whereas the registry is significantly more complicated. Here are some of the benefits of using the registry:

• Windows supports multiple users, and the registry allows different users to have different system configurations and each user to have multiple configurations.
• The registry can be remotely administered.
• The registry supports a multilevel hierarchy, whereas initialization files have a fixed hierarchy.
• The registry supports several different data types (including the powerful REG_EXPAND_SZ type), whereas initialization files just support strings.
• The registry has better tools, especially network system management tools. The registry is easier to back up, restore, and modify. For example, it's much easier to search for registry settings by using RegEdit than it is to search for initialization file settings.
• The registry has no size restrictions.
• The registry supports Unicode.

Given all these benefits, it's difficult to justify continuing to use initialization files.

Consider Technical Support

Using a good, well-tested setup program is the single most important step in reducing technical support calls. This is not an exaggeration, and the reason is simple. While your program's advanced features might be its selling point and what gets all the attention, if a user has a problem with an advanced feature maybe you'll get a technical support call and maybe you won't. But if the user cannot install your program, you will get a support call. Guaranteed. And if technical support isn't able to solve the problem, most likely you will get a product return. What good is a program that you can't install?

You should discuss the setup program with your technical support staff and determine whether they need any special functionality. One technique that I have used successfully is to provide a special technical support mode in the setup program, accessed by pressing a function key on the first screen. This mode gives technical support access to additional setup features that you don't want regular users to see. Without such a mode, having the setup program limit users to safe choices also limits your technical support options as well.

Don't Use a Full Screen Setup

This is a personal preference, but I find setup programs that take over the whole screen to be a little old-fashioned and annoying. The typical bad setup program takes over the whole screen, including the taskbar, and then immediately recommends that you quit all other programs. By covering the taskbar, it prevents the user from being able to see whether any programs are running and being able to quit them easily. I know, you can still use the Application key (the one with the Windows logo on it) or use Alt+Tab, but most users don't know this.

Beeping Is OK When Installing from Multiple Disks

As I pointed out in Chapter 4, there's no such thing as an absolute rule in user interface design. Beeping is one of the worst things a user interface can do, but it is appropriate when installing software from a series of disks. Why? Because in this situation, the user doesn't want to be shackled to the computer while the setup program is running. Most likely the user will want to do something else and will appreciate being beeped when it's time to change disks.

Reconsider Displaying Billboards or Bulletins During Setup

I used to think that the technique of displaying useful information on a billboard or the use of a similar metaphor was a great idea. It gives the user useful information about the program and helps the user pass the time. Now I'm not so sure. Why? Again, because the user doesn't want to be shackled to the computer during a long setup process. By displaying useful information in a way that appears only during setup, you make the user feel as if he might be missing out on something important. Furthermore, those using an automated installation won't see this information at all. A better technique is to provide access to such information the first time the program is run and to provide permanent access to it from the Help menu.