[MS] The little-known winstart.bat batch file - devamazonaws.blogspot.com
Reader Otul Osan wants to know what the use case for C:\
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 | (unused) | 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 | TSR1 | (unused) | 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.¹
|
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.
|
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.
|
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.
|
ring 0: virtual machine manager | ||||||||||||||||||
|
|||||||||||||||||||
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
|
ring 0: virtual machine manager | ||||||||||||||||||
|
|||||||||||||||||||
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 | TSR visible in Windows? | TSR visible in virtual machines? |
|---|---|---|
| From MS-DOS | Yes | Yes, all virtual machines |
| From WINSTART.BAT | Yes | No |
| In a single virtual machine | No | Only that virtual machine |
¹ Think about that: We booted an operating system and then booted another operating system around it, so that the original operating system was now running inside a virtual machine controlled by the second operating system. It's like leaving your house, walking down the street, and halfway down the block, realizing that you're now walking inside a movie studio set.
² It isn't actually a copy of the system at the time Windows started. Rather, it is a copy of the system VM, but only the parts that existed at the time Windows started. How this worked is too complex to try to explain in a footnote. Maybe I'll discuss it some other time.
Post Updated on August 11, 2026 at 03:00PM
Thanks for reading
from devamazonaws.blogspot.com
Comments
Post a Comment