How Windows 95 Replaced Locked Files on Reboot

Windows 95 resolved the challenge of updating active system files by deferring replacements until the system restarted, using a dedicated initialization program and a temporary configuration file. When installers encountered dynamic-link libraries (DLLs), drivers, or core system components that were locked in memory by the operating system, they staged the new files on the hard drive and queued replacement commands in a file named WININIT.INI. During the subsequent boot sequence, Windows 95 executed WININIT.EXE to overwrite the locked files before the graphical user interface and kernel processes could load and lock them again.

The Problem of In-Use System Files

In Windows 95, running executables, virtual device drivers (.VxD), and shared dynamic-link libraries (.DLL) were locked by the operating system to prevent file corruption. If an installer or operating system patch needed to update one of these components, standard file-copy APIs would fail with access-denied or sharing-violation errors. Because users could not easily terminate core dependencies while Windows was active, updates had to occur in an environment where these files were completely idle.

The WININIT.INI Staging File

To queue operations for the next reboot, installers wrote instructions to a file named WININIT.INI, located inside the Windows directory (typically C:\WINDOWS). This initialization file used standard INI file formatting and relied primarily on the [Rename] section to instruct the system on how to handle queued files.

The syntax in the [Rename] section followed a destination=source format:

[Rename]
C:\WINDOWS\SYSTEM\COMMCTRL.DLL=C:\WINDOWS\SYSTEM\COMMCTRL.TMP
NUL=C:\WINDOWS\TEMP\OLDDRIVER.DRV

In this syntax:

  • The left side of the equals sign specified the final destination path of the file being updated.
  • The right side specified the location of the newly staged file, which usually carried a temporary file extension.
  • To delete an obsolete or leftover file, installers used NUL as the destination, instructing the system to remove the target file entirely.

If multiple installers ran during a single session, each installer was responsible for appending its instructions to the existing WININIT.INI without overwriting commands queued by previous installers.

The Execution of WININIT.EXE

The actual replacement took place early in the Windows 95 boot sequence. Before starting KRNL386.EXE, USER.EXE, GDI.EXE, or the shell (EXPLORER.EXE), the system checked for the existence of WININIT.INI.

If the file was present, the boot loader executed WININIT.EXE. Because WININIT.EXE ran prior to the loading of the protected-mode graphical subsystem and 32-bit system services, virtually no system libraries were locked in memory.

WININIT.EXE processed the [Rename] section line by line:

  1. It moved or copied the newly staged file over the existing target file, replacing the older version.
  2. It handled any deletion commands directed to NUL.
  3. If a target file had hidden, system, or read-only attributes, WININIT.EXE cleared those attributes to complete the overwrite, restoring appropriate attributes afterward.

Cleanup and Finalization

Once all rename and delete operations finished, WININIT.EXE automatically deleted WININIT.INI (or renamed it to a backup file such as WININIT.BAK if errors occurred). This ensured the update operations were not accidentally repeated on subsequent reboots. Once WININIT.EXE completed its task, Windows 95 continued its normal boot process, launching the operating system with the updated system files now fully in place.