GREG@FNALNET.BITNET (02/24/88)
I have just installed the CMU TCP/IP package on several Microvax'en and am experienced a strange Telnet situation. The DEC TPU editor screen and cursor functions do not work properly if the terminal is defined as device=VT200, but work if defined as device=VT100. Have I done somthing wrong? Is this a known or documented bug (feature)? Have any of you experienced this as well? Thanks, Greg Chartrand - Fermilab P.O. Box 500 - Batavia, Il. 60510 (312) 840-3727 GREG@FNAL.BITNET or GREG%FNAL.HEPNET@LBL.ARPA
JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen") (02/25/88)
DEC editors usually have strong opinions about using VT220s in 8-bit mode, and most Telnet streams won't pass 8-bit unless the 'binary' option has been agreed upon. Few Telnet clients or servers even support 'binary', and there is still a group of Neanderthals out there who insist on sending parity in the 8th bit, so you just can't turn off the masking operation. Some time back, I suggested a concerted campaign to identify and sit upon those who send parity, so the rest of us can just make the masking operation optional, but I got shot at, and am now quietly implementing 'binary' in my own Telnets. Fat lot of good that will do most people. jbvb
MRC@PANDA.PANDA.COM (Mark Crispin) (02/25/88)
I sympathize with JBVB's problem. I've been fighting it for almost 10 years now, both in my own code (Telnet implementations for 3 different operating systems) and in other's code. As far as I know, Telnet implementations which get various of these complexities right are few and far between. Here's my own list of Neanderthals: . host systems which send parity over Telnet connections. These are becoming rarer over time, but there's still a few out there. . operating systems which can't tell the difference between a terminal which sends parity and one which doesn't, making it virtually impossible for the Telnet client to know what to do with that 8th bit. ITS is the only OS I know that lets an application know that the 8th bit is significant. WAITS gets partial credit for supporting this for terminals it recognizes under its display service. VAX/VMS may also be a winner. I believe Unix flunks, as does most versions of TOPS-20 (only PANDA TOPS-20 has a "parity terminal" status bit). . Telnet servers which confuse Telnet binary state with some local concept of what is binary. Tenex gets a big, red F in this (this was the infamous "new Telnet performance bug" of the late 70's), as do certain versions of Unix which associate Telnet binary with something called "raw mode." This is one of the most serious problems facing Telnet application developers trying to do something useful with 8-bit I/O. . operating systems which have no way to instruct the Telnet server to get out of binary mode. WAITS and PANDA versions of TOPS-20 are the only OS's I know of that handle this problem, which is what once a TAC user does @B I S he can't get out of binary mode. . Telnet servers which fail to double '377 (FFh for you Unix guys). Most versions of TOPS-20 (except for PANDA) have this serious bug, and it's led to a plethoria of programs which manually double FFh. Guess what happens when you try to run such programs on a PANDA system which does it right... The most distressing part about all of this is that these bugs are ancient bugs, that intelligent hackers have fixed years ago, but still broken versions continue to proliferate. -------