Byte came to me and said, we want to know the ugly truth. We want you to crash Microsoft Windows, IBM OS/2 and the Apple Macintosh OS, and tell us what that shows about the architectural weaknesses of each of the major personal computer operating systems.

This was mid-1995, when the sun cast no shadows in the popular computer press in the United States. The hype that these products were receiving then was breathtaking. I had founded BugNet the year before, though, so I knew where the bodies were buried, and happily set about exhuming them, sometimes from mass graves.

The thing that impresses me most looking back at this piece, though, is the little Fact Box that ran with it. It told how to get in touch with the companies discussed in the story, those being BugNet, IBM, Microsoft and Apple Computer.

In November 1995, only BugNet had a Web site and e-mail contact listed. IBM, Microsoft and Apple Computer had no Internet presence at all yet. That's how early I took BugNet to the Web.

-- B.B.

Thar she blows --breaking Windows as illustrated by Bob Robinson for Byte.

ALTHOUGH THEIR FANS speak of them in almost transcendental terms, the major desktop OSes sometimes exhibit all the rigor of a tube of toothpaste: You squeeze here, it bulges there; you squeeze there, it breaks. It's almost axiomatic in computer technology, of course, that every strength is simultaneously a weakness, and nowhere is this more apparent than in the crash performance of the major desktop OSes.

Under stress, Windows 3.1, Windows NT 3.5, OS/2 Warp, and Mac OS 7.5 (the PowerPC and Motorola 68000 versions) are all vulnerable to their own particular brands of system failure. They are often called General Protection Faults (GPFs) in the Windows world and system bombs on the Mac side. These flashes of woe (or whoa) typically render the active software application unusable and can freeze the whole system solid, requiring rebooting. As a bonus, you probably lose whatever you were working on, too.

Sometimes seemingly random system failures can at other times be replicated by following specific procedures, with near-scientific reproducibility. The following tour of the shores of computer hell is offered not for the sake of mayhem (or, at least, not for mayhem alone), but for what it reveals about the workings of various desktop OSes and the state of OS development. Forewarned is forearmed.

Breaking Windows

To crash Windows 3.1: Simply open and close Windows applications. Repeat a few dozen times, or until the Black Screen of Death appears.

The most popular OS is also the one that's most prone to total system meltdown. In fact, one of the dark facts about Windows is that you can cause Windows 3.1 and Windows for Workgroups 3.11 to crash simply by using them enough.

Windows 3.x is notoriously susceptible to potentially fatal memory leaks in two crucial 64-KB resource heaps used for system operation: USER.EXE and GDLEXE. It's common for Windows applications to consume, or leak, memory (i.e., releasing less memory back to the system when closing than they took when opening).

Microsoft estimates that Word for Windows 6.0 and Excel for Windows 5.0 both leak about 6 percent of system resources whenever applications are opened and closed. Keep this up long enough, and the OS will choke-asphyxiated by lack of memory-and the system will crash. Thus, simply opening and closing enough Windows programs can eventually exhaust system memory and produce a GPF -- even if you've got 100 MB of RAM installed.

There's an almost-infinite number of ways to bring on system-resource crashes in Windows 3.x. It's particularly (and ironically) easy with many Microsoft applications. For instance, if you insert a series of Microsoft Graph 5.0 objects into a Microsoft Word for Windows 6.0 document, you lose system resources every time you do so, until you eventually crash.

Many Windows users exit from and restart Windows all day, not for the cool breeze of the Microsoft logo blowing by, but to replenish the depleted system resources on their machines. Although they may start out with 80 percent or more of free resources, several hours of hard use can leave them on the wrong side of the perilous 50 percent line, even with no applications open. One of the great attractions of Windows 95 is that it reduces-but does not eliminate-this problem.

Windows NT, a true 32-bit multithreaded OS, promises much greater stability than Windows 3.1, but it has still singed a few eyebrows along the way. Here's a recipe for a quick Windows NT disaster: With either Word for Windows 6.0 or Excel for Windows 5.0 running under Windows NT 3.1, close the program, reopen it, minimize it, and then quit again. Then listen for the splat. Microsoft acknowledges that this particular GPF is the result of a bug-not a feature-in the Windows-on-Windows subsystem memory manager in KRNL386.EXE.

In both Windows NT 3.1 and 3.5, available memory can also become exhausted if more than 100 threads or processes are launched simultaneously. The reason? The great insulation of applications from each other, which is one of NT's virtues, requires system overhead that can overwhelm the system. So, to protect against the sort of bumper-car GPFs that plague Windows 3.x, Windows NT introduces at least the slim possibility of another sort of calamity. "Quis custodiet ipsos custodes?" (translation: "Who shall guard the guards themselves?") is what you're probably saying to yourself at this point.

