View source for PDDREF:Physical Device Driver Overview

{{PDDREF}}
OS/2 physical device drivers are different from DOS device drivers and DOS terminate and stay resident (TSR) programs. All three of these types of software handle I/O requests for applications in their respective environments but because the environments are so different between DOS and OS/2, the responsibilities of the software doing the I/O are very different also.

For example, DOS is a single-tasking environment where software spins the CPU waiting for I/O to complete and can do this because there is only one task running. OS/2 is a multitasking operating system where the CPU is freed to dispatch other tasks if one task is waiting for I/O to complete. DOS runs in the real mode of the 80x86 processor. OS/2 runs in the protected mode of the 80x86 processor.

==Character and Block Device Drivers==
OS2 has two categories of physical device drivers:
* Character Device Drivers
* Block Device Drivers

====Character Device Drivers====
These drivers support I/O for character (or stream or byte) oriented devices. These devices are usually characterized by one or more of the following:
* Reading data is destructive (non-persistent)
* Accessing data is sequential
* Accessing data on byte boundaries
* Utilizing Programmed I/O (PIO)
A character device driver usually has names such as [[SCREEN$]], [[KBD$]], LPT1 or COM2. Applications talk to character device drivers by issuing a DosOpen on the specific device name and then issuing DosRead, DosWrite or DosDevIOCtl calls using the returned handle.

A character device driver can support more than one device by having multiple device headers that each indicate a different device name. Character device drivers are sometimes used as generic extensions of the OS/2 kernel because they do not unnecessarily take up a drive letter yet have the properties of running in the kernel. For additional information on specific character device drivers, refer to the OS/2 Input/Output Device Driver Reference.

====Block Device Drivers====
These drivers support I/O for block or record oriented devices. These devices are usually characterized by one or more of the following:
* Random access
* Reading data is non-destructive (persistent)
* Accessing of data is difficult on byte boundaries
* Utilizing Direct Memory Access (DMA)
A block device driver does not have a name; instead, a block device driver is assigned one or more drive letters. Because a block device driver can support multiple devices (or units), a drive letter is assigned by the OS/2 kernel for each device (or unit). For more information on block device drivers, refer to the Storage Device Driver Reference.

====Application I/O to Devices====
The primary interface to a physical device driver is the OS/2 request packet interface. File I/O and IOCtl requests from OS/2 applications and INT 21h requests from DOS applications running in a DOS session are translated into request packets that are sent to the physical device driver for processing. The actual format of these request packets is discussed in OS/2 Physical Device Driver Design Issues.

OS/2 device drivers are the standard interface for applications to use for manipulating devices. However, if this interface is insufficient, both OS/2 and DOS applications can:
* Access a device directly by sending data to, or receiving data from, a specific port address through I/O instructions. Notice that 32-bit protect-mode applications cannot issue I/O. Only 16-bit protect-mode applications can issue I/O from the Ring 2 code segment.
* Manipulate the state of the hardware interrupts (disable/enable interrupts) through CLI/STI instructions.
Any DOS application can perform direct register I/O with a device from its code segment. OS/2 applications and subsystems can perform direct register I/O only through IOPL code segments. For DOS applications, I/O direct to the hardware is dependent on which virtual device driver is installed. The virtual device driver can register and hook the particular port for I/O. If a virtual device driver hooks a particular port, subsequent direct access to that particular port will be trapped by the virtual device driver.

The following figure illustrates how DOS and OS/2 applications communicate with a device.

====I/O Support for OS/2 Applications====
An OS/2 application can perform I/O requests by using the interfaces that access the physical device drivers. These interfaces are described in the following table:
{|class="wikitable"
!Interface||Example||Advantage
|-
|File System||DOS dynamic link functions||An application can redirect the I/O.
|-
|Subsystem||VIO, KBD, MOU functions||An application is insulated from managing the device I/O.
|-
|IOCtl||DosDevIOCtl commands||A subsystem or application uses IOCtl commands to send device-specific control commands to device drivers.
|-
|Character Device Monitors||OS/2 dynamic link monitor functions||An application can directly insert, view, or modify data passing to or from a device.
|}
The File System interface consists of the file I/O functions. Both OS/2 and DOS applications use the DOS dynamic link calls for file I/O. DOS applications running in a DOS session issue INT 21h file I/O function calls, which are passed to the OS/2 file systems. These file I/O functions are used primarily to perform I/O on block devices, such as hard disks. Some file I/O functions can be used to perform I/O on character devices. These functions include:
* DosOpen
* DosClose
* DosRead
* DosWrite
The advantage of using the file I/O functions to perform I/O on a character device is that the application can redirect the input/output. The application performs I/O to a handle (file or device) that it obtained by opening the named resource passed to it.

A Subsystem interface shields an application from having to manage device input/output.

The IOCtl interface is the mechanism that an application or subsystem uses to send device-specific control commands to the device driver. DosDevIOCtl is used for OS/2 applications. The INT 21h IOCtl request is used for DOS applications. IOCtl commands can be sent to both block and character device drivers. The application or subsystem must first obtain the device handle by performing an OPEN on the device name.

Character Device Monitors are supported by the OS/2 Version 2.1 (and later) operating system. These monitors provide a mechanism for applications or subsystems to monitor all characters passing to or from a character device driver. This mechanism allows one or more registered processes to remove, insert, or modify data passing through a character device.

A physical device driver is the standard way to provide service to and from OS/2 applications. However, occasionally an application written under an earlier version of OS/2 might directly access a device through service routines defined in the IOPL code segments of the application.

====I/O Support for the DOS Session====
A device driver is responsible for managing input and output for its device. Because system resources must be accessible to both DOS applications and OS/2 applications, OS/2 device drivers for system resources come in physical device driver/virtual device driver pairs (PDD/VDD). (Physical device drivers have the additional capability of communicating with virtual device drivers.) PDD/VDD pairs are provided for the disk, keyboard, screen, mouse, and parallel port.

Device I/O in a DOS session is performed in one of three ways:
* DOS INT 21h interface
* ROM BIOS interface
* Direct access to the device
I/O that uses the DOS INT 21h interface is passed to the OS/2 File System and transformed into a request packet, which is then received by the physical device driver. I/O that uses the OS/2 dynamic link functions is similarly transformed into a request packet. This level of support exists in all OS/2 device drivers.

I/O that uses the ROM BIOS interface is handled by the virtual device driver. The OS/2 virtual device driver must intercept the ROM BIOS software interrupt and pass the request along to its associated physical device driver. The virtual device driver and physical device driver serialize access to the device by using semaphores to indicate when the device is busy with a request (and consequently cannot accept or tolerate a request from ROM BIOS).

Direct access for standard system resources, such as RS232-ASYNC communication, disk, keyboard, mouse, parallel port, video, numeric coprocessor, and ROM BIOS, are virtualized by virtual device drivers provided by the OS/2 operating system.

;Note:Virtual device drivers are not normally required for feature hardware (for example, scanners, FAX, or MIDI) when the feature is operated only from a single DOS session.