logo
Kurashizu Blogwhere ideas flow
  • Home
  • News
  • Blog
  • About
  • Home
  • News
  • Blog
  • About

© 2026 Kurashizu. All rights reserved.

Admin·New Post·Service Status
Powered by Cloudflare·31.10.26
← Back to news

The little-known winstart.bat batch file

Original article
devblogs.microsoft.com|68 points|13 comments|by ingve|Aug 15, 2026

Uncovering the Mysteries of winstart.bat

Microsoft

A reader named Otul Osan recently posed a question regarding the specific utility of the C:\WINDOWS\WINSTART.BAT file. Specifically, how did it differ from the more common C:\AUTOEXEC.BAT, and at what precise moment during the boot sequence was it executed?

The Windows 95 Boot Sequence

In the era of Windows 95, users had the option to implement a winstart.bat file within their Windows directory. To understand its purpose, we have to look at how the system transitioned from raw DOS to a graphical environment.

The Startup Workflow

The process follows a specific hierarchy of initialization:

  1. MS-DOS Initialization: The system boots into MS-DOS, loading the command prompt.
  2. Autoexec Execution: command.com executes autoexec.bat. This is where global Terminate and Stay Resident (TSR) programs (let's call the first one TSR1) are typically loaded.
  3. VMM Takeover: Windows begins its launch, initializing the Virtual Machine Manager (VMM).

At this stage, the system enters protected mode. The VMM creates the "System VM"—the primary virtual machine where Windows applications reside. This VM is initialized based on the state of the real-mode environment at the moment of takeover.

A Mind-Bending Realization mind blown Think about the architecture here: we boot one operating system, only to boot a second operating system around the first one. The original OS is now effectively trapped inside a virtual machine managed by the new one. It is akin to leaving your house, walking a few steps, and suddenly realizing you are actually walking through a meticulously crafted movie studio set.

The Role of winstart.bat

Before the user-mode kernel (which manages Windows apps) is launched, the VMM checks for the existence of winstart.bat. If found, it runs it inside the System VM. This allows for the installation of additional TSRs (e.g., TSR2) that exist only within that specific VM.

Visualizing the Layering

The "Ghost" in the Machine

When you are inside the Windows GUI and decide to open a DOS prompt, Windows creates a second virtual machine. This new VM is a snapshot of the system as it existed when Windows first started.

  • Result: The DOS prompt VM contains TSR1 (from autoexec.bat), but it does not contain TSR2 (from winstart.bat).

If you were to manually install a new TSR (TSR3) inside that specific DOS prompt, it would only exist in that instance, not in the System VM or other prompts.

Summary of System States

We can represent the state of the virtual machines using a simple logic:

StateSystem VM=StateDOS+TSRautoexec+TSRwinstart\text{State}_{\text{System VM}} = \text{State}_{\text{DOS}} + \text{TSR}_{\text{autoexec}} + \text{TSR}_{\text{winstart}}StateSystem VM​=StateDOS​+TSRautoexec​+TSRwinstart​ StateDOS Prompt VM=StateDOS+TSRautoexec\text{State}_{\text{DOS Prompt VM}} = \text{State}_{\text{DOS}} + \text{TSR}_{\text{autoexec}}StateDOS Prompt VM​=StateDOS​+TSRautoexec​

Why Use winstart.bat?

The primary goal of winstart.bat was to provide a way to load TSRs that were exclusive to Windows programs.

Common use cases included:

  • Memory Optimization: Installing network drivers only for Windows to save precious conventional memory for pure MS-DOS applications.
  • Compatibility: Some drivers were unable to function across multiple virtual machines; placing them in the System VM via winstart.bat ensured they didn't crash the system while remaining available for GUI apps.

Implementation Example

A typical winstart.bat might look like this:

@echo off
REM Load network drivers only for Windows environment
C:\NET\NETSTART.EXE
REM Load a Windows-specific memory manager
C:\UTILS\WINMEM.EXE

Historical Context

While often associated with Windows 95, this was actually a feature inherited from Windows 3.1 (and potentially 3.0). It is documented on page 263 of the Windows 3.1 Resource Kit.

The documentation provides a clear breakdown of TSR visibility:

Where TSR is loadedVisible in Windows?Visible in non-Windows VMs?
From MS-DOSYesYes (All VMs)
From WINSTART.BATYesNo
In a single VMNoOnly that specific VM

(Note: The Resource Kit uses "virtual machine" to refer specifically to non-Windows VMs, while referring to the main environment simply as "Windows".)

Final Checklist of Startup Events

  • Boot MS-DOS
  • Run autoexec.bat →\rightarrow→ Load Global TSRs
  • Initialize VMM →\rightarrow→ Real-mode File System (VMM takes over)
  • Create System VM
  • Run winstart.bat →\rightarrow→ Load Windows-only TSRs
  • Launch User-mode Kernel →\rightarrow→ Start GUI

compelling


Author Bio: Raymond Chen Raymond Chen has spent over three decades contributing to the evolution of Windows. In 2003, he launched The Old New Thing, a blog that has become a cornerstone for understanding the legacy and inner workings of the Windows platform.

youtube