Software written for MS-DOS used DOS extenders as early as on PC/AT (DOS/16M), and starting from i386-based systems, DOS extenders became really widespread.
I'd think it was pretty obvious at the time that the real-mode limitations of both BIOS and MS-DOS had to be left behind sooner rather than later, and DOS extenders (however ingenious technology-wise) were no more than kludgery to bypass those limitations.
I wonder if anybody considered making a "drop-in" replacement for MS-DOS that would be a purely 32-bit protected mode OS? Of course I know about both Windows and OS/2, though I am saying "drop-in" for a reason:
- Both OS/2 and Windows had their own API and programming model that was totally different from the MS-DOS API. So one would have to spend lots of effort to port existing software. Of course it would be impossible to make the API of this imaginary OS fully compatible with the original MS-DOS & DPMI, but at least I guess one could come as close as possible.
- Both OS/2 and Windows did provide MS-DOS virtualization but that was rather a way to run several MS-DOS apps at once; an MS-DOS app would still need a DOS extender if it wanted to access more than 640K of RAM (OK it could use XMS/EMS directly but that was even more kludgery)
- Neither Windows nor OS/2 provided native direct access to video and audio hardware (at least ca. 1992-1994). There were things like WinG but again they brought a totally different programming model compared to how people worked with graphics and audio in MS-DOS.
- Not so sure about OS/2, but the Windows 3.11 32-bit disk access story was less than ideal (very picky about HDD controller hardware and geometry)
So, what exactly made the idea of such an OS infeasible?
Technology-wise, would 32-bit hardware drivers be the biggest problem? Because, kernel-wise, this imaginary OS could have been built on top of the already existing DOS extender technology, just replacing real-mode 16-bit disk access with a 32-bit protected mode counterpart, and providing some abstraction layer over lower memory allocation.
And, marketing-wise, did everyone want multitasking and GUI so much that the idea of a single-tasked OS was no longer appealing by definition?
FAR(etc.) pointers. The only trick we had was to use the extra 64k-16 from
FFFF:0000. Else we need to find 256 segments not used by BIOS (maybe
9F00are the safest
9F99). And compilers which will not do segment arithmetic.