Original from  Patrick Haller  to Denis Tonn on 12-17-1996
Original Subject: I couldn't get xalloc ex

                         ---------------------------------------

  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

PH> Hmm, strange. MEMMAN=COMMIT never served me this way up to 
PH> a certain kernel in Warp 3. I'll test again.

 It has worked this way since I started teaching debugging classes. I 
have taught these classes on 2.0, 2.1, 2.11, 3.0 GA, 3.0 Connect, and 
Warp 4. 

  DT>  I would expect any OS that includes support for memory overcommit to 
  DT> have components that depend upon it. 

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

 I have it.. I don't expect that this kind of situation would be part 
of the test enviroment, nor even part of a normal beta testers system 
setup. 

  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??).. 

PH> Have you found it yet ? Of course without that special bit, 

 Not yet. Not enough time, and there are more important things on the 
"to-do" list at the moment. 

PH> kernel 9.024 still shows an address increase of 0x10000 
PH> when allocating memory <64k. Could you as one of those 
PH> kernel guys ? ;-)

 I suspect that non-tiled memory will be allocated above the 512MB
line on page boundries. 


   Denis       

 All opinions are my very own, IBM has no claim upon them
. 
. 
.
--- Maximus/2 3.01