Windows Installer

Windows Installer is Microsoft’s installation, maintenance, and removal technology for Windows software, first released in 1999 and known to most people by its file extension: .msi. It is an unusual entry in a language encyclopedia because an MSI package contains no program in the conventional sense. Instead, it is a relational database — a set of typed tables describing files, registry keys, shortcuts, services, and the relationships among them — stored in a COM structured-storage file. The Windows Installer engine (msiexec.exe) reads that declarative description and computes the sequence of actions needed to bring the machine to the described state, executing them transactionally with automatic rollback on failure.

That inversion — describe the desired end state, let the engine figure out the steps — made Windows Installer one of the most widely deployed declarative systems in computing history, and it remains the backbone of enterprise Windows software distribution more than a quarter century after its debut.

History & Origins

By the mid-1990s, Windows software installation was chaos. Every vendor shipped its own hand-rolled setup program or used procedural scripting built on Microsoft’s older Setup API. Installers overwrote each other’s shared DLLs — the infamous “DLL hell” — uninstallers left debris or deleted files other applications needed, and there was no reliable way for an administrator to ask what was installed on a machine, let alone repair it.

Microsoft’s answer was developed under the codename Darwin and initially called Microsoft Installer (the origin of the .msi extension). Rather than yet another scripting language for setup authors, the Darwin team built a service with a database: the package would declare what should exist on the machine, and a single OS-resident engine would own how — including reference counting of shared components, rollback, logging, and repair.

Windows Installer 1.0 shipped in 1999 with Microsoft Office 2000 (released to manufacturing on March 29, 1999), which became the technology’s proving ground: Office used it for install-on-demand features and self-repairing shortcuts. Windows 2000 then built the engine into the operating system itself, wired it into Active Directory Group Policy for organization-wide software deployment, and Microsoft’s Certified for Windows logo program pressured application vendors to adopt MSI-based setups. Within a few years, Windows Installer had gone from novelty to the de facto standard for Windows software packaging.

Design Philosophy

Declare the state, not the steps

A traditional installer is a program: copy this file, write that key, run this DLL. An MSI package is a description: these components exist, they contain these resources, they belong to these features. The engine derives the action plan — and because it knows the full intended state, it can also derive the uninstall, the repair, and the rollback automatically. Setup authors of the era had to hand-write uninstall logic that mirrored their install logic and hope the two never drifted; Windows Installer made that entire class of bug structurally impossible for declaratively authored content.

The component model

The heart of the design is a three-level hierarchy:

• Products — the installed unit the user sees, identified by a ProductCode GUID.
• Features — user-selectable groups (“Spelling tools”, “Documentation”) forming the tree in a Custom Setup dialog.
• Components — the atomic unit of installation: a keyed set of files, registry entries, and shortcuts identified by a GUID, reference-counted across every product on the machine.

Reference-counted shared components were a direct assault on DLL hell: a shared library is only removed when the last product using it is uninstalled.

Transactions and resilience

Every installation runs as a transaction. The engine journals its work, and a failure mid-install triggers rollback that restores the prior state. The same machinery powers resiliency: Windows can detect at launch time that a keyed file of a component is missing or corrupt and silently reinstall it from the source package — the “self-healing” behavior Office 2000 famously demonstrated. Advertisement takes declarativeness to its logical end: a product’s shortcuts and file associations can be published to a machine with no bits installed at all, and the first use triggers installation on demand.

Key Features

The database as source code

An MSI package typically contains dozens of standard tables — File, Component, Feature, Registry, Shortcut, ServiceInstall, Property, and the sequence tables (InstallExecuteSequence and relatives) that order the engine’s actions. Columns are typed by a schema, rows reference other tables by foreign key, and Microsoft ships a table editor, Orca, in the Windows SDK for inspecting and editing packages directly. Because a package is a database, it can also be queried — via a SQL-like dialect through the Windows Installer API — and transformed.

Transforms, patches, and merge modules

Three companion file types round out the format:

• Transforms (.mst) — a diff between two installer databases, applied at install time. Enterprises use transforms to customize a vendor’s package (preset the license key, disable features) without touching the original MSI.
• Patches (.msp) — packaged updates that modify an installed product; Windows Installer 3.0 substantially reworked patching with better sequencing and removal support.
• Merge modules (.msm) — reusable fragments (a runtime library and its registration, say) merged into products at build time so shared code is authored once.

