I have been looking into the best way to get the various telnet clients at my disposal to be usable in my roguelike. Given how long telnet has been in use, it surprises me how little of the useful information that is out there, is coherent and easily locatible. Even trying to locate a coherent overview of the ANSI escape codes is not a straightforward matter. I haven't tried many telnet clients, but neither of the two I have tried are immediately suitable.

Windows telnet: ANSI escape codes do not work in a reliable fashion. Simply moving the cursor around and printing characters results in display corruption.

Windows telnet supports four different terminal types. ANSI, VT100, VT52 and VTNT. Now the second and third are as I understand it a decreasing subset of the first. And the first is the one that exhibits the unreliable ANSI support. So this leaves VTNT. Microsoft provide some documentation on VTNT here which indicates it is a custom protocol. And there is some reverse engineering what went on in this old thread.

The question is, is it possible for a server to support this terminal type in such a way that Windows Telnet can be made to display in a reasonable fashion?

Putty: This uses the ISO-8851-1 character set by default, which does not include many of the more useful graphical characters. The user can be instructed to manually set their saved session to use CP437, but this complicates matters.

Is it possible for the server to instruct Putty to use a terminal type that uses CP437? No. Putty links its character set usage to what is selected by the user through its UI, so even if Putty supported a suitable terminal type, it would not matter. It is almost irrelevant to note that Putty only provides the "xterm" terminal type at this point.

Googling yielded a reference to a CHARSET telnet negotiation option. These RFC documents are quite unintelligible, so instead of reading it, I googled again to see if Putty supported it. A very relevant search result informs that Putty's author was not even aware of it, and therefore Putty does not support it. But that Putty did support some other escape codes which do something unclear, but these would not set code page 437 anyway.

So this leaves the questions of what do these escape codes do?

Reading the Putty source:

ESC(A: Set the United Kingdom G0 character set.

ESC(B: Set the United States G0 character set.

ESC(0: Set the Linedraw G0 character set.

ESC(U: Set the SCO Alternate G0 character set.

ESC)A: Set the United Kingdom G1 character set.

ESC)B: Set the United States G1 character set.

ESC)0: Set the Linedraw G1 character set.

ESC)U: Set the SCO Alternate G1 character set.

ESC%G/ESC%8: Turn UTF support on.

ESC%@: Turn UTF support off.

Trying these in Windows telnet:



Trying these in Putty:



