Installshield Intro -- Bring the Pain
By Chris Koeritz
Design
I am co-opting this section for talking about the
"design" of Installshield installations, if there can be said to be
one. Obviously, there is a lot of structure buried under the
Installshield program, the design of most of which Microsoft can be
held responsible for when they produced the Windows Installer (or
MSI--MicroSoft Installer). MSI is a complex system that often
works, but in the end has some very annoying complications that the
Setup Developer is left holding the bag on. The remainder of the
section will mostly be opinion-free, but I can only liken my role in
introducing you to Installshield to that of Cerberus introducing souls
to hell.
Forget what you know about Install programs as
dynamic, goal-directed programs with flashy interfaces. Microsoft
has boiled down some of the essential nuggets of an installation into
the MSI format, which is essentially interfaceless. It's up to
vendors like Wise and Installshield to add glitz back in, if
desired. Installshield supports extending the Basic MSI type of
installer with a User Interface front-end, such as that used by
LightLink.
The main product of an MSI installation package
building tool is the MSI file itself. This file is crafted
differently according to the Windows Installer version that it
supports, but it is in essence just a database. The MSI file is a
set of tables with content for the different phases of an
Installation. So, anything that an MSI installer does (or can do)
must be something that can be represented as a row in a database table.
There are many activities that Microsoft has
envisioned an installation program may need to perform, and a lot of
operations are provided for these tasks. These include things
like registering services, copying files into place, deleting files,
etc. Each of these types of tasks lives as a line in a table
somewhere. Hopefully you will never need to know more detail
about the MSI tables than that, except for one important table which
has the installation properties stored in it. The properties are
the set of values used by the Installation for directory locations and
so forth. These can be reconfigured by a knowledgeable system
admin to make the installation perform differently.
It is important to have a basic understanding of the
installation process, because it helps fit the random pieces of the
Installshield interface together into a somewhat sensible scheme.
Each installation follows a sequence of activities. In general,
the majority of actions in a sequence are handed to you when you create
the basic framework of the install with a wizard. At some point
in the sequence, choices are made about which features to
install. This can either be automatic, based on parameters passed
to the MSI, or it can be user driven, via a set of dialogs. Each
feature is a collection of components that will be installed, but that
does not mean each component is merely a collection of files. A
component can also be one of the provided types of actions, such as
writing a registry entry.
Since even Microsoft realizes that they cannot think
of everything, there is a special type of action called a custom
action. These are actions that the setup developer creates to
perform more general tasks than might be provided in the default
toolkit. For example, LightLink has a custom action that performs
a large number of configuration steps by running some script
files. Custom actions are still just lines in a database
somewhere, but they provide a way to arbitrarily link to other programs
rather than being limited to features directly provided by MSI.
The actions listed in a sequence will not always
necessarily be operated on. Each action is dependent on a set of
conditions that dictate whether it can fire or not. Some
conditions are simple, such as those based on the choices of components
made in the UI. Others are more complex and may themselves even
need to be set via a custom action, especially if the condition is
needed for a UI decision.
At the time the MSI package is being installed,
Windows passes the package over to the msiexec process. This is a
system process that runs as a service (under the LocalSystem, aka
SYSTEM, account). The msiexec application simply iterates across
the tables in the MSI in a pre-defined way until it hits an error or
concludes the installation.
For some unknown reason, an MSI package is not
allowed to invoke another MSI package while the installation is
running. This leads to numerous hilarious problems and is the
reason that merge modules are created. The merge module allows
what is basically an entire, separate installation program to be
stuffed into your own installer such that the MSI constraints against
running two MSIs are not violated. The LightLink installer uses a
wide variety of merge modules to plug in third-party features we depend
on, or even "first-party" features like extensions to Windows written
by Microsoft but not shipped in their default OS. The above is a
really rough overview of Windows Installer and Installshield, but
hopefully it provided some guidance on how things flow inside an MSI
file when it is running on the target system.
Glossary
Action: The fundamental unit of processing in an installation.
Component: A quantum of installable material. This can be a file,
multiple files, or even an action provided by the Windows Installer
support.
Condition: A boolean statement involving properties which is used to guide whether actions are taken or not.
Custom Action: An action created by the setup developer for a purpose
which is either not available through MSI or which could be better
implemented outside MSI.
Dialog: A user interface component that displays or gathers info (or both) for the user.
Execute Sequence: The set of actions taken once the UI is put away and the installation is given the go ahead.
Feature: A major division of the installation's deliverables.
Features can be made visible to the user as choices they are given
about the installation payload and installed configuration. During the
UI sequence, users select which features will be installed.
Key File: A component can have a key file that represents the presence
or absence of the component. If the key is absent or out of date, the
component must be installed.
Property: A string or numeric value with a name that can be used to
store locations, settings, and other facts about the installation.
Sequence: The ordered stream of activities that make up the install process from initial execution to completion.
UI Sequence: The set of actions taken to interact with a user. Generally involves dialogs and fact checking.
Comparisons
Other operating systems had actually already created
general installation packaging formats that perform really well.
Many of these existed long before Windows Installer was released into
the wild. Most Linux distributions religiously use a packaging
format to deliver their OS itself as well as updates to the OS.
In Redhat Linux, there is the RPM format, and in Debian Linux, there is
the DEB format.
Each of these formats is widely used by other
distributions also. I'm afraid that if you expect MSI to live up to
either of these types of packaging methods, then you will be
disappointed. For example, where a Debian Linux install can be said to
be completely determined by the set of DEB packages that are installed,
there is no such promise for Windows. A Windows user may not even know
of some MSI packages that got installed, whereas others will be visible
in Add/Remove.
Unlike Debian, a Windows user can easily break a
program by uninstalling something it depends on; the Windows user is
not always warned about interdependencies between packages. And Windows
itself is definitely not packaged into discrete, installable MSI chunks
that can be switched out for better versions at any time. Debian Linux
suffers from none of those disadvantages; the set of installed packages
and their interdependencies are clear, and installing a new kernel is
nothing more than getting the package and installing it like any other
package.
Further, each of the distributions will generally
have a huge number of free packages available for a variety of
purposes, and only a small number of these are installed by default.
Microsoft provides no centralized repository of MSIs for customer's
needs, nor would those packages be free (as in beer) if there was such
a repository.
