PF> The 512mb is an address limitation,  so that thunking 
 PF> to 16:16 can be done with an easy/quick bit adjustment.

Right.  Whether you set OBJ_TILE or not, it always returns a 
tiled object (DosAllocMem).

I asked OS/2 SMP Beta with "high memory" support option
and it gave me 2gig without a hitch.  Its aparently
only for backwards compatibility.

 PF> So the answer is yes:  the amount of shared code & data 
 PF> eats away at your useable address space.

 PF> On my machine,  I was able to allocate up to 232650000 
 PF> bytes before I got an error 8.

Why so much overhead?  Plus I thought it was "per process"
and assumed that the rest of OS/2 lived above the 512 limit.

Or is the address space populated with that much of the OS itself?


 PF> I assume you are allocating such a large object with 
 PF> the plans to not-commit it all (ie: a sparse object).  

Yes and no.  The application runs on a 128meg machine, and
on occasion will allocate huge array's (during low load times)
for work.... I was doing the "easy" way out first.

 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.

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

--- Maximus/2 2.02