Overview of Windows Installer

Life is really simple, but men insist on making it complicated. ‚ Confucius

Build no mechanism simply if a way can be found to make it complex and wonderful. ‚ Anonymous

Windows Installer evolved from a long history of earlier methods of installing software. We ‚ ll take a brief tour of the evolution of software installation technology so you can understand Windows Installer in that context.

The evolution of software installation

In the beginning, there was DOS. In those days, installing an application was mostly a matter of copying files from a diskette to the C: drive. This usually involved nothing more complicated than the COPY command, or perhaps the XCOPY command, and maybe a batch file to run it. An application was ‚“installed ‚½ if it simply existed on the hard drive. Uninstalling an application was equally straightforward: all you did was delete the files in the application ‚ s directory. Each application was an entity unto itself, interacting with little if anything outside of the files in its own directory. Life was simpler then, and developers didn ‚ t have to give much thought to how to install their applications.

With the advent of Windows and 32-bit computing, applications grew much more powerful and useful, but also more complex. Applications now consisted of many more files than before, and were often designed as a set of collaborating components. Some of these components might be unique to the application while others might be shared with other applications on the same computer. For an application to be considered ‚“installed, ‚½ not only did the application ‚ s own files need to be present in the proper location(s) on the hard drive, but any common components also had to be present and accessible by any application that needed them. Such common components might or might not already exist on the target machine, meaning your application might or might not have to install them. This and other considerations meant that in order to consider an application ‚“installed, ‚½ the operating system had to be aware of it.

Uninstallation was of course also more complex. No longer could you uninstall software simply by deleting all of the files in the directory where it was installed. Now you had to be able to identify and remove only those things that comprised the application itself ‚ its files, shortcuts, registry entries, etc. ‚ while retaining components used by other applications. This implied the installation process needed to build and maintain a record of what it had done so it would know what to undo when the application was uninstalled .

Again, this meant the operating system itself had to be involved in keeping track of whether an application was installed or not, and whether or not a particular component was common to more than one application. In a nutshell , the computer became stateful . When a new software application was installed, the computer assumed a new state reflecting that fact. When the application was uninstalled, the computer ( ideally ) reverted to its pre-installation state, at least insofar as that application was concerned .

So far so good, but what happened when an installation failed midway through, or when an uninstall removed files while leaving shortcuts or registry entries in place? The computer could be left in an unstable state, with some parts of an application present and other parts not present, and no real way for anyone to know exactly what happened .

Enter the need for better installation software. Newer and better setup tools made possible the development of complex installation scenarios that installed application software with a high level of reliability. These tools also typically provided the end- user with an easy, interactive process to follow when installing or uninstalling the application.

Because third parties independently developed these tools, each one naturally took its own approach to things. This had two important consequences: the deployment package produced by one installation setup program might handle the installation tasks quite differently than the deployment package produced by another installation setup program, and in any case, the deployment package was a black box as far as the end user was concerned. The second issue was of particular concern to network administrators, who of course are responsible for insuring that all the computers on their network are maintained in a reliable and consistent state. Who knew what a rogue installation package might do, or what havoc it might unleash if it failed to complete or installed things improperly?

So, finally, enter Windows Installer.

The arrival of Windows Installer

Windows Installer was initially developed for deploying Microsoft Office. It was created to meet the need for an installation technology that enabled a complex application such as Office to be installed as a suite of collaborating components rather than as a single monolithic application or a disjointed series of independent applications.

Microsoft ‚ s vision for the Windows Installer went far beyond its own internal use, though. For some period of time, system administrators had expressed the need for an installation technology based on a standard, open architecture rather than one that functioned as a black box. The fact that Windows Installer setup files are based on a relational database model whose structure is openly published and fully documented, as well as the fact that system administrators and others ‚“in the field ‚½ can view and modify Windows Installer setups, are among the direct results of these design objectives.

Version 1.0 of the Windows Installer was used for the release of Office 2000 in June 1999. Shortly thereafter Windows Installer was integrated into the Windows operating system itself. Windows Installer version 1.1 was released as an integral part of Windows 2000, and was also released as a redistributable for older versions of Windows. Among the changes introduced in version 1.1 were new features for handling upgrades and installing COM+ components. Windows Installer version 1.2 was released with Windows Millennium Edition (Me) and included support for Windows Me system file protection. The current version of Windows Installer, version 2.0, was released with Windows XP. Windows Installer version 3.0 is currently in beta.

In short, Windows Installer is now a native part of Windows 2000, Windows Me, and Windows XP and is also available as an add-on for Windows 95, Windows 98, and Windows NT. Windows Installer can therefore handle the installation of application software on all 32-bit Windows platforms, and, as of version 2.0, it can also accommodate 64-bit Windows applications.

Windows Installer Design Objectives

