cathoderaydude
@cathoderaydude

yesterday someone asked me if I could resolve the "eternal question" of whether Windows (pre-NT) was "just a shell for DOS." my answer is an unequivocal no, since this assertion never existed in good faith; it's on par with "fix or repair daily :)))))))))", it's just a snarky thing that some jerkwad on usenet came up with solely to start fights. still, before I answered, I did give it a few minutes thought to decide why i was sure of this

"shell", definitionally, is an interface for an existing operating system. Microsoft's own DOS Shell, for instance, does nothing more than streamline access to existing DOS system calls, and launch native DOS applications. X-Tree Gold also did little more than provide interfaces to "move", "attrib", "rename" and so on. even /bin/bash, which has been used to write entire sophisticated applications, is little more than a program launcher with dipping mustards.

this never really applied to Windows, and with every year it existed, it applied less. the very first version of the OS, in 1985, provided an extremely rich set of APIs. some depended on underlying DOS system calls, sure, but that really doesn't mean anything.

"operating system", in 1981, meant a very different thing than it does now. DOS was nothing but a handful of system calls. it had no HAL; it didn't sit in between processes and hardware, unless they opted to do so. you could ask DOS to access a hard drive or a graphics card for you - or you could just blow past it and access the hardware yourself. DOS couldn't get in your way, because when your program was running, DOS wasn't.

literally, as soon as you launched an app, DOS stopped executing. it remained resident in memory, but it had no agency. your program owned the CPU in its entirety, and could keep it until you powered the machine off. the only things that would cede control back to the OS were system calls or hardware interrupts, almost all of which could be ignored.

the same is true for other contemporary platforms. the early PC was closer to an 8-bit home computer than what we think of now, and the OSes that came out for the Apple II and Atari 400 were similarly thin; applications did 95% of the work themselves, and relied on the OS only for tedium like "write text to the screen, i don't really care how long it takes"

unlike what we now think of as "an OS", DOS did not manage processes, or gate access to hardware. it had no HAL. it was, for the most part, simply a library that programs could rely on - and not a very big one. if microsoft had decided to make Windows totally independent of DOS, it would have taken them a couple weeks to rewrite the handful of relevant system calls. they didn't do this because one of the primary features of windows was the ability to run legacy DOS apps. so yeah, duh, of course DOS still needed to be resident.

the amount of sophistication in the very first release of Windows, ignored and unsuccessful as it was, made DOS look like Hello World. programs running under Windows 1 did not need to know that DOS existed. i think, at the point where something literally has its own executable format, you have to admit that it's an operating system.


You must log in to comment.

in reply to @cathoderaydude's post:

This is wild. I knew DOS was pretty basic but I didn't know it was so... optional, for programs that ran on it.

So, if I execute a program in DOSbox, what's it actually doing? Is it less about emulating an OS environment and more about emulating the kind of underlying hardware that the program expects?

yup, 90% of what it's doing is just emulating the hardware. it also has a compatible copy of the DOS APIs, because 99.99% of software DOES depend on those at least to start, and usually for some amount of busywork. especially disk access - it was smart to let DOS handle that rather than trying to parse the FS yourself, that's just bad vibes. but there were absolutely programs that touched the OS for nothing except file handling.

all of the above is true for the BIOS, too. it was also mostly just a pile of hardware access routines that you could use if you wanted. as a result, you'll sometimes see references to "well-behaved software." if you're reading about weird "PC incompatibles", like the few 80186 machines that got made, or the PC-98, you'll hear this term come up, and it basically means "programs that exclusively use DOS or BIOS calls instead of touching memory directly."

if you wrote an app that did everything possible through the BIOS or OS - graphics writes, keyboard polling, etc. - then you could often use that app on things that were not "100% compatible." but a LOT of software was not like this, and when you ran it on one of these "not-quite PCs", it would try to write to what it thought was video memory, and scribble over parts of the BIOS instead, that kind of thing.

PCs were barbarian before protected memory. it is really astonishing that anything worked.

Reading and enjoying this! As someone who has written a DOS game within the past few years, I have a theory as to what specifically Crystal Caves and Commander Keen are doing to make Windows/386 freak out about running them a window: scrolling.

