🚀 go-pugleaf

In article <4619@umbc3.UMBC.EDU> cs202101@umbc5.umbc.edu.UUCP (cs202101) writes:
>In article <1182@ncis.tis.llnl.gov> roott@tis.llnl.gov (Tom Root) writes:
>>In ms-dos an internal command called "ctty" redirects "most" console
>>activities to a com port (1 or 2).  The problem is that it does NOT send
>>ALL output that would go to the screen to the com port (only non-graphic)
>>
>>I would like to know if anyone knows of a public domain or commercial program
>>that will "re-direct" ALL console and keyboard activity to the com (1or2) 
>>port
>The easiest solution that I can think of is to write your own redirection
>program in C, using dup2 to redirect the i/o.  Also, it sounds as though
>part of your problem might be that no redirection is being done for
>stderror.  
>
This is close to what CTTY does. CTTY redirects stdin, stdout, and stderr to
the specified character device. So far, so good. The real problems lies in 
the many meathods of communicating with the user under DOS. A program can
do one of the following:
	DOS for all I/O - Slow, but "portable". Will work with CTTY
	BIOS for screen I/O and DOS for keyboard I/O. Faster, but will
	not work with CTTY.
	BIOS for both. Faster yet, will not work with CTTY.
	Direct hardware access. Fastest, will not work with CTTY.

Being a long-time BBS operator, it's been the bane of myself and other
sysops that programs will sometimes and sometimes not run "over the wire".
There are programs which redirect the BIOS services in order to make other
applications run "over the wire: which would otherwise not do so. (Carbon Copy
for instance).  There is a public domain program which does this, but I 
cannot seem to dig up the name here right now...


Hope this helps...
Steve

-- 
----------------------------------------------------------------------------
steve.resnick@f105.n143.z1.FIDONET.ORG - or - apple!camphq!105!steve.resnick
Flames, grammar errors, spelling errrors >/dev/nul
The Asylum OS/2 BBS - (408)263-8017 IFNA 1:143/105.0