The little-known winstart.bat batch file | Hacker News Reader

The little-known winstart.bat batch file

devblogs.microsoft.com

137 pointsingve41 comments

The architecture the DOS-based windows line, and particularly the versions that had the virtual machine manager and ran in 32-bit protected mode, is such an interesting crufty archaeological dig. The OS's are bristling with hacks to make things work in resource-constrained environments, all while having ridiculous amounts of compatibility. There's a certain perverse elegance in it.

NT, being a "real" OS (with memory protection, kernel/user separation, access control, etc), seems so much more obvious (and boring) in its design compared to the earlier DOS-based Windows series. The "adults" came in and showed the kids how to make a grown-up operating system.

I don't miss the instability of the older DOS-based Windows OS's, for sure. I wouldn't want to go back there. For their time, though, they really did punch above their weight.

Edit: I didn't mean "adults" in any negative sense. I think MSFT took advantage of an opportunity for some very senior and opinionated talent.

I don’t know about that “adults” comment. Microsoft grew their operating system up from a very low base where the “adults” moved theirs down. For most users, windows NT was ridiculous overkill.

At the time most users and businesses didn’t own a PC that could do the virtualisation tricks required by windows 3 (o windows 2 386). A lot of places still had XT class machines right up to the end of the 1980s.

So the Microsoft guys had a pretty complex landscape in which Windows had to operate and they managed a fantastically complicated solution. They were definitely adulting hard during that time.

I didn't mean to imply there was something "less" about the talent creating the DOS-based Windows OS. I think it's a marvel of engineering for economy and constraints.

I think NT was a means to an end (government contracts requiring a "Rainbow book"-qualified OS). It was a long time before the DOS-based Windows OS lost its position as the consumer / business offering. I think that shows MSFT knew what they had in that legacy code and leveraged it for great profit for a long time.

I think the "adults" came in and made a stuffy buttoned-down operating system meant to qualify as a "C2"-compliant OS meant to win contracts. NT doesn't have the hacky charm of the DOS-based Windows versions.

> I didn't mean to imply there was something "less" about the talent creating the DOS-based Windows OS. I think it's a marvel of engineering for economy and constraints.

"DOS-based Windows" was not an OS. It was effectively a program which provided a green thread[0] execution model for cooperative processes to execute within and had the reliability one would expect from same.

0 - https://en.wikipedia.org/wiki/Green_thread

Windows/386, and later 3.x and 9x, was a virtual machine monitor that could run 16-bit operating systems with 32-bit drivers.

The desktop environment you saw was nothing but the main virtual machine, and inside that was the green thread environment you describe. But the VMM on the outside was pretty solid.

> Windows/386, and later 3.x and 9x, was a virtual machine monitor that could run 16-bit operating systems with 32-bit drivers.

Those were not "DOS-based Windows". If your position is Windows/386 et al were OSs which supported running MS-DOS programs, I agree. But that is not "DOS-based" so much as "can run DOS programs."

> The "adults" came in and showed the kids how to make a grown-up operating system

Oh please — it's easy when you have the luxury of starting from scratch with unlimited budget.

DOS-based Windows had to both retain backwards compatibility with DOS applications and all their quirks and coexist with them at the same time.

The amount of hacks necessary to pull that off is an accomplishment unto itself.

Remember you couldn't really play games on NT-based Windows until Windows XP came out and even then DOS games were pretty much out until DOSbox came along.

Guess those "adults" had to stick with Solitaire and Hearts.

Windows games worked great on Windows 2000! There were officially inofficial packages of DirectX and such - I never had any trouble with them.

I think DOS games also worked.

Wow, ancient memory unlocked. Grabbing and ripping the DirectX releases. Word.

There was nothing unofficial about it -- Windows 2000 had full, official DirectX support parity with Win9x.

Windows XP is where Microsoft themselves pushed the consumer market onto the NT line, but Windows 2000 was fully functional as a consumer desktop.

