5 ms·

Myth: Windows 3.1 was just a shell on top of DOS

55 points by CA0DA 3y ago

https443 3y ago
I always thought this was true.
- parl_match 3y ago
  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.
  - stevefan1999 3y ago
    It can be seen as an exokernel
Dwedit 3y ago
What about Windows running in Real Mode or Standard Mode?
- lproven 3y ago
  It can still multitask DOS programs; the problem is that it can only multitask all of them within a single 640 kB memory box... so you can't run many.
- Narishma 3y ago
  Real Mode was dropped in 3.1 and Standard Mode in 3.11
piperswe 3y ago
Windows 3.x and 9x are "shells on top of DOS" the same way that Linux can be a "shell on top of DOS": https://github.com/haileys/doslinux https://github.com/haileys/doslinux
- hulitu 3y ago
  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.
  - helf 3y ago
    [dead]
  - Narishma 3y ago
    That's exactly how I ran Linux on my first PC. It didn't support my sound card, so I had to first boot DOS with the sound card drivers which provided a SoundBlaster compatibility layer, then started Linux from DOS.
JoeAltmaier 3y ago
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).
- musicale 3y ago
  > 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?
  - JoeAltmaier 3y ago
    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.
    - musicale 3y ago
      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.
stuaxo 3y ago
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)
- lproven 3y ago
  There are two projects which did that. 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.
  - signaru 3y ago
    Could what winevdm be doing on 64bit Windows be considered the same? (I find it very interesting but don't know enough to tell if it should be considered an example)
  - hollandheese 3y ago
    That was also how OS/2 2.0+ ran Windows programs.
troad 3y ago
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?)
- Hackbraten 3y ago
  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=14013 https://devblogs.microsoft.com/oldnewthing/20100517-00/?p=14... [1] https://devblogs.microsoft.com/oldnewthing/20140912-00/?p=44083 https://devblogs.microsoft.com/oldnewthing/20140912-00/?p=44... [2] https://devblogs.microsoft.com/oldnewthing/20211129-00/?p=105979 https://devblogs.microsoft.com/oldnewthing/20211129-00/?p=10... I keep coming back for those three articles.
  - phibz 3y ago
    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.
    - Hackbraten 3y ago
      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.
frank_bb 3y ago
[dead]
Aleklart 3y ago
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
musicale 3y ago
In spite of Microsoft's best efforts, Windows 3.1 ran fine on top of DR-DOS or Novell DOS.
- lproven 3y ago
  Here is the personal account of the chap that discovered and proved, in court, how Microsoft attempted to make this fail with fake error messages. https://www.geoffchappell.com/notes/windows/archive/aard/drdos/index.htm https://www.geoffchappell.com/notes/windows/archive/aard/drd...
musicale 3y ago
> 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?
- rahimnathwani 3y ago
  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'.
  - lproven 3y ago
    That's not right... see my reply above.
nurettin 3y ago
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.
hulitu 3y ago
> Myth: Windows 3.1 was just a shell on top of DOS He just made statements without any backing. Pathetic.
- aww_dang 3y ago
  Are there specific claims you would dispute?
  - hulitu 3y ago
    Because of the low quality, normally no. But since you asked: DOS was not a bootloader for Win3.1. Win 3.1 cannot run without DOS. There were TSRs which were loaded in DOS which interacted with Win3.1. And multitasking: only one program was active at a time (just like in Android today). When you minimized the program, it was suspended.
    - zamalek 3y ago
      You've just done the same thing as the author of the article, only there are Raymond Chen references elsewhere in this thread that contradict your statements.
      - hulitu 3y ago
        Raymond Chen stated that there were different OSs running inside win3.1. https://devblogs.microsoft.com/oldnewthing/20100517-00/?p=14013 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.
        zamalek 3y ago
        TSRs (which amount to "DOS drivers") were notoriously flaky with Win3.1. Some requiring installation prior, some requiring installation inside of a guest DOS shell, some just not working at all. More reliable ones (such as MSCDEX) were explicitly compatible with Win3.1 and its IDT. https://www-user.tu-chemnitz.de/~heha/vxd/vxd.htm https://www-user.tu-chemnitz.de/~heha/vxd/vxd.htm
