Novell Netware 3.11
Christopher
On what is becoming a running theme here on SoylentNews, we're reliving the early 90s, and picking up right where I left off from Windows for Workgroups, it was time to look at the 800-pound gorilla: Novell NetWare.
Unlike early Mac, UNIX and Windows, I didn't actually have any personal experience with NetWare back in the day. Instead, my hands were first guided on a stream of my weekly show, HACK-ALT-NCOMMANDER, hosted as part of DEFCON 201, combined with a binge reading marathon of some very hefty manuals. In that vein, this is more of my impressions of what NetWare user and administration is like, especially compared to the tools of the day.
In the simplest terms possible, NetWare was a dedicated network operating system. It was designed around fast and reliable network operations at the expense of almost everything else. Novell had invested massive amounts of research in figuring out how to do fast I/O and minimizing any delays from hardware related sources. The end result was a very lean system that remained stable and performant with a large number of clients attached. As networking was Novell's bread and butter, NetWare had excellent support for everything: clients were available for DOS, Windows, UNIX, Macintosh, OS/2 and probably other platforms I've never even heard of.
The early history of NetWare is very muddled, and pre-2.0 versions have been lost to time. This compounded with poor documentation has made it very difficult to trace the early history of the product. However, while NetWare was not the first (or only) network product for IBM PCs, it quickly became the largest, displacing IBM's PC Network, and laughed at Microsoft's LAN Manager, and IBM OS/2 LAN Server.
While NetWare did compete on UNIX, Sun had already gotten their foot in the door by porting NFS and making it the de-facto solution for all UNIXs of the era, as well as Linux. Meanwhile, Apple held onto AppleTalk which itself survived well into the early 2000s when NetWare had already disappeared into the aether. The explosion of Wintel PCs throughout the 90s had given NetWare a market position that should have been very difficult to dislodge.
The full story of NetWare's fall from grace is a story for another time, but I do want to go into the more technical aspects that were both the boon and bane of NetWare. Much of NetWare's success can be attributed to its own IPX protocol which made networking plug and play and drastically lowered latencies compared to NetBIOS or even TCP/IP.
While NetWare itself doesn't pre-date TCP/IP, like many products of the era it used its own routing protocol known as IPX. IPX wasn't specific to NetWare, and for those of us who remember early LAN parties, IPX powered many Doom, Duke Nukem 3D, and StarCraft multiplayer matches. IPX itself isn't, conceptually, that different from TCP/IP. Each host is given a 32-bit network identifier and a 48-bit host identifier. In absence of a router, link-local networking was available through the pseudo-zero-net.
In truth, IPX actually resembles IPv6 much more than IPv4. I wouldn't be surprised if a lot of IPv6's design decisions were modeled around IPX, such as the fact IPv6 uses a 48-bit network prefix, a 16-bit subnet prefix, and a 64-bit host network adapter. Furthermore, unlike IPv4, IPX is entirely self-configuring, and routing information is broadcast as needed (once again, similar to IPv6's Stateless Address Autoconfiguration (SLAAC). There's no direct equivalent of DHCP for IPX.
That's not to say IPX is perfect. One major pain point is that IPX comes in four different variants, raw, LLC, SNAP, and what Novell calls ETHERNET_II. This is due to the fact that IPX was used heavily on non-Ethernet networks; the protocol itself can change depending on what physical hardware it's running on. For example, it's not possible to use Ethernet frame routing over Token Ring networks. All four variants are incompatible with each other and a misconfiguration means hosts will not see each other on the network. This is in contrast to TCP/IP which was specifically designed to be independent of the network layers below it.
I disagree with the contention that Novell's slow adoption of TCP/IP was part of the reason why they fell into irrelevance. TCP/IP has unfortunate characteristics when dealing with non-switched networks which made it undesirable for LAN usage. TCP/IP has built-in rate limiting designed to handle packet loss issues; the idea is that if packets are being lost in flight, the link is saturated and the sender must slow down. This is part of the TCP/IP specification.
On packet-switched networks and fixed links that made up ARPANET, this was a desirable property. Token Ring and ARCnet also provided full switching for local offices. However, while ARCnet managed to carve a niche in SCADA systems, Token Ring priced itself out of the market and was already vanishing in favor of Ethernet. This lead to a rather unfortunate mess. At the time, thicknet 10BASE2 and Ethernet hubs dominated the low-cost market. Up until switched Ethernet and 10BASET became commonplace, packet collisions were common. This combined with TCP/IP rate limiting meant that TCP/IP would run much slower than it otherwise would.
In contrast, AppleTalk survived well into the mid-2000s before it was given the "Old Yeller" treatment and DECnet is still commonly used with OpenVMS. While supporting multiple Layer 3 routing protocols can be an additional burden, it's not a show stopper. The problem is that IPX was the one real killer feature of NetWare, and without it, NetWare was simply more expensive, and difficult to administer.
One of NetWare's notable features is that it's one of the few products that actually took advantage of the 286's protected mode and got actual speed and usability improvements out of it without concern for legacy backwards compatibility. The catch was that Novell took the protected part of protected mode out to do so.
To prevent this article from becoming yet another rant about the 286, I'm going to summarize what ring 0 means. In modern operating systems, user applications are separated from the low-level guts of the operating system's core code, or OS kernel. On the 8086, no such separation existed, and all programs have full and unrestricted access to hardware and memory. On the 286 and later, Intel added the concept of rings, which divide applications in groups. The kernel exists in ring 0, and user applications are in ring 3. Rings 1-2 were rarely used (with OS/2 being the one notable exception) to provide finer control.
Aside: Rings were informally scrapped with 64-bit architectures. While they still "exist" in the GDT Global Descriptor Table, the removal of segmentation and the addition of SYSENTER means that only ring 0 and 3 can be used in practice.
I'm going to gloss over the details here, but the very short version is that there are two ways to switch rings in protected mode: call gates and interrupt vectors. Both cause a context switch and have a fairly high-performance penalty associated with it. Novell's solution was instead to just not bother. All code within a NetWare server ran in Ring 0, and essentially ignored any security and reliability features offered by the processor.
Both drivers and add-on software took the form of NetWare Loadable Modules, or NLMs. These are effectively kernel modules that can be dynamically loaded and unloaded. To further aid performance, cooperative multitasking was used to prevent delays inherent in modern-day pre-emptive multitasking. That meant a misbehaving app could not only lock a NetWare server up, it could also trash the hardware on the way out.
If this is sounding like a nightmare, it's not quite as bad as it sounds. Novell's engineers were quite good at their job, and I was very impressed at the performance and stability of NetWare's file and print servers. The problem was that, for reasons that will become clear, it wasn't uncommon to have a fair number of add-on NLMs to ease system administration or provide services like BTrieve SQL server. One bug in these NLMs could ABEND a server, or simply cause a deadlock.
Later versions of NetWare did provide some isolation for misbehaving NLMs, but the system as a whole remained cooperatively multitasked. This is in stark contrast to Windows NT where a misbehaving application wouldn't bring the system crashing down.
NetWare 3.12 was contemporary with Windows NT 3.1 as well as Windows for Workgroups. While version 4 had also shipped at this time and introduced Novell's Directory Service, I felt 3.12 would capture NetWare at its zenith before Windows NT would eat its lunch. At a minimum, it would represent the mountain Microsoft would have to scale to compete.
3.12 was available both as a set of both floppy disks and in CD-ROM form. The first disk, System_1 was also personalized to show your license of NetWare, and the disks are bootable, loading up DR-DOS 5 without issue. NetWare's first real quirk comes from the fact that it needs DOS as a bootloader. Early versions could either replace DOS in a dedicated fashion with a cold boot loader or co-exist with both running side by side. NetWare 3 and later instead used DOS as a bootloader, and had limited access to DOS devices. In what is becoming a now-familiar sentence, MS-DOS 6 was installed to a 32 MiB partition, with the rest of the 4 GiB drive set aside for NetWare.
After providing the System_1 disk, SETUP kicks off NetWare, and drops you at the server console after offering to modify AUTOEXEC.BAT to automatically start NetWare server. At this point, installation continues from within NetWare itself.
The first step is loading a device driver for the hard disks. The installation manual (and media) comes with an extremely large set of drivers, including ones for Microchannel, and EDSI Enhanced Small Disk Interface) disks, technologies that have long disappeared. In this case, LOAD ISADRIVE is the correct driver as it's used for AT-compatible hard drives. The next step is then finding a way to load the NetWare system files. LOAD is NetWare's command for installing a NetWare Loadable Module, so it's used for both drivers and applications.
c80f0f1006