All in all, this was a very fun project to do, as Windows/386 was really lacking the kind of in-depth analysis that its successors got. I hope to update the project in the future, as well as maybe pivot to something like OS/2.
At this point, it starts WIN86.COM (loaded by WIN386.EXE) to start a real-mode copy of Windows in the first VM, otherwise known as the “System VM”.
The DOS-based Windows lineage is definitely very interesting to study and a large contrast to more "normal" operating systems like Linux or NT, because they're actually hypervisors running a VM; and their whole userspace is essentially based around an extended DOS (protected mode) application.
From there, it checks if the resident protected-mode software is a memory manager that it recognizes
What's noteworthy is that EMM386 is also a hypervisor, albeit a very thin one. One could imagine an alternate reality in which x86 gained full virtualisation extensions earlier, causing the hypervisor model to be taken even further and creating a bigger architecture gap between Windows and other OSes.
What's noteworthy is that EMM386 is also a hypervisor, albeit a very thin one.
It is absolutely noteworthy, and something I touch on in my article; Windows/386 was heavily based on EMM386's code, both for the EMS emulation as well as for the V86 monitor itself. EMM386 was the starting point for Windows/386, and CEMM/EMM386 are special because they know how to transfer their state into Windows/386 via GEMMIS aka the Windows/386 Paging Import Specification.
After a conversation with Ralph Lipe, designer of Windows/386, he revealed to me that Windows/386 was so thin of a layer over EMM386 (being a slightly more heavy hypervisor but not by much) that it had no scheduler for 32-bit code; there was one thread of execution in the VDMM that IRET'd into VMs, but each VM did not also have an independent Ring 0 protected-mode context like in Windows version 3.0.
One could imagine an alternate reality in which x86 gained full virtualisation extensions earlier, causing the hypervisor model to be taken even further and creating a bigger architecture gap between Windows and other OSes.
Worthy reading would be: https://www.os2museum.com/wp/an-old-idea-x86-hardware-virtua...
I read it about halfway through before the kiddos started screaming. Overall very good.
One nitpick: maybe provide just a bit more detail regarding how your/your friend came to some of the conclusions. It isn't because I don't believe anything, however I'm just an old timer (somewhat, elder millennial) who likes to know how things work/how you guys game to the conclusions you did. Not a full rundown, obviously, however I did see quite a few assumptions that were only partially explained. Seems to be a good read, however, and I'll finish it tomorrow.
What sort of conclusions do you want more explanation for? If you're curious about, for example, how I determined that the Windows/386 executable format was in the Xenix x.out format, I didn't. Geoff Chappell examined/disassembled the WIN386.EXE loader to see how its loader code lined up with the contents of the WIN386.386 file, and Michal Necasek of the OS/2 Museum immediately noticed obvious similarities between the format described by Chappell and the Xenix x.out format. After examining the WIN386.386 file, he found that it did indeed line up with the x.out format. It is worth noting that this specific finding was a late edition to the article; I send a draft version of parts of it to Necasek who informed me of this fact, so I rushed an edited version to Neozeed hours before he posted the article on his Patreon (which occurred a few days before the posting to the blog). As it happens, Necasek had noted that Windows/386 used the x.out format in a comment about a year ago on one of his old articles about Windows/386, though I hadn't seen it.
If you're curious about anything else, I'm happy to elaborate.
I programmed a lot of real mode x86 assembly under DOS in the late 80s. I didn't have a ton of money, was a kid, and wasn't located close to any tech business (rural western Ohio). The bits and pieces I saw about Windows development on BBSs and in magazines were arcane and strange. I wondered how it all worked but, frustratingly, couldn't get my hands on the documentation or development tools.
Reading articles like this are fun glimpses into a world I dreamt about in my youth. It's a ton of fun, even if I'm probably never going to write any code related to it.
There was a lot of cleverness in the DOS-based Windows family, especially in dealing with constrained resources. I'm not sad it died out (because it lacked the overarching "real operating system" design), but I'm pleased to see it getting brought out into the open.
Windows development (especially on 16-bit Windows) was weird and strange, but the VxD layer comprising the enhanced mode 386 components were even more arcane, originally written in assembly-only and virtually undocumented. While Windows 3.0 (and especially 3.1 and 95) had their VxD layers heavily documented by both Microsoft and third parties, the 386 components of Windows/386 are virtually undocumented outside of (ignoring modern research like my own work) sporadic references in DDKs for later versions of Windows (i.e. the Windows 3.0 Virtual Device Adaptation Guide that I mentioned) and the now-lost Windows/386 OEM binary adaptation kit.
Programming directly under the DOS environment certainly is a lot of fun, and there absolutely was a lot of cleverness in the DOS-based Windows family. People rag on it for being unstable and whatnot, but the truth is that it simply was the best compromise OS at the time. It was not as stable as NT, but it ran a lot faster on much slower hardware. It made compromises, but it made the right compromises for most people. By the time Windows XP came out, the market had changed such that the compromises were no longer necessary.
Ha! Funnily enough the VxD layer was the part I was most interested in. I didn't "get" protected mode until I was older, so that didn't help my efforts.
I definitely enjoy and appreciate the work you're doing.
Absolutely, the VxD layer has also been of particular interest to me. Unfortunately, much of that VxD layer is poorly-documented. Much of what comprises the Win32 subsystem in Windows 95 (i.e. VWIN32) is not well documented, nor is the equivalent VxD in Win32s. VFLATD, originally a part of Video for Windows, was to my knowledge not documented until Windows 95.
All in all, this was a very fun project to do, as Windows/386 was really lacking the kind of in-depth analysis that its successors got. I hope to update the project in the future, as well as maybe pivot to something like OS/2.
I love this, great work. Might have more to say once I'm through reading it.
OS/2 would be amazing
thank you, this was a very interesting read!
At this point, it starts WIN86.COM (loaded by WIN386.EXE) to start a real-mode copy of Windows in the first VM, otherwise known as the “System VM”.
The DOS-based Windows lineage is definitely very interesting to study and a large contrast to more "normal" operating systems like Linux or NT, because they're actually hypervisors running a VM; and their whole userspace is essentially based around an extended DOS (protected mode) application.
From there, it checks if the resident protected-mode software is a memory manager that it recognizes
What's noteworthy is that EMM386 is also a hypervisor, albeit a very thin one. One could imagine an alternate reality in which x86 gained full virtualisation extensions earlier, causing the hypervisor model to be taken even further and creating a bigger architecture gap between Windows and other OSes.
What's noteworthy is that EMM386 is also a hypervisor, albeit a very thin one. It is absolutely noteworthy, and something I touch on in my article; Windows/386 was heavily based on EMM386's code, both for the EMS emulation as well as for the V86 monitor itself. EMM386 was the starting point for Windows/386, and CEMM/EMM386 are special because they know how to transfer their state into Windows/386 via GEMMIS aka the Windows/386 Paging Import Specification.
After a conversation with Ralph Lipe, designer of Windows/386, he revealed to me that Windows/386 was so thin of a layer over EMM386 (being a slightly more heavy hypervisor but not by much) that it had no scheduler for 32-bit code; there was one thread of execution in the VDMM that IRET'd into VMs, but each VM did not also have an independent Ring 0 protected-mode context like in Windows version 3.0.
One could imagine an alternate reality in which x86 gained full virtualisation extensions earlier, causing the hypervisor model to be taken even further and creating a bigger architecture gap between Windows and other OSes. Worthy reading would be: https://www.os2museum.com/wp/an-old-idea-x86-hardware-virtua...
I read it about halfway through before the kiddos started screaming. Overall very good.
One nitpick: maybe provide just a bit more detail regarding how your/your friend came to some of the conclusions. It isn't because I don't believe anything, however I'm just an old timer (somewhat, elder millennial) who likes to know how things work/how you guys game to the conclusions you did. Not a full rundown, obviously, however I did see quite a few assumptions that were only partially explained. Seems to be a good read, however, and I'll finish it tomorrow.
What sort of conclusions do you want more explanation for? If you're curious about, for example, how I determined that the Windows/386 executable format was in the Xenix x.out format, I didn't. Geoff Chappell examined/disassembled the WIN386.EXE loader to see how its loader code lined up with the contents of the WIN386.386 file, and Michal Necasek of the OS/2 Museum immediately noticed obvious similarities between the format described by Chappell and the Xenix x.out format. After examining the WIN386.386 file, he found that it did indeed line up with the x.out format. It is worth noting that this specific finding was a late edition to the article; I send a draft version of parts of it to Necasek who informed me of this fact, so I rushed an edited version to Neozeed hours before he posted the article on his Patreon (which occurred a few days before the posting to the blog). As it happens, Necasek had noted that Windows/386 used the x.out format in a comment about a year ago on one of his old articles about Windows/386, though I hadn't seen it.
If you're curious about anything else, I'm happy to elaborate.
I programmed a lot of real mode x86 assembly under DOS in the late 80s. I didn't have a ton of money, was a kid, and wasn't located close to any tech business (rural western Ohio). The bits and pieces I saw about Windows development on BBSs and in magazines were arcane and strange. I wondered how it all worked but, frustratingly, couldn't get my hands on the documentation or development tools.
Reading articles like this are fun glimpses into a world I dreamt about in my youth. It's a ton of fun, even if I'm probably never going to write any code related to it.
There was a lot of cleverness in the DOS-based Windows family, especially in dealing with constrained resources. I'm not sad it died out (because it lacked the overarching "real operating system" design), but I'm pleased to see it getting brought out into the open.
Windows development (especially on 16-bit Windows) was weird and strange, but the VxD layer comprising the enhanced mode 386 components were even more arcane, originally written in assembly-only and virtually undocumented. While Windows 3.0 (and especially 3.1 and 95) had their VxD layers heavily documented by both Microsoft and third parties, the 386 components of Windows/386 are virtually undocumented outside of (ignoring modern research like my own work) sporadic references in DDKs for later versions of Windows (i.e. the Windows 3.0 Virtual Device Adaptation Guide that I mentioned) and the now-lost Windows/386 OEM binary adaptation kit.
Programming directly under the DOS environment certainly is a lot of fun, and there absolutely was a lot of cleverness in the DOS-based Windows family. People rag on it for being unstable and whatnot, but the truth is that it simply was the best compromise OS at the time. It was not as stable as NT, but it ran a lot faster on much slower hardware. It made compromises, but it made the right compromises for most people. By the time Windows XP came out, the market had changed such that the compromises were no longer necessary.
Ha! Funnily enough the VxD layer was the part I was most interested in. I didn't "get" protected mode until I was older, so that didn't help my efforts.
I definitely enjoy and appreciate the work you're doing.
Absolutely, the VxD layer has also been of particular interest to me. Unfortunately, much of that VxD layer is poorly-documented. Much of what comprises the Win32 subsystem in Windows 95 (i.e. VWIN32) is not well documented, nor is the equivalent VxD in Win32s. VFLATD, originally a part of Video for Windows, was to my knowledge not documented until Windows 95.
[dead]