SS>
  > Since I use my OS/2 machine for programming DOS (and hopefully soon, OS/2)
  > apps ...
  >                     ... I've had some bad code (e.g. stray pointers, bad
  > addresses, etc.) that locked OS/2 (2.11) tight as a drum.  ...
SS>

  I haven't.  And I can perhaps point you towards some reasons why our
  experiences differ.

  Almost all of the programs that I've written have had a SYS317x at one
  time or another, and OS/2 has continued soldiering on.  The only time
  that I've had problems where I had to restart the system was when I
  was learning how to program Presentation Manager.  A locked message
  queue is not a happy system. (-:

  However, I now write OS/2 programs.  I remember from my DOS days that
  there is at least one way to *guarantee* a TRAP 000E with about six
  lines of code.

  What is this code ?

  Well, it turns out that the parameters in calls to the Virtual Device
  Drivers that power the Virtual DOS Machines are not validated as
  strictly as they could be.  I passed an array longer than the
  "documented" 14 bytes to one function, and -- voila! -- instant TRAP.

  The problem is that VDDs run at Ring 0 (kernel level), because of the
  way that VDM management is integrated into the kernel.  Any process
  exception in Ring 0 causes a TRAP, whereas the same problem in Ring 3
  (where normal user code, and normal VDM code run) would just be caught
  and give a SYS317x exception.

  If you happen to screw up a VDM to the extent of confusing the wrong
  VDD, then you are liable to get a TRAP.

  This is not to say that VDDs are in general badly written.  On the
  contrary, in a couple of years that one sequence was the only way that
  I found to cause a TRAP from a VDM.  And even that was undocumented
  stuff that I shouldn't really have been fiddling with.  Nevertheless,
  it is important to bear in mind that VDDs may not be perfect.

  > JdeBP <
___
 X MegaMail 2.10 #0:

--- Maximus/2 2.01wb