Windows 98 Windows Installer MSI Runtime Updates

When Microsoft released Windows 98, the operating system relied primarily on legacy setup executables and INF scripts rather than a unified installation framework. With the introduction of the Windows Installer service (.msi) alongside Office 2000 and Windows 2000, Microsoft had to adapt Windows 98 to support this new standard. This article examines how Windows 98 deployed redistributable runtime packages, managed system file dependencies, and handled locked files to enable third-party .msi installations on the Windows 9x platform.

The Need for the Windows Installer Redistributable

Windows 98 shipped prior to the finalization of the Windows Installer technology. Consequently, out of the box, the operating system could not parse .msi databases or execute the msiexec.exe installation engine. To bridge this gap, Microsoft created a dedicated redistributable package called InstMsiA.exe. The "A" designated the ANSI version, tailored specifically for the non-Unicode architecture of the Windows 9x kernel, distinguishing it from the Unicode package (InstMsiW.exe) used by Windows NT and 2000.

Third-party software vendors typically distributed their applications with a bootstrapping executable (such as setup.exe). When launched, the bootstrapper checked the registry to see if the Windows Installer engine was present and met the minimum required version. If missing or outdated, the bootstrapper silently installed InstMsiA.exe before passing the target .msi package to the newly registered installer service.

System File Updating and Core Dependencies

Installing the Windows Installer runtime onto Windows 98 was often complex because the engine itself relied on updated core subsystem components. The runtime package frequently needed to update:

  • OLE automation and COM binaries (such as oleaut32.dll and ole32.dll)
  • The Microsoft C Runtime library (msvcrt.dll)
  • Common Controls libraries (comctl32.dll)

Because Windows 98 lacked the native Windows File Protection system found in Windows 2000, updating these critical shared libraries carried the risk of "DLL Hell." The Windows Installer runtime addressed this by taking over shared file reference counts in the registry and utilizing standard version-checking rules to prevent newer shared components from being overwritten by older versions during subsequent software setups.

Managing Locked Files and Reboot Handling

When InstMsiA.exe or an individual .msi package needed to update files that were actively in use by running system processes, Windows 98 could not rely on the modern session-based restart managers used today. Instead, the runtime engine leveraged the legacy Windows 9x mechanism: the wininit.ini file located in the Windows directory.

During an update that encountered locked files, the Windows Installer scheduled the required replacements under the [Rename] section of wininit.ini. The installation process then prompted the user to restart the machine. During the early MS-DOS boot sequence—before the Windows 98 GUI and shared system DLLs were loaded—the operating system processed wininit.ini, replaced the locked binaries, and deleted the configuration file before completing the boot cycle.

Version Evolution on Windows 98

Microsoft maintained the Windows Installer redistributable through several iterations for Windows 98:

  • Windows Installer 1.0/1.1: Introduced initial support for transaction-based installations, rollbacks, and self-repair capabilities on Windows 98.
  • Windows Installer 1.2: Improved stability, patch management, and bootstrapper integration.
  • Windows Installer 2.0: Served as the final major version released for Windows 98 and Windows 98 Second Edition. It refined rollback functionality and reduced reboot requirements where possible.

Later releases, such as Windows Installer 3.0 and newer, dropped support for the Windows 9x architecture entirely, establishing version 2.0 as the definitive runtime that enabled modern software distribution on Windows 98 throughout its extended lifecycle.