4 ms·

> This is a major release of Windows and, similarly to the previous one [ep 10], it is not a complete operating system, but it’s simply a graphical user shell t

by ndiddy 6mo ago

> This is a major release of Windows and, similarly to the previous one [ep 10], it is not a complete operating system, but it’s simply a graphical user shell that is meant to be run on top of MS-DOS; thus, it inherently gains its limitations, albeit the developers had time to fix some things with this release, as well as add new features such as icons on the desktop and keyboard shortcuts. This is largely untrue. When Windows is running, it's about 95% of a complete operating system. MS-DOS is only used to run DOS software and for file access. Windows takes control of the memory management, process management, video hardware, system timer, keyboard, mouse, printer, serial port, etc (basically every system resource except disk I/O) while it's running. Despite how bad early Windows looks, it's doing some very impressive technical wizardry under the hood to be able to work in real mode on the 8086 and 286. It's a lot more complex than something like Mac OS 1 or GEM, and it makes sense why it kept getting delayed over and over for years. For example, they got multiple DOS programs to run simultaneously in real mode by intercepting all the DOS API calls and patching them on the fly to avoid breaking Windows. To get multitasking to work at all in 384 KB, they had to be able to dynamically load and unload chunks of programs when necessary to deal with memory pressure, and then walk all the stacks on the system and patch out any calls/returns to the unloaded code to instead call the memory manager and make it reload the code from disk. Making this transparent to software authors required a series of complicated workarounds which Raymond Chen has written about. See here if you're interested: https://devblogs.microsoft.com/oldnewthing/20110316-00/?p=11203 https://devblogs.microsoft.com/oldnewthing/20110316-00/?p=11... https://devblogs.microsoft.com/oldnewthing/20120622-00/?p=7303 https://devblogs.microsoft.com/oldnewthing/20120622-00/?p=73... https://devblogs.microsoft.com/oldnewthing/20120629-00/?p=7253 https://devblogs.microsoft.com/oldnewthing/20120629-00/?p=72... https://devblogs.microsoft.com/oldnewthing/20140103-00/?p=2173 https://devblogs.microsoft.com/oldnewthing/20140103-00/?p=21...

dcrazy 6mo ago
I would posit that Windows only became more technically sophisticated than early Mac OS with the release of Windows/386, the version of Windows 2.1 that ran multiple DOS VMs in protected mode.
- dboreham 6mo ago
  Depends how you define sophisticated. Mac used the 68k so didn't have to jump through all those hoops mentioned above.
  - dcrazy 6mo ago
    I’m distinguishing “sophistication” from “complexity”. Windows/386 is “sophisticated” in that it implements a much richer model of execution than its predecessors, with a supervising kernel and memory-protected virtual DOS machines. This is different from the complexity of programming with segmented memory, or punching through the various layers of backward compatibility that had built up even as early as the 286. Likewise, the Mac had some complexities of its own, even though the 68k wasn’t nearly as challenging to program for. Since the Toolbox shipped in ROM, they had to design syscalls (A-traps) in a way that could be patched by later versions of the system software. They soon had to work around software that wasn’t 32-bit clean when they started shipping machines with the 68020. One of the more sophisticated bits of later Mac OS was the 68k virtual machine that was used to run major chunks of the Toolbox on PowerPC Macs.
    - jasomill 6mo ago
      I remember reading the PowerPC System Software volume of Inside Macintosh[1] at the time, and what I found impressive wasn't that 68k applications ran under emulation on PowerPC, but that much of the Toolbox and System Software were also still implemented in 68k code, implemented in terms of a general mechanism that could also be used by third-party code. This came at a performance cost, of course, but I don't recall the Workgroup Server 6150 I was using at the time feeling significantly slower than my Quadra 605, though to be fair the 605 was at the very bottom end of the 040 Mac line. Then again, with the exception of a larger hard drive and bundled AppleShare software, the WGS 6150 was equivalent to the entry-level Power Mac 6100, as well. [1] https://vintageapple.org/inside_r/pdf/PPC_System_Software_1994.pdf https://vintageapple.org/inside_r/pdf/PPC_System_Software_19...
    - ndiddy 6mo ago
      The way 386 enhanced mode worked was that there was a 32-bit preemptive multitasking kernel that would run 16-bit virtual machines. The first VM ran Windows in standard mode, and the rest were the DOS VMs. This meant that Windows programs still shared an address space and were cooperatively multitasked. This is actually somewhat similar to how Apple shoehorned multiprocessor support into later versions of Classic Mac OS. The OS runs under a microkernel. There's one main thread where all the cooperative multitasking happens (anything that uses the Toolbox must run in this thread), and then both user software and the system can make new threads that get preemptively multitasked with the main thread. The main difference is that I don't believe there's a way for Windows software to make use of the preemptive scheduler (unless maybe they do something hacky with a VxD driver, but that's kind of silly).