Protection ... for a Price

OS/2 Warp, Windows NT's main highend 32-bit competitor in the OS wars, has trimmed its sails in a somewhat different fashion. One of OS/2's virtues is that it's more sentient about hardware than Windows is. It can actually tell if your system has a bad memory chip, a floppy drive controller heading south, or even a loose add-in card.

But OS/2's hardware intelligence has a downside. Here's a way to quickly produce the "trap 0002" or "trap e" meltdown in OS/2 Warp-and probably burn up thousands of dollars in consultant fees, too. Open up the case on the system and slightly loosen one of the add-in cards (a network interface card [NIC] or modem will do nicely). Don't take the card out; just loosen it a little.

You now have the makings of an exquisite little bit of misfortune. If you do it right, on a dual-boot machine you will then be able to run DOS just fine, but when you try to run OS/2, you'll get a black screen rudely slammed in your face.

Consultant Chris White, who's based in West Sacramento. California, remembers running into this exact problem. "DOS ran fine, but I kept getting these bomb-outs all the time in OS/2," she recalls. It turned out that this was the beginning of a hardware failure that ultimately cost a great deal of lost data. "OS/2 was trying to warn me, but I didn't understand until it was too late," she explains. "At the time, I was just furious that the system would not work."

Also, while shielding applications from each other, as Windows NT does, OS/2 does not shield the OS from errant code as fully as NT does. A good deal of Warp code and data reside in portions of memory that are distressingly writable by all applications, which opens another door to memory conflicts and system crashes.

Sys! Boom! Bah!

Meanwhile, the Mac, like Windows, has its own heaps of memory trouble. Some Mac users report encountering strange names and arcane text on their screens during particularly showy system failures. These include the following:

_Jackson
+0000 408314A *Debugger
+0002 408314C NewHandle, Immed +0004 408314E BNE.S DisposeCIcon+0032

These are vestiges of the original Mac development process. The name Jackson, for instance, is an abbreviated label for _JacksonPollock, the development code name for Color QuickDraw.

When Mac OS 7.5 users see the name Jackson amid the digital debris, they are probably in the grip of System Error 25, which can also generate out-of-memory errors and the bomb dialog box if MacBug is not installed. Mac System Error 25 occurs when memory stacks and heaps collide. This is commonly caused by an improper calling sequence by an application, prompting the stack to grow until it overruns the heap. (Boom!)

Another type of memory issue causes system bombs on .classic Motorola-powered Macs. It results from the code-swapping model that's used by Mac OS 7.5 when virtual memory or RAM Doubler is turned on.

Unlike the PowerPC version of Mac OS 7.5, the 68000 chip version-segments code so that it doesn't have to be loaded into memory all at once. This is an advantage in some respects (especially on machines with limited memory and disk space), but it can lead to situations where there isn't enough memory left to load a particular program's code into RAM when the time comes. (Bawoomba!)

PowerPC machines running Mac OS 7.5 are designed to overcome this problem, but in the process they introduce a new type of crash. The PowerPC version of Mac OS 7.5 doesn't segment and swap code, and therefore it requires that enough memory-virtual or otherwise-be available to load a program's code into memory all at once.

To crash Mac OS 7.5 on the PowerPC: To crash a PowerPC system with less than 16 MB of RAM, all you have to do is turn off virtual memory and RAM Doubler, and then reboot the machine and try to run Adobe Photoshop. (MacSplat!)

Crash-Test Dummies?

So, what's the moral of all this sorrow? It's not necessarily that every desktop OS is a disaster waiting to happen, nor that everyone's data is doomed. The problems discussed here do not plague every desktop user every day. In fact, they are rare enough that many users may never see them at all.

Yet in a general sense, the crash characteristics of the major desktop OSes reveal some fundamental OS verities. One is that, like military generals, OS designers often seem to be fighting the previous war (e.g., Mac OS 7.5 for PowerPC versus Motorola 68000, or Windows NT versus Windows 3.1). Another is that the major OSes are all essentially involved in the same trade-offs (or deals with the devil) when it comes to protection against showstoppers. Each has gleaming strengths, and each has potentially mortal weaknesses.

Users should remember that each OS represents a real-world compromise. And you know what the real world is like.

"Crashing the Party" originally appeared in the November 1995 issue of Byte.
© Copyright 1995 Bruce Brown