Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-tis!ames!mailrus!cornell!uw-beaver!mit-eddie!ll-xn!adelie!munsell!atexnet!rhartman From: rhartman@atexnet.UUCP (Robert Hartman) Newsgroups: comp.sources.d Subject: Re: Remote control of PC via modem Message-ID: <9@swallow.atexnet.UUCP> Date: 15 Dec 88 16:23:41 GMT References: <4652@phoenix.Princeton.EDU> <104@unibase.UUCP> <190@serene.UUCP> <13246@ncoast.UUCP> Reply-To: rhartman@swallow.UUCP (Robert Hartman) Organization: EPPS (A Kodak Co.),Bedford,MA Lines: 61 In article <13246@ncoast.UUCP> allbery@ncoast.UUCP (Brandon S. Allbery) writes: >As quoted from <190@serene.UUCP> by rfarris@serene.UUCP (Rick Farris): >+--------------- >| In article <104@unibase.UUCP> root@unibase.UUCP (Super User) writes: >| >The basis of the solution is the 'ctty' command, which shifts the command >| >input/output from the keyboard/screen to a com port. >| >| You must be joking. Obviously you've never tried this. In theory, >| it works fine, but in practice it's useless. For instance the first >| time you press the backspace key, you'll crash the computer. Get >| Real. >+--------------- > >Speak for your own brain-damaged machine. I "bootstrapped" my Toshiba >laptop into being able to communicate by CTTY'ing it, running DEBUG, and >blasting DSZ.COM to it as DEBUG "E" commands. I did type backspaces >occasionally in setting it up, and it didn't crash. (For the curious: I >then sz'd Procomm 2.4.2 onto it and zapped DSZ; without a thorough test of >its VT102 compatibility I won't use *any* communications program.) The problem that was mentioned is quite real. As a BBS operator, we find such things pretty quickly, and also know the reasons it happens. In general, if the backspace key causes a machine to die during a CTTY session, it means that the system normally has a DOS command 'helper' like CED installed. This will undoubtedly cause the system to hang. Something inside CED doesn't like backspaces during CTTY. CTTY can also fail under DoubleDOS or DESQview if it is not handled properly, or early versions of either program are in use. Of course, CTTY COM1: will only get you into the BIOS polled mode, which will undoubtedly miss characters if you are used to using type ahead (how can anyone get along without that these days). There are however, MANY solutions: 1. There is a program called GATEWAY which will effectively do a CTTY COM1: for you when you call it with CTTY GATEWAY (or something like that). It has the added advantage of displaying everything on the local console also. It even interprets ASCII sequences. 2. In the FidoNet BBS world, there are things called "FOSSIL drivers". These drivers exist for MANY machines that are MS-DOS compatible (IBM, Rainbow, Tandy, Heath, etc), and give a standard interface to interrupt driven serial communications. When one of these programs is used in addition to gateway, it allows fully buffered, flow controlled access to the serial port. Much more useful than the normal polled mode. The two most popular versions of these programs for the PC are OPUSCOMM (generally found as OCOM_530.ARC) or X00 which can be found as X00_110.ARC (or something like that). As I mentioned, these programs are available for MANY different machines, and allow programs like the Fido BBS, UFGate (that Tim Pozar frequently mentions), and various other BBS programs and FidoNet mail front-ends to work on a wide variety of machines. BinkleyTerm for example (a FidoNet compatible mail front-end and terminal program) is known to be running on Victor 9000's, Rainbows, Tandy 1000's (and all other Tandy models that are MS-DOS machines), Sanyo 555's, and many other architectures that are not quite clones, but run MS-DOS. If you have a favorite Fido or Opus BBS system nearby, you can probably find the programs listed above. I no longer run a BBS, but rather run mail-only, so my system will not be of much help unless you have a FidoNet compatible system. If you do, I run node 1:132/101 and you can file request FILES to get a complete listing of what is available. Everyone should keep in mind that operations like running programs through serial ports is EXACTLY what BBS's do all the time. You may not like to admit it, but your local sysop might actually be a knowledge base that can help you solve problems dealing with serial ports.