Stories
Slash Boxes
Comments

SoylentNews is people

posted by NCommander on Monday June 01 2020, @10:53AM   Printer-friendly
from the causing-thousand-yard-stares-while-ABENDing-all-the-way dept.

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.

Ultimately, I found NetWare a very strange experience, and there were a lot of pluses and minuses to cover, so as usual, here's the tl;dr video summary, followed by more in-depth write-up.

Novell NetWare video

If you haven't ABENDed your copy of server.exe, click below the fold to learn what all the hubbub was about!

The Network Operating System

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.

Internetwork Packet eXchage (IPX)

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.

NetWare servers — as well as most vintage networking equipment — also natively supported IPX routing which was essentially a plug and play affair.

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.

Despite this and compared to TCP/IP, IPX was a breeze to setup and administrate. Neither DHCP nor RFC1918 address spaces (that is 192.168.0.0/16, 10.0.0.0/8 and 172.16.0.0/20) existed at the time. That meant for proper TCP/IP deployment, an allocation had to be requested from your local Regional Internet Registry such as ARIN. Adding salt in the wound, TCP/IP was still classful at the time, meaning network blocks were only available in /8, /16, and /24 sizes.

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.

Certain design decisions within NetWare would also make it an evolutionary dead end.

Ring 0 and NLMs

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.

Intel Processor Rings

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.

What this meant in practice is that NetWare had best the performance possible from a 32-bit processor combined with the stability and reliability of Windows 3.1.

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.

NOTE: Since it came up in the previous article, I did attach a debugger to NetWare and dump the processor's GDT, you can see there are no Ring 3 segments:

VBoxDbg> dg
0000 DataRW Bas=00000000 Lim=fffff000 DPL=0 P NA G BIG AVL=0 L=0
0008 CodeER Bas=00000000 Lim=00fff000 DPL=0 P A G BIG AVL=0 L=0
0010 DataRW Bas=00000000 Lim=00fff000 DPL=0 P A G BIG AVL=0 L=0
0018 CodeER Bas=0001b9e0 Lim=0000ffff DPL=0 P A AVL=0 L=0
0020 DataRW Bas=0001b9e0 Lim=0000ffff DPL=0 P A AVL=0 L=0
0028 VERR_INVALID_SELECTOR
VBoxDbg> 

LOAD INSTALL

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.

As I had no desire to feed a large number of floppy disks, OAKCDROM.SYS was added to DOS, and installation was kicked off from the CD.

OAKCDROM.SYS

The initial installation is very bare bones, with the only network-related question coming in the form of selecting the server name and internal IPX network number

IPX SETUP

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.

NetWare Console

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.

The easiest option (and what I went with) was simply letting NetWare use the CD-ROM driver in DOS. This doesn't require any configuration: NetWare itself loads above the 1 MiB memory line, and DOS itself is still resident in conventional memory including any device drivers loaded. Other options include: LOAD CDROM, loading the files via network, or loading from a DOS partition.

LOAD INSTALL takes over from here, and is one of the few graphical applications on the server console. Partitioning is straight forward, and RAID can also be configured. Unlike DOS, NetWare is relatively happy with larger disks, however the ISADISK driver refused to touch a hard drive larger than 4 GiB, which isn't uncommon for the era.

Disk Partitioning

After the partition is mounted, volumes must be created. This is conceptually similar to BSD disklabels, or LVM logical partitions. The main NetWare partition is SYS: which holds the core system files, and is also the default directory for user home folders. One quirk I ran into was that volumes are not automatically mounted upon creation, but this was otherwise straightforward.

MOUNT SYS

Finally, the installation is finished with "Copy Public and System Files". This option isn't actually specific to NetWare's installation as both add-on software and patches could use this mechanism. Typing in "d:\netware.312\server" set NetWare away from copying files from the CD. It should be noted this process was abnormally slow and took several minutes running in a VM to complete. This is likely due to the fact that NetWare must suspend itself, load data from DOS through OAKCDROM, re-enter protected mode, and then continue.

NOTE: I briefly looked with VirtualBox's debugger to see how this worked. The very poor speed made me wonder if they were doing some sort of software trickery like running DOS on OS/2 on a 286, or using Virtual 8086 mode. My guess is the former; VirtualBox says that no Task Select Segment is loaded, likely due to no ring 3 code, although I can't definitively say this isn't using Virtual 8086 mode somewhere.

FILE INSTALLATION

Once file copying was finally finished, the last ugly truth comes up. Administrating NetWare is impossible without a second machine, and this also applied to the patching process. This is especially egregious as older "Nondedicated" versions of NetWare could run the DOS based administration tools on the same machine. That meant the network had to come up to continue.

A PCNet Experience

NetWare's support for NICs, as you may expect, is excellent with support for Token Ring, ARCnet, and many Ethernet adapters. Novell also had their own line of network cards, the NE1000 and NE2000 which were so successful that the NE2000 became a de facto standard for 16-bit computers. VirtualBox also has the ability to emulate an ISA-based NIC via a poorly-documented advanced option, but I opted to go with the more standard PCI AMD PCNet device offered in the GUI.

Having been burned with unstable NE2K emulation under QEMU, I really didn't want to risk having undocumented IRQ conflicts, so this was the path of least resistance. AMD did publish loadable drivers for NetWare 4. However, the ODI33G patch can allow these to be used under NetWare 3.12. Driver installation was slightly odd and in hindsight, foreshadowed the lengthy patching process.

The first step was simply returning to DOS. This is done by DOWN and followed by EXIT. ODI33G was first installed. This took the form of a self-extracting ARJ archive, and files from that archive must replace basic files in the C:\server.312. It's pretty clear that unless a system administrator was diligent, it would be exceptionally easy to accidentally downgrade server components during an "upgrade".

Following that, the PCNTNW driver was loaded across and NetWare restarted. Then came the more difficult process of configuring the network. NetWare is controlled by two main startup files: STARTUP.NCF, and AUTOEXEC.NCF. STARTUP is used for any "early initialization" steps (such as in my case LOAD ISADISK) and is executed immediately during the DOS startup phase. AUTOEXEC.NCF meanwhile is loaded when the system is fully up and running. It's here where networking is configured.

AUTOEXEC.NCF

The first two lines of the file were added during server installation and set the server name and loopback IPX network number. Below that, I needed to load the msm31x, or the "Media Support Module" as it's called in the documentation. Then I could load the PCNTNW driver. Both these drivers exist on the DOS partition, and DOS-style file paths are used to access them. The next step is binding.

