mTCP Telnet client for DOS logo

mTCP Telnet is a telnet client for DOS that allows you to connect to other systems running telnet servers, telnet BBSes, or online MUDs (multi-user dungeons, the original online virtual worlds.) Telnet includes ANSI terminal emulation so that you should be able to enjoy color and cursor control on the systems you are connecting to.

This version of Telnet is designed for early IBM PCs and similar machines. Great care was taken to make the screen updating as fast as possible, making it usable even on the slowest of systems. Features include:

And here are some screen shots showing different uses. (Click on each one to see the full size image.)

mTCP Telnet client screen shot showing Linux coding

Editing code on a Linux machine with the Help/Status window showing

mTCP Telnet client screen shot showing the forest at lord.nuklear.org

In the forest at lord.nuklear.org

mTCP Telnet client screen shot showing Netris at SDF.org

Playing Netris at SDF.org

mTCP Telnet client screen shot showing Welcome screen for TheKeep.net

Initial welcome screen for TheKeep.net using the 80x50 VGA mode

Requirements

Basically, if you have any old PC running DOS with something that looks like a network connection you should be able to run Telnet.

Setup instructions

Telnet uses the mTCP TCP/IP library for DOS. To use Telnet you need a working network connection and an IP address for your DOS machine. Instructions for getting an IP address can be found in the mTCP setup instructions. Setup is not difficult and once it is done it is good for all of the mTCP applications.

Download

Telnet is included with the other mTCP applications. They can be downloaded from the main mTCP page here.

Aside from the TELNET.EXE program and a packet driver to talk to your Ethernet card, no other downloads are needed. Everything that TELNET needs to connect on the Internet is included in the program.

Usage

Telnet uses the following syntax:

telnet [options] <telnet_server_addr> [port]

where <telnet_server_addr> is the name or numerical IP address of the telnet server you wish to connect to and [port] is an optional port to connect to use. By default the port is set to 23, which is the standard telnet server port.

Options are:

-help      Show basic help text
-debug_ansi      Create telnet.log with some extra debug info
-debug_telnet      Create telnet.log with some extra debug info
-sessiontype <telnet|raw>      Force telnet mode or raw mode

Under normal operation if you connect to port 23 on a server you will be operating in telnet mode. This means that the telnet client will expect to receive telnet options from the server, and will reply and try to negotiate option settings. If you connect to any port besides port 23 you will be operating in raw mode, where the telnet client will not respond to telnet options and it will not try to negotiate option settings.

If you need to connect to a real telnet server on a non-standard port then use the -sessiontype option to force the telnet into telnet mode, even though you are not connecting to the standard telnet port. You probably will never need to specify raw mode but it is there if you need it.

For example:

telnet bbs.retroarchive.org

connects to a machine called 'bbs.retroarchive.org' using the standard telnet port (23). It expects to find a telnet server at that port and it will negotiate telnet options with that server.

telnet example.com 5500

connects to a machine called example.com on port 5500. This is not the standard telnet port so no telnet options negotiation will be done. If that machine really were running a telnet server at that port you could force telnet mode using:

telnet -sessiontype telnet example.com 5500

To make the screen performance tolerable on older machines telnet will take incoming data and render the current screen on a virtual buffer before trying to repaint the real screen. This approach uses a little bit more memory but it dramatically improves the performance of the screen handling, especially when scrolling large amounts of data. You will notice that the screen will pause and stop updating while the machine is getting flooded with incoming data - this is normal and it is keeping you from dying a slow and agonizing death while the display adapter scrolls. A nice side-effect of the virtual buffer approach is that you get backscroll capability for free - if something does scroll past the screen you can hit Page Up and Page Down to browse around.

The following special keys are recognized while telnet is running:

PageUp      Move up through the backscroll buffer
PageDown      Move down through the backscroll buffer
 
Alt-H      Show a combined help and status screen
 
Alt-B      Toggle sending DEL chars when the Backspace key is used on and off
Alt-E      Toggle local echoing on and off
Alt-N      Toggle between sending [Enter] as CR/NUL, CR/LF, CR or LF
Alt-W      Toggle automatic wrapping around the right margin on and off
 
Alt-R      Refresh the screen from our local virtual buffer. (Should not be needed unless I have a screen drawing bug)
 
Alt-D      Download a file using Xmodem or Ymodem Batch
Alt-U      Upload a file using Xmodem or Ymodem Batch
 
Alt-F      Drop to DOS to run some commands (make it quick!)
 
Alt-X      Exit the program (Ctrl-Break does this too)

When you use one of the toggle options a single beep means it was turned off, while a beep followed quickly by a higher pitched beep means it was turned on.

The following special keys are sent to the server to handle:

Telnet protocol features and limitations

This isn't a fully compliant telnet client implementation. It has the following limitations:

It does properly support the following telnet options:

Other options such as passing the environment variables are not supported, but that is not a big deal considering that you are connecting from a DOS machine. (If you have a burning desire for a missing option let me know.)

Uploading and Downloading files

In ye old days one would use a terminal emulation program with a modem to gain access to a BBS or multi-user timesharing system. If you wanted to download a file you used something like Xmodem, Kermit, or Zmodem. Downloading was slow and agonizing, which made the reward for getting a good file that much more precious.

Now people use HTTP and FTP to transfer files over broadband. It just works. It's not interesting. Most people don't even know that FTP or HTTP exists - they are just "getting a file."

In order to give you a taste of what it was like to transfer files back in the old days I have finally added Xmodem and Ymodem to telnet! Many telnet BBSes support uploading and downloading through telnet connections and Unix systems have supported it using the sx/sb and rx/rb commands for years. It is not as fast as FTP but you can do it right from telnet without quitting to run another program. On faster machines the speed difference is not noticable.

Protocols:

Here are your options for uploading and downloading:

To download a file (or files) give the server the command to start sending the file(s) and then press Alt-D. You will need to select the protocol to use - be sure this matches what the other side is going to use. If you have a mismatch the file transfer will probably fail. If you choose one of the Xmodem variants you will have to enter the filename to save the file to and the saved file size will be rounded up to the next 128 byte size. The file timestamp will also be set to the current time, as Xmodem does not preserve the file timestamp. If you download using Ymodem Batch just select the protocol and the transfer will start. The filename is automatically received, the file size will be exact, and the original file timestamp from the server size will be preserved.

(Almost - If you run using DOSBox the file timestamp is not preserved because of a limitation in DOSBox.)

If you try to download a file that already exists on your system you will be prompted to see if you really want to write over the existing file. If the file can not be over written for some reason then the transfer is aborted. This can happen if the filename happens to be the same as a directory on your local machine.

To upload a file give the server the command to start receiving the file and then press Alt-U. Select a protocol to use, and enter the name of the file to send.

When uploading and downloading use the ESC key to abort the file transfer. Xmodem and Ymodem transfers are normally cancelled by sending a special character (Ctrl-X) at least two times. mTCP Telnet will do this for you, but if you need to cancel a file transfer manually just hit Ctrl-X a few times and be patient. (You might need to do this if you started the file transfer on the other side and changed your mind before starting it on the mTCP Telnet side.)

All file operations happen in the current directory. See the section on "Shelling to DOS" for details on how to change directories and manage files.

Limitations on file transfers:

Notes for Linux/Unix:

If you have lrzsz package installed then you have the following commands available:

All of these commands have a bad habit - they write to stderr which in turn appears on stdout. And that can mess up your transfer. To get reliable transfers from these commands pipe the output of stderr to a file or /dev/nul. For example:

sx dosfile.exe 2> stderr.txt

That will send the file dosfile.exe from Linux to the mTCP Telnet client, piping the output on stderr to a file called stderr.txt. (This assumes you are using bash for your shell. If you use a different shell figure out how to pipe stderr using that shell.)

The send commands (sx and sb) might not use 1KB packet sizes or CRC by default. Not using CRC is not an issue over telnet, but not using 1KB packets can slow you down quite a bit. Use the "-k" option to setup for 1KB packets. (And using CRC never hurts either.)

Notes for Synchronet:

Synchronet BBS is great, but it has a bad habit. When using Ymodem batch it will append extra bytes to your file to insert an advertisement for Synchronet. This kind of defeats the purpose of preserving the original file size. While I appreciate the effort that goes into maintaining Synchronet, this is bad behavior.

Shelling to DOS

Sometimes you may need to suspend telnet and execute DOS commands while still connected to a server. You might need to do this manage files that you have just transferred. The Alt-F (File) key in telnet allows you to do this.

When you use this function telnet will be suspended and you will be dropped at a DOS prompt. You can execute commands here; I would limit it to just a few seconds and only using simple commands. For example, if you need to delete a partially downloaded file, change directories, or check a directory for files this function is ideal. Do not do anything that might alter the screen mode; the screen contents will be restored but telnet is not expecting the mode to change.

While you are at the DOS shell telnet is not processing any incoming Ethernet packets. If you receive something from the other system the connection will time out and you will be disconnected! Keeping that in mind, do not use this function if you are expecting input from the other side. When you are sitting at a Unix command prompt it is probably safe; doing it while a directory listing is coming down is definitely not safe.

Use the "exit" command at the DOS prompt to return to telnet.

ANSI Emulation Notes

Full blown ANSI terminal emulation is a complicated mess. All of the different variations of ANSI emulation over the years have not helped anything either. To put it politely, I've done the best I can and you might still see screen rendering problems.

That being said, I've tried to do a reasonable good job of interpreting ANSI escape sequences and rendering them properly. The ANSI emulation does not depend on ANSI.SYS or any other console device driver - it is all internal to the program. I used a few sources to determine the required set of escape sequences, including the Linux TERMCAP entries for a few ANSI-like terminals, including the generic ANSI terminal definition and a few related PC flavors. The emulation is good enough for me to write this documentation using VI, browse in text mode with Lynx, run the 'screen' program to get a few virtual terminals, use the 'info' command to browse the terminfo writeup, and run some of the more complicated 'system-config-*' commands provided with Fedora.

Here are a few notes to improve your experience:

Unicode:

This telnet client doesn't have Unicode support in it, so sending a three byte sequence to it and hoping that you will get a Unicode character will not work. The easiest way to supress the bogus Unicode characters is to set your LANG enviroment variable so that it doesn't trigger Unicode support. For example, on my recent Linux boxes LANG looks like this:

echo $LANG
en_US.UTF-8

Set it to en_US instead like this: export LANG=en_US

Codepages:

The standard codepage built into the monochrome card or the CGA card is codepage 437. No other codepages are possible if you are using these two video cards. Set Lynx to use codepage 437 to avoid getting weird characters.

EGA and VGA users may be able to get other codepages loaded into memory using country.sys and other DOS configuration commands. I have not experimented with this yet, but in theory you should be able to use other codepages with telnet by doing that. (If you try this out please let me know how it works!)

Terminal Types:
By default if the telnet server asks type type of terminal is connecting this code will report back as 'ANSI'. This happens during telnet option negotiation.

If you want to experiment with other terminal types supported by your system then you can change the string that gets reported. See the section entitled 'Advanced Setup' for instructions on how to do this.

If you just want to make a temporary change most Unix systems have a TERM variable in the environment that you can alter.

Depending on your system there may be several suitable terminal types to explore. Older Linux systems have over 20 variants of ANSI terminals to choose from. Newer Linux systems might just have 'ANSI' and 'PCANSI' to choose from. Look in /usr/share/terminfo/ for possible termcap definitions to play with. If you want to make a custom termcap for this program contact me and I'll tell you exactly what I implemented.

Monochrome Adapter Users:

The monochrome adapter does not display color, but it does have the ability to underline characters properly. If you are on a true monochrome display adapter (MDA) then you should set your terminal type to 'pcansi-mono', or something similar that tells the server that you have a terminal with true underlining capability. The standard ANSI setting will work, but will not enable underlining.

Special note: Telnet BBSes and MUDs

Not everything out there claiming to be a telnet server is actually running a compliant telnet server that does telnet option negotiation. A lot of telnet BBBes and multi-user dungeons fall into this category. If you are having trouble trying to connect to something that is not a standard telnet server, try using the "-sessiontype raw" option. You will still get ANSI emulation but all of the telnet protocol negotiation code will be disabled. This is done automatically when you connect to anything other than port 23.

Assuming that works, you might need to turn on local echoing using Alt-E.

[Enter] key handling

The telnet standard spells out that a "newline" character is comprised of a CR (carriage return) followed by a LF (line feed). But it is not clear what it means when a user presses "Enter" at a terminal; that is traditionally just a CR that gets sent to the server. This makes the standard ambiguous.

After two years of struggling with the ambiguity I think I have found something that works for most telnet servers. By default pressing the "Enter" key will send a CR/NUL pair. If you need something different for a non-standard telnet server you can use Alt-N to toggle between the following options: CR/NUL, CR, LF, CR/LF. The help screen will show you the current setting.

Regardless of this setting you can always send a CR by pressing Ctrl-M and send a LF by pressing CTRL-J.

Advanced setup

There are some options that you can specify in the MTCPCFG file to override default behavior, such as the initial state of toggles. Below is the list:

TELNET_VIRTBUFFER_PAGES n      Replace n with a number from 1 to 8
TELNET_CONNECT_TIMEOUT n      N is time in seconds to wait for a connection
TELNET_AUTOWRAP n      Use 0 for autowrap off (default), 1 for on
TELNET_SENDBSASDEL n      Use 1 to send DEL chars when Backspace is hit
TELNET_TERMTYPE termtype      Report 'termtype' as your terminal type during telnet option negotiation
TELNET_SEND_NEWLINE chars      Send [Enter] as chars (see below

By default the number of Virtual Buffer Pages is 4, the connection timeout is 10 seconds, autowrap is turned on and sending DEL chars when the Backspace key is hit is on. The terminal type string is set to 'ANSI'.

The valid values for TELNET_SEND_NEWLINE are "CR/LF", "CR", "LF", "CR/NUL", or "AUTO". The default is AUTO, which uses CR/NUL unless telnet binary mode is enabled. If binary mode is active then just a CR will be sent. (You don't have any direct control over binary mode so don't worry about it.) See the section on [Enter] key handling above for details.)

Examples:

TELNET_SEND_NEWLINE AUTO      Default: use CR/NUL or just CR automatically
TELNET_SEND_NEWLINE CR/LF      send both CR and LF at all times
TELNET_SEND_NEWLINE CR      Send just a CR
TELNET_SEND_NEWLINE LF      Send just an LF
TELNET_SEND_NEWLINE CR/NUL      TELNET_SEND_NEWLINE CR/NUL

Support

Nothing is perfect but we can try ...

The Telnet client is part of the mTCP project which features a TCP/IP library for DOS and several TCP/IP applications that use the library. The applications include a DHCP client, an FTP client, an IRC client, an FTP server, Ping, Netcat, an SNTP client, and an HTTP file fetcher. All of the software is open source and is licensed under the GPL, version 3. More information about mTCP can be found at the mTCP project page.

Have a comment or need help? Please email me at mbbrutman@gmail.com.

Recent changes


Link: mTCP main project page

Created July 31st, 2008, Last updated December 23nd, 2013
(C)opyright Michael B. Brutman, mbbrutman@gmail.com