Xref: utzoo gnu.misc.discuss:3229 comp.misc:12685 comp.dcom.modems:9981 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mdisea!mitchell From: mitchell@MDI.COM (Bill Mitchell) Newsgroups: gnu.misc.discuss,comp.misc,comp.dcom.modems Subject: Re: hayes lawsuit Message-ID: <1991May24.143702.19479@MDI.COM> Date: 24 May 91 14:37:02 GMT References: <9BDBC58@xds13.ferranti.com> <1991May17.222410.26944@MDI.COM> Sender: news@MDI.COM Organization: Motorola, Mobile Data Division - Seattle, WA Lines: 78 In article peter@ficc.ferranti.com (Peter da Silva) writes: >In article <1991May17.222410.26944@MDI.COM> mitchell@MDI.COM (Bill Mitchell) writes: >> Be fair now. > >Hard to do with my complexion. > >> The +++ mechanism allowed users and application writers to manipulate >> the modem without having to worry about how to twiddle hardware control >> lines. If you could talk _thru_ the modem, you could talk _to_ the >> modem. > >Like I said, it's a kludge that covers for an inadequate programming >interface to the hardware. Yup. That's what it is. Just what is needed when you attach the modem you've purchased from the modem hardware supplier to the computer system you purchased from a supplier who delivered it without any specific programming interface to that particular modem, and perhaps without any provision in the software or the hardware to manipulate modem control lines. You can use the hayes from the moment of installation if you have any kind of serial communications software (kermit, tip, cu, etc. on unix; kermit, telix, procomm, etc. on PC; kermit on most anything else) which allows you to connect your keyboard & display thru the computer to the modem. If the modem requires DTR/RTS to be twiddled and the hardware supports that, you may be able to use it once you've done some programming. You may have to throw out the communications program which you've been using to connect to external systems or devices thru hardwired serial lines if it doesn't support access to whatever provisions you implement to twiddle RTS/DTR and write or acquire one which does and retrain your users to operate the new program and redo existing applications using the old communications program to use the new one instead, but what the heck. Of course if your computer system hardware does not support manipulation of DTR/RTS lines at all you may have to upgrade it with new serial cards to make it compatable with your spiffy new modem, or perhaps just junk the whole system and buy one which is compatable with the modem. ............. In another recent article, gandrews@netcom.COM (Greg Andrews) writes: >[...] >several people have asked "why use the +++ escape when you can >use a Break or DTR instead?", and I'd like to bring up a point about >that. Your article was just the latest one I've seen on the topic - I'm >not really replying to your points directly. > >Probably the major reason for having a character-based signal to the modem >rather than using DTR or a Break is two-fold, and it's apparent when you >consider the state of modem communications when the Hayes modem was being >developed (mid-to-late 70's?): > > a) The same reason async communications became so popular in the first > place. You only need three wires in your cable and the circuitry for > async is correspondingly simpler and cheaper to design in computer > equipment. > > b) The entities who needed to grab control of the modem were people and > not machines, thus the mechanism needed to be something a human could > perform while using any of the popular terminals of the time. > >In short, if your terminal doesn't let you manipulate DTR or a Break signal >comfortably, then those methods will be useless. That was a very common >situation with terminals in those days. > >If you can't use an RS232 control signal or a Break signal, then you're >stuck with the normal keyboard characters available on standard terminals. >Therefore the choice of the plus sign as the default character, and the >need for an unusual interaction to signal your desire to chat with the modem. -- mitchell@mdi.com (Bill Mitchell)