Plug N’Pray

(This column first appeared in Vol. 6-2 of the Panacea Perspective,
circa November, 1994)

It’s the dream of PC support specialists. It’s a technology backed/pushed by the might of Microsoft and Intel. It’s a core part of the PCI local-bus specification. It also doesn’t  work just yet, and it may never work properly.

Plug and Play (or PnP for short) is something that was announced at the 1993 Windows Hardware Engineering Conference (WinHEC), about 18 months ago. The purpose of PnP is to allow peripheral hardware to be inserted into a PC via the normal bus connectors and be automatically detected and configured. In order to support this capability, the hardware has to be PnP aware and software configurable. Microsoft, Intel, and Compaq, the originators of PnP, determined something like it was needed to help diminish the amount of time and effort it takes to properly configure a system when new hardware is added.

Currently, a user putting a new board into his or her system needs to make sure that the board doesn’t use any of the same IRQs, DMA channels, I/O port addresses, or memory ranges as any other piece of hardware in the system. This can be a difficult feat to accomplish because this sort of information is not always supplied by the peripherals  vendors. Frequently, conflicting settings may not be apparent until some obscure software package accidentally enables multiple devices at the same time, and the system hangs.

With a PnP BIOS or operating system, and completely PnP compliant hardware, the system software can determine the exact nature of all the add-in boards in the system, figure out what various resources are needed by the hardware, and then individually configure each component so that the devices don’t interfere with one another.

However, this all works only if the BIOS, the OS, the hardware-specific applications, and all the add-in boards are PnP compliant and work correctly in a PnP environment. The reality is that this will not happen for many years to come. Let’s take a look at why.

Add-In Boards
To date, very few add-in boards support the two basic requirements of PnP – a standard method of unique identification and software-only configuration. The only boards that do are a handful of ISA-bus based boards that have been specifically designed to support PnP. Also, virtually all EISA, MicroChannel, and PCI local bus based boards support PnP in a sense, but the percentage of the overall add-in board market that these boards represent is still quite small, and will probably continue to be so.

The reason for the latter assertion is that EISA has been relegated to being pretty much just for servers, MicroChannel has been quietly shelved by IBM in favor of ISA, VL-Bus, and PCI, and finally, PCI slots in on PCI- capable motherboard account for only 25-40% of the slots – the rest of the slots on the motherboard are usually ISA. And, while PCI is on a majority of Pentium motherboards, it accounts for only a tiny percentage of 486-class motherboards, virtually all of which ship with VL-Bus (basically used as an extension to ISA, and VL-Bus boards tend not to be PnP compliant as a result).

Also, while increasing numbers of PCI-based graphics boards are being shipped, very few of any other kind of add- in board are being turned out and sold in anything other than ISA flavors. Looking at today’s PCs, the drive controllers, CD-ROM controllers, I/O boards, network controllers, and modems are all generally still being cranked out as non-PnP compliant ISA boards. While PCI is the best bus hope for PnP, most add-in boards have no need for the performance PCI offers, and PnP also adds additional cost. Not enough cost to double the price of a PnP compliant add-in board, but enough to make competition difficult when margins are small, as they tend to be with high volume add- in boards.

In an attempt to force hardware manufacturers to make their ISA boards PnP compliant, Microsoft has implied that only PnP compliant boards will be able to receive a  “Windows 95-compliant” seal. Whether this coercion will be effective is yet to be determined, but it is obvious that as a result, virtually no user will be using Windows 95 compatible hardware to run Windows 95. This, of course, makes Microsoft Customer Service’s job a lot easier:

<ring> “Hi. I can’t get Windows 95 to run on my Pentium PC”

“Well, are all of your components certified as Windows 95 compatible?”

“Uh, no. I don’t think so.”

“Well then, we’re sorry, but we can’t help you. We can only support Windows 95 on PCs that are completely and thoroughly Windows 95 certified. Good bye.” <click>

The net result is that since the vast majority of add-in boards in use today, and sold for the next few years, will not be PnP compliant, PnP will not always work reliably.

Operating System Issues
Part of the PnP specification calls for non-PnP compliant hardware to be identified through a complex identification mechanism in the operating system. For Microsoft’s OSes  (such as Windows 95), for example, Microsoft has spent the last couple of years working with vendors to find out how they identify their particular hardware add-ins so that they can put such ID mechanisms into their OSes. Unfortunately, there are so many thousands of different devices out there, some very alike, that the likelihood of such add-in hardware being accurately and thoroughly identifiable (both for type and resource usage) is practically nil. A recent review of a Windows 95 Beta mentioned that it took the software 5 minutes to try and figure out what was in the system, and after all that effort, the detection still reported incorrect information.

