Laevos

(>^—^(>ÓωÒ)>

^ ~
ω


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.


DecayWTF
@DecayWTF

It's fundamentally, like Gravis said, a question of What An Operating System Is. How do you define it?

The very oldest computers had no operating system. Not only that, they didn't even have anything we'd recognize as a bootloader. All they did was munch instructions that were physically wired in, via plugboard, switch panel or both. Stored program computers were the next innovation, because plugboards or just directly slam-dunking machine code into memory by switches doesn't really scale to programs that are very long at all. Instead, you wrote your machine code on punchcards, the punchcard reader - a frontend to the actual computer - slurped the machine code on the punchcards into memory and then the computer ran it. Still no OS or anything, it's all just running on bare metal.

People started to realize two things at this point:

  1. Computer programs often do a lot of the same things as other programs. You don't have to reinvent the wheel every time.
  2. If your computer has any mechanism to do this at all, keeping that shared functionality in memory and only bringing in new programs allows you to write smaller programs.

And so people started writing shared libraries of functionality, and then the operators started keeping those libraries resident. Eventually the libraries started developing their own functionality, for debugging or hardware management and soon the libraries evolved into what were called "monitors", which could manage software on their own. These were the first operating systems as we know them!

The thing to understand here is that these were mainframe programs but were still single-tasking, single-user. The mainframe operators still ran single programs (now loaded via the monitor!) in batch mode and then provided the results to the programmer.

The real big innovation next was timesharing, allowing multiple batches and multiple interactive programs to run at, from the user's perspective, the same time! This is where modern operating systems started; they supported memory management, and multiple process management. They had filesystem drivers and network subsystems. Some of these systems we use (their direct descendants) daily, most especially Unix.

So! By the late 60s/early 70s, this is what an OS really is, a full scale modern OS. You still had single-tasking systems like RT-11 that were mostly employed for realtime operations like industrial control; they didn't have process control for multitasking but they still had many of the other features including hardware abstraction, memory management, filesystem and network and other device support and the like.

Mid-70s, the first microcomputers appeared. The Altair 8800, the KIM-1 and others all emerged in the 74 to 76 period. These were full-fledged computers, not just calculators or such, but were vastly less powerful than even the smallest minicomputers that could run small OSes like RT-11, let alone the big CDC beasts or DEC's 36-bit monsters. They went through a similar evolution of operating systems, with the earliest being simple ROM-based or switch-loaded monitors, with relatively more powerful embedded BASIC environments or simple control systems built on the same architectural lines, but vastly simplified, as already simple single-tasking RTOSes like RT-11, coming along later.

The most popular of these control environments, which DOS was somewhat of a copy of, was CP/M. CP/M provided some of the functionality that would be expected of a minicomputer OS; it had filesystem drivers, and some minimal hardware abstraction, so that CP/M software (as long as the CPU was the same or compatible) written correctly could run on different computers without having to be rewritten.

DOS was different on that respect, in that it was never intended to be portable. The original 86-DOS written by Seattle Computer Products was just a quick and dirty system to run development on for an 8086 development system. When Microsoft acquired it to sell to IBM, they wrote some utilities to get a fully functional computer out of it, with some APIs to support, but that's it. The result is this:

Almost every DOS program of any complexity had to bypass it and talk to the hardware directly.

This was not a hard thing to do! DOS provided no (and so enforced no) memory management, hardware layer, process control, and so on. It had some facilities to allow well-behaved software to coexist and hooks to allow drivers to extend the OS functionality, but that was it. Quite a bit of software, especially games but also a fair number of commercial/business packages, interacted with DOS very little or not at all; some things we remember as DOS programs actually weren't but booted directly from floppies without DOS ever being started.

The upshot of this is that a lot of programs for DOS functioned, to some extent or another, as operating systems in their own right. Video card manufacturers famously provided their own graphics drivers, not for DOS, but for AutoCAD. In general, the only thing these programs used DOS for was the filesystem access, treating DOS itself as basically just a disk driver. 386 era programs that used DOS extenders (think Doom) had the DOS extender take over the system entirely, and the DOS extenders would supply basically everything a traditional OS would: Memory management, process control, sometimes a hardware abstraction layer with its own small set of drivers, only ever thunking back to DOS for (you guessed it) filesystem access. DOS itself just kind of sat and vegetated in a corner, not even running in any meaningful way unless the DOS extender invoked it.

So! Not only was Windows basically a full operating system from word go, so were a lot of other programs. Some of them were even OS-shaped and provided their own operating environment distinct from the DOS command line, like Desqview (a true multitasking, windowing system for DOS programs that was probably Windows' biggest competitor in the early days). Others were programs like AutoCAD or Doom that shoved DOS completely out of the way and took over the whole computer.

Even for the era, DOS was wimpy. "A shell on top of DOS" is verbal sleight-of-hand because DOS basically didn't do shit.


cathoderaydude
@cathoderaydude

it's almost like "disk operating system" was primarily software for accessing disks


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

in reply to @DecayWTF's post:

Even for the era, DOS was wimpy. "A shell on top of DOS" is verbal sleight-of-hand because DOS basically didn't do shit.

also worth keeping in mind that 86-DOS/microsoft DOS wasn't the only DOS in the market sector of DOSes, at the time it launched; other microcomputers like the apples, commodores, and ataris had their own DOSes that limited themselves to the prosaic goal of operating a disk, i.e., providing small bundles of routines specifically for formatting disks, getting disk directories, reading and writing files, and executing programs off a disk.

however, 86-DOS/microsoft DOS was a DOS for the IBM 5150 Personal Computer, which originally shipped with a ROM BASIC, no system monitor, and no disk drives in its base configuration -- so its DOS had to do everything else as well.

it wasn't a crappy operating system1, it was a disk operating system that had to bring along a whole bunch of other stuff because none of it came with the computer.


  1. in the sense of a supervisor

:yeah:

Actually, I am also remembering, unbidden, that Commodore's approach for the C64 in particular was typically unhinged Commodore bullshit where they put what would nominally be the DOS in the firmware of the disk drive itself and shunted the entire user interface through the BASIC LOAD and SAVE commands