Review of DPMI Serving Software for DosLynxP and DosLynxS

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 Intel '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! DosLynxP was joined by a 32-bit Protected Mode version (DosLynxS) in 2008.

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 needs a DPMI server that, at least, supports 16-bit applications. At the same time, DosLynxS is a 32-bit application and needs a DPMI server that supports 32-bit applications. Perhaps needless to say, these will require a '386 or later processor. Because, the '286 doesn't have 32-bit registers.

Finally, here are my two lists. The first is to let you know what 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 and/or DosLynxS like 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 and/or DosLynxS Like

Borland's DPMI16BI.OVL, DPMI32BI.OVL, and DPMI32VM.OVL

I had been aware of only the first of these until someone in Russia wrote to me about DPMI32BI.OVL! Then, I looked into DPMIRES.EXE (see below), with DEBUG or SHOWTEXT, and saw that it mentions all three in the same breath. I am not sure if DPMI32*.OVL provide support for 32-bit applications. Or, if they simply improve the 16-bit application support provided, when running on a 32-bit PC. If you don't have these yet, it won't hurt to look for all three. If you know of any documentation for these, available from the Internet, I hope you will write to let me know about it. For the rest of this section, I'll tell you what I have learned about DPMI16BI.OVL:

 

As its name suggests, DPMI16BI.OVL is a 16-bit DPMI server. DosLynxP likes it quite well. But, DosLynxS can't use it at all. (Though, DosLynxS may be able to use DPMI32BI.OVL or DPMI32VM.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 (or only) 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 able to get only about 128 KB of Extended Memory before a further request gets refused.

 

Charles W. Sandmann's CWSDPMI or CSDPMI

This is a free package that sets out to support only 32-bit applications. DosLynxS likes CWSDPMI.EXE versions 5 and 7 quite well. But, DosLynxP can't use them at all. As it is included in the DJGPP tool set used to make DosLynxS, I've been able to include CWSDPMI.EXE in the DosLynx Protected Mode Add-On Package. When DosLynxS starts up, it will check for the presence of a 32-bit DPMI server. If it doesn't find one already running, it will look in its own directory, and on the PATH, for CWSDPMI.EXE. If CWSDPMI.EXE is waiting in any of those places, DosLynxS will start it up. That's almost all there is to it! I have tested DosLynxS with CWSDPMI on systems starting with Willy, as well.

 

GO32-V2.EXE, which also is included in the DosLynx v0.44b Protected Mode Add-On Package, is a small tool for checking up on your 32-bit DPMI service, if any. It can help you see the effect of changing certain options with any of the 32-bit DPMI services. Like DosLynxS, GO32-V2 will attempt to start CWSDPMI.EXE, as described above, if necessary. If GO32-V2 reports:

 

DPMI memory available: 4000 Kb

 

or more, for your environment, you can expect DosLynxS to run well.

 

On a PC with only 4 MB of RAM, GO32-V2 is likely to report that only about 3600 Kb of DPMI memory is available. In that case, CWSDPMI will try to satisfy some of DosLynxS' memory requests with disk based "virtual memory". If that happens, the heap memory pool checking that DosLynxS performs while idle will keep your disk activity light flashing constantly. To avoid that issue, CWSDPMI may be used with its -s- parameter, which tells it not to provide any virtual memory. To do this, add an explicit

CWSDPMI -s-

call to the beginning of your DOSLYNXS.BAT file. With that done, DosLynxS will indicate that it only has about 750 KB of memory available for its data. That seems preferable to having it constantly exercising the disk.

 

In January 2010, a CWSDPMI "release 7" version was released from: http://www.delorie.com/pub/djgpp/current/v2misc/ . There are two files: csdpmi7b.zip and csdpmi7s.zip, for the binaries and source, respectively. The release 7 version is said to be better suited for PCs with very large memories. So, that is the CWSDPMI version I am now including in the DosLynx Protected Mode Add-On Package. If you are already comfortable with the "release 5" version, there likely is no need to change.

 

Japheth's HDPMI16.EXE and HDPMI32.EXE v2.17

