Hello David!
18 Mar 97 22:08, David Noon wrote to James Mckenzie:
 DN> Yes, I used DOS4GW.EXE to load the program explicitly and I also ran
 DN> the program directly, allowing the stub to load the DOS/4GW software.
 DN> Worked correctly either way.
Thanks for this clarification.
 DN> It isn't for data files. It is purely about memory allocation and
 DN> commitment. You can read a file of arbitrary size, provided your
 DN> buffers don't exceed the DPMI memory limitation.
Again, thanks.  I was aware of this, but I forgot to mention it.
 DN> Also, remember that the 640KB of conventional memory is separately
 DN> addressable from DPMI memory. In fact, XMS storage is normally used
 DN> to back DPMI page frames in central memory. In p-mode XMS has no
 DN> meaning, but conventional memory can be accessed by DPMI services
 DN> that "simulate real mode".
Again, I was aware of this capability, but I've only USED DOS/4GW in the 
protected mode.  I was making statements based on the copy of DOS/4GW 
included with Watcom C++ 10.0.
 DN> Yes, that was VCPI; long dead and good riddance.
Unfortunately two good programs, one being JetFighter II and the other being 
Strike Command, were written to that "specification.
 DN> The 32MB limit is imposed by the DOS/4GW server code, not the client
 DN> code. The client will handle 40MB or more if a DPMI server will
 DN> provide it.
I think that I understand what you are saying.  I might have misinterpeted 
what Watcom said.
 DN> I am also running 1.97. The server is a genuine DPMI interface. It
 DN> simply says "no" to any request that would cause the amount of memory
 DN> allocated to exceed 32MB. Apart from that it is a straight DPMI
 DN> server, with some short-cut entry points documented largely by Ralf
 DN> Brown and Jim Kyle.
Ok.
 DN> The DOS/4GW client accepts whatever DPMI server is active when the
 DN> program starts. It does not depend at all on having the DOS/4GW server
 DN> active, as my experiment above shows.
And proves.  OS/2 can provide up to 512MB of DPMI memory.  I guess that this 
is much more than 32MB ;-).   I'm kinda glad of that point too.  I would like 
to see a 512MB program....
 DN> I suspect that if one ran a program using, say, Phar Lap 386 to
 DN> establish the DPMI environment and that program then chained to a
 DN> DOS/4GW program, the latter would use the Phar Lap DPMI server and its
 DN> 4GB of virtual memory.
Yep.  I remember the constraints of PharLap (can you say MajorBBS?)
 DN> Thw DOS/4GW Pro server is limited to 128MB. Only DOS/4G server can
 DN> offer as much DPMI memory that OS/2 can provide (and more).
Yep.  And have you priced that baby?  I think that OS/2 is much cheaper...
 DN> However, the DOS/4GW client can access all 512MB of DPMI memory,
 DN> provided you have the RAM and paging space on DASD to back it. The
 DN> 32MB is not a client constraint, as my experiment shows.
Again, I agree that you proved the point that a client can access more than 
32MB.  I guess that I misinterpeted what Watcom had stated...
 DN> I guess it depends upon the program's objectives. Generally, all
 DN> programs run better as native OS/2 executables.
Under OS/2 yes.  However DOS/4GW does (sorta) guarantee that the program will 
run under OS/2 and DOS.  It is also a wonderful way of getting non-graphic 
programs (those that can be run from the command line, not from the GUI) to 
run under more than one platform without creating more than one version.
 DN> P.S. Heee's baaack!! I recevied a message on the PC Co. BBS from
 DN> Steerboy last week. ...:-(
Send me Netmail on what that man in the field is up to.  I guess that he 
could not be kept busy enough with Windows97 (it is still an etomotogists 
dream). And remind him that his favorite company just released a SATAN 
delight (one site will look at your browser and disconnect you with a frowny 
face if you are using Netscape!)
James
... Windows: Ultimate memory manager.  It manages to use it all.
--- GoldED/2 2.50+
(1:309/63)
---------------