• Please review our updated Terms and Rules here

Next new application: Telnet?

Beta version available

Beta version available

I'd really like to get some input on what I have in the telnet client so far, and the best way to do that is to make it available. Here it is:


You should have the current mTCP DHCP client first. That is available from here:


Right now it supports the following:

  • Generic 'ANSI' terminal emulation including the four arrow keys
  • CGA, EGA and VGA displays in 25, 43 or 50 line mode
  • Monochrome (MDA) should work marginally - I don't have the colors/attributes right.
  • Backscroll buffer - you get three screens worth of backscroll. Use PageUp and PageDn to navigate through them.

If you are using a genuine CGA card you will get snow like Minnesota in January. If this bothers you try this:

set MTCP_SNOW=5​

Do that before you run. The value can be from 0 to 10 with 0 giving you the highest quality display, while 10 will still give you a bit of snow. If you see snow at settings below 3 I want to know about it ..

If your clone machine is non-standard and my screen update code is making a mess you can tell my code to use BIOS for screen updates. This will make the display slower but at least you can run. The magic environment variable is:

set MTCP_USEBIOS=1​


Now, the reward for getting this far is the single fastest Telnet client to ever run on an 8088 class machine. If you've ever been bored waiting for another telnet client to finish a directory listing, you are going to love this. It is wicked fast. On a PCjr it is great. On a 386-40 with VGA it is incredible.

Besides your general impression, I'm looking for reports of screen glitches and bad terminal emulation. There are probably a few more ANSI codes that I need to implement. I don't expect that anybody will see screen glitches except for things related to incomplete terminal emulation, but you never know.

I'm also looking for suggestions. Here is the current todo list:

  • Status line?
  • An option to turn wrapping on and off
  • Monochrome support (just need to ignore color and add underlining)
  • Possible xmodem/ymodem client built in for use with sx/rx under Linux
  • Screen snapshots
  • Gag option: terminal simulator featuring 300, 1200, and 2400bps timings


Thanks,
Mike
 
Very fast! Although I'm running it on a p133 (MS-DOS-6.22), directory listings or cat output is instant and very satisfactory. I tried to telnet into one machine and then, from there, into another machine and that works exactly the same. All screens looked good and no glitches of any kind. The scrollback is great - love it! I don't know what I can do to exercise this thing, but so far so good. :) Sorry I don't have an 8088 set up.

Comments on the todo list and other suggestions:

- Yes, mono is essential.
- Wrap, on/off? It might be handy, but I'd have to see it.
- Screen capture would be VERY cool. In that case wrap control would be handy.
- Status line? My feeling is that I'm happy with the prompt from the server and a status line wouldn't really give me much help.
- File transfer would be fantastic, but I'm not familiar with sx/rx under Linux. Can I use it on my lan, or would it only work on a serial connection?
- I don't have a very strong gag reflex, so any gag options would be wasted on me. :p
 
I'd test it on my Amstrad PPC 640 If I had a way to network it. This post reminds me of when my Mac SE connected to the BBS your PCjr was running. I need to learn some Mac programing so I can do some cool stuff on it.
 
Ole Juul,

I think a P133 is overkill - I might have to try that for grins. On an 8088 things obviously are not as instant, but I think it is still very good. Your P133 is 27 times faster just based on clock rate, and the effective speed is probably far faster because of a better CPU pipeline and the cache on the memory.

I'm glad that you like the backscroll buffer - I think is killer, especially given the speed at which things can fly past.

Onto the todo list:

  • Monochrome support is essential, and it will be next on the list. I have a table that maps ANSI colors to CGA equivalents, and I just need to do the same thing for monochrome. That table is much more sparse. ;-0
  • Wrap on/off is important if you telnet to something like an HTTP port. It might also be an issue for a regular telnet session, although my Linux box is happy as things are. Right now it does not wrap when it hits the end of the line. It used to wrap, but that messed up the output from 'Top'.
  • Screen capture - in what format? ASCII text (no color), a straight binary image of the video buffer memory, or ASCII + ANSI escape codes?
  • Status line - Right now I value the screen real estate. I don't know if I want to lose a line for a status line. However, having a line to show the current settings of toggled options would be helpful. As I add features that can be turned on and off this will become more important.
  • File transfer: It works right through your telnet connection over your LAN! Do --help on sx or rx sometime on a Linux box. (These programs or similar ones exist for other Unix machines too.) This would not be as efficient as FTP, but for small files it would be fine.
  • The 'gag' options .. I think the 300 bps simulation mode would be pretty funny. And no, I would not punish anybody with it. :)

I need some other machines to test against. I have Linux and AIX available ...
 
Starshadow said:
I'd test it on my Amstrad PPC 640 If I had a way to network it. This post reminds me of when my Mac SE connected to the BBS your PCjr was running. I need to learn some Mac programing so I can do some cool stuff on it.
Click to expand...

