This is taken from a post by Michael Sokolov (of Quasijarus fame), all about DPMI.

   Mark H. Wood <address@hidden> wrote:
> Which spec is that? cwsdpmi, as I recall, implements DPMI 1.0, while
> Microsoft has never gone beyond 0.9. There are significant differences
> *in the spec.s*.
Well, I have turned this semester's last paper in today, so I can spend
a few more hours enlightening the public... Warning: I am going to give a
lecture on DPMI. Feel free to skip this message, but if you do please
refrain from any further participation in the work on Lynx for DOS, since
an understanding of the material I present in this lecture is absolutely
essential to doing any work under DOS beyond 640 KB.
DPMI has been born in the fall of 1989 in a bright flash of genius of
Microsoft's Ralph Lipe. At that time there was a flourishing DOS extender
industry led by Phar Lap, Rational Systems (later Tenberry Software), and
Ergo (formerly Eclipse and A. I. Architects). A DOS extender is some kind
of software solution (they come in all sorts of flavors) that allows an
application to execute in protected mode and yet retain access to the file
system and other services provided by DOS via an API that closely resembles
that of real-mode DOS (INT 21h and such) but with pointers to buffers and
such addressing memory outside the first MB via protected-mode selectors.
DOS extenders from Phar Lap, Rational Systems, and Ergo are inherently
flawed in that they are built into apps. This has been done against all
rationale simply because the market demanded that a protected-mode apps
must not have any prerequisites and must run even in a bare environment
without any pre-existing protected-mode software. However, having a
separate DOS extender for every app is not much different from having a
separate power plant for every light bulb. Since they want to have no
prerequisites, these DOS extenders need to take the total control of the
CPU and build their own protected-mode environments. Of course, this
creates a hell of a problem when a machine IS running some protected-mode
software. In the days of Phar Lap and friends, there were two other kinds
of the latter in addition to DOS extenders: LIMulators and multitaskers.
The former are things like CEMM and EMM386 that provide LIM EMS services by
setting up a protected-mode environment and mapping some extended memory
into the UMB space. The latter provide multiple simultaneous DOS sessions
and allow the user to switch between them instantly. They do so again by
setting up a protected-mode environment and using to it manage several
different VMs. The result was that by 1989 there were three kinds of
protected-mode environments (LIMulators, multitaskers, and DOS extenders),
and all three were, oh big surprise, for the most part mutually exclusive.
There were some feeble attempts (VCPI being the primary example) to make
them live together, but they worked by making one environment totally yield
to the other, which is unacceptable for many reasons.
Microsoft has entered the protected-mode-under-DOS field in the summer
of 1988 when Murray Sargent and David Weise wrote a DOS extender for a big
DOS app called Windows. Until then this app was running in pure real mode
and was limited by the (in)famous 640 KB barrier. Jumping over this barrier
was one of the primary goals for Windows v3.00. Murray Sargent's DOS
extender did this. It was a quick-and-dirty single-app DOS extender just
like the ones from Phar Lap and others. There was a problem, however. When
all this was happening in the summer of 1988, there already was a baby
called Windows/386 v2.xx. It was another protected-mode environment
developed independently by Ralph Lipe in 1987. It was not a DOS extender,
but a multitasker, and its purpose was to manage several independent VMs,
one running Windows and all others being DOS boxes. Although there were
several VMs, each was running in V86 (real-like) mode only, and no VM had
any ability to jump over the 640 KB barrier, even though each VM had its
own 640 KB of memory.
Windows v3.00 was supposed to include both Windows/386 (so that it could
have the familiar DOS boxes) and Murray Sargent's DOS extender. There was a
problem, however. The two were mutually exclusive! It was exactly the same
eternal conflict between LIMulators, multitaskers, and DOS extenders that
the industry had been wrestling with for a couple of years by then, except
that the conflicting parties were parts of the same product! Clearly a
breath of fresh air was needed. And it came. From no one but Ralph Lipe,
the author of Windows/386. In a bright flash of genius, he realized that
building a separate DOS extender into every app, be it AutoCAD, Lotus
1-2-3, or Windows, is just as ridiculous as building a separate power plant
for every light bulb. However, getting rid of this kludge required adopting
a new industry standard. Just like in order to have the same power plant
serve everyone you have to agree upon a common standard on voltage,
waveform, and power factor, if you are going to have common protected-mode
DOS services for all apps you have to agree on the protected-mode DOS API.
A logical name for the generic API to the protected-mode DOS was DOS
Protected Mode Interface (DPMI), and it is the name that has ended up being
chosen.
The specs published by the DPMI Committee and distributed by Intel only
vaguely resemble Ralph Lipe's DPMI. The INT 31h API they describe is only
the low-level building-block portion of Ralph Lipe's DPMI. Its high-level
portion is nothing less than a functional specification for Protected Mode
DOS (hence the name). It allows one to develop an add-on to DOS or even a
new version of DOS that would have a protected-mode API directly usable by
protected-mode DOS apps without the need for separate built-in DOS
extenders. Understandably this troubled Phar Lap and others a lot, since
Ralph Lipe's DPMI makes their products unnecessary. This is the setting in
which the most unfortunate event in the history of DOS has happened. Being
too used to Microsoft's evils, the industry had failed to think the problem
through and sided against Ralph Lipe. Before I continue any further, let me
make an analogy. Suppose a group of doctors were able to cure some dreadful
disease against which there were no vaccine and to which everyone were
prone. Suppose that they charged a lot of money for curing this disease and
made a good living on it. Then suppose that some guy came up with a vaccine
that once injected totally eliminated the possibility of getting this
disease. The vaccine would solve a major health problem, but it would also
push the doctors making great money on curing the disease out of business.
What do you think is more important, sparing millions of people of a major
health problem or keeping a group of lucky doctors in business?
Unfortunately, the industry has chosen the latter. Ralph Lipe agreed not
to publicize his version of the DPMI spec and to create the so-called DPMI
Committee to write a "public" version of the spec that would please Phar
Lap and the rest of the gang. This Committee was practically headed by Bob
Moote, the vice-president and co-founder of Phar Lap and the author of
their 386|DOS Extender. It has prepared a castrated (deprived of the most
essential component) version of DPMI and released it under the name "DPMI
Version 0.9". It essentially comprises the low-level building-block portion
of True (Ralph Lipe's) DPMI. Fortunately, no committee in the world could
prevent Ralph Lipe from doing the right thing, and the Win386 component in
Windows v3.00+ implements the full True DPMI spec. As a result, DOS apps
running under its supervision (e.g., Windows itself) have immediate access
to Protected Mode DOS without built-in DOS extenders. Since this is the new
proper and vastly improved way of writing protected-mode DOS apps (sure
enough, Microsoft itself has used it in its C/C++ Compiler v7.00), Win386
rightfully does not support apps with built-in DOS extenders using kludges
like VCPI. Thus Bob Moote and his gang have made their version of DPMI a
subset of True DPMI rather than a completely different interface, so that
their DOS extenders could run under Win386.
It is a very unfortunate fact that since Ralph Lipe has agreed not to
send out copies of his True DPMI spec most people associate the name DPMI
with Bob Moote's "Committee". There were, however, a few copies of the True
DPMI spec sent out to people like Borland. It is interesting to note that
the latter company has chosen True DPMI over Bob Moote's creature for their
protected-mode DOS tools. 16-bit Borland C and Pascal compilers are
targeted for the DOS/protected-mode-DOS/Windows triple, and the protected-
mode DOS versions of the tools use nothing but True DPMI. Also Borland
includes a True DPMI implementation of its own with these compilers. Given
that copies of the True DPMI spec are out there, I'm searching for them
much like Agent Mulder is searching for the truth about extraterrestrial
life and intelligence. Fortunately Bob Moote's "Committee" has never made
DPMI a trademark and Ralph Lipe's spec has never got Microsoft's copyright
stamped on it (it was just a rough dev draft quickly typed up in WinWord,
after all), meaning that if/when I find a copy of it I can immediately put
it up on my FTP site.
Now you may ask "what is DPMI Version 1.0 then?" As I have said before,
Ralph Lipe and Bob Moote had radically different visions of DPMI, the
former seeking an interface between protected-mode DOS and its apps and the
latter seeking an interface for use by Phar Lap's DOS extenders. "DPMI
Version 0.9" has been produced perhaps in an hour by ripping out Ralph
Lipe's high-level APIs, but there are still references to it dangling
around, making it clear to anyone reading the spec that something is
obviously missing. Being dissatisfied with the fact that his ugly "DPMI
Version 0.9" still contained hints toward its original purpose and didn't
completely subvert to his ideology, he set out to write a spec that would
not contain a single word by Ralph Lipe and instead would be geared fully
toward Phar Lap's DOS extenders. The result is commonly known as "DPMI
Version 1.0". I still wonder why did Bob waste his time on writing it, as
it was clear even to a porcupine that it would never be implemented, since
its alleged purpose was light years apart from the real purpose of DPMI
(which started being accepted by the industry, partly because Microsoft and
Borland compilers used it). It is a grave mistake to treat "DPMI Version
1.0" as an improvement upon "DPMI Version 0.9", it is merely a further move
away from True DPMI.
A very unfortunate fact is that DJGPP and CWSDPMI have chosen to use Bob
Moote's lopsided idea of DPMI instead of its true nature. Certainly this is
due to DJ Delorie simply not knowing about the existence of True DPMI,
which in turn is certainly due to the scarcity of the copies of the True
DPMI spec. It is still a pity, though, that DJGPP uses only the low-level
building-block APIs that are suitable to Bob Moote's selfish interests and
builds a separate power plant for every light bulb (i.e., builds the DOS
API translation engine into every app by making it a part of the
statically-linked libc.a).
The conclusion of this lecture is that I need to continue searching for
the truth that is out there, so that I could finally bring it to light
after all these years (True DPMI: 1989, "DPMI Version 0.9": 1990, "DPMI
Version 1.0": 1991). This would mean finding a copy of the True DPMI spec,
putting it up on my FTP site, and writing a software development suite that
would produce apps for it, as well as writing a public-domain
implementation of it (to my knowledge all existing ones are commercial,
except possibly the DOS emulation under Linux).
A billion thanks for reading! If you read up to here, please drop me a
note :-).
> Stuff compiled with DJGPP works just fine for me on Win95 [...]
OK, so DJGPP is at least correct after all, although severely misguided
because of the lack of knowledge.
> [...] which is (among
> other things) a DPMI provider and certainly written by Microsoft.
The Protected Mode DOS component of Windows 95 is virtually identical to
that of Windows v3.00 and v3.1x. In all of them it is written by Ralph Lipe
and is the reference implementation of True DPMI.
> The same stuff also seems just fine using cwsdpmi.
OTOH, when I tried running a True DPMI client under CWSDPMI, it sent
about 2 KB of binary garbage to stdout and exited. Note that this client
does check for BobMootish DPMI hosts that implement only the low-level
building-block API and prints an appropriate error message if one is found,
so what I have seen indicates that CWSDPMI's implementation of the low-
level building-block API is also screwed. Well, it should be no surprise
for anyone that CWSDPMI is a specialized gadget for DJGPP and doesn't even
resemble True DPMI. If you want the latter without running Windows, your
current choices are (to my knowledge) 386Max and QEMM-386 with QDPMI. There
also is the Borland DPMI host, but it's 16-bit only. Oh, and OS/2, Windows
NT, and Novell DOS all implement True DPMI.
Sincerely,
Michael Sokolov
Phone: 440-449-0299
ARPA Internet SMTP mail: address@hidden
P.S. It is really swinish for me to be bashing Bob Moote, since he has
once done me a significant personal favor, but I simply can't put my
personal interests and obligations above my duty to the industry.
P.P.S. A lot of my knowledge of this subject has been derived from
direct phone conversations with the key players in this field, including
Murray Sargent, Ralph Lipe, Bob Moote, and Dan Spear (author of QEMM-386
and QDPMI).