21–30 of 45 posts
It was very slow compared to running on native DOS, so obviously some time partitioning shenanigans were afoot.
He just made statements without any backing. Pathetic.
> Myth: Windows 3.1 was just a shell on top of DOS He just made statements without any backing. Pathetic.
> Myth: Windows 3.1 was just a shell on top of DOS He just made statements without any backing. Pathetic.
Are there specific claims you would dispute?
And multitasking: only one program was active at a time (just like in Android today). When you minimized the program, it was suspended.
Earlier quoted context omitted.
Are there specific claims you would dispute?
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.
Earlier quoted context omitted.
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.
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.
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.
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
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.
In spite of Microsoft's best efforts, Windows 3.1 ran fine on top of DR-DOS or Novell DOS.
https://www.geoffchappell.com/notes/windows/archive/aard/drd...