Existing private OS/2 device drivers will not be supported in the OS/2 subsystem directly, but must be rewritten for the Windows NT device driver model. In this context, private device driver means a driver that a particular application requires but that is not included in the OS/2 operating system itself.
Examples of such drivers include those that provide custom support for security, fax, MIDI, or 3270 communication cards. Once an OS/2 device driver has been rewritten for the Windows NT model, however, an OS/2 application can communicate with that device driver using the same OS/2 API, DosDevIoctl; no changes will be required within the application itself. Additionally, support exists for the native device drivers included with Windows NT, such as the display, printer, disk, communications, keyboard, and mouse devices.
For example, suppose that a corporation has written a custom device driver to control a security card. The OS/2 device driver for this card uses an internal name, SECDEV, and an entry for this device driver appears in the Config.sys file. In OS/2, the operating system reads the Config.sys file and adds SECDEV to the device driver list. When an application calls the OS/2 API, DosOpen, this list is searched first. The OS/2 subsystem will read this file during initialization and add symbolic links that will allow the OS/2 application to call the Windows NT device driver from the subsystem. For information about how to set the Config.sys file for the OS/2 subsystem to load a Windows NT device driver, see "OS/2 Configuration" later in this chapter.
The OS/2 application code, as opposed to the device driver code, can still load and run in a binary-compatible manner because the device-specific parameters passed by DosDevIoctl(2) APIs are just PVOID buffers. Of course, the new Windows NT version of the ported device driver would have to be made compatible with the original by accepting the same set of parameters within the buffers. Other related OS/2 APIs, such as DosOpen, are supported compatibly, just as they are for supporting native Windows NT system device drivers such as the communications device, the keyboard, and the screen.
The OS/2 subsystem supports long names and extended attributes but no longer supports HPFS. The subsystem does not utilize or expose recoverability and C2 security functions.
The OS/2 subsystem implements many LAN Manager APIs. It also implements NetBIOS (both version 2.x and version 3.0 functionality), named pipes, and mail slots.
The OS/2 subsystem maintains remote drives compatible with OS/2. With these, any OS/2 application can use redirected drives transparently with the file I/O APIs. Uniform naming convention (UNC) naming is supported as well. Redirected drives of various network operating systems can be used, provided that the related Win32 Windows NT device drivers (redirectors) have been installed.