How Windows 95 Handled Run Registry Keys

Windows 95 fundamentally changed how personal computers launched background software by shifting automated startup tasks from legacy configuration files into the centralized Windows Registry. This article details the mechanics of how Windows 95 read, ordered, and executed the startup applications defined within the Run and RunOnce registry branches, detailing the sequential handoff from core boot components to the newly introduced Windows Explorer shell.

Prior to Windows 95, automated program execution relied on DOS-era batch scripts like AUTOEXEC.BAT and configuration lines—specifically the load= and run= directives—inside WIN.INI. Windows 95 preserved these legacy methods for backwards compatibility, but it introduced a structured mechanism governed by SYSTEM.DAT and USER.DAT, the files comprising the Windows Registry.

Windows 95 managed startup applications by checking specific keys located under both machine-wide (HKEY_LOCAL_MACHINE) and user-specific (HKEY_CURRENT_USER) paths:

1. HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServicesOnce
2. HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServices
3. HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce
4. HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run
5. HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
6. HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce

The execution sequence was strictly chronological and tied to the user authentication state.

During the initial boot phase, before the logon dialog box appeared, the operating system processed RunServicesOnce followed by RunServices. These keys were intended for essential background processes, such as network components and driver utilities, which needed to run without requiring a logged-in user. RunServicesOnce values were executed sequentially and immediately removed from the registry before launching to ensure they ran only a single time.

Once the user authenticated (or the desktop loaded directly if networking was disabled), the system shell, EXPLORER.EXE, took control of user-level execution. Explorer parsed the remaining keys in a defined order:

First, Explorer read HKEY_LOCAL_MACHINE\...\RunOnce. Like its service counterpart, the operating system removed each entry from the registry prior to execution. This preemptive deletion protected the system from infinite reboot loops if a setup routine or installer crashed during execution. Windows 95 typically executed RunOnce items synchronously, pausing subsequent startup items until each process exited, unless the value name began with an asterisk (*), which altered its error-handling and execution behavior.

Second, Explorer launched the values listed in HKEY_LOCAL_MACHINE\...\Run. These programs were initiated asynchronously, allowing Windows to spawn multiple processes in parallel to speed up the loading of system tray utilities, hardware monitoring tools, and antivirus software.

Third, Explorer evaluated the current user's profile under HKEY_CURRENT_USER\...\Run. These programs also launched asynchronously, tailored to the specific user profile active on the system.

Finally, Explorer processed HKEY_CURRENT_USER\...\RunOnce, followed by the shortcuts placed in the user's Start Menu\Programs\Startup folder.

Each entry inside the Run keys consisted of a standard string value (REG_SZ), where the value name identified the application and the value data stored the fully qualified file path, command-line flags, and optional arguments. If a program's path contained spaces, it required quotation marks; otherwise, Windows 95 could misinterpret the arguments and fail to launch the process silently.

Through this phased architecture, Windows 95 decoupled background system requirements from interactive user-space software, creating a standardized autostart framework that formed the foundation for all subsequent versions of the Windows NT family.