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.
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.
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.
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.



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.