Archives
 
 
 
  Special
 
 
 
  About Us
 
 
 

Newsletter
Free E-mail Newsletter from BYTE.com

 
    
           
Visit the home page Browse the four-year online archive Download platform-neutral CPU/FPU benchmarks Find information for advertisers, authors, vendors, subscribers Request free information on products written about or advertised in BYTE Submit a press release, or scan recent announcements Talk with BYTE's staff and readers about products and technologies

ArticlesPlug and Play


September 1994 / Editorial / Plug and Play

An archaic PC architecture leaves us with the albatross of compatibility hanging from our necks

Dennis Allen

The most frequently heard phrase in the computer industry today, plug and play, is most often used to define what computers are not. That is a sad commentary on the state of computing, and the outlook is only a little brighter. While we all want a plug-and-play world, getting the PC platform there is not going to be a fast or easy process.

The reasons are many, and they are centered on a desire to maintain compatibility with hardware that was engineered in the early 1980s. Intel and Microsoft are leading a commendable effort to get the industry to adopt a set of standards rightly called Plug and Play. The problem, according to Tom R. Halfhill, a BYTE senior news editor and author of our cover story, is that moving t o Plug and Play ``won't be painless, won't come cheap, and will likely take years.''

It's a move in the right direction, and there isn't anything particularly wrong with the Plug and Play standard--it's probably the best it can be, given the archaic PC architecture it must support. The problem is that if the transition will take years, perhaps moving to another platform altogether might make more sense.

Ah, but market demand is fickle, and as Halfhill points out, previous attempts to move to a plug-and-play kind of world with Micro Channel architecture and EISA have, more or less, failed. It occurs to me that in this sea of change, we're all aboard a boat going nowhere, and we have the albatross of compatibility hanging from our necks.

It is no longer clear to me why we must be so intent on clinging to an ideal notion of compatibility with a PC architecture that was introduced over 10 years ago. What happened to the revolution? Instead of forging ahead, we've become content with what we o nce saw as the fallacy of mainframes: the failure to embrace change.

Once, legacy systems referred to the mainframes and minicomputers in the data-processing center. Today, though, the real legacy systems are the PCs on our desks running DOS and Windows--including those 66-MHz 486s and Pentiums you just bought. In the end, those systems are still defined as fast, albeit very fast, IBM PC clones.

Working with PC clones in 1994 is like steering a 12-meter yacht to the moon--sure it's a fast, complicated boat, but it doesn't do well out of the water. With PC clones, you are still stuck with 640-KB limits, patchwork IRQ (interrupt request) and port management, device-driver hell, and error messages that no user should ever have to experience. Why do we tolerate this misery?

Many reasonable people will argue that software distribution in an enterprise would be impossible without adherence to so-called PC compatibility. Nonsense! Software distribution across networked computers is, for all prac tical purposes, already impossible. Ask people in large organizations, and they'll tell you war stories of trying to upgrade software across their networks. Even when everyone on a network uses the same brand and model computer and the same operating system, the configuration files, device drivers, additional memory and hardware devices, and even the lowly AUTOEXEC.BAT files can differ wildly. Where's the compatibility in that?

To Intel's and Microsoft's credit, the Plug and Play standard is at least a realistic approach to a market enthralled by the IBM PC standard. The problem is that, at best, it will take years for Plug and Play to significantly change our world for the better. By that time, the IBM PC standard will be even more outdated.

It seems to me that there is a vacuum where a computer industry vision ought to be. It's high time to cut loose this albatross of compatibility and sail ahead. Computer companies say rhetorically they're giving customers what they want. I say, give us what we need, platforms that break with the past. We need systems that don't make us wait for graphics, systems fast enough to deal with the complex issue of real human interfaces, and systems that plug and play into where we're going, not where we've been.

I would like to welcome the newest member to the BYTE family, BYTE Middle East, an Arabic-language edition that will be distributed throughout the Middle East and Arabic-speaking North Africa.


DENNIS ALLEN, EDITOR IN CHIEF ( dallen@bix.com )

Up to the Editorial section contentsSearchSend a comment on this articleSubscribe to BYTE or BYTE on CD-ROM  
Flexible C++
Matthew Wilson
My approach to software engineering is far more pragmatic than it is theoretical--and no language better exemplifies this than C++.

more...

BYTE Digest

BYTE Digest editors every month analyze and evaluate the best articles from Information Week, EE Times, Dr. Dobb's Journal, Network Computing, Sys Admin, and dozens of other CMP publications—bringing you critical news and information about wireless communication, computer security, software development, embedded systems, and more!

Find out more

BYTE.com Store

BYTE CD-ROM
NOW, on one CD-ROM, you can instantly access more than 8 years of BYTE.
 
The Best of BYTE Volume 1: Programming Languages
The Best of BYTE
Volume 1: Programming Languages
In this issue of Best of BYTE, we bring together some of the leading programming language designers and implementors...

Copyright © 2005 CMP Media LLC, Privacy Policy, Your California Privacy rights, Terms of Service
Site comments: webmaster@byte.com
SDMG Web Sites: BYTE.com, C/C++ Users Journal, Dr. Dobb's Journal, MSDN Magazine, New Architect, SD Expo, SD Magazine, Sys Admin, The Perl Journal, UnixReview.com, Windows Developer Network