switch (d->inbuf[nSkip])
{
case 8:
case 127:
d->inbuf[nSkip] = '\b';
write(d->descriptor, "\b \b", 3); // handle backspace.
break;
case '\n':
write(d->descriptor, "\r\n", 2);
break;
default:
if (IS_SET(d->comm_flags, COMM_FLAG_PASSWORD))
{
write(d->descriptor, "*", 1);
}
else
{
write(d->descriptor, d->inbuf + nSkip, 1);
}
break;
}
I'd rather avoid character mode.
Some notes based on quick experimentation..
I am not sure whether character mode is defined as where the client sends characters as they are entered, and the server echos them back. Or whether it is just the client sending the characters as they are entered, rather than as the user hits enter. But during my experiments just now, Windows Telnet seems to engage in the latter by default.
Experiment 1: The goal was to verify the correctness of the claim that Windows Telnet will stop its local echoing when server-side negotiation is attempted. I removed all negotiation and connected, the client was echoing correctly. I added back TTYPE negotiation and connected, the client had stopped echoing. I replaced TTYPE negotiation and connected, the client also stopped echoing.
Conclusion 1: When a server negotiates with Windows Telnet, it does turn off local echo.
Experiment 2: The goal was to see whether a fix applied by the client's user was practical and what it involved. This would not be an ideal solution, but it would be one regardless. I enabled only TTYPE negotiation and connected. Then I entered the Windows Telnet settings screen by pressing "CTRL-]". I then typed "st" (short for status) and saw nothing about the localecho setting. So I typed "set localecho" which gave a statement that it was set. Exiting the settings screen and typing, Windows Telnet was now doing local echo again.
Conclusion 2: The user of Windows Telnet in this situation can fix the problem. Given that it is possible to detect Windows Telnet, a MUD could tell a connecting user "Hey, look, your client is not the best one, but you can use it here if you do this.."
Experiment 3: The goal was to see if it was possible for a server to negotiate Windows Telnet back to doing local echo. I enabled NAWS and on receiving its response, I send a DO ECHO. I waited for the response in case handling of other options at approximately the same time negated the DO ECHO request. Windows Telnet responded with WILL ECHO, but did not do local echo.
Conclusion 3: This is a bug in Windows Telnet. It may be there is another way to work around it, but it is non-obvious. This is a pretty bad bug, but overall I am extremely impressed by Windows Telnet and the level of support it has for things like escape sequences.
So the result of this, is that it looks like conclusion 2 is the only workable option. Is it possible to do it in a way that doesn't discourage users? I don't see why not.