PF> I suggest you let C++ do it for you (create a class 
 PF> that looks like a memory pointer but really does file 
 PF> i/o),  or use Windows NT instead.

 TF> Why would I want to switch to NT?  I'm kinda surprised to
 TF> hear you say that.

 PF> I hope it stings some IBMers to hear me say so too.  
 PF> This is one of the things that would be easy to fix,  and has not.

Its been "fixed" or removed in the version of SMP warp Beta that we
have... so I assume that it wouldn't be too much of a stretch to remove
the limit.  I know now that the real limit is 295mb, and that this
can be removed.  But I have yet to hear a *real* defintion as to what's
exactly going on.  One of the IBM engineers mentioned that it has to
do with DLL's, but had no specifics for me.

 PF> The other thing that comes to mind is memory-mapped 
 PF> files,  which would be a cinch to code (but would be 
 PF> limited to the ~230mb limit you found,unless that is fixed first).

 PF> I actually coded memory mapped files in a late OS/2 2.0 
 PF> beta,  and they worked 100% -- but IBM decided to add 
 PF> some more error checking ("for my own good" kogan told 
 PF> me) that prevented it from working (Before 2.0 GA,a 
 PF> "page not present" exception in a kernel call (DosRead, 
 PF> for example) could be handled by a program's exception 
 PF> handler;  when GA came out,they prevent this,  and 
 PF> cause the program to trap instead).


Ah.  So at one time you could have handled that exception.  I had
heard that it was possible, but when I moved to 2.0 (a while after GA)
I found no mention of how to do this.

Memory mapped files probably wouldn't help us with this, we are too
close to shipping to make large changes in architecture.


Thanks for the information.... it does help.


--- Maximus/2 2.02