Some quick background: CGA had just barely enough video memory - 16kb - to hold a single screen's worth of pixels when not in text mode. You dump pixels to memory, they show up on the screen. You want different pixels, you write different pixels to memory. If you're an OS looking to pretend to be a video card, this is a reasonably good situation to be in; catch the writes to video memory and redirect them to a different spot in video memory where your window is (and/or to your offscreen buffer if you've shrunk the window). There's overhead, but it's manageable.

EGA came along and declared that 64kb of video memory was the absolute bare minimum you could reasonably get away with, and if you paid IBM for all the expansion kits, you should be able to go as high as 256kb. When fully expanded, this is enough memory to store four 320x200x16 colour screens of graphics with some room to spare. Because there's now so much extra space, the EGA card can offer the capability to give it a "window" into video memory - specifying where it should look to read the pixels for the screen when generating its video signal. This is very fast and cheap to do in hardware, and was pretty much the only way you could get smooth scrolling in DOS in that era - redrawing the full screen to video memory every frame just took way too much time. Panning around memory that you've already written, though? Basically free.

This mechanism was also used as a double buffering or "page-flipping" technique, to prevent flickering. Keep two screens in video memory, draw the next frame on top of the one that's not currently being displayed, and swap between them when you're done. The user only ever sees a stable, complete image. I believe Commander Keen combines both techniques.

For Windows/386, any program messing with this feature would be an absolute nightmare. To simulate it in a window, it would need to actually do the full redraw, turning an operation from one 16-bit write into tens of thousands of slow memory accesses. It would theoretically be possible, but in practice the experience would be so miserable, the performance so awful, that you might as well just pause it, tell the user to go to fullscreen, and let the game have full access to the video card.

By the time Windows got to “386 enhanced mode” in windows 3.0, it also became a “real operating system” by pretty much any beard strokingly technical definition of the term, since there was a real kernel providing real memory protection there. DOS served as boot loader, and stayed resident to provide services and drivers Windows didn’t yet provide itself (particularly disk and file system access), but only served passively at the Windows VMM’s demand.

And then Windows 3.11 For Workgroups added “32-bit file access”, which is a boring name for a complete rewrite of the disk and file system drivers as native Windows drivers, and you could have a system that basically never invoked DOS code once Windows was running

haha, yeah, i was thinkin about that! especially by 95, was any part of windows, or any normal windows app, ever calling out to a part of DOS? as far as I know, absolutely not.

and, while this is a blank spot in my understanding of real mode multitasking, i kind of assume that every new DOS process or command window gets its own distinct duplicate of the OS in memory when launched. so i wonder if that "underlying" copy of the OS is even actually used once Windows has started.

ada answered the "was windows ever calling into DOS" bit, but what happens when DOS programs run in Win3.x or Win9x is interesting too. each DOS box does indeed get a mostly-clone of the DOS system as it existed when Windows booted; there are hidden DOS calls that drivers and TSRs can use to map certain memory regions as being globally shared among all DOS boxes when running in Windows, but for the most part they're isolated. so you have a funny situation in Win3.x where DOS programs get memory protection and preemptive multitasking but Windows apps don't

windows also serves as a DPMI host, so if you run something like Doom which comes with a compatible DOS extender, then DOS/4GW will see that there's already a DPMI host in place and let it handle all the syscalls and such. so if you run Doom in Windows, when it makes DOS syscalls, those syscalls end up being handled directly by Windows code

back in the day there was even a linux bootloader syslinux.exe that booted a linux kernel from DOS, and you could use a umsdos file system driver that let you use the DOS filesystem as your root partition, mangling Unix long filenames into 8.3 filenames with hidden metadata files to carry the long file name and Unix-specific attributes, which is not so different from how windows 95 works

hmm. if you want the period-accurate experience, you can look at old versions of Slackware that supported this as an installation mode, like if you look for umsdos in http://slackware.absolutehosting.net/pub/slackware/slackware-2.0.0/INSTALL.TXT .

it looks like syslinux has still been getting updates as recently as 2014: https://wiki.syslinux.org/wiki/index.php?title=Syslinux_6_Changelog#Changes_in_6.03 i remember having to use it with my old whitebox computer back in the day because it had a weird sound card that could only be switched into soundblaster mode by a DOS TSR, so to get sound in linux i had to boot into dos, run the dos driver, then boot the linux kernel with syslinux