Client ran DOS, OS/2 or Macintosh as OS and used a client software
like "LAN Manager client" or "MS Client" for the connection to the
server.
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
section).
PC-IP
A small TCP/IP implementation that was
linked into a few applications like finger, whois and netwatch. PC-IP was
released with its source into the public domain. Drew Perkins from Carnegie
Mellon University (CMU) and Dan Lanciani from Harvard University improved the
code further. PC-IP still can be found in the web.
PC/TCP
The success of PC-IP inspired Romkey and friends to take the CMU version
of the code and develop it into a proprietary product: "PC/TCP", which they
sold through their company "FTP Software, Inc.",
founded in 1986. The name was chosen after the popular 'File Transfer
Protocol': PC/TCP included one of the first applications for FTP services on
the PC.
Packet Drivers
Along with PC/TCP, FTP Software Inc. developed the "Packet Driver
Specification", the first multiprotocol driver specification for PC
network interface cards. On 12 Dec 1988 this specification was released as an
open standard, for anyone to implement.
Packet drivers proved useful to hardware vendors and software developers
alike. Most of the public-domain or shareware TCP/IP applications have been
written to interface with packet drivers only.
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 DIS_PKT.GUP did
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.
KA9Q
Second after the early PC-IP kernel was the ""KA9Q Network Operating System"
(NOS)" by Phil Karn in 1985. Karn, an engineer from Baltimore, Maryland
had created it for CP/M two years before and then ported it to DOS. It also
was one of the first TCP/IP applications for DOS that used FTP Software's
packet driver specification.
KA9Q simultaneously acted as an Internet client, a server and an IP packet
router. The program was specialized for amateur packet radio, but also could
be used f.i. as ftp- or webserver. KA9Q attracted many contributors. As Karn
describes: "It was the Linux
of its day".
In 2002 KA9Q became free software (GNU GPL). Its descendants, JNOS and EZ-NOS (see also here and here) are
still actively maintained.
NCSA Telnet
Based on the Packet Driver Specification several universities wrote TCP/IP
applications and utilities for DOS PCs. In 1986 the "National Center for
Supercomputing Applications" (NCSA) at the University of lllinois released
"Telnet"
- a client for UNIX telnet services which could act as FTP and rcp server as
well. It was accompanied by TCP/IP tools like finger, whois and lpr. NCSA
Telnet came with its own TCP/IP kernel, which was already built-in into the
applications. The software was developed until 1995 (v2.308) and released
with source
into the public domain.
CUTCP
Clarkson University in Potsdam, New York took version 2.2 of NCSA
Telnet and modified it. They called their version CUTE or CUTCP. Eventually
Rutgers University, New Jersey took over the maintenance and published the
latest release
in July 1993. In difference to NCSA Telnet, CUTCP supported the IBM-3270
emulation and was technically improved. It also became public domain.
Others
Minuet Version 1.0 Beta 18A
Other developments at universities that should be mentioned are "Kermit", a terminal emulation for
DOS written at the Columbia University, New York and the University of
Minnesota's "Minnesota InterNet Users Essential Tool" ("Minuet"), a packet driver
based suite of TCP/IP applications. Minuet provided a mouse driven graphical
interface that integrated client applications as E-mail, Gopher, telnet,
Usenet News, a web browser and FTP.
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.
- Free versions of packet driver converters for today's more common ODI
and NDIS drivers:
ODIPKT.COM written by Dan Lanciani
(Harvard University) allows to use ODI drivers as packet drivers,
DIS_PKT9.DOS by Prof. Joe R. Doupnik (Utah State University)
and Dan Lanciani does the same with NDIS drivers.
- "WatTCP", a popular free TCP/IP kernel library written 1990 - 1992 by
Erick Engelke from Canadian Waterloo University and its successor Watt-32
by Gisle Vanem (Norway). These libraries enable programmers to include
TCP/IP functions into their applications without having to reinvent the
wheel.
- "Trumpet TCP driver (NTCPDRV)" from 1992, a free external TCP/IP kernel
created by Australian programmer Peter Tattam (also well known for his
Trumpet Winsock).
Beneath FTP Software Inc.'s PC/TCP a lot of other commercial applications
could be found on the market for DOS TCP/IP networking software ten or
fifteen years ago.
Up to 30
TCP/IP packages for DOS were available in the middle of the nineties,
including IBM "TCP/IP for DOS", NetManage "Chameleon", Sun "PC-NFS", Novell
"LAN WorkPlace", Frontier Technologies "SuperTCP" or Artisoft "Lantastic".
A comparison of their features can be found here. Read also
the corresponding article in the
"Network Computing" magazine.
Picking up the pieces
Some Novell and Microsoft tools can still be legally downloaded and
used. And TCP/IP solutions by universities and hobbyists that were released
into the public domain, as shareware and even as postcardware, are still
around.
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.
2. DOS networking today
Here we learn about network drivers, protocols
and applications for a DOS PC.
For more information try Eugene Blanchard's "Introduction to
Data Communications" More recent version
here).
Ethernet is today's dominant network hardware technology.
For such network adapters three types of driver can be used.
Network Driver Interface Specification (NDIS) drivers, developed
by Microsoft and 3Com.
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.).
Protocols
The following protocols are supported by these three drivers:
- Transmission Control Protocol / Internet Protocol (TCP/IP) used
by the internet,
- Internet Packet Exchange / Sequenced Packet Exchange (IPX/SPX)
protocols, used by Novell NetWare,
- Network Basic Input Output System (NetBIOS) Extended User Interface
(NetBEUI) protocol used by OS/2, Windows 9x, ME and 2000.
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.
Applications
Three ways of networking used with DOS.
- ODI driver based Novell NetWare
programs around for accessing a NetWare network and using TCP/IP services.
- NDIS driver based Microsoft "LAN Manager Client" or "MS Client
3.0" are supposed to integrate DOS machines into a Windows / SMB
workgroup.
- Packet driver based "UNIX-like" TCP/IP applications
can be used to access or provide network services.
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
"TransBIOS".
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
helpful.
Examples are:
Bart's Network Boot Disk |
Drivesnapshot |
Netbootdisk
Novell provides software for free:
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".
Microsoft "LAN Manager Client" and "MS Client 3.0"
Download from Microsoft's ftp-site and are
free for "internal use", but not for distribution.
Excellent review,
installation report and comparison of both Microsoft products
by Dutch programmer Jacco de Leeuw.
Ken from British website "DOS Solutions" gives a detailed overview
over many resources related to MS Client .
U.S. programmer Jonathan Young has created a nice looking MS Client installation
walkthrough with many screenshots. James Hatridge wrote a nice article about MS
Client for Linux Journal in 2002.
Installation guides in German language have been written by Volker
Rüddigkeit, by Gerhard
Zeiser, by Gerd
Röthig, by Michael Vogl
and by Stefan
Mayrhofer.
Popularity of the thirteen year old MS Client 3.0 may be caused by
the possibility (but not officially supported) to use an update
called "WG1049.EXE"
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.
TCP/IP applications
DOS TCP/IP applications include classic networking tools as ping, lpr or
finger as well as SSH and NFS clients, FTP servers, webservers, mail and news
software or web browsers. There is even a complete peer-to-peer networking
solution called "Network Enhanced
Operating System" (NeOS) which was developed 1995-2000 as part
of European Union's "EUREKA" project. Now it is postcardware.
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.
3. Practical Guide: Adding TCP/IP to DOS
The majority of TCP/IP applications for DOS uses the packet driver
interface. So to be able to run them, we need to install the appropriate
drivers first.
To install a generic packet driver is the simplest way. But it isn't
always possible, as modern network cards often only come with ODI- and
NDIS-drivers. Anyway: ODI- or NDIS-drivers can also be used as packet drivers
through special converters ("shims").
Packet drivers work as an interface between the hardware (the network
interface card) and the TCP/IP kernel (which is also called "protocol
stack"). One sort of TCP/IP kernels work as an external program that can be
called and used by various network applications. Other TCP/IP kernels are
already built into network applications, a web browser for instance or a
ftp-client. We will learn more about these kernels a bit
further in this document.
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 IPXPD.COM or PDIPX.COM
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
directory "PKTDRV" on the CD or floppy that came with your
card.
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 NICSCAN.EXE
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.
Installing a packet driver
To install a packet driver, add a line to
AUTOEXEC.BAT (example for 3c589 PCMCIA card):
LH 3C589PD.COM 0x60 5 0x300
In 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
"-u".
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.
"Open Datalink Interface" (ODI) drivers were originally needed for Novell
NetWare. But that doesn't mean they can not be used for packet-driver-based
TCP/IP applications. In fact, they were used for this since they were
invented.
An ODI driver is a good choice, if you cannot get a packet driver.
Look for a directory called "netware",
"nwclient", "ODI" or "VLM" on the
installation floppy or CD-ROM. The drivers are executables,
their names look like "3C574.COM" or
"DFE670.COM".
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
called "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
file "LSL.COM" can be found in the folder
"NIOS".
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
three options.
ODIPKT.COM v3.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.EXE by 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.
- If already running full NetWare, can use
IPXPKT.COM to run a packetdriver over IPX.COM.
IPXPKT.COM is 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 "NET.CFG". An
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
ODI driver.
Configuration of NET.CFG
Edit main configuration file NET.CFG. If it
doesn't exist, create it. Choose a directory - default locations
of NET.CFG seem to be C:\NWCLIENT or
C:\NET. The location should be in same directory,
where LSL.COM and driver is found.
An example NET.CFG which
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
are enough:
--- NET.CFG ---
Link Support
buffers 8 1600
Link Driver 3C574
Frame Ethernet_II
Explanation of the parameters
Line "Link Support" configures the LSL. Options are:
"buffers", "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 "envelope type"
(both declarations work and mean the same thing) used by this driver:
Frame Ethernet_II
It 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 NET.CFG see
"NetWare Client
for DOS and MS Windows Technical Reference".
Once configured NET.CFG start ODI drivers in
AUTOEXEC.BAT at boot. The first thing to start is Link Support Layer:
LH C:\NETWORK\NWCLIENT\LSL.COM /C C:\NETWORK\NET\NET.CFG
Change paths for your system. The "/C" option tells LSL
where to find NET.CFG.
Only necessary, if NET.CFG is not in the same
directory as LSL.COM.
Now start MLID: LH C:\NETWORK\PCMCIA\3C574\ODI\3C574.COM
Last install Packet Driver to ODI Converter. Choose between ODIPKT or
PKT2ODI.
Alternative 1: ODIPKT
With free converter ODIPKT.COM by Dan Lanciani,
start with a command in AUTOEXEC.BAT:
LH C:\NETWORK\NWCLIENT\ODIPKT.COM 0 96
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:
--- NET.CFG ---
Link Driver 3C574
FRAME ETHERNET_II
FRAME ETHERNET_802.2
FRAME ETHERNET_802.3
FRAME ETHERNET_SNAP
Tell 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.
To make things a bit tricky, ODIPKT starts counting with "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 = 126
Packet driver is installed. Use command "ping" from the WATTCP package to test.
Alternative 2: PKT2ODI
An alternative is Caldera's PKT2ODI.EXE as
Packet Driver to ODI Converter.
PKT2ODI.EXE will be started in
AUTOEXEC.BAT with command:
LH C:\NETWORK\NWCLIENT\PKT2ODI.EXE /B:1 /I:69
The "/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
with "1", so if NET.CFG appears:
--- NET.CFG ---
Link Driver 3C574
FRAME ETHERNET_II
FRAME ETHERNET_802.2
FRAME ETHERNET_802.3
FRAME ETHERNET_SNAP
use parameter: PKT2ODI.EXE /B:1
Define use of first board (the one with 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.
Use vector 0x69: PKT2ODI.EXE /I:69
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".
Drivers based on the "Network Driver Interface Specification" (NDIS) are
the default in the Windows and OS/2 world. Most recent version is NDIS 6
used in Windows Vista. Windows 98 used NDIS 5, Windows 95 came with NDIS 3.1.
In DOS use real-mode driver NDIS2.
Probably a NDIS driver exists for your network card. Look for
directory "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:
- Commands in
FDCONFIG.SYS (FreeDOS) or
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.INI.
- The Protocol Manager reads the configuration from
PROTOCOL.INI and makes them available to the MAC driver and
protocol driver which load after him.
- The MAC driver and the protocol driver load and configure themselve
according to that information. They identify themselves to the Protocol
Manager.
- Before MAC driver and protocol driver can communicate, they have to be
bound together, so they can access each others "entry points"
(communication ports). This bind process is controlled by the Protocol
Manager based on information in
PROTOCOL.INI.
- The binding sequence can be triggered by
NET.EXE or
NETBIND.COM (which can be done in
AUTOEXEC.BAT).
- The Protocol Manager (
PROTMAN.DOS) then starts the memory
resident (Terminate and Stay Resident - TSR) program
PROTMAN.EXE to execute the bind command and to control the
correct ordering of drivers.
- After binding has occurred, the MAC and the protocol driver communicate
directly to each other. The Protocol Manager is not involved in this
communication process any longer, so
NETBIND.COM frees 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:
The bind utility ("NETBIND.COM")
These are part of MS Client 3.0 downloaded here:
ftp://ftp.microsoft.com/bussys/Clients/MSCLIENT/DSK3-1.EXE
ftp://ftp.microsoft.com/bussys/Clients/MSCLIENT/DSK3-2.EXE
Three files are part of "DSK3-1.EXE". Use
utility "EXPAND.EXE" included on the first disk to decompress.
NETBIND.COM is 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).
Configuration of NDIS drivers
This is a minimal installation of MS Client 3.0. The only purpose is to use a
packet-driver application. For this purpose:
Copy the four files
PROTMAN.DOS
PROTMAN.EXE
NETBIND.COM
DIS_PKT.DOS
into 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 PROTOCOL.INI inside
the C:\NET directory. 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
Explanation of the parameters
Like other *.ini files, PROTOCOL.INI is structured into
section names in square brackets and item names with values assigned.
[protman]
DriverName=PROTMAN$
[protman] defines the Protocol Manager.
loaded as driver PROTMAN.DOS named "PROTMAN$".
Section and line are mandatory.
[EL3C574]
DriverName=EL3C574$
[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.INI that
point to that section.
The next line is "DriverName=EL3C574$" which
defines driver for network interface card. In example is
EL3C574.DOS, named "EL3C574$".
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
"PKTDRV$".
Important that converter binds to driver of network
card. Achieved by "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.COM
Note that NETBIND.COM can 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".
Test with ping.
TCP/IP kernel is also called "stack" or "protocol stack", because it
consists of two layers: IP and TCP. IP runs on top of the hardware driver and
TCP on top of IP, providing an interface to network applications.
Modern operating systems have their own TCP/IP kernel already built-in:
Microsoft come with "Winsock" since Windows 95. In GNU/Linux
TCP/IP stack is part of Linux kernel. For DOS different types of TCP/IP kernels are available.
They can either work as external programs or already built into applications.
- An external TCP/IP kernel is typically started by
AUTOEXEC.BAT or by a batch-file. It stays memory resident,
so it can answer ping requests for instance.
- Other network applications come with TCP/IP kernel functions already
built-in and do not need an external TSR kernel. An application
with built-in TCP kernel has the advantage that it doesn't need another
driver which consumes precious DOS memory. On the other hand TCP/IP
functions are limited to those of the network application and are only
provided as long as it runs.
Every TCP/IP kernel must be configured with general information about the
network, as IP address, netmask, nameservers and gateway, or it must be told
to get this information via a BOOTP or DHCP server.
Examples for external TCP/IP kernels for DOS are the free Trumpet TCP
kernel NTCPDRV.EXE, the TCP/IP kernel of Novell NetWare
TCPIP.EXE, Microsoft MS Client's TCPTSR.EXE and 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.
WatTCP / Watt-32
Waterloo TCP (WatTCP) was written 1990 - 1992 at the University of
Waterloo in Ontario Canada. Author Erick Engelke, then a developer
in the Faculty of Engineering, today the university's Manager of Networks and System
Integration. The core TCP engine of WatTCP was based on Geoffrey H.
Cooper's TinyTCP.
WatTCP was originally released under a homebrewed public domain license -
binary and source were free for use, distribution was allowed only for
non-commercial reasons. In 2004 Erick Engelke copyrighted the libraries under
the terms of the GNU LGPL. WatTCP can be found at Erick Engelke's homepage or as
WAT1104.ZIP at 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".
Usage
No download needed to use WatTCP / Watt-32 kernel.
It is already in the applications. What is required is a configuration
file, named "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 = 129.97.128.196
nameserver = 129.97.128.1
gateway = 192.168.1.1
# Uncomment, if your receive your configuration via DHCP
# my_ip = dhcp
Additional settings may be needed. A deeper
introduction into the use of WatTCP programs at Smashco.
Trumpet TCP driver is an external TCP/IP kernel working as a
TSR program running on top of a packet driver.
TCPDRV was created in 1992 by Peter Tattam, a programmer in the Psychology
department of the University of Tasmania at Hobart, Australia. According to a
biography on his website,
he developed the shareware "Trumpet Newsreader" short time before and wrote
the TCP driver just because nothing else was openly available for Turbo
Pascal. Development eventually lead to the popular Windows software "Trumpet
Winsock", which Tattam sold through his own company "Trumpet International of Australia",
founded in 1994.
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 TCP201.SPE
(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
Enterprises".
Usage
Download NTCPDRV.ZIP
and extract. For documentation, download the older version
TCP201.ZIP
as 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.
Start NTCPDRV.EXE with command (one line):
NTCPDRV -ip=192.168.1.80 -netmask=255.255.255.0 -gateway=192.168.1.1 -dns-host=192.168.1.1
or configure by setting environment variables: Add lines to
AUTOEXEC.BAT or batchfile to be started before
NTCPDRV.EXE.
--- 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.1
The 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.
Other TCP/IP Kernels
Other external TCP/IP kernels are still legally downloaded. From Novell and
Microsoft may be of use.
- Novell distributes its popular 16-bit TCP/IP protocol stack "
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.
- Microsoft's "MS Client
3.0" includes its own TCP/IP 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.
Comments to this site? Ideas? Suggestions? Please drop a note!
Don't forget to add your email, if you wish a personal reply.
The comments are sorted from date.
Ulrich Hansen, 12.12.2007 modified by others 1.08.2008
Further questions visit FreeDOS User mailing
list.
DosNetcomment Ulrich's homepage