How Windows 95 Processed MS-DOS Batch Files

Windows 95 marked a major transition to a 32-bit preemptive multitasking operating system, yet it retained extensive backwards compatibility with legacy MS-DOS software. When executing batch (.BAT) files, Windows 95 did not parse the scripts using its native 32-bit graphical user interface shell; instead, it relied on its internal MS-DOS 7.0 command interpreter (COMMAND.COM) running inside a Virtual DOS Machine (VDM). This article details the underlying mechanisms Windows 95 used to detect, initiate, and execute batch scripts through this hybrid environment.

Execution Trigger and File Identification

When a user double-clicked a .BAT file in Windows Explorer, typed its name in the Run dialog, or triggered it via a 32-bit Win32 API call such as CreateProcess or ShellExecute, the system evaluated the file extension and header. Recognizing the file as an MS-DOS batch script rather than a 32-bit Portable Executable (PE) or a 16-bit New Executable (NE), the Windows 95 kernel redirected the execution request to the legacy program execution path.

Configuration via Program Information Files (PIF)

Before allocating resources for the script, Windows 95 checked for an associated Program Information File (PIF). If a file named yourscript.pif existed, the operating system loaded execution preferences from it. If not, Windows applied the system-wide default settings stored in _DEFAULT.PIF.

The PIF metadata determined critical operational parameters:

  • Display mode (windowed or full screen).
  • Memory allocation limits (conventional, expanded/EMS, and extended/XMS memory).
  • Background execution permissions.
  • Whether the window should close automatically upon script termination ("Close on exit").

Spawning the Virtual DOS Machine (VDM)

To run the script, the Windows 95 Virtual Machine Manager (VMM32.VXD) created a new Virtual 8086 (V86) mode task. Unlike Windows NT, which used a completely isolated software emulation layer (NTVDM), Windows 95 ran its MS-DOS subsystem close to the metal, virtualizing the x86 CPU hardware states using 32-bit Virtual Device Drivers (VxDs).

Each VDM represented an isolated 1-megabyte address space mimicking an IBM-compatible PC running real-mode MS-DOS. The Virtual Machine Manager allocated memory for conventional DOS space, loaded virtual device drivers to handle keyboard, display, and mouse I/O, and initialized the MS-DOS 7.0 system kernel into that virtual session.

Launching COMMAND.COM

Once the Virtual DOS Machine was initialized, Windows 95 invoked the MS-DOS command interpreter, COMMAND.COM.

The operating system invoked the interpreter with the /C parameter followed by the batch file path:

COMMAND.COM /C C:\PATH\TO\SCRIPT.BAT

The /C switch instructed COMMAND.COM to load into the virtual machine, execute the commands within the specified batch file sequentially, and exit as soon as processing completed.

Sequential Processing and Execution Flow

Inside the V86 session, COMMAND.COM parsed the batch file line-by-line using its internal processing logic:

  1. Internal Commands: Commands built directly into COMMAND.COM (such as ECHO, IF, GOTO, SET, FOR, and DIR) were executed entirely within the interpreter's resident memory without creating additional processes.
  2. External 16-bit Commands: When the batch file called an external 16-bit DOS utility (such as FORMAT.COM or XCOPY.EXE), COMMAND.COM loaded the binary into the transient program area of that same VDM and transferred execution control to it.
  3. Win32 and GUI Interoperability: If a batch file referenced a 32-bit Windows executable (such as NOTEPAD.EXE), the MS-DOS kernel recognized the modern PE header. Instead of failing due to 16-bit incompatibility, the internal DOS processor communicated back across the virtualization boundary to the 32-bit Windows kernel via an interrupt hook. Windows 95 then spawned the 32-bit process in the primary Win32 system context while the batch processor waited or continued based on how the command was invoked.

Clean-Up and Session Termination

When COMMAND.COM encountered the end of the batch file, reached an explicit EXIT instruction, or was aborted via Ctrl+C, the interpreter closed open file handles and returned an exit code.

If the associated PIF had the "Close on exit" property enabled, Windows immediately destroyed the Virtual DOS Machine and reclaimed its conventional and expanded memory pools. If the setting was disabled, the window remained visible with the prefix "Finished - " in the title bar, allowing the user to view command-line output until manually closing the window.