User manual SONY VAIO VGN-Z520N

[. . . ] This white paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT. Microsoft, Active Desktop, BackOffice, the BackOffice logo, MSN, Windows, and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. Other product and company names mentioned herein may be the trademarks of their respective owners. [. . . ] Plug and Play driver Plug and Play device Non-Plug and Play device Full Plug and Play Possible partial Plug and Play Non-Plug and Play driver No Plug and Play No Plug and Play As this table indicates, any device that supports Plug and Play should have Plug and Play support in its driver. The following list expands on the possible configurations: Plug and Play device and driver--full Plug and Play support. To provide the optimal Plug and Play support, the hardware implementation must comply with the OnNow design initiative, including ACPI. Windows 2000 Plug and Play targets ACPI systems only. Plug and Play device/non-Plug and Play driver--no Plug and Play support. If a driver does not support Plug and Play, its device behaves as a non-Plug and Play device, regardless of support in the hardware. A non-Plug and Play device can constrain the Plug and Play capabilities of the entire system. Non-Plug and Play device/Plug and Play driver--possible partial Plug and Play support. A non-Plug and Play device can have partial Plug and Play support. Although it is not possible for the system to automatically and dynamically recognize the hardware and load the appropriate drivers, it is possible to have Plug and Play manage resource allocation, provide an interface for driver interaction with the Plug and Play system, interact with power management, and register device notification events. Also, if a non-Plug and Play device has a Plug and Play driver, the device appears in the Device Manager application, and property pages are available for that device. In this context, any device from which other devices are enumerated is referred to as a bus. A bus driver responds to new Plug and Play and power management I/O request packets (IRPs) and can be extended using filter drivers. The bus driver is primarily responsible for the following: Enumerating the devices on its bus. Reporting dynamic events on its bus to the operating system. Responding to Plug and Play and power management IRPs. Multiplexing access to the bus (for some buses). Generically administering the devices on its bus. During enumeration, a bus driver identifies the devices on its bus and creates device objects for them. The method that a bus driver uses to identify connected devices depends on the particular bus. Windows 2000 White Paper 8 A bus driver performs certain operations on behalf of the devices on its bus but usually does not handle reads and writes to the devices on its bus. (A device's function driver handles reads and writes to a device. ) A bus driver acts as a function driver for its controller, adapter, bridge, or other device. Microsoft provides bus drivers for most common buses, including PCI, Plug and Play ISA, SCSI, and USB. Other bus drivers can be provided by IHVs or OEMs. [. . . ] The PCI driver creates an FDO for the PCI bus and attaches the FDO to the device stack for the PCI controller. Creating and attaching this FDO are the PCI driver's responsibilities as the function driver for the PCI controller. An IHV can add functionality to a bus by supplying a bus filter driver (not shown in Figure 2). This method is preferred to supplying a custom bus driver. 4. LAN adapter and USB host controller PDOs and FDOs. [. . . ]