It's good that we have now arrived at the same point, and
we are all happy that TSR's should close STDOUT, just
in case this is being redirected ... :-)
Incidentally, regarding your function $09 vs. file I/O example,
(title : Re: STDOUT (and other special files)), am I naive to
think you can "have the best of both worlds", using func. $09
to write to STDOUT, then simply "closing" file handle 1
(STDOUT)? I don't see why not ... ;-)
Finally, regarding below ... :-(
Perhaps it's just my HLL perspective, but it seems that I
don't understand what is meant here by "inheritance". We
both know that any files opened by the parent remain open
while the child is exec'ed, but this "inheritance" stuff seems
to imply rather _more_ than that. We also both know that the
special file handles such as STDOUT are available to all,
but again, I don't think that is what is being said here. So,
exactly what does "inheritance" mean ... ? :-/
Joe.
> -----Original Message-----
> From: Clarence Verge [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, 23 February 2001 7:16
> To: [EMAIL PROTECTED]
> Subject: Re: Second thoughts on closing someone else's files
>
> Opening the can of worms again:
>
> da Silva, Joe wrote:
> >
>
> > > From: Clarence Verge [SMTP:[EMAIL PROTECTED]]
> > > Sent: Thursday, 22 February 2001 14:28
> > >
> > > What if a TSR is loaded by an application via one of the EXEC
> functions ?
> > > Not unusual. Then it inherits the open files of the parent.
> > >
> > [da Silva, Joe]
> >
> > No, it does NOT! The TSR is an independent application,
> > with it's own PSP (which is what DOS uses to determine
> > what application "owns" a file, in particular, what application
> > has the file open in Write or Read+Write mode ...). It does
> > not inherit any file from it's parent (just a copy of the
> parent's
> > environment, that's about it).
>
> I hate to drag this along further than necessary, but I quote here from
> Ray Duncan "Advanced MSDOS" 1986, re: EXEC (4BH):
>
> All files or devices of the parent that were opened using the Handle
> extended file-management calls are duplicated in the newly created child
> task; that is, the child inherits all the active handles of the parent
> task.
> Any file operations on those handles by the child, such as seek or file
> I/O,
> also affect the file pointers associated with the parents handles.
>
> And from Terry Dettman "DOS Programmers Reference" 1993, re the same 4BH:
>
> A child process spawned in this way inherits the parent process I/O
> files
> unless the parent specifically specifies otherwise in the file-open call
> (Function 3DH). Standard files remain open. If standard files were re-
> directed for the parent , they remain re-directed for the child.
>
> If the parent was producing standard output, and the USER had re-directed
> that to a file, this re-direction is an operation directly under the care
> of DOS *NOT* the application. So the application shouldn't close it.
>
----- snip -----
