How Windows 98 Processed Offline Service Packs

This article examines the technical mechanisms Windows 98 used to apply system patches and updates without an active internet connection. During an era when dial-up dominated and centralized online updating was in its infancy, Microsoft relied on offline distribution channels such as physical CD-ROMs, network shares, and standalone installation packages. The process relied on self-extracting archives, Setup Information (INF) files, Cabinet (CAB) compression, and low-level boot initialization scripts to replace active operating system files safely.

Distribution and Packaging

Offline updates for Windows 98, including Service Pack 1 and individual hotfixes, were distributed primarily as monolithic self-extracting executables created with tools like Microsoft IExpress. Administrators and users acquired these packages via physical media—such as TechNet CDs or magazine cover discs—or by downloading them on a connected machine and transferring them via local area networks or removable media.

When launched, the executable decompressed its payload into a temporary directory on the local hard drive. This payload typically consisted of:

  • Cabinet (.CAB) files: Compressed archives containing the replacement system binaries, such as Dynamic Link Libraries (DLLs), system drivers (.SYS), and executable files (.EXE).
  • Setup Information (.INF) files: Plain-text configuration scripts containing installation instructions, registry modifications, version checks, and file copy directives.
  • Update Engine Executables: Small bootstrap utilities (such as UPDATE.EXE or calls to RUNDLL32.EXE) responsible for orchestrating the installation sequence.

Prerequisite Checks and INF Parsing

Once extracted, the setup engine evaluated the system environment to determine compatibility. Unlike modern modular servicing stacks, Windows 98 relied on the Setup API to parse .INF files.

The update script verified:

  • Operating System Version: Ensuring the patch matched Windows 98 First Edition or Windows 98 Second Edition (SE).
  • Language and Localization: Confirming that localized resource files matched the installed language of the operating system.
  • Component Dependencies: Checking file timestamps and version resources of existing DLLs to ensure the update did not overwrite newer files with older ones.

If prerequisites were met, the setup engine executed the specific directives declared in the INF file, primarily the [CopyFiles] and [AddReg] sections.

Handling In-Use Files via WININIT.INI

Because Windows 98 was a hybrid 16-bit/32-bit operating system without the advanced file-locking management of Windows NT, critical core components could not be overwritten while the operating system was running.

To bypass this limitation, the update process utilized the DOS-era file replacement mechanism:

  1. Staging: The installer copied the new system files to temporary names or staging locations (often inside the C:\WINDOWS\SYSTEM directory).
  2. Writing Directives: The installer wrote rename and delete instructions to a specialized text file named WININIT.INI located in the root Windows directory under the [Rename] section.
  3. Reboot: The user was prompted to restart the computer.
  4. Execution via WININIT.EXE: During the initial phase of the boot sequence—before the 32-bit graphical user interface loaded—the real-mode component WININIT.EXE executed. It parsed WININIT.INI, deleted the locked legacy files, renamed the staged files to their correct names, and then deleted WININIT.INI itself.

Registry Updates and Verification

Once the system finished rebooting, Windows 98 finalized the update by processing registry entries that had been queued for the next logon. The installer registered COM components using REGSVR32.EXE and wrote records to HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Setup\Updates.

These registry keys stored the patch identifier, the list of modified files, and uninstall configurations, enabling the operating system to track installed hotfixes and prevent conflicting patches from running in the future.