If you have a parallel port on the machine (and I believe you do) check out the Xircom PE3-10BT - it hangs off of the parallel port and gives you a connection to a normal Ethernet network. There have been plenty of threads about it.

My PCjr is far from 'compatible', but it works fine on that. I figure if a PCjr can do it, almost any machine can do it.


Mike
 
Well, the P133 just happens to be a daily user. I still like small programs, and I like the option of using them from floppy on older kit too. :)

Screen realestate is important, and it's generally better to not use superfluous status lines. Like you say though, with more toggle options it may be good to know where you stand.

Actually screen capture is not that important to me. I just think that a lot people could use it. On all DOS installations, I run a cut/paste tsr which only takes 4K of ram. (SNIPPER.COM) From the keyboard (no mouse) you block anything and write it to a file or to stdout as you wish. There are, of course, many such programs, but for some reason not everyone uses them. I can't imagine why. To me the ability for the telnet program to dump the whole scrollback buffer to a file would perhaps be an interesting alternative to the (perhaps) 6 or 7 keystrokes to block and save. ASCII text (no colour) is my preference, but if the other options can be available with little code then fine.
 
I added Back-Tab, Home, and Insert key support last night. Those where easy.

I also found an obscure ANSI escape sequence that I had not implemented, so that is in there now too.

The latest challenge is Unicode. Even if I set environment variables to use only standard ASCII or UTF-8, I'm still having things sent to my telnet client that require a Unicode decoder. I would think this is a bug on the Linux/Unix side and it is certainly not standard .. the unicode sequences are coming in as 2 or 3 byte sequences.

Normally this is not a problem - you just get a slightly inaccurate screen and the bug is elsewhere. But last night it caused a buffer overflow in my code, so it crashed. I know how to protect myself against this (and I should have already). I'm just more annoyed now that something is sending me 2 or 3 byte sequences to interpret when it should be just straight ASCII.

Ah, the joys of internetworking ...


Mike
 
hey mike - got around to putting your telnet client on one of my 8088s. for the most part it works very well, but i found a couple possible bugs..

i tested the client by telnetting into my web/ftp/fileserver machine which runs debian 5.0 "lenny"... when i was at the login prompt, i accidentally began typing in the wrong username, so i tried to backspace it out from it doesn't accept backspace properly. it shows as "^H" .. after i actually logged in backspaces worked perfectly.

the other thing is that when i tried to use aptitude over the telnet, much of the screen was not displayed correctly. i'll run it again and take a pic for you tomorrow.

nice work though! :yell:
 
The backspace issue goes back to almost the beginning of time. Your PC sends an ASCII 8 when you hit backspace. If the other side is echoing that back as ^H then use 'Ctrl-Backspace' instead, which should generate a DEL character instead. Until you login and set the term type DEL will probably work better.

What is aptitude and how do I recreate the problem?

