With the advent of this Windows 2000 tool, there’s finally a concerted effort to get .DLL hell and similar problems under control.

Inside Windows Installer

With the advent of this Windows 2000 tool, there’s finally a concerted effort to get .DLL hell and similar problems under control.

• By Michael Chacon
• February 01, 2000

To those interested in cool stuff like OSs and designing systems that deliver frames from place to place, the release of Windows 2000 is a highly anticipated event. Well, actually it already has been released, in dribs and drabs throughout the last few years, but there’s still something about the official release day that legitimizes a product. It removes the last excuse of, “It’s still in beta,” when unfortunate events occur.

But sometimes we get so caught up in the cool new way that technology is implemented, we lose sight of the fact that we’re really only building a delivery mechanism. It’s akin to the design engineer or mechanic on a new slick engine focusing on the new fuel efficiencies. In fact, the person using the car wants only to get from one place to another, oblivious to the “magic” under the hood. In IT, this distinction between us and them will only grow with time and maturation of systems.

We mechanics and designers spend considerable time building and maintaining our electronic plumbing systems to present a stable platform for what the end user really cares about. That’s mainly applications (and, I might add, applications that work properly when users select a menu function). As we all know, we can have the most wonderful, elegant, stable, available, and supportable network, only to have irritating, obese code images indulgently read and write to our files systems and registries—not to mention our new directory service. Applications are the acknowledged reason computers even exist; but it would be useful to have a better method to manage them without having to abandon the desktop and run back to the completely centralized mainframe mentality that server-based companies love to tout.

Configuration Control

The underlying problem with application storage and management is that each developer has his or her own idea—and opportunity—about how to implement the installing and storing of configuration information in the registry and directory structure. Developers also rely on shared globs of code without letting any other application know about it, which leads to the most visible manifestation of this chaos, commonly known as .DLL hell. There’s nothing like causing a problem by creating multiple copies or overwriting reliant image versions of shared data link libraries. With the advent of the Windows Installer in Win2K, there’s finally a concerted effort to get this and other problems under control.

The fundamental concept driving Windows Installer is that the set-up or installation of an application isn’t a one-time discrete event. Rather, it’s an on-going process that must be monitored and controlled as long as the application remains a part of the system.

Currently, application installation is a grab bag of techniques. They range from sophisticated proprietary programs to simple self-extracting executables that copy files and configuration information to their appropriate locations in the directory and registry structures. The Add/Remove Programs applet in the Control Panel is the first generation of the Installer Idea, but it’s only marginally useful. Windows Installer essentially takes control of the functions necessary to place data in the proper locations for the application and the operating system to perform properly. The Windows Installer is another step forward in the process of standardizing functional layer abstractions in the operating system, which is a significant part of Microsoft’s Zero Administration initiative.

Following fundamental NT architecture, the Installer is a group of related, but abstracted components. The main Windows Installer function is implemented as a service that’s always available to respond to a particular installation transaction. This design also solves another problem—well, the result of a solution to yet a different problem. (Sometimes our solutions raise other problems.)

For example, it’s a generally accepted wise policy to lock down workstations to prevent users from installing unsupported applications or destroying workstation configuration. However, this also prevents users from installing approved applications unless they also have the appropriate permissions, a classic Catch-22. Since the Installer runs as a service, it can run under the security context of the local system account, giving it the authority and permission to install a program the user can’t. With the Windows Installer, this can also be configured granularly to apply to specific applications. This level of control isn’t available for the Installer service on NT 4.x. In Win2K, the Installer either has permission entirely to install applications, or to run in the context of the user. This obviously can defeat the lockdown of the desktop (yet another nudge towards moving from NT 4.x to Win2K).

The Hierarchy of Installer

The Windows Installer Client Install engine runs, naturally, in user mode. Its purpose is to take the installation commands from the application and pass them to the Installer service as a transaction. This transaction method records all of the files and configuration information that is overwritten, so that if the installation process doesn’t succeed, the entire process can be rolled back and the system returned to its original state. However, once the installation is complete, these rollback files are deleted. Once this occurs, the only way to return the machine to its previous state is to go through the uninstall process.

