NetWare Pure IP on DOS

It is fair to say that Novell struggled with moving from the IPX protocol to TCP/IP. Of course a big part of the problem was that IPX worked extremely well on LANs and IP brought absolutely no advantages for basic file sharing, only additional complexity. Specifically in DOS environments, a major disadvantage of TCP/IP was that it is far more complex to implement and therefore consumes significantly more memory.

But in many corporate and government networks, there was a strong push towards TCP/IP from the early 1990s, greatly accelerating in the mid-1990s when the Internet started becoming popular and very soon, indispensable. TCP/IP support became a requirement which Novell (or Microsoft for that matter) could not stop. And once TCP/IP had a foot in the door, there was understandable pressure to get rid of other protocols.

Novell’s first serious attempt at a solution was NetWare/IP (1993), or NWIP for short. NWIP was an add-on product for NetWare 3.x and later came bundled with NetWare 4.x. The trouble with NWIP was that it was relatively difficult to set up and manage, and heavily relied on DNS.

With NetWare 5.0 (1998), Novell implemented a different solution, often called Pure IP. The design of Pure IP was closer to IPX and used SLP (Service Location Protocol) to let clients automatically find the nearest server, just like classic NetWare did. Clients still needed some way to configure their IP address but by then, DHCP was widespread and unlike NetWare/IP, Pure IP did not need any special DHCP options.

When Novell ported their networking services to Linux in OES, Pure IP was the only option. While “proper” NetWare offered IPX support until the end, OES never did and Pure IP was the only game in town.

SUSE Linux based Novell OES2 server (2005)

Note that Linux did support IPX in the past, and there were IPX-based NetWare clients and even servers.

For migrating existing IPX and NetWare/IP networks to Pure IP, Novell offered IPX Compatibility Mode Driver (CMD) which acted as a bridge between IPX and Pure IP networks. Of course CMD required NetWare and did not run on Linux-based OES.

DOS and Pure IP

In times of NetWare 5.x (initially released in 1998), DOS (and Windows 3.1) was still a supported client. Novell did more or less support Pure IP in DOS, but only with the final NLM-based Client32. Older VLM-based clients cannot support Pure IP at all (but can work with NetWare/IP).

Since Pure IP was new and DOS was at the tail end of support, Pure IP in DOS is a little iffy (while IPX works in Client32 without issues). Notably TRANNTA.NLM must be version 1.12 (May 1999), while the 1.11 (October 1998) version from the NetWare 5 client for some reason cannot seem to find Pure IP servers.

With the slightly updated DOS Client32, I was able to connect to a NetWare 5.0 (1998) server using Pure IP. However, I still had no luck connecting to an OES2 server (2005). The servers should be compatible but something was going wrong. I have a suspicion that the issue was with the SLP implementation–while NetWare uses Novell’s own, OES2 uses OpenSLP which is part of SUSE Linux, and it behaves a slightly differently.

But then I kept poking around and found out that although DOS Client32 support officially ended in 2002, the core of the client lived on for much longer in the form of the SRVINST2.EXE package.

This was a bootable DOS disk suitable for installing NetWare servers over the network. It was supported until the end of NetWare 6.5. A support article regarding SRVINST2.EXE was created as late as 2006. To my surprise, the disk created by SRVINST2.EXE had no trouble connecting to my OES2 server.

It appears that the trick is that it’s using a newer CLIENT32.NLM than the one shipped with the DOS client. Note that the client must also have SRVLOC.NLM loaded in order to find the server.

From DOS to Linux-based OES2

Conveniently, OES2 still comes with the DOS-based LOGIN.EXE and MAP.EXE utilities. Therefore the DOS client can automatically attach drive F: to the server’s SYS:\LOGIN directory and from there, login and map the server’s usual PUBLIC directory.

For reference, the modules loaded after the NIC driver (with FRAME=ETHERNET_II of course), with version numbers of known working components included, are:

  • TCPIP.NLM (v1.01 981026)
  • TRANNTA.NLM (1.12 990511)
  • SRVLOC.NLM (1.17 980723)
  • CLIENT32.NLM (3.03 001018)

