[#toc]

Table of Contents

[#intro]

Introduction

Network drivers frequently have been distributed to support multiple operating systems with one driver package. (So DOS, Windows 3.1, and 32-bit Windows drivers have often all appeared in one downloadable file, even though many users won't be using more than one of those sets of drivers.)

Before listing specific driver packages, a discussion is in order of what types of drivers are available, and which should be used, so that it can be understood what one gets and what one should use when mulitple choices present themselves. (This is perhaps most important for the DOS platform.)

As for which driver type should be used, there are some clear criteria to determine that. They are:

Compatibility

Note that if one type of driver is available but another type of driver is desired, one can use a piece of software called a "shim", basically a converter, that is a driver of one driver type and that uses a driver of another driver type.

Compatibility with hardware
In order to use a certain type of software with hardware, that driver must exist. Often drivers are bundled with packages released by the manufacturer. Other drivers may be provided by the creators of the type of driver.
Compatibility with software

Software is generally written to use just one type of driver API. This may be less important than hardware compatibility as a shim can often be used if the desired type of driver is different than what is available for the hardware. For instance, DOS Networking HOWTO says the Packet Driver specification standard is "the one most used by GNU and shareware programmers." ODI is often used with IPX, which DOS Networking HOWTO calls "a very memory efficient protocol". NDIS 3.0 is used to save some memory when using Microsoft Windows.

Superiority for need

If there are multiple options, then here are some guidelines to help choose which type of driver to prefer.

NDIS drivers are not preferred in DOS since they take up more memory. As for the other two options, the amount of DOS memory could vary. Using the option that uses up less DOS memory may make the most sense. If both options seem to take up similar amounts of memory, Crynwr's drivers are open source. Therefore, the recommended order has been: The TCP/IP-based packet drivers, then the IPX-based ODI drivers, then the NetBEUI-based NDIS standard.

When the connections between the layer 3 protocols were later noticed, and these layer 3 protocols have a clear order of preference (which is the popular TCP/IP followed by the less often used IPX and lastly and leastly followed by the less routable NetBEUI), that same order simply became re-confirmed.

[#drivapis]

Driver APIs

The "Packet Driver" specification from FTP Software, Inc.

This specification has been su pported by Crynwr Software, a company which has provided many packet drivers that Crynwr Software's main page says are OSI (Open Source Initiative) Certified Open Source. The specification, then, may frequently be referred to by the name Cyrnwr, or ftp.com (a domain which FTP Software, Inc. did control, at least at one time.)

In addition to many of the drivers being open source, the specification is openly available. Cyrnwr hosts the documentation of the Packet Driver Specification (local, renamed).

Novell ODI Driver

"Originally Novell combined the driver and protocols together in one monolithic program, but in 1991 developed the ODI driver specification, which, with modification, is still in use today. This allows a single hardware specific driver to be written and used with multiple different protocols. Most manufacturers will write ODI drivers and Novell have many available for download. Configuration is fairly straightforward using a text file called NET.CFG".

Because this may have more drivers written for it then the ftp.com packet driver standard, ODI may be somehow more useful in some cases. Called newer than NDIS and Packet Drivers, and furthermore said to be "in many ways is the "best" of the bunch".

A quick guide to using ODI: This was written without much testing for accuracy, so hopefully this information works well.

Typically, it seems the purpose of using ODI is to get a network set up that uses IPX. Accomplishing that is done in 3 stages:

  1. Run the Link Support Layer (LSL.Com)
    • There are different versions of LSL.Com. Some will use up more memory than others. Sometimes a minimum version is required for some software (if by nothing else, then by IPXODI).
      • Version 2.11 can be a needed minimum version. IPXODI-2.Zip (local) contains this.
      • Version 2.02 (often works and uses less mem?)
  2. Running the NIC-specific driver, which will use NET.CFG. The name of this file varies, often having the name of the manufacturer and/or card model in the filename.
  3. At this point in the procedure is the optimal time to load ODIPKT/WinPKT, if these optional programs are going to be run, according to An ODIREAD.ME text file (local, renamed to lowercase).
  4. Running IPXODI.Com

Removing the network drivers involves running the three commands with -u parameter in reverse order:

  1. ipxodi.com -u
  2. filename.com -u
  3. lsl.com -u

PDEther (local), an older ODI driver which runs over a packet driver. (Called a "shim" by Cyrnwr's SOFTWARE.DOC in pktd11.zip).

Microsoft/3COM Network Driver Interface Specification (NDIS)

"The NDIS drivers use the most memory of all the drivers in use, so should only be used where no other driver is available OR the software you want to uses only works with NDIS." Actually, I wonder if they are large only in pure DOS. I could easily see them being large because they are more advanced (although uselessly so: They don't provide extra functionality that really makes them more useful in DOS) but if NDIS can use Windows drivers and thereby use up less memory when in Windows.

NDIS 2.0

NDIS may consist of three parts: The "Protocol Manager" (protman.dos, which apparently uses protocol.ini from the LAN Client LANMAN.DOS directory), the "LAN Adapter card driver"/"MAC driver" (which could be one of several different filenames), and additional drivers, like the one for the NETBEUI protocol (netbeui.dos) or the one supporting Windows for Workgroups 3.1 moving the Redirector and Server modules to Windows-managed memory above the first megabyte (workgrp.sys). The *.DOS filenames are meant to be loaded using the CONFIG.SYS file, just like HIMEM.SYS and EMM386. (To give proper reference, a lot of this information hasn't been tested by TOOGAM as of this writing, and was taken from NDIS document.)

NDIS 3.0

"Windows for Workgroups 3.11 permits new 32-bit LAN support modules to run in Windows. Technically, such MAC adapter card drivers and protocol modules are said to follow the NDIS 3.0 specification. CONFIG.SYS contains only a single statement that serves as a placeholder:
device=ifshelp.sys"

(This quote comes from Adding Packet Drivers to NDIS document, which is also the source of a lot of this NDIS 3.0 information, which TOOGAM hasn't personally tested.) (Interestingly, this filename seems quite similar to the ifshlp.sys which Win9x loads into memory by default unless MSDOS.SYS specifies NOAUTO on the DOS= line.) The NDIS 3.0 standard involves running NET.EXE from the Windows folder. NET.EXE looks through SYSTEM.INI to find references to Network code, and determines whether any of the code isn't based on the 32-bit standard new to NDIS 3.0. If it is all based on the new standard then code doesn't get loaded before Windows starts, otherwise it gets loaded.

When DIS_PKT is loaded with SYSTEM.INI, then PROTOCOL.INI is used (and apparently from the \WINDOWS directory, instead of the LAN Client directory LANMAN.DOS.)

The Adding Packet Drivers to NDIS document (local as ndis/addpknds.htm) gives an overview of NDIS and details how to use DIS_PKT.DOS with NDIS or with WfWG 3.11. PROTOCOL.INI is a file that may be in different locations (either LANMAN.DOS or the Windows directory).

An index file describes ODINSUP.ZIP as ODI to NDIS shim. (However, it was found in an ODI directory and seems to be the other way: Taking an NDIS card and making it work with ODI.) This is for DOS and OS/2. It is not unloadable. local as ndis/odinsup.zip until its exact use is determined.

Others
Token Ring
There are shims for token ring. For example, TOK* (and related) in FTP site.
[#toolnet6]: Toolnet6

Toolnet6 was distributed by Hitachi. The drivers of Toolnet6 provided IPv6 support and worked in Windows 95, 98, and NT. Drivers were provided for NE2K cards and some 3Com cards. The software may still be obtained from Wayback Machine's Archive of a Mirror with Toolnet6 files (which have not been verified nor tested, although the files have been recently downloadable). (Note: If the Wayback machine doesn't successfully provide the files, try downloading again, as the first request may time out so the server results in a retrieval error, although a subsequent request may work.) (There is a local copy of the Toolnet 6 files, archived.)

Yet others

There may be other standards in use. Those used for other operating systems may still be useful. For DOS, by and large, other custom made solutions have limited application as there weren't as many software programs written to support the other standards.

[#netdrivs]

Network Drivers

This section largely details collections of drivers sorted by hardware. Especially for use with DOS, some useful drivers may currently be found in the above section: Driver APIs, and are not redundantly placed in this section as well.

NE2000 (a.k.a. NE2K) (and compatible cards)

Several network cards were compatible with the NE2000. A packet driver is available. There is an NE2K driver that uses up a fairly low amount of DOS memory.

Intel drivers

Intel has made a number of popular NICs (Network Interface "Cards"), including circuitry found on some motherboards.

Intel page refers to Crynwr and has link regarding Linux and Unix drivers. To get drivers for a card, just pick some specific card that sounds close (Intel's site has you pick a very specific card before it links you to drivers for the card, but then the drivers aren't nearly so card specific). After you choose a driver from the list, the page lists oodles of cards that the driver supports. After installing the driver, a tray icon appears that can be disabled or re-enabled through Control Panel -> "Intel(R) PROSET II" icon. The more specific card may then be easier to identify: For example, the AW-MB700 motherboard model such as used on the WINIP-06046 motherboard comes with an Intel(R) PRO/100 VM Network Connection and an Intel(R) PRO/1000 CT Desktop Connection, as clearly shown in the Windows control panel icon after installing the driver.

Intel's website has redesigned so that earlier links, such as Download Finder, don't have the same content. They might redirect to a new page, such as Downloads page, or they might refer to a file not being found.

The following are some drivers for the PRO/1000 CT circuitry.

Page links
Standard Drivers
DOS Drivers
DOS NDIS2, DOS ODI Intel PRO drivers for DOS (Executable archive)
Windows 32-bit drivers
Notes: Although the website http://downloadmirror.intel.com/df-support/4236/eng/PRO98.exe dates the drivers (Ver 10.1) as 8/9/2005, Windows recognizes them as being earlier (sometime 06/2005). The temporary directory used during driver installation is C:\Intel10.1\. I believe the drvers probably were what was causing an issue I had in Win98SE: (when Putty was opened with lots of port forwards enabled, even if not used, Firefox 2.0.0.2 would simply not download pages. I am guessing that was a network driver issue.) The web page for the new drivers note "If, after updating the drivers on Gigabit interfaces, you get a VFAT error, try booting into Safe Mode and then changing the Transmit Descriptors and Receive Descriptors to reduce the number to 80." I'm guessing that really only affects when transfering at the higher speeds (more than 100Mbps), and I'm guessing the issue is also present with the older drivers.
Win98(SE)
Win98(SE) PRO98.EXE
WinMe
WinMe PROME.EXE

Others: Intel drivers for Intel Gigabit and PRO/1000 Gigabit Server Adapters has been hyperlinked to, from VMware KB (1016456): e1000 NIC driver.

Monitor Mode

Archive.Org cache of Intel's Monitor Mode Gigabit Driver says, "This gigabit driver is not in the standard download area but is available via the link below." However, the site that the link points to seems unresponsive. (In case it comes back, the link was Gigabit Driver [EXE]: MONITORMODEGIGDRIVER.EXE 3.51MB file dated Sept 26, 2003.) There may be a local copy: renamed. (There is also a current Network Adapter Gigabit Packet Driver (GigPktDrvr.exe) for DOS which might be completely unreleated.

A newer page about Monitro mode mentions: HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\00xx where xx is the instance of the network adapter that you need to see tags on. (Check by opening and viewing the name of the adapter). It should be set to read: MonitorModeEnabled= 1 Note: ControlSet001 may need to be CurrentControlSet or another 00x number.

Intel Boot Agent (flash utility)
Intel Boot Agent search results. The Intel Boot Agent "Prepares Boot ROM of most Intel® network adapters for PXE 2.1 boot and configures Wake On LAN options." PROBOOT.EXE
Driver files may be found locally in the Intel PRO 100/1000 drivers directory.
3Com
3Com ® Fast EtherLink® XL PCI TX Network Interface Card (Product #: 3C905B-TX)
(Not to be confused with 3C509 series.)
3Com® 10/100 LAN+56K Modem Mini PCI Card
Part # 3CN3AC1556B (a.k.a. 3C556) which I found in a machine with the brand of Qrium. Win95/98/NT/Me/2k driver (local) DOS driver (local) .lan driver for DOS based Novell Client 32 application (local)

Installing the drivers were a pain. I seemed to not make any progress until I did the following things *in order*:

  1. Went to Device Manager and removed any already existing device that referred to this card (namely this was some with yellow question marks, like "PCI Ethernet controller")
  2. Went to Add/Remove hardware, and if I was asked about detecting a device, I said to not detect a device: If asked if a device was in the list, I said "No". I went to "Have Disk"
  3. Windows eventually said it was going to try to install the device. Then it said it couldn't install the drivers and gave me Error 1F6.
  4. I rebooted per Windows suggesting/asking/telling me.
  5. Windows then it asked me about installing the driver. I tried again to install driver, perhaps using Have Disk. It tried again and gave Error 1F6 again.
  6. I might have rebooted and then repeated the previous step.
  7. I cancelled out of the window that poppped up when I restarted again, and went to Device Manager. There I found a device, I think it might have been a yellow ? under "Unknown devices", but the description was 3Com 10/100 Mini PCI controller.
  8. I hit properties button for that device and selected the Reinstall driver button. I then proceeded again to try to re-install the driver. Winodws had me reboot.
  9. The device still didn't work, but at least then it was showing up as a 3Com 10/100 Mini PCI, and it was under the Network Adapters section. A dialog box when I started the system said the device wasn't working, and in Device Manager I learned that the device wasn't present or I needed to Re-install.
  10. After powering off the system and rebooting, hoping that would fix things but having that have no effect, I went to the item and clicked "Update driver". When Windows searched, it told me the best driver was already installed, but I had it Display locations and I manually picked the driver. I was told basically the driver didn't match the hardware (actually meaning the driver didn't match the hardware that the non-working driver was installed for.)
  11. When I rebooted, I noticed Windows saying it was updating some files. (A positive sign, I think.) After I was done rebooting the device manager showed me a network device with no name, and no drivers. It was using IRQ10, which the 3Com was supposed to. 3Com was a yellow ? in unknown devices section (called 3Com, though). Removing the dummy network card had me reboot.
  12. At this point of time, I started thinking I was repeating things, but things worked soon. When the system rebooted, I had it display drivers at a location and I attempted again to reinstall. When I rebooted again, in device manager I went to the yellow ? 3Com device and re-installed/updated driver. When I rebooted, the device worked fine.
Some of that may seem redundant, with multiple steps of instalilng the driver, and multiple reboots.
Cirrus Logic
Cirrus Logic's Generic Ethernet Drivers for Windows 98 (Initial Release) is distributed as a disk image that supports “ CS8900/CS8920 for Windows 3.11, 95, 98, NT, and 2000; Novell; MS Lan Manager; Packet Driver; and setup utility.” The web page for these drivers notes, “These generic drivers may have been modified by the electronics manufacturer to suit a particular product. We recommend that you contact your product's manufacturer for support.” (Cirrus Logic Network Drivers locally mirrored in the cirlgnet/clgcnet9.zip file.)