Various virtualization fun, including games & productivity!
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).