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.
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.