Review of DPMI Serving Software for DosLynxP

The DOS Protected Mode Interface (DPMI) specification has been around for almost as long as the Internet and its Web. It came about, in the very late '80s. When some of the largest PC businesses finally came to grips with the issue of how to adapt or extend DOS to take advantage of the Protected Mode offered in the 80286 and following 'x86 family microprocessors. So, some of the software mentioned here is as old as the Internet. However, one of the better entries is still being perfected. I think that testifies to the DPMI specification's success.

The DosLynx 16 bit Protected Mode version (DosLynxP) was brand new in 2005. When I started work on it, I thought it would suffice to wave my hand and tell potential DosLynxP users to go get a DPMI server for their system. Now, I've seen that the situation is a little too complicated for that. Because, in a number of cases, the successful DPMI serving software has been released as just a part of an expensive commercial package. QEMM and the Borland compilers provide examples. As often happens, however, a free offering that's also available works as well or better, with DosLynxP, as all the rest!

Another complication is that many of the available DPMI servers support only 16 bit applications. Or, only 32 bit applications. Though, some do support both. But, those limitations aren't always apparent from their names. Being a 16 bit application, DosLynxP can't work with a DPMI server that supports only 32 bit applications. I won't mention many of those. But, I'll list at least one popular one that doesn't have a revealing name.

So, here are two lists. The first is to let you know what it is that you need to look for. The second is to let you know what you don't need to waste your time with. The DPMI servers that DosLynxP likes all work pretty well. The others aren't usable at all. So, the two lists are given in alphabetical order by the author's or publisher's names.

DPMI Servers That DosLynxP Likes

Borland's DPMI16BI.OVL

Borland first released DPMI16BI.OVL, along with DPMIINST.EXE, DPMILOAD.EXE, and DPMIRES.EXE, in their C/C++ v3.x compiler packages, in 1992. DPMIINST provides for updating a hardware database included within DPMI16BI.OVL. It is said that you probably won't need to use DPMIINST unless you have an unusual '286 based system. This package may be your best bet if you do have such a system. To activate this package, you simply command: DPMIRES. When you're done with it, command: EXIT, to have it leave memory, if you like. I've found that I need to do this after each run of DosLynxP. So, I've added the needed DPMIRES and EXIT commands to a version of DOSLYNXP.BAT that I use for testing with DPMI16BI.OVL. As an early version of DPMILOAD.EXE had to be updated, you will do best to look for the v3.1 edition of this package. I have tested DosLynxP with this package on systems starting with Willy, my '386 based Zenith system, with only 4 MB of RAM.

 

Borland released an updated DPMI16BI.OVL, along with RTM.EXE and RTMRES.EXE, in their Pascal v7.x compiler packages, in 1993. The DPMI16BI.OVL in these packages has an expanded hardware database. This later DPMI16BI.OVL works well with the DPMI*.EXE programs named above. However, I haven't been able to get it to work, for DosLynxP, in combination with RTM and RTMRES. After commanding: RTMRES, DosLynxP is only able to get about 128 KB of Extended Memory before a further request gets refused.

 

Japheth's HDPMI16.EXE v3.06

This is a free DPMI server included within the HXRT.ZIP package offered at: http://www.japheth.de/HX.html . DosLynxP seems to like it as well as, or better than, the other entries in this list! As with the Borland package, you simply use an HDPMI16 command to start its service up. HDPMI16 is now said to only require a '386 processor -- as long as its HDPMI environment variable isn't set to one nor any other odd number. A '486 or later processor will handle any setup. I have now tested DosLynxP with HDPMI16 on Willy, as well as on my other systems. Willy is running MS-DOS v6.22 together with the HIMEM.SYS provided by Windows 3.11. A difference I notice on Willy, which only has 4 MB of RAM, is that DosLynxP is only able to get about 1.6 MB of that RAM, to work with, from HDPMI16. With the HDPMI environment variable set to 2, to add DOS memory to HDPMI16's memory pool, this figure comes up to about 2.1 MB of RAM. Still a little short of the 2.3 MB of RAM that DosLynxP is able to get from the other three DPMI services I've used on Willy.

 

Microsoft's Windows DOS windows

These provide DPMI service by default. As with DosLynx, the main trick involved in running DosLynxP in a Windows DOS window, will come in arranging Packet Driver interface(s) for it. With Windows 3.x, you may as well load a Real Mode (or, traditional DOS) Packet Driver before starting Windows. This approach may also work with Windows 9x and ME. However, it would be a shame to keep these Windows versions from using their own drivers on your network devices. With Windows driving your network devices, you'll also need a driver such as NDIS3PKT.386, NDIS3PKT.SYS, or SWSVPKT.SYS, to provide Packet Driver interface(s) for your Windows DOS windows. My What To Do with a WinModem Web page provides more information on these drivers. So far, my DosLynxP testing has been limited to Windows 3.11, 9x, NT 4.0, SP6, and 2000, SP3, DOS windows. I have tested DosLynxP with Willy's Windows 3.11 system. With Windows 95 and NT 4.0, SP6, systems on the Cyrix 6x86 based IBM Aptiva, with 16 MB of RAM, that has replaced Sailboard on my home LAN. And, with Windows 98 SE and Windows 2000 Pro, SP3, on my Pentium based system, with 64 MB of RAM, Digerydo.

 

In my first test of a Windows 2000 DOS window, I failed to notice that DosLynxP can't successfully use this system's stock Microsoft mouse driver. (The DosLynx Real Mode version has no trouble with this.) As soon as the mouse moves, DosLynxP crashes with a registers snap. I haven't been able to resolve this issue, yet. However, beginning with version 0.32b, both DosLynx versions provide a new configuration option for bypassing this kind of problem. DosLynxP may now be configured to ignore the mouse. And, thereby, avoid that crash.

 

Quarterdeck's QDPMI.SYS

If you are already running with QEMM386.SYS, getting DPMI service is just a matter of adding QDPMI.SYS to your CONFIG.SYS file, as well. Once you have done that and reBooted, DPMI service will be available by default. You may disable and reenable it by means of QDPMI.COM. As you might expect, QDPMI OFF disables DPMI service. And, QDPMI ON reenables it. I have tested DosLynxP with QEMM/QDPMI versions 7.02 and 8.01. Unless you keep QEMM386.SYS from loading itself into Extended Memory, its requirements together with DosLynxP's, may be more than is available on a system with only 4 MB of RAM. Fortunately, QDPMI.SYS can fill the gap by providing a swap file. You can expect DosLynxP to get very slooow when it is working with swap file based memory. But, that won't come until it has allocated all the physical RAM.

DPMI Servers That DosLynxP Doesn't Like

DR-DOS v7.x EMM386.EXE

DosLynxP seems to get started with this DPMI service. Though, very slowly. It continues to respond to keyboard and mouse interrupts, for a while. But, its background process seems to stall in a disk I/O call.

 

Charles W. Sandmann's CWSDPMI or CSDPMI

These packages set out to support only 32 bit applications. They dismiss 16 bit DosLynxP's request(s) and shut it down.

 

Bob Smith's DPMIONE v0.91

Depending on profile settings, DosLynxP either hangs or crashes, almost immediately, when run with this DPMI service.

Please tell me about other DPMI serving software that should be added to either of these lists!

Fred C. Macall
20 December 2005

Updated and extended several of the reviews.
7 July 2006