Jonathan de Boyne Pollard wrote in a message to Mike Bilow:

  > Now, remember that this would succeed 30 or more times using Borland's
  > malloc() to allocate that buffer, and then might trap out
  > on the 31st or whatever call to the driver.  The driver
  > logic was validated, I think, by the fact that the problem
  > did not arise when DosAllocMem()/DosFree() was substituted
  > for malloc()/free().
  >
  > I have never really satisfied myself as to what the problem
  > was, and the code had to go out one way or another.  I also
  > was not responsible for the application level code, so my
  > opportunities to explore were somewhat limited.

 JdBP>   Of course.  I understood that.  After a week or so's being
 JdBP> away from   OS2PROG I don't think that Phil's and your cases
 JdBP> are related, in fact.   I think that Phil's problem is a
 JdBP> variation on the old "how do we share   heaps from EXE to
 JdBP> DLL?" problem.

I tend to agree.

 JdBP>   Yours is probably an application-level problem.  Borland
 JdBP> always   commits pages before adding them to the heap, and
 JdBP> even always   allocates tileable memory (and tries to keep
 JdBP> all allocations less than   64Kb within the same segment). 
 JdBP> So I cannot see *anything* that could   cause a page-level
 JdBP> problem with memory allocated via Borland's   malloc().

I assume that you realize that there is actually no way to allocate
non-tiled memory in OS/2.  Even if you don't set the OBJ_TILE flag when
calling DosAllocMem(), you still get tiled memory.  The documentation warns
that this is subject to change in a future release of OS/2 -- it obviously
makes no sense in the context of the PowerPC, for example -- but all Intel
x86 versions of OS/2 act this way so far.

 JdBP>   But on the other hand, Borland's thunking mechanisms are
 JdBP> known to be   problematic.  If the applications programmers
 JdBP> were allocating 0:32   memory and then passing it to the
 JdBP> 16-bit DosDevIOCtl whilst relying on   Borland C++ to do the
 JdBP> thunking ...

I am fairly sure that Borland is not responsible for the thunk in this
case. I don't think that DosDevIOCtl() is thunked when called from 0:32
applications, since the parameters are different sizes (ULONG instead of
USHORT) than if called from 16:16 applications.  A thunk is clearly
performed somewhere, since the driver is entered at a 16:16 entry point
with a 16:16 stack and sees 16:16 addresses embedded in the request packet.
 However, I believe that this thunk is handled by the operating system
directly.

I ran into another problem last week when I was called in to work on the
same driver, so maybe this will be a clue.  Calling DosDevIOCtl() in a loop
to do successive writes from a 0:32 application -- using the same data in
memory at the same address -- was failing out after exactly 126 iterations.
 Instead of Trap D, however, the driver was returning
"ERROR_I24_BAD_COMMAND" in response to the 127th call.  This
error code is usually only issued by the driver if there is a syntax error
or something similar in the IOCtl parameter packet, which I was validating
manually with the debugging kernel.  I was also checking other likely
candidates manually, such as the stack pointer position on successive
entries to the driver.

I made a small change to the driver code to add two new global data items
to keep track of something, and suddenly the driver itself was pulling Trap
E on system boot.  I quickly determined that the error was in linker symbol
resolution: I could clearly see, for example, that the entry point to my
function was at offset 0400h, but the linker was resolving that label to
0404h -- four bytes later.  As a result, jumps and calls were going to the
wrong addresses, garbage code was being executed, and this eventually
pulled Trap E. I was at a complete loss for what to do, and I tried all of
the obvious solutions such as a full rebuild to catch dependency errors.

After hunting this for many hours, in desperation I did a full rebuild with
Microsoft C 6.0 instead of Watcom C 10.0.  The linker errors, the Trap E on
boot, and the ERROR_I24_BAD_COMMAND on the 127th iteration all went away! 
I would be tempted to condemn the Watcom tools except for two problems: I
was always using the old MS LINK program even when building with the Watcom
compiler, and the earlier problem with Trap D months ago was when I was
still building with the MS compiler.  When I have the time to deal with
this further, probably next week, I intend to start by looking at the
Watcom optimization switches.
 
-- Mike


---