2. DOS networking today
3. Practical Guide: Adding TCP/IP to DOS
This document describes how to network a computer using DOS. System used for testing is FreeDOS. Most things are supposed to work with other versions of DOS as well. How to add TCP/IP capabilities to a DOS machine is a detailed guide through the installation and configuration of drivers and other required software.
Tried the following network interface cards (NIC), all PCMCIA:
SP1045.EXE. It also can be downloaded from driverguide as "SystemSoft Version 3.1,
Network is 100Base-T Ethernet LAN connected to the internet through a DSL router. FreeDOS version is 1.0.
Parts of document inspired by Michael Bernardi's "DOS Networking HOWTO". Links there and FAQs and applications were of great value. Screenshot of "LAN Manager 2.1" in chapter LAN Manager was taken by Michal Necasek for his "History of OS/2" with permission to use this screenshot. Photo of software package "Workgroup Add-On for MS-DOS" in the same chapter by Dirk Makowski for his "Winhistory", a huge collection of items and screenshots of historic software.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
In 1985 Novell, a former hardware manufacture of CP/M systems, released its product "NetWare 86" (v 1.5) for the PC. A version for the AT followed with "NetWare 286" (v 2.0) in 1986. Novell networked computers according to the client/server model: Clients running MS DOS and some memory resident (TSR) Novell software were able to "log in" to a server that ran "Novell NetWare Server". Once connected they could "map" a volume on the server to a driveletter in DOS and then use it like a local drive. NetWare also enabled the clients to use printers connected to the server. Client and server communicated over Novell's "Internet Packet Exchange / Sequenced Packet Exchange" (IPX/SPX) protocol. The driver architecture was called "Open Datalink Interface" (ODI). NetWare established a dominant position in the market until the middle of the nineties.
With the "Server Message Block" (SMB) protocol merged into LAN Manager since 1991, Microsoft networks became able to do peer-to-peer networking as well. This was used by Windows for Workgroups 3.11, released in 1993. The mechanism is known to Windows users as "Windows share", "network neighbourhood" or "Workgroup".
In October 1993 Microsoft released a tool called "Microsoft Workgroup
Add-On for DOS" which allowed to have the same peer-to-peer networking
possibilities in DOS. While the tool itself is not sold any longer, most of
its functionally is still available by usage of "MS Client" and a special
update called "
WG1049" (see MS Client
Many packet drivers were written or managed by Russ Nelson at Clarkson University, who became known as the "Packet Driver King" - a story, he describes at his website. Nelson still distributes these drivers as free software through the site of his company "Crynwr" (which was named after the welsh word for "Quaker", his religious belief).
One cause for the success of FTP Software's PC/TCP was this open packet
driver interface, which made it easy to develop drivers and applications.
When other driver interfaces like ODI and NDIS appeared on the scene, PC/TCP
included converters: With a tool called
ODIPKT.COM ODI drivers
became usable as packet drivers, a tool called
the same for NDIS drivers.
PC/TCP also came with an external TCP/IP kernel called
ETHDRV.EXE that allowed other programmers to call network
functions within their applications without programming them themselves. All
these features and an application suite that allowed DOS computers to access
or provide TCP/IP services such as news, e-mail, ftp, telnet or network
storage (PC/TCP even included a NFS client called InterDrive) made FTP
Software Inc. market leader for DOS TCP/IP software.
PC-IP and its successor PC/TCP may have been the first or most successful TCP/IP kernels for DOS but they were not the only ones.
In 2002 KA9Q became free software (GNU GPL). Its descendants, JNOS and EZ-NOS (see also here and here) are still actively maintained.
Minuet is a good example for the unfortunate design of DOS software licenses in this era. In difference to the GNU General Public License (GPL) that became a standard in the GNU/Linux world, licenses for DOS software written at Universities and by hobbyists were mostly homebrewed. The Minuet license f. i. allowed free usage for the University of Minnesota faculty, staff and students. All others were expected to pay 50$ after 15 days evaluation. Distribution was allowed for non-commercial reasons only.
ODIPKT.COMwritten by Dan Lanciani (Harvard University) allows to use ODI drivers as packet drivers,
DIS_PKT9.DOSby Prof. Joe R. Doupnik (Utah State University) and Dan Lanciani does the same with NDIS drivers.
A few projects are still alive: The graphical DOS browser Arachne is actively developed again by a group of programmers after it was released under the GNU GPL. Also ssh2dos, Watt-32 and the KA9Q successors EZ-NOS2 and JNOS2 are still maintained and developed. Even new DOS TCP/IP software has been written recently, although there seems to be some reluctance to release the source and give these creations a future as free software projects.
All are multiprotocol network drivers, meaning they are able to support multiple protocols over the same card. Earlier drivers did support only a single protocol. Multiprotocol drivers communicate directly with the network interface card and provide a published interface specification, to which applications can be written. Good general introduction "Implementing Multi-Protocol Network Drivers in a DOS Environment" by the University of Georgia, Athens, Georgia (U.S.).
TCP/IP has become the default protocol for Local Area Networks (LAN).
NetBEUI was the default protocol for LANs in Microsoft systems until Windows 2000. Replaced by NetBIOS over TCP/IP (NBT) and then by TCP/IP. The application level network protocol SMB for instance can run directly atop of TCP since Windows XP.
Novell's IPX was used in NetWare, which was the default networking solution for personal computers running DOS or Windows 3.x. Since 1998 NetWare is able to run on TCP/IP, more recent versions use it per default.
While the above categories should cover most programs, there are a few
exceptions. One of them is "Invisible LAN", a
NetWare-like DOS application that even comes with an own protocol called
Another special type of applications are network bootdisks, which are able
to work with a broad range of hardware and use multiple protocols. Bootdisks
are mostly used for backup, restore and repair. They can be extremely
Examples are: Bart's Network Boot Disk | Drivesnapshot | Netbootdisk
TCP16.EXE" (1996) can still be used to run TCP/IP applications directly over ODI (see chapter "Other TCP/IP Kernel").
On the sites above Novell includes a warning that this software is neither maintained nor supported any longer. Useful information about Novell's DOS clients can still be found at the newsgroup "novell.support.os.client.dos-win3x" which was active until 2004. More recent information and useful links about using NetWare with DOS can be found at "DOS Solutions".
Popularity of the thirteen year old MS Client 3.0 may be caused by
the possibility (but not officially supported) to use an update
to add server functionality to the client. This adds features
comparable to those of the "Workgroup Add-On for DOS", no longer
sold by Microsoft.
This "hack" seems to give people hope to be able to integrate their DOS machine into a modern Windows XP or GNU/Linux SMB Workgroup. There may be limits, though.
Steven Baker critically remarks, that, while the core TCP/IP protocol remained stable over the years, Microsoft's SMB protocols changed from upgrade to upgrade and exist "in a dozen different dialects". So compatibility is an issue. Other problems can be caused by the authentication methods that are used with Windows or Samba. Some files from the "MS Client" package are essential for use of TCP/IP applications over today's common NDIS drivers.
Michael Bernardi has collected a list of more than hundred TCP/IP applications available for DOS. There also other lists here, here and here, which may contain additional information. A recent and constantly updated resource for DOS networking applications is the British "DOS Solutions". Links to other DOS resources are collected in FreeDOS technote 157. I also found the nostalgia site oldskool.org pretty helpful. Information can still retrieved from usenet newsgroup comp.protocols.tcp-ip.ibmpc, especially from their FAQ, which is posted in parts one, two and three.
"Arachne" is a graphical web browser for DOS. It was created in 1996 by Czech programmer Michael Polak and his company xChaos / Arachne Labs. In 2002 Michael Polak decided to make Arachne free software. The new license is the GNU GPL. It supports various picture formats. Tables and frames are shown correctly, it renders HTML 4 and CSS 1.0 and the latest version (1.90J3) even understands UTF-8. Other Arachne services include FTP, NNTP, IRC-Chat, RSS, POP3 and SMTP. Look here for a complete history of the software. Arachne is still actively developed - programmers are invited to join a mailing list. The latest version can be found at the site of Glenn McCorkle. Read more about it at Wikipedia.
"EZ-NOS 2" is one of the descendants of Phil Karn's KA9Q. It is currently developed by DOS Solutions. The software suite includes a webserver, a FTP-server and a bootp server as well as an email client. As all KA9Q descendants EZ-NOS 2 is licensed with the GNU GPL. The source can be downloaded as ez_src.zip.
"SSH2DOS" is a SSH, SFTP and SCP client for DOS. These services more and more replace the classic telnet- and FTP-services, which are regarded as less secure. (The screenshot shows a closed SSH session to my Debian server.) SSH2DOS was created by Hungarian developer Nagy Daniel in 2000 and can be downloaded at Sourceforge.net. It is released under the GNU GPL. It uses code of the PuTTY SSH client as well as the WatTCP kernel library.
As already mentioned, packet drivers are multiprotocol drivers so TCP/IP
isn't the only kernel that can work atop of it. As you can see in the figure
above, it is also possible to run Novell NetWare over of a packet driver:
Specialized drivers like
support IPX over the packet driver interface. The NetBEUI protocol can't be
used on top of a packet driver though, as the packet driver interface is too
different from NDIS.
The first place to look for a packet driver should be the installation
medium that came with your card. Packet drivers often have the letters
PD" in their names, so the packet driver of a 3com 3C589
PC-Card is called "
3C589PD.COM" and the driver of the D-Link
DFE-670TXD PC-Card is called "
DFE670PD.COM". Look for a
PKTDRV" on the CD or floppy that came with your
For ISA and PCI network cards a packet driver may be found at Russell Nelson's Crynwr project - a resource of public domain packet drivers. PCMCIA drivers seem to be rare there, though.
Georg Potthast provides a collection of PCI
card packet drivers and a tool called
to determine the chipset of PCI network cards. He found that
packet drivers are often the same for many models by the same
manufacturer; recommends finding a packet driver by chipset.
AUTOEXEC.BAT(example for 3c589 PCMCIA card):
LH 3C589PD.COM 0x60 5 0x300In the example above the driver is loaded into high memory by using the command "
LH". The first option ("
0x60") sets the software interrupt (vector) used by the driver. The most frequently used packet driver software interrupt number is 0x60. The second option ("
5") sets the IRQ, the third option ("
0x300") sets the I/O port. Some drivers only need the vector and find the other values by themselves. Most packet drivers can be unloaded after use with the option "
That's all. After successfully installing a packet driver, you can skip the next two steps (ODI / NDIS drivers) and proceed with the TCP/IP kernel.
ODI" or "
VLM" on the installation floppy or CD-ROM. The drivers are executables, their names look like "
3C574.COM" or "
In the language of the ODI specification these drivers of the network card are called "Multiple Link Interface Driver" (MLID). The MLID communicates directly with the hardware of the network interface card. The MLID receives packets for different protocol stacks (kernels) in the system and passes these packets to a second piece of software, the "Link Support Layer" (LSL). The LSL then determines which protocol stack is to receive the packet. Both, MLID and LSL form the ODI architecture.
Need an additional file to get ODI working: The LSL, which is a file
LSL.COM". This file is part of the "DOS NetWare Client",
which can be downloaded
at Novell. Novell's download site
explicitly remarks "LICENSE: FREE" for it. After download and extraction, the
LSL.COM" can be found in the folder
To use ODI with packet driver based TCP/IP applications, need to download
another software, a "Packet Driver to ODI
Converter". Converters are also called "wrappers" or a "shim". We have
ODIPKT.COMv3.1 by Dan Lanciani (danlan.com) at Harvard University. The software is public domain; its license allows free redistribution of binary and source and the modification of the source (assembler).
PKT2ODI.EXEby Caldera. File is part of DR "WebSpyder", a graphical DOS browser that Caldera released in 1998. WebSpyder was licensed from xChaos/Arachne. Downloaded here. It's license allows it to be evaluated and freely redistributed for non-commercial purposes.
IPXPKT.COMto run a packetdriver over
IPXPKT.COMis free software by Crynwr and is a part of their packet driver collection
PKTD11.ZIP. This is a special case and will not be further investigated in this document.
With the MLID, the LSL and the converter we have most of the files needed.
The only one missing is the configuration file "
example file with settings supposed for your card may be found on the CD or
floppy that came with it and should be located in the same directory as the
NET.CFG. If it doesn't exist, create it. Choose a directory - default locations of
NET.CFGseem to be
C:\NET. The location should be in same directory, where
LSL.COMand driver is found. An example
NET.CFGwhich came with the 3Com 3C574 PC Card shows a lot of configuration settings, that are needed for Novell NetWare and other software. For using packet driver based TCP/IP applications the following four lines in
--- NET.CFG --- Link Support buffers 8 1600 Link Driver 3C574 Frame Ethernet_II
Link Support" configures the LSL. Options are: "
max boards", "
max stacks" and "
mempool". We only need to set: buffers 8 1600
Determines number and size of receive buffers of the LSL. Default communication number for TCP/IP is 8. Author of ODIPKT, Dan Lanciani recommends to use a buffer size of 1600 bytes for ODIPKT.
Link Driver 3C574 configures the MLID (driver of network card). First,
the name of driver is specified. Change to the name of your NIC.
Configure the "
frame" or "
(both declarations work and mean the same thing) used by this driver:
Frame Ethernet_IIIt is possible to define more than one frame type here: We already heard that ODI is a multiprotocol driver, so the MLID is able to use more than one frame and protocol with the same hardware network board. For this purpose it defines logical boards for each defined frame. Possible frames are for instance "
ETHERNET_II" (IP protocol), "
ETHERNET_802.2" or "
ETHERNET_802.3" (both IPX/SPX protocol).
For the packet driver converter, that we want to start later, it is
mandatory to define at least the Ethernet II frame here. You also have to
inform ODIPKT in a command line parameter to use the board with the
ETHERNET_II frame (see below).
Full documentation of parameters in
for DOS and MS Windows Technical Reference".
NET.CFGstart ODI drivers in
AUTOEXEC.BATat boot. The first thing to start is Link Support Layer:
Change paths for your system. The "
/C" option tells LSL
where to find
Only necessary, if
NET.CFG is not in the same
Now start MLID: LH C:\NETWORK\PCMCIA\3C574\ODI\3C574.COM
Last install Packet Driver to ODI Converter. Choose between ODIPKT or PKT2ODI.
ODIPKT.COMby Dan Lanciani, start with a command in
First number of parameters above ("
0") determines the
board that uses
ETHERNET_II frame. The following example
assumes you defined different frames (also known as "envelope types") in
--- NET.CFG --- Link Driver 3C574 FRAME ETHERNET_II FRAME ETHERNET_802.2 FRAME ETHERNET_802.3 FRAME ETHERNET_SNAPTell ODIPKT index number of logical board that supports the Ethernet II frame. Count the frames in NET.CFG: Ethernet II is the first one, the frame 802.2 is the second, the frame 802.3 is the third, snap is fourth.
0" (like programmers do). According to example above:
ODIPKT.COM 0 | board with ETHERNET_II ODIPKT.COM 1 | ETHERNET_802.2 (won't work) ODIPKT.COM 2 | ETHERNET_802.3 (won't work) ODIPKT.COM 3 | ETHERNET_SNAP (won't work)Only option that works for ODIPKT is the number that defines logical board with frame ETHERNET II, which is "
0" in example.
Second parameter ("
96") for ODIPKT. This defines software
interrupt (vector) used by driver. As learned configuring a packet driver, the
most frequently used software interrupt number is 0x60, which is the
hexadecimal value 60 (the "0x" is hex format). ODIPKT does not understand hex
values; translate this parameter to a decimal number - which is 96.
To use other values may try a hex-dec calculator or see the following list:
0x60 = 96 0x61 = 97 0x62 = 98 ... 0x69 = 105 0x6A = 106 ... 0x7D = 125 0x7E = 126Packet driver is installed. Use command "ping" from the WATTCP package to test.
PKT2ODI.EXEas Packet Driver to ODI Converter.
PKT2ODI.EXEwill be started in
AUTOEXEC.BATwith command: LH C:\NETWORK\NWCLIENT\PKT2ODI.EXE /B:1 /I:69
/B" option tells
PKT2ODI which logical
board to use. As previously choose board that
uses the Ethernet II frame. Different to ODIPKT, PKT2ODI starts counting
1", so if
--- NET.CFG --- Link Driver 3C574 FRAME ETHERNET_II FRAME ETHERNET_802.2 FRAME ETHERNET_802.3 FRAME ETHERNET_SNAPuse parameter: PKT2ODI.EXE /B:1
ETHERNET_II). Remember to use the board with Ethernet II, otherwise converter cannot communicate with driver and complain of finding MLID. Second parameter, "
/I" sets the software interrupt (vector) used by driver. Should be 0x60 but won't work with PKT2ODI. Program doesn't accept interrupt vectors 0x60 to 0x68.
Unusual interrupt vector like 0x69 can be a problem for some TCP/IP applications. Must be configured to use this vector. Some programs, like webserver SIOUX, may not function, if vector is not 0x60.
Start LSL, MLID and converter, the packet driver interface should function. Proceed with chapter "TCP/IP kernel".
NDIS2" in card installation files. Cannot find a driver, look at this site. The ending of the driver name has to be
*.DOS, so for instance driver of 3com 3C574 PC-Card is "
EL3C574.DOS". In the language of the NDIS architecture these are named "Media Access Control" (MAC) drivers.
The MAC driver is only one component of NDIS architecture. Check NDIS 2.1 documentation Procedure:
CONFIG.SYS(other DOS) load Protocol Manager driver
PROTMAN.DOS, MAC driver and protocol driver. This can be done by lines for each of these drivers or by starting the "Installable File System Helper" driver, which is loaded by "
DEVICEHIGH=IFSHLP.SYS" and starts all three drivers according to
PROTOCOL.INIand makes them available to the MAC driver and protocol driver which load after him.
NETBIND.COM(which can be done in
PROTMAN.DOS) then starts the memory resident (Terminate and Stay Resident - TSR) program
PROTMAN.EXEto execute the bind command and to control the correct ordering of drivers.
NETBIND.COMfrees most of the memory previously reserved by the Protocol Manager.
Configuration of NDIS under DOS has changed over time with different versions of the package. Some hints about the differences can be found here. In this document, we use NDIS files from MS Client 3.0. To use the NDIS2 (MAC) driver need more files. These are:
PROTMAN.DOS" and "
These are part of MS Client 3.0 downloaded here:
Three files are part of "
EXPAND.EXE" included on the first disk to decompress.
DSK3-1.EXEto a directory like
C:\MSCLIENT1. Avoid a long path if done in Windows. 16-bit software won't execute, if path is too long.
DSK3-1.EXEto unpack it's content.
expand -r protman.do_
expand -r protman.ex_
NETBIND.COMis already uncompressed. Files are ready. Last item is "Packet Driver to NDIS Converter". Get the widely used "
DIS_PKT9.DOS" (version 9) or alternatively the slightly newer (version 11) "
DIS_PKT.DOS". There are no differences in usage and handling. Both written by Prof. Joe R. Doupnik (Utah State University) and Dan Lanciani (Harvard University).
PROTMAN.DOS PROTMAN.EXE NETBIND.COM DIS_PKT.DOSinto a directory, for instance
C:\NET. Copy the MAC driver of network interface card, for instance: EL3C574.DOS into this directory. Create configuration file needed for NDIS architecture: Create a file with the name
C:\NETdirectory. For our minimal configuration it needs the following lines:
--- PROTOCOL.INI --- [protman] DriverName=PROTMAN$ [EL3C574] DriverName=EL3C574$ [PKTDRV] drivername=PKTDRV$ bindings=EL3C574 intvec=0x60 chainvec=0x68
PROTOCOL.INIis structured into section names in square brackets and item names with values assigned.
[protman]defines the Protocol Manager. loaded as driver
PROTMAN$". Section and line are mandatory.
[EL3C574]defines network interface card. By default the section itself is named after the card - this is useful, if you have more than one network card and use different sections for different cards. Section name is the first value to change. Good idea to name it after your network card. Could name section to "netcard", "NIC" or even "baked_beans" - as long as you also change all the other lines in
PROTOCOL.INIthat point to that section.
The next line is "
defines driver for network interface card. In example is
EL3C574.DOS, named "
Modify with your driver name. Find correct name of driver
in a text file "
PROTOCOL.INI" that should be included with
NDIS driver files supplied with card.
Possible to add more lines to this section, to define
special settings for network card. Consult the
PROTOCOL.INI" supplied with NDIS driver for more
information. In many cases the line with drivername should be enough.
[PKTDRV] drivername=PKTDRV$ bindings=EL3C574 intvec=0x60 chainvec=0x68"
[PKTDRV]" defines Packet Driver to NDIS Converter, "
DIS_PKT.DOS" or "
DIS_PKT9.DOS". Both are called by the name "
"bindings=EL3C574". Note this name includes no "
$" letter - it refers to the name of the section that defines the driver, not to driver itself. If you named section "
[baked_beans]" you would write "
bindings=baked_beans" here ;-).
intvec" specifies software interrupt vector
used by packet driver. Hexadecimal value 0x60 per default.
chainvec" defines an available software
interrupt. It's function is still a mystery to me. According
to packet driver inventor FTP, adding a chain vector interrupt may improve
packet processing speed and reliability. Users saw
"a 10-fold increase in performance". To avoid EMM386 errors, some recommend
to set an interrupt that increases the vector by decimal 8. So if the
intvec is 0x60 (that is decimal 96), then the
chainvec should be decimal 104 (96+8) which is hexadecimal 0x68.
This is also described
by one of the authors of
DIS_PKT.DOS, Dan Lanciani. Please write
if you find out more.
These are settings in
PROTOCOL.INI needed for our
purpose. Final hint: if you consider changing some of these values at
boot, for instance by a DOS boot menu, could use
Horst Schaeffer's freeware "Inifile"
Load drivers at boot. Modify system files with the following lines:
--- FDCONFIG.SYS (FreeDOS) --- --- or CONFIG.SYS (MS DOS/other DOS) --- DEVICEHIGH=C:\NET\PROTMAN.DOS /I:C:\NET DEVICEHIGH=C:\NET\EL3C574.DOS DEVICEHIGH=C:\NET\DIS_PKT.DOS"
/I" parameter tells Protocol Manager the location of
PROTOCOL.INI. Unneeded if both in same directory.
--- AUTOEXEC.BAT --- C:\NET\NETBIND.COMNote that
NETBIND.COMcan not be loaded high and should just be executed from
AUTOEXEC.BAT. If you try to load it like a driver, it will abort with the message "
run-time error R6009 - not enough space for environment".
AUTOEXEC.BATor by a batch-file. It stays memory resident, so it can answer ping requests for instance.
NTCPDRV.EXE, the TCP/IP kernel of Novell NetWare
TCPIP.EXE, Microsoft MS Client's
TCPTSR.EXEand FTP Software Inc.'s
ETHDRV.EXE. Examples for TCP/IP kernels that are already built-in into DOS applications are WatTCP, which is f.i. already built-in the graphical web browser "Arachne", the KA9Q kernel which is part of that program, the NCSA Telnet kernel which is built into the applications included in this suite, the CUTCP kernel and the University of Minnesota stack, which is part of "Minuet". According to Jeffrey L. Hayes from the retrocomputing website http://www.oldskool.org more than half of the DOS networking applications available use the WatTCP kernel.
First look at WatTCP and successor Watt-32. Then examine NTCPDRV, the only free external TCP/IP kernel available. Last brief look at other external TCP/IP kernels.
WAT1104.ZIPat various sites in the internet. While the software is free, the WatTCP Programmer's Reference issold as PDF for 55$. WatTCP was ported to 32-bit by Gisle Vanem at Bergen, Norway in 1999. The port is called Watt-32. It supports 32-bit protected-mode as well as 16-bit real-mode. It comes with uncompiled applications, compiled versions can be downloaded here. There is a developer forum which is still active. WatTCP and Watt-32 are not external TCP/IP kernels. Both are just sets of libraries designated to programmers - they can use these libraries to implement TCP/IP functions into their applications. The WatTCP package includes such applications with built-in WatTCP kernel like "ping", "finger", "whois" or "lpr".
Some important DOS network applications use the WatTCP libraries like Arachne or ssh2dos. A list of these apps is available at "DOS Solutions".
WATTCP.CFG" basically the same in both versions. Located in applications directory per default. General settings:
--- WATTCP.CFG --- # These are example values: my_ip = 192.168.1.10 netmask = 255.255.255.0 nameserver = 192.168.1.1 nameserver = 22.214.171.124 nameserver = 126.96.36.199 gateway = 192.168.1.1 # Uncomment, if your receive your configuration via DHCP # my_ip = dhcpAdditional settings may be needed. A deeper introduction into the use of WatTCP programs at Smashco.
TCPDRV 2.01 was released as "experimental version". In 1993 a version 3.01
followed, which was called NTCPDRV. Improvements included a more efficient
memory usage and bug
fixes. Both versions and the textfile
(the specification for programmers) were made publicly available from the
Trumpet website: trumpet.com.au/dosapps
Licensing issues are simple: "These DOS
applications are provided free without support." Thanks to the popularity of
the trumpet software, it can be downloaded from various mirrors. A
commercial version of the TCP driver is available from Peter Tattams new
company "Tattam Software
NTCPDRV.ZIPand extract. For documentation, download the older version
TCP201.ZIPas well, which also includes several applications. The TCP/IP kernel has to be configured with the settings of your network. Done either by commandline parameters or by setting DOS environment variables.
NTCPDRV.EXEwith command (one line):
or configure by setting environment variables: Add lines to
AUTOEXEC.BAT or batchfile to be started before
--- AUTOEXEC.BAT --- set ip=192.168.1.80 set netmask=255.255.255.0 set gateway=192.168.1.1 set dns=192.168.1.1The kernel automatically searchs for a usable interrupt vector, may also use parameter "
-vec=61" to specify vector 0x61 provided by packet driver. See documentation for more possibilities. Once Trumpet TCP/IP kernel operating able to run several TCP/IP applications (for instance Trumpet Newsreader, webservers Sioux or Webserv). Machine also reachable from the network, try a ping request.
TCP16.EXE", which runs directly atop of the ODI driver. A few programs like Josh's "Tiny" remote control software and Tsoft's "NFS Clients for DOS" still use this kernel.
TCPTSR.EXE". It also can be used by external programs. It may be useful though, to check memory requirements first. MS Client's TCP/IP seems to consume a lot of conventional DOS memory.