Although Novell primarily used IPX protocols for file sharing and printing, NetWare did support others; specifically TCP/IP was included in this version, as well as RPL for netbooting in the pre-PXE era. Add-on software also provided support for AppleTalk and even NFS based file sharing. Network protocols are attached to interface cards via "BIND". In that case, the frame type and network number must also be entered. Restarting NetWare showed that the PCNTNW driver was loaded and initialized. Further, Wireshark was showing IPX traffic over the network!

NetWare booted with drivers

At this point, we can LOAD MONITOR, and bring up the most common screenshot seen of NetWare systems (shown below). Next, it was time to jump into the pit of the NetWare Requester for DOS.

LOAD MONITOR

As an aside, there is one more step to installation that I've omitted. NetWare did support UNIX, Mac, and OS/2 clients. Each of these systems had add-in support modules that had to be loaded server-side. For example, Macintosh requires support for storing resource and data forks, while OS/2 could use long filename and extended attribute bits. For this article (and video), I didn't bother installing these as I'm only going to use DOS-based clients. If we re-visit NetWare, I'll document the experience then.

NWClient Install

I'd like to say that compared to the server setup experience, the client was better. It wasn't, although this wasn't entirely Novell's fault. Included with the server discs are two client installers, one for both DOS and Windows 3.1, and the other for OS/2 with NWClient 3.12. Our client machine got the DOS 6 treatment followed by Windows 3.1 (not Windows for Workgroups) with a dash of OAKCDROM for seasoning. Once again, there was a long list of drivers, and frustratingly, no AMD PCNet PCI card one. More annoyingly, I have a PCNet driver from AMD but the driver disk wasn't recognized by NWClient.

The files I have from AMD don't indicate a version number, but the example net.cfg suggests that this driver was for a 16-bit NetWare 4 client. One interesting design choice of these older NetWare ODI clients is that they're extremely modular in nature and have exceptionally low memory requirements. ODI is a fairly lengthy topic in and of itself, but the short story is that instead of one giant monolithic blob, each part of the network stack was separated into add-on layers. It is very reminiscent of the Winsock API and I wouldn't be surprised if some Winsock aspects were modeled around it.

Since ODI was supported for a long time, relatively stable, and — most importantly — highly modular, there was a decent chance I could get this to work.

On the AMD disk I had was a replacement LSL (Link Support Layer) module, and a startnet.bat which would load the basic drivers just fine. As I found out later, if I ran startnet.bat from the disk, NWClient's installer would see it, and write net.cfg for me properly. Instead, I ultimately ended up monkeying for about half an hour before finding the right set of client switches and options, and AUTOEXEC.BAT lines to let this work.

Wireshark saw IPX announce and NCP handshakes go which told me I was going in the right direction, but I got slightly stumped. There were no client utilities on the disk and I knew from the documentation that I was looking for LOGIN.EXE. What actually happens is a little more interesting.

fileman nwclient

NetWare servers announce their presence on the network via Service Announcement Protocols or SAP, which include their network number. The client can then use that information to determine the closest NetWare server and use that to access the SYS:LOGIN share which has LOGIN.EXE. As it turned out, the moment I got the network client running, NetWare announced its IPX address, and SYS:LOGIN was silently mounted to F:

This is part of the plug and play nature of IPX, but was also something of a double-edged sword. On the upside, patches to NetWare client software automatically got delivered to users as most of the brains were on the NetWare server — not the client. The first downside though is as far as I can tell, there's no way to force the client requester to go to a specific NetWare server. I'm also not entirely sure how this mechanism worked with OS/2. There is a LOGIN/OS2 folder with its own version of LOGIN, and reading suggests THAT folder gets mounted to F: instead of the general public one.

This likely wasn't a big deal in NetWare 2.x and 3.x, but I can see a potential for problems in NetWare 4 which replaced bindery with NDS. This was also a problem for netbooting clients as NetWare RPL looks for SYS:PUBLIC to find NET$OS.SYS. The documentation has a fairly large section documenting nearest server and how to reconfigure NetWare, but is maddeningly vague on detailing the behavior.

Regardless, with LOGIN.EXE found, I could login as SUPERVISOR, and enter a world of hurt and MAP SYS:

One final bit I found humorous though, was that as with most DOS software, NWClient offers to backup AUTOEXEC.BAT before modifying it. The original version is written as AUTOEXEC.BNW, which either stands for "Before NetWare", or "Brave New World". I like to think it's the latter and I am John trying to relate to a society that no longer exists.

LOGIN SUPERVISOR

With our entry into the new world and its strange utilities, it was now time to get NetWare to learn the fact that we can no longer party like it's 1999.

The Bumpy Road to Y2K Compliance

Up to this point I've glossed over why I needed a client system to patch the server. The simple reason is that NetWare doesn't have any tools to manipulate files on its own NetWare FileSystem (NWFS) partitions. Aside from the EDIT NLM, the disk might as well not exist as far as the server console is concerned. A large number of add-on NLMs were available to fix this, but Novell didn't support these out of the box. NetWare's own documentation specifically states that patch files needed to be loaded to SYS: from a client partition.

Supposedly, it is possible to load NLMs from the DOS boot partition, but I couldn't get this to work properly. Another option would have been to use Copy System and Public from INSTALL, but for the sake of not "rat holing" myself, I stayed with what Novell's READMEs said to do. Not that they were super helpful. What I had was a large number of patch files, and no clear order to install. For example, the LIBC upgrade said that it should only be used with some patch revisions and not others.

Ultimately (through some trial and error) I discovered that to fix the Y2K problems I was having on the server, I needed the base PTD312 patch, followed by the Y2K patch. The other patch files handled bug fixes in CDROM.NLM and Printer Services, which I skipped as I didn't need either of them. Compounding the pain is that NetWare patches have no uniform installation process. Some simply replace files, others include a PATCH NLM, and some require going into DOS on the server to perform surgery.

Starting with PTD312, the patch directory was extracted from its archive and XCOPY-ed to the SYS partition. Then I needed to LOAD PATCH312 on the console which updated and installed all the necessary bits.

PTD312.NLM

The Y2K patch was much messier. Instead of having an installation NLM, the replacement patches were copied to SYS, and then the server restarted. However, the date still came up as 1920. Careful reading made me realize I skipped a step.

NetWare's kernel exists in the form of server.exe, and consists of both a loader and the NetWare kernel wrapped together. The Y2K patch requires the loader component to be replaced. To actually do this, I had to copy the replacement LOADER.EXE to a floppy disk and then use the Loader SWAP (LSWAP) utility to write a new server.exe. Having climbed the mountain, NetWare finally recognized what century we're in.

