Windows 2000 Professional's Minuses Outweigh Plusses in Five-Day Ordeal

As Mark Kellner wrote recently in the opening of his widely cited Los Angeles Times column ("Linux's Minuses Outweigh Plusses in 14-Day Trial", published on 12/28/2000), here's the story so far.
Day 2

There's a pattern here and I see it clearly now: I make my worst decisions in the morning. As dawn broke on Day 2, I resolved that I would damned well get this system running, even if my hardware wasn't officially labeled as compatible. From Linux, I've learned that it's often possible to get quasi-compatible hardware running with a bit of tweaking; after all, Windows 2000 did install and it was running. The decision seemed sensible at the time.

First, I tackled the SCSI adapter. It's a ridiculously simple ISA adapter, a Zip Zoom adapter. The Adaptec chip identified it as an AHA-1502, but the Windows Hardware Wizard doesn't list an AHA-1502. It does, however, list an AVA-1502. After spending a couple of hours doing an exhaustive web search, I found out that the Windows 2000 AVA-1502 driver is really the driver for the AHA-1502; it is, indeed, the Sparrow driver, which Linux users know and configure as the AHA-152x. And it worked.

Next, I tackled the video adapter and sound card. Windows 2000 didn't report any resource conflicts, but I discovered--after another four hours of experimentation--that the adapter and sound card seemed to be competing for the same memory address. I recall hearing that adapter manufacturers often fail to document the full range of their devices' resource usages, and my experience seems to bear this out. (Now I know what they mean by "Plug and Pray.")  After remapping the video adapter's memory addresses, I had everything working (or so I thought). I shut down the system and called it a day.

Day 3

With what I thought to be a working Windows 2000 system, I began the next day by installing my  copy of Office 2000 Premium, a process that ate up a couple of hours. Still, it went very smoothly and by noon on Day 3, I believed--stupidly, naively--that I was ready to get back to work. I fired up Word, started to write, and...Zap! The dreaded Blue Screen of Death, with the horrifying message "IRQL NOT LESS OR EQUAL".

To a competent user such as myself a message like this presents no special difficulty. One quickly deduces that the IRQL, whatever that may be, is too large. It must be less than or, at the maximum, equal to, and it is not that way now. Logic is indeed a powerful tool, is it not?  But there is just one problem. The phrase in question has no object, in the grammatical rather than the computational sense of the term. Less than or equal to what?

An hour of searching the Windows Knowledge Base turned up a troubleshooter, which indicated, as if I didn't know, that the problem was most likely due to an incompatible adapter. Still, I tried tweaking the adapter settings manually, hoping I could figure out where the conflict was occurring. Click, reboot, crash, Blue Screen of Death. Click, reboot, crash, Blue Screen of Death.

There comes a time when a rational person must say, "Enough!" Instead, I made yet another boneheaded decision. I would continue. Damn the resource conflicts, full speed ahead! The rationale was that I'd already spent two and one-half days on this quest; I wasn't going to quit until I succeeded. Dimly, I perceived that I could well spend another two and one-half days in futility, which would compound the damage, but I dismissed this thought from my mind. And why not? Marginally compatible hardware has never stopped me from getting Linux running successfully. In an attempt to pin down the problem, I spent hours working through the testing procedures suggested in the Knowledge Base troubleshooter, all without success.

Since I was reasonably certain that the problem wasn't being caused by any of the adapters, there was only one remaining possibility: motherboard incompatibility. I wasn't going to be able to get Windows 2000 working without upgrading my motherboard's BIOS.

A web search disclosed that my elderly motherboard's manufacturer was still in business, and I found that a BIOS upgrade was indeed available. Unlike the BIOS upgrades for some of the newer boards, though, the accompanying blurb said nothing about Windows 2000 compatibility. Still, I decided to give it a try; the new BIOS was designed to fix system hangs after certain memory paging events, which seemed a likely explanation for the problems I'd experienced.

I followed the instructions religiously; really, I did. I rebooted with a floppy, launched the BIOS upgrade utility and watched in horror as the utility updated all but one segment of Lothlorien's BIOS. And there it hung. For hours.

Finally, I gave up and switched off the power, knowing full well what the result would be. When I turned it back on, Lothlorien's communication organs flashed randomly, like a zombie who's just had his brain ripped out. The screen? Blank.

It's the end of the third day. With Linux, I had a fully functional computer. Now I have a pile of useless junk.

There followed a fit of rage. I yelled. I cursed. I made a big stack of every Microsoft product  I could find, piled them up in the middle of the floor and made ready to jump up and down on them until they were mashed beyond recognition.

Just in time, the words of Jimmy Buffett came to mind: "Hell, it could be my fault." If you don't believe Microsoft when they say that you shouldn't try to run Windows 2000 with incompatible equipment, you've only yourself to blame.

Windows 2000 just isn't like Linux. With Linux, hardware compatibility comes in degrees, as we all know from the famous Red Hat compatibility lists; a moderately skilled user can get any marginally compatible adapter working with a bit of tweaking and a little help from the community. With Windows 2000, apparently, it's a Boolean, either/or thing. If the hardware ain't on the list, it ain't compatible. Period.

So it was my fault all along.

The Microsoft products survived. But it was a close call.

______________________

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix