Emulation "How To" News and Discussion .............................................................................. One point often overlooked: terminal emulation is harder than it looks. An essential tool for checking the accuracy of a VT100 emulation is "vttest". http://invisible-island.net/vttest/vttest.html .............................................................................. *** *** A misunderstanding that frequently arises: *** how a real "terminal emulator" differs from a "screen scraper". *** A terminal emulator is a program for hands-on control of a terminal session, where the user is looking at a display and typing on a keyboard (or seeming to type on a keyboard, anyway, since this also can be emulated, with mouse clicks or other inputs). If, however, the computer is running a non-interactive program which is parsing the terminal datastream and feeding the extracted data to some programmatic interface for direct consumption by another program, then the setup is properly called a *screen scraper*. If you have not heard of this distinction, read what the Jargon file says: http://www.catb.org/~esr/jargon/html/S/screen-scraping.html These two types of programs share many properties, but calling them by their right names avoids confusion. ----**----**----**----**----**----**----**----**----**----**----**----**---- If you want to see some working source code for a program that emulates a simple type of video terminal, you can see Pascal code for a Hazeltine 1500 emulator here: http://www.cs.utk.edu/~shuford/terminal/hazeltine_m1_emul_src.zip ////////////////////////////////////////////////////////////////////////////// On the VT100 web site operated by Paul Williams, there is a description of a data-stream parser and finite state machine for VT100-style control codes: http://vt100.net/emu/dec_ansi_parser ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals Path: cs.utk.edu!darwin.sura.net!europa.eng.gtefsd.com!uunet!pipex!uknet !bradford.ac.uk!M.T.Shipley Message-ID: <1993Sep6.155625.24514@bradford.ac.uk> Organization: University of Bradford, UK References: Date: Mon, 6 Sep 1993 15:56:25 GMT From: M.T.Shipley@bradford.ac.uk (MT SHIPLEY) Subject: Re: VT100 Emulator: How To? Thomas Boutell (boutell@netcom.com) wrote: : : I need to write a simple VT100 emulator. I would appreciate any and all : pointers to source or, preferably, documentation on the subject of the : vt100 command set. I seem to recall having such a document years ago, but : alas, it's long since lost to me. Any help appreciated. Make what you will of the following, I've only a very short time to do a bit of typing/cut/paste. Soz. Basically, to implement an ANSI/VT100 type escape sequence interpreter, you need to... (a) parse the escape sequence; (b) decode the escape sequence; (c) execute the escape sequence and some housekeeping too. First, the way *not* to do it... I have seen a number of implementations of ANSI-escape-sequence interpreters, and some of these combine steps (a) and (b) into a single stage, as sort of a set of comparisons which need to be done one after another. The problem with this is that sequences which are not recognised (by your interpreter) sometimes give garbage characters on the screen. For example, Digital, with release 5 point-something-or-other of the VMS operating system started outputting the mouse enable/disable sequences when you went into the editor. Now, most (all?) VT100 terminals don't actually implement these sequences, and the ones that combine them give you some rubbish on the screen too. Either the ANSI standard or the DEC standard require you to IGNORE sequences that are not recognised, NOT output a load of rubbish on the screen and possibly mis-interpret the following sequence. Now, the way to do it (in my opinion) is... Parse the escape sequence, according to a small finite set of valid syntaxes (plural?). There are basically the following syntax forms: [the "16#" is a prefix to indicate hexadecimal radix] A control character A character in the range 16#00 .. 16#1F or 16#80 .. 16#9F A escape sequence A escape character, followed by zero or more intermediate character (16#20 .. 16#2F) followed by a final character (16#30 .. 16#7E) A control sequence A control sequence introducer character (16#9B) followed by zero or more parameter characters (16#30 .. 16#3F) followed by zero or more intermediate character (16#20 .. 16#2F) followed by a final character (16#40 .. 16#7E) A device control string A device control string introducer character (16#90) followed by zero or more parameter characters (16#30 .. 16#3F) followed by zero or more intermediate character (16#20 .. 16#2F) followed by a final character (16#40 .. 16#7E) followed by the data string followed by a string terminator character (16#9C) An operating system control string etc A privacy message etc An application control string etc A printable character glyph etc There are 8 bit equivalents of some 7 bit sequences... 7-Bit Sequence ---> 8-Bit C1 Control Character 1. Remove the ESC character 2. Add 16#40 to the final character 8-Bit C1 Control Character ---> 7-Bit Sequence 1. Insert an ESC character 2. Subtract 16#40 from the final character For example... DCS == ESC P ST == ESC \ I strongly suggested getting hold of a DEC manual (e.g., VT420 text programmers manual EK-VT420-RM) and the ANSI standards, to see the full set of syntaxes (plural?)/sequences. The parsing code may be implemented as a finite state machine, with either state table expressed as code or data. I.e., you may have a set of conditional comparison statements expressed as code, with jumps to the correct bit, or you may (like I do) simply use a state table, with the inputs being current state (soon to become the last state), and the character code, and the output being the new state. Various optimizations may be made here, for example, you could block/group/bunch who sets of characters that are always treated the same way up --- you'll see what I mean if you implement the table! Label (either implicitly or explicitly) each node and terminating or non terminating, and when you get a terminating node, decode it and execute it. Now it has been parsed, the output from the parse should be in nice variables, such as parameters, intermediate characters, final characters etc. class : classes; parameter_introductory_byte : unsigned_byte; parameter_count : 0..max_params; parameter_values : ARRAY [1..max_params] OF param_range; parameter_explicitly_specified : ARRAY [1..max_params] OF BOOLEAN; intermediate_count : 0 .. max_intermediate; intermediate_bytes : ARRAY [1..max_intermediate] OF unsigned_byte; final_byte : unsigned_byte; This can be done ether as two steps (decode, then execute), or as one (decode and execute in same part of code). For example, you may have a number of case statements... ................... CASE class OF class_ctrl : decode_ctrl; class_esc : decode_esc; class_csi : decode_csi; class_dcs : decode_dcs; class_data : decode_data; class_osc : decode_osc; class_pm : decode_pm; class_apc : decode_apc; class_printable : decode_printable END {CASE} ................... PROCEDURE decode_ctrl; CASE final_byte OF 16#00 : mnemonic := NUL; 16#01 : mnemonic := SOH; 16#02 : mnemonic := STX; 16#03 : mnemonic := ETX; 16#04 : mnemonic := EOT; 16#05 : mnemonic := ENQ; ................... PROCEDURE decode_esc; CASE intermediate_count OF 0 : CASE final_byte OF 16#60 : mnemonic := DMI; 16#61 : mnemonic := INT; 16#62 : mnemonic := EMI; 16#63 : mnemonic := RIS; ................... PROCEDURE decode_csi; CASE intermediate_count OF 0 : CASE final_byte OF 16#40 : mnemonic := ICH; 16#41 : mnemonic := CUU; 16#42 : mnemonic := CUD; 1 : CASE intermediate_bytes[1] OF 16#20 : CASE final_byte OF 16#40 : mnemonic := SL; 16#41 : mnemonic := SR; 16#42 : mnemonic := GSM; 16#43 : mnemonic := GSS; 16#2B : CASE final_byte OF 16#70 : mnemonic := DECSR; {VT420} 16#71 : mnemonic := DECELF; {VT420} 16#72 : mnemonic := DECSMKR; {VT420} ................... Now just execute it! The advantage with this approach is that sequences which are not recognised are ignored, with no garbage output the the screen. : -T : -- Martin : "The funnels provide the deep base and rhythm boutell@netcom.com : And all the utensils are dancing; : All rubbing together and clinking. Such pleasure : To be out- of- drawers and romancing!" -- Zvi Gilbert Well, that ones foxed me! ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals Path: cs.utk.edu!emory!europa.eng.gtefsd.com!uunet!pipex!uknet!bradford.ac.uk !M.T.Shipley Message-ID: <1993Sep6.202256.29874@bradford.ac.uk> Organization: University of Bradford, UK References: <26fqra$6k7@vixen.cso.uiuc.edu> Date: Mon, 6 Sep 1993 20:22:56 GMT From: M.T.Shipley@bradford.ac.uk (MT SHIPLEY) Subject: Re: VT100 Emulator: How To? John Cavanaugh (cavanaug@cogsci.uiuc.edu) wrote: : > : > Parse the escape sequence, according to a small finite set of valid : > syntaxes (plural?). : I was wondering if you could do all this lexing and parsing using lex : and yacc. That way (a) & (b) above are handled for you, all you would : have to do then is develop the lex and yacc definition files and write : (c). The first time I read this, I though that you suggested writing using the C language, but now, on read-reading, I see you mean my option (c). Anyway, for those wanting to travel to new ground and foreign parts, while being able to see (ha ha), and at the same time, use Pascal (or not use the output language of most lex/yacc systems), you may have a look at the Turbo Pascal version of lex/yacc, called something like TPLY30A1.ZIP and TPLY30A2.ZIP from simtel20 and friends (I saw it on oak.oakland.edu). Anyway, even though I never see a line of Lex/Yacc, a friend uses it and from his comments in the past, you may (likely) will be able too, **but** since the set of possible syntax thingies (what do we call 'em?) is quite small, you it ain't too much of a problem anyway, and the decoding only takes one like for each mnemonic, so maybe there's not a lot in it! : Has anybody done this before??? Bet they ain't done using the Pascal lex/yacc. Time to break new ground! : -John Cavanaugh Martin PS Can someone tell me how to change the stupid from "MT SHIPLEY" to something nicer, such as "Martin T Shipley" etc, using "tin" newsreader, without having to get systems admin to do it. ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals Path: cs.utk.edu!darwin.sura.net!news-feed-2.peachnet.edu!concert !news-feed-1.peachnet.edu!umn.edu!msus1.msus.edu!news.gac.edu!news!scott Message-ID: From: scott@flash.gac.edu (Scott Hess) Date: 12 Sep 93 20:17:11 References:<1993Sep6.155625.24514@bradford.ac.uk> Subject: Re: VT100 Emulator: How To? : <26fqra$6k7@vixen.cso.uiuc.edu> : NNTP-Posting-Host: flash.gac.edu : In-reply-to: cavanaug@cogsci.uiuc.edu's message of 6 Sep 1993 17:08:58 GMT In article <26fqra$6k7@vixen.cso.uiuc.edu> cavanaug@cogsci.uiuc.edu (John Cavanaugh) writes: I was wondering if you could do all this lexing and parsing using lex and yacc. That way a) & b) above are handled for you, all you would have to do then is develop the lex and yacc definition files and write c). I don't think you can do this (reasonably). One large problem is that any VT100 escape sequence can have embedded control characters. For instance, "ESC [ NL m" executes as "NL ESC [ m". What you could do, I suppose, it to write a multi-layered beastie to handle pulling the control characters to the front of the escape sequences (except for CAN and other control chars that cancel the sequence). Another problem is that you usually need a pretty interactive system, which will be interesting to hack into a Lex/Yacc setup. Worse, you don't even get some fundamental "unit" of input - if you get partial input, you have to buffer it and save it until you _do_ get an entire escape sequence. Annoying. Anyhow, it probably could be done. I'm not certain if it's worth all that much, though, since the parsing isn't really all that hard. In fact, the parsing is really pretty trivial. The hard part is getting the things that happen due to the parsed information correct. Later, -- scott hess 12901 Upton Avenue South, #326 Burnsville, MN 55337 (612) 895-1208 Anytime! ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals,comp.os.vms Path: cs.utk.edu!stc06.CTD.ORNL.GOV!fnnews.fnal.gov!uwm.edu!lll-winken.llnl.gov !decwrl!svc.portal.com!portal.com!cup.portal.com!Chris_F_Chiesa Date: 2 Feb 1995 11:20:10 -0800 Sender: pccop@unix.portal.com Message-ID: <132149@cup.portal.com> References: <3f4g3g$1mp@bert.ga.com.au> From: Chris_F_Chiesa@cup.portal.com Subject: Re: Pathworks VT320 vs VT100 ...whereas MY experience with "VT100" emulators suggests that many, maybe even most, lack some fundamental capability: the ability to respond to an auto-identification query, the ability to perform certain screen or cursor operations, the ability to transmit appropriate "editing keypad" escape sequences, etc. The more layers (in this case Pathworks, plus whatever transport(s) it is using to reach the VMS system) between the emulator and the application, the more likely it is that some layer will intercept an otherwise "vanilla" keycode and use it for its own purposes, or conversely will insert its own background data into the stream without bothering to inform the user. (My experience includes VAX and AXP VMS DECwindows/Motif "DECterm," SGI Irix "console" and "Unix shell," Macintosh MacTerminal and Red Ryder, numerous MS-DOS and MS-Windows terminal emulators including Qmodem, Procomm, MS-Kermit and others, and several Amiga- and (cringe) Atari-800-based emulators. Of these, DECterm is definitive, MacTerminal, MS-Kermit, and "Kermit-65" on the Atari, are the only sufficiently complete emulations to receive my stamp of approval, and pretty much everything else I've seen is pure crap.) Beware. Chris Chiesa Chris_F_Chiesa@cup.portal.com ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals Path: cs.utk.edu!stc06.CTD.ORNL.GOV!fnnews.fnal.gov!uwm.edu!news.alpha.net !news.mathworks.com!transfer.stratus.com!xylogics.com!Xylogics.COM!carlson Organization: Xylogics Incorporated Message-ID: <3hste4$jpg@newhub.xylogics.com> References: <3hpc0n$1do@senator-bedfellow.MIT.EDU> Keywords: DEC VT100 VT200 VT240 Date: 15 Feb 1995 12:52:20 GMT From: James Carlson Subject: Re: DEC private modes fot VT series. In article <3hpc0n$1do@senator-bedfellow.MIT.EDU>, igorlord@athena.mit.edu (Igor Lyubashevskiy) writes: |> |> Hi. I am trying to write a VT200 emulator, and my manual does not make |> it clear the exact format of what it calls Ps;Ps;... sequences with DEC |> private modes. |> |> For example, when CSI ? 2 ; 4 h is recieved, is it equivalent to |> CSI ? 2 h and CSI 4 h or |> CSI ? 2 h and CSI ? 4 h ? |> |> Please if you can help me, email to me or followup to this group. "CSI ? 2 ; 4 h" is equivalent to "CSI ? 2 h CSI ? 4 h". The flags (like the '?' character) are global within a single CSI sequence. Since the command isn't actually dispatched until the 'h' is received (flags are saved in a bit vector and the decimal arguments are saved in an array along with a present/omitted flag which is needed on the VT220 because the set-scroll-region command has a default of max-lines for the second argument), the '?' flag can appear anywhere. For example, this is a sequence equivalent to the one above, even if it is a bit strange looking: CSI 2 ; ? 4 h A properly-functioning VT100/VT200 emulator jumps from "character" state to "csi argument gathering" state when CSI is received, and then jumps through a dispatch table when a code in the range 40-7E (hex) is received. This allows ESC, CSI, CAN and SUB to terminate the sequence prematurely without altering any other variables, and it allows LF, VT, FF, CR, TAB and ENQ to be dispatched in the middle of the CSI argument list without changing state. For example, this is a perfectly legal VT command -- it goes down one line and right two characters: CSI 2 LF C When the LF is received, the cursor is moved to the next line (and a scroll happens if necessary), but the CSI state isn't touched. When the 'C' is received, the cursor is moved two characters to the right because the CSI sequence is dispatched at that point. The "correct" implementation is thus a big loop which dispatches all of the incoming data based on a state machine. It is *NOT* correct to build a CSI-argument-parser which calls the (blocking) character-read function directly. This is almost guaranteed to fail, and I've seen this done in too many poorly-implemented PC-based emulators. The dispatch loop must call the parser instead. The vttest program will test for compliance with all of this. You can find it at an FTP site near you. I made heavy use of this when I was designing terminals at Data General. (I wanted to get DG to make a contribution to the author, but I was never able to locate him. Sigh.) --- James Carlson Tel: +1 617 272 8140 Annex Software Support / Xylogics, Inc. +1 800 225 3317 53 Third Avenue / Burlington MA 01803-4491 Fax: +1 617 272 2618 ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.databases.pick Path: cs.utk.edu!stc06.ctd.ornl.gov!fnnews.fnal.gov!mp.cs.niu.edu !vixen.cso.uiuc.edu!howland.reston.ans.net!news.sprintlink.net !matlock.mindspring.com!francisc.mindspring.com!francisc Date: Mon, 8 May 1995 11:18:39 gmt Message-ID: References: <3oii76$qb7@fitzherbert.pavilion.co.uk> <3oj4uk$a54@news.primenet.com> From: francisc@mindspring.com (Francis Carden) Subject: Re: New IPX terminal to replace Piclan wanted >Is there any reason that there cannot be an int 14 compatible hook so that >the wide world of terminal emulators that run under Novells various >systems could be used. Then one could load a layer between Piclan and the >worlds emulators, rather than the rather limited Pick choices? Novell's >Netware connect or NASP (i think) supports terminals over the network >and serial connection, and products that communicate with these things >could be fooled into talking to Piclan instead. >I don't think a user will write a terminal emulator. We leave such chores >up to guys like Luke Webber to do these things (listening Luke?). The rest >of us would like Procomm or such when there are a few extra features >to be used, and not have to rewrite an emulator from the ground up to get >what we want. >Jim >-- >----------------------------------------------------------- >Jim Stephens jws@world.std.com Irvine, Ca >url ftp://www.std.com/pub/jws/jws.html >----------------------------------------------------------- INT 14 is an effective way of supporting lots of networks, we've had it in TERMiTE for many many years. However, it's very inefficient, it cripples other resources on the desktop, does not allow multiple sessions and locks up ports frequently. Doug, what's your view ? Francis Carden Pixel (TERMiTE) Atlanta ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.protocols.kermit.misc Path: cs.utk.edu!news.msfc.nasa.gov!elroy.jpl.nasa.gov!swrinde!cs.utexas.edu !news.cs.utah.edu!cc.usu.edu!jrd Message-ID: <1995Jun19.100536.54278@cc.usu.edu> Date: 19 Jun 95 10:05:36 MDT References: Organization: Utah State University From: jrd@cc.usu.edu (Joe Doupnik) Subject: Re: cursor In article , romani@email.unc.edu (David Romani) writes: > > Folks, > > Does any one know of any way to turn the terminal cursor blink off, or > even just off (as opposed to set terminal cursor block or underline). It > is a setup feature on VT420 terminals and I have a user who is _very_ > interested in doing it in MS-Kermit 3.14. So far the I have found DOS > level utils that let me control the cursor in DOS and will supress the > cursor at the MS-Kermit prompt, but not once I connect. ---------- The IBM PC display adapter hardware controls cursor blinking, and there are no blinking controls available in the hardware. The DOS utils to which you refer are trying to play games with character sets and hooking the timer tick interrupt to include and then make invisible the cursor and so on; they can't control the real cursor blinking because there isn't any control. Sorry to report this, but the question comes up every few months and there isn't a satisfactory solution. Joe D. ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals,comp.protocols.misc Path: cs.utk.edu!stc06.ctd.ornl.gov!fnnews.fnal.gov!usenet.eel.ufl.edu !tank.news.pipex.net!pipex!news.mathworks.com!newsfeed.internetmci.com !news.sesqui.net!uuneo.neosoft.com!nmtigw!zuul.nmti.com!peter Date: 2 Jan 1996 23:12:20 GMT Organization: Network/development platform support, NMTI Message-ID: <4cce4k$ap3@zuul.nmti.com> References: <48mlt7$5i9@tools.bbnplanet.com> <487nql$rfi@kannews.ca.newbridge.com> <49fr70INN6fp@duncan.cs.utk.edu> Keywords: X3.64, VT100, ANSI From: peter@nmti.com (Peter da Silva) Subject: Re: ANSI X3.64 alias In article <49fr70INN6fp@duncan.cs.utk.edu>, Richard Shuford wrote: > | Sometimes it's the small differences that really screw programs up! > Yup. That's why programming is hard. Particularly Vt100 emulators. I wrote a state-machine emulation of VT100, so I could run VT100 software on Televideo terminals. I got it to the point where it'd survive the VT100 torture test (I didn't bother implementing things like double-wide and double-height), but damn, there's a lot of things VMS and RSX software do, which you have to check for, that are not documented anywhere. -- Peter da Silva (NIC: PJD2) `-_-' 1601 Industrial Boulevard Bailey Network Management 'U` Sugar Land, TX 77487-5013 +1 713 274 5180 "Har du kramat din varg idag?" USA Bailey pays for my technical expertise. My opinions probably scare them ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals Path: cs.utk.edu!gatech!news.mathworks.com!nntp.primenet.com!news.asu.edu !ennfs.eas.asu.edu!cs.utexas.edu!usc!news.cerf.net !nntp-server.caltech.edu!dacut From: dacut@ugcs.caltech.edu (David A. Cuthbert) Subject: Re: VTXXX question (which one should be emulated) Date: 16 Aug 1996 04:22:03 GMT Organization: California Institute of Technology Message-ID: <4v0t1b$fu1@gap.cco.caltech.edu> References: <4uhi01$h45@rhino.cis.vutbr.cz> <4uu7p7$p6a@apakabar.cc.columbia.edu> Jeffrey Altman wrote > > Why create yet another terminal emulation package when there are so many > already available? Not speaking for the original poster, but I can think of a number of such cases. For example, if you have a small target electronics board that implements additional functions (e.g., uploading configuration information) that won't be present in the final version (so your customer can use a standard terminal). Non-standard network communications. There's a lot of "special case" software needs out there. Perhaps what is really needed is an interpretation library (class, or whatever); you tell it what functions are used to position the cursor, print text, etc., and it handles the VT emulation. -- David A. Cuthbert dacut@ugcs.caltech.edu ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals Path: utkcs2!stc06.ctd.ornl.gov!fnnews.fnal.gov!uwm.edu!news-peer.gsl.net !news.gsl.net!news.mathworks.com!news.maxwell.syr.edu !news.cis.ohio-state.edu!nntp.sei.cmu.edu!fs7.ece.cmu.edu!dacut Date: 6 Mar 1997 08:06:51 GMT Organization: Elect. & Comp. Eng., Carnegie Mellon University Message-ID: <5fltur$gh7@fs7.ece.cmu.edu> References: From: dacut@henry.ece.cmu.edu (David A. Cuthbert) Subject: Re: vt100 development toolkits Jon A Phillips wrote: > > We are looking for a VT100 family terminal emulation development toolkit. > We need the toolkit to be an API using the C programming language. The API > needs to be compiled rather than interpeted. UnixWare 1.1.2 and > needs to be compiled rather than interpeted. UnixWare 1.1.2 and > UnixWare 1.2 (SCO UNIX) are the platforms the API will be compiled on. > The toolkit needs to be able to read and write VT100 screens. I don't know of any such toolkits around (I was looking for something that would run in *any* environment). I finally wrote my own. If you (or anyone else here) happens to run into the same problem, let me know and I'll toss the source code your way. It doesn't quite fit what you're looking for -- it is Win32 C++ code that is telnet- oriented. It shouldn't be too much of a pain to port to generic C, and will at least provide a starting point. It is fairly well debugged (I am sending this using that code displaying an emacs window, which has horrendous scroll-backwards commands, etc.). ////////////////////////////////////////////////////////////////////////////// As of spring 1997, Distinct Corporation has both a Telnet toolkit and a VT220 toolkit for sale. http://www.distinct.com/ ----**----**----**----**----**----**----**----**----**----**----**----**---- ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals, comp.arch.embedded Message-ID: References: <5i1p56$ndv$1@europa.frii.com> <3345b5c4.216988993@news.alt.net> <5i3jag$ete$1@apakabar.cc.columbia.edu> <3349f864.73849399@news.netcomuk.co.uk> <5i6305$h7f@baygull.rtd.com> Date: 07 Apr 1997 08:57:16 -0400 From: James Carlson Subject: Re: Q: what terminal emulations would you want supported? In article <5i6305$h7f@baygull.rtd.com> dgy@rtd.com (Don Yuniskis) writes: [...] > (assuming you're too lazy to hard code it). Toughest part is > putting timeouts on the ESC characters (since that usually needs > some amount of driver/O.S. support)... Timeouts on the ESC characters? I hope you're referring to possibly adding a longish delay after sending ESC from the keyboard "Esc" key for compatibility with broken curses implementations. Otherwise, this would be a bad thing to do. VT-series terminals operate by running a single state machine over the input, not by doing a read-character/call-function type of implementation. If you can't handle a LF in the middle of a CSI, then the implementation is broken. -- James Carlson , Prin Engr Tel: +1 508 916 4351 Bay Networks - Annex I/F Develop. / 8 Federal ST +1 800 225 3317 Mail Stop BL08-05 / Billerica MA 01821-3548 Fax: +1 508 916 4789 ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals,comp.arch.embedded Organization: Bay Networks, Inc. Message-ID: References: <5i1p56$ndv$1@europa.frii.com> <3349f864.73849399@news.netcomuk.co.uk> <5ie3v9$kdi@baygull.rtd.com> Date: 09 Apr 1997 08:01:56 -0400 From: James Carlson Subject: Re: Q: what terminal emulations would you want supported? In article <5ie3v9$kdi@baygull.rtd.com> dgy@rtd.com (Don Yuniskis) writes: > >Timeouts on the ESC characters? I hope you're referring to possibly > >adding a longish delay after sending ESC from the keyboard "Esc" key > >for compatibility with broken curses implementations. > > Typically, ESC must be followed by the remaining characters (well, at least > the *next* character) in a multicharacter escape sequence within a one second > window to be recognized as an ESCape sequence as opposed to the ESCape > key itself. I haven't seen many (small) embedded systems that implement > a "complete" tty driver with support for things like MIN and TIME. I haven't seen any terminals or terminal emulators that do this. This is generally a necessary function on the *host* side, not the *terminal* side of communications. The data sent to terminals is quite a bit different from the data sent to hosts. The worst part of the data sent to hosts is that ESC is unfortunately used by a number of applications, and this makes 7-bit C1 sequences ambiguous without a timer. No such ambiguity exists on the terminal side of things. > >Otherwise, this would be a bad thing to do. VT-series terminals > >operate by running a single state machine over the input, not by doing > >a read-character/call-function type of implementation. If you can't > > Yes, but will (for example) a VT-100 wait "forever" after receiving > an ESC for the balance of the escape sequence? Hmmm... I guess it > *could* since it doesn't have anything *else* to use the ESC for... > (which is different from curses trying to distinguish ESC from, > for example, KEY_LEFT) Yes, it does wait forever. There's no reason for the host system to send a "bare" escape to a terminal -- ever. It would have no meaning. > >handle a LF in the middle of a CSI, then the implementation is broken. > > Hmmm... I didn't realize LF was ignored in a CSI. I had assumed > that *all* characters (except flow control) were expected *literally* > in these sequences! No, it's not at all ignored, nor is it treated as a literal. If you send, for example, the sequence "ESC [ LF C", then the terminal will move the cursor down one line (scrolling if necessary) and then to the right one position (stopping at the right margin if necessary). That's why you have to implement it with a centralized state machine, rather than distributed read routines. The C0 sequences are still active in the middle of an ANSI control sequence. (And ignoring this fact is why so many of the PC-based emulators that are available are very poorly done and not quite compatible. If the implementors at least tested against "vttest," this common bug would be caught.) Flow control is done at a conceptually lower layer. It can appear anywhere in the "data," and should be handled separately by the input driver. (Though I suppose a careful implementation could also do it in the central state machine.) -- James Carlson , Prin Engr Tel: +1 508 916 4351 Bay Networks - Annex I/F Develop. / 8 Federal ST +1 800 225 3317 Mail Stop BL08-05 / Billerica MA 01821-3548 Fax: +1 508 916 4789 ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals, comp.arch.embedded Date: 09 Apr 1997 08:02:52 -0400 Message-ID: From: James Carlson Subject: Re: Q: what terminal emulations would you want supported? In article <334c8cb1.373958233@news.netcomuk.co.uk>, z80@dserve.com (Peter) writes: > >Timeouts on the ESC characters? I hope you're referring to possibly > >adding a longish delay after sending ESC from the keyboard "Esc" key > >for compatibility with broken curses implementations. > [...] > Not having a timeout means that ESCape characters could never be sent > to the application, e.g. to exit from menus etc. That's a host function, not a terminal function. Hosts never send a bare escape to a terminal. It's not a legal command for anything. -- James Carlson , Prin Engr Tel: +1 508 916 4351 Bay Networks - Annex I/F Develop. / 8 Federal ST +1 800 225 3317 Mail Stop BL08-05 / Billerica MA 01821-3548 Fax: +1 508 916 4789 ////////////////////////////////////////////////////////////////////////////// Date: Wed, 09 Apr 1997 09:22:50 -0400 From: Jerry Leichter Message-ID: <334B982A.36F9@smarts.com> To: z80@digiserve.com Newsgroups: comp.terminals, comp.arch.embedded Subject: Re: Q: what terminal emulations would you want supported? | >Timeouts on the ESC characters? I hope you're referring to possibly | >adding a longish delay after sending ESC from the keyboard "Esc" key | >for compatibility with broken curses implementations. | | When implementing a VT100 emulator, one needs to implement a timeout, | typically tens of ms, on the ESC character, so that e.g. | | ESC [ M | | (sent without any large gaps) is interpreted as such (I made up that | ESCape sequence, BTW) whereas someone typing | | ESC | | (done with a finger, so obviously followed by a long gap) is taken as | a single character which is to be passed on to the application. Incorrect, in every possible way. a) People can, and do, type keys one after another very quickly. b) No ANSI terminal guarantees anything about how quickly it will send the constituents of an outgoing escape sequence. In practice, they *usually* send them quickly, but this is certainly not guaranteed. c) No ANSI terminal, and no application, can possibly guaranteed the performance of the comm line between the terminal and the host. If the comm line is simply slow - seems hard to believe now, but 300 bps = about 30 cps used to be common for modems. People can easily type that fast in bursts. Today, *everything* but hardwired connections is packetized. What happens when ESC goes in one packet, and the rest of the sequence in the next - and the second packet gets delayed, or lost? | Not having a timeout means that ESCape characters could never be sent | to the application, e.g. to exit from menus etc. Correct. Properly designed applications should not rely on timeouts to distinguish between ESC and escape sequences. Thus, they should not use bare ESC to mean *anything*. Such usage is incompatible with the ANSI definitions. Yes, this is a common design. Yes, it works 99.9999+% of the time with no problems. But it *will* fail every once in a while, and when it does, the fault is the *application* designer's, not the terminal or terminal emulator or host interface designer's. The relevant standards date back to, what, 1974? If you insist on ignoring them, it's at your own peril. (BTW, it was exactly to try to wean people from such interfaces that the DEC VT200 and later terminals removed the ESC key from the keyboard. Yes, you can still generate ESC, but it takes a deliberate action. There are plenty of other function keys available. Pick one!) -- Jerry ............................................................................ [ARCHIVER'S NOTE: Obviously Bill Joy wasn't thinking about such things when he designed the vi editor. But some would say that "vi" is the heart of "EviL". ...RSS] ////////////////////////////////////////////////////////////////////////////// Date: 9 Apr 1997 00:05:45 GMT From: Don Yuniskis Newsgroups: comp.terminals, comp.arch.embedded Subject: Re: Q: what terminal emulations would you want supported? In article <5iejer$133$1@apakabar.cc.columbia.edu>, Frank da Cruz wrote: >In article <5ie1da$k74@baygull.rtd.com>, Don Yuniskis wrote: [stats of kermit slower than zmodem on transfer of gzip'ed file snipped] >But, since ZMODEM works on this connection, then Kermit with "full >unprefixing" will also work. I should point out that the current version >of C-Kermit is 6.0.192 and you can pick it up at: > > http://www.columbia.edu/kermit/ck60.html (groan) Sorry, I don't have the time to do another port :-/ It's more than a full-time job just keeping all the *other* software packages running, configured, etc. :-( >With this version in hand, just give the FAST command prior to transfer >and it will unprefix most control characters (give this command to the >file sender). (The FAST command actually uses a fairly conservative form >of unprefixing, but you can make it less conservative -- which, again, is >probably safe on this particular connection since Zmodem works there -- >with SET PREFIXING MINIMAL.) Can I do something like PREFIXING OFF (sorry, I'm not on a UN*X box currently so can't recall the exact kermit commands) with the 190 version? I'll have to dig up my .kermrc and see what it spells out currently... And, for what scenarios does kermit have to be more conservative than ZModem? (sorry, poorly phrased). In other words, why are you qualifying your statements with "since ZMODEM works there"? In which of these (dialup) conditions would ZMODEM *not* work yet kermit provide me a workaround? >: So, as a TERMINAL EMULATION, what exactly is your suggestion intended to >: contribute to this guy? >: >Something along the lines of: a good terminal emulator is not something you >can knock off in a week, or a month, nor is it something that will fit into a >few K of memory -- especially if it is for a fairly high-level terminal like >VT320, Wyse 60, SCOANSI, etc -- the ones most people want. Even a good VT100 >emulator is not that easy to find: run your 10 favorite VT100 emulators >through VTTEST and see how they score. That, of course, depends on what the original poster was looking for. I use a *real* VT-100 since I find most (fill in the blank) emulators have *some* quirks, and if I'm designing a product that is advertised to work with a VT-100, I want to be damn sure that it *does* work with a VT-100 (and I don't particularly care if it bombs out with some no-name clone/emulator/etc.). Actually, I reread the original post and it appears the original poster was NOT (necessarily) looking to *write* a terminal emulator for use in an embedded product (as I had ASSuMEd :-( In fact, he was looking for info on what terminal emulations to *support* *if* you were writing a terminal emulator for use by embedded systems, etc. I *guess* that's another beast entirely... To answer that question, I would say "VT-100" (assuming you want to pick *just one*). Keeping in mind that many embedded products have to talk to legacy systems, etc. So, even a VT-220 could be "too new". --don ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals, comp.arch.embedded Message-ID: <5igq7l$269$1@apakabar.cc.columbia.edu> Date: 9 Apr 1997 19:21:25 GMT From: Frank da Cruz Subject: Re: Q: what terminal emulations would you want supported? In article <5iemgp$p05@baygull.rtd.com>, Don Yuniskis wrote: : In article <5iejer$133$1@apakabar.cc.columbia.edu>, : Frank da Cruz wrote: : >In article <5ie1da$k74@baygull.rtd.com>, Don Yuniskis wrote: : : [stats of kermit slower than zmodem on transfer of gzip'ed file snipped] : : >But, since ZMODEM works on this connection, then Kermit with "full : >unprefixing" will also work. I should point out that the current version : >of C-Kermit is 6.0.192 and you can pick it up at: : > : > http://www.columbia.edu/kermit/ck60.html : : : (groan) Sorry, I don't have the time to do another port :-/ But you don't have to -- it's most likely already done for you. I keep referring to this Web page because it lists (among other things) several HUNDRED prebuilt UNIX binaries, and quite a few of them already in "install package" form (Linux, AIX, etc). : Can I do something like PREFIXING OFF (sorry, I'm not on a UN*X box : currently so can't recall the exact kermit commands) with the : 190 version? I'll have to dig up my .kermrc and see what it : spells out currently... There is a coarse control available in version 6.0 only: SET PREFIXING { ALL, CAUTIOUS, MINIMAL, NONE } by which Kermit picks out selected control characters to prefix/unprefix, and there is a fine-grained control available in 5A(189) and later: SET CONTROL { PREFIX, UNPREFIX } { ALL, } By which you can can control the prefixing of each control character. And then there is is the FAST command (6.0 only), which does an implicit SET PREFIXING CAUTIOUS along with selecting a big packet and window size -- in other words tuning Kermit for fast transfers in one simple command. : And, for what scenarios does kermit have to be more conservative than ZModem? Going through a terminal server or to a host that has limited buffer space and/or inadequate flow control. Using a modem connection that is not error corrected. Using a lossy network connection on the New Internet. Using a long-distance connection that has long delays. Using a noisy (non-error- corrected) connection. Using a connection that is not transparent to every single control character (52 of them) -- and that includes just about every terminal server. Transferring files over a Telnet connection when the server does not know it's a Telnet connection (and so does not prefix 0xFF). Using a half-duplex connection (there are such things). And on and on and on. : (sorry, poorly phrased). In other words, why are you qualifying your : statements with "since ZMODEM works there"? In which of these (dialup) : conditions would ZMODEM *not* work yet kermit provide me a workaround? : See above. The most typical example is this: You are logged in to the host through a terminal server, whose escape character is (say) Ctrl-^ (ASCII 30) (or any other control character). Another less obvious example, but it happens: you are dialed up using a Hayes-like modem that does not implement "guard time" around its escape sequence (because the manufacturer did not want to pay the license fee). If your file contains +++, the modem pops back to command mode. Only a very small subset of all the connections people make are *totally* transparent. - Frank ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals, comp.arch.embedded Date: 9 Apr 1997 19:15:51 GMT Message-ID: <5igpt7$dbn@baygull.rtd.com> From: Don Yuniskis Subject: Re: Q: what terminal emulations would you want supported? Tim Shoppa wrote: >In article <5ie3v9$kdi@baygull.rtd.com>, Don Yuniskis wrote: >>In article , wrote: >>>Timeouts on the ESC characters? I hope you're referring to possibly >>>adding a longish delay after sending ESC from the keyboard "Esc" key >>>for compatibility with broken curses implementations. >> >>Typically, ESC must be followed by the remaining characters (well, at least >>the *next* character) in a multicharacter escape sequence within a one second >>window to be recognized as an ESCape sequence as opposed to the ESCape >>key itself. > >Huh? This is a rather bizarre behavior, and one I've never >found with any real terminal. Sorry, I was talking from the viewpoint of the *other* end of the wire (i.e. having written code that had to distinguish ESC from KEY_LEFT) This is, in fact, how curses differentiates between ESC and KEY_LEFT, etc. When *emulating* a (true) VT-100 keyboard, there are many applications that (unfortunately) *expect* there to be no delay between the characters in a multibyte escape sequence. A VT-100 does not introduce a delay so faithfully reproducing a function key, arrow key, etc. requires a true terminal emulator to do likewise. Doing this on a PC in damn near *any* kind of terminal emulator is not possible (to *guarantee*) even if you code things in assembler. Unless you are prepared to disable interrupts, etc. since the disk cache, scheduler, etc. could easily preempt you and introduce a delay... I've often thought of coding such an application just to be able to NOT have to lug VT-100's around. But, doing so in a truly portable way is more work than it's worth -- considering the fact that you couldn't even trust the BIOS since it can't be fully characterized, etc. Easier to build something that does what you want. And, if faced with *that* alternative, it's easier to just throw a VT-100 in your trunk! :> >>>Otherwise, this would be a bad thing to do. VT-series terminals >>>operate by running a single state machine over the input, not by doing >>>a read-character/call-function type of implementation. If you can't >> >>Yes, but will (for example) a VT-100 wait "forever" after receiving >>an ESC for the balance of the escape sequence? > > >Yes, it will. > >Come on guys, there are enough crappy terminal emulators out there >already. Please don't go pontificating about how you think a >VT-100 *ought* to work - just find a real one and figure out how >it *actually does* work. I have two of them sitting beside me and just need to scrounge up a null modem cable, thankyouverymuch! I distrust damn near *all* terminal emulators... --don ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals, comp.arch.embedded Date: 9 Apr 1997 22:07:23 GMT Message-ID: <5ih3ur$931$1@apakabar.cc.columbia.edu> From: Jeffrey Altman Subject: Re: Q: what terminal emulations would you want supported? In article <5igr8o$dgn@baygull.rtd.com>, Don Yuniskis wrote: > ... [everything said deleted] Before anybody else continues this thread, let's all take our VT100 off the shelf and performing the following test: place the terminal in local echo mode press the ESC key go to eat a meal return some time later press [ press C (or any other valid cursor movement sequence--they are easy to see the effect) and then let's report whether or not VT terminals use timeouts. Since I have already performed this test, the answer is they don't. And since the terminal doesn't care how long it takes a user the type the Escape sequence as long as it is valid, neither should an application. Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 The Kermit Project * Columbia University 612 West 115th St #716 * New York, NY * 10025 * (212) 854-1344 http://www.columbia.edu/kermit/k95.html * kermit-support@columbia.edu ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals, comp.arch.embedded Date: 10 Apr 1997 00:37:17 GMT Message-ID: <5ihcnt$hn0@baygull.rtd.com> From: Don Yuniskis Subject: Re: Q: what terminal emulations would you want supported? In article <5ih3ur$931$1@apakabar.cc.columbia.edu>, Jeffrey Altman wrote: >In article <5igr8o$dgn@baygull.rtd.com>, Don Yuniskis wrote: > > >before anybody else continues this thread, lets all take our >VT100 off the shelf and performing the following: I thought we already established this? >or any other valid cursor movement sequence (they are easy to see the effect) >and then lets report whether or not VT terminals use timeouts. > >Since I have already performed this test, the answer is they don't. >And since the terminal doesn't care how long it takes a user the type >the escape sequence as long as it is valid, neither should an application. I don't see "applications" running *in* the VT-100. Reread your statement: just because the VT-100 will wait forever for an escape sequence, doesn't mean an *application* -- which is NOT a VT-100 -- should wait forever for a multicharacter key sequence! (note the difference between sequences *interpreted* by the VT-100 vs. keys *generated* by the VT-100 -- data flows two ways!) An "application" (running in a mainframe, PC, embedded product or a pay telephone!) can chose to deal with characters *from* a VT-100 in whatever way it damn well pleases! *If* an application wants to differentiate between ESC and KEY_LEFT, it can make whatever it considers as a "valid attempt" to do so. There's very little the VT-100 can do to change its mind! The fact is, there are *lots* of existing systems that *do* exactly this. Just because it's "bad practice" doesn't make it go away! Since you can't typically change those systems (ask a hospital to replace it's billing system because your new blood analysis equipment doesn't think it's "good practice" to have to send ESC to the data entry program that logs charges for each patient... they'll quickly find another vendor who's equipment is quite comfortable sending ESC, KEY_LEFT, etc.) you have to ensure that you mimic a real VT-100. Thankfully, you *can* fully characterize how a VT-100 will behave in all possible circumstances -- it's small enough and a closed system. Spend a week or two with an ICE and you'll know how the firmware works in gory detail! Unlike terminal emulators, VT-100's don't have to worry about some spurious interrupt from a mouse, disk drive, NIC, etc. coming in and stealing the CPU when it wants to send out the next character in (for example) KEY_LEFT. So, the equipment which is listening to that VT-100 (or, embedded product which mimics a VT-100) can very well expect the ESC to be immediately followed by the balance of the character sequence. It may not be a robust design, but it works, is in place and try to convince a hospital (e.g.) administrator that he should spend his scarce dollars replacing this design with something more elegant. And, while you're at it, you could try to convince him to abandon DOS because of it's 640K memory limit. Or, the X86 family of processors because of their silly 64K segments. As with each of these, if you want to sell to that market, you adapt to their needs. --don ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals, comp.arch.embedded Date: 9 Apr 1997 19:39:03 GMT Message-ID: <5igr8o$dgn@baygull.rtd.com> From: Don Yuniskis Subject: Re: Q: what terminal emulations would you want supported? In article <5igibq$f4b$1@nntp.ucs.ubc.ca>, Tim Shoppa wrote: >In article <334c8cb1.373958233@news.netcomuk.co.uk>, >Peter wrote: >> >>>Timeouts on the ESC characters? I hope you're referring to possibly >>>adding a longish delay after sending ESC from the keyboard "Esc" key >>>for compatibility with broken curses implementations. >> >>When implementing a VT100 emulator, one needs to implement a timeout, >>typically tens of ms, on the ESC character, so that e.g. >> >> ESC [ M >> >>(sent without any large gaps) is interpreted as such (I made up that >>ESCape sequence, BTW) whereas someone typing >> >> ESC >> >>(done with a finger, so obviously followed by a long gap) is taken as >>a single character which is to be passed on to the application. >> >>Not having a timeout means that ESCape characters could never be sent >>to the application, e.g. to exit from menus etc. > >Again, clearly spoken by someone who has never used a real VT100. >A real VT100 exhibits no timeout on the escape character or sequences. >Anyone who says otherwise is itching for a fight. Funny, I was about to say you've obviously never *written* anything that is intended to behave like a (true) VT-100. There are two sides to this issue and you persist in looking at only one side. Peter's statement says "that ESCape characters could never be sent to the application". He doesn't make any claim about how a VT-100 times out on escape sequences... *If* you are writing a piece of code that has to pretend to be a VT-100, it must not only *decode* escape sequences sent to it in the manner in which a VT-100 would, but it must also GENERATE multiple character sequences in the *SAME* manner that a true VT-100 would! There are many products in the market place that pretend to be VT-100's AND DON"T HAVE CRT'S IN THEM!!! Yet they are VT-100 terminal emulators! In particular, they may, for example, have a modem in them, go off hook at a particular time, dial a number, wait for a connection and then talk to a piece of LEGACY software/hardware that was written to talk to *true* VT-100's via hardwired RS-232C lines. You *can't* change any of the hardware or software on that end of the line. Why? Because it's either no longer available (company is out of business, etc.), too expensive to maintain, already "qualified" (i.e. regulatory agency apporvals which would be a nightmare to have to recertify just to change the terminal interface), etc. And, buying surplus VT-100's and gutting the keyboards to tie in to your "black box" is an unrealistic (i.e. silly!) option. So, you want your terminal emulator to *really* match the characteristics of a VT-100 even though there's no human operator involved. Your product will examine the data stream sent to it -- similar to looking for a "Login: " in a UUCP script -- and then issue a canned sequence of keystrokes in *exactly* the same manner as a VT-100 with a human operator that was knowledgeable of the syntax expected by the application. So, if the application expects all of the characters in a multibyte character sequence to be adjacent in time (without intervening pauses), you must reproduce them in that manner. Since it is possible for an application to be written to talk to a VT-100 and *use* the ESC key as an independant key (perhaps the application disallows all of the function/arrow keys, etc.!), then you must be able to reproduce this, too. If an application uses *both* ESC and, e.g. KEY_LEFT, then you must ensure that you generate these key sequences in the same manner that a VT-100 would WITH A KNOWLEDGEABLE HUMAN OPERATOR (i.e. a human operator would deliberately pause after ESC if the next keys were known to be easily confused with a function key sequence, etc. Why would they know? Because, over the years of use of that legacy system, folks have been bitching about how the crummy application gets confused if you type ESC [ A to do something and it instead interprets it as ESC [ A -- you'd be amazed at how many crappy applications are out there!). One way of doing this is to invent a "pause" key code for your keystroke sequencer. So, you would code this as ESC PAUSE [ A. Another way is to bury the PAUSE in the ESC *implicitly* so ESC generates ESC PAUSE while KEY_LEFT generates ESC [ A (IIRC). The advantage of this latter approach is that it mimics the algorithm used by the application to differentiate ESC from any keystroke sequences which contain ESC. So, you are less likely to have errors in your implementation if you had to remember to explicitly insert a PAUSE everywhere you generated an ESC. --don ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals, comp.arch.embedded Message-ID: <5igl61$s88$1@apakabar.cc.columbia.edu> Date: 9 Apr 1997 17:55:13 GMT From: Jeffrey Altman Subject: Re: Q: what terminal emulations would you want supported? In article <5igi6p$f2g$1@nntp.ucs.ubc.ca>, Tim Shoppa wrote: : : Come on guys, there are enough crappy terminal emulators out there : already. Please don't go pontificating about how you think a : VT-100 *ought* to work - just find a real one and figure out how : it *actually does* work. : : I've spoken with several companies selling PC-clone DOS/Windows terminal : emulators where it's clear that nobody at the company has even : bothered to compare the behavior that a real VT100 has. MS-DOS : Kermit is one of the very few that does emulation right. : Tim: On behalf of Joe Doupnik, Frank da Cruz, and myself, thanks for the compliment. We at the Kermit Project try extremely hard to get this stuff right, not just by collecting and reading physical manuals for the terminals we emulate but also by comparing the output of our software against the real thing. There does seem to be some confusion in this thread caused by the differences in Escape-sequence handling in ANSI-X3.64-based terminals such as the VT 100 and above, as compared to the ASCII terminals including WYSE, Televideo, DataGeneral, HP, etc. ANSI X3.64 defines an Escape sequence using a method very similar to those used in implementing packets over networks or other communication mediums. All sequences begin with ESC or CSI and end with a limited number of INTERMEDIATE and FINAL characters. Therefore, sequences may be of arbitrary length and state machines may be easily constructed without the need for timeouts, even if the terminal doesn't support the command which is being sent. Miscellaneous ASCII terminals use a C0 character to begin the sequence (ESC or RS are popular) followed by an ASCII character sequence. However, there is no way to know when the sequence terminates unless the terminal implements the command. Timeouts for processing ESC sequences are an application hack that was implemented to get around the use of the ESC character as a valid command (by itself) before these same applications attempted to handle terminal-based cursor-movement commands. The general solution for applications to avoid this application-based escape timeout problems is to never send an incomplete ESC sequence over a network--especially one that implements the Nagle algorithm for traffic reduction. Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 The Kermit Project * Columbia University 612 West 115th St #716 * New York, NY * 10025 * (212) 854-1344 http://www.columbia.edu/kermit/k95.html * kermit-support@columbia.edu .............................................................................. [all the better TCP implementations employ Nagle's heuristic] ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals NNTP-Posting-Host: blossom.sivell.com (65.112.226.100) Message-ID: Date: Tue, 16 Mar 2004 01:54:37 -0600 From: Vu Pham Subject: Vt-100 Test of cursor-control characters inside ESC sequences In the vttest VT100, v2.7, in the test of the curosr movements, there is a test of cursor-control characters inside ESC sequences. What is the correct action for the following sequence ? ESC [ 2 C Will the backspace be applied or ignored ? Thanks, Vu .............................................................................. Newsgroups: comp.terminals NNTP-Posting-Host: crawd09058.int.rdel.co.uk NNTP-Posting-Date: 16 Mar 2004 08:30:55 GMT References: Message-ID: Date: Tue, 16 Mar 2004 08:30:55 +0000 From: Paul Williams Subject: Re: Vt-100 Test of cursor-control characters inside ESC sequences On Tue, 16 Mar 2004 01:54:37 -0600, Vu Pham asked: > > Will the backspace be applied or ignored ? Applied. ANSI X3.64 says that the effect of embedding C0 controls in Escape sequences is undefined, so this behaviour may be specific to DEC VTs and compatibles. You can find a comprehensive treatment of similar cases here: http://vt100.net/emu/dec_ansi_parser Particularly the section "What X3.64 Doesn't Say". -- Paul ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals,comp.arch.embedded Path: utkcs2:stc06.ctd.ornl.gov!news.he.net!newsfeed.nacamar.de !news.maxwell.syr.edu!news.bc.net!unixg.ubc.ca!alph02.triumf.ca!shoppa Date: 9 Apr 1997 18:42:11 GMT Organization: TRIUMF, Canada's National Meson Facility Message-ID: <5ignu3$j42$1@nntp.ucs.ubc.ca> References: <5i1p56$ndv$1@europa.frii.com> <5ie3v9$kdi@baygull.rtd.com> <5igi6p$f2g$1@nntp.ucs.ubc.ca> <5igl61$s88$1@apakabar.cc.columbia.edu> From: shoppa@alph02.triumf.ca (Tim Shoppa) Subject: Re: Q: what terminal emulations would you want supported? In article <5igl61$s88$1@apakabar.cc.columbia.edu>, Jeffrey Altman wrote: > In article <5igi6p$f2g$1@nntp.ucs.ubc.ca>, >In article <5igi6p$f2g$1@nntp.ucs.ubc.ca>, >Tim Shoppa wrote: >: >: Come on guys, there are enough crappy terminal emulators out there >: already. Please don't go pontificating about how you think a >: VT-100 *ought* to work - just find a real one and figure out how >: it *actually does* work. >: >: I've spoken with several companies selling PC-clone DOS/Windows terminal >: emulators where it's clear that nobody at the company has even >: bothered to compare the behavior that a real VT100 has. MS-DOS >: Kermit is one of the very few that does emulation right. > >On behalf of Joe Doupnik, Frank da Cruz, and myself, thanks for the >compliment. You guys deserve every compliment there is! >We at the Kermit Project try extremely hard to get this >stuff right, not just by collecting and reading physical manuals >for the terminals we emulate but also by comparing the output of >our software against the real thing. Unfortunately, in the crappy-emulator world a vicious cycle has already begun. People write emulators that emulate what they think a VT100 *should* do, not what a VT100 *really* does. THEN application writers assume that because features are present in some of these emulators, that these features must be available on the real terminal. The worst offender I've found is a commercial editor that requires VT100 users to hit F5 through F10 to access certain abilities that are rather necessary - such as exiting the editor. Despite repeated phone calls to the company, I've yet to convince them that a VT100 does NOT have F5 through F10 function keys. They claim that because some popular Windows-based emulators implement these function keys in VT100 mode, a real VT100 must as well. Arrggghhh!!!! I'm tempted to deliver a half-dozen true VT100's to their corporate offices via catapult. Tim. (shoppa@triumf.ca) ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals, comp.arch.embedded Message-ID: Date: 11 Apr 1997 08:40:53 -0400 From: James Carlson Subject: Re: Q: what terminal emulations would you want supported? In article <5ij3g0$1qd@baygull.rtd.com> dgy@rtd.com (Don Yuniskis) writes: > > How many embedded applications have you dealt with? (re: comp.arch.embedded) Oh, only several dozen. Are ad hominem attacks a reasonable way to discuss these problems? > >right. (In fact, my previous job was with Data General writing the > >firmware for the Dasher line of terminals. I'm intimately aware of > >the fun things involved.) Unfortunately, we can't always do this. > > But this assumes there is a terminal server involved at all! Duh. I was responding to a previous posting which mentioned that even if you do modify your code to attempt to get all the characters in a 7-bit C1 sequence to go out as a contiguous block, there are often still devices in the communications path which can break lame attempts at (mis-)using timing information. > > 2. Use a VT-200 (or higher) series emulation and set it to > > send 8-bit C1 controls. This is a much better solution. > > If your application isn't hopelessly broken, it should > > already be (optionally, of course) internally converting > > "ESC chr" to (chr+0x40) for 7-bit C1 controls, and this > > should work seamlessly with no time-outs on ESC. > > Grrrr... you're still thinking desktop/mainframe. Most embedded No, I'm not. The point is that if you're a developer working on such applications, you should at least be trying to move away from a broken model -- one that has been well-understood to be broken since the 1970's. Perhaps someday there will only be a few systems which are broken in that way. That won't happen if you persist in doing things the same way. -- James Carlson , Prin Engr Tel: +1 508 916 4351 Bay Networks - Annex I/F Develop. / 8 Federal ST +1 800 225 3317 Mail Stop BL08-05 / Billerica MA 01821-3548 Fax: +1 508 916 4789 ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals Path: utkcs2!stc06.ctd.ornl.gov!news.he.net!uwm.edu!news-peer.gsl.net !news-peer.sprintlink.net!news.sprintlink.net!sprint!howland.erols.net !europa.clark.net!news.clark.net!explorer2.clark.net!not-for-mail Organization: Clark Internet Services, Inc., Ellicott City, MD USA Message-ID: <5j2a53$f56@clarknet.clark.net> References: <5j19ns$ccp$1@europa.frii.com> Date: 16 Apr 1997 10:37:23 GMT From: T.E.Dickey Subject: Re: ESC code parser techniques SH wrote: : : I'd like to learn more about how to design my own : VT-100 (or VT-220) terminal emulator and was wondering : if anyone could provide some comments or suggestions : on how to parse the ESC codes. : I already have ESC code information for these terminals, : so what I'm looking for is your comments/experiences : with parsing these codes (i.e., did you implement a state : machine? etc..). "xterm" uses a state machine - the XFree86 3.2A xterm does most of the VT220 codes--copy of source at: [OLD URL: http://www.clark.net/pub/dickey/xterm/] [URL good in 2009] http://invisible-island.net/xterm/ -- Thomas E. Dickey http://www.invisible-island.net/ ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals Path: utkcs2!stc06.ctd.ornl.gov!fnnews.fnal.gov!uwm.edu!vixen.cso.uiuc.edu !howland.erols.net!newshub2.home.com!news.home.com !su-news-hub1.bbnplanet.com!cam-news-feed2.bbnplanet.com !news.bbnplanet.com!transfer.stratus.com!xylogics.com!usenet Organization: Bay Networks, Inc. Message-ID: References: <01bc9879$c973b740$0100007f@Beer1> NNTP-Posting-Host: donald.xylogics.com Date: 28 Jul 1997 07:33:10 -0400 From: James Carlson Subject: Re: Simple Telnet Help! In article <01bc9879$c973b740$0100007f@Beer1> "Bill Murray" writes: > > The host (VAX) I am communicating with sends > WILL Echo > I send > DONT Echo > The host then sends > WONT Echo > Is this correct? I though the negotiation was finished with the DONT ECHO > (the reply from host being unecessary). The VAX is behaving correctly. The "WILL ECHO" message implies a change of state (default is all options off; this is informing the peer that one of the local options was turned on). The "DONT ECHO" message requests that the state be changed back, so, again, there is a change of state (from on back to off), so a "WONT ECHO" message is required. This is described on page 2 of RFC 854. > Also when I try to turn this option (and suppress go ahead) off the host > continues to echo, even though it says it wont! That's probably a system issue outside of the TELNET protocol. Disabling ECHO using "DONT ECHO" should stop the peer from echoing back characters it receives. If it doesn't do that, then the peer is broken. -- James Carlson , Prin Engr Tel: +1 508 916 4351 Bay Networks - Annex I/F Develop. / 8 Federal ST +1 800 225 3317 Mail Stop BL08-05 / Billerica MA 01821-3548 Fax: +1 508 916 4789 Keep an eye out for my PPP design and debug book from Addison-Wesley. (Available early 1998.) [2002 UPDATE--2nd edition: http://www.aw.com/cseng/titles/0-201-70053-0/ ] ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals Organization: Antigua Computers Ltd. Message-ID: <01bca0ab$4acc8360$aee9989e@antigua-software> References: <01bc9879$c973b740$0100007f@Beer1> Date: Mon, 04 Aug 1997 07:53:42 GMT From: "Bill Murray" Subject: Re: Simple Telnet Help! James, Thanks for responding. I have read RFC 854, I got the impression that state changes were not permitted unless agreed. Therefore WILL ECHO does not represent a state change and does not require and acceptance of change back with WONT ECHO. Doesn't the RFC state that communications shouldn't simply be used to announce state change? I am still a bit confused on this one. Is it that a refusal always requires three components: WILL, DONT, WONT or DO, WONT, DONT ? Whereas an acceptance only requires two WILL, DO or DO, WILL? Can't find this information in the RFC. Thanks Bill. ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals Organization: Bay Networks, Inc. Sender: carlson@donald.xylogics.com Message-ID: Date: 04 Aug 1997 07:29:13 -0400 From: James Carlson Subject: Re: Simple Telnet Help! > Doesn't the RFC state that communications shouldn't simply > be used to announce state change? No. It says that you cannot send a request to announce what mode you are *already* in, but if you're *changing* mode, then you must send a request. In other words, when you first come up, you must not send any "DONT foo" or "WONT foo" messages. The default for all options is off, so these are redundant announcements. Only the options that change state should be sent. > I am still a bit confused on this one. Is it that a refusal always > requires three components: WILL, DONT, WONT or DO, WONT, DONT ? > Whereas an acceptance only requires two WILL, DO or DO, WILL? > Can't find this information in the RFC. No, that's not it. "DO" and "DONT" just request state change on the other side of the link. Nothing is actually changed until the peer responds. "WILL" and "WONT" mean that the local state *has* changed, and must be inserted in the data stream at the point where the mode change takes place. Any data that follows either of these messages must be encoded in the 'new' format (whatever that means for the given option). This does imply that a system sending an unsolicited WILL when the option is off must buffer the user-level data, rather than encode and transmit it, until the peer responds with a DO or DONT (which the peer is required to do). This is what's meant by avoiding the "uncertainty period" at the top of page 3. In our implementation, I wait 30 seconds for this to happen. Sadly, there are many (mostly PC-based) implementations of TELNET that get this exchange wrong and fail to respond to WILL messages as required by the RFC. So reasonable and complete exchanges (assuming 'opt' is initially off) are: 1. DO opt (requests change of state; must be answered) -> <- WILL opt (agreeing to change; option now in effect) 2. DO opt (requests change of state; must be answered) -> <- WONT opt (not agreeing to change; option still not in effect) 3. WILL opt (implies change of state; must be answered) -> <- DO opt (agree to change already in effect) 4. WILL opt (implies change of state; must be answered) -> <- DONT opt (not agreeing to change) WONT opt (buffering off) -> With 'opt' initially on: 1. DONT opt (requests change of state) -> <- WONT opt (option is disabled) 2. WONT opt (implies change of state) -> It is required that all implementations support any or all options disabled, so it's not too reasonable to force an option back on if the peer disables it. -- James Carlson , Prin Engr Tel: +1 508 916 4351 Bay Networks - Annex I/F Develop. / 8 Federal ST +1 800 225 3317 Mail Stop BL08-05 / Billerica MA 01821-3548 Fax: +1 508 916 4789 ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals Organization: Antigua Computers Ltd. Message-ID: <01bca19d$0ac2b080$aee9989e@antigua-software> References: <01bc9879$c973b740$0100007f@Beer1> <01bca0ab$4acc8360$aee9989e@antigua-software> Date: Tue, 05 Aug 1997 12:43:45 GMT From: "Bill Murray" Subject: Re: Simple Telnet Help! Thanks that clears up the process enough for the implementation, however I do have one or two questions about the validity of the process... WONT and DONT on startup I am aware of.. redundant--all options are off this seems fine and reasonable. And when a local change is announced with a WILL, it is pre-empting the peer's acceptance of the change (and buffering to cover up the uncertainty period). The peer is not required to accept the change, a valid response would be DONT foo. When the peer sends DONT foo, the local change is rejected and the locally buffered change of state must be undone(redone). To all intense and purpose the state (from the point of view of the peer) never changed. The side of the link that sent the original WILL has had its local state change denied. It is at this point I am confused (duh). As it would not seem sensible for the originator of the WILL to respond to this denial (DONT) with a WILL again, it *must* respond WONT, it has no choice and therefore it would seem that the response is as redundant as sending DONT/WONT on startup. The peer has already said it will not agree to the option, it does not need to wait for a conformation of its own refusal--on the grounds that it is not required to implement the option and has not changed state. I can see how always sending a WONT when a DONT is received could simplify the state model, because currently I process WILL(remote unsolicited)/DONT(response) as separate set of state changes which cause the overall state to return to an option off state--which will ignore the final WONT ( remote response--which I hadn't really expected to get) as it would an unsolicited WONT on startup. Bill. ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals Path: utkcs2!stc06.ctd.ornl.gov!news.he.net!news-spur1.maxwell.syr.edu !news.maxwell.syr.edu!cpk-news-hub1.bbnplanet.com!news.bbnplanet.com !gatech!news-feed-1.peachnet.edu!paperboy.engeast.baynetworks.com !news-w.ans.net!newsfeeds.ans.net!xylogics.com!usenet Organization: Bay Networks, Inc. Message-ID: References: <01bca1c4$a3574a00$aee9989e@antigua-software> Date: 06 Aug 1997 09:26:42 -0400 From: James Carlson , Subject: Re: Simple Telnet Help! In article <01bca1c4$a3574a00$aee9989e@antigua-software> "Bill Murray" writes: > > It does need to know *WHERE* in the data stream the option took... > > My confusion is clearer. but... > ... > So is WONT needed? Yes, it's still needed. As I said, there's no demand in the RFC that the peer buffer the data after sending the WILL, and there's also no demand that the receiver attempt to handle such foreign data. Suppose, for instance, the WILL option in question is going to translate everything from ASCII into EBCDIC, and that the peer doesn't buffer its output. Do you still want to deliver this data even if you don't speak EBCDIC? What will the user think of this? Some options are somewhat benign, but others aren't. > For the options I am using I will take the approach you suggest, discarding > until the the final WONT. > > Thanks for all your help. :-) As with all kludges for interoperability with broken peers (the ones that send WONT willy-nilly without regard to where it takes effect), this one should have a switch on it if possible. Staying compatible with all of the dumb things people have done over the years is tough, but it makes for a pretty decent living. ;-} Keep an eye out for my PPP design and debug book from Addison-Wesley. "PPP Design and Debugging", 2nd ed. http://www.aw.com/cseng/titles/0-201-70053-0/ -- James Carlson , Prin Engr Tel: +1 508 916 4351 Bay Networks - Annex I/F Develop. / 8 Federal ST +1 800 225 3317 Mail Stop BL08-05 / Billerica MA 01821-3548 Fax: +1 508 916 4789 ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.os.linux.development.apps, comp.protocols.tcp-ip Message-ID: References: <53bb806a.0301171607.78ba6f93@posting.google.com> Organization: Networks and Distributed Computing Date: Fri, 17 Jan 2003 17:51:35 -0800 From: Mark Crispin Subject: Re: Can't get Linux telnet client to disable line mode The normal mode of TELNET is that all options are disabled. In other words, you should not sent any DONT/WONT options unless: 1) you wish to disable an option that you previously agreed to with DO/WILL. 2) you wish to refuse a WILL/DO change request from the client. So, you should not send DONT ECHO and DONT LINEMODE, because you are already in that mode. Also, a compliant TELNET implementation will ignore such things. Also, it's silly for a TELNET client to ever send WILL ECHO, or for a TELNET server to ever send DO ECHO. It is only meaningful for a client to send DO/DONT ECHO and a server to send WILL/WONT ECHO. Getting TELNET protocol right is something that trips up newbies every time. I strongly suggest that you get a good pedagogical book about TCP/IP protocols. -- Mark -- http://staff.washington.edu/mrc -- Science does not emerge from voting, party politics, or public debate. ////////////////////////////////////////////////////////////////////////////// Date: Sat, 2 May 1998 13:56:20 -0500 From: "Hermann V. Rosch M." To: "Richard S. Shuford" Subject: Re: VT420 Telnet and VMS > From: Richard S. Shuford > To: Hermann V. Rosch M. > Subject: Re: VT420 Telnet and VMS > Date: Saturday, May 02, 1998 12:04 PM > > Sir Hermann: > > >Date: Wed, 29 Apr 1998 05:35:37 -0500 > >From: "Hermann V. Rosch M." > >Subject: VT420 Telnet and VMS > > > >Hi Richard, > > > >Congratulations for your excellent site > >http://www.cs.utk.edu/~shuford/terminal/ > > > >If you can give me any hints on this I will be grateful: > > > >A few years ago I developed an MS-DOS Telnet emulator of the DEC-VT420 > >terminal, for that purpose I used "PC/TCP Network Software for DOS Ver 2.2" > >(kernel) and the "PC/TCP Development Kit for DOS" both from FTP Software. > > > >The emulator was tested again this week against SCO UNIX and it works fine, > >however it did not function properly when I tested it against a DEC VMS > >machine with OpenVMS Alpha(TM) Operating System, Version V6.2-1H3. > > > >It seems that VMS rejects any of my ANSI escape sequences (such as ESC[H > >ESC[J cursor movements ESC[A ESC[B etc...) as invalid or incomplete. I > >even "mocked" without success the exact behavior of Attachmate's KEA > >emulator (wich works OK against the same VMS with the same ESC sequences). > >It seems that it is some functionality that I don't have in the DOS PC/TCP > >kernel or maybe a special parameter/consideration for VMS has to be set. > >Is there a similar situation with WinSock? > > > >Any help will be very welcome. > > > >Thanks, > >/*-------------------------------------------------------------+ > > | Hermann V. Rosch M. OPTIMIZING SOFTWARE cnap@pan.gbm.net | > > | http://sac.org.org.mx/optima/sp/empresas.html | > > | Tel/Fax:(507)269-9256 Tel:(507)223-2103 Cel:(507)613-5987 | > > +-------------------------------------------------------------*/ > > > This does sound puzzling. > > My best guess is that something is amiss in the emulation of the > "line discipline" or in the Telnet protocol options that are selected > at connection setup. > > Since TCP/IP is not built into OpenVMS, I can only guess which > layered-product protocol stack you are using. Is the machine using > the Process Software TCPware TCP/IP stack? Or perhaps the MultiNet > stack (which Process Software bought from cisco/TGV)? > > I suggest you put a data analyzer on the wire and look at exactly > what's in the packets, with attention to the setup phase and any > differences you see with the two clients. > > Also, I assume you verified that VMS's opinion of the session makes > sense? (SHOW TERMINAL output...) > > > > ...Richard S. Shuford | "It is not good to have zeal without knowledge, > ...shuford%cs.utk.edu | nor to be hasty and miss the way." > ...Info-Stratus contact| Proverbs 19:2 Dear Richard, Here are two responses from some friends at FTP Software Inc., they both were right, but the reason that was killing me was that characters were being sent one at the time. It did work OK against SCO UNIX, but the VMS telnet daemon requires you to send the complete sequence in a single full packet, not byte by byte. Thanks for answering, I appreciate your help! Read on please...: ----- We have seen situations when escape sequences that should work don't. This happens when the escape sequence is sent in different packets. For instance, the ESC [ is sent in one and the A is sent another. Watching a Lanwatch trace will definitely show the differences here. The other question I have is, how is he sending the escape sequences? In the VT world, ESC [ can be sent as two separate characters 0x1b for ESC and the ASCII equivalent for [, or it can sent as one character referred to as CSI (control sequence indicator) 0x9b. When the escape sequence is sent using the CSI character, it is referred to as a C1 [8-bit] control character. If the telnet daemon on the VMS is stripping off the high bit of characters, which it does by default, unless it is in binary mode, C1 control characters will be interpreted incorrectly. Hope this helps. Lynne -------- VMS usually places the Terminal into 8bit mode. Which means 2 things 1. Binary mode should be negoiated with telnet. 2. The ESC [ becomes CSI (ESC [) is the 7bit breakup of the 8bit char CSI Kevin ---------- [Archiver's Note: In the general case, binary mode and 8-bit CSI are not necessarily linked together. ...RSS] ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals Message-ID: <35c7792c.1286901927@news.demon.co.uk> References: <01bdb66d$b8c74700$63636363@laptop-brc> Date: Fri, 24 Jul 1998 12:19:32 GMT From: Harry Broomhall Subject: Re: Wyse-50 emulation recomendations wanted On 23 Jul 1998 19:11:39 GMT, "Bill Creager" wrote: >I am about to write a program that must emulate a Wyse-50 terminal, and I >am looking for recommendations regarding the information I will need. At >this point, I do not have any consolidated information about the control >sequences. Why not buy a Wyse50 emulator? Surely it would be easier? > >I have just ordered the book, "Termcap & Terminfo". Will this book provide >sufficient detail to develop an emulator? Not at all. > If not, what additional documentation is recommended? You need the Wyse programming handbook. It also helps to have a *real* Wy-50 to hand to see where you went wrong! > My previous experience is with vt100 for >which there seems to be much more technical information on the internet, >but it is almost impossible to develop a satisfactory emulator without Dec >documentation. > >Does anyone have recommendations on where to locate a comprehensive set of >control sequences? Is there a test program similar to vttest that can be >used to validate the functionality of a Wyse-50 emulator? Any >recommendations will be greatly appreciated. The problem is that Wyse50 and similar terminals are *very* different in style from the VT100 series. I have always mentally divided terminals into two groups: 'hardware' and 'software'. Wyse-50 and Prestel belong to the 'hardware' group, and VT100 and friends to the 'software' group. In the hardware group screen effects are done almost totally with the hardware. As an example, if you set the highlight bit on *highlight is now on until the end of the screen, or the place where it is set off, whichever comes first*. This is a *totally* different concept from the VT100, where, after putting highlight on, it is on ONLY for characters subsequently *written* until switched off. Unix does not really understand such an idea, and termcap and terminfo merely hack at it a bit, which is why the book is not particularly useful on its own. You also have to deal with the tiresome 'cookie-glitch'; a product of limited hardware capabilities of the day. [early 1980s] Regards, Harry (who has written a Wyse50 emulator). ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals Message-ID: <6pa576$je4$1@apakabar.cc.columbia.edu> References: <01bdb66d$b8c74700$63636363@laptop-brc> Date: 24 Jul 1998 14:20:22 GMT From: Jeffrey Altman Subject: Re: Wyse-50 emulation recomendations wanted In article <35c7792c.1286901927@news.demon.co.uk>, Harry Broomhall wrote: : The problem is that Wyse50 and similar terminals are *very* : different in style from the VT100 series. I have always mentaly : divided terminals into two groups: 'hardware' and 'software'. This is the first time I have ever heard it described quite like that. I look at it from two different perspectives. There are text terminals which are based on the ANSI X3.64-1979 standard (replaced by ISO-6429) upon which most modern day terminals are based (VT100 and higher; SCOANSI; AT386; IBM LFT,HFT,AIXTERM; SNI; WY350 family; and most Unix consoles) and those that are not based on this standard (VT52; Wyse 30,50,60, and their decendents; HP; TVI; DG; IBM 31xx; and many others). The other dimension is defined by how are attributes implemented. They can either be VISIBLE or HIDDEN and applicable to the following CHARACTER, LINE or PAGE. A VISIBLE atteibute tkaes up a character position whereas a INVISIBLE one does not. Some terminals allow any of the six possible combinations to be used. Others limit you to just one. ANSI X3.64 terminals always use HIDDEN/CHARACTER attributes and the Wyse 50 uses VISIBLE/PAGE attributes. The Wyse 60 for example defaults to INVISIBLE/PAGE attributes but can be configured either locally or remotely to use CHARACTER or LINE attributes instead. --- When developing terminal emulators always have two things: . copies of the manufacturer's manuals . a real terminal The manual will give you a feeling for what the escape sequences are and what they are supposed to do. For an ANSI X3.64-1979 or ISO-6429-based terminal, you can implement a very simple parser that will work regardless of the things you do not know. Command sequences that you do not recognize will be absorbed and ignored, if you do it right. Non-ANSI-X3.64 terminals are not that forgiving. They are unparsable and, unless you know all of the sequences that the terminal accepts, the visual appearance of the data will be corrupted by unprocessed escape sequences. The real terminal is necessary so you can test the behavior of the terminal against your implementation and so that you determine all of the undocumented behaviors that the terminal provides. I agree with Harry that implementing a good emulator, even for simple terminals such as VT100 and WY50, is a non-trivial piece of work. Unless you are doing it as a hobby or because there is no other piece of software available that can perform the job that you need, it is significantly cheaper to just buy an emulator from someone else. Extremely good emulators can be had for a few dollars a copy in quantity and if the quantity is small the overall cost must be less than the cost of your time. See http://www.columbia.edu/kermit/k95pricing.html for the pricing model; for the Kermit 95 terminal emulation and file transfer product see http://www.columbia.edu/kermit/k95.html Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 The Kermit Project * Columbia University 612 West 115th St #716 * New York, NY * 10025 http://www.kermit-project.org/k95.html * kermit-support@kermit-project.org ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals Message-ID: <35c8a128.1297137975@news.demon.co.uk> Date: Fri, 24 Jul 1998 15:08:10 GMT From: Harry Broomhall Subject: Re: Wyse-50 emulation recomendations wanted On 24 Jul 1998 14:20:22 GMT, jaltman@watsun.cc.columbia.edu (Jeffrey Altman) wrote: >In article <35c7792c.1286901927@news.demon.co.uk>, >Harry Broomhall wrote: >: >: ...I have always mentaly >: divided terminals into two groups: 'hardware' and 'software'. > >This is the first time I have ever heard it described quite like that. Well - it *is* my own invention! (Cue the White Knight) So I don't expect to find it in the literature. > >I look at it from two different perspectives. There are text >terminals which are based on the ANSI X3.64-1979 standard (replaced by >ISO-6429) upon which most modern day terminals are based (VT100 and >higher; SCOANSI; AT386; IBM LFT,HFT,AIXTERM; SNI; WY350 family; and >most Unix consoles) and those that are not based on this standard >(VT52; Wyse 30,50,60, and their decendents; HP; TVI; DG; IBM 31xx; >and many others). This is a slightly different classification. For my purpose as a developer my classification is more useful in determining how hard an emulation is to do. This is because to do a 'hardware' terminal is *much* harder than a 'software' one. It also tends to be slower, as you have to 'extend' the attribute forwards. Note that while VT52 may not be a 'standard based' terminal it is, in my classification, a 'software' terminal, and thus not so hard to do. [SNIP] > >When developing terminal emulators always have two things: > >. copies of the manufacturer's manuals >. a real terminal Good solid advice here! Regards, Harry. ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals Message-ID: <6uq091$ce8$1@nnrp1.dejanews.com> References: Date: Tue, 29 Sep 1998 06:55:29 GMT From: celigne@celigne.co.uk Subject: Re: ANSI Emulation In article , "James Rich" wrote: > I'm working on an ANSI emulation, and I have a quick question. > > Does anyone know what character should be displayed when a terminal receives > a DLE (hex 10) from an ANSI host? I'm not sure whether a symbol should be > displayed or not, and if so, what symbol. Quick answer: Ignore DLE on input. Do not display a symbol. Longer answer: I doubt you will ever receive DLE nowadays. DLE was generally used to prefix another control character. For example, in the days when many comms lines were half-duplex (i.e., only one end could talk at a time), one or more control characters would be selected to perform "line turnaround", which pretty much meant "I've finished talking, you can have a babble now". On the VT102 and VT131, the control character End of Transmission (EOT, 4) could be selected as the disconnect character or the line turnaround character. If it was used as the turnaround character, the disconnect character would be DLE-EOT. The glossary of Digital's Terminals & Printers Handbook, 1983-84, has this to say about DLE: --quote-- A control character used exclusively to provide supplementary line control signals (contol character sequences or DLE sequences). These are two-character sequences where the first character is DLE. The second character varies according to the function desired and the code used. --end quote-- [Aside: this book is such a mine of information about ancient terminals and printers (the VT200 Series had just been introduced), I'm currently working on putting it on-line.] Regards, Paul ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.sys.tandem Date: 3 Aug 1998 18:26:43 GMT Message-ID: <01bdbf0c$6912e280$3797cad0@bighand.concentric.net> References: <01bc9fe6$03eba2c0$0586d00a@alex> From: "Dale Blommendahl" Subject: Re: FORMAT 6530 emulation (Help me !) Alex wrote in article <01bc9fe6$03eba2c0$0586d00a@alex>... > Hi ! > Please help me ! > I want to write 6530 emulator throuth telnet WinSocket. > Where i can get docs about format of tandem emulation? > > Alex. > RUSSIA Alex, In order to do a good job of creating a new emulator you'll need a lot of experience with the various versions of both Tandem and others 6530/6526 emulators. Among the emulators that have existed are: PCT/PC6530, Tandem Terminal Emulator (TTE), CAIL's T6530 (CTT), Crystal Point's Emulator, FutureSoft's DynaComm Tandem 6530, CASEMaker's DRSE, and other's I can't remember at this time (sorry to any of you I've forgotten to mention). The single best source of information on the 6530 protocols is the 6530 Multipage Terminal Programming Guide that was published about 14 years ago. To my knowledge you'll have to find one that someone is willing to part with as they are out of print and have been for a long time. There are also many user's guides and manuals from the emualtor vendors that can be very helpful: CTT Communication Facility Operator Guide (CAIL Systems), Tandem Terminal Emulators User's Guide, 6530 Multi-Page Terminal Users Guide, PC6530 User's Guide (Tandem), 6526 Multi-Page Terminal Installation and Operation Guide, etc. A word of caution: there are lots of undocumented "features" that you'll have to find by testing your emulator with every piece of software Tandem (and some customers) ever wrote. If you are only going to support TCP/IP it will cut down on the number of these nasty "got you" features that you have to deal with. ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals, comp.emulation.misc Message-ID: <01bdef9f$cd216bc0$63636363@laptop-brc> References: <361503E0.AC05587A@eskimo.com> Date: 4 Oct 1998 13:59:43 GMT From: Bill Creager Subject: Re: Reference material for VT100 escape sequences Don Christine wrote in article <361503E0.AC05587A@eskimo.com>... > Hello, > > I'm trying to locate reference material with character tables and escape > sequences for VT100 terminal emulation. Can anyone help? > > Thanks in advance, > Don Christine > dbchris@eskimo.com There is a good deal of information at http://www.cs.utk.edu/~shuford/terminal_index.html (you found it!) The kind of information you will find on the internet is likely to be lists of escape sequences with brief descriptions. The information is very good, but it will not provide a complete description of the terminal's behavior. In my opinion based on having developed a vt100 emulator, it is not possible to develop a good emulator without the detail that is only available in the DEC reference manual. When I last checked, DEC was no longer publishing the manual you need so it may be hard to find. There is a tremendous program named vttest which you should also get. It runs on a Unix system and is an invaluable resource in helping detect problems with an emulator. It is available from several sites on the internet, including the above(I think). The other tool you need is a data scope to capture the data stream.Good luck. ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals References: <01bdefa0$673256c0$63636363@laptop-brc> <361be1ba.16306079@netbsd.haeb.demon.org> <01bdf20c$bd653da0$63636363@laptop-brc> Organization: C.I.C. Ltd Date: Thu, 08 Oct 1998 00:34:01 GMT From: Harry Broomhall Subject: Re: Sending break with Wyse 50 emulator On 7 Oct 1998 16:04:26 GMT, "Bill Creager" wrote: > My original question was obviously written poorly. I have written the > emulator, and need to know what my program must sent to simulate pressing > the break key. > > My Wyse-50 display terminal reference manual does not specify what a break > signal is. My program is communicating with another computer which does not > send breaks, although it expects them for some functions. In the serial comms world (for example RS-232) a BREAK signal is where the line is held at SPACE for longer than a normal character frame. Other rules apply for other media. Regards, Harry. ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals NNTP-Posting-Host: watsun.cc.columbia.edu Date: 30 Dec 1998 18:10:11 GMT Organization: Columbia University Message-ID: <76dqa3$8v5$1@apakabar.cc.columbia.edu> References: From: Jeffrey Altman Subject: Re: new test for vttest? In article , John E. Davis wrote: : Hi, : : I noticed that both the telnet program from Microsoft and the win32 : SimpTerm telnet program do not seem to scroll properly in the presence : of a scrolling region. For example, suppose that I have a terminal : that consists of 24 lines and I set the scrolling region to lines : 2-22, then with the cursor on line 22, then should a linefeed : character cause a blank line to appear on line 22? Here is a program : that illustrates what I am talking about. If I am not invoking some : sort of undefined behavior, then perhaps this test should be added to : vttest because both the microsoft telnet client and simpterm fail this : test. Given the number of tests that MS Telnet fails in vttest I would be surprised if the problem you describe is not already covered in modern releases of vttest. There are numerous differences between VT100 and any of the several "ANSI" (based on ANSI X3.64-1979) specifications that are in use. Microsoft does nothing more than change the name the telnet client reports to the server and it supports neither name well. : Finally, is there a good, freely available telnet program for win32 : that provides a half-way decent vt100 emulation? I am not interested : in shareware. Thanks, --John Terminal emulation is hard to get right. It takes time, patience, access to the real thing, and long term support for the software. While it is possible to find these qualities in freeware, it is not common. If you want solid terminal emulation I would suggest you be willing to spend a few dollars. Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 The Kermit Project * Columbia University 612 West 115th St #716 * New York, NY * 10025 http://www.kermit-project.org/k95.html * kermit-support@kermit-project.org ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals,comp.sys.dec,comp.sys.ibm.as400.misc Message-ID: <7f0eer$ov5$1@nnrp1.dejanews.com> References: NNTP-Posting-Host: 192.133.7.205 From: Jerry Rackley Organization: Esker Date: Tue, 13 Apr 1999 21:54:38 GMT Subject: Re: terminal emulation dll's In article , "Mike Kraft" wrote: > I need info about companies that sell libraries for use in developing > terminal emulation products for the following terminal types: > > 3270 (SNA, TN3270, TN3270E) > 5250 (SNA, TN5250, TN5250E) > VT 100 family > VT 220 > > It is not necessary for a single company to supply all these emulations, > although it would be nice. Any help anyone can provide will be much > appreciated. > > Mike Kraft > Cel Corporation > http://www.celcorp.com/ Mike, Esker's Tun PLUS v10 delivers the emulations you mention, with the exception of TN5250E, in the form of ActiveX controls that you can embed within another application. Info and an evaluation copy can be downloaded from: http://www.esker.com/products/tunplus/2.2_tunplus.html Jerry Rackley Esker ///////////////////////////////////////////////////////////////////////////// Message-ID: <7fpvp3$9jb$1@newsmaster.cc.columbia.edu> References: <7fnlb4$pfs$1@nnrp1.dejanews.com> <7fptvb$r1g$1@nnrp1.dejanews.com> Organization: Columbia University Date: 23 Apr 1999 14:23:31 GMT From: Jeffrey Altman Newsgroups: comp.terminals Subject: Re: WYSE 50/60 Specs for Emulator In article <7fptvb$r1g$1@nnrp1.dejanews.com>, Mark Greene wrote: : There is a new Wyse-50 FAQ, that contains allot more information than the old : page did: : : http://www.wyse.com/service/faq/wy50faq.htm : This isn't much better. It contains a termcap and a terminfo entry for the terminal. But termcap and terminfo entries do not provide enough information to implement an emulation. All they do is provide enough information to emulate the way that termcap or terminfo uses the terminal. If you want to implement a terminal you must: . find copies of the real terminal manuals . get a real terminal . build a test suite to test against. Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 The Kermit Project * Columbia University 612 West 115th St #716 * New York, NY * 10025 http://www.kermit-project.org/k95.html * kermit-support@kermit-project.org ///////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals Organization: vakusolar Message-ID: <1dd2xcs.l6nl6u109a6p4N@gatezh5-79.access.ch> References: <35c261cf.0@news3.uswest.net> NNTP-Posting-Host: gatezh5-79.access.ch NNTP-Posting-Date: 1 Aug 1998 09:25:56 GMT Date: Sat, 1 Aug 1998 11:27:18 +0200 From: vakusolar@mus.ch (Georg Lachenmeier) Subject: Re: Terminal emulation Handor wrote: > Hi all > > I need to develop a vt100 (ansi?) compatible telnet application. However, I > have found neither web pages nor books containing the information I need to > write applications for terminal emulation. > > If anyone knows anything about programming telnet applications like this, > please let me know. I am looking chiefly for information relating to visual > basic 5.0 for windows 9x. No activex, please, unless it's free. Source from > other languages welcome, too. > > Thanks in advance, > Hi Dominic No long ago I have written the software for a heatingsystem with a modem. This small computer serve any Vt100 Terminal(-emulation). If you want test it: Phone-Number international +411 761 06 14 (is in Switzerland) 1200 Baud no parity, Handshake optional XOn/Off. If you ar connect, type: Vt100, an the Image will com on your terminal. All the software-commands how I need, I hav found in this news-group. If you found it not here, email me, and so I will you send a copy (lot of stuff). George ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.unix.programmer, comp.protocols.kermit.misc Date: 14 Mar 2000 15:29:42 GMT Organization: Columbia University Message-ID: <8allt6$p76$1@newsmaster.cc.columbia.edu> From: Frank da Cruz Subject: Re: Sockets programming: telnet problem. In article <8ak6qk$qse$1@nnrp1.deja.com>, wrote: : Ok, I'm attempting to write a (very) basic telnet client as an : experiment. Actually, I'm using it to connect to various talkers, : NUTS based which don't do very much in following the telnet protocol. : (They seem to ignore or treat as CR any control codes, in fact the : only code they ever DO seem to send is the echo control when it's : time to enter a password). : : My program is sending data out in a character based manner (as soon : as a key is pressed, sent it with write() over the socket) and : reading in as much data as it can at once with read(), using select() : to check if there is any data to be read on the socket. The problem : is as follows: when a NUTS talker displays a prompt such as "give me : a name:" on its login screen, or COM> which is a command prompt, this : line is NOT terminated by a carriage return, as it's a prompt and the : user who is telnetting in is meant to make their input on the same : line. However, these prompts simply aren't seen by my program. In : fact, neither select() or read() are aware of the existence of this : line until at least one character has been sent back the other way! : Therefore, I don't see the "give me a name:" prompt until I press the : first letter of my name, which then appears not to be displayed as : the prompt appears on top of it. After reading through the details : of the telnet protocol, I figured that maybe I needed to do something : strange like send a GA code. But 255, 249 isn't recognised by the : talkers, which appears to worsen matters. : : So HELP!!! What am I doing wrong? How can I get my program to see : these unterminated prompts before it sends any output back to the : server. : There really is no longer any reason for everybody to write their own Telnet implementation from the ground up. It's all been done for you already in C-Kermit: http://www.columbia.edu/kermit/ckermit.html This is a Telnet client that: . Includes its own programming language, allowing you to write your application at a high level without needing to know a thing about Telnet protocol details, NVTs, etc. . Runs on every known variety of UNIX, as well as on VMS, VOS, AOS/VS, and other platforms. . Has compatible companion programs for Windows, DOS, OS/2, etc. . Offers lots of other services including file transfer and management, character-set translation, etc, on the Telnet connection. . Also can make other kinds of connections: dialed, Rlogin, and on some platforms X.25, LAT, etc. As you describe your application, it could be programmed very simply about like this: .myname = joedoaks set host someserver.com /telnet if fail exit 1 {Can't make connection} input 10 {give me a name:} if fail exit 1 {No name prompt} lineout \m(myname) .\%n = 0 while true { input 10 {COM>} if fail { increment \%n if ( > \%n 10 ) exit 1 {Timeout waiting for command prompt} echo WARNING: Missing command prompt - trying again... lineout continue } else { .\%n = 0 (do whatever you wanted to do here...) } } As you can see, the Telnet details are completely transparent to your program. Therefore the same script can easily be adapted to other communication methods. And it can also be run on hundreds of different platforms with little or no modification. To see lots of sample Kermit scripts, visit: http://www.columbia.edu/kermit/ckscripts.html To find out about all that Kermit's telnet client is doing for you behind the scenes, see: http://www.columbia.edu/kermit/telnet.html - Frank ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.unix.programmer,comp.protocols.kermit.misc Message-ID: <8ambce$dro$1@newsmaster.cc.columbia.edu> References: <8ak6qk$qse$1@nnrp1.deja.com> <8allt6$p76$1@newsmaster.cc.columbia.edu> <8am990$9jj$1@nnrp1.deja.com> Date: 14 Mar 2000 21:36:14 GMT Organization: Columbia University From: Frank da Cruz Subject: Re: Sockets programming: telnet problem. In article <8am990$9jj$1@nnrp1.deja.com>, wrote: : ... : Thanks! While I will take a look at C-Kermit, I am still writing my : ground up code simply for my own experience and sense of : satisfaction. : : I really am VERY curious as to what the probelm is and why I'm not : seeing those prompts until after input, so I really would be very : appreciative if someone could still answer my question via email : (jrc@aardsets.com). : : Thanks very much for the information, and rest assured, I WILL take : a look at that, but I'm also determined to complete what I've started. : Sure, but be warned: it's a slippery slope. Telnet is not a simple protocol, at least not any more. It started out as RFC854 in 1983 and has grown ever since. A current search of the RFC database for "telnet" turns up 107 references. Unfortunately, all too many people crank out ad-hoc Telnet clients by (a) trial and error (b) asking somebody how to do it and then acting on bad advice (c) copying some code they found by searching the Internet or (d) following RFC854 but nothing else All of these, including (d), are likely not to work when fielded against the variety of Telnet servers, ancient to modern, that exist today. Doing it right is a long, hard, big job, and the job doesn't end when just one test case works. While I'm at it, I should mention that more than a few Telnet servers violate the IETF standards. Unfortunately, many writers of Telnet implementations don't know this, and so tailor their programs to work with the faulty servers, thus propagating their errors and making matters more difficult for everybody. Again, see: http://www.columbia.edu/kermit/telnet.html to get an idea of some of the considerations that must go into writing modern and correct Telnet sofware, especially the later sections that deal with broken Telnet implementations. - Frank ////////////////////////////////////////////////////////////////////////////// Date: Thu, 21 Sep 2000 05:01:07 GMT Organization: @Home Network Newsgroups: comp.terminals Message-ID: <39C9954F.F9F5E78@gbahn.com> From: Colin Barry Subject: data Does anyone know how I could find out what the most popular terminal emulations are? I am writing a terminal emulation program and have started with ANSI, Wyse 60 and VT100. I'm starting VT220 next. Can anyone offer an opinion or where I could find legit statistics? Many thanks Colin ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals Message-ID: <39CB5694.78888B85@rdel.co.uk> References: <39C9954F.F9F5E78@gbahn.com> Organization: RDEL Date: Fri, 22 Sep 2000 13:54:44 +0100 From: Paul Williams Subject: Re: data Colin Barry wrote: > > Does anyone know how I could find out what the most > popular terminal emulations are? I am writing a terminal > emulation program and have started with ANSI, > Wyse 60 and VT100. I'm starting VT220 next. Can anyone > offer an opinion or where I could find legit statistics? I woke up this morning and the first thought that entered my head was: "There just aren't enough terminal emulators in world." You'll quickly discover that there is no well-defined thing called an ANSI terminal. You'll also find many lists on the Web that purport to list VT100 escape sequences. To take one at random from Google: a page[1] saying that the VT100 sequence to save the cursor position is "CSI s". Oh dear. This is a minefield that you'd need a really good reason to step into. Is there something fundamentally wrong with the hundreds of other emulators out there? [1] http://www.csd.uch.gr/~athaks/manuals/vt100esc.html -- Don't rely on this list! ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals, comp.unix.programmer References: <3be716b8@news.uni-ulm.de> <9rv1l8$s3c$1@newsmaster.cc.columbia.edu> Message-ID: Organization: Stratagy Users Group Date: Tue, 6 Nov 2001 17:30:30 -0500 From: Richard S. Shuford Subject: Re: vt420 emulation on solaris 7 (keyboard differences) Richard S. Shuford wrote: > > I'm not sure what you mean by the "end" key. There is no key on a Sun > keyboard with this label, nor is it a key on any DEC keyboard that I > recall. and Sven Mascheck corrected: | | At least Sun Type-4, -5 and -6 provide a cap labeled End. | However, in contrast to X11, there is no explicit name for it | in console mode, keytables(4), but it's just a "function" key. He is correct. In glancing quickly at the Sun Type 5 keyboard that sits at my right elbow, I overlooked the "End" key--but there it is, right between "Del" and "Page Down". This reminds me of the general problem: In terminal emulation, there is often a design conundrum: do you re-assign function keys according to how they are labeled, or according to their position on the keyboard? Sometimes you need to maintain the position of the key on the keyboard that you are emulating; other times maybe you want to match the label as closely as possible. The editing bank of function keys on the Sun keyboards is pretty close to those on a 102- or 104-key PC keyboard: +-------------+-------------+-------------+ | | | | | Insert | Home | Page-Up | | | | | +-------------+-------------+-------------+ | | | | | Delete | End | Page-Down | | | | | +-------------+-------------+-------------+ ..but the DEC LK201 has its own editing-key arrangement: +-------------+-------------+-------------+ | | | | | Find | Insert-Here | Remove | | | | | +-------------+-------------+-------------+ | | | | | Select | Prev-Screen | Next-Screen | | | | | +-------------+-------------+-------------+ ..and you can see that the meanings don't correspond by position. So, you might find it set up either way, depending on which emulation you are running (or in the X Windows CDE dtterm/xterm case, on settings in ~/.Xresources and ~/.Xdefaults). | > http://www.cs.utk.edu/~shuford/terminal_index.html | > | > You should look to the "xterm" page and see several links and Jeff Altman astutely noted: ) ) [...] the VMS [application] should query for the keyboard type via ) a control sequence and not make assumptions based upon the terminal ) type string provided by telnet. ...RSS ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals References: <55dac88b.0302210526.3e82edd9@posting.google.com> Message-ID: Organization: http://vt100.net Date: Tue, 25 Feb 2003 20:55:55 -0000 From: Paul Williams Subject: Re: VT100 emulator buffer eliofungi@hotmail.com (Elio Fungi) wrote in news:55dac88b.0302210526.3e82edd9@posting.google.com: > I developed a terminal emulator (VT100), but now I have a doubt: when > the terminal receives the sequence ^[H^[J (where ^ is escape > character) it means: HOME and CLEAR from cursor position to the end of > screen. Now, what about the buffer? Is it cleared 1 page? I have seen > that Hyperterminal keeps the old history and scrolls 1 page after this > command, whilst other terminal emulators do not, and overwrite the > last page of buffer. I don't see why any emulator would clear or scroll one page on receipt of the sequence you gave, because it is only supposed to clear to the end of the display. If you are asking about CSI 2 J, which does clear the complete display, then the correct behaviour depends on your definition of "display". As Thomas mentioned, the display can be at most 24 lines long on a VT100, but for later VTs the lines on the screen could be part of a longer page. On a VT520, for example, you might have a screen length of 24 lines on a page that is 72 lines long. In this case, the display is taken to be the entire page. IMO, the scrollback buffer of an emulator (or the top-most lines of the page) only presents a useful picture of your session if the display has been updated sequentially, top to bottom. If you've just typed a file to the screen and the top lines have scrolled out of view, the scrollback buffer allows you to see them without redisplaying the entire file. However, for applications which use the entire screen and are likely to use Erase in Display (ED), the scrollback buffer doesn't provide any useful history information. In summary, I don't think it matters to the user which behaviour you pick, though if you wish to extend your emulator beyond VT100 capability, you should erase the entire page/buffer. - Paul ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals References: <55dac88b.0302210526.3e82edd9@posting.google.com> <55dac88b.0302280741.45bf68f7@posting.google.com> Message-ID: Organization: http://vt100.net Date: Fri, 28 Feb 2003 16:55:00 -0000 From: Paul Williams Subject: Re: VT100 emulator buffer eliofungi@hotmail.com (Elio Fungi) wrote in news:55dac88b.0302280741.45bf68f7@posting.google.com: > > I cannot understand: in the first sentence you said that you dont see > why the emulator would clear one page, and in the second you suggest > me to clear the page. Could you explain? I'm sorry, I confused things by only looking at the ED sequence (CSI J), which clears from the cursor position to the end of the display. However, you had already sent CSI H to move the cursor to the home position, so the entire display should be cleared. -- Paul ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals NNTP-Posting-Host: 65.87.184.196 NNTP-Posting-Date: Sun, 09 Nov 2003 01:48:14 EST Message-ID: Date: Sun, 09 Nov 2003 06:48:14 GMT From: Kevin L Subject: ANSI/VT100 emulation: how to handle CSI sequence with multiple params? Hi all, It's late and my eyes are drifting, and I can't seem to find the answer to a simple question. I'm writing the VT100 emulation for an open-source emulator (see http://qodem.sourceforge.net/ , y'all might get a kick out of it :) ) and ran across this problem: How should a CSI sequence that takes 1 parameter be handled if multiple parameters are sent? Example: "CSI 3 ; 4 A" Should my parser: 1. Discard the sequence? 2. Treat it like "CSI 4 A" ? I.e. move four characters right 3. Treat it like "CSI 3 A" ? I.e. move three characters right 4. Treat it like "CSI 3 A CSI 4 A" ? I.e. move seven characters right 5. Something else? More details: I'm implementing a subset of Paul William's excellently-documented DEC ANSI parser state machine http://vt100.net/emu/dec_ansi_parser (BTW I had to add a state to handle the sequence "ESC Y l c" when in VT52 mode.) I know that CSI sequences that take a variable number of arguments should be handled like #4 above, and also that a CSI sequence lacking an argument has a default value. But I couldn't find an example in the DEC documentation or the ECMA docs that covers this situation: a CSI sequence with precisely one argument that has multiple arguments specified. Any ideas? .............................................................................. Newsgroups: comp.terminals References: Message-ID: Organization: VT100.net Date: Sun, 09 Nov 2003 09:54:49 +0000 From: Paul Williams Subject: Re: ANSI/VT100 emulation: how to handle CSI sequence with multiple params? On Sun, 09 Nov 2003 06:48:14 +0000, Kevin L wrote: > > How should a CSI sequence that takes 1 parameter be handled if multiple > parameters are sent? In the description of the "dispatch" action, it says: "The selected control function will have access to the list of parameters, which it will use some or all of. If more parameters are supplied than the control function requires, only the earliest parameters will be used and the rest will be ignored. If too few parameters are supplied, default values will be used." In other words, it is handled as in #3. > But I couldn't find an example in the DEC documentation > or the ECMA docs that covers this situation: a CSI sequence with > precisely one argument that has multiple arguments specified. The possible error cases are too numerous for the specifications to cover. -- Paul .............................................................................. Newsgroups: comp.terminals NNTP-Posting-Host: 65.87.184.196 NNTP-Posting-Date: Sun, 09 Nov 2003 09:41:23 EST References: Message-ID: Date: Sun, 09 Nov 2003 14:41:23 GMT From: Kevin L Subject: Re: ANSI/VT100 emulation: how to handle CSI sequence with multiple params? Paul Williams wrote: > > In other words, it is handled as in #3. D'oh! And I remember reading that! Thanks for the reminder. While we're on the topic, another thank-you for the section on the parser, AND the VT100 manuals in convenient HTML form! :) The state machine looks daunting at first, but once you fully stub it in and start putting in the dispatch actions it just falls right into place. ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals NNTP-Posting-Host: 198.152.13.71 NNTP-Posting-Date: 24 Jul 2003 04:55:42 GMT Message-ID: Date: 23 Jul 2003 21:55:42 -0700 From: Ralph Warta Subject: AT386 terminal specs needed Hi, Does anyone possess the specs for a AT386 terminal (including charsets)? I need it because I have to write a Terminal Emulator but cannot find the specs for the AT386. Thanks Ralph .............................................................................. Message-ID: Date: Thu, 24 Jul 2003 19:22:53 -0400 (EDT) From: Richard S. Shuford Subject: Re: AT386 terminal specs needed The AT386 is the virtual terminal type of the Unix operating system product originated by Interactive Systems and later taken over by Sun Microsystems. Some versions of SCO Unixware also implement the AT386 as the console terminal type. Some of the AT386's properties may be deduced from its terminfo description, which in Solaris resides in binary form at /usr/share/lib/terminfo/a/at386 Here is the termcap-style decoding: $ infocmp -C at386 AT386|at386|386AT|386at|at/386 console @(#)386.ti 1.4:\ :am:bw:eo:xo:pt:\ :co#80:li#25:kn#6:\ :AL=\E[%dL:DC=\E[%dP:DL=\E[%dM:DO=\E[%dB:IC=\E[%d@:\ :LE=\E[%dD:RI=\E[%dC:SF=\E[%dS:SR=\E[S:UP=\E[%dA:\ :ae=\E[10m:al=\E[1L:as=\E[12m:cd=\E[J:ce=\E[K:\ :cl=\E[2J\E[H:cm=\E[%i%2;%2H:dc=\E[P:dl=\E[1M:ho=\E[H:\ :ic=\E[1@:is=\E[0;10m:k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:\ :k5=\EOT:k6=\EOU:k7=\EOV:k8=\EOW:k9=\EOX:kb=\b:\ :kd=\E[B:kh=\E[H:kl=\E[D:kr=\E[C:ku=\E[A:nd=\E[C:\ :se=\E[m:so=\E[7m:ue=\E[m:up=\E[A:us=\E[4m:vb=^G:\ :bc=\E[D:nl=\E[B:ko=le,do,nd,up,dc,ho: If you don't know how to interpret a "termcap" entry, there is a book to read: "termcap and terminfo" by John Strang, Linda Mui and Tim O'Reilly 3rd Edition April 1988 270 pages, ISBN: 0-937175-22-6, $29.95 U.S. http://www.oreilly.com/catalog/term/ http://www.amazon.com/exec/obidos/ISBN=0937175226 Kermit-95 (and possibly MS-Kermit) have AT386 as an emulation type. You could consult that documentation, and possibly the documentation of other products that emulate the type. ...RSS ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals Organization: UKFSN.ORG Message-ID: <87ves7ea4k.fsf@hardknott.home.whinlatter.ukfsn.org> NNTP-Posting-Host: 84-45-213-194.no-dns-yet.enta.net NNTP-Posting-Date: Mon, 15 May 2006 12:40:04 +0000 (UTC) X-Trace: slavica.ukpost.com 1147696804 17253 84.45.213.194 (15 May 2006 12:40:04 GMT) User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux) X-GnuPG-Key: 0x25BFB848 Date: Mon, 15 May 2006 13:38:19 +0100 From: Roger Leigh <${rleigh}@invalid.whinlatter.ukfsn.org.invalid> Subject: Terminal emulation with separate data and presentation components Hello, I'm interested in writing a terminal emulator that implements most of ECMA-48 (including full ECMA-35/ISO-2022 and ECMA-43 support). While I've done most of the ECMA-35/ECMA-43 support, one point I'm looking for some guidance with is the the separation of the data and presentation components. In a "typical" terminal emulator, there is only the presentation component, so the representation is potentially as simple as a 2D array. With the data and presentation components, the data component stores the data in the order it was received, so in the case of mixed left-to-right and right-to-left text, this is in the order it would be written and read. In the presentation component, it is in the order it would be displayed on screen. So, for example, if the text is mainly LTR, embedded RTL words would be reversed here. The problem is in the mapping from one to the other. For example, the cursor may be moved visually right or left in the presentation component, or logically right or left in the data component, and both need to be kept in sync. It's possible to implement both without having two copies of the data, but I'm yet unsure of the performance and complexity tradeoffs. I could, for example, store each line in the data as a linked list, and then cache the presentation component as a list of pointers into the data. I'm interested in looking at any existing (free software) implementations, or any other material on the subject, so long as it's not patent or otherwise encumbered (my program will be licensed under the GNU GPL). Many thanks, Roger -- Roger Leigh Printing on GNU/Linux? http://gutenprint.sourceforge.net/ Debian GNU/Linux http://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals NNTP-Posting-Host: cpc1-mfld5-0-0-cust674.nott.cable.ntl.com NNTP-Posting-Date: Mon, 14 Dec 2009 18:40:58 UTC References: <2j17s6-5d6.ln1@news.anatron.com.au> <91b9a6f1-df4b-4251-a8d4-767c23fcc677@f18g2000prf.googlegroups.com> Message-ID: <_EvVm.37665$Vq3.32310@newsfe04.ams2> Organization: virginmedia.com Date: Mon, 14 Dec 2009 18:41:28 +0000 From: Paul Potter Subject: Re: newbie terminal doubt Russell Shaw wrote: > > deostroll wrote: > > > > when we speak of building terminal emulators, is there always a screen > > size we have to consider...? > > If making one for the X windowing system, if you resize the X terminal > window, your emulator should be notified of this, and send a SIGWINCH > signal to the process running on its PTY. > > http://en.wikipedia.org/wiki/SIGWINCH I wondered how that was done. Paul //////////////////////////////////////////////////////////////////////////////