Well, I hope this discussion about TSRs and redirection, etc. has been
educational, not boring. This is a "development" list, after all. <g>
Anyway, we should be just about finished here, and a subtle problem
with Arachne can be eliminated/avoided ... :-)
Below is another short test program, used together with the simple
TSR presented on Wednesday, from which the results _further_ below
have been determined. (Incidentally, for those of you who don't have
Turbo Pascal, you can download version 5.5 for free from the Borland
"museum" at "community.borland.com". You can also download the
French version of 7.01 from "www.inprise.fr/download", but I don't
know if this version includes the Run Time Error 200 fix for "CRT" ...)
Joe.
program stdout_test (output);
{$M $800,0,0 } { 2K stack, no heap }
uses
dos;
begin {stdout_test}
{write stuff, then flush buffer, etc.}
writeln('Before ...');
close(output);
{call the tsr ...}
swapvectors;
exec('tsr.exe','');
swapvectors;
{re-initialize buffer, etc.}
rewrite(output);
{write more stuff, flush buffer (just in case)}
writeln('After ...');
close(output)
end. {stdout_test}
> -----Original Message-----
> From: da Silva, Joe [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, 22 February 2001 17:02
> To: '[EMAIL PROTECTED]'
> Subject: RE: Second thoughts on closing someone else's files
>
----- snip -----
> If you want to exec another application, to operate on
> a file, you must close it first, THEN call your "child"
> application, which *should* close the file before returning
> (for normal applications, I think the DOS does this
> automatically anyway, though it's knowledge of the PSP).
> The "parent" application can then re-open the file, if it
> has further need of it!
>
[da Silva, Joe]
Well, the above is the conventional way of avoiding file
sharing violations; however, it appears that the STDOUT
handle has some unusual properties, which prevent you
doing this ...
It seems that once an application _really_ closes STDOUT,
_it_ cannot re-open it! This problem doesn't occur if say,
you open file "CON:" for output - you can close and re-open
_that_ "at will" ... I guess the special file handles 0-5 are
given "special treatment" :-/
Fortunately, however, it seems that an application can,
without producing a "file sharing violation" :
1. Write to STDOUT (not forgetting to flush buffers, if any),
2. Invoke a TSR that also writes to STDOUT and then
_closes_ it,
3. Write some more to STDOUT (flush if necessary ;-),
4. Terminate (closes STDOUT).
So, how does this affect the requirement that a TSR
close STDOUT before "going resident" (just in case
this has been redirected to a file)? Well - it doesn't!
As you can see above (and if you try the sample
code), the "closure" of STDOUT by the TSR does
_not_ deprive either COMMAND.COM or a parent
application of the STDOUT handle, redirected or not!
Remember, the TSR has it's own PSP segment, so
DOS _knows_ that it is just the TSR application which
is "closing" STDOUT, not any _other_ application, etc.
----- snip -----
> > What if the launcher closes its STDOUT handle before loading the TSR ?
> > Then it knows it has to open it again when the TSR is finished loading.
> > But this defeats the ability of the application to re-direct STDOUT.
> >
> [da Silva, Joe]
>
> Hmmm ... that's an interesting scenario, if sufficiently motivated,
> I may check this out, just for curiosity. <g>
>
> However, my initial reaction is that the redirection will only
> occur for the parent application. When this invokes another
> application that uses STDOUT, I think the child's output will
> actually go to the console (not entirely sure, here).
>
[da Silva, Joe]
Well, in fact, redirection remains in effect until the parent
application terminates (or _really_ closes STDOUT, I
suppose ;-).
Also, see above ...
----- snip -----
