Well, I've done some investigation on this redirection problem,
with the following results :
1. With Turbo Pascal, the "file handle" is always 1 for standard
output, regardless of whether the CRT unit is used or whether
the output is being redirected. So, it's still a mystery how the
CRT unit inhibits redirection, but I can't be bothered to pursue
this further ... <g>
2. Initial attempts to "close" standard output, as a solution to
this redirection problem with TSRs, was not successful ...
However, knowing that Turbo Pascal provides intermediate
buffering of "text" files, I then added a call to DOS function
$3E, to close the file handle - and this worked! Obviously
(for "text" files, at least), the Turbo Pascal "close" routine
just does some internal stuff (eg. flushing the buffer) and
doesn't _really_ close the file (this presumably happens
only when the program terminates). For anyone interested,
I have included a copy of the (short) test program, below ...
Anyway, I have e-mailed David Lindauer, asking that LSPPP
close "standard output" just before going resident. Assuming
he is happy to do this, we can once again redirect LSPPP's
output to PPP.LOG (for diagnostic purposes, I guess), without
the "side effects" ... :-)
Joe.
program tsr_test (output);
{$M $800,0,0 } { 2K stack, no heap }
uses
dos;
procedure really_close (var f : text);
var
regs : registers;
begin {really_close}
{flush internal buffer, etc.}
close(f);
{close file handle}
regs.AH := $3E;
regs.BX := textrec(f).handle;
msdos(regs)
end; {really_close}
begin {tsr_test}
writeln('This is just a useless TSR ...');
really_close(output); {fully close STDOUT}
keep(0) {don't terminate - stay resident}
end. {tsr_test}
> -----Original Message-----
> From: da Silva, Joe
> Sent: Tuesday, 20 February 2001 18:34
> To: '[EMAIL PROTECTED]'
> Subject: RE: DOS command line redirection (was PPP.LOG redirection
> ...)
>
> See below ...
>
> Joe.
>
> -----Original Message-----
> From: Clarence Verge [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, 20 February 2001 13:14
> To: [EMAIL PROTECTED]
> Subject: Re: DOS command line redirection (was PPP.LOG
> redirection ...)
>
----- snip -----
> While DOS STDIN and STDOUT can be re-directed, nothing else can take
> over
> this function AS LONG AS YOU USE STDIN AND STDOUT.
> In fact, if EPPPD is loaded by a DOS commandline, any re-direction
> characters
> will be stripped (and used) by DOS before EPPPD can get a LOOK at
> the line.
>
> It may be possible to mine the memory for the original command tail,
> but I've
> had no luck with a little experiment I just performed. I think DOS
> wipes it.
>
> [da Silva, Joe]
>
> Yes, even when redirection is inhibited, the command parameters
> stored in the PSP do _not_ include anything after any "redirection"
> character (ie. '<', '>' or '|'). Which leaves two possibilities :
>
> 1. If redirection is inhibited, this might be because the program is
> using an alternative file/device handle (or API?) to do it's
> console
> I/O. In that case, there is probably a function available in the
> DOS API, that will convert a "handle" into it's corresponding
> device/file name. One could then find the name assigned to the
> STDIN or STDOUT handle, and perform normal file I/O to these.
> (Indeed, one might be able to use the STDIN/STDOUT handles
> directly, without bothering to determine their corresponding file
> name(s)). This would effectively re-enable redirection, but under
> full control of the application.
>
> 2. If redirection is _not_ inhibited (ie. "situation normal"),
> perhaps
> an application can simply "close" STDIN and/or STDOUT
> before "going resident"? If so, then this is all that LSPPP (or
> whatever) requires, to prevent problems with redirection .... If
> time permits, I'll investigate further ...
>
>
> - Clarence Verge
> --
> - Help stamp out FATWARE. As a start visit:
> http://home.arachne.cz/
> --