anthk 6mo ago
Windows 3.11 can run in vanilla DOSBox. Under DOSBox-X you basically boot Windows by converting DOSBox into a PC emulator.
AshamedCaptain 6mo ago
The problem with all these arguments is that DOS extenders of the day used to do the same, or more. Do you call DOS extenders "operating systems not shells" too ? On one hand you have that the technical answer to the above question is likely "yes". DOS is so simple that any non-trivial application likely qualifies as an operating system. Implementing some kind of virtual memory support is almost a given, and process control is not unheard of. But on the other hand most people would refer to anything pre-95 as "shell" for the simple reason that it requires DOS to boot ; even when complexity-wise, 95 and later versions of 3.x are practically the same: if you call one an OS, you ought to call the other one a full OS too. So this question is on the "angels on the head of a pin"-level; but this simply means there's no answer that doesn't require a lot of nuance, and this also applies to the "it can't be a shell, it does too many things" answer.
- blisscast 6mo ago
  That's exactly what I'd say, as it still requires DOS to boot, thus another OS.

by ndiddy 6mo ago

dcrazy 6mo ago

I would posit that Windows only became more technically sophisticated than early Mac OS with the release of Windows/386, the version of Windows 2.1 that ran multiple DOS VMs in protected mode.

dboreham 6mo ago
Depends how you define sophisticated. Mac used the 68k so didn't have to jump through all those hoops mentioned above.
- dcrazy 6mo ago
  I’m distinguishing “sophistication” from “complexity”. Windows/386 is “sophisticated” in that it implements a much richer model of execution than its predecessors, with a supervising kernel and memory-protected virtual DOS machines. This is different from the complexity of programming with segmented memory, or punching through the various layers of backward compatibility that had built up even as early as the 286. Likewise, the Mac had some complexities of its own, even though the 68k wasn’t nearly as challenging to program for. Since the Toolbox shipped in ROM, they had to design syscalls (A-traps) in a way that could be patched by later versions of the system software. They soon had to work around software that wasn’t 32-bit clean when they started shipping machines with the 68020. One of the more sophisticated bits of later Mac OS was the 68k virtual machine that was used to run major chunks of the Toolbox on PowerPC Macs.
  - jasomill 6mo ago
    I remember reading the PowerPC System Software volume of Inside Macintosh[1] at the time, and what I found impressive wasn't that 68k applications ran under emulation on PowerPC, but that much of the Toolbox and System Software were also still implemented in 68k code, implemented in terms of a general mechanism that could also be used by third-party code. This came at a performance cost, of course, but I don't recall the Workgroup Server 6150 I was using at the time feeling significantly slower than my Quadra 605, though to be fair the 605 was at the very bottom end of the 040 Mac line. Then again, with the exception of a larger hard drive and bundled AppleShare software, the WGS 6150 was equivalent to the entry-level Power Mac 6100, as well. [1] https://vintageapple.org/inside_r/pdf/PPC_System_Software_1994.pdf https://vintageapple.org/inside_r/pdf/PPC_System_Software_19...
  - ndiddy 6mo ago
    The way 386 enhanced mode worked was that there was a 32-bit preemptive multitasking kernel that would run 16-bit virtual machines. The first VM ran Windows in standard mode, and the rest were the DOS VMs. This meant that Windows programs still shared an address space and were cooperatively multitasked. This is actually somewhat similar to how Apple shoehorned multiprocessor support into later versions of Classic Mac OS. The OS runs under a microkernel. There's one main thread where all the cooperative multitasking happens (anything that uses the Toolbox must run in this thread), and then both user software and the system can make new threads that get preemptively multitasked with the main thread. The main difference is that I don't believe there's a way for Windows software to make use of the preemptive scheduler (unless maybe they do something hacky with a VxD driver, but that's kind of silly).

anthk 6mo ago

Windows 3.11 can run in vanilla DOSBox. Under DOSBox-X you basically boot Windows by converting DOSBox into a PC emulator.

AshamedCaptain 6mo ago

The problem with all these arguments is that DOS extenders of the day used to do the same, or more. Do you call DOS extenders "operating systems not shells" too ? On one hand you have that the technical answer to the above question is likely "yes". DOS is so simple that any non-trivial application likely qualifies as an operating system. Implementing some kind of virtual memory support is almost a given, and process control is not unheard of. But on the other hand most people would refer to anything pre-95 as "shell" for the simple reason that it requires DOS to boot ; even when complexity-wise, 95 and later versions of 3.x are practically the same: if you call one an OS, you ought to call the other one a full OS too. So this question is on the "angels on the head of a pin"-level; but this simply means there's no answer that doesn't require a lot of nuance, and this also applies to the "it can't be a shell, it does too many things" answer.

blisscast 6mo ago
That's exactly what I'd say, as it still requires DOS to boot, thus another OS.