Microsoft shares details of a clever old Windows trick it no longer needs

Microsoft continues to enhance Windows, and over the years, the operating system has amassed a variety of lesser-known features. Among these is a batch file that many users, including readers of Neowin, may not be familiar with: the WINSTART.BAT file.

Understanding WINSTART.BAT

In a recent entry on Microsoft’s Old New Thing blog, veteran engineer Raymond Chen shed light on the purpose and historical context of WINSTART.BAT, detailing its role in the Windows startup sequence. Contrary to popular belief, this feature did not debut with Windows 95; rather, it predates the operating system by several years and was thoroughly documented in the Windows 3.1 Resource Kit.

Batch files, as many may know, serve as a practical means to automate routine tasks. These simple text files contain a series of commands that the Windows Command Shell executes sequentially. Although they are less advanced than contemporary PowerShell scripts, batch files remain supported in modern Windows environments.

The primary function of WINSTART.BAT was to enable users to load terminate-and-stay-resident (TSR) programs, which would be accessible to Windows applications but not to individual MS-DOS virtual machines. For context, a TSR is an MS-DOS program that appears to exit yet remains in memory, allowing it to be reactivated through a hardware or software trigger. TSRs were frequently employed for utilities accessed via hotkeys or as device drivers, effectively circumventing MS-DOS’s limitation of running only one program at a time.

Chen illustrated this concept with the example of a network driver. Users could load a necessary driver for Windows while avoiding the memory overhead associated with making that driver available to MS-DOS programs as well.

WINSTART.BAT vs. AUTOEXEC.BAT

To clarify how WINSTART.BAT integrates into the startup process, Chen compared it to AUTOEXEC.BAT. The latter executes during the MS-DOS startup phase and can load TSRs that are then inherited by the virtual machines Windows creates for MS-DOS applications.

Once Windows initializes its virtual machine manager (VMM), it establishes the System VM, where Windows applications operate. Before the Windows user-mode kernel is initiated, the VMM executes WINSTART.BAT, provided the file is present. This timing grants WINSTART.BAT a distinct advantage.

Windows 3.x and Windows 95 utilized VMs to run MS-DOS environments. TSRs loaded via AUTOEXEC.BAT were accessible within those environments. In contrast, TSRs loaded through WINSTART.BAT were limited to Windows programs running in the System VM and did not extend to separate MS-DOS VMs. In essence, a TSR loaded via AUTOEXEC.BAT was available to both Windows and its MS-DOS environments, while those loaded through WINSTART.BAT were confined to Windows alone.

For those interested in delving deeper, the official blog post can be found on Microsoft’s site.