LSWAP

2020 boot date

Sad to say, this was far more painful than it really needed to be. That also would prove to be a wonderful foreshadowing of what the NetWare experience was actually like.

The User Experience

Things continued to go downhill. By default, the rest of NetWare's management utilities are mounted to the Z:\PUBLIC drive. Notably, this isn't added to the PATH so you need to switch to that directory manually if no additional setup is done. File sharing can be managed either through the command line's MAP and ATTACH utilities or through the graphical SESSION NWClient for Windows. SESSION suffers from poor user experience. NetWare is rather consistent in the fact that its user interfaces are extremely inconsistent. For example, the UI doesn't note that the insert and delete keys are used to add new mount points. Furthermore, NetWare presents no graphical viewer for shares or available. Instead, a user must write a path like SERVER_NAME\VOLUME:PATH_TO_DIR.

SESSION

To actually find mountable directories, NDIR and FILER are available. FILER is both a user and administrative tool as it's the only graphical interface that allows for easy viewing of access permissions and browsing of remote servers. One can't, however, actually mount or attach drives directly with FILER. On the other hand, FILER could also be used to view and manage Macintosh and UNIX files.

FILER

Once a directory is mapped to a drive letter, it works like any normal DOS share. The performance was excellent and I didn't have any stutters or stalls as I did with Windows for Workgroups. This is likely due to the low overhead of IPX and the Network Control Protocol that NetWare uses for file management. Printers are manageable through the PCONSOLE command and are mapped to local LPT ports.

In theory, most of the terribleness of these utilities was supposed to be mitigated by the fact that the network administrator can set login scripts to automatically setup drive mappings. In theory, you'd simply LOGIN and go. Login scripts are marred, however, by the fact that they execute as part of LOGIN and not "in the context of COMMAND.COM, which means that they're limited to whatever functionality Novell provided.

While that may or may not have been the case, Novell was seemingly aware how bad this situation actually was and a Windows 3.1 application for share management was provided in the box. Unfortunately, I'm not actually sure I can call it an 'improvement'.

NWClient Windows

The first stumbling block is that logging in to and out of the NetWare server is not directly possible in the NWClient/Windows. You're expected to do so from DOS, and I only saw login prompts show up during resuming drive shares. That of course leads us into the second problem. The Windows client has the ability to make shares "permanent" which automatically connects and disconnects to them. However this functionality is entirely disconnected from NetWare logins. Instead, NetWare simply assumes your computer has one user and it was trivial to make NetWare try to mount folders I didn't have permissions for.

Resuming Connections

This is exceptionally ugly. Although Windows for Workgroups 3.11 had no real concept of a user, permanent shares were still stored independently through a pseudo-login prompt shown at startup. This also remained true through the 9x series of Windows. Then there is the very strong disconnect between the DOS and Windows worlds going on which is a bit harder to explain.

Back in the Windows 3.1 days, it wasn't uncommon to switch back and forth from Windows to DOS. While DOS applications could be run within Windows, it was also common to use programs like WordPerfect from DOS. This is especially important because a lot of DOS add-on software for WordPerfect and other word processors worked in the form of TSRs which hooked the original application — that wouldn't work while Windows was open. Reference Manager for WordPerfect was one such example I specifically remember.

NetWare client for DOS essentially assumed that your network administrator would handle all the hard parts of handling network MAPs for you. NetWare for Windows meanwhile made it easy for end-users to manage this themselves. The problem is these two environments don't talk to each other. Persistent shares set in Windows are not automatically loaded on DOS startup. Instead one needs to take a trip into Windows, and then quit back to DOS to have those shares actually become available.

The practical upshot is that I can easily see a world where a user had to start Windows to simply quit to DOS. End users couldn't manage their own login scripts, so it was either use the graphical Windows client, or write your own batch shell scripts to run the necessary MAP commands. This is an utter mess to say the least and I can only assume the same held true on Mac and OS/2 clients.

The next oddity I found is that NetWare installs its own Winsock implementation. That, in and of itself, is not that unusual. As I previously mentioned, Microsoft originally left it to third-party developers to write Windows Sockets implementations before it released Shoebill as part of Windows for Workgroups 3.11. NWClient showed up as version 4, likely due to the updated NIC components I had to add for PCNTNW support. The Network control panel icon also reappears, although it just launches the configuration page from NetWare Tools for Windows.

Windows SETUP

What makes it strange is that there appears to be absolutely no support for TCP/IP here. While Windows for Workgroups didn't ship with TCP/IP, it was available as a free add-on. Other Winsock implementations I've seen such as DEC PATHWORKS included TCP/IP in addition to their own protocols. That meant NetWare Tools for Windows was inherently incompatible with the Internet. It might also be possible to install a TCP/IP add-on into the NWClient, but this wasn't available (or even confirmed to exist). Some early comments on the video said that major NetWare users had never seen the Windows client prior to Windows 95, and I can't help but think this was the reason.

This is also damning based on the fact that NetWare server 3.12 supported TCP/IP for NLMs!

To sum up, NetWare Client Tools for Windows, at least in this version, were a mess. NetWare Client 4 would improve the situation somewhat, but it should be noted that NetWare 3.12 was released 1993, and NW3.12 was very popular. Windows 3.x had been on the market for three years at this point, and Windows already had become a staple at that point. More damning is Windows for Workgroups and the Microsoft Workgroups Add-On for Windows had already been released at this point.

To sum up, the user experience was poor on DOS — and amazingly — even worse on Windows. I really don't know how Novell botched this so badly, but they did. The administration experience was as bad if not worse overall.

There's also another glaring omission to talk about: as far as I can tell, there is no support for dial-up networking in any form with NetWare. Modems were immensely popular in this era for home and mobile users. TCP/IP over dial-up eventually codified around SLIP and later PPP to handle modems, while Microsoft provided Remote Access in Windows 3.1/NT for NetBIOS and later Dial-Up Networking in 95 for PPP/SLIP, and NetBIOS. I also believe IBM offered NetBIOS with its own LAN Server product line. I can't find an equivalent technology for IPX or NetWare in general. Microsoft notably got NetBIOS to work which has no concept of routing at all! The only references I could find to modem support is relating to ACONSOLE which allows a network administrator to dial into a NetWare server.

From what shreds of documentation I can find on the subject, dial-up networking for Windows 95 did, in fact, support IPX over modems... but it assumes that it's dialing into Windows NT Remote Access Service which then routes to NetWare. If there was a first-party solution from Novell, I'm unaware of it. I also have to assume there are add-on NLMs for this, because NetWare does support serial ports so it's not like attaching a modem would be hard.

