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.


White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState