A nice little
TCP/IP stack for IBM PCs, XTs PCjrs, and newer machines
Current version: February 8, 2010
Introduction
In the early days of personal computing the computer was a solitary
machine that rarely connected to other computers. If you had an
advanced setup you had a modem and you might be able to use your
machine as a 'dumb' terminal to an information service or a larger
shared machine, like a Unix machine at a university. File transfer
between machines was usually done by doing the 'floppy shuffle', where
you carried a floppy disk from one machine to the other machine. File
transfer could also be done from machine to machine using a modem, but
it was slow and error prone. (A 2400 bps modem could transmit 240 bytes
per second, assuming you had a perfect telephone line.)
Today we take it for granted that machines are connected to each other.
The machines connect to each other using TCP/IP over local area
networks, DSL, cable modems, wireless Ethernet, cellular data networks,
and even the occasional modem connection. It is basically assumed that
machines are network connected - it would be hard to use a computer for
any length of time without a connection.
Any machine today has the ability to be networked. But that wasn't
always the case. It wasn't until the mid 1990s when we started getting
operating systems for personal computers where TCP/IP was supported by
the operating system. And earlier hardware from the first generations
of personal computers (8088 and 80286 class) just doesn't have a lot of
memory or CPU power to handle the full TCP/IP network stack. Getting a
machine like an original IBM PC 5150, an IBM AT, a PCjr, or anything of
that vintage onto a TCP/IP network is a challenge. Yet these machines
can benefit from network connectivity, the same way new machines do.
In 2005 after playing with some TCP/IP solutions for old DOS machines I
decided that I didn't like any of them, and I wanted to write my own
TCP/IP for DOS. Some of my requirements were:
- Small size - the applications have to run on a reasonably sized
machine with some room to spare. A good target would be a 256K machine.
- Good performance - the TCP/IP stack should be able to transfer
data quickly. That is its primary reason for existing. Even on the
closest PC it should be usable.
- Up to date features - TCP/IP is basically the same as it was 20
years ago, but some great new features like DHCP exist now. To work in
a modern network the TCP/IP stack should support those features.
- Bug free - No software is probably ever bug free, but it doesn't
mean you shouldn't try. Some of the other TCP/IP solutions I tried
really bothered me because they were so close to being usable, but had
flaws I couldn't correct.
Today, some three years later, I am finally at the point where I can
share the applications with others who are also interested in
networking their old personal computers.
What is it?
mTCP is a TCP/IP stack for old personal computers written using Borland Turbo C++ 3.0 for
DOS and a sprinkling of x86 assembler. It is designed to work with an
Ethernet card and a packet driver. Basic features include:
- ARP support for finding the IP addresses of other machines
on the network
- A simple UDP implementation
- A high performance TCP implementation
On top of this foundation are the applications. The applications are
what make all of this compelling. At the moment there is a DHCP client,
IRC client, FTP client, Telnet client and the Netcat utility.
Some of the more advanced features of mTCP are:
- Configuration: A lot of the features are enabled and
disabled at compile time using #defines so you can tailor the
features and behavior of the TCP/IP
code to each application.
- High performance: Great care was taken to minimize memory
copies, speed up checksum calculations and avoiding needless polling
and
locking of data structures. The end result is code that can move around
50KB per second through a TCP/IP socket on a 4.77Mhz PC XT with an 8
bit ethernet card. On faster DOS machines (386-40) the rate is well
over 500KB per second. (Click here for more detailed performance notes.)
- Small space requirements: There are TCP/IP implementations
which use less space, but not with the same performance. I made my
target a 256KB machine, which gives me plenty of room for buffers and
code. Basic applications such as the IRC client can run in under 160KB
of space. Buffer space and features are configurable to suit your needs.
- Extensive tracing: Nobody likes a bug. I built a very
comprehensive trace mechanism into the code so that in the event of a
bug I can set two environment variables, get a detailed trace, and
figure out what happened. This has come in handy a few times when other
people have had problems. The trace feature can be compiled
out to save space if you think your application is truly perfect. (Ha!)
- Robustness: Test code that I have written has handled
several simultaneous connections for days. The IRC client has been run
against a busy IRC channel for over a week at a time.
- Usability: DHCP configuration makes it easy to use on a modern home network. Static configuration is also available..
I have tried to adhere to the TCP/IP specifications as closely as
possible, but not everything is possible in such a small machine. There
are a few features missing. Some I will be adding as options as time
goes on. IP packet fragmentation and reassembly is a good example - you
can do a lot without having this feature implemented, and it can be
quite a resource hog. For now, we are doing without it.
Structure/Packaging
mTCP is a library that is statically linked with the application code.
Put another way, any application that you write will include a copy of
the mTCP code in it. This is very similar to the way WATTCP and the
TCP/IP code in NCSA Telnet is packaged. The other common way to package
TCP/IP is as a memory resident DOS TSR. Here are the pros and cons:
- Pro: The TCP/IP code can be tailored to match the needs of
the application
- Pro: One less piece of software to install and configure.
- Pro: Better performance due to less call overhead.
- Con: Applications will be larger on disk because they
include the TCP/IP code in them.
- Con: To write an application you need to be able to link
your code against the TCP/IP code. This means you probably need a copy
of Borland Turbo C++ to do any applications yourself.
At the moment when you download mTCP you get a zip file with seven applications:
- A DHCP
client for auto-configuring your machine to use your local area
network Your machine will be able to get an IP address and other
connection information from your cable modem or router, just like the
other machines in your house.
- Netcat (nc):
a simple port of the Unix utility that lets you send and receive bytes across the network. It can be used for
large files or short messages, and can be scripted into BAT files.
- IRCjr: a simple
DOS IRC
client with timestamps, logging, and a large backscroll buffer.
- FTP: a
full-featured FTP client with very good file transfer performance
- Ping: a simple network debugging tool similar to Unix and Windows versions
- Telnet: a DOS telnet client with excellent screen updating performance and ANSI emulation
- DNSTest: A DNS resolver that can convert machine names (ie:
www.brutman.com) to IP addresses. Includes an extensive trace
mode so that you can see what is going on under the covers.
All of these applications will run well on the oldest, slowest PC you
can find. I routinely use them on a 1983 IBM PCjr because nothing beats
the fun of putting a 25+ year old machine on the Internet.
I am constantly working on more features, applications and
performance improvements. I am not distributing source code yet because this is a work in progress.
Requirements
The applications should work on any DOS PC with an Ethernet adapter and
a packet driver. My personal testing includes:
- Generic AMD 386-40 with an NE2000 Ethernet adapter, DOS 5, and a VGA display
- IBM PC XT at 4.77Mhz with a 3Com 3C503 Ethernet adapter, DOS 3.3, and a CGA display
- IBM PC XT at 4.77Mhz with a Xircom PE3-10BT parallel-port to Ethernet adapter, DOS 5, and an MDA display
- IBM PCjr at 4.77Mhz with a NEC V20 CPU, Xircom PE3-10BT
parallel-port to Ethernet adapter and DOS 5
As long as you have an Ethernet adapter (card or parallel port device)
with a packet driver, it should work.
Token Ring, SLIP, CSLIP and other network types are not
supported at the moment, but could be if there was a reason.
There is experimental support for SLIP and CSLIP using a packet
driver that emulated Ethernet (eg: SLIPPR and CSLIPPR).
Downloads
Get the current set of mTCP applications for DOS here! mTCP_2010-02-08.zip
The zip file includes all of the current applications and TXT files explaining how to set them up and use them.
Interested in seeing the source code that lets you talk directly to a
packet driver? I've taken the lowest layer of my code and packaged it
with a sample application that shows you how to interface a C program
with the software interrupt mechanism used by packet drivers. Check it
out here: mTCP_tcpacket.html
I am interested in hearing about your experiences with the mTCP applications and any
comments you have. Please email me at mbbrutman@yahoo.com. You can also
start a thread on http://www.brutman.com/forums
(Mike's PCjr Page) in the 'Programming' area.
Recent News
I received very good feedback from Ulrich Hansen, a FreeDOS user -
mTCP works well under FreeDOS. FreeDOS was on my todo list, so this was
very helpful. The FreeDOS project can be found at http://www.freedos.org/ and the networking FreeDOS Wiki pages can be found at http://sourceforge.net/apps/mediawiki/freedos/index.php?title=Networking_FreeDOS .
Recent changes
- Jan 2009: 43 and 50 line support for IRCjr, new FTP client
- April 2009: FTP client enhancements: mget, mput, rename, lcd and other commands
- September 2009: Some ICMP support for IP; small bug fixes to FTP
- November 2009: A beta copy of Telnet was added
- December 2009: Bug fixes and new features for Telnet
- February 2010: Complete rewrite of Netcat
Created July 29th, 2008, Last updated February 8th, 2010
(C)opyright Michael B. Brutman, mbbrutman@yahoo.com