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
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
- 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
- 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 version 5 quite well.
But, DosLynxP can't use it 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.41b
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 1.3 MB of memory
available for its data. That seems preferable to having it
constantly exercising the disk.
- In August 2008, a CWSDPMI "release 5, 2008 refresh" version was
(As of this writing early in November 2010, this site is known to
DNS but is not responding to my connection attempts.)
The new CWSDPMI makes plain that it is refreshed.
However, I have not been able to find anything (else) documenting
the change(s) made by the refresh. This has left me ambivalent
about changing the version I distribute in the DosLynx v0.41b
Protected Mode Add-On Package. As I have had no trouble with
the un-refreshed version 5, I have decided against updating it.
- Japheth's HDPMI16.EXE and HDPMI32.EXE v3.17
- These are free DPMI servers included in the HXRTnnn.ZIP package
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.41b, 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).
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.41b 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.
12 November 2010