The escape hatch: custom actions

For work the standard actions cannot express, packages can embed custom actions — DLL calls, executables, or scripts scheduled into the installation sequence. Custom actions are the format’s pragmatic concession to reality and its best-known trouble spot: code the engine cannot reason about also cannot be safely rolled back unless the author supplies a compensating action, so installer folklore urges authors to stay declarative whenever possible.

Driving the engine

Interaction with the engine goes through msiexec.exe or the Windows Installer API:

1
2
3
4
5
6
7
8
9

# Install silently, log verbosely, set a public property
msiexec /i product.msi /qn /L*v install.log INSTALLDIR="C:\Tools\Product"

# Apply an enterprise transform at install time
msiexec /i product.msi TRANSFORMS=corporate.mst /qb

# Repair, then uninstall by product code
msiexec /fa product.msi
msiexec /x {12345678-90AB-CDEF-1234-567890ABCDEF} /qn

Authoring in XML: WiX

Raw table authoring proved so unfriendly that a whole tool industry grew around it — and inside Microsoft, Rob Mensching’s WiX toolset turned MSI authoring into a compiled language: XML source describing products, features, and components is compiled into the binary database. Released on April 5, 2004, WiX was Microsoft’s first open-source project under an OSI-approved license, and its element vocabulary is essentially the MSI schema in XML form:

1
2
3
4
5
6
7
8

<Component Id="MainExecutable" Guid="4C24B420-2C42-4A3E-8F5B-6E1A2D3C4B5A">
  <File Id="AppExe" Name="app.exe" Source="build\app.exe" KeyPath="yes">
    <Shortcut Id="StartMenuShortcut" Directory="ProgramMenuFolder"
              Name="My Application" Advertise="yes" />
  </File>
  <ServiceInstall Id="AppService" Name="AppSvc" Type="ownProcess"
                  Start="auto" ErrorControl="normal" />
</Component>

Evolution

The engine’s version history tracks Windows itself:

The striking fact is the last row: Windows Installer 5.0, released with Windows 7 in 2009, is still the current version in Windows 10 and Windows 11. The format was declared feature-complete in practice, and Microsoft’s packaging energy moved elsewhere — first to AppX for Store apps, then to MSIX, announced at Build 2018 as a unified successor whose very name acknowledges the ancestor it is meant to replace. MSIX adopts containerized, manifest-driven installation with clean uninstall guarantees — the same goals Darwin pursued in 1999, rebuilt on modern isolation technology.

Current Relevance

Reports of MSI’s death have been greatly exaggerated, and repeatedly. MSIX adoption has grown in managed environments, but the enterprise world still runs to a large degree on MSI: Group Policy deployment consumes it, Configuration Manager and Intune detect and inventory software through it, IT departments customize vendor packages with transforms, and commercial authoring tools like InstallShield and Advanced Installer still treat MSI as their flagship output. The WiX toolset remains in active open-source development, now stewarded by FireGiant, and compiling WiX source into MSI packages is a routine step in countless Windows CI pipelines.

For a technology whose engine has not seen a major version since 2009, Windows Installer is remarkably alive — less a growing language than a load-bearing one.

Why It Matters

Windows Installer is one of the clearest industrial demonstrations of the declarative idea: that describing what should be true is more robust than scripting how to make it true. From its relational tables the engine derives installation, uninstallation, repair, rollback, and inventory — capabilities that procedural installers of the 1990s each had to hand-build and routinely got wrong. Its component reference-counting was a systemic answer to DLL hell, and its transactional model brought database-style ACID thinking to the messy business of mutating a live operating system.

Its influence runs forward in a direct line. WiX turned the MSI schema into a compiled XML language and, in doing so, became the crack in the dam for open source at Microsoft. MSIX carries the declarative-manifest philosophy into the container era. And every modern package manager that promises atomic installs, clean uninstalls, and state repair is walking ground that Darwin surveyed in 1999. Few pieces of infrastructure are simultaneously so unglamorous, so complained about, and so quietly indispensable.