Original from  Mike Bilow  to Denis Tonn on 06-06-1996
Original Subject: Toolkit 1.3 from Devcon

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

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

 Oh, I have no argument here. What I was attempting to understand and 
explain is the comments copied from the CP Ref from the devcon. 

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

 Actually, it traps. Trap 000E to be exact. I have a lab for my 
classes that does exactly this. You cannot access memory that is 
uncommitted at all. If you have an exception handler in place, it will
receive control with an exception report record and context record 
on the stack. Your handler can then decide what to do.. But I 
digress.. .. 

 
  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. 
 
MB> This is again completely different.  Address space has no physical analogue.

 Again, we are in violent agreement. 

 
  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. 
 
MB> This is not quite accurate.  The least significant two bits of a selector 
MB> code its privilege; any selector ending in 7h is therefore 
MB> a Ring 3 selector.  This is an Intel hardware issue, not an 

 This exactly what I mean. Here is a small cut from a dump. You can 
see the same thing under the debug kernel: 

# dg 28
0028  LDT     Bas=a8ea7000 Lim=0000ffff DPL=0 P   

# dl 7
0007  Data    Bas=a8ea7000 Lim=0000ffff DPL=3 P  RO        

 Note that selector 7 (and it *is* an application accessable data 
descriptor, abet read only) is the same base address at the LDT. 

 This selector has been available to all applications for a LONG time.
Just not well known. 
 And yes, if you want to get picky, this is index 1 of the LDT. But 
since each DT entry is 8 bytes long, and the last 3 bits define the DT
(either the LDT or the GDT) and the PL, people usually use the full 
value when descibing it. Besides, you cannot use just the upper 13 
bits in a selector, you also have to specify the last 3 bits. 

MB> OS/2 issue.  Buffers passed from Ring 3 to Ring 0, as arise 
MB> in a DosDevIOCtl() call, will generally be mapped to 
MB> selector 0017h.  Temporary selectors mapped by 

 Selector 17 will tile to a flat address of %20000 - always. This is 
usually a data segment, but on larger pieces of 32 bit code may not be 
so.. I have looked at lots of dumps where this is not true. 

 But it is irrelevent to the subject anyway. 

MB> DevHelp_PhysToVirt() will likewise map to selector 0017h, 
MB> 0027h, and so on.  Processes are not supposed to be able to 
MB> read their own LDTs.

 But in fact they can. It is an analomy, but selector 7 *does* always 
point to the base of the LDT. 

 Anyway, to get back to the original discussion .. 
 
  I finally did some testing on the subject. All unique allocations 
still occur on 64K boundries (at least up to FP17) even without the 
tiled bit. But I experimented a bit more. I allocated 3 blocks of 
memory.
 The first test without the commit flag, and only 1 byte in size. 
Since the minimum allocation unit is 4K, I still one page - but 
uncommitted. I then proceeded to setmem 8 pages without error.  Note
that this goes well beyond the original address (yes address!)
allocation. 
 Then I allocated 1 byte WITH the commit flag, I had immediate access 
to the first page and was able to setmem an additional 5 pages (as far
as I tested). Still able to setmem more than I "allocated". 
 Then I allocated 32K without the commit flag, and commited the first 
4 pages of this and caused a trapdump (I am getting good at that) to 
easily see the tiled address in the LDT. The tiled addresses only 
showed 4 pages mapped in the LDT. 
 Lastly I allocated 1 byte without the commit flag, then tried to 
setmem the pages until the setmem failed. I was able to cleanly setmem
the first 16 pages of the returned address range but failed as soon as
I crossed the next 64K boundry. 

 This all was under FP17. Which is a higher kernel rev than Connect 
GA, so it appears that the comment in the CP Ref is still wrong with 
reference to Warp Connect. It still allocates a 64K "object" with the 
addresses beyond the original request (committed memory) "without 
attributes". Commit is an attribute, and you can use setmem to change 
the attributes of allocated addresses: 
 
                ---------------------------------

 DosAllocMem can be used to reserve, or reserve and commit, 
 linear address space for a private memory object. 

 Note:  DosAllocMem and DosAllocSharedMem both allocate a 
 block of memory of the size requested rounded to the nearest 
 page. On OS/2 Warp, the system allocates a 64K object 
 without attributes on every allocation. 

 For example, for a DosAllocMem call with a size of 1, the 
 following occurs: 

       On OS/2 Warp Connect, the system allocates a 4096-byte 
       block of committed memory. 
       On OS/2 Warp, the system allocates a 4096-byte block 
       of committed memory plus 61440 bytes without 
       attributes. 
  
                ---------------------------------

 Which leads me to wonder what the above comment is all about. I 
suspect that they are "preparing" us for changes in the memory 
allocation method. And possibly removing the default (and automatic) 
allocation on tiled (64K) boundries. 


   Denis       

 Certified OS/2 Engineer, Certified OS/2 Instructor, Certifiable....
 All opinions are my very own, IBM has no claim upon them
 
.
--- Maximus/2 3.01