Blog
MSI Introduction to the Windows Installer
Introduction to the Windows Installer
MSI Introduction to the Windows Installer Starting with the release of Office 2000 in early 1999, the new Windows Installer is Microsoft’s preferred way of delivering software to end users. But why should you care? There are several reasons why you should investigate this new technology:
• Using the Windows Installer is a requirement for any application that wants to conform with the new Windows 2000 logo guidelines.
• The Windows Installer makes it less likely that your application will break existing applications by accident. This translates directly into cost savings in troubleshooting and support. • You can speed up your applications, make the user’s experience better, and offer increased flexibility by making full use of the Windows Installer.
Issues with Older Setup Software
Why did Microsoft decide that this was a good time to invest resources in a new way of installing applications? Because existing software installation solutions have grown complex and unreliable. If Windows applications can’t be installed and uninstalled without problems, this ultimately reflects poorly on the operating system itself. Let’s take a look at some of the problems with software installation on Windows that existed before the Windows Installer.
DLL Version Conflicts
The first problem with existing setups is so prevalent that it’s gotten its own informal term over the years: “DLL Hell.” This refers to the tendency of installation programs to do the wrong things with Windows libraries (DLL files). Sometimes older versions are installed atop newer versions, breaking programs that depend on the newer versions. Sometimes newer versions replace older versions even though they’re not 100 percent compatible. Sometimes shared libraries are removed even when other applications are using them. Overall, while shared libraries represent an important part of the functionality of Windows, maintaining them has required far too much time, trouble, and effort.
Too Much Software Installed
Over the years, applications have grown from the 27KB of the original VisiCalc (the first spreadsheet program) to roughly 1GB of Microsoft Office 2000 Premium with all the bells and whistles installed. Although hard drives have continued to grow and to get cheaper per megabyte, today’s applications are huge by any measure. Most people, although they install complete applications, never use most of the functionality of those applications. And even when setup programs provide custom installations that let users pick and choose what to install, the choices often don’t make a lot of sense to the non developer. The net result is that applications routinely install much more software than the user will actually ever use.
Lack of Administrative Control
If you’re installing software for yourself, you can keep track of what you’ve put on your computer and where you put it. But what if you’re the administrator for a large network? It’s a nightmare trying to maintain a thousand installations of, say, Microsoft Office if every user can choose their own set of features and their own location for the software. Network administrators need the ability to control the installations done by end users. Although some tools, such as Microsoft Systems Management Server, exist to help with this task, there’s no standard to allow them to work easily with all installation programs.
Need for Administrative Rights
It’s becoming increasingly popular for large organizations to “lock down” user desktops to a greater or lesser extent. The “fiddle factor,” the natural tendency of users to change settings on their computers, to move things around, and to customize their desktops, is reputed to waste significant resources in large organizations. So administrators are inclined to provide a standard environment that the user can’t change, often by using Windows NT Workstation as the operating system and using security to restrict what the user can do. This leads to problems when installing software, though. Many software packages need to be installed under an Administrator account in order to function properly. If you’ve locked down your users’ desktops, this means that they can’t install their own software.
Varying Setup Routines
Windows now includes four major platforms (Windows 95, Windows 98, Windows NT 4.0, and Windows 2000) with over a dozen minor variations. In order to work everywhere, setup programs must take into account the differences between these platforms. Some Registry keys have to be written to different locations on different platforms, some folders are in different places, and even some API calls function differently on one platform or another. This leads to larger setup programs with more complex logic, which inevitably means that there are more bugs in the setup programs and those bugs are harder to fix. It also leads to a substantial testing burden, especially for smaller software developers. How many developers can afford to set up a couple of dozen computers just to test their installation program?
Uninstalls Break Other Software
Some applications today don’t treat shared resources properly. A shared resource might be a library (.dll file) in the Windows folder, a Registry key that’s used by multiple programs, or an environment setting. Some software removes shared resources when uninstalled, even when those resources should remain. The result is that uninstalling one application can break another application.
Software Isn’t Resilient
Things go wrong with software. The user accidentally deletes a critical file, the Registry gets corrupted when the user’s hard drive fills, or the user customizes a setting and can’t remember how to return it to its default value. Most of today’s software can’t deal with these problems at all. How many times have you been told by technical support that the answer is to completely uninstall and reinstall the application? Even one time is too many. Good software should be able to repair itself when things go wrong.
Failed Installations Make a Mess
If an application fails to install completely, it can leave the user’s computer in an inconsistent state. Perhaps only one of a pair of matched libraries gets updated, or a Registry key gets deleted without a new key being created. Whatever the actual mechanics, it’s very difficult to recover from failed installations. In the worst case, not just the new software, but also the existing software, fails to work after such a disaster.
Solutions from the Windows Installer
The Windows Installer acts as a single point of contact for all software that needs to be installed on your computer. Instead of each application making its own calls directly to the operating system to copy files, write Registry keys, and perform other setup tasks, applications call services from the Windows Installer.
With the Windows Installer, application developers are free to do what they do best (describing the changes that their application should make to the user’s computer), while leaving Microsoft free to implement the actual changes. This allows the Windows Installer to perform several critical functions:
• Versioning and sharing rules for libraries and other components are consistently followed.
• Features can be “advertised” so that they appear to be installed without taking the time to actually install them.
• Administrators can control exactly what gets installed on computers in an enterprise.
• Software can be installed even when the user can’t modify the desktop or Registry directly.
• Setup programs use one uniform API on all platforms.
• All changes during setup can be “rolled back” for a clean uninstall.
• Software can be repaired or reinstalled by calling the Windows Installer.
• Failed installations make no changes to the user’s computer.
Windows Installer
Windows Installer is a system service for installing and managing applications. It provides a standard method for developing, customizing, installing, and updating applications.
Windows Installer provides the following basic functions:
• Transactional operations. All installation operations are transactional. For each operation that Windows Installer performs, it generates an equivalent undo operation that would undo the change made to the system. If a failure occurs during the middle of an installation, Windows Installer can roll back the machine to its original state.
• Self-healing. Windows Installer supports “self-healing” abilities for applications. Applications can detect common installation problems at launch, like missing files or registry keys, and automatically repair themselves.
• Installation on demand. Windows Installer supports on-demand installations of application features. For example, the spelling checker in Microsoft Office Word may not be installed by default, but a user can trigger an on-demand installation of this feature.
• Installation in locked-down environments. In fully locked-down environments, users don’t generally have permission or the ability to install applications. In most cases, they don’t have write-access to the Program Files folder of their computers or to the HKEY_LOCAL_MACHINE registry location. If an administrator approves an installation package by means of Group Policy, for instance, Windows Installer can perform an installation on the user’s behalf.
• State management. Windows Installer provides a set of standard Win32® application programming interfaces (APIs) and automation interfaces for applications and administrators to use for querying the installation state on the machine. The APIs allow querying of the current state, verification of the existing state, repair of a corrupted state, and transition from one state to another.
Products and Packages
At the very top level, the Windows Installer distinguishes between products, packages, and databases. In general, a product comes in a package, and a package contains a database. In the Windows Installer world, you need to start thinking of “product,” “package,” and “database” as specific technical terms. For example, if you happen to have a copy of Microsoft Office 2000 handy, the terms would apply this way:
The product is the particular piece of software. In this case, that might be the U.S. English version of Microsoft Office 2000 Professional.
The package is everything that the Installer needs to do its job of installing the software. In this case, that would be the contents of the CD-ROMs inside the Office box.
The database is a particular file that contains instructions for the Installer. For Office 2000, that’s a file named DATA1.MSI.
In the next few pages, I’ll look at these three ideas in a bit more detail. You’ll see how all three pieces fit together to help the Installer in its job of setting up an application on the user’s computer.
Products
A product is anything that the Windows Installer can install. If you’ve worked in the software industry for a while, you might have run across the concept of a stock keeping unit (SKU). A SKU (generally pronounced “skew”) is a particular box that might be on the shelf of your local computer store—for example, Microsoft Office 2000 Professional in English. One way to think of a Windows Installer product is as a unique SKU, as something that can be packaged in a box and put on the shelf. Products are identified to the Windows Installer by unique product codes. A product code (like many other identifiers in the Windows Installer world) is a Globally Unique Identifier, or GUID. I’ll show you how to generate GUIDs in a few pages. If you ship multiple distinct versions of your product, you need to assign different product codes to each version. So, again taking an example from the Microsoft world, the English and Japanese versions of Microsoft Office 2000 Professional have different product codes. You’re not required to change the product code every time the product changes, though. If relatively minor changes are made to the product, you can keep the same product code. What’s a minor change? Anything that you’d identify by only changing the minor version number of a product is probably minor enough that you can keep the same product code. When in doubt, update the product code when you change a product. It can’t hurt, and there are so many possible GUIDs that we won’t run out even if you use up a few unnecessarily.
Packages
A package is a set of files that contains instructions for the Windows Installer. The file in a package that the Installer can read is distinguished by the file extension .msi. Like products, packages are identified by unique package codes. Package codes are also GUIDs. However, any change to a package, no matter how minor, requires generating a new package code. If you fail to follow this rule, the Windows Installer might use an old cached copy of your package instead of the new changed one, and you’ll be left wondering why upgraded components weren’t installed. A single Installer package can contain the information for multiple products. For example, if you create an Installer package that installs either the English or the French version of your product, depending on the choices the user makes on the user interface of the installation program, you’d have a single package code but two product codes. .
MSI (Package File)
This is the file that contains the instructions for MSIEXEC.EXE to install the application. The MSI file is a Database file format. The .msi file in a package is a COM structured storage file. That is, it can contain multiple streams of information. These streams can include the following:
- An Installer database
- A summary information stream
- .cab files containing components to install
- Source files for the installation
- Transforms
If you like, you can put everything needed for an installation in the .msi file, and have a package consisting of a single file. On the other extreme, the .msi file can contain only the Installer database and the summary information stream, with the other package components stored in external files. Sometimes the .msi file itself is referred to as an Installer package. While technically the package also includes any external files that go with the .msi file, this usually doesn’t cause any confusion.
Operating systems and Windows Installer Versions
| Release | Version | Description |
| Windows Installer 1.0 | 1.00.5104.0 | Released with Office 2000 and as a redistributable. |
| Windows Installer 1.1 | 1.10.1029.0 | Released with Windows 2000. |
| 1.10.1029.1 | Released as a redistributable. | |
| Windows Installer 1.11 | 1.11.1314.0 | Released with Windows 2000 Server SP1. |
| Windows Installer 1.11 | 1.11.2405.0 | Released with Windows 2000 Server SP2. |
| Windows Installer 1.2 | 1.20.1410.0 | Released with Windows Me. |
| Windows Installer 1.2 | 1.20.1827.1 | Released as a redistributable. |
| Windows Installer 2.0 | 2.0.2600.0 | Released with Windows XP. |
| Windows Installer 2.0 | 2.0.2600.1 | Released with Windows 2000 Server SP3. |
| Windows Installer 2.0 | 2.0.2600.1183 | Released with Windows 2000 Server SP4. |
| Windows Installer 2.0 | 2.0.2600.2 | Released as a redistributable. |
| Windows Installer 2.0 | 2.0.2600.1106 | Released with Windows XP SP1. |
| Windows Installer 2.0 | 2.0.3790.0 | Released with Windows Server 2003. |
| Windows Installer 3.0 | 3.0.3790.2180 | Released with Windows XP SP2. Released as a redistributable. |
| Windows Installer 3.1 | 3.1.4000.1823 | Released as a redistributable. |
| Windows Installer 3.1 | 3.1.4000.1830 | Released with Windows Server 2003 SP1 and Windows XP Professional x64 Edition. |
| Windows Installer 3.1 | 3.1.4000.2435 | Released with a fix to address the issue discussed in KB898628. |
| Windows Installer 4.0 | 4.0.x.x | Available in Windows Vista. |
Windows Installer is included with the Microsoft Windows 2000 and Microsoft Windows Millennium Edition (Me) operating systems, and is provided in a service pack for the Microsoft Windows 95, Microsoft Windows 98, Windows 98 Second Edition, and Microsoft Windows NT 4.0 operating systems.
One must install the Windows Installer on Windows 95, Windows 98, Windows 98 Second Edition, or Windows NT 4.0 before you run an .msi file to install a product. Version 1.1 of the Windows Installer is included in Windows 2000, and version 1.2 is included in Windows Me.
Instmsiw.exe is the redistributable package for installing or upgrading this version of Microsoft Windows Installer on Windows NT 4.0 with Service Pack 6 and Windows 2000
.exe is the redistributable package for installing or upgrading Windows Installer on Windows 95; Windows 98
What are Windows Installer and Logo Requirements?
What is the use of windows installer logo?
The Certified for Microsoft® Windows® Logo identifies products that have been verified through independent testing to comply with the Application Specification for Windows®. This specification was developed by Microsoft in cooperation with customers and other developers to provide a road map for building reliable and manageable applications.
Software vendors who comply with the specification qualify for the Certified for Microsoft Windows logo and then license the logo for use on their product packaging, advertising, collateral, and other marketing materials.
The following table provides links to information in Windows Installer documentation pertinent for some of the certification requirements. Note that the not every requirement for certification discussed in the Application Specification is dependent upon Windows Installer.
| Requirement for Certification | See the following sections |
| 1.1 Application should perform primary functionality and maintain stability. | If one provides an installation package, then application can use the installer service available on all 32-bit Windows platforms. Using the Installer can improve the functionality and stability of the application. |
| 1.3 Application should support Long File Names and UNC paths | The installer supports installing to and from both UNC and drive network and always uses the long file names provided in the package except if the SHORTFILENAMES Property is set or if the target volume does not support long file names. |
| 1.5 The application should not read from or write to Win.ini, System.ini, Autoexec.bat or Config.sys on any Windows operating system based on Windows NT technology. | The installation program should add entries to the registry not to the Win.ini, System.ini, Autoexec.bat or Config.sys on any Windows operating system based on Windows NT technology. Windows Installer supports informational keys in the registry. When the application uses the installer, these registry keys become available as installer properties. One can author the package for the application such that it is easy to check and set the values of these keys. If the application uses information that one do not want to put in the registry, create a private initialization file and place it in the directory with the application’s executable files. One can easily manage the installation of a private .ini file, as well as add or remove information from existing .ini files, by using Windows Installer to install the application. |
| 1.7 The application should perform Windows version checking correctly. | When one prepares an installation package for the application, he must include information about the product’s operating system version requirements. On initialization, the installer automatically sets certain properties to the version of the current operating system. The setup program can use these installer properties to provide easy version checking. |
| 2.1 The application should install using a Windows Installer package that passes validation testing. | One can check that the installation package passes validation testing by using a specific set of validation rules known as Internal Consistency Evaluators – ICEs. To qualify for certification, an installation package must not produce any errors when validated using these rules. Warnings are acceptable, but generally should be corrected. |
| 2.2 The installation package used to install the application should follow the rules for creating components. | An installer component is a part of an application that is always installed or removed as one piece. There is a set of rules to help one to decide how best to divide the application into components. If the components in the installation package are correctly defined, the installer can install and remove them safely. |
| 2.3 The application’s installation package should identify shared components. | If one provides an installation package that correctly organizes the application into components, and set msidbComponentAttributesSharedDllRefCount in the Component table, Windows Installer can track shared components using the reference count in the shared DLL registry of the component’s key file. If installer is not used, then the application must keep track of its use of shared DLLs by incrementing a usage counter for the DLL in the SharedDLLs registry key. |
| 2.4 The application should install to the Program Files folder by default. | On initialization, the installer sets a property to the full path of the Program Files folder. When one prepare the installation package one can specify that the installer install the application to this folder by default. If one also includes a UI in the package, the installer can provide users with an option to select another installation location. |
| 2.5 The application should support Add/Remove Program Files properly. | One can supply all the information that is needed by Add/Remove Programs in the Control Panel by setting the values of certain installer properties in the application’s Windows Installer package. Setting these properties automatically writes the corresponding values into the registry. |
| 2.6 The application should ensure that Windows Installer package supports advertising. | Support advertising by organizing the application for advertising and by including all the information needed for advertisement in the application’s Windows Installer package. |
| 2.7 The application’s installation package should ensure correct uninstall support. | If one uses the installer to install the application, then need not create a separate uninstaller. One can author an installation package that enables the installer to install, uninstall, and repair the application. |
| 3.1 On Windows 2000 do not attempt to replace files that are protected by Windows File Protection. | Windows Installer adheres to Windows File Protection (WFP) when installing essential system files on Windows 2000. Windows Installer never attempts to install or replace a protected file. If a protected system file is modified by an unattended installation of an application, WFP restores the file to the verified file version. |
| 3.2 Authors writing new redistributable components must use side-by-side sharing techniques so their components can be installed into the application directory. | Authors of Windows Installer packages can specify that the installer copy the shared files (commonly shared DLLs) of an application into the application’s folder rather than to a shared location. These private sets of files (DLLs) are then used only by the application. |
| 3.3 For Windows 2000 and Windows 98 Second Edition, any side-by-side DLLs that the application depends on must be installed into the application directory: | Authors of Windows Installer packages can specify that the installer copy the shared files (commonly shared DLLs) of an application into the application’s folder rather than to a shared location. This private set of files (DLLs) is then used only by the application. |
| 4.3 The application should degrade gracefully if access is denied. | The objective of this requirement is to ensure that if the user is denied access to resources, the application fails in a manner that maintains a secure environment. Windows Installer handles privileges only during installation. The application must handle privileges at run time. The installer can set certain properties on initialization to the user’s privilege level or to a level specified by System Policy. One can then author the Windows Installer package such that the installer checks the user’s access privileges before installation begins. One can author the installation package so that the installer determines whether there is sufficient disk space. If one author a user interface (UI) for the application’s package, it can display options to users that run out of disk space. If the installation is unsuccessful, the installer can switch into its rollback mode and automatically restore the original state of the computer. |
| 4.5 The application should adhere to system-level Group Policy settings. | Windows Installer can follow policies pertaining to installation. |
| 7.1 Applications should continue to function after upgrade to Microsoft Windows 2000 Professional without reinstall | The installer has a component attribute that can facilitate preparation of the application for migration to Windows 2000. |
Windows Installer Version history
About Windows Installer 3.1
New Features of Windows Installer 3.1:
- New minor UpdateTargetRTMProperty property: Patch files can now target both the original release baseline and the latest service-pack-level baseline that is on the system.
- New MsiSetExternalUIRecord API: Packages that use an external user interface can now receive messages as records instead of receiving the messages as strings.
- New x64 and Msix64 properties: Packages can now use the x64 and Msix64 properties to indicate x64 processor-based operating system support.
- New MsiNotifySidChange API: One can use this API to upgrade the Windows Installer configuration if the security identifier (SID) of a user changes.
Flyweight patching is now an opt-in behavior: Windows Installer 3.0 introduced new “flyweight patching” functionality. By default, this functionality was enabled for all patches. Windows Installer 3.1 now disables this functionality unless one specifically enables the functionality by setting the OptimizedInstallMode property in the MsiPatchMetaData table.
Issues that are addressed in Windows Installer 3.1
- Windows Installer now logs null characters (“[~]”) correctly when the characters are used in a registry value marker or in a service dependency.
- The MsiGetFileHash function now works correctly for very large unversioned files. These files may be about 2 GB.
- The MediaSrcProp property of a patch is now set to the original launched-from location when the patch is installed. The MediaSrcProp property is set to the cached patch location for subsequent transactions.
- Progress bar now works correctly even if the package installs more than 2GB of files.
- Patching of isolated components now works.
- Target information for a custom action is no longer logged when the custom action fails if the custom action is marked to hide the target.
- Error 1642 (ERROR_PATCH_TARGET_NOT_FOUND) is returned even if only one Windows Installer 2.0-style inapplicable patch is being applied.
- Applying a full-file Windows Installer 2.0-style patch that contains companion files no longer requires access to the source media.
- Windows Installer 3.1 now correctly handles the scenario where a minor update package is installed when an obsolete or superseded patch also exists.
- Windows Installer 3.1 now supports application of patches for packages that have large numbers of files. (Sequence column of File table includes values larger than 32767.)
- Windows Installer 3.1 now sends INSTALLSTART_ACTIONSTART messages for all actions.
- In Windows Installer 3.0 and earlier versions, if one applied several major upgrade patches, subsequent installations occasionally failed. This issue is now fixed.
- The patch sequencer no longer incorrectly rejects a valid patch during administrative image patching.
- Windows Installer 3.1 no longer skips script custom actions that are marked as asynchronous.
About Windows Installer v3.0
New Features of Windows Installer 3.0
Patch sequencing
with patch sequencing, a set of new or existing patches are deployed in the correct logical order, regardless of the chronological order that the patches were received in on the computer.
Removable patches
One can now remove patches that are installed with Windows Installer 3.0 if they are marked as removable in the patch package. Patch removal enables the patched program to be returned to the state that the program was in before the patch was applied.
More efficient patching
Several improvements have been made to patching in this release. These improvements include the following:
- One can double-click a patch file to apply it.
- Patches are smaller and more reliable.
- Delta compression patches no longer require the source media.
- One can install multiple patches in one transaction.
- One can install patches that are targeted to different products in a single transaction.
- Non-administrator patches and patch elevation
- User with Limited accounts can now apply patches that have been marked as trusted by the system administrator.
Source list APIs and inventory management APIs
with new source list APIs, system administrators can easily examine and change the list of source locations that are registered with the Windows Installer. Windows Installer 3.0 also supports rich product, feature, component, and patch inventory queries through new inventory management APIs. Users with privileged accounts can use these APIs to enumerate across all user and installation contexts.
Standard command-line options
To ease program deployment, the Windows Installer supports standard, easy-to-understand command-line options that control display and restart behavior, and the installation, removal, logging, and application of updates. Windows Installer 2.0 command-line options will continue to be supported and can be used with new command-line options. The following new command-line options are supported:
- /help
- /quiet
- /passive
- /norestart
- /forcerestart
- /promptrestart
- /uninstall
- /log
- /package
- /update
Windows Installer 3.0 also supports the msiexec /? Option One can use this option to display all the command-line parameters that are available in Windows Installer 3.0.
Better assembly servicing
Support for binary delta patching and new assembly authoring and servicing guidelines improve assembly servicing.
Improved interface for Add or Remove Programs in the Windows XP Control Panel
The Add or Remove Programs feature in Control Panel now lets users view and interact with the installed updates to programs. With Windows XP SP2, users can select a single check box to view program updates and their relationship to a program. Updates are now grouped with a relevant program and include an installation date.
Issues that are addressed in Windows Installer 3.0
- Windows Installer did not use a correct token after the LogonUser function had been called.
- Failure occurred when a custom action called an API that queried for a string that was larger than 256 characters.
- “The Windows Installer Service could not be accessed” error was displayed when MSIServer class registration was missing on the server”.
- The MsiOpenProduct function failed when the product’s registration was corrupted.
- Setup failed if the browsing window is closed by double-clicking the program icon after one opens the program icon menu.
- The ServiceInstall table did not install services correctly if the path contained a space.
- The MsiGetComponentPath function sometimes failed unexpectedly.
- When one cancels program installation during the installer engine initialization, the action was ignored and returned an unexpected error. When tried to remove a program, an incorrect program name was displayed as the running program.
- An MsiAssemblyName table that was not written correctly could prevent the removal of global assemblies on the computer.
- Windows Installer rolled back an installation when commit custom actions failed, but ultimately reported that the installation was a success instead of a failure.
- The Windows Installer did not let the external user interface filter for files in use messages.
- Windows Installer 3.0 now adds the INSTALLLOGMODE_FILESINUSE = (1 << (INSTALLMESSAGE_FILESINUSE >> 24)) parameter to public headers.
- The DependantService registry value was truncated.
- Windows Installer provided insufficient logging information when the BindImage API failed.
- Windows Installer did not declare the INSTALLMODE_NODETECTION_ANY parameter in the public header for the MsiProvideAssembly function.
- COM activation failed if a component was run from a source and if source validation failed.
- An actionable pointer was displayed as an hourglass and did not change.
- A service did not shut down after it failed.
- If an administrator or local system was denied access to a file, the Windows Installer could not delete the file.
- The ServiceInstall table did not respect the msidbServiceInstallErrorControlVital bit if modal dialogs were disabled by the /qb- or /qn switches.
- The OpenPackage method ignored the Safe Session flag.
- The msiUILevelSourceResOnly installation table definition was missing from the typelib definition for the Windows Installer Automation interface.
- Versioned files could not be installed if companion files were specified with run-from-source components.
- The error dialog box that is used by the Customer Information dialog box used the wrong pointer.
- When one pressed the spacebar or the ENTER key, it enables a hidden Cancel button.
- Windows Installer did not let non-administrators generate advertisement scripts when DisableMSI=1.
- Security errors displayed only the OK button when one was prompted to click Retry or Cancel.
- Environment variables were lost when one removed programs.
- The Windows Installer API that provides component paths returned incorrect paths if the component was installed with a run-from-source component and if the media disk ID for the component was more than 99.
- Windows Installer could not remove files with read-only permissions for the administrator and system accounts.
- The FilesInUse dialog box may have displayed incorrect window titles if the window titles contained [propertyname] references.
About Microsoft Windows Installer 2.0
Microsoft has released version 2.0 of the Windows Installer runtime files and the Windows Installer SDK. Besides support for Windows XP and 64 bit applications, this version includes bug fixes and introduces useful operating system properties, e.g. to detect whether setup is running on NT Workstation or Server, or an XP Professional or Home Edition. It also significantly simplifies updates by eliminating the need for complicated ADDLOCAL and REINSTALL constructs, and no longer requires a reboot after installing the runtime files. The good news is that one can benefit from these improvements in the existing projects. Some modifications in the authoring tool may be required to install the new runtime files. As a result of the improvements and fixes in MSI 2.0 one may find that the setups and patches behave differently than they used to or even fail. Even if one don’t include MSI 2.0 in own setup, the new version may already be present on the target machine, so one should at least include MSI 2.0 in the testing scenario.
Version 2.0 of Windows Installer provides increased reliability and a number of feature enhancements. Backwards compatibility was paramount in the design of version 2.0 so applications authored correctly for version 1.1 of Windows Installer would continue to function properly when installed and maintained with version 2.0.
New and Improved Features
Windows Installer version 2.0 includes many new and improved features over previous versions. These changes improve Windows Installers ability to install and manage software on the Windows platform. These new and improved features include:
Installation and Management of Assemblies
The Windows Installer is integrated with SxS (Fusion) and Common Language Runtime (CLR) assemblies.
Configurable Merge Modules
Merge modules (.msm files) can now be authored to contain attributes configurable by the consumer of the merge module.
Increased Security
The Windows Installer architecture is modified to increase security, such as sandboxing of all custom actions and hiding sensitive information in log files.
Isolation of Program Configuration Information
A program’s per-user configuration information is isolated, enabling program installations to be performed on a per-user basis.
Application Compatibility Infrastructure
The Windows Installer includes an application compatibility infrastructure for handling application compatibility issues that occur.
Digital Signature Support
Digital signature support is included for Windows Installer-related files, such as packages (MSI), patches (MSP), transforms (MST), and external cabinet files (CAB). Additionally, Windows Installer can verify files packaged in a cabinet (*.cab) file external to the applications *.msi.
Improved Patching and Updates
Numerous enhancements improve the experience of creating and applying patches and updates, such as:
- Simplified patch authoring through automated patch conflict resolution.
- Eliminated unnecessary source resolution attempts. For example, in most cases one are no longer required to insert the original application CD to install a patch.
- The installation of updates is more efficient because unnecessary un-versioned file copy operations are removed.
Support for Transforms and Patches from URL Sources
Support for the installation of transforms and patches from a source referenced by a universal resource locator (URL) are added. Earlier versions contained only support for packages (MSI) from a URL source.
Enhancement of Operating System Features
Integration with System Restore and Software Restriction Policies (Windows XP features).
Improved Terminal Server Support
The Windows Installer is a native 64 bit service for the installation of 64 bit applications on 64 bit Windows.
Enhanced Logging
Event logging has been greatly improved in order to aid the troubleshooting of installation issues.
Application Compatibility
During and since the development of Windows Installer 2.0, Microsoft has tested thousands of applications for compatibility. Almost all applications designed for Windows Installer 1.1 work properly on version 2.0. In the rare cases in which compatibility issues have been discovered, the common cause was an application authored in unsupported ways for Windows Installer 1.1.