Windows Installer set out to accomplish several important objectives. Among these were:

• to create an open architecture for installing software.

• to implement a standardized installation process for all applications.

• to manage shared resources.

• to allow users to choose the parts of an application they want to install.

• to maintain the state integrity of the computer during and after installation.

• to allow for customization of an installation.

• to allow network administrators to install software on ‚“locked down ‚½ desktops throughout an organization.

• to provide a mechanism for the modification, repair, and removal of installed software.

This is an ambitious list. Let ‚ s see how Windows Installer addresses each of these objectives.

Open architecture

As we noted earlier, prior to Windows Installer installation packages tended to be black boxes insofar as the end user or the system administrator was concerned. There was usually no way to know exactly what a given setup program was going to do to a system, let alone any way of modifying it. Installing application software with such a setup package essentially meant trusting the setup tool ‚ and, perhaps more importantly, trusting the setup developer ‚ to get it right.

Unfortunately, it wasn ‚ t always right, and the consequences of getting it wrong, particularly on a network workstation, could be ugly. For example, an installation might fail to properly register its components, or it might overwrite the current version of a shared DLL with an older version. An uninstall might delete components still required by other applications, or might delete data files from
a file server even though those files contained live data and were still in use by other users. These situations can be real productivity killers, not to mention they ‚ re expensive to fix, particularly when a system administrator has to be called in and might have to spend hours trying to figure out what happened.

Moreover, it ‚ s difficult if not impossible for a setup developer to anticipate all of the various environments where an application might need to be installed. A rigid setup package places the entire burden of anticipating all possible scenarios on the setup developer, while an open, flexible setup package enables the local system administrator to exercise some control over the installation process if necessary.

Windows Installer addresses these concerns by using an open architecture for setup packages. Later in this chapter we explore the contents of a Windows Installer setup package in some detail, and in doing so you ‚ ll see that anybody can open a Windows Installer setup package, find out what ‚ s inside, see what it does, and even make changes if necessary.

Standardized installation

Windows Installer runs as a service of the operating system. Because the structure of a Windows Installer setup package is standardized, and because all Windows Installer setup packages are processed by the Windows Installer service, installation of every application is handled in a standardized manner. This eliminates the risk of a rogue installation program rendering a computer unstable or possibly even unusable by improperly handling an installation task, such as managing shared resources.

Managing shared resources

A shared resource means a resource used by more than one application on the computer. The term ‚“resource ‚½ in this context typically refers to program components such as DLL files and ActiveX controls. The VFP runtime files are a good example of shared resources. One objective of Windows Installer was to significantly improve the management of shared resources and to put an end to ‚“DLL hell, ‚½ the popular name for what happens when an installer overwrites a shared DLL with an incompatible or an out-of-date version of the same DLL, or when an uninstaller removes a DLL still used by another program. In either case, the result is another application is broken.

Windows Installer addresses this issue in a number of ways. It manages the registration of common resources during installation in such a way it can roll back the registrations if the install is canceled or fails to complete. Windows Installer also keeps track not only of the number of programs using a shared resource, but which specific programs are using it.

Choosing what to install

Windows Installer setups are arranged into functional building blocks called features and components. The organization of a product into features is what enables the end user or system administrator to choose the parts of the product they want to install, whereas the grouping of an application ‚ s files and other resources into components is what gives the developer control over what needs to be installed to implement each feature. We cover features and components in detail later in this chapter.

Managing state integrity

Windows Installer treats the installation of a product like a database transaction: either the whole product successfully installs, or none of it installs . In order to accomplish this, Windows Installer maintains temporary files during installation so it can perform a rollback to the pre- installation state of the computer if the installation fails or is canceled. If the installation is successful, Windows Installer performs the equivalent of a database transaction ‚“commit, ‚½ and then removes its temporary files. This guarantees the computer is either completely updated to the desired post-installation state or completely reverted to its pre-installation state.

Customizing installations

Windows Installer provides a mechanism called ‚“transforms ‚½ for customizing an installation. A transform is a set of changes applied to the installation database, usually at install time, in order to modify the installation. This is primarily intended for use by system administrators, who may for example want to limit the feature set the user can choose from during installation. Another use for transforms is to enable localization of an install for different languages.

Installation on locked-down desktops

One of the key challenges facing system administrators before Windows Installer was how to deploy software throughout an organization without having to physically visit each desktop. This was particularly difficult when the installation of software required administrative privileges, which of course are not typically granted to end users. Windows Installer addresses this situation by employing a client/server model where the user interface and certain pre- installation tasks are run on the client side in the user ‚ s context, while the core installation tasks ‚ copying files, writing registry entries, etc. ‚ run with elevated privileges in the system context on the server side. This enables end users to perform installations that require privileges not normally granted to them, while keeping the system administrator in control of the process.

