From Wikipedia: "Sneakernet" is an informal term describing the transfer of electronic information, especially computer files, by physically moving removable media such as magnetic tape, floppy disks, compact discs, USB flash drives (thumb drives, USB stick), or external hard drives from one computer to another. This is usually in lieu of transferring the information over a computer network. The name is a tongue-in-cheek sound-alike to Ethernet, and refers to the use of someone wearing sneakers as the transport mechanism for the data.
DOS has been an obsolete operating system for close to twenty years but it still shows up in a few places:
Back when DOS was a current operating system many machines were not network connected at all. Back then people did not have home networks and networking equipment was much more expensive. If people had any sort of connectivity it might have been to use a bulletin board system (BBS) through a dial-up modem or to talk to a Novell Netware server running on their local network. "Sneakernet", or the art of carrying software around on floppy disks, was the standard method of moving data around.
Networking started to become more popular as businesses obtained multiple computers and they needed a way to communicate. This drove the cost of networking adapters and equipment down, which made it more affordable for home users. The growth of DSL and cable modem devices in the early 2000s made home networks almost a requirement, if only to allow sharing the one connection point to the Internet.
The good news is that networking adapters and equipment is as inexpensive as it will ever get, and most machines running DOS can easily make use of used equipment that people are just throwing away. And although DOS came a little bit before the era of widespread networking on home computers, there was enough overlap such that reasonably good networking software exists for DOS.
On a modern operating system networking is a standard function and great effort has been made to make it easy to setup. Networking for DOS is always an add-on feature so it takes a little bit of work to set up, but nothing too difficult.
Even the slowest DOS machines dating back to the early 1980s can do the following once networked:
Almost every old machine can use floppy disks or the serial port for data transfer and for a machine that is rarely used that is all you need. But if you enable networking you get the following advantages:
Using a home network cuts down on your time "doing the floppy shuffle" and saves wear and tear on your system. It also saves you time.
There are lots of ways to connect computers together. This page primarily discusses TCP/IP and packet drivers (to be introduced later). Before getting into the details of those I'd like to present a brief survey of ways to network PCs running DOS.
Serial ports are relatively easy devices to program and lots of people wrote software that uses the serial port. As a result, there was a great variety of programs that used different rules for sending data. Examples include:
Parallel ports were not used for communications as much as serial ports were. Often there was just one parallel port compared with two serial ports on a computer, and the parallel port was often connected to a printer. Serial ports supported "hot plugging" (removing and connecting devices while running) while parallel ports did not, so swapping devices on a parallel port often required shutting the computer and the devices off.
A notable exception was LapLink by Traveling Software. LapLink provided software and a special cable that allowed two computers to directly connect to each other through their parallel ports. The software allowed the computers to move files back and forth. Later versions of DOS provided a similar function with INTERLNK and INTERSRV.
TCP/IP over the parallel port was also possible using a protocol called Parallel Line Internet Protocol (PLIP).
Transfers on the parallel port were inherently faster than those over serial ports because of the nature of the parallel port. Parallel ports also evolved to operate at faster and faster speeds using improved handshaking on the wires and even DMA. Those enhancements were made to improve the speeds of connected devices, but they would help data transfer of any type.
Protocol suites are interesting but most people do not interact with them; they use applications that hide the details of the protocol suite and underlying data transfer medium.
TCP/IP is the protocol suite that the Internet is built on and the term "Internet" refers to a global system of interconnected computer networks that use TCP/IP. In addition to powering the Internet, TCP/IP is used on countless private networks. Simply put, TCP/IP allows computers to send and receive data across these networks. The path the data takes might be confined to one room in your house or might span several continents and satellites; TCP/IP is robust enough to handle it all.
TCP/IP is composed of layers of protocols:
In addition to IP, UDP and TCP there are additional protocols that help. Examples include ICMP, ARP, and DNS. Most of these other protocols work silently in the background so you do not need to worry about them.
TCP/IP is a fairly comprehensive protocol and it can be ver complicated. A full implementation requires more memory than is usually available on an old PC. With some sensible performance and feature trade-offs it is possible to get a reasonably complete TCP/IP implementation running on an old PC with decent performance. Smaller machines can run TCP/IP, but they often wind up making trade-offs that hurt performance or limit features.
While most people associate TCP/IP with high performance networking, it can be used on very low performance networking technologies. For example:
I would stick to classic Ethernet over these two alternatives - they tend to drop a lot of packets.
As noted earlier, DOS generally predates the widespread use of TCP/IP. That means that TCP/IP is going to be a feature of your programs and not integrated into the operating system at all.
On a DOS PC there are generally two ways to used TCP/IP in applications:
The first approach generally works well because the TCP/IP code and application are combined together in one program, reducing complexity and improving performance. But it also makes every application that needs the TCP/IP code bigger in size because the application has to include its own copy of TCP/IP. A change to TCP/IP also requires all of the affected programs to be updated. On the other hand, the TCP/IP code is included can be tailored and customized to the specific application.
The second approach allows multiple applications to share the TCP/IP code, allowing them to be smaller on disk. If the TCP/IP code needs to be changed the programs do not need to change too - you can just swap out the TCP/IP part. This makes the TCP/IP code more of an operating system extension or a dynamically shared library that other programs can use. But performance is not as good as with the first approach and the "one size fits all" philosophy leads to some design compromises that may not be good for the individual programs.
The approach that you choose will probably be driven by the applications that you want to use. A pragmatic approach says to find the application that you like and use that, letting it worry about about how it gets access to TCP/IP services.
If you are not comfortable installing new hardware in your machine, editing CONFIG.SYS, or trying to debug hardware that has not been supported in years, then TCP/IP in DOS is not for you. At a minimum you are going to have to:
On the other hand, the rewards are well worth it. Blasting files around the house at speeds ranging from 25KB per second (on a slow machine with a parallel-port Ethernet adapter) to 600KB per second (on a high end 386 with a 16 bit NE2000 compatible adapter) sure beats the heck out of 'sneakernet.' And once it is setup there is little to no maintenance required to keep it setup.
At the beginning of the networking era for DOS PCs there were very few network adapters to choose from and network applications were highly specialized. As a result, networking applications generally included code to talk to a few specific models of network adapters directly. This was a simple approach that worked back when there were few network adapters, but you can see a few problems with it.
This was not a sustainable way to do software development.
In 1986 FTP Software Inc. created the PC/TCP Packet Driver specification which defined an API for sending and receiving packets over networking devices. A device manufacturer needed to provide a packet driver, which was a small TSR that provided the API in the form of software interrupts. Application software would use the API to send and receive packets. Decoupling the network hardware programming from the applications made the applications smaller and less complex while allowing them to handle new adapters with no changes, provided that the new adapters provided a packet driver. The packet driver for an adapter is effectively the device driver for the adapter.
Another way to look at it is that your networking software never really talks directly to the networking hardware. It talks to the packet driver for that hardware, and as far as the networking software is concerned all packet drivers all look and behave the same way. The complexity of the hardware is hidden by the packet driver. An 8-bit Western Digital WD8003 Ethernet card from 1989 is very different from a NE2000 clone in a 486 PC, yet the packet drivers for each card make them look the same to the rest of the system.
Inside the packet driver is code to talk to a specific piece of hardware. That hardware might be a network adapter, an Ethernet chipset connected through the parallel port, or even just a plain serial port. Your TCP/IP code really does not care because the packet driver provides a consistent way to send packets and receive packets from the chosen network hardware. A packet driver makes the hardware and network accessible in an easy manner.
The PC/TCP packet driver specification can be found at http://www.crynwr.com/packet_driver.html .
The Network Driver Interface Specification (NDIS) is a similar API used primarily with Microsoft Windows. Open Data-Link Interface (ODI) is another similar API that was used primarily by Novell NetWare and Apple Macintosh environments. If your adapter does not provide a packet driver you might be able to use DIS_PKT which provides NDIS to packet driver translation or ODIPKT which provides ODI to packet driver translation.
Packet drivers are usually specific to a particular model of Ethernet device. Here are some places to look for a packet driver for a specific Ethernet device.
The packet driver is a DOS TSR (Terminate and Stay Resident) utility. When a TSR returns you to the command line it has stopped running, but it leaves itself loaded in memory which allows other programs to call it and use the code. This behavior makes it look like an extension to DOS; once it is loaded your computer knows how to do something new. (In this case, talk to a piece of networking hardware.)
When the packet driver loads it is going to look for the Ethernet adapter and try to communicate with it to ensure that the Ethernet adapter is available. To find the Ethernet adapter, the packet driver is going to talk to a set of I/O ports. Usually you have to specify those I/O ports on the command line of the packet driver. If the packet driver can not find the expected Ethernet adapter at the specified I/O ports, it will give up and not load itself.
The packet driver will probably require other command line options too:
As mentioned earlier, all packet drivers talk to higher level software using the packet driver interface/programming API. The packet driver makes itself available to higher level software by taking control of a software interrupt. After the packet driver is installed, other software will use the packet driver by setting parameters and issuing the software interrupt.
For this system to work you need to tell the packet driver what software interrupt it should claim. You also need to tell the other software what software interrupt that the packet driver is listening too. The software interrupt to use is usually specified on the command line when the packet driver is loaded. Here are some examples:
Davicom 9008 Ethernet card (an NE2000 clone) in an AMD 386-40 using software interupt 0x60. The hardware interrupt is 0xA and the hardware I/O port address is 0x300.
Xircom PE3 10BT Parallel-port to Ethernet Adapter running on a PCjr with software interrupt 0x61 and hardware interrupts disabled.
At this point your machine is physically ready to talk on your network. A "software service" for sending and receiving raw Ethernet packets is in place, courtesy of the packet driver.
There are lots of factors that go into choosing networking hardware. Here is my set of criteria:
For 16 bit ISA bus machines you can use nearly anything. I would look for a adapter from a well-known manufacturer with an RJ45 connector and a good packet driver. 3Com, Intel, and NE2000 compatible adapters are safe bets.
For 8 bit ISA bus machines your choices are more limited. The 3Com 3C503 based adapters are good choices. Western Digital/SMC 8003 based adapters and NE1000 adapters are good as well. I have not experienced one but I have read in many places that if you find a 3Com 3C501 based adapter that you should burn it and bury it. Some 16 bit cards might be able to function in an 8 bit slot, but you will have to experiment with that.
For machines without slots or where you want a temporary solution I would use a parallel-port to Ethernet adapter. The Xircom PE3-10BT is a good example of this type of adapter. It connects to the machine using the parallel port and the packet driver makes it look just like a real Ethernet adapter. But the overhead of the parallel port does hurt performance, so while it is a good basic solution it will never beat the performance of an Ethernet adapter on a card.
Of course you might have a machine new enough to have PCI slots or an Ethernet adapter on the motherboard. If you are running DOS on such a high powered machine, I applaud you. :-)
There is a lot of software out there for networking using a packet driver and there are already a lot of resources on the Internet that describe those resources. Here are some notes on the ones that I have tried.
NCSA is a great Telnet program for DOS. Features include:
Stated requirements are DOS 2.0 and a 80286 or better CPU. It will run with a NEC V20 and it might be possible to recompile it to get rid of the 80286 specific instructions.
NCSA Telnet has its own TCP/IP software built in to the application so a separate TCP/IP stack such as Trumpet is not necessary. NCSA Telnet can use a packet driver or it can talk directly to several different Ethernet cards without the need for a packet driver. (They switched to a packet driver interface when the variety of Ethernet cards mushroomed.) The FTP server is very old and it does not support PASSIVE mode connections. I don't think it supports the PORT FTP command either, so you will have to work hard to find an FTP client that will work with it. (It assumes a specific data transfer port number, which is what was standard years ago. The mTCP FTP client is compatible with the FTP server.)
One of the great things about NCSA Telnet is that the source code is readily available for download - with the correct build environment, you can modify it!
The NCSA Telnet home page is gone, but the files can still be downloaded using ftp at ftp://ftp.ncsa.uiuc.edu/Telnet/DOS/ .
Trumpet is a DOS TSR (Terminate and Stay Resident) that adds TCP/IP functions to your system. On one side it talks to a packet driver to move data in and out of your Ethernet card, while on the other side it provides TCP/IP functions to your application. Applications wishing to use Trumpet communicate with it using a software interrupt, in much the same way that Trumpet or other TCP/IP stacks talk to a packet driver.
Trumpet came with some sample applications including an FTP client, IRC client, and a finger client. Other applications were written to use it too. Trumpet published the programming interface to their TCP/IP stack, but the source code is not available. So you can use it, but you will have to live with any bugs and limitations.
Unfortunately the web pages for Trumpet are gone now. Search for tcp201.zip to find an archive of it on the Internet.
WATTCP is a TCP library that is linked with specific applications. There is a 16 bit real mode version for use on the older machines and a 32 bit protected mode version for newer machines. The 32 bit versions compile under a variety of C compilers.
WATTCP is one of the older DOS TCP/IP implementations and one of the most widely used. I do not have a lot of experience with WATTCP (yet) because I got sidetracked with writing my own TCP/IP library. I had a fairly long email conversation with Erick Engelke about WATTCP and the lessons he learned, and it was suprising how much of his work I duplicated. :-)
WATTCP can be found at its new home: http://www.erickengelke.com/wattcp
mTCP is a TCP library and a set of applications that I started working on in late 2006. It is designed for low spec machines like the original IBM PC, PCjr, PC XT, PC AT, PC Convertible, etc. All of the code is 16 bit and most of the programs will run on a 265K system using DOS 2.1 or better. The library includes features like DNS, IP fragments, automatic retransmission of lost packets, listening sockets for server applications, some ICMP support, etc.
The current list of applications includes a DHCP client, Telnet client, IRC client, Simple Network Time Protocol (SNTP) client, FTP client, FTP server, Ping, Netcat, and HTGet (an HTTP file fetcher).
More information on mTCP can be found at http://www.brutman.com/mTCP/mTCP.html .
This page barely scratches the surface of DOS networking. Most of my experience has been with packet drivers and related software; a list of additional resources is provided to help you understand packet driver based solutions and other solutions that I mentioned earlier.
Created August 13th 2007, last updated
December 28th, 2013
(C)opyright Michael B. Brutman, mbbrutman at gmail.com