> I am afraid I might incorrectly understand what is to be the
> _direction_ of the redirection: do you need DosEmu to see some
> streams as its COM port, or you need some COM port to be used
> as DosEmu input/output?
the former. perhaps a crash course in BBSing might help...
DOS BBS programs are unlike any Unix program. They have TWO inputs and TWO
outputs. The local screen (ie. the monitor)+keyboard, and the COM port (to
which the user has connected to via modem). All these programs write their
output twice, once to the local screen, and once to the com port.
And vice versa.
The local console is only ever used by the sysop (the guy that runs the BBS,
who is sitting at the physical machine). That means it has god powers - a
status bar with user info on it, and the ability to modify the user's
security and so on. if not for that there would be no problem - I could just
run all the BBS stuff in 'local mode' (ie. the program uses only the local
console - DOSEMU handles this just fine).
Normally, I can telnet to my machine, run DOSEMU and I'll see a DOS prompt -
DOS is assuming it's writing to the physical screen, and reading from the
physical keyboard - not my telnet session. And I assume that this is indeed
the case - DOSEMU has a screen buffer, and is sending it's contents across
to my terminal. Probably the same as the program 'screen' does.
This has to be somehow disconnected. The program will still need to write to
the screen buffer, but it will not be sent to my terminal. It will still
need to poll for keyboard input, but there will never be any.
So, DOSEMU has stopped reading/writing my terminal as though it were DOS's
console. What it needs to do instead is connect the COM port (that is, a
fake COM port within DOSEMU, not a real com port) to my terminal. So if I
type "foo" over my telnet session, those characters will be placed in the
incoming buffer on DOSEMU's COM port. If the program sends "bar" to the COM
port, those characters will be sent to my terminal.
clear as mud? :)
