Installation

The following sections provide guidelines for installing your application's files. Applying these guidelines will help you improve system stability and reduce the clutter of irrelevant files when the user browses for a file. In addition, you'll reduce the redundancy of common files and make it easier for the user to update applications or the system software.

Support the Windows Installer or a third-party setup toolkit that supports the Windows Installer. The Windows Installer not only provides support for installing and uninstalling your application's files, it also includes support for on-demand installation of specific features and repair of damaged installations. The Windows Installer also integrates with Add/Remove Programs in Control Panel and with the Windows 2000 Active Directory services. For more information about the Windows Installer, see the Microsoft Platform SDK on the MSDN Online Web site at http://msdn.microsoft.com/ui/guide/sdk.asp.

Copying Files

When the user installs your software, avoid copying files into the Windows folder (directory) or its System subfolder. In highly managed locked-down computer scenarios, you may not be able to write to these folders. Instead, create a single folder, preferably using the application's name, in the Program Files folder (or the location that the user chooses). In this folder, place the executable file. For example, if a program is named My Application, create a My Application subfolder and place My Application.exe in that folder.

In your application's folder, create a subfolder named System and store in it all support files that the user does not directly access, such as .dll files and Help files. For example, place a support file named My Application.dll in the subfolder Program Files\My Application\System. Hide the support files and your application's System folder and register the System folder's location using a Path value in the App Paths subkey under HKEY_LOCAL_MACHINE \Software\Microsoft\Windows\CurrentVersion. Although you can place support files in the same folder as your application, placing them in a subfolder helps avoid confusing the user and makes files easier to manage.

Remember that the System folder installed by Windows is intended for system files only. Avoid installing any files here unless they are necessary for compatibility issues.

The system provides support services in Ver.dll for helping you do version verification. For more information about this utility, see the Microsoft Platform SDK on the MSDN Online Web site at http://msdn.microsoft.com/ui/guide/sdk.asp.

If you store a new file in the System folder installed by Windows, register a corresponding entry in the SharedDLL subkey under the HKEY_LOCAL_MACHINE key.

If a file is shared, but only among your applications, create a subfolder in the following location and store the file there:

Alternatively, for application "suite" installations where multiple applications are bundled together, you can create suite subfolders as follows:

In either case, register the path using the Path subkey under the App Paths subkey.

When you install an updated version of a shared file, ensure that it is upwardly compatible before replacing the existing file. Alternatively, you can create a separate entry with a different file name (for example, Vbrun301.dll).

Windows no longer requires the Autoexec.bat and Config.sys files, so make sure that your application also does not require these files. To make your program accessible from the command window or the Run dialog box without registering it in the PATH environment variable, use the App Paths section of the registry.

In addition, do not make entries in the Win.ini file. Storing information in this file can make it difficult for users to update or move your application. Also, avoid maintaining your application's own initialization file. Instead, use the registry. The registry provides conventions for storing most application and user settings. The registry provides greater flexibility, allowing you to store information on a per-computer or per-user basis. It also supports accessing this information across a network.

Make sure that you register the types supported by your application and the icons for these types along with your application's icons. In addition, register other application information, such as information required to enable printing.

Providing Access to Your Application

To provide easy user access to your application, place a shortcut icon to the application in the Programs folder on the Start menu.

However, avoid adding entries to the Programs menu for every application you might include in your product; this quickly overloads the menu. Always limit what you include on the Programs menu to applications that the user will frequently access. Do not include Readme, Help, or Uninstall entries on the Programs menu. If your product includes several applications, include an entry only for the one that the user will most frequently use. If your program includes other important utilities, you can also include a folder on the Programs menu that provides access to these other items.

When you install entries on the Programs menu, consider whether they should be available to all users or on a per-user basis. Windows supports user profiles so that each user can customize the configuration.

Avoid adding items to the top of the Start menu. This area is intended to provide access to key user features provided by the operating system and user customization. Putting an entry here may interfere with the user's preferences and access.

Avoid adding icons to the Windows desktop. If you want to provide access to your application from the desktop, include an option for adding a shortcut icon in your application's interface.

Similarly, avoid using the taskbar Quick Launch or status notification area as a launching point for your application or utility. Quick Launch is intended primarily for system services and user customization. The status notification area is intended for letting users know about events and information they need to respond to, not for providing a more accessible entry point for your programs. Overloading these areas of the taskbar defeats its purpose and in general is not an effective access point for novice and intermediate users.

Designing Your Installation Program

Your installation program should offer the user different installation options such as the following:

Typical setup (default): Installs using the common defaults, copying only the most common files.
Compact setup: Installs the minimum number of files necessary to operate your application. This option is best for situations where disk space must be conserved — for example, on laptop computers. You can optionally add a Portable setup option for additional functionality designed especially for configurations on laptop computers, portable computers, and portable computers used with docking stations.
Custom setup (for experienced users): Allows users to choose where to copy files and which options or features to include. This can include options or components not available for compact or typical setup.
CD-ROM setup: Installs from a CD-ROM. This option allows users to select which files to install on the hard disk and which files they want to run directly from the CD.
Silent setup: Installs using a command-line switch. This allows your setup program to run with a batch file and without any visible user interface.

