The Windows Installer is an operating system service that was developed by Microsoft to improve the installation and uninstallation of programs, make software deployment in corporate networks easier, and to solve common problems such as shared dll conflicts. The Windows Installer is also a set of rules that developers must follow to take advantage of the service. To use all the features, your application has to be “Windows Installer aware” – so you have to think about installation already when you plan and write your application, not after everything is complete. For example you need to call a special API to enable just-in-time installation of parts of your application (see below).
The Windows Installer has formerly been called “Microsoft Installer” (MSI). Therefore the names of the API functions start with “Msi”, and the installer packages have the .MSI extension.
Features of the Windows Installer Service
The installer registers the application, creates shortcuts and menu entries, associates file types etc. without actually copying the application files to the user’s hard drive. If the user or another application tries to access the advertised program, it is installed on demand. In this case the invoking of the installer is handled by the operating system.
Installation on demand
This is quite similar to Advertising. However it doesn’t refer to a whole application, but to a feature or function that is called from inside the application (e.g. an import filter). When the application tries to access the feature and finds that it isn’t present, it calls the installer service to install it just in time. This way users don’t have to anticipate the functionality they need before they ever used the product. Requirement: The application must be modified to call the Windows Installer API.
Side-by-Side Sharing of Components
Windows 2000 and Windows 98 Second Edition introduce another measure to avoid version conflicts with shared DLLs (aka “DLL Hell”). It is now possible to load several versions of the same file into memory. Microsoft recommends that files like COM servers are no longer copied to a common location but to the application directory. This requires modification of the application to enable it to load components from the application directory, and modifications to the component to avoid conflicts with other instances of the same file. And of course such a component must be registered in a special way, which can be done with the Windows Installer. This also avoids the need for a reboot, because a component located in the application directory will not be in use (locked) by a different application.
Patching and Upgrades
Windows Installer supports several ways to update an existing package. Basically, these are Transforms, but they can be delivered as binary patches.
- Only few files have to be changed.
- Version number and product GUID stay unchanged.
- Typically shipped as binary patch.
- Example: Bug fix, service pack
- Version number is incremented, but product GUID stay unchanged.
- Typically new features are added.
- Example: New version of application.
- Product GUID is changed.
- Applying the upgrade results in a new product
- Example: Upgrading MS Works to MS Office.