luckystarr 3y ago
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.
wzdd 3y ago
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.

55 points by CA0DA 3y ago

https443 3y ago

I always thought this was true.

parl_match 3y ago
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.
- stevefan1999 3y ago
  It can be seen as an exokernel

Dwedit 3y ago

What about Windows running in Real Mode or Standard Mode?

lproven 3y ago
It can still multitask DOS programs; the problem is that it can only multitask all of them within a single 640 kB memory box... so you can't run many.
Narishma 3y ago
Real Mode was dropped in 3.1 and Standard Mode in 3.11

piperswe 3y ago

Windows 3.x and 9x are "shells on top of DOS" the same way that Linux can be a "shell on top of DOS": https://github.com/haileys/doslinux https://github.com/haileys/doslinux

hulitu 3y ago
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.
- helf 3y ago
  [dead]
- Narishma 3y ago
  That's exactly how I ran Linux on my first PC. It didn't support my sound card, so I had to first boot DOS with the sound card drivers which provided a SoundBlaster compatibility layer, then started Linux from DOS.

JoeAltmaier 3y ago

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).

musicale 3y ago
> 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?
- JoeAltmaier 3y ago
  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.
  - musicale 3y ago
    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.

stuaxo 3y ago

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)

lproven 3y ago
There are two projects which did that. 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.
- signaru 3y ago
  Could what winevdm be doing on 64bit Windows be considered the same? (I find it very interesting but don't know enough to tell if it should be considered an example)
- hollandheese 3y ago
  That was also how OS/2 2.0+ ran Windows programs.

troad 3y ago

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?)

Hackbraten 3y ago
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=14013 https://devblogs.microsoft.com/oldnewthing/20100517-00/?p=14... [1] https://devblogs.microsoft.com/oldnewthing/20140912-00/?p=44083 https://devblogs.microsoft.com/oldnewthing/20140912-00/?p=44... [2] https://devblogs.microsoft.com/oldnewthing/20211129-00/?p=105979 https://devblogs.microsoft.com/oldnewthing/20211129-00/?p=10... I keep coming back for those three articles.
- phibz 3y ago
  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.
  - Hackbraten 3y ago
    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.

frank_bb 3y ago

[dead]

Aleklart 3y ago

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

musicale 3y ago

In spite of Microsoft's best efforts, Windows 3.1 ran fine on top of DR-DOS or Novell DOS.

lproven 3y ago
Here is the personal account of the chap that discovered and proved, in court, how Microsoft attempted to make this fail with fake error messages. https://www.geoffchappell.com/notes/windows/archive/aard/drdos/index.htm https://www.geoffchappell.com/notes/windows/archive/aard/drd...

musicale 3y ago

> 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?

rahimnathwani 3y ago
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'.
- lproven 3y ago
  That's not right... see my reply above.

nurettin 3y ago

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.

hulitu 3y ago

> Myth: Windows 3.1 was just a shell on top of DOS He just made statements without any backing. Pathetic.

aww_dang 3y ago
Are there specific claims you would dispute?
- hulitu 3y ago
  Because of the low quality, normally no. But since you asked: DOS was not a bootloader for Win3.1. Win 3.1 cannot run without DOS. There were TSRs which were loaded in DOS which interacted with Win3.1. And multitasking: only one program was active at a time (just like in Android today). When you minimized the program, it was suspended.
  - zamalek 3y ago
    You've just done the same thing as the author of the article, only there are Raymond Chen references elsewhere in this thread that contradict your statements.
    - hulitu 3y ago
      Raymond Chen stated that there were different OSs running inside win3.1. https://devblogs.microsoft.com/oldnewthing/20100517-00/?p=14013 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.
      - zamalek 3y ago
        TSRs (which amount to "DOS drivers") were notoriously flaky with Win3.1. Some requiring installation prior, some requiring installation inside of a guest DOS shell, some just not working at all. More reliable ones (such as MSCDEX) were explicitly compatible with Win3.1 and its IDT. https://www-user.tu-chemnitz.de/~heha/vxd/vxd.htm https://www-user.tu-chemnitz.de/~heha/vxd/vxd.htm

luckystarr 3y ago

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.

wzdd 3y ago

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.