Mark Crispin (MRC@PANDA.PANDA.COM)
Wed, 24 Feb 88 18:03:50 PST
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.
This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:41:30 GMT