Let’s just assume, for the time being, that such identification is an achievable task. The identification and configuration data so gathered then gets put in a registry of installed hardware that the user can manually override, just in case. Of course, this only works for operating systems that have such a capability built in. That automatically rules out DOS, Windows 3.1, versions of OS/2 prior to v3.0 (Warp), and all shipping versions of PC- based UNIX OSes. In other words, no OS currently shipping in any real numbers can properly support a mixed installation of PnP and non-PnP compliant hardware without significant user intervention. That implies that a complete PnP installation in software really only applies to future operating systems. What percentage of current users will be using such future operating systems anytime soon, assuming they actually do work? A few hardy souls, certainly, but not the masses in any near term. And, to top it off, the ability of these new OSes to be able to identify not-PnP hardware still remains in serious doubt.

BIOS Issues
Several manufacturers are currently shipping PnP compliant BIOSes. The BIOS implementations of PnP limit themselves to only identifying and configuring PnP compliant devices in the system. This is a necessary function, since PnP devices need to be configured in order to work with today’s common operating systems, like DOS and Windows. In some systems, the BIOS does the configuration automatically, while in others the BIOS is supplemented with an external utility to let the user aid in the configuration process, if necessary.

The problem we’ve encountered in working with various graphics hardware companies who have been building PCI graphics boards is that BIOS configuration behavior differs greatly among the various brands of BIOSes systems manufacturers use in their systems. For example, some of these BIOSes have refused to map a 1MB ROM into extended memory addresses locations, while others map only a portion of it, and some actually do it correctly. The net result is that manufacturers of new generation PnP compliant hardware can’t rely on the BIOSes to configure things properly, and as a result, may need to supply a custom configuration utility anyway. This makes PnP kind of useless at times. What needs to happen here to make this part of PnP functional is that all BIOSes need to be consistent in how they configure devices. Random configuration serves no one, the end user least of all.

Application Implications
One might not realize it, but there are lots of applications out there that have a definite dependence on how hardware is configured, specifically in order to access the hardware directly. The most obvious are programs that use externally loadable drivers, including environments such as Windows 3.1, or programs such as AutoCAD. In both of these cases, the drivers used for I/O, display, etc., need to be PnP aware. None (or virtually none) are, or will be any time soon.

Many such drivers are PCI aware, which comes with its own set of headaches, as there are at least 4 different ways to try and determine the configuration of PCI-based  hardware, none of which can be counted on to work in all situations. In some cases, only one or two of the methods are available because some control programs, like EMM386, have accidentally prevented the other methods from working. Needless to say, this can be a royal pain for drivers that have to handle device initialization and figure out device configuration as part of that process.

Another form of external driver is the kind that you might normally load/install as part of your CONFIG.SYS or AUTOEXEC.BAT files, such as network drivers, SCSI drivers, CD-ROM drivers, mouse drivers, etc. Again, virtually none of these drivers currently support PnP in any way, and that’s not likely to change as long as there’s legacy hardware (i.e. non-PnP) in circulation.

Finally, there’s a whole set of DOS applications out there that don’t necessarily use external drivers, but still need to access hardware that might have been reconfigured by a “helpful” PnP BIOS or OS. Perhaps the two largest categories of such software are communications packages (which need direct access to modem hardware) and entertainment software (which access sound and game controller hardware). The number of packages in the latter category is overwhelming, and as a result, it means that we will probably never see DOS software become truly PnP compatible. And, DOS software, especially entertainment software, will continue to be around for many years to come, Microsoft’s wishes notwithstanding. The effect on add-in board manufacturers is that they can either release PnP compliant hardware, or they can support the large (although most analysts try to ignore it) DOS market with a given product, but not both.

Conclusion
The only way PnP can become a true standard is getting away from today’s standard bus architectures and switching to a completely new add-in device mechanism, using a new OS that doesn’t support DOS and other existing hardware- dependent applications and drivers. On the hardware side, PCMCIA looks like it might offer this opportunity, while something beyond Windows 95 or OS/2 v3.0 is required on the software side of things. It’s far from certain, however, whether such a scenario will ultimately be a better one for the user.