winstart.bat: The Windows 3.1 Trick to Load TSRs Only for Windows Apps

A Microsoft “Old New Thing” post unpacks the purpose of winstart.bat, a batch file that lived in the Windows directory and ran at a very specific moment during boot. After MS-DOS started, autoexec.bat loaded its TSRs, and Windows initialized the virtual machine manager, the VMM would execute winstart.bat inside the newly created System VM—right before handing control to the user-mode kernel that runs Windows applications. The result is a window in which you could load memory-resident programs that exist only in the environment where Windows programs live, not in the separate MS-DOS VMs spun up later for command prompts.

The practical payoff was memory and driver management. You could install something like network drivers exclusively for your Windows programs, sparing scarce conventional memory in your DOS sessions, or accommodate drivers that couldn’t cope with running across multiple virtual machines by confining them to the System VM. Because each new DOS command-prompt VM is cloned from the System VM as it existed at Windows startup, it inherits autoexec.bat’s TSRs but never sees the ones loaded by winstart.bat.

The wrinkle the author flags is attribution: people routinely call this a Windows 95 feature, but it dates back to Windows 3.1 and possibly 3.0, documented on page 263 of the Windows 3.1 Resource Kit alongside a table comparing three ways to launch TSRs and where each becomes visible. It’s a small but telling artifact of the era’s layered architecture, in which a booted OS ends up running inside a virtual machine controlled by the OS booted around it.