Denis Tonn wrote in a message to Mike Bilow:

MB> As far as I know, Mario's quote from the docs is just plain 
MB> wrong.  The allocation of memory results in some kind of 
MB> selector being mapped, and that selector will have whatever 
MB> length is appropriate for the allocation, subject to 4 KB 
MB> granularity.  That is, if 1 byte is allocated, then the 
MB> selector is mapped to a 4 KB area of memory.  You cannot then 
MB> call DosSetMem() to commit more memory than the allocated 
MB> selector length under any version of OS/2.

 DT>  Hmm.. I have allocated an address range without commit,
 DT> then  committed the pages one at a time. The tiled selector
 DT> was automaticly  adjusted in it's limit after each commit.
 DT> It has to do this for 16/32  code compatability (the reason
 DT> for the tiled selector in the LDT).  

This is completely different.  The claim was that one can allocate 1 byte
and get something allocated that is 64 KB rather than 4 KB.  Whatever is
allocated is just address space, which has no physical analogue whatsoever.
 Allocating 64 KB and committing 1 byte does actually allocate something 64
KB big that has a physical analogue.

Memory which is allocated but uncommitted is handled internally by OS/2 as
"not present."  That is, an attempt to access the memory causes a
"not present" exception, which is the normal behavior for an
attempt to access committed memory that has been swapped out.  However, the
swap manager finds no table entry for the requested page, since it is
uncommitted, and gracefully returns an error code.

 DT>  I never tried to do what I suspect the documentation is
 DT> saying, IE:  allocate a 4K page and then commit additional
 DT> pages beyond the  original allocation size. It will take
 DT> some testing to prove it one  way or another. 

This is again completely different.  Address space has no physical analogue.

 DT>  If you are interested, selector 7 is a readonly selector to
 DT> the  base address of the LDT, and if you map this address
 DT> into a LDT struc then you can "watch" the tiling process
 DT> take place. 

This is not quite accurate.  The least significant two bits of a selector
code its privilege; any selector ending in 7h is therefore a Ring 3
selector.  This is an Intel hardware issue, not an OS/2 issue.  Buffers
passed from Ring 3 to Ring 0, as arise in a DosDevIOCtl() call, will
generally be mapped to selector 0017h.  Temporary selectors mapped by
DevHelp_PhysToVirt() will likewise map to selector 0017h, 0027h, and so on.
 Processes are not supposed to be able to read their own LDTs.
 
-- Mike


---