The article mentions those at the bottom: "And that’s it for today folks. I intentionally did not touch on DPMI—the technology that truly allowed DOS applications to break free from the 1 MB memory limitation—because I’m saving that for the next article. So, make sure to come back for more!"
[Original author here.] Exactly! That (DPMI) is the thing I originally wanted to talk about but I realized I had to clarify many more thoughts first! And I still have to do the research on DPMI to be able to talk about it :)
I was almost amazed when instead of launching windows 3.1 running win.com one could run Borland DPMI host (that they used in their own 32-bit compiler toolchain), that stayed resident offering its API, and then one could run windows' KRNL386.EXE, that hooked with the DPMI host and booted windows.
None concrete I can think about, apart from understanding better the innards of windows boot with a whacky experiment. DPMI was an open spec, so this validated that in principle you could write your own DPMI host to make windows think it was running on top of a protected mode whose view to clients you could control and customize. But again can't answer to what avail.
CauseWay DOS Extender was released open source to public domain in 2000, and the source is on GitHub, if you're curious about the implementation. It supports builtin EXE (LE) packing as well.
It would be interesting to understand the Quarterdeck products and how they fit together: the separation between QEMM and QDPMI, and how DESQview worked to enhance DOS with multitasking.
DOS/4GW was memorable because it advertised itself while loading games made with it, usually late 386/486 era 32-bit games from before gaming on Windows had its act together.
Phar Lap was more ubiquitous throughout the 286 and 386 DOS days. Microsoft distributed a light version of it with their compiler for a while.
They also had DOS/16M which targeted 286 protected mode. The company I worked for used it when moving the Clipper programming language to protected mode.
The big problem is that 64-bit x86 long mode removes the V86 mode that made DOS 386 memory managers possible.
This is why the DOSemu project has been doing a multi-year rewrite: to create a new, full-VM-based DOSemu2 that can run DOS without emulation on x86-64 machines.