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.
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.
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.
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
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.
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.
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.
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.
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.
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!
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.
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.
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.
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.
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.
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.
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.
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.
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'.
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.
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.
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:
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):
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).
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.
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.
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.
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.
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.
Related Stories
I've made no secret that I'd like to bring original content to SoylentNews, and recently polled the community on their feelings for crowdfunding articles. The overall response was somewhat lukewarm mostly on dividing where money and paying authors. As such, taking that into account, I decided to write a series of articles for SN in an attempt to drive more subscriptions and readers to the site, and to scratch a personal itch on doing a retro-computing project. The question then became: What to write?
As part of a conversation on IRC, part of me wondered what a modern day keylogger would have looked running on DOS. In the world of 2016, its no secret that various three letter agencies engage in mass surveillance and cyberwarfare. A keylogger would be part of any basic set of attack tools. The question is what would a potential attack tool have looked like if it was written during the 1980s. Back in 1980, the world was a very different place both from a networking and programming perspective.
For example, in 1988 (the year I was born), the IBM PC/XT and AT would have been a relatively common fixture, and the PS/2 only recently released. Most of the personal computing market ran some version of DOS, networking (which was rare) frequently took the form of Token Ring or ARCNet equipment. Further up the stack, TCP/IP competed with IPX, NetBIOS, and several other protocols for dominance. From the programming side, coding for DOS is very different that any modern platform as you had to deal with Intel's segmented architecture, and interacting directly with both the BIOS, and hardware. As such its an interesting look at how technology has evolved since.
Now obviously, I don't want to release a ready-made attack tool to be abused for the masses especially since DOS is still frequently used in embedded and industry roles. As such, I'm going to target a non-IP based protocol for logging both to explore these technologies, while simultaneously making it as useless as possible. To the extent possible, I will try and keep everything accessible to non-programmers, but this isn't intended as a tutorial for real mode programming. As such I'm not going to go super in-depth in places, but will try to link relevant information. If anyone is confused, post a comment, and I'll answer questions or edit these articles as they go live.
More past the break ...
For those who've been long-time readers of SoylentNews, it's not exactly a secret that I have a personal interest in retro computing and documenting the history and evolution of the Personal Computer. About three years ago, I ran a series of articles about restoring Xenix 2.2.3c, and I'm far overdue on writing a new one. For those who do programming work of any sort, you'll also be familiar with "Hello World", the first program most, if not all, programmers write in their careers.
A sample hello world program might look like the following:
#include <stdio.h> int main() { printf("Hello world\n"); return 0; }
Recently, I was inspired to investigate the original HELLO.C for Windows 1.0, a 125 line behemoth that was talked about in hush tones. To that end, I recorded a video on YouTube that provides a look into the world of programming for Windows 1.0, and then testing the backward compatibility of Windows through to Windows 10.
For those less inclined to watch a video, my write-up of the experience is past the fold and an annotated version of the file is available on GitHub
So at it turns out, being cooped up due to COVID-19 causes your local resident NCommander to go on a retro computing spree. Last time, I dug into the nuts and bolts of Hello World for Windows 1.0.. Today, the Delorean is ready to take us to 1993 — the height of the "Network Wars" between Microsoft, Novell Netware, and many other companies competing to control your protocols — to take a closer look at one of Microsoft's offerings: Windows for Workgroups
As with the previous article, there's a YouTube video covering most of the content as well as: a live demonstration of Windows for Workgroups in action, my personal experiences, and the best startup chimes of the early 90s.
If the summary doesn't make you relive all those General Protection Faults, then slip past the fold to see what all the hubbub was about for Windows for Workgroups compared to its younger brother, Windows 3.1.
As promised, here's the round-table discussion post that I said on Wednesday was coming. We have a long history at SoylentNews of listening and responding to our community; I genuinely hope that never changes. I also recognize that I may have ruffled some feathers in the last few weeks with original content postings so here's the best place to get this all out.
I am mindful of the community's support and goodwill; I don't want to squander any of it. Yes, there are times where my hand may be forced (e.g., DCMA takedowns). Still, I'm always a bit hesitant whenever I post on the main site for anything that isn't site update news or similar. I may be the de facto site leader, but I want my submissions to be treated like anyone else's — I want no favoritism. The editorial team does review my stories and signs off before they go live (unless it's an "emergency" situation such as the last time we blew up the site). However, as the saying goes, the buck stops with me.
SoylentNews accepts original content. I'm also aware that I've probably submitted the most original content so far (See "Previously", below for some examples). I'm grateful for the community's apparent acceptance of my submissions and the positive responses to them. What I don't know is if there is an undercurrent of displeasure with these. Maybe everyone thinks these are all fine. Then again, maybe somebody has an issue with them. Rather than assume anything, let's get it all out in the open.
What I want to cover in this round-table discussion is original content and having images in posts as well as topics such as yesterday's Live Show on Improving Your Security -- Wednesday June 3rd, 2020.
So, contributors and commenters to SoylentNews, get that Reply button hot and let me hear your feedback. As usual, either a member of staff or I will respond to your comments below,
73 de NCommander
Previously:
(2020-06-03) Live Show on Improving Your Security -- Wednesday June 3rd, 2020
(2020-05-24) Retrotech: The Novell NetWare Experience
(2020-05-14) Exploring Windows for Workgroups 3.11 - Early 90s Networking
(2020-05-10) Examining Windows 1.0 HELLO.C - 35 Years of Backwards Compatibility
(2020-05-15) Meta: Having a Chat about SoylentNews' Internet Relay Chat
(2018-10-25) My Time as an ICANN Fellow
(2017-10-09) soylentnews.org experiencing DNSSEC issues
(2017-04-20) Soylentnews.org is Moving to Gentoo...
(2017-04-17) SN Security Updates: CAA, LogJam, HTTP Method Disable, and 3DES
(2017-03-13) Xenix 2.2.3c Restoration: Xrossing The X (Part 4)
20200618_214854 UTC Update: yes, some of these pictures are... large. Placed in <spoiler> tags for now; click each one it to see/hide the picture. --martyb]
Well, here we go again! Coming off the Novell NetWare experience, I had intended to go straight into Windows NT. After two attempts of shooting a video and much swearing, I decided to shelve that project for the moment. Furthermore, a lot of the feedback from my previous articles talked about early Linux.
That gave me a thought. Why not dig out the grandfather of modern Linux distributions and put it on camera? Ladies and gentlemen, let me introduce you: the Softlanding Linux System, complete with XFree86 1.2!
Honestly, there's a lot of good and bad to say about Softlanding Linux, and while SLS is essentially forgotten, its legacy birthed the concept of the Linux distribution and its bugginess also lead to the creation of both Slackware and Debian. It also made me remember a lot of the bad that came with Linux of this era.
Assuming the summary hasn't scared you off, get ready to write your Xconfig, strap in your Model Ms, and LOADLIN your way below the fold!
(Score: 2, Informative) by Anonymous Coward on Monday June 01 2020, @11:09AM (2 children)
I've had one of these 3COM NICs. It's on an ISA bus. I'm not certain if I still have it as Linux cannot compile a driver for it even 10 years ago when I tried. The board is also littered with through-hole components.
Anyway, if you want to run all these legacy crap, you can still do.
https://www.microfocus.com/en-us/products/open-enterprise-server/overview [microfocus.com]
(Score: 2) by TheRaven on Monday June 01 2020, @01:04PM
I think FreeBSD dropped support for NE2K about a year ago. They lasted a *long* time after the ISA bus had gone from real systems because it was really simple to emulate. A load of early x86 emulators / virtualisation platforms provided an emulated ISA bus and NE2K: it was simple and every OS had a driver for it.
A bunch of my friends had cheap NE2K cards for early LAN parties (where the first half day was spent getting the network wired up and everyone configuring IPX in DOS: I can't remember the tool we used, ezconfig or ezsetup. It took me ages to realise that Americans pronounce the letter Z as Zee so it was meant to be ee-zee setup, not ee-zed setup). We replaced them with Realtek 8129 cards, which had insanely small buffers (one of the many corners that they cut to make them so cheap) and had a comment in the FreeBSD device driver saying that you'd need a ludicrously fast 300MHz CPU running flat out to be able to get anything close to line rate. That seemed bad when I got the card originally for a 233MHz Pentium clone, less bad by the time it was a 450MHz K6-2, and completely irrelevant by the time I was using the same card in a 1.33GHz Athlon.
sudo mod me up
(Score: 0) by Anonymous Coward on Monday June 01 2020, @11:40PM
I was using the chipset of this board (it was called "PT" chip, from the manufacturer's initials) and it is quite well designed and can be well used...
...if you can do a fast I/O. In my embedded system - great. In Windows 9x - great. In all other systems - its performance and CPU usage limits to waiting 90% time in a waiting loop in state "can_i_do_this" only to miss the proper time because some other part kicked in and wait again.
As I remember, the "P" in initials was for "Parallel". The chipset works well when supported nearly serially.
(Score: 4, Interesting) by looorg on Monday June 01 2020, @12:14PM (7 children)
Time to share some memories I guess. This is what ran the network in the high school I attended. It was weird and clunky, the supervisor (or admin) was a grumpy old guy and he did NOT like us playing around with HIS network. Which we naturally did anyway. I recall having lots of fun with various commands (I might be remembering the exact names wrong)
Send sent messages between logged in users, but there was also an ALL switch and if that was sent at the "wrong" time it could pretty much crash or lockdown the entire network. I don't recall now if there was other broadcast commands, there might have been and they had some similar effect. But if enough people was logged in this would be a big program. I don't recall the command now but there was something you could do to shield yourself from the commands and that in turn eventually was the first thing you ran as you logged in, until we figured out that we could just script that into a login-script.
Then there was one to change the attributes of files and one of those attributes was to hide files -- which was great to have local copies of DOOM stored on the computers, there was NO GAMES ALLOWED on the school computers -- which no student cared about at all. They wouldn't be shown in the list anymore if you just did a DIR so you either had to knew the name in which case you could just CD into them or you had to use other commands and access privileges to reveal them again. This led to many computers in the network being taken offline physically from time to time cause apparently that interfered with their anti-virus software which noticed the files but couldn't read them and then in turn they couldn't find the files when they went to look for them -- solution -- REFORMAT and REINSTALL ... cause clearly our games had brought virii to the network or somesuch reason.
The last oddity was perhaps more of a DOS issue but this is where I found out that if you have files with the same name but different suffix they are apparently read in a weird order -- one would think that .exe would have priority but it doesn't or didn't. So say LOGIN.BAT (and LOGIN.COM) is read before LOGIN.EXE if you just typed LOGIN -- which most people did. Which in turn made it somewhat trivial to write a little script and program that just saved the credentials of everyone that logged in -- queue installing this, create a problem with the computer, notify staff, supervisor comes around to fix the problem, TADA! We now have supervisor access to the network. Thank you! Which in turn opened the world of SYSCON etc.
For all my evil wrongdoings and tormenting the poor staff I after high-school got a job administering a Novell network (among other things). But things had improved somewhat then and it was mostly done in a GUI running under windows instead of doing it all in DOS and various DOS shells. It was still weird with it's tree structures and all but it was at the same time better then many of the alternatives.
(Score: 2) by JoeMerchant on Monday June 01 2020, @12:34PM (5 children)
Hidden files are a sort of level 1 hack. When your admin has made it to level 1.1, they'll run a tool that shows all hidden files. Level 1.2 they will make a tool that keeps a reference list of which hidden files belong and only show them new hidden files. Level 2.0: the tool will run automatically and present them with a report every (necessary interval: daily, hourly, etc.) and an option: delete all of these files now?
🌻🌻 [google.com]
(Score: 3, Interesting) by sjames on Monday June 01 2020, @08:23PM (4 children)
And, of course the old DOS trick, holding down alt and typing a 3 digit number on the keypad entered that ASCII character. 255 looked like a space but wasn't treated like space.
(Score: 2) by JoeMerchant on Monday June 01 2020, @09:16PM (2 children)
My first experience with invisible characters was on the Apple II, some crazy shit with escaping up to the line above and putting in a bunch of invisible binary that would be present in the file, but invisible in the editor. Of course you can, but why would anybody think that's a good idea?
🌻🌻 [google.com]
(Score: 2) by sjames on Monday June 01 2020, @09:37PM
That and other tricks were mostly good for pranks or more nefarious activities. Never a good idea for regular use.
My favorite for Apple ][ was that if you entered a REM statement with a ^L as the (IIRC) 79th character on the line, the following would be executed as a command when the program was listed.
(Score: 2) by looorg on Monday June 01 2020, @10:49PM
There are (or was) uses for it I gather, beyond just plain fuckery. I can recall using it on systems where files wasn't exactly private or you had to put it in a shared folder for a moment (space being at premium and all) -- you tossed in some weird chars you knew were invisible in the filename or just wasn't on the normal keyboard -- if it was allowed. So others probably couldn't read them or access them but you could (if you remembered what you had done). It sort of became a thing of the past I guess when various systems later allowed you to just copy-paste what was on screen or there was some sort of tab-name-completion or you grabbed it with some kind of wildcard statement. But still it was "safe" from the common users that snooped around and such.
I guess it's also for people using non-english/standardized languages. It's somewhat beyond me since it's still ingrained with me to this days that you don't ever use non-english chars in filenames cause that eventually just leads to misery and pain. There is (or was) always some program somewhere, or I guess it's more a thing of the past -- even tho I still run into it from time to time, that crashed or started to do weird things once it found such chars -- even if they were just standard umlauts such as åäöü etc. I guess the most annoying one otherwise are all those little ' (can't recall the name now -- single quotes or ticks or whatever) that exists in various non-english languages -- most of the time I can't even see the difference, it's tilting to the left or right or is in the center etc. But on some old fonts etc they looked exactly the same if they were even visible.
(Score: 2) by Reziac on Tuesday June 02 2020, @02:21AM
Friend who'd had her AOL account hacked hit on a clever way of preventing a recurrance: she used a backspace as part of her username. Yes, it was actually accepted and worked. Kinda in the same realm of hiding in plain sight.
And there is no Alkibiades to come back and save us from ourselves.
(Score: 2) by NickM on Tuesday June 02 2020, @02:07AM
I a master of typographic, grammatical and miscellaneous errors !
(Score: 4, Interesting) by JoeMerchant on Monday June 01 2020, @12:42PM (5 children)
In 1988 I took my fresh BS in EE with specialization in computers to Manhattan and, more for entertainment than serious life pursuit, interviewed for jobs. There was a lot of IPX networking skill demand at the time, I don't believe ANYTHING in my 4 year degree ever even mentioned IPX, much less explained anything about how to work with it. There was not a lot of demand in NYC for freshly minted BSEE degrees, but if you shined your shoes and put on a bright red tie they'd give a job to just about anybody.
In the mid '90s I did install a few Netware networks in P2P mode, more as a sideline than an actual job function - they were pretty low maintenance, and not even too much hassle to setup in the first place: install an ISA card, run some coax, remember your terminators... pre-internet about the only thing they were good for (for us) was data shuffling from DAQ systems to archive systems, and printer sharing. Even after we got dial-up internet, the office computers each dialed in separately - internet connection sharing didn't really come into common play until the connection modem itself was a bridge between DSL and Ethernet.
🌻🌻 [google.com]
(Score: 2) by NCommander on Monday June 01 2020, @12:59PM (1 child)
If Netware can be used in a "set it and forget it" fashion, its perfectly fine once you get it going; its just an ongoing headache to actually configure. That being said, Personal NetWare was a very different beast from "real" NetWare and it ran as a TSR as far as I know and without access controls which sounds much more in line with what you're describing.
Still always moving
(Score: 2) by JoeMerchant on Monday June 01 2020, @02:03PM
Yeah, I'm pretty sure we were using "personal" stuff - no need or desire for access controls, etc. Max network size we ever made was about 6 nodes, all highly trusted actors on it - physical access control to the PCs, DOS mode: no passwords.
🌻🌻 [google.com]
(Score: 0) by Anonymous Coward on Monday June 01 2020, @04:22PM (1 child)
In the early 90s my highschool computer lab had a Netware setup running on what must have been tremendously expensive 386 PS/2 systems. As is probably typical for highschool computer labs, the network was mostly used to play games and to print to the shared printer. I'm sure it would have been cheaper to just give every computer its own printer.
By the time I got to college it was obvious that Netware was going to be irrelevant and I never really bothered to learn it. My school mostly had Apple stuff anyway.
I do, however, still have an NE2K network adapter, although it would only be useful for retrocomputing since nobody supports ISA any more, and apparently my phone autocorrect knows what Netware is. So, it still lives on, sort of.
(Score: 0) by Anonymous Coward on Tuesday June 02 2020, @10:21AM
like they did IPX protocol support (which for the record was never properly documented in manpages, making use/development of it difficult.)
ISA and NE2K ISA support were still in there a few years ago when I looked. I've used it both for ReactOS 'AT'/NONACPI support as well as under linux and... netbsd 6.0(?) to spin up some real hardware a few years before that.
(Score: 0) by Anonymous Coward on Tuesday June 02 2020, @10:17AM
I was using ppp along with... the predecessor to ipchains? to run 10 baseT on a couple 82593 cards and a brand spanking new either RTL8129 or SMC something card running in NE2K-PCI mode. While Windows 3.1 was pretty much limited to IPX or dial-up TCP-IP because of the available TCP/IP stacks (winsock cost money and most of the ISP versions were dialup only if I remember correctly.) Windows 95 actually had full TCP/IP support, as well as IPX, although Win98 made IPX hard to use by requiring ODI drivers it seems like, rather than allowing you to use the native Win95 one.
Anyway point was connection sharing was common prior to DSL, and in face by Windows ME if not early, they had internet connection sharing support that could actually share dialup over a windows computer acting as a terrible tcp/ip gateway. Personally though I just used pppd, plus whatever was used pre-ipchains, then ipchains, then many years later iptables when it fully replaced ipchains along with finally having fucking documentation (it was one of those documented syntax without documented examples cases where the syntax and ordered wasn't always obvious, you can find it in lots of manpages even today!)
I even ran some old multi-user text based games off those modems during the late hours of the evening when local phone charges didn't apply and the ISP was in low use so it didn't drop you randomly to make it seem to customers like it was properly subscribed instead of heavily oversubscribed.
(Score: 3, Interesting) by GlennC on Monday June 01 2020, @02:26PM (8 children)
One of my first jobs was at a small company that made PC clone systems. They had a disk copying system set up to make bootleg Netware installations using the one legal copy they bought. The clients were mostly other small companies who were trying to do things on the cheap.
I spent many an afternoon running coax over drop ceilings and hand-making 50-ohm terminations.
It worked about as well as you'd expect, and the company soon imploded. Fortunately for me, I landed a job at a more reputable place by then and ended up going back to get my Bachelor's degree.
Sorry folks...the world is bigger and more varied than you want it to be. Deal with it.
(Score: 5, Interesting) by Rosco P. Coltrane on Monday June 01 2020, @02:40PM (7 children)
One of my first job was maintainer of the DRDOS kernel at Digital Research. We had to support NetWare. It was a great product, but a bit of a headache to accommodate it's dirty tricks in the DOS kernel. Then again, every product that used undocumented kernel structures was also...
Takes me back too...
(Score: 2) by RS3 on Monday June 01 2020, @03:56PM
Firstly, thank you for your work at DR. I did a bit of Novell stuff in the 90s, and even used CP/M in the 80s, and certainly installed and used DR-DOS a ton, mostly with the Novell stuff. IIRC, DR-DOS had a bunch of enhancements to command.com commands, enhanced config.sys parameters, utilities, etc. Generally way cooler and made my work and life easier and better.
I wasn't aware that Novell did any "dirty tricks" into DOS. Do you remember what some of them were? Or just generally what they did or why they were needed?
(Score: 2) by NCommander on Monday June 01 2020, @04:58PM (5 children)
Ok, now I'm curious.
The DOS redirector interface was standardized in DOS 3.1, and the ODI stack should exist mostly independently of DOS so I'm curious what was playing with DOS's guts. I could see Personal NetWare doing that for locking files on DOS, but not the standard redirector.
Also, any experience with the work on making DR-DOS pass the AARD code?
Still always moving
(Score: 3, Interesting) by RS3 on Monday June 01 2020, @08:20PM (4 children)
Rosco hasn't replied yet, but I wonder if it (DOS guts play) pertained to the P2P stuff. For sure Netware server didn't care, and I know workstations ran on MS-DOS 5-6 with no problems that I remember.
Also, IIRC, it was proven in court that MS Windows clobbered Novell client code, using encrypted code that someone decrypted and reverse-engineered, to crash Windows and make Netware look bad. B. Gates many times infamously said he would demolish Novell.
(Score: 1, Informative) by Anonymous Coward on Tuesday June 02 2020, @12:35AM (3 children)
The XOR encrypted code was to detect if, what would become windows 3.11, was running on DR DOS (the Microsoft evil code was discovered before general release). If DR DOS was detected, the encrypted code would display bogus error messages to scare the user away from running non MS DOS (DR DOS was superior in every way).
It was discovered by the author of the Undocumented Windows book (can't remember if he did Undocumented DOS too, but undocumented DOS was a life saver for me back then).
IIRC, windows 3.11 was also when MS took away the mode that allowed windows 3.1 to run under deskviewX. The benchmarks that had windows running under deskview performing better than windows running native were hilarious, and probably played a part in MS killing the ability of deskview to do this. DeskviewX was also pretty awesome in that it allowed you to turn a crappy PC into an X terminal.
(Score: 2) by RS3 on Tuesday June 02 2020, @01:01AM (2 children)
Wow, thanks for all of that- fills in some gaps in what I knew at the time. I was never fully invested in IT at the time. Besides tinkering at home, it was usually some percentage of whatever job I had at the time. I don't think I ever had DeskviewX, but I ran desqview sometimes, and Windows 3.11 on Qemm. Is that maybe what you were thinking of- Qemm rather than himem.sys and emm386.exe?
(Score: 0) by Anonymous Coward on Tuesday June 02 2020, @03:45AM (1 child)
> Qemm. Is that maybe what you were thinking of- Qemm rather than himem.sys and emm386.exe?
The same company behind desqview (thanks for spelling fix; it was same spelling on desqviewX), was behind qemm-- Quarterdeck. They had windows 3.1 running in a window in desqviewX faster than windows, on bare metal. It was probably due to qemm, but the demo was to show no hit from using desqview.
(Score: 2) by RS3 on Tuesday June 02 2020, @04:01AM
You mean they had MS Windows running in a Desqview "container"? Way cool if so. I don't remember trying that.
Yeah, I actually bought a Qemm license I liked it so much. And worth it because I helped a company to be able to sell their products. The applications's developer was a very surly guy, and his code needed 615K to run, and Netware drivers and some other necessary stuff (scsi & aspi drivers and maybe CDROM) took up too much RAM but Qemm beat it into submission. I wonder what ever happened to those guys... ... ah, Symantec gobbled them up.
(Score: 5, Insightful) by Arik on Monday June 01 2020, @02:58PM (17 children)
This was not my experience at all. I supported Netware 3 and 4 for several years at a couple of different institutions, and found it FAR more stable and reliable than Windows, just night and day. The very first server did crash often, but this turned out to be due to a hardware issue that was resolved within a week or two, and other than that it was always rock solid. I /did/ make sure to only buy hardware that was supposed to be well supported for Netware on these machines, and of course it's quite possible someone who took less care on that end would have had a different experience, as might someone that depended on a buggy module, but I never saw a Netware box that wasn't both noticeably faster and also far more reliable than the Windows machines it served.
The Netware servers that I took care of were not retired for performance or stability reasons. It looked more like bribery from where I sat. The execs asked us to evaluate NT 3.51 as a replacement for our existing servers, and this was a result of a MicroSoft sales force that bypassed the technical people and went right to wining and dining the execs. So we dutifully setup a test bed and ran the tests and it was still nowhere near ready to handle the job. The report went up to the execs, and what came next was a team from Redmond who came in and setup the new servers themselves, after claiming our report just indicated we didn't know how to use NT.
Well that was nonsense (we'd been using it on the workstations for years) but fine. Let them try.
When they came into the office we had one Netware server serving the office, handling email, print jobs, etc. It had always been stable and quick, even during usage peaks.
When the initial MS team left, it had been replaced with TWO NT servers, one dedicated solely to email, another handle all the other miscellaneous jobs, and each of these was significantly more powerful than our Netware server had been. Well, that's a bit of a cheat, but ok, let's see how it works.
Of course, it didn't work well at all. Even with all the extra resources, it was slow at best, and very unreliable. These servers would crash often, or worse yet, just slow to a crawl and start randomly dropping traffic. Emails that we were used to being delivered to headquarters in seconds took several minutes to send, if they went through at all. Want to print? Good luck. Sometimes you had to send the job then reboot the server and then the printer would finally start a few minutes later. Sometimes even that didn't work.
This went on for months, with the same crew from Redmond flying back into town almost every week, taking us off the network for days while they tinkered with their servers. They kept upgrading the hardware too. After many months of this I left the company; and at that point these things were /still/ very slow and unreliable in comparison to what they had replaced. But I understand that not only did the company not pay for any of this, but actually MS was paying us for the deal! Which is why the execs jumped on it. They could quit paying Netware, and MS promised to replace it at no charge, you can see how that was an attractive offer at the time, to an exec who didn't know the difference in the systems anyway.
Did they calculate in all the lost productivity this caused? I doubt it very much. When I warned of exactly what wound up happening, that wasn't considered credible. When my predictions proved true, they didn't learn to listen to me - quite the opposite, it seemed like I was resented, and considered not a team player, for declining the kool-aid on offer.
At any rate, Netware made an effective product, MicroSoft made an effective marketing campaign. Look which one won.
If laughter is the best medicine, who are the best doctors?
(Score: 4, Interesting) by canopic jug on Monday June 01 2020, @04:25PM (7 children)
Netware 3.12 or thereabouts was ridiculously stable. That was appreciated a lot even at the time and became legendary by around the turn of the century.
However, 3.12 came in towards the beginning of the end for IT departments as the IT departments transitions first to M$ shops and later to full-out M$ resellers. That gripe is relevant because the Netware sever never needed any attention, unlike the Windows machines which were always falling over and needed repair or rebooting or both. The Windows assholes got all kinds of unwarranted positive attention from management for saving the day, instead of the pink slips they deserved for having fucked things up. Overtime, those that even knew of the existence of the Netware machines had moved on and managment and the sales team focused on fighting one Windows-related fire after another. However, eventually after many years, the drive on the Netware machine would give out and troubleshooters would end up having to follow cables to rediscover not just where they were located but that the machines existed at all. There are many anecdotes of Netware servers being forgotten in that way and running unattended for years.
Netware's stability, ease of use, and especially client support, was a big sore point for M$. So much so that they used their sales people to propagate a whisper campaign against it and were successful in killing off Novell Netware despite it being so profitable and widely deployed. After Netware was dead and out of the way, M$ settled [nytimes.com] for a rather tiny sum. The killing of Netware did pave the way for Samba to take over, however. M$ had all but replaced the IT departments but there were often one or two on staff who still knew what they were doing and had not moved on. Managers bought M$ junk and expected it to work and leaned on the staff to try to keep it running. That never worked so many, many shops just installed Samba instead and left the M$ machines off to the side. So the managers paid M$ bills, and could brag about being an M$ shop, but at the end of the day were really running Samba to get the job done. But Samba is a different topic.
Back to Novell's Netware, I consider the fact that the ubquity and quality of Netware's filesharing and M$ inability to provide anything even remotely competitive contributed to the general smear campaign against the term filesharing. That happened about the same time as the intrigues against Netware and couldn't have helped the company since its main product was filesharing software at a time where the public was hearing it daily in negative contexts.
Money is not free speech. Elections should not be auctions.
(Score: 3, Insightful) by NCommander on Monday June 01 2020, @05:10PM (6 children)
That article likely is referring to the problems Novell had with GNSS and sign into Novell Directory Services, but there isn't enough context to be sure. I do intend to menthon that if/when I do NetWare 4/5. The version of NetWare demoed here was 3.12 before that existed.
I won't deny Microsoft pulled quite a bit of shit, but NetWare's retail price was much higher than Microsoft's for NT 3.1 and 3.5 and NetWare basically sat on the vine not innovating for over half a decade.
Still always moving
(Score: 3, Interesting) by canopic jug on Monday June 01 2020, @06:19PM (4 children)
Yeah a lot of software was overpriced even back then. Back in the earlier Windows NT days, people knew that NT did not work. It continued the M$ tradition of being slow, difficult to adjust, and very unreliable. Frequent require reinstallations would easily burn up a work day and run into an hour or two of overtime. So competitors, including Novell, could ask for more. It was then Bill turned M$ more into a marketing company and by the late 1990s was actively gaming the press. There were still reviews back then mostly on technical merits. NT5 was getting taken to the cleaners in the reviews. Relatively speaking Netware 5 was doing much better. So by changing the name from NT5 to Windows 2000, he was able to slough off a few years of bad reviews and launch to a clean slate.
It's great to read the article above on Netware. So the hard work is appreciated, though it brings back both good and bad memories.
Money is not free speech. Elections should not be auctions.
(Score: 2) by RS3 on Monday June 01 2020, @10:02PM (2 children)
But, but, Solitaire! ON the SERVER!!! :) and MINESWEEPER!! And hearts and whatever other games they gave you. Novell was frumpy.
And think of all the jobs M$ created!
Netware only had the cool screensaver, and words like "down" and "abend". IIRC you could send fun messages to all workstations.
(Score: 4, Informative) by canopic jug on Tuesday June 02 2020, @06:45AM
And think of all the jobs M$ created!
Or more accurately, think of the the money they misappropriated from real work [wikisource.org] just to struggle harder and harder just to keep up with where they already were. The only employees which benefited were the semiliterate tools hired to fiddle with the Windows servers 24/7 and the empire builders [entrepreneur.com] who hired them. M$ seemed to hit the sweet spot there with the maximum tolerated uneccessary hirings. All others, especially those needing to get tasks accomplished, suffer.
Again it comes down to Bill having made bad engineering acceptable. People took that as a joke with computers since M$ later became some people's first exposure to computers. Sadly, over time people have become accepting of bad engineering all over the place. That is Bill's real legacy.
Netware Directory Services turned out to be another useful service and it scaled nicely. It was easy to use and it worked well.
But as for sending messages to the workstations, that was possible even in early versions of Netware, years before M$ Windows spread.
Money is not free speech. Elections should not be auctions.
(Score: 3, Funny) by NCommander on Tuesday June 02 2020, @10:37PM
NetWare had Snipes [wikipedia.org] included in most versions, although its not on my copy or if it is, I haven't found it. It was shipped in Personal NetWare though. It was a homage to the original inspiration for creating NetWare which was a multiplayer network game on mainframes.
Also, you can mass annoy users with NetWare from SESSION :)
Still always moving
(Score: 1, Interesting) by Anonymous Coward on Tuesday June 02 2020, @10:30AM
But NT5 beta didn't have that until either the last RC or the fucking RTM.
It was a huge nightmare for actually testing or using it without network access, or to install network access when you first needed it.
I remember thinking NT5 was a toy OS, until I ended up spending 300 quid a few years later just to avoid Microsoft's Online Registration on XP by buying a copy... just in time for ATI's driver support to drop on it, and DirectX 9.0c (which wasn't support on Win2K if I remember correctly) Long story short, the last combo is 9.0 or 9.0b and the Radeon HD3xx0 series cards with most software dropping ABI support for it in either 2007 or 2008. ME Didn't get DirectX 9, being limited to 8.1 if I remember correctly, but only got deprecated maybe a year before.
Yay.
(Score: 2) by RS3 on Thursday June 04 2020, @01:35AM
> ...NetWare's retail price was much higher than Microsoft's for NT 3.1 and 3.5 and NetWare basically sat on the vine not innovating for over half a decade.
It's true and makes me sad. What they did early on- mid-80s to mid-90s- was so awesome. I'd love to know the inside story. Now I want to get my hands on Netware 5 or 6 and find out how good it was.
Novell surely should have tried to compete on price. And, they should have made it easier for people like me to be a certified admin / trainer.
One thing I know from the overall market- for whatever reason, MS did a good job of pulling businesses away from GroupWise into Outlook / SharePoint / Exchange / whatever it was. I didn't really deal with any of that sort of stuff, so I don't know the pros and cons, maybe GroupWise did improve but admins didn't update things, or MS just had some features people wanted.
(Score: 2) by NCommander on Monday June 01 2020, @04:40PM (7 children)
I did note specifically that NetWare itself was solid when used with Novell's own software. The problem was when you tried to use it as an application server. However, NetWare was both cooperatively multitasked and ran ring 0. When using MSFT's own software, Windows 3.1 was also stable, and although Win 3.1 did use Ring 3, it suffered a lot more from "one app causes lockup issue" primarily because GUI software is harder to write than console based ones. The problem is entirely with add-ons.
That meant it had no protection against a misbehaving NLM. NetWare did offer it's own SQL database for NetWare and Oracle for NetWare was in fact a thing. I've also seen NLMs for things like adding a web server and more. Same story if you added something like Exchange ontop of it. In general, as long as I stuck to the Hardware Compatibility List, I never had serious problems with NT4 as a domain controller which was much easier to administrate. Exchange 5.5 was a somewhat different story, but Novell didn't offer a mail product in the box.
I'm not sure what you were using for mail. A bunch of mail products (Quarterdeck's comes to mind, since it became MS Mail) used a file share instead of a network protocol like MAPI.
Still always moving
(Score: 2) by Arik on Monday June 01 2020, @05:19PM
I get that structurally they have similar /potential/ for problems with add-ons, I'm just saying in terms of /actual problems in my experience/ the reality was quite different. Windows had constant problems, some of which could be partially ameliorated with good setup, and Netware looked /very/ good in comparison.
"I'm not sure what you were using for mail. A bunch of mail products (Quarterdeck's comes to mind, since it became MS Mail) used a file share instead of a network protocol like MAPI."
I used Mercury when I set things up myself. In the case of the last server although I quickly became responsible for the box it was actually setup by someone at corporate, and worked so well out of the box I may have never even had a reason to find out what it was using. At any rate if I knew I don't remember.
I didn't even remember Quarterdeck made a mail client, and the only reference I could find with a few quick searches doesn't seem to backup your sequence of events:
"The first Microsoft Mail product was introduced in 1988 for AppleTalk Networks. It was based on InterMail, a product that Microsoft purchased and updated. An MS-DOS client was added for PCs on AppleTalk networks. It was later sold off to become Star Nine Mail[1], then Quarterdeck Mail[2], and has long since been discontinued."
https://en.wikipedia.org/wiki/Microsoft_Mail
If laughter is the best medicine, who are the best doctors?
(Score: 2) by RS3 on Monday June 01 2020, @09:55PM (5 children)
It's all about the '386 and the huge penalty for context switches, ring PL switching, etc. Remember we were running 386/25 up to 486/66 in those days, and Novell screamed (fast!), esp. with RAID controllers. Even without RAID, elevator seek was amazing.
Didn't get to read your entire super-excellent article, but Netware also ran flat-model memory- everything in 1 segment/selector, for speed. Being a bit of a hot-rodder, I really liked the speed / efficiency.
Regarding application servers, Novell license costs aside, it would have made sense to run one server as application, and another one for files.
Printers could run directly from the server, or a workstation.
At some point Novell got into GroupWise which included email, task / scheduling, collaboration, etc., but I didn't deal with that very much in those days. I know Netware had some kind of email / messaging system built-in, but again, I didn't run it much (Novell Messenger, and NIMS).
BTW, I had done some .nlm dev. in the mid-'90s.
(Score: 2) by NCommander on Tuesday June 02 2020, @10:16AM (4 children)
I didn't test RAID, although I wanted to. I have no idea how to simulate a realistic drive failure in virtualization; anything I can do would be close to ideal conditions since short of shredding the real HDD, I'm just staying to SMART that the drive has tapped out. A few friends of mine are debating the logistics of testing RAID claims with a couple of hard drives and a rifle, but that's probably a year out.
Novell did some amazing stuff to get the performance they did, and the decisions they made in the context of 1994 do make sense, specifically ring 0/cooperative multitasking. The problem was as processor power increased, those decisions lead to evolutionary dead-ends. I do think NetWare could have been re-engineered to work better as a pre-emptive multitasking server for applications. Looking at the NetWare API, I'm not seeing anything that would *inherently* break for well-behaving NLMs.
That being said, NetWare as a development platform looks like it won't be a lot of fun. GIven non-dedicated NetWare died, the only option for a developer is two machines, or NetWare for OS/2 which could run the server, client, and also Watcom. I also haven't dug up what Novell charged for the SDK. I know Watcom C was the official toolchain, but I can't tell if that was just free in the box, or if you had to fork up for it. Finding any definitive pricing for NetWare has required me to dive into old InfoWorld magazines and hope I get lucky.
The base libraries look rather bareboned; basically a network stack and a C library so you also don't have a lot of niceties to start from.
Still always moving
(Score: 0) by Anonymous Coward on Tuesday June 02 2020, @10:54AM
I don't know exactly whne SMART stuff came onto the market, but it wasn't seriously implemented until either 8 or 10GB HDDs (I have some of that vintage still running, and some older busted models.)
I'll check the 3.1 and maybe 540 gig if they still spin up, but Maxtor or WD definitely didn't have it back then. I don't think the SCSI drives from that era did either, in fact.
(Score: 2) by RS3 on Tuesday June 02 2020, @04:27PM (2 children)
This is an abbreviated response: you can just unplug a drive from the RAID and you'll find out what happens. AR-15 not needed. Normally it will continue to run in "degraded" mode. SCA disks can be hot-unplugged.
Which hw RAID controller are you running?
Netware SDK had to be fairly cheap- company I worked for bought it with Watcom C on my whim. There were tons of .nlms that added myriad libraries / API functionality.
I haven't done a ton of sw dev, but have always wanted to do more. That said, in those days I used Borland 3.1 and 4.5 for the nice IDE colorized syntax highlighting, built-in help, etc., and of course would run the Watcom compiler, which I think was CLI only... too many years ago, too many wildly different things I get into.
I agree that Novell's sw dev. lagged behind CPU / RAM improvements. They did urge people to only use Novell certified .nlms.
I thought I remembered, and searched, and it turns out Netware 5 included memory protection, etc. (Not sure about preemption...) Pretty good writeup: https://support.novell.com/techcenter/articles/nc1998_05a.html [novell.com]
I remember Netware being a very easy and good experience for me, and Windows being a pain. Yes, I like a good GUI like anyone, but some of the most difficult things in Windows are CLI, like "cacls". Ugh!! (I mostly admin Linux in CLI because the few GUI tools suck, at least in RedHat / CentOS they have. Worst- they make you think they're going to work, but they don't.)
(Score: 2) by NCommander on Tuesday June 02 2020, @10:42PM (1 child)
I can't remember what RAID controller it was, just that it was driving some SCSI HDDs because I had to install a spare SCSI card just to see how badly the disks got trashed. As far as I can remember, one of the disks decided to tap out, but the RAID declared that one good, and the other one bad, and shot the good disk in the head. This happened during a system backup because the backup the night of was completely trashed. Fortunately, we could go back to the previous tape.
We ultimately restored Exchange to a piece of junk since it took us awhile to figure out why our system had lost it's mind, and then did the mailbox move dance. I think we moved to NT's software RAID after that experience but I don't remember definitively.
As for NetWare's SDK, it's possible it was included in the box with Watcom at one point. I think OpenWatcom even has it. Trying to trace the history of development tools is close to impossible. I tried that back in Xenix and got lost in a rats nest.
And yeah, I agree with Linux UI tools. That being said, Linux's CLI stuff is great and scriptable. PowerShell still has a lot to learn here.
Still always moving
(Score: 2) by RS3 on Wednesday June 03 2020, @05:02AM
In those days (mid 90s) company was using Adaptec SCSI cards. I chose Mylex RAID controller and they were awesome. However, I don't remember a utility for running tests and rebuilds while running the server... IE, all I remember is the Mylex firmware utility that did all of that stuff, so you had to reboot and get into Mylex firmware. BTW, the servers weren't my idea- company had based on Novell years before I got there. And these were shipping with medical data gathering systems. I know we shipped many dozens of them during my 4 years there. At least 1 had a 100 user license. I kept copies of stuff, including server.exe- the only unique licensed file.
Wow, what a nightmare you had! Sounds like obvious error in RAID controller's firmware.
The Watcom compiler was it's own thing. IE, you could buy it standalone and it had nothing to do with Netware. But obviously Novell liked their software and formed a good relationship with them. I still have all of that stuff... somewhere... The Watcom C reference book is still right here on my bookshelf.
Just before Linux came out, well, before I knew of it, maybe 1994, at a hamfest I bought a box of Unisys Xenix. Still have that somewhere. I didn't do a lot with it. Mostly found a way to download a copy of FoxPro and a few libs and it ran so I could tinker. Back in the day. The good old days... :)
(Score: 3, Insightful) by RS3 on Tuesday June 02 2020, @04:06AM
"At any rate, Netware made an effective product, MicroSoft made an effective marketing campaign. Look which one won."
Yeah, and I've ranted about this many times- that non-technical coneheads make the decisions about such things. MS is good at some things, including semi-technical demonstrations that appeal to the MBA-types. I'm wondering what the world would be like if we tech-types had final say on such decisions.
(Score: 1, Interesting) by Anonymous Coward on Monday June 01 2020, @03:09PM
I managed Netware networks from 30 years ago up til 2007 when new management moved us to Windows. Ugh.
Netware was stable. We had on server that, as a point of pride, hadn't been rebooted in over 3 years. We also ran Word Perfect Office (later Groupwise) on a OS2 box and it just worked. In fact, once, when an extended power failure caused the mail server to shut down dirty it just came back up cleanly.
Our setup included Novell Bordermanager as a firewall and VPN and, while confusing sometimes, it just worked.
(Score: 2) by VLM on Monday June 01 2020, @03:46PM
IPX Novell was a simpler era.
I'm not surprised OP was super frustrated at the struggles of "pushing the envelope" or that "pushing the envelope" in the context of a 2020 feature list was painful. Pushing the envelope of any software in any era has always been painful.
What I do remember of novell in the 90s was it was SO simple if you didn't push it.
(Score: 5, Interesting) by DannyB on Monday June 01 2020, @04:11PM (26 children)
I had forgotten all about CALs.
Oh how I remember how much I laughed at the very idea of having CALs.
But, that leads me to another thought. I remember laughing at the idea that an OS developer would charge developers for development tools. I'm thinking of Microsoft here. Apple had done that earlier, but had eventually seen the light (MPW) that they should give out their tools to encourage developers. Even in the face of competing commercial development tools.
Then speaking of Apple, the iPhone. You have to buy their tools. And it only runs on a Mac, so you have to buy their computer. Then you have to jump through hoops to even get your app into their store. And all this for the privilege and honor of being allowed by Apple to develop for their platform. Contrast with Android, open source dev tools, runs on all platforms, and you can put your own app on your own phone with nobody's permission. To get into the Android Play store you don't have to be approved, you just have to not be rejected for obvious reasons.
But back to CALs. A Linux file server and print server worked. No CALs. If running a Windows workstation, then why should you have to buy a CAL to connect to a Microsoft server? I buy two products from a vendor, and one of the products (server) is already expensive and only has any usefulness to work with the other product (workstation) -- yet I then have to pay yet a third time just to connect the two together -- when the server's only useful function is to connect workstations to it.
But then Microsoft did all sorts of IBM tricks like charging by how many CPUs a server had, etc. Truly a monopolist in every sense of the word IBM.
If you don't like grocery prices now, wait until Trump deports the 'lazy' people who pick it, process it and package it.
(Score: 4, Informative) by NCommander on Monday June 01 2020, @04:56PM (25 children)
CALs piss me off, however, NT AS 3.1 specifically allowed unlimited use. CALs showed up in NT 3.51 I think. Maybe 3.5. UNIX generally was CAL free for the base system, however, UnixWare is an exception. INFORMIX and a few other database servers however required CALs. Oracle's licensing is tangled to figure out, but they usually had some mix of CALs + hardware licensing. AppleShare IP was also CAL free from what I remember, but it was utterly useless except at talking to Macs or light webserver duty.
Developer tools being free is actually a bit of an oddity in the period. Very early DOS included the assembler in the box, and DEBUG could also be used as such. Microsoft Programmers Workshop, MASM, and MS C became paid products, but Watcom C and Borland C helped keep prices "reasonable". In contrast, the SDK for OS/2 was a whopping $3k USD. I can't remember if Sun used to charge for Studio pre-Solaris 11, but HP's acc and AIX's xlr were both things you had to pay for. I can't find detailed information if MIPSPro for IRIX was free or not.
For MPW, you're misremembering history. MPW didn't become free software until at least the PowerPC era, I want to say Mac OS 8, but possibly back with OS 7. At the time, it was both expensive, and CodeWarrior plus symnatic were popular for both 68k and PowerPC both wildly popular choices. Very early Macintosh (probably up to the Macintosh Plus if not as late as the SE) was actually coded for by Apple from Apple Lisa with a modified Workbench and MacCom since early Macs had no concept of virtual memory, and were badly starved. I can't find a price list, but a few articles like this one [wanderingcoder.net] do mention it was fairly late.
Course, Apple then has the $99 developer program for iOS, though you can now sideload an app for a few days now without ponying up. The entire iPhone walled garden combined with Mac OS X 10.5 being kinda shit soured me on Apple products. I used late PowerPC macs and the first Intel ones before I finally jumped into Linux full time.
IBM was remarkably reasonable with OS/2 licensing. If you really want to see highway robbery, I'd take a look at mainframe pricing.
Still always moving
(Score: 2) by DannyB on Monday June 01 2020, @05:08PM
You could be right about that.
We did buy each developer MPW while it was commercial. I also remember a monthly stack of paper and a CD ROM from Apple. Eventually they sent ony CDs with great names that were spoofs on movie titles. "Night of the living Disk!"
I do distinctly remember MPW becoming free. And at that time I think I was already using CodeWarrior from MetroWerks. Later tried Think C, then later Symantec's C++ development tools which were great -- until version 8.0 when it sucked. Unstable. I think I recall even getting it to generate wrongly behaving object code. And I had the distinction, years earlier, of having discovered, documented and reporting a Pascal compiler bug to Apple.
I remember how I loved Macintosh Common Lisp (about 1989 or 90), and realizing as the Power PC took hold, that MCL wasn't going to get ported to Power PC any time soon. It ran under 68k emulation. But I had already given a lot of thought to how to implement lisp on 68k, realizing that none of what I planned was likely to work on PPC.
If you don't like grocery prices now, wait until Trump deports the 'lazy' people who pick it, process it and package it.
(Score: 2) by DannyB on Monday June 01 2020, @05:14PM (23 children)
IBM's mainframe behavior in the 50's, 60's and 70's was what I was thinking about when I mention monopolist. Microsoft copied many of IBM's tricks exactly.
Don't allow secondary markets. (eg, don't provide an install disk)
Segment your market. (Vista Home Basic, Vista Business, Vista Tartar Control, Vista Extra Whitening, Vista with Baking Soda, Enterprise Edition, etc)
If competitor pops up in one segment, then use low, low predatory prices only in that market segment (Windows Small Business Server) to wipe out the Linux competition for small business servers. Eventually when competitor is gone, you can charge out the nose again.
Do anything legal, or illegal to maintain the monopoly. Even if convicted and having to pay a gigantic fine, if you still have a monopoly, that gigantic fine is just a cost of business paid through monopoly pricing.
Fear Uncertainty Doubt
Undocumented iinterfaces
And more
If you don't like grocery prices now, wait until Trump deports the 'lazy' people who pick it, process it and package it.
(Score: 2) by NCommander on Monday June 01 2020, @05:21PM (22 children)
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
(Score: 2) by Reziac on Tuesday June 02 2020, @02:32AM (16 children)
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)
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)
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)
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)
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)
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)
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)
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)
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
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)
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
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)
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)
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)
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)
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
"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)
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.
If you don't like grocery prices now, wait until Trump deports the 'lazy' people who pick it, process it and package it.
(Score: 2) by Reziac on Tuesday June 02 2020, @04:21PM (1 child)
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: 2) by NCommander on Tuesday June 02 2020, @10:09PM
The firewall was hidden in Proxy Server, and I'm not entirely sure it was a winsock level firewall; I haven't had a chance to take it apart yet.
Still always moving
(Score: 3, Interesting) by NCommander on Tuesday June 02 2020, @10:08PM (1 child)
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
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.
If you don't like grocery prices now, wait until Trump deports the 'lazy' people who pick it, process it and package it.
(Score: 3, Interesting) by DannyB on Monday June 01 2020, @04:19PM (5 children)
I remember in about 2001 hearing a story . . . but I was able to actually google evidence of it, so I'll post links . . .
Missing Novell server discovered after four years [theregister.com]
And this [arstechnica.com], which is a forum post describing a TechWeb article of the same thing as above . . . but alas the linked TechWeb article has been memory holed.
If you don't like grocery prices now, wait until Trump deports the 'lazy' people who pick it, process it and package it.
(Score: 2) by DannyB on Monday June 01 2020, @04:20PM (4 children)
Doh! I see that in the article now. So I'm not the only one who remembers.
If you don't like grocery prices now, wait until Trump deports the 'lazy' people who pick it, process it and package it.
(Score: 2) by NCommander on Tuesday June 02 2020, @10:08AM (3 children)
It's not the only "walled in server" I've seen, but that article always stuck in my mind, and it's the original source of the story as far as I can find.
Still always moving
(Score: 2) by DannyB on Tuesday June 02 2020, @01:49PM (1 child)
I didn't know any other servers had ever been walled in. The netware server is the only such story I have any memory of.
Interesting that there were others.
Someday it will be an underground data center that got closed off in an earthquake, forgotten about, and continued to run for millennia. Gradually taking over all the human jobs on the surface.
If you don't like grocery prices now, wait until Trump deports the 'lazy' people who pick it, process it and package it.
(Score: 2) by Reziac on Tuesday June 02 2020, @11:55PM
Not walled in, but a sidebar link led to this:
https://www.theregister.com/2016/01/20/486_fleet_still_in_production/ [theregister.com]
"The server is an HP Netserver LX with dual 200MHz Pentium Pros, 128MB of RAM, runs Windows NT 4.1 and Jake reckons it was purchased in 96 or 97.
...
The uptime shown when NT rebooted was 15 years, three months, 13 days."
And there is no Alkibiades to come back and save us from ourselves.
(Score: 2) by Reziac on Tuesday June 02 2020, @04:36PM
Well, you could consider space probes to be walled-in servers... what's Voyager got on it now, 40 years??
And there is no Alkibiades to come back and save us from ourselves.
(Score: 3, Interesting) by SDRefugee on Monday June 01 2020, @05:22PM (2 children)
I started my career in IT back in 1988 with a small company that installed Netware 2.X on Arcnet for a medical research facility. The company also provided XT clone workstations (640k ram/20MEGAbyte MFM harddrives/Hercules Mono video). By 1990 the company had folded and I moved to another company that was doing Netware 3.11 with whitebox Windows 3.11/DOS systems.
America should be proud of Edward Snowden, the hero, whether they know it or not..
(Score: 2) by NCommander on Tuesday June 02 2020, @11:35AM (1 child)
I'm actually trying to track down some ARCnet equipment because I'd like to do a retrospective on networking pre-Ethernet, and I have an eBay watchlist. ARCNet though is still sold new since its still ticking in SCADA, but at $600 USD per NIC, it's a bit hard to justify on my non-existent budget.
Also finding early NetWare is virtually impossible. The one copy of NW2.0 that surfaced had the NE1000 driver disk literally disintegrate. Fortunately, the 3c501, and arcnet disks did survive. Part of that is probably because early NetWare needed keycards, or dedicated hardware which is why the media has never surfaced. It likely got junked with the machine.
Still always moving
(Score: 2) by Reziac on Tuesday June 02 2020, @04:40PM
No idea if sufficiently complete, but...
https://winworldpc.com/product/netware/2x [winworldpc.com]
And there is no Alkibiades to come back and save us from ourselves.
(Score: 3, Informative) by juggs on Monday June 01 2020, @10:07PM (1 child)
CAUTION: This post is delved from the dusty regions of my memory of the time so some bit rot is more than possible!
Back in those days I worked as "the IT, tech pre-sales, make it work for the customer guy" for a company that sold / leased printers, copiers, all things reprographic and document management solutions for the then trending "paperless office".
The copiers had the option of working as printers also with the optional addition of an internal network print server - giving nice things to the user like 50ppm, collate, duplex, staple etc. So rather than print out one copy on their local LJ3 or LJ4 then walk to the copier to do that, it was all selectable from the print options in Windows.
Installed many of these things into Netware 3.x and 4.x environments. They did not need to be physically attached to the Netware print server in either case, they plugged into the LAN.
Typically the copier print server could talk Netware 3 or 4, LPR, RAW, SMB (NETBIOS), AppleTalk and in some cases emulate HP JetDirect. The print engine itself would always support PCL5 (or maybe it was PCL4 for earlier ones) with a very expensive optional add-on board to support PostScript if needs be (probably a licensing thing back then and largely only bought by Mac only environments).
For Netware 3.x you'd just print out the Network Config page from the device which had a preset printer name, then hop on the Netware Print Server and use PCONSOLE to add a new printer and queue which then became discoverable to client PCs etc.
For Netware 4.x I seem to remember there was a little bit more config to do on the printer / copier print server to specify what NDS context it was going to exist it and what it was going to be called - achieved via telnet or web interface. Then hop onto NDS management tool and add the printer and queue in the matching place in the tree.
I don't recall Netware having any automagic way of pushing print drivers to clients when they connect to a print queue (a la NT4), I think we just poked something into the user login scripts to install the driver as one time deal. Although you could use any generic HP style PCL driver to print from the default tray, if you wanted to be able to use all the trays, collation, binding and stapling etc. options the client PC needed the driver.
As for Unix. Plenty of the Netware shops I installed these things to had Unix boxes also. There was never an instance where they desired to print via the Netware print queue, we set them up as LPR printers over IP. The options for collate, staple etc etc could be controlled by inserting escape control codes (raw PCL I guess) into the start of the print jobs which the Unix botherers of the day seemed to have absolutely no problem setting up, I left them to it :D
It all seems so long ago :/
(Score: 2) by NCommander on Tuesday June 02 2020, @10:14PM
The addon board is a weird thing, I actually remember that because we upgraded the memory in the LaserJet once. HP had the LaserJet 4, and the LaserJet 4M which was for Macintosh but the only real difference was the postscript board. There was also the 4N for Network and 4MN for both; the card you stuck in the printer determined what network it could use, I remember there was some really crazy way to get onto the card initially to configure it, probably abuse of ARP or similar.
Still always moving
(Score: 0) by Anonymous Coward on Monday June 01 2020, @11:56PM (1 child)
but I get nostalgic for software packages sold in a biggish cardboard box containing full printed documentation/thick manual(s). Even if it contains only a single floppy disk, it feels like you are paying your good money for something with some substance.
(Score: 3, Interesting) by NCommander on Tuesday June 02 2020, @11:37AM
At the time, I embraced digital distrubition, but I've come to realize that there's a certain aspect of having physical disks and media that really goes a lot longer. I've ripped my ISOs for backup, but I'll still use the original media if I have it. I even put an optical drive in my rig for expressly this purpose, with a USB floppy drive sitting ontop.
Still always moving
(Score: 2) by Reziac on Tuesday June 02 2020, @02:24AM (2 children)
This was both amazing fun and utterly terrifying... today's networking doesn't know how easy they have it!
So, when will you do Netware 5.x and 6.x? I think it would be fun to compare in light of this foray into ancient incantations.
And there is no Alkibiades to come back and save us from ourselves.
(Score: 2) by NCommander on Tuesday June 02 2020, @10:01AM (1 child)
It's mostly when I manage to obtain a copy, and the necessary licenses.
Still always moving
(Score: 2) by Reziac on Tuesday June 02 2020, @04:10PM
Ah. Look forward to the day. They are out there, tho dunno about price for legit. Wonder if Microfocus would lend you review copies, if you reviewed current as well?
I have copies of 5 and maybe 6 here somewhere (from attending Novell's seminars), which I keep meaning to unearth and try out. Some year... there were a lot of copies given out, and they came with a license; surely some will show up on eBay...
And there is no Alkibiades to come back and save us from ourselves.
(Score: 1, Interesting) by Anonymous Coward on Tuesday June 02 2020, @12:29PM
To this day still prefer how eDirectory and NSS worked over AD and NTFS.. less bloat and better inheritance models for permissions.
(Score: 3, Informative) by Deeo Kain on Tuesday June 02 2020, @03:02PM
"At the time, thicknet 10BASE2 and Ethernet hubs dominated the low-cost market."
10BASE2 was the thinnet, thicknet was 10BASE5.
(Score: 1) by jman on Wednesday June 03 2020, @12:37PM
Nice story. In the early-mid 90's I'd been out of the service for almost a decade, and working as IT admin for a theater company in Houston (went there for a couple of days temp data entry, ended up staying for some years).
We had a 2.12 server in an unbecoming Compaq box, amber screen. The network was a star topology with Thomas Conrad 2.5 Mbps cards. No built-in MAC. Set dip-switches wrong on one card and you bring the network to its knees.
It was time to upgrade to 3.12, and while Netware wasn't that hard to figure out, I'd never taken any sort of class on it, so was a little nervous. What if I borked things in the upgrade? This was years before one even had the spare storage, must less easy-to-run apps like Clonezilla, to image your system prior to major fiddling.
Fortunately, all the hand-wringing was for naught, and the upgrade went smoothly.
A year or so later the office got broken into. That fancy new HP Laserjet 4? Gone. Most of the PC's? Gone.
That unremarkable looking Compaq box sitting in a corner of the supplies room? The place where all our data lived? The worst machine in the building to lose? Untouched. Why would anyone bother taking it? It looked like it had a moldy old 286 inside. Had been warning the bosses about backups; the next day I got them to splurge on an then-expensive tape system.
Miss the snake screen saver, and that it just didn't need rebooting. When I left I think uptime showed 1,300 days or so, corresponding to when that 2.12 - 3.12 upgrade happened.
The shop did eventually send me to a Novell class once, and I sat with a small group of other techies, each with a screen, each with Admin rights to the server. Didn't really learn much I hadn't already picked up on my own. The guy in front of me kept thinking it was funny to drop my connection so I'd have to log back in. No prob. After the third time, droped him, then as I was an admin, locked his user. When the teacher said to follow the next step and he couldn't show his work, it came out what he was doing. I got chastised just a hair for dropping him, but also kudos for thinking to prevent him from doing it to me again.