This is glib to the point of being misinformation in the other direction.
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.
It was not just a shell, but all other stuff is presented like microsoft sales memo.
It had basic supervisor code that used intel v86 in protected mode and you can hang whole system with single call anytime. Guess what else can do it - Novell DOS 7.
Win32s was much more of OS than windows 3.1
DOS 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 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).
This 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?)
MS-DOS was not really what people would today consider to be a "true" kernel, as it didn't implement any sort of access controls, boundaries, or other process management functionality. It was more of a set of shared libraries, and also included some standards such as a file system, and program loader format.
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.
I wonder if anyone has managed to run windows apps in seperate vms just like the dos apps were (could you even start Windows in standard mode in one somehow)
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.
As a teen I was surprised that I could run multiple pascal programs (one reading COM and the other reading LPT) at the same time while within the win16 environment.
It was very slow compared to running on native DOS, so obviously some time partitioning shenanigans were afoot.
Back in the 90s I found out that when you loaded Windows from DOS, performance of many DOS programs actually improved as compared to them running under DOS directly. This alone contradicts the "shell" theory.
> 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'.
Not really. Linux can initialize HW itself. Win3.1 and sometimes 95 relied on DOS to load drivers for some perpherals (Sound cards for example) because there were no Windows drivers available.
wzdd|2 years ago
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.
Aleklart|2 years ago
JoeAltmaier|2 years ago
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).
musicale|2 years ago
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?
troad|2 years ago
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?)
Hackbraten|2 years ago
- 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.
musicale|2 years ago
lproven|2 years ago
https://www.geoffchappell.com/notes/windows/archive/aard/drd...
https443|2 years ago
parl_match|2 years ago
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.
stuaxo|2 years ago
lproven|2 years ago
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.
Dwedit|2 years ago
lproven|2 years ago
Narishma|2 years ago
nurettin|2 years ago
It was very slow compared to running on native DOS, so obviously some time partitioning shenanigans were afoot.
luckystarr|2 years ago
musicale|2 years ago
What about Win286/running Windows 3.1 on an 80286?
rahimnathwani|2 years ago
hulitu|2 years ago
He just made statements without any backing. Pathetic.
aww_dang|2 years ago
piperswe|2 years ago
hulitu|2 years ago
frank_bb|2 years ago
[deleted]