This article relies too much on references to primary sources. (March 2013) (Learn how and when to remove this template message)
The term Legacy Plug and Play, also shortened to PnP, describes a series of specifications and Microsoft Windows features geared towards operating system configuration of devices. The standards were primarily aimed at the IBM PC standard bus, later dubbed Industry Standard Architecture (ISA). Related specifications are also defined for the common external or specialist busses commonly attached via ISA at the time of development, including RS-232 and parallel port devices.
As a Windows feature, Plug and Play refers to operating system functionality that supports connectivity, configuration and management with native plug and play devices. Originally considered part of the same feature set as the specifications, Plug and Play in this context refers primarily to the responsibilities and interfaces associated with Windows driver development.
Plug and Play allows for detection of devices without user intervention, and occasionally for minor configuration of device resources, such as I/O ports and device memory maps. PnP is a specific set of standards, not be confused with the generic term plug and play, which describes any hardware specification that alleviates the need for user configuration of device resources.
The Plug and Play standard requires configuration of devices to be handled by system firmware, which then provides details of resources allocations to the operating system. The process is invoked at boot time. When the computer is first turned on, compatible devices are identified and assigned non-conflicting addresses and interrupt request numbers.
The term was adopted by Microsoft in reference to their Windows 95 product. Other operating systems, such as AmigaOS Autoconfig and the Mac OS NuBus system, had already supported such features for some time (under various names, or no name). Even Yggdrasil Linux advertised itself as "Plug and Play Linux" at least 2 years before Windows 95. But the term plug and play gradually became universal due to worldwide acceptance of Windows.
Typically, non-PnP devices need to be identified in the computer's BIOS setup so that the PnP system will not reassign those devices. Problems in the interactions between legacy non-PnP devices and the PnP system can cause it to fail, leading to this technology having historically been referred to as "plug and pray".
Legacy Plug and Play was defined in Microsoft and Intel specifications, which proposed changes to legacy hardware, as well as the BIOS to support operating system-bound discovery of devices. These roles were later assumed by the ACPI standard, which also moves support for power management and configuration into the operating system, as opposed to the firmware as previously required by the "Plug and Play BIOS" and APM specifications. The following standards compose what Microsoft describe as Legacy Plug and Play, as opposed to native Plug-and-Play specifications such as PCI and USB.
Apart from the Plug and Play BIOS Specification, all standards are still supported by Microsoft. However, support for them as opposed to Advanced Configuration and Power Interface will be removed in a future version of Windows.
To use Plug and Play, three requirements have to be met:
Plug-and-play hardware typically also requires some sort of ID code that it can supply, in order for the computer software to correctly identify it.
This ID code system was not integrated into the early Industry Standard Architecture (ISA) hardware common in PCs when Plug and Play was first introduced. ISA Plug and Play caused some of the greatest difficulties that made PnP initially very unreliable. This led to the derisive term "Plug and Pray", since I/O addresses and IRQ lines were often set incorrectly in the early days. Later computer buses like MCA, EISA and PCI (which was becoming the industry standard at that time) integrated this functionality.
Finally, the operating system of the computer needs to be able to handle these changes. Typically, this means looking for interrupts from the bus saying that the configuration has changed, and then reading the information from the bus to locate what happened. Older bus designs often required the entire system to be read in order to locate these changes, which can be time consuming for lots of devices. More modern designs use some sort of system to either reduce or eliminate this "hunt"; for example, USB uses a hub system for this purpose.
When the change is located, the OS then examines the information in the device to figure out what it is. It then has to load up the appropriate device drivers in order to make it work. In the past, this was an all-or-nothing affair, but modern operating systems often include the ability to find the proper driver on the Internet and install it automatically.
Manage research, learning and skills at defaultlogic.com. Create an account using LinkedIn to manage and organize your omni-channel knowledge. defaultlogic.com is like a shopping cart for information -- helping you to save, discuss and share.