Just because the Installer service is available doesn’t mean an application will use it. The developer must write to the Windows Installer APIs that talk to the service. (Of course, several companies have published authoring tools for creating packaged applications.) [For reviews of some tools, see Mike Gunderloy’s comparison, “Software in Nice, Tidy Packages,” in the January issue.—Ed.] Fortunately Microsoft is serious about getting developers to use the Installer service; for an application to display the good housekeeping seal of approval, the Win2K certified logo, the application must support the service. This means all supported applications will follow the three-layer hierarchy the Windows Installer is based upon.

At the top of the hierarchy is a product—what needs to be installed, such as Office 2000. A product is identified and tracked by the Installer service through its product code. The instructions delivered with the product are stored in an .MSI file, usually found in the root directory of the product’s CD.

A product is comprised of individual features, defined as a standalone unit of functionality. For example, with Office 2000, Word or Excel is a feature—either of which could also include sub-features; each of the sub-features could be individually installed. If someone wrote a standalone word processor, it would be considered a separate product, and perhaps the spell-checker could be considered a feature. A feature can be shared among different products.

At the bottom of the hierarchy—and where the Installer keeps track of all the files and information—is the component. A component is a related collection of files, registry keys, and other information that must be considered a cohesive group. It’s all for one and one for all. No two components share files with each other. If a component uses a file that another component might also use, each maintains a copy of that file. For two applications to share a file, they must independently ship the same component, which is identified by a Global Unique Identifier (GUID). The first application to be installed will use the component. The second application will see the existing component and raise a counter, called a refcount, to reflect how many applications are using the component. That’s so it won’t be removed until the last application that relies on it is removed. Collecting multiple files within a component minimizes the number of unique objects that the Windows Installer needs to keep track of.

Component Contents

Since a feature is the smallest object in the Windows Installer architecture, the Installer service provides more flexibility than the simple binary selection of most setup routines. Windows Installer allows the user to choose from among four alternatives (as shown in Figure 1):

• Run From My Computer. The files are installed on the local hard drive and run locally.
• Run from CD. The image files are left at the CD or directory source and run from a central location.
• Installed on First Use. This is referred to as advertising an available option. Although the feature (or application) shows up on the menu, it’s not installed until the user selects the function from the menu. This allows the user to essentially customize features from an approved list without administrator intervention.
• Not Installed. No files are copied and the user isn’t informed of the option.

Figure 1. What the user sees when you use the Windows Installer to mandate choices for component installation.

The components contain the actual files that make up each feature of an application. Although component contents are a singular object, components can be shared across features and products. If a component is installed or uninstalled, all of the files and other objects associated with the component are installed or removed. This guarantees that if a component is referenced among multiple features or products, it always contains the same set of objects. Ultimately, the Installer Service manages applications at the component level. Since components are always uninstalled together, when an application is removed, the Installer service won’t leave file or other object litter on the system. Also, since the component is viewed as the smallest unit, the system can easily keep track of how many applications use it and can determine when the last application that depends upon it is removed.

This architecture simplifies and provides distributed on-demand installation of products and individual features of those products. The features are advertised as adjuncts to the products; but because the Windows Installer APIs are built into the Win2K operating system, entire applications can be advertised in menu systems on multiple workstations. When the user selects the advertised application, it’s installed either as the user desires or as the administrator has previously determined. Additionally, since the Windows Installer is aware of all the components on the system, it can also be used automatically to repair damaged installations as well. If a file is missing or corrupted, the Windows Installer can determine the problem and replace all the objects related to the component.

While not the most fascinating aspect of network support, the Windows Installer is a welcome tool to help minimize the tedious task of delivering and maintaining application support and availability. This marks it as one of the most useful features of Win2K.