I'd think it was pretty obvious at the time that
the real-mode limitations of both BIOS and MS-DOS
Real-mode limitations are not of BIOS or MS-DOS.
Real-mode uses a 16bit addressing + segmentation,
which gives 20bit addressing at total (+HMA), and that
allows you to access 1Mb of memory in theory, and
640K (+UMA) on PCs. Given that
the amounts of memory quickly grown over 1Mb,
that addressing model started to represent the
limitation by its inability to access whole memory.
To overcome that limitation, your program needs
to be re-compiled for different addressing model.
The role of DOS extender in that process is explained
and DOS extenders (however ingenious technology-wise)
were no more than kludgery to bypass those limitations.
The primary goal of the DOS extenders was to minimize
the porting efforts of the DOS software authors, when
they wanted to switch to protected-mode addressing
from real-mode addressing. Extenders usually were shipped
together with the compiler tool-chains (eg Borland C,
Watcom C), and were allowing to re-compile a well-written
C program for protected mode without any modifications.
After such re-compilation, the former 16bit pointers
were turning into 32bit ones, so even without a single
change, the program could already address much more
memory than before.
You could, of course, re-compile for win32, rather
than for a DOS extender. The aforementioned compilers
offered such option too. But the amount of porting efforts
would then be much bigger. So the DOS extenders were
just a part of a porting layer, and nothing more.
The slightly paradoxical
situation happened because there was no DirectX or
alike API for graphics on PCs yet, so the best
graphics libraries were exactly those ported to
prot mode with the DOS extenders. That led to the
rapid development of DOS extenders for a short while,
as if they were a thing on their own, rather than
just a cludgy porting layer. But the development
of DOS extenders dropped almost immediately with
the appearance of DirectX.
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. There are at least the following ways of
- Make a single-tasking protected mode OS that
gives a direct hardware access for the DOS programs.
A few examples were already pointed out, let me
just add FreeDOS-32 to the list.
- Make a multi-tasking OS with DOS VM (Windows, OS/2).
- Make an OS+DOS extender+compiler tool-chain such
that you can re-compile your DOS program for that
OS with minimal porting efforts. This probablly doesn't
classify as a "drop-in" replacement though.
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.
There exist PDOS/386
that implements a "theoretical 32-bit MSDOS API"
(citing their site). So maybe this is what you are
looking for, but you'd need to port your program to
that API in order for it to work there. The VM-based
solutions, OTOH, allow you to run the DOS programs
as they are, without any porting.
an MS-DOS app would still need a DOS extender if it
wanted to access more than 640K of RAM
As was already said, this is a limitation of real-mode
addressing model, i.e. the hardware limitation in CPU.
You need to re-compile your program, and that may or
may not require a DOS extender - depending on how many
porting efforts you are going to spend.
So, what exactly made the idea of such an OS infeasible?
If you mean a single-tasking DOS-compatible protected-mode
OS, then, despite many examples of such OSes, no one
uses them today. Multitasking OSes have both the DOS VM
for running unmodified DOS apps concurrently, and the
DOS extenders to run the "re-compiled versions" of them.
They also offer stability, so that you can make sure
no DOS app can hang or harm any other DOS or native
process within that OS.
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.
That's a pretty good description of windows-95 actually.
It is built around the DOS extender technology, it uses
int21 internally quite a lot, and if you disable some
32bit driver, the calls to it would be thunked to
real-mode bios. So you may actually think of windows-95
as a very sophisticated DOS extender, with win32 API
implemented on top.
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?
Given that multitasking OSes provide both DOS VM
and DOS extender compatibility (DPMI) - yes. All
the possible needs are covered and no one needs
a single-tasking OS today. And given your desire
to run the DOS programs with the direct hardware
access, such OS will also be unstable and insecure,
and any DOS app can wipe your entire HDD under such OS.
Maybe you can provide more details on what exactly
problem you want to solve. Then perhaps there would
be the more concrete pointers to the existing solutions.