I’ve also been curious about the inner-workings of Windows/386 for a long time, hence why I decided to dive right into it. What you say bout OS/2’s Win32s implementation is absolutely right, and also applies to the DOSEMU code that jschwart sent in here.

I’m also pretty sure that even if Windows was running in Standard Mode, 32-bit software for Windows 3.1 (including Watcom’s Win386-based stuff) *should* still work as long as the DPMI host is a 32-bit DPMI host. DOSX wasn’t (even if acting as a VCPI client under a 386 memory manager), but other DPMI servers like Quarterdeck’s were, even though they didn’t implement any of the VxD services. Windows itself is still a 16-bit DPMI client, though.

We also more-or-less did get a 32-bit protected-mode DOS, just with a few asterisks. If you’re talking about an OS that does multitasking and has 32-bit int 21h, we basically got that in Windows 95 (and to a lesser degree in earlier versions too). Obviously you got the GUI too (though MS did have an internal character mode task switcher running in the System VM), but you got most of the building blocks of it. The problem is that people didn’t just want a 32-bit protected-mode DOS.

People wanted inter-process communication (pipes and even advanced data exchange stuff like OLE), people wanted threads, people wanted GUIs. And people wanted a C-callable dynamically-linked API, not some baroque assembly interrupt-driven thing. OS/2 basically tried to fulfill that vision of taking the “spirit” of DOS into the protected-mode dynamically-linked multithreaded world, and then added a GUI on top.

Taking DOS verbatim and adding the bare minimum to make it work in protected-mode just isn’t all that compelling.

All they were missing was Raymond Chen’s character-mode task switcher.

A note about OS/2’s implementation of Windows 386 Enhanced Mode (“Win-OS/2”)… it indeed took the approach of having a DPMI server which provided the same services that 386 Enhanced Windows would also provide, including the various VxDs. This had the unfortunate side effect that you couldn’t load generic VxDs into it, although you could provide a 32-bit OS/2 VDD which could provide VxD callbacks, which is exactly what the Win32s support for OS/2 did. Win-OS/2 had a few minor changes to KRNL386 and friends (basically to avoid loading VxDs); the “OS/2 for Windows” release used the release version of Windows binaries but hot patched them to the same effect.

This meant most 32-bit software for Windows 3.1 would work (basically anything that used 32-bit DPMI, which included stuff like Watcom’s 32-bit “Windows extender”), but anything VxD based was a no-go. This wasn’t much of a limitation. There was some scanner software I couldn’t upgrade to because the upgrade was VxD based.

It’s interesting that we got very close to having a true 32-bit protected mode DOS, and we didn’t end up getting there because the DOS extender vendors didn’t want Microsoft to release that. It’s not hard to imagine a world in which a DOS 5.00 or 6.x release included a 32-bit full featured DPMI host and a few VxDs, and Windows just ran as a happy client under that; instead, the closest you could get to that was rather messy piles of stuff like Netroom.

As far as I know, OS/2 basically uses this approach to run Windows. At first, I think it could only run standard-mode Windows, but gained support for things like Win32s by essentially implementing the Win32s VxD services into the MVDM.

Many thanks for your elaboration. I understand now that multiple DPMI hosts are going further than just the DPMI spec to handle Windows 3.x enhanced mode. That was not entirely clear to me so I was a bit surprised when you mentioned enhanced mode would not be possible with an alternative DPMI host.
I am curious now how OS/2 is handling this when running Windows 3.x.

From Jesus Lopez’s post, it would seem interesting to learn what Borland did with it’s DPMI host. Possibly Merge/Win4Lin also is using an alternative implementation for some aspects.

I rember crisply that the Borland 32 bits compiler toolchain included a DPMI host executable that allowed to launch win9x invoking one of the *386.exe (krnl386?) from the shell bypassing totally win.com.

KRNL286/386 is a bit more nuanced… on Windows 3.0, KRNL286 is used for Standard Mode on all processors (and DOSX.EXE – the 80286 DOS Extender – starts it already in protected-mode) while KRNL386 is used for Enhanced Mode. They’re built mostly from the same code, but KRNL386 has some 80386-specific code including being able to allocate selectors >64K. On Windows 3.1, KRNL286 is used for 80286 processors (and DOSX switches back to real-mode before loading KRNL286, with KRNL286 using the DPMI real->protect mode switch entry point just like KRNL386) while KRNL386 is used for 80386 processors (even in Standard Mode).
More to your point, those DPMI hosts you mention do not implement support for loading arbitrary VxDs like you’d be able to do in Windows 3.x/9x. Rather, they hardcode in support for the services provided by a handful of VxDs (for instance, DOSEMU implements the services provided by the VxD used by Win32s to allow Win32s to run, but it isn’t actually running the original Win32s VxD). Theoretically, you could implement all of the VxD services needed to launch Windows 9x, but it would be a lot of work. Alternatively, you could implement a VxD loader, but at that point, you’re not just running Windows enhanced mode under an alternative DPMI host, you’re cloning the virtual machine manager.

Many thanks for your response!

I have to admit. These modes are always somewhat confusing for me. There is win/s and win/3 for standard and enhanced mode, but at one point I understood that there is also another difference (krnl286/krnl386 related I think).

At least there are alternative DPMI hosts that can run win/3 but indeed they are also implementing VxD related things in their DPMI host:
https://github.com/dosemu2/dosemu2/blob/devel/src/dosext/dpmi/vxd.c
https://github.com/Baron-von-Riedesel/HX/blob/master/Src/HDPMI/VXD.ASM
And DPMIONE seems to have attempted Windows 9x:
https://github.com/sudleyplace/DPMIONE/issues/1#issuecomment-596798294

So maybe they are not just DPMI hosts as they go beyond the specified DPMI by implementing VxDs? Or would you not refer to win/3 as specifically 386 Enhanced Mode? Thanks in advance for your response!!