If the community knows, let me know and I'll post an update/correction. Having thoroughly thrashed NetWare's user experience, it's now time to step into the role of the World Controller, and see how Mustapha Mond managed NetWare.

The Administration Experience

If Mond is arguing against the value of free will, then as John, I can only state that Novell showed great creativity in the inconsistencies with their administration experience. Let's start with the simplest to describe: RCONSOLE

It's not exactly unheard of that NetWare servers ended up getting walled in. After all, the server console isn't exactly a useful feature post-installation. In a stunning display of usability, Novell allows network administrators to use the RCONSOLE command to remotely access the console in a 1:1 copy of the server framebuffer via the RSPX protocol. As such, walling up a server is an entirely practical means of physical security.

Configuration on the server side is relatively simple. LOAD REMOTE enables remote administration, and LOAD RSPX allows for RCONSOLE over IPX. Modem support (via ACONSOLE) and serial terminal (LOAD RS232) were also available:

LOAD REMOTE

RCONSOLE menu

At first glance, this seems somewhat useless, given what I've said about the server console before. However, a hidden menu pops up if "*" is pressed on the numeric keypad (and it has to be the numeric keypad):

RCONSOLE Start menu

Beside the option to switch servers, RCONSOLE does provide a somewhat handy mechanism to copy files. Unfortunately, this directory copy isn't recursive, which means its pretty useless for installing patch files, and while the file browser exists, you have to manually type paths to use it to just add that final bit of salt in the wound. The other main option, Copy System and Public Files we've already seen before: this was used to install some patches, add-on software, and functions essentially identically to INSTALL. The primary purpose of this function, though, is to actually fully install NetWare from a second machine as a kludge around the lack of client-side sharing options.

The real meat of NetWare system administration comes from SYSCON which is used to actually create users, groups, and manage permissions (functionality also shared with FILER).

SYSCON

It wasn't immediately obvious on how to actually add a new user however. The secret is the INSERT and DELETE keys which, again, the UI doesn't point out. User permissions and groups are much more similar to what we got in Windows NT than POSIX groups, and I'm curious if Microsoft copied NetWare in this regard or if the basic layout was due to government mandates for security.

SYSCON add users

Both system and user login scripts can be edited through SYSCON, as well as specific permission grants. Something that doesn't translate well is how clunky actually setting ACL permissions is. Instead, it's easier to look at how Novell officially recommended working out user and group permissions.

ACL Worksheets

I can only assume the conversation at Novell went something like this:

Manager 1: So we have this large massive product with amazing access control features, what tools should we give our customers to control these?

Manager 2: Well, we have the FLAG command, and maybe we could add them to SYSCON, and let you look at them in FILER. Maybe if we gave them some sorta template to work off?

Manager 1: Perfect, ship it!

I legitimately have no idea how you could easily audit permissions on a NetWare server given the total lack of scripting support and poor tooling.

I did notice this gem in the documentation, the eXecute Only flag, which acted as a form of DRM for network installation applications:

Prevents copying or backing up files. Attribute cannot be removed. Assign only to files with an .EXE or .COM extension (program files).

Keep a duplicate of these files in case they become corrupted and need to be replaced.

CAUTION: Some programs do not execute properly if flagged Execute Only.

How this actually works is unclear — files obviously have to be read to be loaded into local system memory — and I'm not sure I want to find out.

Besides SYSCON, NetWare also came with built-in utilities for printer management (PCONSOLE), creating network bootable DOS disks (DOSGEN), talking to BTreieve, and much more. Here's a list of all the programs just to give you an idea of scope.

DIR * /w

So much of this was a chore. I didn't exactly expect software of this vintage to be especially user-friendly. But, given how much Novell was charging for NetWare, I was expecting something less clunky. This is the case even before mentioning that add-on software could bring NetWare crashing down with an ABEND.

ABEND

It's rather telling that there is an entire book in the box dedicated to this topic.

The Theorical Printer Experience

As stated, I didn't test NetWare's print capability, as the only printer I have is several decades too new. I did, however, read the documentation, and I immediately spotted a problem. Printers had to be connected to a NetWare server of some form. Unlike NetBIOS, NetWare and its Network Control Protocol work in a client-server architecture instead of a peer-to-peer mode. While this is usually desirable for things like files, printers benefit from being physically accessible.

NetWare clients were that, clients. They have no inherent ability to share files or printers from the local system. The problem becomes obvious, you needed a NetWare server physically attached to the printer, or at least something that could fake it. NetWare had two separate products for peer-to-peer sharing, NetWare Lite, and Personal NetWare which both in DOS. Personal NetWare was later bundled with DR-DOS after Novell bought out Digital Research. How these integrate into an environment that has a proper NetWare server is at best unclear, especially in regards to access control lists, and the later Novell Directory Service.

I suspect I'm going to have a "Personal NetWare" experience video/article, but from what I can tell from the documentation, Personal NetWare simply showed up as a normal NetWare server on the network and didn't operate in true P2P mode. I suspect this wasn't a problem in practice as IPX SAP could easily fake true P2P connectivity.

The problem is, however, that NetWare Lite and Personal NetWare were separate retail products, and required individual licenses for each machine with serialized disks used to install it; the client won't allow it to be used if it sees the same license being used. I also know that several very high end printers such as HP's LaserJet 4 could have a network card installed and the printer shared to a NetWare network, likely appearing as an independent server. HP also offered JetDirect which had a parallel port on one end, and a network plug on the other which converted most of their printer line into network capable beasts.

I'd like to hear personal experiences about NetWare printing, because frankly, it looks pretty bad. NetWare printers are mapped to LPT ports, and DOS applications/Windows had to provide their own drivers (Windows for Workgroups also has the same problem), and I can't imagine how this could possible work with UNIX, or Macintosh clients.

I do get the sense that "Yes, it works with NetWare" was more marketing hype than actual truth. Maybe "It sorta works with NetWare if your network administrator is a god among mortals" might have been more accurate.

The Conclusions from Experience

To be perfectly frank, I'm not sure what I was expecting when I dove into NetWare. I knew about some of its technical quirks such as running in Ring 0 and cooperative multitasking, but as a whole it's an entirely different experience. NetWare's IPX protocol was its killer feature, but because internet TCP/IP required every computer in a NetWare shop to be dual-stacked, it quickly became irrelevant.