It's not surprising that Windows telnet does not support these escape codes, but it doesn't need to, it already uses cp437. What is interesting however, is that the last code ESC(U makes Putty use cp437. Who knew SCO were good for something? So we do not need to prompt a Putty user to set their translation character set and can effectively do it ourselves.

So, what is the difference between these G0 and G1 things? As I read it, G0 is the default mode, so the escape codes I show printed above change it while it is in use. But G1 can be switched to with CTRL+N and G0 switched to with CTRL+O. Let's give this a shot in Putty, as this has been shown to be irrelevant for Windows telnet.



Success. With interleaving of control codes, the alternate character sets can be used in Putty. However it should be noted that Putty distorts characters through its default use of antialiasing, as can be noted by comparing the following picture to the preceding one (check out the characters immediately under "abc" within the displayed G1 mode character set).



Further research

Antialiasing usually makes things look distorted. Are the distorted antialiased by default Putty characters detrimental to the point where Putty should be detected and its users guided towards disabling it?

VTNT may provide a way to make Windows telnet usable, given how bad its escape code support is. No-one seems to have written and open sourced server code for it. Is it worth doing so?

Putty supports switching on UTF character sets through the ESC%G, does this allow a roguelike access to a consolidated selection of characters that will allow an enhanced and more comprehensible display? What other possibilities does it provide?

Is it possible to create a telnet server that attempts to catalogue the behaviour of any client that it gets connected to with, with the aid of the client's user?

This is about as far as I can take this at this time without getting further side-tracked to the point of unproductiveness, with regard to my roguelike endeavours. If anyone has any thoughts on the things I have posted here, they'd be appreciated of course.

While I have it fresh in my mind..

So what is the Windows telnet ansi escape code problem?

If your DOS console screen buffer size is larger than the window size, then Windows telnet sends the window size to the server, but movement of the cursor within that window size results in random scrolling. It seems that the telnet client gets confused about exactly where cursor x position 1 is for instance.

I have basically nothing constructive to add to this, and I will probably never use the information you have posted here, but I just want to tell you that I love you for creating this thread. This is an excellent post and I wish problems and questions people posted were always done with this level of depth.

Did you set the scrolling region with \e
Did you set the scrolling region with \e[r ?

One thing I know that's broken with windows telnet is that you need to set the top line as non scrolling for it to work properly, otherwise I've never had much trouble with it. Keep in mind that windows telnet is disabled by default as of Windows Vista.

Something I proposed a while ago is for someone to make a general purpose mudding font with a useful set of drawing characters.

IMHO, Microsoft's Telnet is a lost cause for a couple reasons; It starts with local echo on and if you tell it to suppress local echo it will – but it will then ignore any requests to re-enable it. Starting with Vista, it is no longer installed by default which, previously, was its sole advantage against other, more robust clients.

Assuming you still want to try, I can tell you that Windows Telnet will respond to the 'Get Terminal Type' IAC with "ANSI". It shares this trait with SimpleMU. Here's the list of clients I tested;
http://code.google.com/p/bogboa/wiki/Ter...


Back when SCO stood for the 'Santa Cruz Organization', they had a pretty decent product providing UNIX on commodity hardware. I once had 20 some users running WordPerfect for UNIX on a 25Mhz 386. It was a shame to see them bought and turned into The SCO Group (Darl McBride's idiotic fireship against Linux).

I made a truetype font version of my handwriting last year using Inkscape + FontForge. It actually worked pretty well. Basing it from an open font like Deja Vu Mono Sans would make things 100x simpler – just replace the 'extended ASCII' portion. You'd even have unicode.

If I did that, no one'd be able to read it!

No, that's not 'Get Terminal Type', it's 'Select Terminal Type'. You might be aware that I use a gutted version of your telnet negotiation code. I've had to make some modifications to get it to work correctly with regard to clients that actively negotiate (i.e. Putty by default), and in general with how TTYPE works, and now my version enumerates all the available terminal types and allows selection of a preferred one.

Great link! I'll have to check out libtcod in more detail soon.

No, it got changed to 'Pedantically Procure Terminal Type With Needless Specificity That Doesn't Add Anything to the Conversation' in a secret revision.



Did I mention I just gave up coffee?

To the contrary, all I have done in this topic is add information. I've explored escape codes and character sets. I've explored terminal types and possibilities that lie there. You posted a misleading statement about terminal types, and a link to a page which only listed the first that each client selected. This is information, but of limited use. Knowing all the terminal types that a client supports is valuable, one use might be to fingerprint telnet clients and engage special handling for them on a case by case basis. And getting angry that I pointed that I fixed bugs in your telnet negotiation code? I am sorry that I tried to share useful information I discovered with you. If you are not open to amicable dialogue on matters like this, then why are you posting?

You are the one who is not adding anything to the conversation, other than hostility and a general lack of ability to actually state in a friendly way your problem. If you have a problem with my post, or me, then try and resolve it amicably. Are you trying to make me feel bad about the work I have been putting in to look into these matters?

I wouldn't spend too much time or effort trying to do ANYTHING for windows telnet. Windows 7 buries it deeply enough that most users won't be able to use it. It is no longer in the accessories menu, and also no longer in the standard path of your command shell. On my system, it's buried in C:\Windows\winsxs\amd64_microsoft-windows-telnet-client_31bf3856ad364e35_6.1.7600.16385_none_1426830c3ebb712d\telnet.exe!

The fact that it's not in the path, nor anywhere in a standard menu tells me even Microsoft assumes anyone who cares will be using a third-party client of some kind.

It is very nice to detail the incompatibilities of various clients though! Thanks for that! It might be good to merge in some of the xterm256/ANSI stuff too, since I know some clients only do the original 8-colour ANSI, but most now do the 16-colour "bold" version, sometimes at the expense of not supporting something else (IE: blink).

I was trying to offer a suggestion of where to start with Windows Telnet – namely, attempting to identify the client via RFC 1091. Then I shared the results I had found. Your response was to tell me that I referred to it by a slightly wrong name. You're welcome.

BTW, nowhere in 1091 nor your wiki page is it called 'Select Terminal Type'.



Do you have coffee?

TTYPE won't work for windows telnet, you need to go the NEW ENVIRON route. But as pointed out already, there's no future with windows telnet.

Gosh, that was an old post of mine.

:ghostface:

I remember looking at it at the time and coming to the conclusion: Windows Telnet is broken. It doesn't use the latest TTYPE spec, which allows for a repeated listing of terminal types. Instead, it uses the prior version, in which you're supposed to cycle through them until you find one you like.

When the terminal type of Windows Telnet is VTNT, it expects both input and output to be in the VTNT format I dissected … at least until the client has pressed an indeterminate number of keys. Then it reverts to normal format.

That was such a weird behaviour that I gave up.

Ironically, one way to make Windows Telnet behave was to have the client explicitly set the terminal type to be VTNT before connecting (I forget whether this was through a registry key or an actual setting). This would ensure that, whatever the final terminal type it came to rest on during the scan of the terminal types, it wouldn't be VTNT.

My thought was to start progressively, since Telnet support across the spectrum of clients is extremely dodgy. Since we have no clue what client has connected, see if it replies 'ANSI' and move forward.

But I completely agree that Windows Telnet is a dead end. Heck, that was my first comment.

Donky,

I would like to apologize for being oversensitive earlier. I noticed that Elanthis hasn't posted since I accused him of being condescending in Idealiad's thread and I feel pretty guilty about that. Believe me, it's not my goal to antagonize anyone. Apparently, I have trouble reading the tone of posts on here and that's something I need to work on. There's only a handful of people working on MUD code in Python and I certainly don't want to build any walls.

Sorry.

I think text as a medium is open to misinterpretation. I've had replies I have made that I would classify as exact literal statements described as snippy by others. If someone can't stick around to work out the possible misunderstandings, then that's unfortunate. In any case, no worries, if I get replies I do not understand the reason for I either just keep posting until I do, or let it go.

Don't feel bad Barm! It'd take a lot more then that to scare off Elanthis. When his school semester kicks in, he's virtually a ghost. He'll be back to getcha, don't worry ;).