🚀 go-pugleaf

In message: <1989Nov10.025654.3274@eddie.mit.edu>
jamin@eddie.mit.edu (Sugih Jamin), writes:
> Ah, the manual.  It, the manual, says that I must use DosSubSet on a 
> chunk of memory allocated with DosAllocSeg or DosAllocShrSeg.  It 
> doesn't say I must not use it with DosAllocHuge.  Normally, I would 
> assume that only DosAllocSeg and DosAllocShrSeg work with DosSubSet.  
> ...
> this out from the M&T book.  Besides, calling DosSubSet on memory
> allocated with DosAllocHuge didn't return any error.

All DosAllocHuge does is allocate a series of memory blocks whose
selectors are evenly spaced throughout one's LDT (this space between
them is found from a function call).  Once a block's selector is
known, it can be used as if it were a stand-alone memory segment
when used with "simple" calls like DosSub{Set,Alloc,Free}, but only
as a single segment.  Those functions will not cross the segment
boundaries.  I think that the only connection that remains between
the segments allocated with DosAllocHuge is that they can be deallocated
all at once (I think) with a function call.

> Now that we have mentioned the manual, allow me to ask, "Why is
> Microsoft so inconsistent in making up function names?"  For dealing 
> with semaphores, for example, we have DosOpenSem, DosCreateSem, etc.,
> but we also have DosSemRequest, and DosSemWait.  A simple test:

I think that the reason behind the inconsistent naming "conventions"
is tied to the classic "7-letter limit" for distinct external link-time
references, and if all the semaphore commands were DosSem..., then
there would only be 1 letter left (at least) for distinguishing all the
semaphore commands (risky).  That is, DosSemWait and DosSemWhatsit would
be the same.  I am not sure if this is totally accurate, but it looks
plausible.
  Of course, they could have been named by different committees working
on commands split up arbitrarily, but that never happens. :-)

> Then there is that Hungarian notation.  It simply defeats the whole
> purpose of data abstraction, doesn't it?  Even the manual itself got
> confused over it.  In more than one instances, the manual errorneously

Yes, that notation is weird and ambiguous at best.
And mentioning confused manuals, I have noticed several inconsistencies
in Iacobucci's (no offense) book on OS/2, mainly in some of the
descriptions of the interfaces to the function calls.  I would use
the descriptions in the book, but when I was unsure about a function's
interface, I would have to break out the Tech Ref.  Maybe these glitches
will be fixed in a later edition of the book.

Disclaimer: I speak for myself alone, and not for my employer (as if
any of you know where I work :-).
-- 
Joseph Lawrence Martin
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp:	  ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!ccastmj
Internet: ccastmj@prism.gatech.edu