Since you already had to climb Mt. TCP/IP to get on the Internet, IPX's plug and play features stop being relevant as a sales point. Furthermore, if you had UNIX in any form — which was almost universally TCP/IP — you were in the same spot. Without it, you're left with a very expensive file and print server which wasn't really better than a DOS box at running add-on software. IPX's second major feature — good performance on non-switched networks — became less and less important as switched Ethernet became dominant and as cheaper switches could replace NetWare boxes for routing. You're also left with a product that your system administrators hate; given a lack of lock-in, they could (and did) jump ship as it became viable to do so.

Now, to Novell's credit, IPX and the base NetWare package felt rock solid, and the DOS ODI stack is incredibly small for its size. The latter I really need to emphasize, I've struggled with conventional memory with MSNet for DOS, but Novell's stack just sips memory which meant it was considerably less likely to conflict with DOS applications which were always competing for conventional memory. As for IPX, most of what it gave the world would only reappear in IPv6, and even then, the latter is nowhere as plug-and-play friendly (DHCPv6, I'm looking at you).

Novell would have stayed relevant in this space if their product hadn't stagnated for five years. NetWare 2.x was not very different from 3.x from what I can glean from its documentation in either user experience or administration. NetWare was essentially called feature complete in the late 80s, and that was that. Compounding the problem was that NetWare Directory Services was not well received and NetWare 4 initially had a stupidly high price tag compared to NetWare 3.

Windows NT 3.5 and 4.0 would prove to be a wakeup call, and Novell went on a buying spree to try and compete. DR-DOS, DESQview, WordPerfect, and NetWare Server for OS/2 couldn't stop the ship from sinking at that point. Ultimately, and what could be said as irony, Novell, who had bought UNIX from the remains of Ma Bell, with the intention to kill it ended up migrating their product line onto SuSE Linux. The final versions of NetWare either ran Linux as a NLM, or itself ran as an application under Linux.

My personal opinion is that Microsoft won this battle by having a better and cheaper product. While Microsoft did pull some underhanded moves (which eventually lead to Novell v. Microsoft over WordPerfect for Windows), the fact is I don't have a lot to recommend NetWare instead of Windows NT. NetWare might have been faster, but processor speed increases meant the network, not the CPU, quickly became the bottleneck.

In short, innovate or die ...

73 de NCommander

P.S. I fully expect to come back to NetWare as I want to try and write a definitive account of Novell's fall from grace in the 90s. That means tracking down hardware that can run NetWare 2.01 (the earliest surviving version), and either a 3C501 card and thicknet cabling (or adapters), as well as later NetWare versions, especially 6.x. I especially want to see how NDS actually compared to Active Directory as it came first. I also want to collect user experiences, so write yours below so I can share your memories as part of these articles.

P.P.S. I'm also on the lookout for Banyan VINES. VINES has a hardware dongle protection measure, and I've yet to find a complete set on eBay or similar. That being said, I think we're soon going to be touching into the history of Windows NT, as I managed to score a copy on eBay for an unboxing and exploration video.

