thad@cup.portal.com (Thad P Floryan) (02/01/90)
bdb@becker.UUCP (Bruce Becker) in <3060@becker.UUCP> brings up some good points re: VT100 emulation, termcap/terminfo, etc. If one calls INTO one's UNIXPC and selects TERM=dt80 (a faster, better VT100 emulation) using a DT80 (or a VT100 :-), everything is fine for the remote user. If one wishes to (logically) "cu" OUT from one's system, THEN the need for a proper VT100 (or whatever) emulation package becomes painfully evident; no termcap or terminfo will help under this condition. As I replied to someone else in e-mail, the areas in which most terminal emulations fail miserably (on any system (3B1, Amiga, Mac, IBM PC, Atari ST, etc.)) include: double-wide and double-wide/-high characters VT100 alternate and graphics character sets scrolling regions video attributes (bold, blink, underline, reverse, etc.) 80 and 132 column displays other "DECPRIVATE" functions Even expensive commercial products such as Mirror II for the IBM-PC fail miserably ... they just don't work properly when calling INTO other systems that insist on a "proper" VT100 emulation. This is NOT a trivial concern. A *LOT* of commercial applications REQUIRE proper emulation. I didn't realize myself how BAD the problem is until last week when one of my clients started using an existing application on one of my VAX systems and NOTHING they could run on their IBM PCs performed properly because of the poor VT100 emulation (of their PC-based terminal emulators). So-called "developers" have ASSUMED (there's THAT word again! :-) that VT100 implies ANSI ... that is NOT the case, and that's why the Per Lindberg VT100 Validation Suite (whose availability on UUNET, osu-cis, elsewhere) I posted recently. The Per Lindberg suite is a UNIX- or DEC-20 hosted emulation test package whose use is mandatory if one is using or writing an emulator. For the record, NO version of PCOMM emulates a VT100, and NO claim was made by the author that it did. Contrast that with all the hokey emulators which DO claim "VT100" but don't perform worth beans when talking to a VT100-based application. "X", curses and termcap/terminfo notwithstanding, there are a LOT of applications in the real world requiring proper emulation. Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]
bdb@becker.UUCP (Bruce Becker) (02/02/90)
In article <26488@cup.portal.com> thad@cup.portal.com (Thad P Floryan) writes: |[...] |If one wishes to (logically) "cu" OUT from one's system, THEN the need for a |proper VT100 (or whatever) emulation package becomes painfully evident; no |termcap or terminfo will help under this condition. | |As I replied to someone else in e-mail, the areas in which most terminal |emulations fail miserably (on any system (3B1, Amiga, Mac, IBM PC, Atari ST, |etc.)) include: | | double-wide and double-wide/-high characters Not provided in 3B1. | VT100 alternate and graphics character sets This is provided! The 'SO' (0x0D) character selects font 1, which can be loaded from the stock set to be a DEC-style line-drawing font. What's missing is the "ESC-(" and ESC-)" character-set loading commands. | scrolling regions Not provided. | video attributes (bold, blink, underline, reverse, etc.) This is provided! (except for blink) | 80 and 132 column displays Not provided. | other "DECPRIVATE" functions Linewrap is provided, except the code sequence is different. On the other hand, VT102-style editing is supported. |Even expensive commercial products such as Mirror II for the IBM-PC fail |miserably ... they just don't work properly when calling INTO other systems |that insist on a "proper" VT100 emulation. | |This is NOT a trivial concern. A *LOT* of commercial applications REQUIRE |proper emulation. Certainly DEC VMS products seem to require full compatibility, it's true. I've seen a very nice FULLY-compatible emulation only once, on an Amiga shareware package called "Handshake". It provides full VT-220 emulation, and is a superior product. (Details on request) |For the record, NO version of PCOMM emulates a VT100, and NO claim was made |by the author that it did. My apologies, what I assumed was the VT100 support of Pcomm must have been underlying console window support only. Some questions to anyone: How can I get "cu" (the HDB version) to actually talk even parity? How can I get "async_main" to work with HDB? Doesn't "async_main" provide better "real" VT100 emulation? -- (__) Bruce Becker Toronto, Ont. w \@@/ Internet: bdb@becker.UUCP, bruce@gpu.utcs.toronto.edu `/v/-e BitNet: BECKER@HUMBER.BITNET _/ \_ Well I didn't want to mention it cause it's so silly, but you know how
thad@cup.portal.com (Thad P Floryan) (02/04/90)
bdb@becker.UUCP (Bruce Becker) in <3232@becker.UUCP> comments some more about VT100 emulators. Confirming his comment about "Handshake" (for the Amiga), it actually passes the Per Lindberg suite! It's the program I use exclusively on my Amigas. However, this *IS* the UNIXPC newsgroup, so ... continuing ... Some questions to anyone: How can I get "cu" (the HDB version) to actually talk even parity? The docs I have state "-e designates that even parity is to be generated for data sent to the remote system." I'm still testing this (and odd parity), so far it appears to be OK, but I'm not yet convinced the test system I'm using is itself responding properly to parity ... more details later after I connect a Data Line Monitor. How can I get "async_main" to work with HDB? I don't understand the question. "async_main" is the terminal emulator for the UNIXPC ... how COULD it be expected to function with HDB? Unless you're referring to the lockfile. Would you please elaborate further? Doesn't "async_main" provide better "real" VT100 emulation? My tests confirm "async_main" is an ANSI emulator and, as such, works as one would expect. It most definitely is NOT a VT100 emulator ... it does not perform as does a real VT100 (which I have here in addition to the DT80). If anyone's really interested, I "could" post the Per Lindberg VT100 Validation Suite that one could test by calling OUT from then back INTO one's own system. But because of its size, it's best that interested parties get it direct from the archive sites; I can repost the (known to me) archive site information if you missed it before (it's available on uunet.UU.NET and osu-cis among other places). Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]
ignatz@chinet.chi.il.us (Dave Ihnat) (02/06/90)
In article <3232@becker.UUCP> bdb@becker.UUCP (Bruce Becker) writes: > Certainly DEC VMS products seem to require > full compatibility, it's true. Well, true, *if* you call the terminal a true VT100. BUT, VMS supports a termcap-like capability that would easily allow you to define the subset of the VT100 capabilities your emulator supports, and to call the thing a different foreign terminal. Such an approach *is* a kludge, and *is* inelegant. But. It works. I wrote a memorandum for one of my clients which excerpted the necessary information to create such a foreign terminal support entry; it's certainly no more difficult than writing a termcap/terminfo entry. All the info is in the VMS manual set, too. Dave Ihnat Analysts International Corp. ignatz@homebru.chi.il.us (preferred address)
michaelb@mikebat.UUCP (Michael R. Batchelor) (02/09/90)
> How can I get "async_main" to work > > I don't understand the question. "async_main" is the terminal emulator for > the UNIXPC ... Well I have an even more basic question about async_main? How do I get it to do anything? It was on the disk when I bought the machine, and I don't have any docs for it. The office doesn't show any communications software is installed. I played with it for a few days figuring it had to be some- thing to do with asynchronous communications, but I couldn't figure out the correct syntax. Michael -- Michael Batchelor / KA7ZNZ uunet!wshb!mikebat!michaelb Ships don't come in; they're built. -- (I don't know who said it.)