The relevant NET.CFG section is:

Protocol TCPIP
IF_CONFIGURATION DHCP LAN_NET
PATH TCP_CFG C:\NOVELL\CLIENT32\TCP
BIND MY_NIC_DRIVER

The network must provide a DHCP server, but any old DHCP will do. Unlike NetWare/IP, no special DHCP options are needed, nor are additional infrastructure servers, although of course OES must run the SLP service, or be registered with an SLP server.

And after going through all this trouble… is it any good? Well, maybe. It does appear to work, but of course Client32 requires a relatively modern machine to be useful. It consumes very little conventional memory, but requires at least a 386 system—it is called Client32 for a reason and won’t work on a 286 or earlier.

Note that the DOS-based Client32 shares its core with the Win9x-based Client32. For example the Win9x client comes with a handy SLPINFO.BAT utility that can be used to diagnose problems with SLP. The DOS client does not come with SLPINFO.BAT, but SLPINFO.BAT from the Win9x client works just fine in DOS.

SLPINFO from Win9x Client32 running on DOS

For classic DOS networking, IPX can’t be beat–it runs on an 8088, it can run on very old DOS version, it uses only a small amount of memory. But running a relatively modern OES Linux has its advantages, and being able to connect to it from DOS may be handy.

NetBIOS Over TCP/IP

It is instructive to compare NetWare with its biggest competitor, Microsoft and IBM SMB networking based on NetBIOS. For reasons that may be an accident of history, NetBIOS over TCP/IP (NBTCP) was standardized very early, with RFC 1001/1002 being published in March 1987. That was before LAN Manager 1.0, before OS/2, before IBM even considered it worthwhile to support Ethernet.

Thanks to the layered implementation, it was possible to implement NetBIOS over TCP/IP as an add-on for both DOS and OS/2 clients. By 1992, Microsoft LAN Manager servers and clients came with bundled NetBIOS over TCP/IP support. IBM sold TCP/IP separately but NetBIOS over TCP/IP kits were also available. Windows NT (1993) came with NBTCP support built in from the very beginning, and so did Windows 95.

To put it in context, NetBIOS for TCP/IP is old enough that Microsoft and IBM shipped their own implementations for OS/2 1.x, whereas NetWare/IP appeared after NetWare 4.0. Pure IP appeared at about the same time as Windows 98—years after Windows 95 and NT 4.0.

Because NetBIOS over TCP/IP was defined by RFCs, third parties (for example Excelan or HP) offered support even earlier–obviously the RFCs were not published in a vacuum and several implementations existed in the late 1980s.

All this meant that by the time the Internet became important in the mid-1990s, NetBIOS over TCP/IP was already well established, with good support from Microsoft, IBM, and others. Although NBTCP could use relatively complex infrastructure, it didn’t have to, and switching existing servers and clients from the NetBIOS Frames (NBF) protocol to NBTCP was generally not complicated.

By the time Novell came up with Pure IP, NetBIOS over TCP/IP had been around for a decade. That made switching to TCP/IP vastly easier in the Microsoft/IBM networking world. For example, Microsoft’s 1995 DOS network client continued working with future Windows servers for many years to come, whereas Novell’s 1995 clients have no idea about Pure IP whatsoever.

This entry was posted in DOS, NetWare, Networking. Bookmark the permalink.