BackOffice Server

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by NCommander on Monday June 01 2020, @05:21PM (22 children)

    by NCommander (2) Subscriber Badge <michael@casadevall.pro> on Monday June 01 2020, @05:21PM (#1001795) Homepage Journal

    Yeah, the change of MSFT of the 80s to the 90s is rather startling. MSFT learned a lot from IBM and a lot of what not to do.

    I'll still stand by my opinion that NT won this battle by being the better product, even on the basis that you could actually do something beside fileshare and not risk the server crashing. We had a lot of NT4 boxes at my first job, and the only serious downtime I remember is when our Exchange server's HW RAID crashed so hard, it took the disks with it (as best we found, the RAID controller failed in such a way it wrote bad data).

    Getting the tape backups to restore was a pain. We'd tested the backups, but never in the case of catastrophic server failure where we had to forcing remove the PDC because the Directory Store *DEMANDED* to be restored to the same box that had made the backup. A hexeditor was ultimately involved, and Exchange 2000 did make this process much less shit.

    --
    Still always moving
    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 2) by Reziac on Tuesday June 02 2020, @02:32AM (16 children)

    by Reziac (2489) on Tuesday June 02 2020, @02:32AM (#1002007) Homepage

    NT may have been a lot less arcane to use, but I'm reminded of this:

    Until somewhere after 2001 (when I stopped needing to use it regularly and stopped paying attention) the Los Angeles County Assessor's Office webserver was on NT4. After much frustration with it getting slower and slower until it approached glacial. I discovered a fix: if I'd make *and* interrupt a bunch of page requests, pretty soon it would lock up. And then when someone arrived at 8am the next morning and rebooted it, all would be well again for a few days, then it would again start clogging up. Rinse and repeat as needed to keep the thing in working order.

    --
    And there is no Alkibiades to come back and save us from ourselves.
    • (Score: 2) by RS3 on Tuesday June 02 2020, @03:51AM (10 children)

      by RS3 (6367) on Tuesday June 02 2020, @03:51AM (#1002028)

      I've had more than 1 Windows computer with some kind of similar problem (one was a very weird hard disk problem) that I just set up a scheduled task to reboot it every 2 or so days. Hack? Workaround? What else do you do when you can't really get at the problem. :)

      • (Score: 2) by Reziac on Tuesday June 02 2020, @04:18AM (9 children)

        by Reziac (2489) on Tuesday June 02 2020, @04:18AM (#1002036) Homepage

        Tee hee yes, it was a remote workaround, that's it. :D

        I've been blessed with so much the opposite in my WinBoxen, that I think any uptime less than several months is embarrassing, and have had multiple uptimes over two years. Yon XP64 box (that does duty as a file server, because it plays nice with everyone) will run indefinitely and never clogs up, even when it gets used for heavy lifting... only time it ever gets a restart is for a power outage beyond the UPS's capacity.

        Some of this is good fortune in hardware (I've even had boxes that lacked the timer bug that ultimately caused Win9x's 49-day rollover issue, and 9x would consequently run for several months) and some is good maintenance... and if it ain't broke, don't fix it.

        --
        And there is no Alkibiades to come back and save us from ourselves.
        • (Score: 2) by NCommander on Tuesday June 02 2020, @11:33AM (8 children)

          by NCommander (2) Subscriber Badge <michael@casadevall.pro> on Tuesday June 02 2020, @11:33AM (#1002132) Homepage Journal

          My personal experience is that if you stuck to the Hardware Compatibility Lists, you got a very stable system. As I said, the only real NT4 disaster was when the RAID self-destructed, and that was due to HW raid losing its mind. A lot of the trouble is dropping Windows on commodity hardware which has shit drivers.

          --
          Still always moving
          • (Score: 2) by Reziac on Tuesday June 02 2020, @04:34PM (7 children)

            by Reziac (2489) on Tuesday June 02 2020, @04:34PM (#1002215) Homepage

            When RAID commits seppuku, I doubt it much matters what the OS is... I once spent a summer rebuilding files with a hex editor, recovered from a linux server where RAID had gone berserk and randomly interleaved 'em with each other and whatever random junk was in memory.

            Yeah, that's nearly always the problem when Windows chronically misbehaves -- junk hardware and shit drivers. It's gotten a lot better, tho. Used to be if you wanted truly stable, you had to be picky about hardware and cautious about drivers. But now anything off the shelf is usually pretty good, and a BSOD means some component is going tits-up.

            People don't believe me, but on my old Tyan-based boxes, even WinME was stable (once beaten into submission; the trick was to disable the then-buggy System Restore, and run it past 98Lite; at first it couldn't even crash properly, but after this treatment it never crashed again) ...it had an uptime in excess of two years, doing all the heavy lifting... and that despite WinME having horrible resource management (but unlike Win9x, it would recover from being overdrawn at the memory bank).

            --
            And there is no Alkibiades to come back and save us from ourselves.
            • (Score: 2) by NCommander on Tuesday June 02 2020, @10:24PM (6 children)

              by NCommander (2) Subscriber Badge <michael@casadevall.pro> on Tuesday June 02 2020, @10:24PM (#1002433) Homepage Journal

              I had a Sony VAIO with ME as hand-me-down. I never had any serious issues with it even with System Restore, although I had to do one of the DOS mode hacks for the few legacy programs I kept around. LGR recently installed ME on one of his machines and honestly didn't find it bad.

              I think ME gets a fairly bad rap because Windows 2000 Professional had spread like wildfire so people were expecting their home computers to be as stable as their work ones. ME does show signs of a rushed product. Microsoft was planning Neptune as the ME follow-up but it wasn't quite viable so the 9x line got one more update as a stopgap until Neptune collapsed into Whistler and we got XP. That being said, I really can't cite any good reason to run it for a retro PC over say 98 SE.

              It also suffered the Microsoft update problem. ME I think was the last major version where Microsoft really pushed "Upgrade inplace" for quite a few years until Win 8/10. ME had higher system requirements, and PCs that were struggling with 98 SE would just collapse into a pile of BSODs.

              --
              Still always moving
              • (Score: 2) by Reziac on Tuesday June 02 2020, @11:48PM (5 children)

                by Reziac (2489) on Tuesday June 02 2020, @11:48PM (#1002495) Homepage

                The main problem with WinME is that it would use up the resource heaps a lot faster than 98, even doing the exactly same tasks with the exact same software. It was just better at recovering 'em afterward, 100%, so there was no loss over time. Agreed it was rushed, and unfinished -- in fact word around was that development was simply abandoned when they decided to congeal both lines into XP, so it was RTM'd as-is. I think the higher sysreqs were actually a function of bad resource management, not just of running more crap. The underlying DOS, when exposed via a 3rd party utility, was seriously broken -- it could not run any sort of memory manager other than one that's self-contained, like DOOM's DPMI.

                Only reason I still have WinME is because it was left as a dual boot when I first got XP, and there's another copy on a loose HD around here somewhere -- ME itself was effectively portable and would grab whatever drivers were available (it could use Win95 drivers too) so it would run on anything without a reinstall. Which was sometimes handy.

                Funny, tho -- I can see the same hands at work in Vista. It *feels* like ME, and is perhaps as unfinished. (And I've seen Vista run beautifully, and horribly, but haven't taken the time to figure out why.)

                --
                And there is no Alkibiades to come back and save us from ourselves.
                • (Score: 3, Interesting) by RS3 on Wednesday June 03 2020, @05:18AM (2 children)

                  by RS3 (6367) on Wednesday June 03 2020, @05:18AM (#1002619)

                  Wow, the memories, the nostalgia! I pretty much hated Win95, oh, well, 95c was okay, but 98 was good and had gotten SE early and loved it, and kept it running for many years- maybe up until 2010? Anyway, I had found the autopatcher people, and somewhere (maybe them?) a reference to grabbing 1 system file from ME, and you had the best of all worlds. I even had USB 2.0 working reliably.

                  I had gotten into Qemm, oh, maybe 1990, so I always ran Windows 3.1 - 98SE on Qemm, so maybe that's why I had such good success? And I've always been a hot-rodder / tuner / tweaker (cars too) so that helped too I guess. Tweaked the daylights out of config.sys, Windows' .ini files, etc. Hmmm, I'm not sure I miss those days. Maybe someday I'll have to see if my Win98SE drive will still boot (or if the heads are glued to the platters...)

                  • (Score: 2) by Reziac on Wednesday June 03 2020, @06:52AM (1 child)

                    by Reziac (2489) on Wednesday June 03 2020, @06:52AM (#1002638) Homepage

                    I started off in DOS5 on a two-floppy XT (well, if you don't count the IBM1620 in high school... Fortran and punch cards!), then spent several happy years with a tricked-out 286... yeah, memory management was a black art; it only had 1mb (with one bad bank locked out via a switch) and there was much juggling of TSRs, available blocks, and initializing memory vs running memory, and forcing programs to share as much as possible of the paltry 20mb disk (which required a low-level format every couple years because those old MFM drives went unstable from their own heat); and a RAMcard for workspace. It's amazing how much we managed to cram into so little. "We have done so much for so long with so little, that we are now qualified to do anything with nothing." :D

                    Then came a 486 (only system I ever bought new; everything else has been freebies, salvage, and frankenputers) and Win3.1, which was the same kind of puzzle only a lot larger. I never used QEMM but I did have it running atop DRDOS7, which was an adventure, because DRDOS's memory manager had Very Different Ideas, and forgot to emulate DOS4 for Word6. (DRDOS also didn't have the best performance. By actual test, 20% slower than MSDOS.) It was well-behaved and grew into an incredibly complex system, with programs calling one another to fill up each other's holes... I once figured out that recreating it from scratch would have taken a month as a full-time job. That system's original sound card is in the box I use for DOS gaming (P4 with ISA slots) and is still cranky about which slot vs IRQ. Lordy, the things we struggled with in the olden days... remember when some modems only worked in the bottom slot?? I still have the HD in a box (mainboard was killed by a keyboard short), and it still runs, tho finding appropriate hardware... well, maybe in another box. :)

                    I didn't like the initial release of Win95, but OSR2b was excellent -- good performance and never once misbehaved. Wasn't retired til 2012; unfortunately the well-loved system has since died, but I still have a disk image, and a lingering desire to resurrect it. I do still have my Win98 (not SE, which I did not like) box, twin to the ME/XP box and equally stable... only time it EVER crashed was when Mozilla 1.0 tried to directly access the hardware (bad programmer! no donut.) But a need for Win98 is... well, just not with me anymore, and ReactOS covers the same ground and is easier to get running on newish hardware.

                    And then I grew accustomed to WinXP/XP64, now the standard by which I judge other OSs and still my daily driver. I dislike Win7 and loathe Win10, so when I need "modern" .... now it's PCLinuxOS/KDE.

                    Ah, the memory lanes, striped by madmen. :D

                    --
                    And there is no Alkibiades to come back and save us from ourselves.
                    • (Score: 3, Interesting) by RS3 on Thursday June 04 2020, @02:07AM

                      by RS3 (6367) on Thursday June 04 2020, @02:07AM (#1003022)

                      I started out with shells and straws and sand until they gave me an abacus. Now get off my lawn!

                      But seriously my computer history is long, including some CP/M machines (not mine, but I used them a bit. Get it- "bit"? ugh. sorry. I'll stop now.)

                      Mine were usually frankencomputers, often just a MB on a box. One of the coolest things I ever got (very nerdy of me) was 3 full-height 5.25" Priam 330 MB ESDI drives for cheap at a hamfest. Man they were fast. I loved their startup- they had the linear "voice coil" head actuators and they went through a full-range head motion sweep in several steps. The floor would shake! It felt like really serious hardware, not the stupid Seagate 20 and 40 MB squeak-squeak chirp-chirp drives that I had too many of. I've admitted this to few people, but early on, maybe 1989, I learned about RLL vs MFM, that RLL had 1.5x the speed AND density. I had this full-height 40 MB Maxtor (I think it was Maxtor) and it would not reliably low-level format to 60 MB RLL. So I reverse-engineered the head amp circuits, modded the filters, and had 100% rock-solid reliable 60 MB drive that was one or my main drives for many years.

                      I'm a bit of a hard disk / storage freak. Perhaps you never had SpinRite? The older versions would properly low-level format and test test test sectors. The drive's label's defect maps were just way off, so I always used SpinRite, and I'd run it maybe monthly and I never ever had any lost data or hard drive problems (unlike the drives of the past 20-some years...)

                      Interestingly I was very into Linux starting in maybe 1994 and it was my main OS for a very long time. When I got Win98SE + ME file running well, that kind of took over, and partly because I was using laptops and X-windows was so clunky slow. I begrudgingly got into XP maybe 2005, but didn't really use it until maybe 2012. I only started using 7 maybe 2 years ago. I've never liked it for many reasons. I have 1 Win10 machine, well, hard drive, that I can't find because I pulled it to install something else on another drive in that machine. I'm trying to get better at labeling drives...

                      4 or so years ago I used to know a very highly-paid sw. dev. manager for a major bank. He told me Win 8 is the best of all- most refined, fastest, and without all the garbage of 10. I have messed with it, and installed it for a couple of people (their HD had died) and it surely was fast. IIRC you can get rid of the ridiculous "tiles" UI. I'm going to be trying it very soon any day now. Drivers are always a frustrating problem with Windows and hardware, esp. laptops. Not sure why Linux gets all the bad rap on that end. For me the worst is when the slightly wrong drivers kind of work so you think you're okay but you get bluescreens and you run "bluescreenview" and the dump is no help. Turns out to be a driver that seemed to work... One was for a touchpad that I _never_ use, but need to install a driver so I can disable the touchpad. Moronic. Thanks MS, keep trying to be like MacOS.

                      Oh yeah, I've got various Macs in the mix. Mostly use them for audio editing, but less and less anymore.

                • (Score: 2) by NCommander on Tuesday June 09 2020, @04:48AM (1 child)

                  by NCommander (2) Subscriber Badge <michael@casadevall.pro> on Tuesday June 09 2020, @04:48AM (#1005092) Homepage Journal

                  Visita ... good lord where do you start there?

                  I have no idea what happened within Microsoft, but Longhorn (Vista's codename) shows pretty much feature creep and mismanagement throughout all its betas. THey basically had to restart from scratch multiple times. Honestly, it's kinda like Apple Copland expect Microsoft managed to push it out the door.

                  Vista itself was rather usable at SP1, although it had such a bad rap that most people wrote it off until Win 7 which is easier to think of as service pack. THere isn't much that 7 actually had that Visita didn't in some form.

                  --
                  Still always moving
                  • (Score: 2) by Reziac on Tuesday June 09 2020, @05:24AM

                    by Reziac (2489) on Tuesday June 09 2020, @05:24AM (#1005106) Homepage

                    I've only meddled briefly with Vista, and never looked at the betas... one (Home ed. x86) runs beautifully on an older system, so I left it alone as a justincaser; the other (Pro? x64) ran like crap on a somewhat faster system (like crap: 30 second lag for a mouse click), and could not figure out what the problem was (wasn't especially junked up) and replaced it with Win7, which as you say was functionally a service pack.

                    Have you seen the Shorthorn project?
                    http://shorthornproject.com/ [shorthornproject.com]

                    --
                    And there is no Alkibiades to come back and save us from ourselves.
    • (Score: 2) by NCommander on Tuesday June 02 2020, @10:08AM (4 children)

      by NCommander (2) Subscriber Badge <michael@casadevall.pro> on Tuesday June 02 2020, @10:08AM (#1002114) Homepage Journal

      Honestly, that sounds like IIS being a pile of shit. I've had very mixed bag of experiences with both old and modern IISes. IIS has always shown signs of Microsoft reacting to being slow to the Internet and it's never come across as a great product. I've actually had much better experiences with Apache on NT than I did with IIS.

      That being said, from a developer's perspective, at the time, Perl and PHP/FI were the two main scripting languages and neither had great tools (arguably true now at least as far as Perl goes). InterDev very much made applications easier to write, and while Visual Basic as a language sucked, I think on the whole the development experience was better.

      A lot of this is that Access is a pretty good frontend to JET databases, and SQL Server's administration tools generally have been better than any others, especially in the era we're talking. phpMyAdmin was the "best" I remember for MySQL, and I don't even remember when pgAdmin was something worth using.

      --
      Still always moving
      • (Score: 2) by Reziac on Tuesday June 02 2020, @04:16PM (3 children)

        by Reziac (2489) on Tuesday June 02 2020, @04:16PM (#1002208) Homepage

        Yeah, now that you remind me, it was probably IIS clogging up, and it wasn't the only site with this problem, just the one that regularly annoyed me. I don't recall a lot of bitching about NT4 in, say, an office environment, but as a webserver... ugh.

        Funny story about the bad old days when hacked FTPs were common... I'd gone looking for some-file-or-other, found it in the bowels of some completely p0wnd server.... got curious, went up to the root, and discovered it was owned by Halliburton. And yes, it was NT4.

        Security was Netware's claim to fame back then... it was a relatively tough nut to crack, for the day. I remember how slim its chapter was in Hacking Exposed.

        --
        And there is no Alkibiades to come back and save us from ourselves.
        • (Score: 3, Interesting) by NCommander on Tuesday June 02 2020, @10:11PM (2 children)

          by NCommander (2) Subscriber Badge <michael@casadevall.pro> on Tuesday June 02 2020, @10:11PM (#1002424) Homepage Journal

          The great irony it being in Ring 0 meant that if you could smash a stack anywhere, you've won. NetWare itself though didn't exactly offer much. You got file and print sharing, with netbooting capability ... and that's about it.

          If you added in additional NLMs, that story changes somewhat but you'd still need custom attack code over IPX. Given IPX isn't Internet routable for obvious reasons, it becomes security through nonroutability :)

          --
          Still always moving
          • (Score: 2) by RS3 on Thursday June 04 2020, @02:14AM (1 child)

            by RS3 (6367) on Thursday June 04 2020, @02:14AM (#1003027)

            Many people used the Internet to route IPX packets that were wrapped in IP packets.

            • (Score: 2) by RS3 on Thursday June 04 2020, @02:18AM

              by RS3 (6367) on Thursday June 04 2020, @02:18AM (#1003032)

              "Tunneling" is the word I was trying to remember. I think Netware would tunnel IPX through IP, on the server, if you set it up.

  • (Score: 4, Interesting) by DannyB on Tuesday June 02 2020, @01:43PM (4 children)

    by DannyB (5839) Subscriber Badge on Tuesday June 02 2020, @01:43PM (#1002168) Journal

    I'll still stand by my opinion that NT won this battle by being the better product

    NT was unfit for any porpoise.

    I've told this story on SN before, but briefly . . . set up a new NT 4 box in about 1999. First was the endless series of required reboots. Had to install IIS, MSMQ and a number of other things for the purpose of this box. (We were selected by Microsoft to build an adapter for our product for a new "interoperability framework", and this prototype effort, involving multiple vendors was to be shown to Microsoft in a few months in NY.)

    I demonstrated to my coworker how easy it was to hack IIS. (This is the part I've told before on SN.) Just use dot-dot-slash to work your way out of inetpub wwwroot and then down to windows/system32 where your "cgi" could be "cmd.exe" using the built in TFTP command to grab another exe from evil.com. Then a 2nd carefully constructed url to iis would execute the exe you just downloaded from evil.com.

    Microsoft mitigated this by making IIS not recognize dots in urls in this manner. No problem, one could use url encoded sequences, such as percent-two-zero %20 for a space. Similar sequences for dots and backslashes. Same hack then worked.

    So Microsoft fixed that. BUt the filesystem still allowed the percent-two-zero %20 for space type url encoded sequences. So you could double-encode to evade IIS detection, which then un-escaped it once and handed that portion of the url to the filesystem, which unescaped it again, and you could still execute an exe from evil.com

    This was not fit for any purpose whatsoever.

    IIS ran as the SYSTEM account . . . because . . . performance more important than security.

    IIS had a 8192 character buffer for the url, and a longer overflow would overflow the buffer and this is now Code Red attacked IIS.

    And on and on and on.

    --
    People today are educated enough to repeat what they are taught but not to question what they are taught.
    • (Score: 2) by Reziac on Tuesday June 02 2020, @04:21PM (1 child)

      by Reziac (2489) on Tuesday June 02 2020, @04:21PM (#1002211) Homepage

      Yeah, I remember when hacked FTPs were common... the p0wnd directories would have long strings of ../.../..../ in the path, and other nonsense characters. You could fall into 'em via search engine, but if you went upstream you couldn't find 'em again.

      Also recall a demo someone did of putting an NT4 server online without a firewall (then a 3rd party app), what with all that open networking. It lasted 30 seconds.

      --
      And there is no Alkibiades to come back and save us from ourselves.
    • (Score: 3, Interesting) by NCommander on Tuesday June 02 2020, @10:08PM (1 child)

      by NCommander (2) Subscriber Badge <michael@casadevall.pro> on Tuesday June 02 2020, @10:08PM (#1002420) Homepage Journal

      You're comparing apples to oranges here. First off, I didn't include IIS because Novell didn't include a first-party web server, at least with NW 3.12.

      I'm happy to trash IIS all day long, but let's get some facts straight. IIS running as SYSTEM is no different from the fact that NetWare runs in ring 0. If I can pop a buffer, I've popped the box. UNIX had a better security track record in the era because they did had made the same mistakes back on ARPANET. Then again, I also saw Apache running as root because of stupid bugs on UNIX since you need to be UID 0 to open port 80. sendmail's DEBUG command comes to mind years prior as a Code Red idiotic moment. Even by this period, I still remember running nmap on IRIX and finding a ridicious number of ports opened by root servers.

      You're free to believe NT was total shit. Was NT not as good as UNIX of the era? I'll even cop that argument, it wasn't until NT4 that Microsoft reached a point where it could attempt to compete. Many would argue it still hasn't gotten there. I will say that NT was better than NetWare in most roles, and was competive in file and print sharing.

      NetWare was almost never Internet facing directly because it ran on IPX and it's TCPIP support was at best lackluster. By time Novell got its act together, its ship sailed. There's also no concept of user accounts on NetWare's NLMs; everything runs at full privs. That MIGHT have been fixed in later NetWare but I haven't confirmed that specifically.

      --
      Still always moving
      • (Score: 2) by DannyB on Wednesday June 03 2020, @04:53PM

        by DannyB (5839) Subscriber Badge on Wednesday June 03 2020, @04:53PM (#1002815) Journal

        I don't have a problem with anyone being nostalgic for stuff they enjoyed back in the day.

        I think I simply see Windows from a different perspective that colors my perceptions of it differently.

        --
        People today are educated enough to repeat what they are taught but not to question what they are taught.