SC> But it got me wondering how it's done. At first I 
 SC> thought it was a simple matter of opening the com port 
 SC> as READONLY and DENYNONE, and this works reasonably

This works,  but is not safe...even calling certain ioctls clears flags
that the 'real' comm program needs;  and,  of course,  calling DosRead is
completely out of the question.  This is why,  in my serial communications
course,  I teach that an OS/2 serial port should always be opened in deny
read-write mode.

 SC> But then, when I started up Faxworks, Faxworks (which uses its own comms 
 SC> driver) was denied access to the port because I still

That is because Faxworks is opening it in deny read-write -- and since a
read handle already exists,  the deny read-write request can not be
satisfied,  so DosOpen fails ---  just as it should for an inherently
single-use device like a serial port.

 SC> had an open file handle on the port. Makes sense, 
 SC> except that somehow PMLM manages to simply step aside 
 SC> when Faxworks is running. It doesn't report any 
 SC> activity, but it also doesn't interfere.

 SC> Anyone got any ideas about how PMLM does it?

I do not know how it actually does it,  but I can guess:  The device driver
presents a special device name (for example, LM$) that the monitor program
opens.  This back door gives the monitor program access to internal DD data
structures.


--- Maximus/2 3.00