In addition to these setup options, your installation program should be a well-designed, Windows-based application and follow the conventions detailed in this book and in the following guidelines:

Supply a default response to every option so that users can step through the installation process by confirming the default settings (that is, by pressing the ENTER key).
Tell users how much disk space they will need before proceeding with installation. In the custom setup option, adjust the figure as users choose to include or exclude certain options. If there is not sufficient disk space, let users know.
Offer users the option to quit the installation before it is finished. Keep a log of the files copied and the settings made so the canceled installation can be cleaned up easily. Also make sure your installation program can handle a previously failed or incomplete uninstall.
Ask users to insert a disk only once during the installation. Lay out your files on the disk so that users do not have to reinsert the same disk multiple times.
Provide a visual prompt and an audio cue when users need to insert the next disk.
Support installation from any location. Do not assume that installation must be done from a logical MS-DOS drive (such as drive A). Design your installation program to support any valid universal naming convention (UNC) path.
Provide a progress indicator to inform users about their progress through the installation process.
Do not require users to restart the computer after installation unless it is unavoidable.
Avoid including non-essential information in your Setup program. Keep legal statements to a minimum and do not include any Readme information.
Keep supplemental windows to a minimum. If possible, try to restrict your installation to a single window. If you are creating your own installation program, consider using the wizard control or design. Following the guidelines for wizards will result in a consistent interface for users.

Name your installation program Setup.exe or Install.exe (or the localized equivalent). This allows the system to recognize the file. Place the file in the root folder of the disk the user inserts. This allows the system to run your installation program automatically when the user clicks the Install button in the Add/Remove Programs utility in Control Panel.

Installing Fonts

When your application installs fonts on a local computer, determine whether the font is already present. If it is, rename your font file — for example, by appending a number to the end of its file name. After copying a font file, register it with the system by calling the appropriate font installation interface so that it will be available for use immediately.

Installing Your Application on a Network

If you create a client-server application so that multiple users access it from a network server, create separate installation programs:

For more information about designing client-server applications, see the Microsoft Platform SDK on the MSDN Online Web site at http://msdn.microsoft.com/ui/guide/sdk.asp.

Design your client software so that an administrator can deploy it over the network and have it automatically configure itself when the user starts it.

Because Windows may itself be configured to be shared on a server, do not assume that your installation program can store information in the main Windows folder on the server. In addition, do not store shared application files in the "home" folder provided for the user.

Design your installation program to support UNC paths. Also, use UNC paths for any shortcut icons you install in the Start Menu folder.

Uninstalling Your Application

Users may need to remove your application to recover disk space or to move your application to another location. To facilitate this, provide an uninstall program with your application that removes its files and settings. Remember to remove registry entries and shortcuts your application may have placed in the Start menu hierarchy. However, when removing your application's folder structure be careful not to delete any user-created files (unless you confirm their removal with the user).

Your uninstall program should follow the conventions detailed in this guide and in the following guidelines:

Display a window that provides users with information about the progress of the uninstall process. You can also provide an option to allow the program to uninstall "silently" — that is, without displaying any information so that it can be used in batch files.
Display clear and helpful messages for any errors your uninstall program encounters during the uninstall process.
When uninstalling an application, decrease the usage count in the registry for any shared component — for example, a .dll file. If the result is zero, give users the option to delete the shared component with the warning that other applications may use this file and will not work if it is missing.
If you install your application using a CD-ROM, avoid requiring users to insert the disc to start the uninstall program.
Restore any file associations your application took over.

Your uninstall program should remove all files in the Program Files folder that it uniquely owns. If your application has files stored here that you are not sure whether you should remove, they probably should not have been stored in the Program Files folder. Files that your application shares with other applications are the exception. For more information about using the file system appropriately to store your application's files, see the guidelines earlier in this chapter.

When you register your uninstall program, your application will be listed on the Uninstall page of the Add/Remove Programs utility included with Windows. To register your uninstall program, add entries for your application to the Uninstall subkey, as follows:

You must supply complete names for both the DisplayName and UninstallString values for your uninstall program to appear in the Add/Remove Programs utility. The path you supply to Uninstall-String must be the complete command line used to carry out your uninstall program. The command line you supply should carry out the uninstall program directly rather than from a batch file or subprocess.

Supporting AutoPlay

Windows supports the ability to run a file automatically when the user inserts removable media that support insertion notification, such as CD-ROMs, PC Cards (PCMCIA), hard disks, or flash ROM cards. This feature is named AutoPlay. With AutoPlay, you can include a custom icon for the media type, start a custom program automatically, and provide custom shortcut menu entries for the media icon. For more information about this feature, see the Microsoft Platform SDK on the MSDN Online Web site at http://msdn.microsoft.com/ui/guide/autoplay.asp.