Myth: Windows 3.1 was just a shell on top of DOS(lunduke.locals.com) |
Myth: Windows 3.1 was just a shell on top of DOS(lunduke.locals.com) |
1. All Windows native apps were cooperatively multitasked. Only DOS boxes were pre-emptively multitasked. When your GUI locks up because some random app got into an infinite loop you're not going to sit there thinking "Oh goody, my dos box is still usable (or would be, if I could switch to it)".
2. Even then, virtual x86 mode was a 386-only feature. Windows on older machines ran in "standard mode" which featured no pre-emptive multitasking at all (DOS boxes only ran in the foreground).
3. DOS as a whole was not unloaded, only the command line portion, COMMAND.COM, was. (This was how DOS was designed to work, to free up as much memory as possible for th foreground program). Device drivers (.SYS) stayed loaded, because...
4. Windows could use DOS drivers, and it was very common, particularly in the early days, to have a CD-ROM or network device which didn't have native Windows support. For these devices Windows would call the DOS routines as usual. (I'm pretty sure, but not certain, that this was the only route Windows would take on non-386 machines.)
On the other hand, on 386, it was indeed possible to configure Windows in 386 Enhanced Mode with the correct driver set such that it was not using any DOS services, and you could run as many DOS boxes as you liked without fear of one of them locking up the rest of the system.
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 exits or dies or faults, it can release resources that were allocated to the dying thing.
The hardware access was the lowest, simplest part of that. And DOS used the BIOS anyway, for half of what it did (floppy drivers etc). Which meant 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?
Enough to boot. But worthless for any real OS.
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?)
- 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.
https://www.geoffchappell.com/notes/windows/archive/aard/drd...
Even Windows 1.0, which more directly sat on top of MS-DOS, had to implement considerable amounts of functionality that would be considered more of a kernel than what MS-DOS offered.
If you were running Windows NT, when running a 16-bit .EXE file, there was a checkbox in the properties dialogue titled something like "run in separate memory space". That launched this particular binary in its own isolated wow16 runtime.
Of course, being an official Microsoft Project slightly reduces how impressive visit.
The other one that I am aware of is that Quarterdeck's DESQview/X could run multiple instances of Windows 3.1 in standard mode in separate windows under a single instance of DESQview.
It was very slow compared to running on native DOS, so obviously some time partitioning shenanigans were afoot.
What about Win286/running Windows 3.1 on an 80286?
He just made statements without any backing. Pathetic.
And multitasking: only one program was active at a time (just like in Android today). When you minimized the program, it was suspended.
Plus, I really enjoy Raymond Chen’s writing style. Lastly, I want to remember the technical details, and re-reading helps with that.
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.
It was the first attempt to move game studios into Windows 3.x.
Another piece of history that will be lost as there are so few of us that remember it and it is badly documented.
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.
1. Windows 3.1 can run without DOS. For example: on top of DR DOS, an entirely independent operating system from a different vendor. And of course it also runs on top of OS/2 2.0 and above which is not remotely DOS like in structure. Now yes to be fair that is because IBM had access to the Microsoft source code for Windows 3.0 and 3.1. Even so it falsifies your statement.
2. Your claim about multitasking is wrong and it is specifically refuted in the article that you are criticising.
2a. Under Windows 3.0 and 3.1, Windows binaries multitask cooperatively, and programs can and do run in the background. You can minimise the program and it will keep working. Four example you could minimise a comms program that is doing a download of a dial-up, and keep working in some other application. Your download would continue. I used this in production from 2.01 up until Windows for Workgroups 3.11. It was Windows 3 – it was very unstable – so you have to be extremely careful with what you did, but it was possible.
2b. As the article specifically spells out, Windows 3.0 and 3.1 were able to pre-emptively multitask DOS applications. So although Windows binaries were only cooperatively multitasked, DOS binaries were pre-empted... which was necessary because MS-DOS didn't support multitasking. And just for the sake of clarity, this did not require a 386: they were able to multitask DOS apps even on 8086, although that ability wasn't much use, because you wouldn't have enough available memory on an 8086 to run two or more DOS programs at once. But you could demonstrate it with tiny DOS applications like say `pkzip`. The relevance of a 386 and 386 enhanced mode to this was memory management - Windows 3 could use V86 mode to give each DOS program 640 kB RAM.
You are mixing up the terms here.
Windows 3.1 cannot run without DOS.
Windows 3.1 can run without MS DOS.
The difference is, that you provide other DOS implementation. It cannot run if you remove it. It was not able to boot itself, the launcher itself (win.com) was DOS executable.
So it still needs DOS. I mean you cannot boot directly in win.com.
https://devblogs.microsoft.com/oldnewthing/20100517-00/?p=14...
There was a lot of HW which only had DOS drivers which were loaded prior to starting Windows. Yes, the Windows kernel took the whole thing further but it still relied on MS-DOS for some things.