The Defacto Hardware Monopoly

BeOS, Linux Users Change Industry from the Inside

People use alternative operating systems for a reason. Not just to be different (though that's often part of the impetus), but because they quickly discover how many things they can do that they can't do in Windows or MacOS. But you can't do much in an alternative OS if you can't get it running on your hardware. Windows users take for granted the fact that Windows will work (perhaps after some wrestling) with any hardware they can throw at it. BeOS and Linux users don't have the luxury of making that assumption, due to the huge momentum of Windows-centric inertia that pervades the hardware industry.

While the Department of Justice trial focuses on issues like browser integration, the real point of the trial is often lost in all the hubbub: The hardware industry is, by necessity or by choice, beholden to Microsoft. It's one thing to see an "Intel Inside" sticker on a new machine, but when I see hardware labeled "Designed for Windows 98" or "Windows 98-compatible," a shiver of frustration runs up my spine. Since when should hardware care what operating system it's working with?

The Insidious WinModem

By definition, it seems to me, hardware should be operating system-agnostic. Hardware built to work on the x86 architecture should not care which operating system it finds itself in at any given moment. The whole concept of the driver is to provide an abstraction layer so that any hardware will work under any OS. Explain to me, then, the existence of the so-called "WinModem." For those who haven't run up against these at some point, the WinModem is really just half a modem -- a card with a DSP and a phone jack, but none of the usual telecomunications chips on board. Instead, it uses the system processor(s) to do all of the hard work. The catch is that it utilizes Windows-specific API calls to accomplish its task.

Because this hardware is not operating system-agnostic, it can't be made to work under BeOS or Linux, or under any other x86 operating system, for that matter. BeOS and Linux users who purchase a machine with a built-in WinModem are forced to spend extra money for a standard modem for their communications needs. The WinModem, to me, represents the single most glaring example of the hardware industry bending over to please Redmond (and to shave a few pennies at the expense of their integrity). The WinModem also taxes Windows' performance unnecessarily, but that's another matter.

The fun doesn't stop with WinModems. The entire Plug-and-Play specification was designed to work with Microsoft Windows as well. PnP isn't quite as egregious as the WinModem, because PnP hardware can be made to work under alternative operating systems, though OS designers have to work around its limitations. But the fact remains that when an operating system is intelligently designed, hardware can be detected and have its resources properly assigned without PnP. The PCI bus makes dynamic resource assignment comparatively trivial for the OS. The fact that that PnP is built into so much hardware means OS designers are forced to find ways to work with what is essentially a Microsoft specification at a very low level.

Share Your Toys

Let's leave WinModems and PnP out of the discussion for a moment, though, and imagine that all hardware was truly OS-agnostic. That would leave us with the simple matter of obtaining drivers. But as Linux developers and users have known for nearly a decade, and as Be developers and users have discovered over the past two years, there are only three ways to obtain a device driver for any particular piece of hardware. Either 1) The vendor jumps out of Microsoft's bed and decides to develop drivers for alternative OS vendors, or 2) The manufacturer hands over the documentation developers need to write clean drivers on their own, or 3) Developers reverse engineer the driver, working backwards from what can be deterimined by looking at the hardware's low level output.

The first case is, of course, vastly preferable. It means the OS developers and the hardware vendor both obtain a larger user base, enjoy the many benefits of open communication, and can exploit the full range of any given hardware's capabilities. The second method is acceptable, but many hardware vendors consider their technical specifications to be their crown jewels. They fear that handing out the spec could lead to a competitor learning and possibly stealing their secrets. Piffle. The hardware industry moves too fast for this to be a genuine consideration, and most similar hardware products move more or less in lockstep with one another's feature sets anyway. It's a weak argument against sharing specs with OS developers, but is, unfortunately, still the dominant attitude. Fortunately, this state of mind is slowly changing, in large part due to the constant prodding of the alt.os user base.

If a vendor won't release specifications, reverse engineering often ensues. While most hardware can eventually be made to work this way, it's often impossible to utilize all features of any given component, or to extract its full performance potential. It also sometimes means that ill will is generated between the group doing the reverse engineering and the hardware vendor, which may make it more difficult to get specs in the future. Oh, and did I mention that reverse engineering sometimes doesn't work at all?

The Irony of it All

The upshot of all this is that BeOS and Linux users must choose their hardware carefully, and can't simply take for granted the fact that all of their hardware will work under their system of choice. Result: They get to use a superior OS that doesn't work with hardware supported under an inferior OS. The BeOS and Linux worlds have coped with the situation admirably. The list of supported Linux hardware these days spans just about everything but the very latest and greatest. The list of supported BeOS hardware is smaller, but is growing at a rapid rate, thanks to the tireless efforts of the Be engineering team and 3rd-party developers. But why aren't hardware vendors developing their own drivers for alternative systems? (It happens, but far too rarely).

Consider the irony: Microsoft has endless mountains of money and engineering talent, but doesn't have to develop a single driver; vendors do it for them, and provide the drivers for inclusion on the Windows installation CD. Meanwhile, Be has less than 100 engineers, extremely limited resources, and is forced to do driver development on its own. Releasing technical specs is a good first step, but hardware vendors who don't spend the few days it would take to develop a driver for systems other than Windows do themselves and their potential users a disservice. In the process, they (perhaps unwittingly) play into the hands of the de facto monopoly and make it more difficult for users to make their own OS choices.

The Far Reaches of the Defacto Monopoly

The crux of the biscuit, of course, is that hardware vendors are driven by market forces just like any other company. It's all about numbers. Executives don't give a tinker's cuss whether BeOS or Linux can run circles around Windows. They care that 90% of their users are running Windows. Their job is to address their installed base, not to spend time and money (not that it would take much effort, for chrissake) developing for some marginal fraction of the computing underground.

Note to hardware vendors: Windows is just an option for your users; one of many available. By treating Windows as if it were the only OS that matters, you make it so.

The only solution is to grow the installed base in order to convince the executives that alternative systems are worth their while. But it's hard to grow the installed base when your alternative operating system won't work on the hardware the user already owns. It's the quintessential chicken-and-egg problem, and to me it symbolizes the defacto Microsoft monopoly in action, in a way that issues being raised in the halls of the DOJ do not. This is not the kind of monopoly created by unfair business practices. It's the kind that's caused by sheer momentum and inertia. A railroad train takes a full mile to stop, and you can't turn an ocean liner on a dime. Systems like BeOS and Linux just have to keep playing the role of tugboats, pushing and pulling at every corner of the industry until it learns how to play reasonably and fairly.

BeView Content Archives