No more DLL hell. That was just one of Microsoft Corp.’s goals when it introduced the Windows Installer service along with Windows 2000 nearly four years ago. The service, which now runs on Windows XP, Windows Server 2003 and earlier versions of Windows by way of service packs, was designed to provide much-needed consistency to the Windows application installation process.

Before Windows Installer was available, software developers created their own automated installation scripts or used third-party authoring tools to create an installation program. Each followed different rules, had a limited ability to keep track of files also in use by other applications and had no ability at all to track shared use of nonfile resources such Windows registry keys.

More

Computerworld QuickStudies This situation resulted in the classic problem in which one application would install a Dynamic Link Library (DLL) in the Windows system directory only to have another application overwrite it with a different version, breaking the first application in the process. Uninstall programs likewise unknowingly removed DLLs or changed registry keys that other applications were sharing.

Windows Installer enforces a single set of installation rules that all compliant applications follow, including versioning rules that prevent the overwriting of newer files with older ones. It also keeps track of all changes made to Windows, including any made to the file system and registry keys.

For Installer to work, software developers must replace traditional installation scripts with Windows Installer package files (called .MSI files, after the file extension). And since Windows Installer can track only installations that follow the .MSI format, end users will reap the full benefits only when all applications installed on a Windows machine support Windows Installer.

An .MSI package functions as a small relational database with fields containing all of the information and instructions that Windows Installer needs to successfully deploy an application. At runtime, Windows Installer converts the .MSI data into an install script and an uninstall script. This allows for a graceful rollback of the application and restoration of the system to its previous state if an install fails. For example, if an upgrade to Office System fails, the system can roll back to the previously installed Office XP version and the user can continue working—something that didn’t always happen before.

The .MSI breaks the installation data into three parts. This architecture enables it to install applications without ever having to manage individual resources directly. Instead, it groups registry keys, files and other resources into components, such as the Speller Engine in Microsoft Office. Components group together interdependent resources, such as an executable program file and the registry key that holds license information.

Windows Installer tracks all changes made to the system during the installation at the component level and keeps “refcounts” that tell how many applications share a given component. It also assigns each component a globally unique identifier (called a GUID or “gwid”) and a keypath, which Windows uses to identify the component. By maintaining refcounts at the component level rather than for each individual resource, Windows Installer can easily track all shared resources, not just files. DLLs and other resources are deleted only when the last component that uses them is deleted.

The .MSI package groups components into features. These are the user-recognizable chunks of an application, including options that users can choose to install, such as Word in the Office suite. Subfeatures, such as a spell checker, can be nested within a larger feature for more granular control of the installation process. Features can share components, and they allow more installation options than do scripted installs. With .MSI, features can be installed to run locally, to run from a secondary location such as a product CD, or they can be “advertised,” appearing in an application’s menu but installing only when the user invokes the feature. All of the features that make up an application are then aggregated into a single .MSI file.

Management API

Windows Installer also includes a management application programming interface (API) that it uses to keep track of installed products, features, components and keypath data. Using this API, an application management tool can repair a broken application. Through the API, it can determine which component isn’t working and reinstall just that component and its associated resources, rather than the entire application.

Administrators can customize the .MSI package by creating a complementary transform (or .MST) file. The transform can provide answers to Windows Installer when the .MSI file calls for user input, such as choosing which options to install or the correct installation path. It can also remove unwanted features from the basic installation.

Software vendors have been slow to adopt the .MSI format. Nearly four years after Windows Installer’s release, many applications still use non-.MSI installation routines. To get the full benefits of Installer, enterprise administrators have turned to automated application packaging tools . Such tools can create .MSI packages for noncompliant applications as well as build transforms for existing packages. For most other users, however, the legacy of installation conflicts will linger until every noncompliant Windows application on the desktop has been updated.

See additional Computerworld QuickStudies