On Saturday, 97/03/15, James Mckenzie wrote to David Noon about "Dpmi
Limits" as follows:
JM>  DN> Since you roused my curiosity, I decided to write a little test
JM>  DN> program that would access 40MB of DPMI storage. It worked perfectly,
JM>  DN> allocating and _committing_ all 40MB without incident beyond 
loating
JM>  DN> the swap file a bit.
JM> 
JM> Did you use the DOS/4GW executeable to do this?
Hi James,
Yes, I used DOS4GW.EXE to load the program explicitly and I also ran
the program directly, allowing the stub to load the DOS/4GW software.
Worked correctly either way.
JM> DOS/4GW allows the DOS environment to access more than the 
JM> normally available 640KB for executeable and data files.
It isn't for data files. It is purely about memory allocation and
commitment. You can read a file of arbitrary size, provided your
buffers don't exceed the DPMI memory limitation.
Also, remember that the 640KB of conventional memory is separately
addressable from DPMI memory. In fact, XMS storage is normally used to
back DPMI page frames in central memory. In p-mode XMS has no meaning,
but conventional memory can be accessed by DPMI services that
"simulate real mode".
JM> The earlier versions (<1.94) used a method that was not 
JM> compatible with OS/2's VDM structure.  The later versions 
JM> started to use DPMI, but were limited to 32MB of combined 
JM> executeable and data file in memory.
Yes, that was VCPI; long dead and good riddance.
The 32MB limit is imposed by the DOS/4GW server code, not the client
code. The client will handle 40MB or more if a DPMI server will
provide it.
JM>  DN> A DPMI client is obliged to obey the DPMI conventions. These are not
JM>  DN> dependent on pure DOS. Indeed, using DPMI makes DOS very impure, 
since
JM>  DN> a DPMI server switches the CPU from real mode to protected mode.
JM> 
JM> True, David.  However, the interface presented by DOS/4GW is not
JM> which a  "true" DPMI interface would present.  It has its 
JM> limitations.  BTW, this all come from the version I  received with
JM> Watcom 10.0. (1.97?)
I am also running 1.97. The server is a genuine DPMI interface. It
simply says "no" to any request that would cause the amount of memory
allocated to exceed 32MB. Apart from that it is a straight DPMI
server, with some short-cut entry points documented largely by Ralf
Brown and Jim Kyle.
JM> Again, true.  But DOS/4GW is designed to setup its own DPMI 
JM> environmet. Remember, DOS does not setup DPMI like OS/2 and 
JM> several other OS's do.
The DOS/4GW client accepts whatever DPMI server is active when the
program starts. It does not depend at all on having the DOS/4GW server
active, as my experiment above shows.
I suspect that if one ran a program using, say, Phar Lap 386 to
establish the DPMI environment and that program then chained to a
DOS/4GW program, the latter would use the Phar Lap DPMI server and its
4GB of virtual memory.
JM> However, OS/2 can provide up to 512MB of DPMI space.  The 
JM> limitation is not on OS/2, but rather the DOS/4GW stub that 
JM> was provided with Watcom.  DOS/4GW Professional can access 
JM> up to and including all of the space that OS/2 can provide.
Thw DOS/4GW Pro server is limited to 128MB. Only DOS/4G server can
offer as much DPMI memory that OS/2 can provide (and more).
However, the DOS/4GW client can access all 512MB of DPMI memory,
provided you have the RAM and paging space on DASD to back it. The
32MB is not a client constraint, as my experiment shows.
In fact, this was Jonathan's point in querying my suggestion about
setting DPMI limits. The 32MB limit is in the DOS/4GW server, not the
client.
JM>  However, I think at that point it would be better to have 
JM> a native OS/2 version of the executible.
I guess it depends upon the program's objectives. Generally, all
programs run better as native OS/2 executables.
Regards
Dave

P.S. Heee's baaack!! I recevied a message on the PC Co. BBS from
Steerboy last week. ...:-(
 * KWQ/2 1.2i * Double your drive space! Delete Windows!
--- Maximus/2 3.01
---------------