-=> Quoting Jonathan de Boyne Pollard to Michael Duffy <=-

 MD>    Ok, so what exactly is the most intelligent way to allocate memory 
 MD> if you don't know exactly what you requirements will be?  Apparently 
 MD> malloc isn't giving me any single allocations larger than 32K 
 MD> (Watcom v.10.0),

 JdBP> I'd complain, or use the 32-bit compiler.  (-:
 JdBP> malloc() and ::operator new are both be able to allocate enormous
 JdBP> amounts of memory.
 
Actually, it turns out that the problem is a bit screwier than I first 
realized.  I can use the 32-bit Watcom compiler to malloc huge segments of
memory.  It turns out that that was not the problem.  The problem is when
I need an API call (in this situation GpiSetBitmapBits) to access this
memory as well.  Both malloc and the OS/2 stack handling functions are 
the same way: they seem to leave only the first 32K of memory committed.
It turns out that if I handle the committing of pages myself before they
are handled by the stack (with DosSubSetMem), then there is no problem.  
The only problem is when I let the SubAllocate functions handle the 
committing by themselves.

And this leads be back to my original problem.  If I have to handle 
committing the pages myself, then how much memory should I commit?
Is this an OS/2 problem, or a compiler problem?  Shared memory is not
the answer either, since shared memory pages are left committed.  I guess
a workaround is to allocate large bitmaps with the DosAllocMem
function and commit all the pages, and then allocate structures that aren't
passed to API routines with malloc, but this isn't too graceful.

Or perhaps programming just isn't meant to be graceful.

If anyone has any insights into this, I'm all ears.

Michael Duffy

... Taglines: Bumber stickers for the Information Superhighway
--- GEcho 1.10+