How Windows 95 Executed DOS Commands in the Run Dialog

When a user typed a command into the Windows 95 Start Menu "Run" dialog box, the operating system resolved the command string, determined its execution environment, and launched it through the appropriate subsystem. While 32-bit and 16-bit Windows executables were dispatched natively via standard Win32 APIs, MS-DOS commands and programs were delegated to the command interpreter (COMMAND.COM) and executed inside an isolated Virtual 8086 mode environment managed by the Virtual Machine Manager (VMM32) and the WinOldApp subsystem.

Command Parsing and File Resolution

The Run dialog box, implemented within SHELL32.DLL, evaluated the user's input string. It first searched for an executable file matching the specified name across the current working directory, the system directories (C:\WINDOWS, C:\WINDOWS\SYSTEM), and any directories listed in the PATH environment variable.

The shell checked for executable extensions in a specific order: .pif, .com, .exe, and .bat.

  • External Commands and Programs: If the user entered an executable MS-DOS utility (such as EDIT.COM or FDISK.EXE) or a batch script (.BAT), Windows detected the DOS binary header or script format directly.
  • Internal MS-DOS Commands: Commands built directly into the MS-DOS interpreter (such as DIR, COPY, or DEL) did not exist as standalone .exe or .com files. To run these directly from the Run dialog, the command had to be passed through the command interpreter explicitly or invoked using the COMSPEC environment variable (for example, command /c dir).

PIF Association and Environment Setup

Before launching an MS-DOS program, Windows 95 reviewed its execution properties. These settings were stored in Program Information Files (.PIF).

If a dedicated .PIF file matching the program's filename existed, Windows applied its settings. If no matching file was found, Windows 95 generated an environment based on _DEFAULT.PIF. These properties governed:

  • Conventional, Extended (XMS), and Expanded (EMS) memory allocation.
  • Display modes (full-screen vs. windowed console).
  • Multitasking behavior (whether the DOS program paused when placed in the background).
  • Whether the command window closed automatically upon task completion ("Close on exit").

Spawning the Virtual DOS Machine (VDM)

Windows 95 did not drop out of protected mode to execute MS-DOS commands; instead, it used hardware virtualization:

  1. Virtual 8086 Mode: The Windows 95 kernel (VMM32.VXD) created a new Virtual Machine (VM) running the Intel processor in Virtual 8086 (V86) mode. This provided the application with the illusion of a dedicated real-mode 8086 environment with 1 MB of address space.
  2. WinOldApp Subsystem: The protected-mode bridge, handled by WINOA386.MOD (WinOldApp), coordinated communication between the 32-bit Windows graphical user interface and the MS-DOS environment. WinOldApp handled window framing, mouse integration, clipboard copy-pasting, and display rendering for text-mode and graphical DOS programs.
  3. Shell Invocation: Inside the newly created VM, COMMAND.COM loaded. If the Run dialog passed a single execution parameter (such as running a batch file or a /c directive), COMMAND.COM executed the instructions, directed the output to the active console buffer, and signaled WinOldApp upon termination.

Execution and Termination

Once the command finished, the behavior depended on the active PIF configuration. If "Close on exit" was enabled, WinOldApp destroyed the Virtual DOS Machine and returned focus to the Windows desktop. If the option was disabled, the window remained open with the word "Finished" appended to the title bar, allowing the user to view the command line output before closing the window manually.