These are free DPMI servers included in the HXRTnnn.ZIP package offered at: https://www.japheth.de/HX.html . As you might guess, HDPMI16.EXE supports 16-bit applications while HDPMI32.EXE supports 32-bit applications. DosLynxP seems to like HDPMI16 as well as, or better than, the other entries in this list! As with the Borland package, you simply use an HDPMI16 or HDPMI32 command to start these services up. If you want to run both 16-bit and 32-bit applications, it is suggested that you: "first run HDPMI16, then HDPMI32, both with option -r." However, I've found that this approach may be problematic. You may be better off adding more specific HDPMInn command(s) to your DosLynxP and/or DosLynxS .BAT wrappers. As suggested above for the Borland DPMI server. These servers are said to require only a '386 processor -- as long as the 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 and DosLynxS with HDPMI32 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 is that DosLynxP is only able to get about 1.9 MB of RAM, for its data, from HDPMI16. Setting the HDPMI environment variable to 2, to add DOS memory to HDPMI16's memory pool, does bring this figure up to the 2.3 MB of RAM that DosLynxP expects. Unfortunately, this trick can't be used with HDPMI32, for serving DosLynxS, on a 4 MB PC. Because, HDPMI32 provides no way to limit the amount of DOS memory provided to its DPMI client. If you try it with DosLynxS v0.44b, you're likely to see trouble with DOS disk I/O. That happens because DosLynxS has taken all of the free DOS memory. Leaving nothing free for DOS to use when it needs some.

 

Microsoft's Windows DOS windows

These provide DPMI service, for either 16-bit or 32-bit applications, by default. As with DosLynx, the main trick involved in running DosLynxP or DosLynxS, in a Windows DOS window, will come in arranging a Packet Driver interface for it. With Windows 3.x, you may as well load a Real Mode (or, traditional DOS) Packet Driver before starting Windows. This approach also may 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 device(s). With Windows driving your network device(s), 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 window(s). My What To Do with a WinModem Web page provides more information on these drivers. So far, my DosLynxP and DosLynxS Windows testing has been limited to Windows 3.11, 9x, NT 4.0 (SP6), 2000 (SP3 and SP4), and XP (SP2) DOS windows. I have tested DosLynxP and DosLynxS with Willy's Windows 3.11 system. With Windows 95 and NT 4.0 (SP6), systems on the Pentium based Gateway 2000, with 32 MB of RAM, that has again replaced Sailboard on my home LAN. With both Windows 98 SE and Windows 2000 Pro, on my Pentium based systems, with 64 MB and 192 MB of RAM, Digerydo and Paquie. And, with Windows XP on my Celeron (or, 80F86) based Dell GX270, with 128 MB of RAM, Barnaby. I welcome reports on your experience(s) with DosLynx in OS/2, Windows Vista, and Windows 7 DOS windows.

 

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 and 32-bit Protected Mode versions have 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, all DosLynx versions provide a new configuration option for bypassing this kind of problem. The DosLynx Protected Mode versions may now be configured to ignore the mouse. And, thereby, avoid that crash. Strangely enough, this problem is also seen with DosLynxS, on Windows NT 4.0 (SP6). While DosLynx and DosLynxP have no mouse trouble, there. Go figure.

 

Quarterdeck's QDPMI.SYS

If you are already running with QEMM386.SYS, getting DPMI service for both 16-bit and 32-bit applications 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, sometimes. (When QDPMI ON won't work, the problem may be that I've still got another DPMI server running. Rather than investigate, my next step there usually is to reBoot the system.) I have tested DosLynxP and DosLynxS with QEMM/QDPMI versions 7.02 and 8.01.

 

The Extended Memory requirements of QEMM386.SYS, together with DosLynxP's or DosLynxS's may be more than what is available on a system with only 4 MB of RAM. QDPMI.SYS can fill the gap for DosLynxP by providing "virtual memory" by means of a swap file. However, you can expect DosLynxP to get very slooow when it is working with virtual or swap file based memory. As DosLynxS trys to lock all of the memory it uses, QDPMI's virtual memory isn't an option for it. A better approach, for both DosLynxP and DosLynxS, is to use QDPMI's MAXLOW and VMOFF options. These direct QDPMI to augment its DPMI memory pool with DOS memory, rather than trying to provide virtual memory. The MAXLOW option provides for limiting the amount of DOS memory given to the DPMI client. So, QDPMI can avoid the problem that HDPMI32 has with providing DOS memory to DosLynxS on a 4 MB PC.

 

An unresolved issue, with the https/SSL support added to DosLynxS in version 0.38b, is that it doesn't work with QEMM's QDPMI DPMI service on my older PCs with pre-Pentium (i.e.: '386 and '486) processors. If you have QDPMI.SYS in your CONFIG.SYS file and run into this issue, you'll need either to remove it or command QDPMI OFF before using DosLynxS to access https URL(s). With that done, DosLynxS automatically will use CWSDPMI.EXE (provided in the DosLynx v0.44b Protected Mode Add-On Package) for its DPMI service.

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.

 

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

Updated several of the DPMI server reviews.
Updated the link to my Web site.
17 September 2020