There are some problems I'm not going to attempt to solve. Here they are:


  • Language issues. By default Linux sets "LANG=en-US.UTF-8". I find that for basic applications this is fine, but for things like man pages and Lynx I get special chars and attempts to form special chars that mess things up. I set LANG=en and that puts things back to the way they were in 1985.
  • Lynx - I've found that Lynx doesn't care what my LANG variable is set at. I have to got to the Lynx options and set the codepage to 437 (or whatever the PC codepage is.

Even with these changes some apps are just slightly hosed. Lynx for example, depending on the page. The options page just doesn't work perfectly with TERM=ANSI, and I've used other terminal emulators to reproduce the bad behavior.

To make a long story short - try those ENV vars first. If it doesn't work then it still might not be my code. But I expect man pages, VI, color listings, and the standard stuff to work well.

Another thing to try - experiment with the TERM variable. Right now I'm reporting back 'ansi'. One of the 'pcansi' variants might work better, and I'm adding a feature to make the TERM type that gets reported through the telnet options so that it can be customized. ANSI emulation is far more complex than what is in ANSI.SYS. I've taken every code that Linux uses for 'ANSI' and implemented it, with few exceptions. Saying the terminal is 'ANSI' might be too ambitious, and dumbing it down to the other variants might work better.
 
Last edited:
Linux will probably set it to sv-SE.UTF-8 for me, which is even worse as it will display translated messages containing non-ASCII characters encoded as UTF-8. The old way would be to use ISO-8859-1 (Latin-1) and raw 8-bit transfers.

Aptitude is a front-end to install software packages (APT) found in Debian and others. It probably does more cursor movements and other escape sequences than Lynx will ever do. I suppose if you start any full screen editor within Linux, you will soon notice if the text gets garbled up. Any day now I will download your telnet program and try a session of Emacs somewhere.
 
Carlsson,

It should not be too helpless. I turned on 8 bit support for telnet, so Linux/Unix can send the special characters. The obvious restriction is that you are limited to the 256 characters in the PC ROM.

My understanding of Unicode implementation is weak, but UTF-8 maps to plain old US ASCII, right? (I'm really interested in at least understanding what is going wrong, so I'm going to have to dive into code pages and Unicode.)

Some full screen apps work better than others. Most of Lynx works .. VI works perfectly.

Before you download, give me a few hours - I'm going to post a newer version with some bug fixes and extra keys supported.
 
Carlsson (and all else who dare!),

Here is the latest code: http://www.brutman.com/mTCP/telnet_2009-11-27.zip

Here is the current state of things:

  • Turn off unicode with your LANG environment variable because this code doesn't have Unicode support.
  • If your apps have an option, set the codepage to 437 - that matches the chars in BIOS ROM. (Lynx is an example of an application that works better like this.)

The zip file includes a readme that has the finer points of how to use it. It's not terribly complicated.

This version should work pretty well if you have Unicode turned off and the codepage set correctly.


Thanks!
Mike
 
Regarding UTF-8, the first 128 characters including control codes should be a 1:1 match of US ASCII and always be sent as single characters. The following characters (extended Latin-1 and all other forms of writing) are escaped with a binary code 11111xxx or something like that, followed by a binary number. I have once programmed a partial UTF-8 decoder, but it was many years ago. In the case of an IBM PC in DOS, you would need to transliterate all extended characters to the nearest similar character which quite soon becomes an impossible task.

Then again I don't know how e.g. Chinese or Arabic MS-DOS, Unix and other command line interfaces look like, if they operate in ASCII transliterated mode or display text in native mode. Not that it should have any effect on your application.
 
The new one seems to work the same for me. I tried both and connected to 3 different Linux machines and the good and the bad was the same in all cases.

Normal commands work fine and I can run lynx (or rather the more contemporary elinks) without any problem. What didn't work was aptitude, but I would never use it anyway because of the very excellent apt-get which doesn't require any support other than the commands.

More important to me is that I could not get alsamixer to work. The screen only shows a couple of lines at the top. It is probably noteworthy that for alsamixer, lxtelnet shows the screen but it is blinking. MiniTelnet won't do it at all and says "unknown terminal emulation" regardless of the emulation chosen. I was really hoping to set up a DOS machine using telnet to control my sound server. Hopefully, I (or Mike, depending on where the problem lies) can sort this out. :)

Another anomaly is that MikeTelenet takes a few seconds to bring up the login prompt on two machine, but not the third. Kubuntu 8.04 is slow, Kubuntu 9.04 is slow, Ubuntu Server 8.04 is fast. The other two telnet programs don't do that. This could be a local configuration problem, but I just thought I'd mention it.
 
I just tried Nagy Daniel's SSH2DOS V2.0 and it shows the alsamixer screen just fine. I notice that the docs say that the default terminal type is xterm.
 
Ole Juul,

I tried Alsamixer on my Fedora 10 machine here. You need to hit Alt-W to turn on screen wrapping at the right margin. By default it is off.

I chose off as a default because Top depends on that behavior. I've got something slightly wrong in how I wrap the screen, which is why it one setting doesn't work for both, and now I need to go understand what the exact rules are.

Alsamixer is going to have other problems - it is using function keys. A generic ANSI terminal doesn't have function keys. I might have to upgrade a little bit to emulate XTERM or PUTTY. (Putty used to emulate XTERM too until they made their own terminal definition.)
 
And I think I just found the answer to my question ..

Some of the terminal types have an 'xenl' attribute which is described as 'newline ignored after 80 cols'. Top is sending a full 80 characters followed by a newline, which is causing the double spacing that I am seeing when I run it with wrap turned on. Alsamixer is depending on wrapping being turned on.

Putty and xterm have the xenl attribute set in their terminfo/termcap definitions. None of the ANSI variants do. Hence the problem ..

The solution is to deal with the autowrap kludge or go to another form of emulation. Xterm is probably the safest because it has been around the longest, but it is also the more complicated emulations to do because it does so much.

How well does SSH2DOS run on 8088 or 80286 hardware?
 
Alt-W does the trick on alsamixer! Very nice.

One thing though, For many years I've been using Alt-W for something else and it will take a while to reprogram my nervous system. Is there any way of changing it in MTelnet? Could using function keys be a good interface? It's the old TSR juggeling routine. :) I do have the possibility of changing the Alt-W in my present TSR with debug, but I'd like to avoid that.

- Ole
 
Hmm. Wrap starts with a W. It's going to be the first keystroke most people are going to go for. You are going to have to start separating your debuggers from your telnet clients or you are going to run out of keys on your keyboard quickly ... ;-0
 
Mike, a practical suggestion: Do you have a FTP server or somewhere you can place your files? Maybe the VC Forum has a FTP area, I can't remember. The reason for asking is that currently your TCP/IP package doesn't contain a web browser which makes it a bit hard to upgrade from within the PC running the software.
 
You must log in or register to reply here.
Back
Top