TeSSH

While searching for a way to reproduce possible network connection delays in TeSSH, I was looking into Telnet Terminal Type differences between TeSSH and PuTTY. When connecting to the Windows Telnet Server (on Vista), PuTTY *only* sends "XTERM" in response to the terminal type telnet option. TeSSH sends XTERM first (since that is the value selected by default in the session preferences), but the Windows Server rejects this and asks for another terminal option. TeSSH sends the VT100 terminal type next, and the Windows Server accepts this. This behavior has caused me to add a new terminal type to TeSSH/CMUD called "Auto" which will allow the server to cycle through all supported emulations within TeSSH. If you enter a fixed terminal value (like XTERM), TeSSH/CMUD will no longer cycle to other options. This will allow TeSSH to use the XTERM option with the Windows Server just like PuTTY does. Why does this matter? Turns out that using a VT100 terminal type with the Windows Telnet Server is a HORRIBLE FAILURE! The Windows Server tries to be too smart and only sends the actual text that will be displayed on the screen...NO SCROLLBACK! For example, type the HELP command when using VT100 mode with the Telnet Server. Use the Script Debugger Raw Input/Out message and you'll see that only the final visible page of HELP text is actually sent by the Server to the client. And if you type HELP again, the Server doesn't send anything at all since it thinks the previous text is still already displayed. While this behavior might be nice for reducing network bandwidth, it's horrible on the client side if you want to scroll back. I want the ENTIRE HELP text so I can scroll to previous screens to read it. I don't just want the last screen portion. For a while I really thought TeSSH was broken since PuTTY didn't have any of these problems. It was only when I discovered that the Windows Server was selecting VT100 with TeSSH and XTERM with PuTTY that I tracked this down. I'll probably still use some of the VT100 mode to make sure the emulation in TeSSH is working perfectly. But I thought I should let people know about this behavior in case you telnet to a Windows Telnet Server. Be warned!