Modification, repair, and removal

Following the successful installation of a product, any one of several things might happen that require access to the installation package again: the application can get broken and need repair if a required file is removed; the user may want to install a feature not originally installed; or the user might decide to uninstall the application entirely. Windows Installer prepares for these situations by caching a copy of the MSI file on the local computer during installation. These cached files are typically located in the {Windows}\Installer folder.

As you would expect, Windows Installer uses the registry to store information about the products it installs. This information includes the file name and location of the cached copy of the MSI file. Figure 1 shows the registry information from the installation of a sample application. The file name and location of the cached package is shown as the ‚“LocalPackage ‚½ value.

Figure 1. This is the registry information from the installation of the demo application. The name and location of the cached MSI file are stored in the ‚“LocalPackage ‚½ value.

Note ‚  

On this author ‚ s Windows 2000 machine, the registry entries shown in Figure 1 are found at HKLM\Software\Microsoft\Windows\CurrentVersion\Installer\ UserData\S-1-5-18\Products\2146ECB43F287D1138680005AD468B15\ InstallProperties. If you think the penultimate portion of this path looks like a GUID, you ‚ re right ‚ it ‚ s a scrambled version of the product code GUID for this app. Information about Windows Installer GUIDs is discussed later in this chapter.

When you use the Add/Remove Programs applet to change or remove an installed product, Windows Installer fetches the cached copy of the MSI file. Repair or removal of the product can be performed without access to the original CD or other installation source media. If the user chooses to install a feature not originally installed, however, then the original CD or other source media is needed because the resources required by the new feature would not have been cached during the original installation.

Working with Windows Installer

Windows Installer service

Beginning with Windows 2000, the Windows Installer service became part of the operating system. Windows 2000 was originally released with version 1.10 of the Windows Installer. The latest version of Windows Installer, which is version 2.0 as of this writing, is available for download from Microsoft as a redistributable file for Windows 2000 as well as for Windows NT 4.0, Windows 95, Windows 98, and Windows Me. Windows XP already contains version 2.0 of Windows Installer.

As an application developer, you may very likely need to distribute your application to people using computers with older versions of the Windows operating system, and you can ‚ t rely on Windows Installer already being installed on those computers. To address this possibility, you can choose to include Windows Installer itself as part of the setup package for your product. If SETUP.EXE detects that Windows Installer is not already installed on the target computer, it first installs Windows Installer, and then installs your application.

The Windows Installer executable program is MSIEXEC.EXE. This program reads the MSI file and interprets instructions it contains in order to carry out the installation of your application. When you right-click on an MSI file and choose ‚“Install, ‚½ ‚“Repair, ‚½ or ‚“Uninstall ‚½ you are running MSIEXEC.EXE. If you install software from a Windows Installer setup executable ‚ typically SETUP.EXE ‚ the MSIEXEC.EXE program is called after the MSI file and other installation resources are extracted from the setup package.

MSIEXEC.EXE also has a command line interface. You can use the command line interface to pass parameters to the installer to control how it handles the installation. You can find more information about this in the section ‚“The Windows Installer executable program ‚½ later in this chapter.

Windows Installer SDK

The Windows Installer Software Development Kit (SDK) is a set of tools for working with Windows Installer files. It is part of the Platform SDK and available for download from Microsoft at http://www.microsoft.com/msdownload/platformsdk/sdkupdate/ .

Note ‚  

The Windows Installer SDK is a relatively small 8.4MB download. However, depending on your OS and what ‚ s already installed, you may also be required to download the Core SDK as well as a couple of other dependencies, which can bring the total size of the download to over 260MB. As an alternative, you can order the SDK on CD for a nominal cost. The SDK is also available with the MSDN Universal subscription. Information on various ways to obtain the complete SDK are at http://msdn.microsoft.com/library/default.asp?url=/library/enus/sdkintro/sdkintro/obtaining_the_complete_sdk.asp .

If you are using a Windows Installer-base setup tool such as InstallShield Express you don ‚ t need the Windows Installer SDK to build and maintain your Windows Installer setup packages, but the SDK contains many useful tools. Among the most important of these is Orca, the Windows Installer database editor. We ‚ ll be using Orca a lot throughout the rest of this chapter and we take a closer look at Orca in the next section of this chapter, including information on how to install it.

Among the other tools included in the Windows Installer SDK are a pair of files you can use to create Windows Installer patches. The program MSIMSP.EXE, in conjunction with PATCHWIZ.DLL, can be used to generate patch packages. This can be particularly useful if the setup tool you ‚ re using, such as the version of InstallShield Express that ships with Visual FoxPro, cannot create patch packages on its own. Other useful things in the SDK include tools to merge two databases, to generate transforms, and to analyze Windows Installer log files.

