Mail Archives: djgpp/2002/07/09/11:01:05
Eli Zaretskii wrote:
> Actually, `redir' opens the COM3 port even before it runs the
> application. It has no way of knowing whether something is actually
> output to the port (to say nothing of the fact that while the application
> executes, `redir' is suspended--this is DOS, remember?--and so none of
> `redir's own code can run).
>
OK, but the strange thing is that I am able to send everything to COM3 from
withing my program prior to the moment when stderr is accessed first time.
After that it is only redir's output getting through.
Strange thing happens though. At start-up the program normally outputs to
the COM3 the following data:
POWER UP TIME <time> DATE <date>
REMOTE MODE IDLE <time>
If something sent to stderr at this point, the program only gets to print
this data partially, even though it sends the whole chunk to COM3 at once
not by single character. So, it looks like redir intervenes with its output
to COM3 at this moment and shuts down any further access to COM3 for the
main program.
> Is this on Windows or in plain DOS? If the former, it might be some
> quirk of how Windows virtualizes the COM ports.
>
This is a plain DOS.
> What happens if you try "redir -ea COM3" instead of just -e?
>
Same thing.
> Does it help to open COM3 from your application in `append' mode?
>
I am not sure how to do that with PMCOM.
> Finally, do you really need `redir' at all? Why can't you redirect
> stderr to COM3 from within your application? You do have the sources,
> right?
Yes, that's correct, except one thing - I want redir to capture the crash
dump in case the application goes down and send it to the printer.
Thanks,
Alex
- Raw text -