cwstarblazer

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.

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.

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

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.

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.

Yet more proof, if any was needed, that C++ is a lost cause and never should've existed. Undefined behavior in C is bad enough, but apparently the C++ people decided to take it to the next level.

In the old days, C(++) had a pretty clean correspondence to assembly, and you could picture the generated assembly in your head as you went, while(1); would map pretty easily to

loop: jmp loop

Glad to see my project picking up some traction! EmuWoW is still being worked on and I have an Alpha on the way to work with.

Yeah, I do take your point, and I never denied that all of these are going to be valid consideration for some program for some customer somewhere, my main point was that in most cases, it doesn't matter. Like you said, one could probably stop there in most cases. Obviously, the needs of a program doing OCR for ancient languages is different than something spitting out and reading in text from a console or even a Win32 text entry field.

Honestly, I'm going to go against the grain here and say that 99% of the time, this is needless pedantry. Yes, these assumptions are technically wrong, but most of the time, let's be real, they're right, or else people wouldn't be able to get away with making them.

Characters are integers, that is a fact. Most of the time, they're a byte, and to be honest, English/ASCII is the most important text setup for computers and it's fine to only support that. For the niche foreign edge cases, Windows supports UCS-2.