IT>On the 03-19-95, Peter Fitzsimmons was chatting with Ian Timms:

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

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

IT>PF>In fact,  to be
IT>PF>sure no other session comes along to screw things up,  the
IT>PF>parent program should be opening the port with "deny
IT>PF>read/write".

The only case where you might want to use SHARE_DENY_NONE is with SIO,
if you plan to spawn a DOS session and you want it to have access to the
com port.  I think.  This could get tricky, and you'd better know what
your doing.

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.

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. A child process is one which is invoked in the
IT>same 'session' as its parent by using a DosExecPgm call.

True.

IT>Such a child process should be able to read and write to
IT>any of these handles without doing an open call regardless of
IT>the open mode used by the parent.  Such child processes however
IT>need to be of the same 'type' as the parent ie. PM, Windowed,
IT>Full screen for them to be openable using DosExecPgm.

Not exactly.

IT>To start processes of a different type you'd use DosStartSession,
IT>processes started using DosStartSession ARE NOT child processes
IT>of the invoking process, they are seperate processes altogether,
IT>and reside in their very own 'session', this 'session' may/maynot
IT>be a child 'session', but the process started in it can _never_ be
IT>a child of the process which started it. Therefore such a process
IT>can _never_ inherit the file handles from it's 'logical parent'.
IT>Such a process must also perform an open/close on any file it
IT>wishes to use and that file if opened by the 'logical parent'
IT>MUST be opened in OPEN_SHARE_DENYNONE for it to succeed.

Whoa.  OS/2 sessions started with DosStartSession or WinStartApp do
inherit the file handles of their starter (I will avoid the term
"parent," it seems to be causing confusion)  It doesn't matter if they
are related or unrelated sessions.  In either case, they are technically
children of the "shell" process, and in either case they inherit file
handles.  Even a detached process, which has no parent, inherits file
handles.

I know you won't believe me, so try this experiment.

From an OS/2 window, give the following command:

 type con | start more

As you type lines into the first window, they will be copied to the
second window (an unrelated session).  When you enter CONTROL-Z or
CONTROL-BREAK in the first window, the second one will close.

The type command sends output to file handle 1 (stdout)  The more
command, which is running in a separate session, accepts input from
handle 0 (stdin).  The | pipe symbol sets up the file handles for us,
before starting.

You can have a lot of fun with this.  Try hitting CONTROL-BREAK in the
second window, for instance: see what happens.

___
 X SLMR 2.1a X 

--- Maximus/2 2.02