Hi Denis!

[..]
 DT> The test app only uses about 8K of this memory
 DT> allocation, and runs fine without memman=commit in config.sys. Note
 DT> the return code. 

 DT> (OS) Dos32AllocMem Post-Invocation
 DT> Event [41]  Major [5/0x05]  Minor [7/0x0007]  PID [38/0x0026]
 DT> Length [11]  Time [00:38:01.81]
 DT> Address = 000406E9   Return code = 0000 0008

 DT> (OS) Dos32AllocMem Pre-Invocation
 DT> Event [42]  Major [5/0x05]  Minor [164/0x00a4]  PID [38/0x0026]
 DT> Length [21]  Time [00:38:01.81]
 DT> Address = 000320DC   Size = 0400 0000
 DT> Flags = 0000 0013
Hmm, strange. MEMMAN=COMMIT never served me this way up to a certain kernel
in Warp 3. I'll test again.

[..]
 DT>  I would expect any OS that includes support for memory overcommit to 
 DT> have components that depend upon it. 
But this is not the case for the frontends. I'd rather like to see an error
message popup than a PM/WPS lockup which tends to be unresolvable in this
particular situation. For the user it's like when you open about 250 E.EXEs
- Warp 4's Error Log writes a record about "CreateMessageQueue failed
...". Afterwards PM is unable to allocate a queue, regardless if you
close anything else. Pressing Ctrl-Esc is fatal as PM locks up because the
window list can't be created ... got my point ? :)

[..]
 DT>  From what I have been able to find out, this capability is also in 
 DT> Warp Connect (bldlevel 8.209) and above. To exploit it, you have to 
 DT> have an app that does not use the OBJ_TILED flag and also has a bit on
 DT> in the module header that indicates to the OS that allocations of 
 DT> non-tiled addresses is allowed. I am still searching for this
"bit" in
 DT> the header (spare time??).. 
Have you found it yet ? Of course without that special bit, kernel 9.024
still shows an address increase of 0x10000 when allocating memory <64k.
Could you as one of those kernel guys ? ;-)
     __
     |_)
cu/2 |atrick
[Team  OS/2]

--- FleetStreet 1.18+