Given that all of these tools are freely available as part of the Windows Installer SDK, you may be asking yourself why you would need any other tools ‚ such as those from InstallShield or Wise ‚ to create and maintain your Windows Installer setup packages. The answer is the same as the answer to the question, why do your users need your applications instead of simply using VFP itself? The answer, of course, is that using a setup tool such as InstallShield Express, InstallShield Developer, or Wise for Windows Installer makes it much easier for you to create and maintain your Windows Installer setup packages, just as using your applications makes it much easier for your clients to create and maintain their databases.

Orca

Orca is the Windows Installer database editor. It is an indispensable tool when working with Windows Installer files. Orca puts a lot of power in your hands: not only can you use it to open and look around inside Windows Installer database (MSI) files and merge modules (MSM) files, but you can also use it to edit the contents of these files. Needless to say, making direct changes to a Windows Installer database is something you should do only if you ‚ re sure you know what you ‚ re doing (but of course, after reading this chapter, you will!).

After installing the Windows Installer SDK, you can find the Orca installation file, ORCA.MSI, in Program Files\Microsoft SDK\Bin. To install Orca, right-click ORCA.MSI and choose ‚Install ‚ from the shortcut menu. Once Orca is installed, you can right-click an MSI file and choose ‚Edit with Orca ‚ from the shortcut menu. You can also run Orca from the Start menu and open an MSI file with Orca ‚ s File Open menu.

One thing to be aware of when using Orca is that Orca changes the file ‚ s Modified date even if you don ‚ t make any changes to the file. This may seem harmless enough at first, but you need to be careful because a file ‚ s Modified date is part of the versioning rules Windows Installer uses to determine whether to overwrite the file during installation of an update. When dealing with non-versioned files, Windows Installer assumes a file whose Modified date is different than its Created date has been updated since it was installed, and the default behavior in this case is to not replace the file. More information about how Windows Installer determines which files to replace is presented later in this chapter in the section on ‚“Versioning rules during installs. ‚½

Note ‚  

IMPORTANT! Peeking inside another vendor ‚ s MSM file might not be a good idea unless you back it up first. A good example of this occurred with the SP1 update for VFP 7. The VFP 7 SP1 release included an updated merge module for the VFP runtime files. This new merge module had the same file name (VFP7RUNTIME.MSM) as the original merge module. The SP1 merge module had a Modified data of 01/04/2002. If you had opened the original VFP 7 runtime merge module in Orca sometime after 01/04/2002, but before installing SP1, then its Modified date would be later than its Created date. Therefore when you installed VFP 7 SP1 the new SP1 merge module would not be copied to your computer because the one already on your computer would appear to have been updated by you. Merge modules are not versioned files, so Windows Installer relies on the Created date and the Modified date to determine whether it has been updated and therefore which one should prevail.

Visual Studio Installer

Visual Studio 6 came with a tool called the Microsoft Visual Studio Installer, which is a tool for creating Windows Installer setups. A merge module for the VFP 6 runtime files was also made available, enabling you to create a Windows Installer setup package for your VFP 6 applications. There were a couple of papers written on how to do this, and some of you may have experimented with or actually used the Visual Studio Installer to deploy your VFP 6 apps, but our guess is most VFP developers continued to use the setup wizard until VFP 7 came along and they were forced to make a change. Nonetheless, Visual Studio Installer is one of the tools you can use to author Windows Installer setup packages.

Note ‚  

Visual Studio Installer is still available for download from Microsoft at http://msdn.microsoft.com/vstudio/downloads/tools/vsi11/download.aspx . You must be a licensed user of Visual Studio 6.0, or at least one of its development tools, to qualify for this download. A tutorial on using Visual Studio Installer with VFP 6.0 is at http://msdn.microsoft.com/library/default.asp?url=/library/enus/dnfoxgen/html/vfpvsit.asp .

Third-party Windows Installer tools

The first real exposure to Windows Installer-based setup tools most VFP developers had probably came in the form of InstallShield Express Limited Edition for Visual FoxPro, which accompanied the release of VFP 7.

Today there are many setup tools on the market that enable you to build and work with Windows Installer setup packages. When the Windows Installer service was first created, Microsoft worked with two companies ‚ InstallShield and Wise Solutions, Inc. ‚ to develop setup tools for building Windows Installer packages. As Windows Installer itself evolved, so did these and the other third-party Windows Installer setup tools.

Visual FoxPro 8.0 comes with a more full-featured version of InstallShield Express than did VFP 7. In many cases, it may be the only setup tool you need. If your setup requirements are more demanding, however, you many want to move up to the full version of InstallShield Express (which is version 4.0 as of this writing) or even to one of more fully-featured ‚ and more expensive ‚ tools such as InstallShield Developer or Wise for Windows Installer.