6 Responses to NetWare Pure IP on DOS

  1. Chris M. says:

    Interesting that NetWare had the same service discovery “struggle” that Apple did with AFP-over-TCP. The original AppleShare IP clients, like Novell, relied on SLP for service discovery if the network wasn’t running “dual stack”. Thing is, SLP discovery didn’t work with Chooser in the same “it just works” fashion that AppleTalk NBP (or NetBIOS) did. Which is very “un-Apple”.

    Most companies stuck with running AppleTalk side-by-side with TCP/IP for this reason (much to sysadmins distaste)…. that and all the old LaserWriters that only supported the older protocol. Its too bad that mDNS took so long to become available as it finally solved all these issues.

  2. Michal Necasek says:

    It’s like in the rush to switch to TCP/IP, nobody thought too hard about how to replicate the incredibly useful ability of older LAN protocols to function with zero configuration and automatic discovery. As if that didn’t count for anything. There were so many efforts to implement something like it on top of TCP/IP that it’s not even funny. The mDNS RFC is from 2013 — only about 20 years too late.

    I think it’s fair to say that in a small office or home LAN environment, forcing everything onto TCP/IP solved zero problems but added quite a few.

  3. John Doe says:

    The thing is by 1994 or so the Internet was really happening and making TCP the primary protocol and ensuring that network clients were running an IP stack simplified deploying ftp ,terminal emulators, and web browsers.

    Trying to get home users to configure things like Trumpet, or pick your favorite DOS packet driver suite was a huge pain, it was not much better for small remote offices where the Enterprise did not have local IT people, often it was just cross ship PCs as practical matter, to get the software configured. If by small office you mean small business you are probably right but Enterprises that had a lot of small offices had lots incentives to move to IP.

    Whatever value was lost in easy peer-to-peer file sharing, and printer discovery, was more then gained in knowing you could send out a disk with the latest Lotus Notes and tell people they could just click the the install, and start it up. Same thing for getting people connected to all the legacy host systems. All those 3270 terminals in the shared office suite could go away and get replaced with IRMA or other popular terminal emulators on every desk, but again you needed all the clients on IP for that to work.

  4. Michal Necasek says:

    Yes, what I had in mind was a small company with ~20 employees and a single office. They still wanted the Internet but beyond that, TCP/IP didn’t really solve anything.

  5. Eric Robinson says:

    What I remember is that Novell implemented Directory Services in 4.0 with NDS I want to say in 1994 or 1995, anyway before Microsoft introduced AD in 2000. Which kind of explains its dependency on DNS, being possibly the most efficient way to navigate LDAP structures.

    I thought Novell was still leading the market until about 1999, but the Internet bubble didn’t help. I do remember encapsulating IP Packets in an IPX header back in the 3.X days because very few companies had internal IP networks and IPX while chatty was routable. They did implement a real IP stack in Netware 5.1 but it was too late by then, plus they already ported NetWare over to Linux.

    Lots of large companies used IPX/SPX for multiple locations, like I said it was chatty but in the early and mid 1990s no one was using the Internet as much. You needed something just go to the companies Bulletin Board Site if you had the number and later their FTP site.

    I don’t think it was the internet that hurt Novell, but more so Databases and their need for a platform agnostic protocol, NetBIOS sure wasn’t it. I think Microsoft was a better fit for TCP/IP because it didn’t have a routable protocol of its own.

    But hey, don’t try to take anything away from my one true ClientServer NOS unlike those other Peer-2-Peer guys. lol

    As far as OES and SuSE Linux it’s still around and doing fine now under the umbrella of OpenText and yes NSS Volumes still exist.

  6. Michal Necasek says:

    NDS came with NetWare 4.0 in 1993, but I don’t think NW 4.x was really used much before 1994-1995. Years before AD in any case.

    NetWare actually had a TCP/IP stack built in since version 3.11 (1991) but it was initially only used for add-ons like SNMP and NFS (both NetWare running as an NFS server or NetWare acting as an NFS gateway). Then came NetWare/IP, IP tunneling, and a couple of other tries. Pure IP only showed up after Microsoft already won.

    You’re right that IPX was routable, and networking gear of the day could deal with it, plus Novell had their own MPR aka Multi-Protocol Router. Microsoft was in a better position since NetBIOS over TCP/IP existed before Internet became a thing, so for them going all TCP/IP was easy and built in since NT 3.1 and Windows 95. Whereas Novell initially tried to charge a lot of money for NetWare/IP and such.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.