Definitely. I think the way microsoft brought their user base along between 1990 and 2000 from Dos to 32-bit protected mode was beautifully respectful of their users. To me it's the standard for how to change a user's preferences (maybe for social change in general). I just used Dos or win16 apps less and less over the decade and eventually my use dropped to zero. At no time did I feel coerced to leave behind what I already invested in, I just came to appreciate the alternative they were offering (the opposite of a forced OTA update). By the 2000s I could already sense a slight change in tone with how strongly they were pushing those service packs for windows xp.

IMHO it was an architecture far ahead of its time --- basically a hypervisor running existing DOS in VMs, with all hardware passed through by default. If they kept at it instead of abandoning for NT, by e.g. increasing protections for better isolation and reliability, while still passing through where performance mattered, we might've gotten Microsoft's take on Xen.

Would HyperV and Virtualization Based Security be that take? I suppose it’s taken very far on Xbox and VBS is enabled by default on most Windows systems.

It was not a hypervisor, the hardware was not virtualized. They instead used 16-bit code for the OS kernel, simply transitioning between 16 and 32-bit modes.

The 16-bit code was a dead end. It was not re-enterable, so 32-bit code had to take a Win16Mutex on every kernel code.

If you ever debugged DirectX code on Win9x, you'd remember that quite vividly. The LockSurface call that provided direct access to pixels locked this mutex, so a breakpoint in a locked section caused an instant hard deadlock.

That being said, it indeed was a brilliant hack that allowed a featereful GUI to run within 2Mb of RAM with good DOS compatibility.

The hardware was virtualized, it's even in the name for drivers on Win9x: Virtual Device Driver

VxD-s technically allowed virtualizing devices, but only in a very limited way. The port IO instructions were easily intercepted but not much else. VxDs could use page protection tricks to redirect MMIO but this was used sparingly.

Really the only serious "virtualization" was in the interrupt handling. Code in Win9x that handles interrupts had to be 16-bit and located in the lower 640kb of RAM.

Most VxDs worked like classic drivers, they encapsulated device-specific interfaces and provided more abstract application-level interfaces.

If the NT design were as obvious as you suppose, then POSIX systems would work that way too.

The "obviousness" about NT's design I was talking about, compared to the DOS-based Windows versions, were things like a trusted computing base, access control, kernel/user separation, memory protection, etc (stuff the DOS-based Windows versions had little to none of).

POSIX systems have that stuff, too.

In other words, POSIX and NT are both "traditional OS" architectures where the OS serves as a relatively heavy and thick abstraction layer that isolates userspace from the hardware, while DOS-based ("hosted DOS"?) Windows is really more like a thin bare-metal hypervisor which arbitrates or virtualises direct hardware access between VMs running DOS. From that perspective, what users think of as "Windows", i.e. the GUI and the whole Win32 environment, is actually just another DOS application running in the protected-mode environment of a DOS extender (DPMI).

"Showstopper" is the book that explains this time in Microsoft's history. An excellent read.

In retrospective everything is easy.

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.

Decades later, this was again brought to attention by https://en.wikipedia.org/wiki/Hyperjacking and subsequently Microsoft themselves "reinvented" the concept as a Windows feature: https://learn.microsoft.com/en-us/windows-hardware/design/de...

Nice little metaphor in the footnote, there:

>>> 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's funny how Windows 9x (and the 386-enhanced versions of 3.x) used "VM" to refer to DOS specifically. The legacy of real mode software was so towering even back then that Intel had to build a mode to virtualize those apps specifically, despite x86 not being able to virtualize protected mode kernels until decades later. In what other CPU architecture do you get such specific amount of privilege isolation?

To be fair, almost all applications in the mid 1980's were real mode, so adding a feature that would allow virtualization of the vast majority of apps makes total sense. Remember, almost no software used the 286's "protected mode" capabilities. Intel wouldn't make the same mistake with the 386.

Here’s hoping that we’ll have the technology to digitize human brains before Raymond Chen dies.

Pictures are worth a thousand words, and oh man those diagrams. I could have used them back then!

Always enjoy a Raymond Chen article

What the heck are "TSR"s? Is this common knowledge?

TSR stands for Terminate and Stay Resident, a distinct behaviour for DOS era programs, which would usually run to completion and exit.

To expand upon this - the TSR programs stayed in memory after being loaded. Typical use were drivers, for example mouse driver. It loaded, hooked itself in the interrupt table and then exited back to DOS prompt. And this gave you mouse support for other programs.

