In spite of Microsoft's best efforts, Windows 3.1 ran fine on top of DR-DOS or Novell DOS.
Myth: Windows 3.1 was just a shell on top of DOS
11–20 of 45 posts
Re: Myth: Windows 3.1 was just a shell on top of DOS
#12DOS provided a tiny fraction of what Windows provided? A full kernel acts as gatekeeper to system resources. While DOS provided access to some resources, it was single-process and so had no gatekeeping. No concept of different pools of resources, different lifetimes of activity. No comprehensive cleanup. Half of a kernel (or more) is taking things from one list and putting them on another list, so when something exit…
> it had not a chance in hell of performing well (executing out of ROM or whatever)
If CP/M-86 performed well, why wouldn't DOS? They're very similar.
Wouldn't the "shadow RAM" technique of copying the ROM BIOS into RAM solve any ROM slowdown issues?
Re: Myth: Windows 3.1 was just a shell on top of DOS
#13> Win386 ran individual "V8086" processes -- which was a key feature of the Intel 386 processor running in Protected Mode -- in a completely preemptive multitasking way.
What about Win286/running Windows 3.1 on an 80286?
Re: Myth: Windows 3.1 was just a shell on top of DOS
#14DOS provided a tiny fraction of what Windows provided? A full kernel acts as gatekeeper to system resources. While DOS provided access to some resources, it was single-process and so had no gatekeeping. No concept of different pools of resources, different lifetimes of activity. No comprehensive cleanup. Half of a kernel (or more) is taking things from one list and putting them on another list, so when something exit…
> it had not a chance in hell of performing well (executing out of ROM or whatever) If CP/M-86 performed well, why wouldn't DOS? They're very similar. Wouldn't the "shadow RAM" technique of copying the ROM BIOS into RAM solve any ROM slowdown issues?
Sure. But add to that, they were crappy drivers. Minimal things just to ship the product. No support for thread-safe or isolation or anything. In fact, they just looped on i/o ports waiting for device completion - no dma, no interrupts, nothing.
Enough to boot. But worthless for any real OS.
Re: Myth: Windows 3.1 was just a shell on top of DOS
#15Earlier quoted context omitted.
> it had not a chance in hell of performing well (executing out of ROM or whatever) If CP/M-86 performed well, why wouldn't DOS? They're very similar. Wouldn't the "shadow RAM" technique of copying the ROM BIOS into RAM solve any ROM slowdown issues?
Sure. But add to that, they were crappy drivers. Minimal things just to ship the product. No support for thread-safe or isolation or anything. In fact, they just looped on i/o ports waiting for device completion - no dma, no interrupts, nothing. Enough to boot. But worthless for any real OS.
If you're running a single app (e.g. a game, or WordStar), adding a "real" OS usually doesn't buy you much in terms of raw performance (though maybe you get better responsiveness during background printing or other multitasking.) In fact a "real" OS tends to add overhead.
Games are notoriously performance-intensive, and early 1990s PC games tend to run well on DOS - Windows just adds overhead. For that matter, many arcade machines used simple drivers and lacked a "real" OS as well.
Moreover, if you're not trying to run some multitasking workload with background tasks (and indeed you don't want to if you care about performance for your game), then polling in a game loop/frame loop may be more efficient than interrupts.
And when you're trying to extract maximal performance, as in the PC demoscene, you often want direct access to the "bare metal" devices themselves - something which DOS happily allows. Windows provides little - or negative - value.
Re: Myth: Windows 3.1 was just a shell on top of DOS
#16Earlier quoted context omitted.
Sure. But add to that, they were crappy drivers. Minimal things just to ship the product. No support for thread-safe or isolation or anything. In fact, they just looped on i/o ports waiting for device completion - no dma, no interrupts, nothing. Enough to boot. But worthless for any real OS.
If you're running a single app (e.g. a game, or WordStar), adding a "real" OS usually doesn't buy you much in terms of raw performance (though maybe you get better responsiveness during background printing or other multitasking.) In fact a "real" OS tends to add overhead. Games are notoriously performance-intensive, and early 1990s PC games tend to run well on DOS - Windows just adds overhead. For that matter, many a…
That's called 'embedded' and it has it's place.
It's nearly always better to take interrupts than poll. A device driver that leaves the game to execute game code, putting results on a queue the game can test in it's poll loop, makes the UI responsive. Otherwise it'd hang every time a write to disk occurred, waiting for seek, then shifing the bytes out. Not a benefit to anybody.
Re: Myth: Windows 3.1 was just a shell on top of DOS
#17> Win386 ran individual "V8086" processes -- which was a key feature of the Intel 386 processor running in Protected Mode -- in a completely preemptive multitasking way. What about Win286/running Windows 3.1 on an 80286?
On a 286, Windows 3.1 ran in 'standard' mode, so it had only cooperative multitasking. Preemptive multitasking was confined to 386 or higher, on which Windows 3.1 ran in 'enhanced mode'.
Re: Myth: Windows 3.1 was just a shell on top of DOS
#18This is a fun little bite-sized post, but I wish it tackled more of the nitty-gritty. Does anyone know of any write-ups on the architecture of early-90s Windows that are more in depth, now that this has whet my appetite? (Or other OSes of the era, come to think of it?)
Raymond Chen has got you covered. These three are my favorite technical articles on Windows 3.1:
- If Windows 3.11 required a 32-bit processor, why was it called a 16-bit operating system? [0]
- What did Windows 3.1 do when you hit Ctrl+Alt+Del? [1]
- How did Windows 3.1’s virtual machine manager get the information to show in the text-mode Alt+Tab switcher? [2]
[0] https://devblogs.microsoft.com/oldnewthing/20100517-00/?p=14...
[1] https://devblogs.microsoft.com/oldnewthing/20140912-00/?p=44...
[2] https://devblogs.microsoft.com/oldnewthing/20211129-00/?p=10...
I keep coming back for those three articles.
Re: Myth: Windows 3.1 was just a shell on top of DOS
#19This is a fun little bite-sized post, but I wish it tackled more of the nitty-gritty. Does anyone know of any write-ups on the architecture of early-90s Windows that are more in depth, now that this has whet my appetite? (Or other OSes of the era, come to think of it?)
Raymond Chen has got you covered. These three are my favorite technical articles on Windows 3.1: - If Windows 3.11 required a 32-bit processor, why was it called a 16-bit operating system? [0] - What did Windows 3.1 do when you hit Ctrl+Alt+Del? [1] - How did Windows 3.1’s virtual machine manager get the information to show in the text-mode Alt+Tab switcher? [2] [0] https://devblogs.microsoft.com/oldnewthing/20100517…
You keep coming back to them? Really? Why? They're interesting articles but they just scratch the surface and I don't see how further readings would change that.
Re: Myth: Windows 3.1 was just a shell on top of DOS
#20Earlier quoted context omitted.
Raymond Chen has got you covered. These three are my favorite technical articles on Windows 3.1: - If Windows 3.11 required a 32-bit processor, why was it called a 16-bit operating system? [0] - What did Windows 3.1 do when you hit Ctrl+Alt+Del? [1] - How did Windows 3.1’s virtual machine manager get the information to show in the text-mode Alt+Tab switcher? [2] [0] https://devblogs.microsoft.com/oldnewthing/20100517…
You keep coming back to them? Really? Why? They're interesting articles but they just scratch the surface and I don't see how further readings would change that.
For me, re-reading triggers a trip down Memory Lane. I have fond memories of the 90s so I just love to revisit to feed my nostalgia.
Plus, I really enjoy Raymond Chen’s writing style. Lastly, I want to remember the technical details, and re-reading helps with that.