The little-known winstart.bat batch file - The Old New Thing
Skip to main content
Dev Blogs
AI
All .NET posts
.NET MAUI<br>ASP.NET Core<br>Blazor<br>Entity Framework
C++<br>C#<br>F#<br>TypeScript
NuGet<br>Servicing<br>.NET Blog in Chinese
Microsoft for Developers<br>Agent Framework<br>Develop from the cloud<br>Xcode<br>ISE Developer<br>TypeScript<br>PowerShell<br>Python<br>Java<br>Java Blog in Chinese<br>Go<br>Microsoft Edge Dev<br>Microsoft 365 Developer<br>Microsoft Entra Identity Developer<br>Microsoft Entra PowerShell
Visual Studio<br>Visual Studio Code<br>Aspire
All things Azure<br>Azure SDK<br>Azure VM Runtime Team<br>Microsoft Azure<br>Azure Cosmos DB<br>Azure DocumentDB<br>Azure Data Studio<br>Azure SQL<br>DevOps<br>DirectX<br>Microsoft Foundry<br>Power Platform
OData<br>Unified Data Model (IDEAs)
Windows Command Line<br>#ifdef Windows<br>Inside MSIX<br>MIDI and music<br>React Native<br>The Old New Thing<br>Windows Developer
Raymond Chen
Reader Otul Osan wants to know what the use case for C:\WINDOWS\WINSTART.BAT was, compared to C:\AUTOEXEC.BAT and when exactly during system startup it launches.
In Windows 95, you could create a winstart.bat file in your Windows directory. During startup, the virtual machine manager initializes and creates the so-called "System virtual machine" (the "System VM"), which is the virtual machine that all Windows programs run in. But before running the user-mode kernel in that virtual machine, the virtual machine manager runs the winstart.bat batch file if it exists.
In pictures: First, we boot up MS-DOS and the command prompt. (Note: All diagrams omit lots of details not relevant to the discussion and are not to scale.)
Stuff<br>(unused)<br>MS-DOS
The box labeled "Stuff" is a catch-all for random things that go at low addresses, like the interrupt vector table and the BIOS data area.
Next, command.com runs autoexec.bat, which might install some TSRs.
Stuff<br>TSR1<br>(unused)<br>MS-DOS
And then Windows starts up and initializes the virtual machine manager. The system is now running in protected mode with a virtual machine running in v86 mode, and that virtual machine is initialized with whatever was running in real mode at the time the virtual machine manager took over.¹
v86 mode<br>Stuff<br>TSR1<br>(unused)<br>MS-DOS
ring 0: virtual machine manager
I crossed out MS-DOS because the virtual machine manager took over responsibility for the file system and shut off the real-mode file system in MS-DOS.
At this point, the virtual machine manager runs winstart.bat inside the virtual machine, and maybe it installs another TSR.
v86 mode<br>Stuff<br>TSR1<br>TSR2<br>(unused)<br>MS-DOS
ring 0: virtual machine manager
And then we start the user-mode kernel that is in charge of Windows applications. That user-mode kernel switches the virtual machine into protected mode and starts running what most people think of as Windows.
v86 mode<br>Stuff<br>TSR1<br>TSR2
MS-DOS
prot mode
(ring 3)<br>GUI stuff
ring 0: virtual machine manager
And then from the Windows GUI, you decide to open a command prompt, which means creating a second virtual machine.
v86 mode<br>Stuff<br>TSR1<br>TSR2
MS-DOS
prot mode
(ring 3)<br>GUI stuff
ring 0: virtual machine manager
v86 mode<br>Stuff<br>TSR1<br>COMMAND.COM<br>MS-DOS
Notice that the virtual machine running command.com is a copy of the system when Windows started.² So it has TSR1 (from autoexec.bat) but not TSR2 (from winstart.bat).
If you install a TSR in the command prompt virtual machine, you get
v86 mode<br>Stuff<br>TSR1<br>TSR2
MS-DOS
prot mode
(ring 3)<br>GUI stuff
ring 0: virtual machine manager
v86 mode<br>Stuff<br>TSR1<br>TSR3<br>COMMAND.COM<br>MS-DOS
Okay, now that we see how the pieces fit together, we can reverse-engineer the purpose of winstart.bat.
The intended purpose of winstart.bat is batch file is to allow you to install TSRs that will apply only to Windows programs. For example, you might install network drivers to support your Windows programs. You might choose this option instead of installing them globally because you don’t care about networking for your MS-DOS programs and want to free up conventional memory for them. Or because those drivers don’t support running in multiple virtual machines, so you’ll take them in the System VM and forego them for your MS-DOS programs.
What I find interesting is that most people who discover this say that it’s a feature of Windows 95. But really, it’s a feature of Windows 3.1 (and possibly even Windows 3.0). You can find it documented in the Windows 3.1 Resource Kit on page 263. That page even has a nice table showing three ways of launching TSRs and how they are visible in the different virtual machines. (In this table, "TSR visible in virtual machines" really means "TSR visible in non-Windows virtual machines", but the documentation takes the convention that the term "virtual machine" refers only to non-Windows virtual machines and not to the virtual machine running Windows itself, which it simply calls "Windows".)
Where TSR is loaded<br>TSR visible in Windows?<br>TSR visible in virtual machines?
From MS-DOS<br>Yes<br>Yes, all virtual machines
From WINSTART.BAT<br>Yes<br>No
In a...