Wikipedia has some details, if you are interested: https://en.wikipedia.org/wiki/Terminate-and-stay-resident_pr...

DOS programs generally were like command line apps today (but simpler, obviously). They did a thing, then exited. Or they showed their "TUI" (as we'd call it today), and when you told it to exit, you got back to the DOS prompt to start the next program.

TSRs were a special kind of program, that instead of telling DOS "I'm done, here's my memory back", said "I'm done for now, but don't unload me", so their memory stayed allocated/used. And you got your command prompt back immediately to continue your work.

TSRs usually hooked into an interrupt like the keyboard interrupt, intercepting a hotkey to re-activate the program (so you could browse your address book while you were in your (text mode) word processor; "kind-of" multitasking), or they offered a service to other programs (like the mouse and CD-ROM drivers).

There were all kinds of things that ran as TSRs. Virus scanners (hooking into disk write/reads), modem tools (showing "RING" in the corner of the screen when the modem detected an incoming call), note-taking apps, address books, you name it.

It was common knowledge, though not for most of those (with some exceptions like legacy gaming fans) coming into the PC world much after the early 2000s.

Terminate but Stay Resident was the original DOS function call to allow a utility program to exit but stay in memory waiting for interrupt signals (it will have hooked into those interrupts before calling TSR) to respond to. Utilities that operated in this manner (mouse drivers, and many other useful things) became collectively known as TSR programs and then just TSRs.

There were later other methods of leaving code resident, implemented by various memory managers for background tools that needed to use RAM outside the first 1MB (which in reality meant outside the first 640KB because of how the PC memory map was arranged), but the name TSR stuck to cover them generally.

WINSTART.BAT is just "AUTOEXEC.BAT for Windows"

The extra diagrams to state how it all works were extra.

It’s not obvious that what WINSTART.BAT loads wouldn’t be available in DOS prompts started from Windows.

I suppose it isn't if you never had it on real hardware. Win32 was well marked as the complete OS takeover for the PC. DOS remained only to boot Windows and as backup OS. If you absolutely needed to jump back to DOS you still could, however you were heavily expected to force your DOS programs to launch and live in their own little DOS environments, much to everyone's chagrin.

It's the “own little DOS environments” that makes WINSTART.BAT's functionality surprising for people who ain't intimately familiar with the Windows 3.1/9x architecture, because those DOS environments are launched from within Windows but without running anything in WINSTART.BAT. Most people would expect those DOS environments to be running inside the Windows environment, not in parallel with / independent from it.

> I suppose it isn't if you never had it on real hardware. Win32 was well marked as the complete OS takeover for the PC. DOS remained only to boot Windows and as backup OS. If you absolutely needed to jump back to DOS you still could, however you were heavily expected to force your DOS programs to launch and live in their own little DOS environments, much to everyone's chagrin.

I remember that at the time of Windows 95, I very often had to boot back to DOS 7.0 (which was also delivered as part of the Windows installation) to run DOS games, which were still very popular until like the middle of the 00 years.

And yes, when Windows XP came out (2001), people were somewhat disappointed that you couldn't simply boot DOS anymore to play your old beloved games. Over the years, DOSBox got sufficiently stable and PCs got sufficiently powerful that this gap could be closed.

I've forgotten now when it changed, but I remember older versions of Windows let you exit back to DOS once you'd finished doing GUI stuff. I'm guessing that was probably removed in Win95 as that was the first "proper" Windows that didn't rely on already having DOS (IIRC).

> I've forgotten now when it changed, but I remember older versions of Windows let you exit back to DOS once you'd finished doing GUI stuff. I'm guessing that was probably removed in Win95 as that was the first "proper" Windows that didn't rely on already having DOS (IIRC).

Until Windows 3.x this was possible (though not recommended). With Windows 95, there was a boot menu that you could access via the F8 key - my previous post should make it very clear why I still have this in my muscle memory after 20-30 years. Via this boot menu, you could boot into DOS 7.0 (or if an older DOS version was installed before the Windows 95 installation, also this older DOS version). In DOS, you could still run

> win

to get to Windows 95.

Reply on news.ycombinator.com