Computerworld - 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.
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.
Free Insider GuideCopyright © 1994 - 2012 Computerworld Inc. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of Computerworld Inc. is prohibited. Computerworld and Computerworld.com and the respective logos are trademarks of International Data Group Inc.
