One problem that the VT100 emulators may have is that they behave
according to the published VT100 specifications rather than the actual
hardware behavior.
They behave like the author of the emulator thinks the documentation describes.
But often, ambiguity in descriptions lead to bad decisions here, especially when
you go to the far right of the screen, the bottom right corner, etc. There's several
quirks of VT100 behavior that just aren't clearly documented. They aren't bugs,
per se, but people depend on that behavior.
The VT100 had notoriously buggy firmware. Alan Kotok, one of DEC's
early engineers, encountered some of these and was annoyed enough
about it that he wrote a program to generate a complete list of escape
sequences--legal and illegal--which he fed to his VT100 terminal. The
results were highly entertaining. Some perfectly valid escape
sequences were mishandled by the firmware and had behavior that didn't
match the documentation. Even worse, some illegal escape sequences
caused catastrophic behavior, such as the terminal freezing with the
alarm continuously on--the only way out was to power-cycle the
terminal. One particularly nasty escape sequence caused corruption of
the EPROM such that the terminal crashed on power-up or restart,
resulting in an infinite crash-and-restart loop that could only be
fixed by sending the terminal in for a factory reset.
Kotok published his results within DEC engineering and shortly
thereafter "email bombs" containing escape sequences that triggered
some of the milder of the bugs started circulating. The VAX/VMS mail
utility had to be changed to filter out escape sequences by default.
Yea... Those are fun... I wonder how many got fixed in later versions?
I'd also read somewhere that VT220 development was slowed by
having to behave exactly the same way as the VT100s (the above
example was one given)... But at least they had the benefit of being
able to look at the old firmware code... At least I'd suppose that was
a benefit...
Warner