PF> IT> As to readwrite_denynone, if the calling program doesn't open
the PF> IT> port in such a way that 'called' programs can use the
handle then PF> IT> there is little point in providing the handle 
PF> IT> in the first place.
PF>
PF>Since the handle is being passed,  and the port is NOT 
PF>being re-opened,deny-none is not required.

 IT> Only IF the process is a genuine child. Yes.

If it is not a child,  you can't pass an opened handle period.

The "OPEN_SHARE_*" constants _only_ affect DosOpen().

 IT> If the process is really a child then this would be true, but it
 IT> appears to me that MAXIMUS does not start child processes but new
 IT> processes in child sessions.

This is not the case;  anyway,  it is also possible to start "child
sessions",  that CAN inhereit handles (as long as they are real OS/2
sessions).

Note that cmd.exe may start a session on a program's (such as maximus)
behalf if required (for example,  the "child" is a DOS program).

 IT> A child process inherits file handles obtained by its parent process,
 IT> along with all sharing and access restrictions specified when the
 IT> parent opened them.

Correct;  so what is important is the "OPEN_ACCESS_*" flags,  not
the "OPEN_SHARE_*" flags.

 IT> To start processes of a different type you'd use DosStartSession,

or exec cmd.exe...

 IT> processes started using DosStartSession ARE NOT child processes

This is not true;  they can be children,  if STARTDATA is setup correctly. 
They CAN inherent open file handles.  


 IT> PS. Pete, if you've got some suggestions as to how I could better
 IT> implement RxAsync so that it functions appropriately with Maximus
 IT> then I'd be glad to hear them.

It sounds fine -- it is the docs that need a little explanation,  and
perhaps a sample that does not do an open.


--- Maximus/2 2.02p1