View source for OS/2 Device Drivers Information

* by [[Udhaya Kumar.V]]
* Compiled Date 08/03/2002

= Description of OS/2 Warp Version =
The term OS/2 Warp will be used as a generic term for the following OS/2 Versions: 
* OS/2 
* OS/2 Warp Version 3
* OS/2 Warp Connect
* OS/2 Warp with WIN-OS/2

= OS/2 Security System =
OS/2 switches the Intel 80286. 80386, 80486 and 80586 Microprocessor chips into Protected mode operation. In this mode of operation, OS/2 Warp can run applications in one of four ''ring mode''s: RING 0, RING 1, RING 2, and RING 3.

; Ring 3 : is reserved for normal applications. From Ring 3 the operating
:System cannot be accessed directly. 

; Ring 2 : is reserved for I/O program (IOPL-Input/Output Privilege Level)
:And some 16-bit dynamic link libraries (32-bit DLLs run at Ring 3). 

; Ring 1 : is reserved by the kernel and is not used.

; Ring 0 : is the most protected area. It is used from the operating system Kernel.
:Device drivers run in this ring. 

= CONFIG.SYS Processing Sequence =
* When you turn on a Personal Computer it immediately performs the Power On Self Test (POST) to ensure the hardware is working correctly. A single beep indicates there are no hardware errors and the operating system can be loaded.
* Once the OS/2 kernel is loaded successfully the CONFIG.SYS file is read and executed. Unlike the DOS environment,
* Where the CONFIG.SYS file was read and processed line-by-line, OS/2 reads the entire CONFIG.SYS file and then organizes all statements into ordered groups for execution.
* Early in the boot sequence of OS/2 the OS2KRNL file is loaded and executed. After the kernel is running, OS/2 searches the root directory of the drive OS/2 is installed on for the CONFIG.SYS file.
* Once CONFIG.SYS is successfully read, OS/2 reorganizes and reorders each line into a new sequence for processing. If CONFIG.SYS in the root directory is damaged or missing, you receive the error message and the boot process halts:

==== Config.sys Group Execution order ====
# First, all '''base device driver''' statements are executed according to their file name extensions.
# Then the '''LIBPATH''' statement and all environment variables are created in memory.
# National language support is next which involves the '''CODEPAGE, COUNTRY, and DEVINFO '''statements.
# '''Files systems''' are loaded next
# Installable device drivers from all '''DEVICE''' commands
# The '''SWAPPATH''' is established next and the swap file is opened on physical storage.
# OS/2 then initializes the '''Virtual DOS Machine environment''' for DOS and Windows programs.
# '''CALL and RUN''' commands are interrogated next prior to executing the Workplace Shell.

= Config.sys Group Execution order Commands =
1.BASEDEV= 

2.LIBPATH=/SET=

3.CODEPAGE=/COUNTRY=/DEVINFO=

4.IFS=/DEVICE=

5.SWAPPATH=

6.VDM Support:
* BREAK=
* DEVICE=
* DEVICEHIGH=
* FCBS=
* FILES=
* LASTDRIVE=
* PROTECTONLY=
* RMSIZE=
* SHELL=

7. CALL=/RUN=

8. PROTSHELL=

9. Others

==The detailed processing sequence and the drivers within each of those Groups==
===BASEDEV= ===
statements are read first and ordered by the file extension as follows:
# .SYS
# .BID
# .VSD
# .TSD
# .ADD
# .I13
# .FLT
# .DMD

The extensions .BID, .VSD and .TSD are used to support Microsoft's LADDR layered device driver model, which is now rarely used in OS/2.

===LIBPATH=/SET= ===
The LIBPATH= statement is read next. LIBPATH is not an environment variable like the PATH and DPATH statements. It cannot be displayed or modified from an OS/2 command prompt like PATH and DPATH can.

If changes are made to CONFIG.SYS, the system must be rebooted to read and load the new LIBPATH statement. When any application searches for dynamic link libraries, it looks in the LIBPATH directory structure first

If you add a "." to the beginning of the LIBPATH= statement you force OS/2 to search the current directory for DLLs first. The "." represents or points to the address of the current directory. Any time a system application or user program makes a call for a dynamic link library, during the boot sequence or normal operation, this causes the Current directory to be searched.

After all LIBPATH= statements are read OS/2 reads all the SET statements in the order that they appear and initializes environment variables for each SET command.

===CODEPAGE=/COUNTRY=/DEVINFO= ===
The National Language Support for screen and keyboard are read next.

===IFS=/DEVICE= ===
Installable File Systems (IFS) are read and loaded next including High Performance File System (HPFS), CD- ROM File System (CDFS), and High Performance Optical File System (HPOFS) if required and installed. Storage devices requiring any installable file system cannot be accessed. if the appropriate IFS support is not successfully loaded.

===SWAPPATH= ===
The SWAPPATH statement points to the location of the SWAPPER.DAT file. It is only read at boot time and if changed, the system must be rebooted.

===VDM Support:===
If DOS support is installed, OS/2 initializes parameters that are specific to the Virtual DOS Machine from the CONFIG.SYS file. These statements cannot be removed from CONFIG.SYS but they can be set to minimal values. Refer to the Command Reference in the Information folder for specific details on minimum, maximum, and default values when appropriate.

 BREAK=
 DEVICE=
 DEVICEHIGH=
 FCBS=
 FILES=
 LASTDRIVE=
 PROTECTONLY=
 RMSIZE=
 SHELL=

===CALL= ===
The CALL= statement is used to start a program before the '''Workplace Shell''' is initialized and loads the Desktop. Programs launched using the CALL= statements in CONFIG.SYS are run synchronously. This means: 

That the first program called must complete before the next CALL= statement is executed. This method allows control to be exercised during the startup sequence prior to initializing the Workplace Shell.

For instance, if you want to be able to execute a command before the Workplace Shell is initialized, you could put the statement, CALL=C:\OS2\CMD.EXE in the CONFIG.SYS file.

When this CALL statement is executed an OS/2 Command Prompt window will be opened. You can now enter any command you wish. Click on '''EXIT '''to close the window and allow the boot process to continue.

After the Workplace Shell initializes and the Desktop is built, certain files are in a locked for protection from other processes. Any attempt to modify or reconfigure one of these files will fail. The CALL= statement allows access to these files before they are locked by OS/2.

===RUN= ===
The RUN= statement is similar to the DETACH command in that it starts a detached process in OS/2. A detached process runs in the background with no access from standard input or to standard output (keyboard or Screen). All input must be piped in from another source and all output similarly must be piped or redirected to a file or storage device. There are two important aspects of the RUN= statement to be aware of:
*The RUN= statement executes the program before the Workplace Shell is initialized.
All that is running at this time in the boot sequence is the base operating system. If your program requires the Workplace Shell or Presentation Manager. Services the program will fail to start or possibly cause other errors on the system.
*Programs started with the RUN= statement in CONFIG.SYS are executed asynchronously. This means that each RUN= statement is started in the order that it appears in CONFIG.SYS and all programs started with a RUN= statement execute simultaneously. You can control the order of initial execution, but you cannot control which program will run faster or complete processing first. If control is important, use the CALL command.

===PROTSHELL= ===
PROTSHELL= tells OS/2 what Presentation Manager program to use as the Protected Mode Shell. By default OS/2 installs and uses [[PMSHELL.EXE]]. PMSHELL.EXE is the first program started after the base operating system is loaded. This is the only Protected Mode Shell program provided with OS/2 Warp, though there might be others from Private sources.

The Protected Mode Shell program is responsible for initializing the Presentation Manager. Environment. This initialization process uses some undocumented features in OS/2 Warp, making it difficult to write a new Presentation Manager.

Other CONFIG.SYS Statements All other [[CONFIG.SYS]] statements that do not fit into one of the above groups are not sequence sensitive and are initialized sometime during the OS/2 boot process.

= OS/2 Warp Device Driver Overview =
  
=== Introduction ===
# Device drivers are software components to implement a device-independent way to access devices. This reduces the Development overhead for applications.
# To achieve this, a well-defined interface from the application's point of view needs to be available to use the device.
# All the device-dependent code resides in the device driver. Therefore it's necessary to have different drivers for different devices.
# Device drivers set up hardware and software components of the system.

'''The Three major categories of device drivers in OS/2 Warp are as follows:''' 

I) Physical device drivers

II) Virtual device drivers

III) Presentation drivers

=== I) Physical Device Drivers ===
* These drivers usually handles I/O requests, e.g. Disks, hard disks, CD-ROMs, Video, Mouse, Keyboard, serial/parallel ports etc. This workshop will cover parts of these types of drivers.
* OS/2 physical device drivers are 16 bit protected mode applications running in ring 0. They need to be reentrant and fast, because OS/2 is a multitasking system.
* Physical device drivers are loaded from CONFIG.SYS with the BASEDEV= or DEVICE= statement.
* These drivers provide support for standard I/O Devices such as a hard disk drive, printer and a fax/modem card.
* Device drivers are initialized at Ring 3 but operate at Ring 0, the most privileged level of the operating system.
* Physical device drivers are loaded by two different methods. The OS/2 kernel loads some, and the others are loaded by entries in the CONFIG.SYS file.
* Device drivers entered in the CONFIG.SYS file are loaded by either the BASEDEV= statement or the DEVICE= statement. For the purpose of this discussion

'''Physical device drivers will be organized into the following three categories (This
is based on Data Accessing):''' 

1) Block Device Driver

2) Character Device Driver

====Block Device Driver====
* A block DD accesses data in block or record structure.
* Usually these drivers can do random access, using DMA and the read operation is non-destructive.
* OS/2 assigns drive letters for Block Devices. Each driver may handle more than one letter.
  
====Character Device Driver==== 
* A character DD accesses data character oriented, often bytes or streams. Usually these drivers access data sequentially e.g. I/O for special hardware chips, like programmable I/O circuits.
* OS/2 assigns names for these drivers e.g. MOUSE$ or LPT1. The driver may support more than one device with the same driver.
* A character DD may be replaced by an other one with the same name (it depends on the loading sequence). This means, that such a driver needs to have a mechanism to unload. This workshop will cover parts of this PDD type.

Physical device drivers will be organized into the following three categories (This is based on the Functionality): 
# Critical device drivers
# Base device drivers
# Installable device drivers

====1) Critical device drivers====
* Critical device drivers are absolutely essential to the Operation of OS/2 Warp.
* They are so important they are loaded by the OS/2 kernel (OS2KRNL) during system Initialization. If one of these device drivers isn't found and fails to load, OS/2 Warp will not load. For example, we renamed the RESOURCE.SYS file in the \OS2\BOOT subdirectory and rebooted the system. After the single beep of the Power On Self Test (POST), we received the following message and the system was halted '''The system is stopped. Correct the preceding error and rest system.'''
* If you lose one of the following critical device drivers for Any reason, you will need to replace it from another Machine or unpack it from the install diskettes into the Proper subdirectory. The proper subdirectory for these device drivers is \OS2\BOOT.
* These device drivers are installed during initial installation and should not be Manually modified in any way or deleted from the system. If you receive an Error on one of these device drivers, it could be a very serious problem requiring a reinstall of the operating system.

===== Device Driver Device Driver Description =====
* '''[[RESOURCE.SYS]] '''OS/2 Resource Manager. 
* '''[[CLOCK01.SYS]] '''System clock device driver for ISA bus personal computers.
* '''[[CLOCK02.SYS]] '''System clock device driver for MCA bus personal computers.
* '''[[SCREEN01.SYS]] '''System standard output device driver for ISA bus computers.
* '''[[SCREEN02.SYS]] '''System standard output device driver for Micro Channel bus computers.
* '''[[KBDBASE.SYS]]''' This is the base OS/2 keyboard device driver. It receives and processes scan code from IBMKBD.SYS, the hardware specific device driver for the particular keyboard attached to the system unit. KBDBASE.SYS instructs IBMKBD.SYS if there are any updates to the keyboard information.

====Base device drivers====
* Base device drivers are primary level support for system devices such as diskette drives, fixed and removable; storage devices, system attached printers, and some other Hardware devices.
* These device drivers are loaded with a BASEDEV= statement in the CONFIG.SYS file. These system-level device drivers communicate with the device-level driver that communicates directly to the supported device. BASEDEV statements are interrogated and loaded prior to any other DEVICE statements. Unlike the DEVICE statement, the BASEDEV= statement cannot contain either drive or path information and therefore the OS/2 operating system cannot process such information at this stage of the startup sequence.
* Support for file systems (File Allocation Table – FAT and High Performance File System - HPFS) is not initialized at this point in the boot process.
* OS/2 first searches the root directory of the startup partition for the specified File name, then the \OS2\BOOT directory. If drive or path information is Included in a BASEDEV= statement.
* The BASEDEV=statement including the path information is not read and CONFIG.SYS processing continues. If the BASEDEV= statement is as critical as the BASEDEV=IBMKBD.SYS (keyboard support) the system will eventually hang. If the base device driver is not critical the system will load successfully with out device support provided by that particular BASEDEV=statement.
* For example, if you include BASEDEV=C:\OS2\BOOT\IBM1FLPY.ADD in CONFIG.SYS, you will generate the above described message during the boot sequence. After a few seconds the message disappears and processing continues. The system will boot normally and the Workplace Shell will initialize. When you attempt to access the diskette drives in your computer, either from a command prompt or the Workplace Shell, you will receive one or both of the following error messages:
* For OS/2 Symmetric Multiprocessing (SMP), the Platform Specific Driver (.PSD) provides the strategy and management code to exploit the multiple processors in SMP machines. There is one .PSD for each machine type, as the manufacturers tend to implement SMP in slightly different ways. As of this writing a platform specific driver for OS/2 Warp was not yet generally available.
  
'''The following is a list of all base device drivers included with OS/2 Warp:''' 
* '''[[IBMKBD.SYS]]''' Device support for the keyboard.
* '''[[IBM1FLPY.ADD]]''' Device support for diskette drives on non-Micro Channel workstations.
* '''[[IBM2FLPY.ADD]]''' Device support for diskette drives on Micro Channel workstations.
* '''[[XDFLOPPY.FLT]]''' Device support for XDF diskettes.
* '''[[OS2DASD.DMD]]''' General-purpose device support for hard disk drives.
* '''[[IBMINT13.I13]]''' General-purpose device support for hard disk controllers.
* '''[[IBM1S506.ADD]]''' Device support for non-SCSI disk drives on non-Micro Channelworkstations.
* '''[[IBM2ADSK.ADD]]''' Device support for non-SCSI disk drives on Micro Channel Workstations.
* '''[[IBM2SCSI.ADD]]''' Device support for Micro Channel SCSI adapters.
* '''[[DELIVERY.SYS]]''' IBM 32-bit Fast &amp; Wide Microchannel adapters. ([[IBM2SCSI.ADD]] must be installed
and initialized.)
* '''[[OS2SCSI.DMD]]''' General-purpose device support for non-disk SCSI devices.
* '''[[OS2ASPI.DMD]]''' Device manager for devices using Adaptec's AdvancedSCSI
Programming Interface (ASPI).
* '''[[AHA152X.ADD]]''' Adaptec ISA SCSI adapters and system board controllers.
* '''[[AHA154X.ADD]]''' Adaptec ISA SCSI adapters.
* '''[[AHA164X.ADD]]''' Adaptec MCA SCSI adapters.
* '''[[AHA174X.ADD]]''' Adaptec EISA SCSI adapters.
* '''[[AIC7770.ADD]]''' Adaptec 2800 ISA and 2700 EISA SCSI adapters and AIC-7770 system board controller.
* '''[[AIC7870.ADD]]''' Adaptec PCI SCSI adapter and 7870 system board controller.
* '''[[FD8XX.ADD]]''' Future Domain 8-bit SCSI adapters.
* '''[[FD16-700.ADD]]''' Future Domain 16-bit, PCI SCSI, and ISA Fast SCSI adapters.
* '''[[FD7000EX.ADD]]''' Future Domain TMC-7000EX EISA SCSI controllers.
* '''[[BTSCSI.ADD]]''' Bus Logic ISA-VL, ISA, MCA, EISA, and PCI SCSI adapter support.
* '''[[DPT20XX.ADD]]''' Distributed Processing Technology (DPT) SCSI adapters.
* '''[[PRINT01.SYS]]''' Device support for locally attached printers on non-Micro Channel workstations. Use the /IRQ parameter to use interrupt driven printing, rather than the default polling method. Polling can use a significant amount of a CPU doing nothing if the printer is slow.
* '''[[PRINT02.SYS]]''' Device support for locally attached printers on Micro Channel workstations.
* '''[[SBCD2.ADD]]''' IBM ISA CD-ROM, Creative Labs Omni CD-ROM, and Panasonic 521/2/3, and 562/3.
* '''[[IBMIDECD.FLT]]''' IBM filter device driver for Enhanced IDE CD-ROM drives.
* '''[[MITFX001.ADD]]''' Mitsumi CRMC-FX001/001D and LU0025/55 CD-ROM drives.
* '''[[SONY31A.ADD]]''' Sony CDU-31A/33A and 7305 CD-ROM drives.
* '''[[SONY535.ADD]]''' Sony CDU-531/6201/6205/535/6205 and 7205 CD-ROM drives.
* '''[[LMS205.ADD]]''' Philips LMS CM205/225 CD-ROM drives.
* '''[[LMS206.ADD]]''' Philips LMS CM205MS/255MS and CM206/226 CD-ROM drives.
* '''[[PCMCIA.SYS]]''' Card services support for PCMCIA devices.
* '''IBM2XXXX.SYS''' Socket services support for PCMCIA devices.
** [[IBM2AMB1.SYS]] - Ambra
** [[IBM2AST1.SYS]] - AST
** [[IBM2CMQ1.SYS]] - Compaq
** [[IBM2CAD1.SYS]] - CompuAdd
** [[IBM2MAT1.SYS]] - Panasonic
** [[IBM2NEC1.SYS]] - NEC
** [[IBM2NCR1.SYS]] - NCR
** [[IBM2TOS1.SYS]] - Toshiba
** [[IBM2ZEN1.SYS]] - Zenith 2 Lite
** [[IBM2ZOS1.SYS]] - ZEOS
** [[IBM2SSO1.SYS]] - ThinkPad 750 (ISA bus)>
** [[IBM2SSO2.SYS]] - ThinkPad 720 (Micro Channel bus)
* '''[[AUTODRV2.SYS]]''' PCMCIA modem driver.
* '''[[PCM2ATA.ADD]]''' PCMCIA Advanced Technology Attach (ATA)/Flash support.
* '''[[ICMEMMTD.SYS]]''' PCMCIA Flash RAM Drive support.
* '''[[ICMEMCDD.SYS]]''' PCMCIA Static RAM Drive support.
* '''[[CSSCSI.SYS]]''' IBM PCMCIA SCSI card support.
* '''[[DETNE2.SYS]]''' Detects NE2000 Ethernet LAN cards and blocks address to prevent conflicts (for example, Mitsumi CD-ROM).

====Installable device driver====
* Installable device drivers are program files required by OS/2 in order to recognize hardware devices and process information received from or sent to that device.
* These Files use the extension .SYS and may have associated Dynamic Link Libraries (DLLs). Examples of device drivers with a corresponding DLL are ANSI.SYS and ANSI.DLL, which provide extended screen and keyboard support.
  
'''Some typical device drivers from the C:\OS2\ subdirectory are:''' 

'''[[RESOURCE.SYS]] '''Scans allocated resources in the system to determine conflicts with I/O port allocation, IRQ levels, BIOS memory allocation, DMA channels, Timer channels, and device drivers.

'''[[COM.SYS]]''' Serial device support. Permits programs to use serial ports. The IRQ and I/O port address are configurable via this device driver.

'''[[RESERVE.SYS]]''' Used to reserve specific system resources for device drivers that are not Resource Manager aware. Works in conjunction with RESOURCE.SYS.

'''[[PMDD.SYS]]''' OS/2 Presentation Manager device driver. It is not required if you only run OS/2 full screen sessions. It also provides pointer draw support for OS/2 PM sessions.

'''[[VDISK.SYS]]''' To create a virtual disk drive in RAM memory. The default size is 16 KB. Virtual disks provide extremely fast access to programs and data, but consume RAM memory that cannot be used by applications.

'''[[EXTDSKDD.SYS]]''' Assigns a drive letter to a diskette drive.

'''[[LOG.SYS]]'''Activates the Systen-Error Logging Service device driver. The /OFF parameter pauses the System-Error LoggingService at initialization. When paused, no error-logging occurs. LOG.SYS is used in conjunction with the RUN=LOGDAEM.EXE statement in CONFIG.SYS.

'''[[POINTDD.SYS]]''' Provides mouse pointer draw support.

'''[[DOS.SYS]]'''Support for Virtual DOS Machines (VDM's) in OS/2 Warp. If you don't run DOS applications you can remove this device driver.

'''[[MOUSE.SYS]]''' Support for pointing devices.

'''[[TESTCFG.SYS]]'''Tests the system configuration, for example, queries adapters, during initial installation and subsequent installs; that is, Selective Install or Device Driver Install. Can be removed if not performing install functions, but not recommended.

'''[[IBMKBD.SYS]]''' Hardware specific portion of the keyboard device driver. It supports the following keyboards: IBM 101/102 Enhanced keyboards, IBM 3279 130 Enhanced keyboard.

===II. Virtual Device Drivers===
* These drivers are ONLY necessary for the Virtual DOS Machine (VDM) and for DOS applications like WinOS/2 and others. Usually these drivers communicate with Physical Device Drivers to gain access to devices. Virtual Device Drivers are implemented in 32 bit code, running in ring 0.
* Virtual Device Drivers (VDDs) are installed to allow DOS applications to access hardware devices in the OS/2 protected environment.
* DOS programs cannot be allowed to monopolize hardware devices for their exclusive use, and OS/2 accomplishes this through a technique known as ''hardware virtualizatio''n.
* It does so using virtual device drivers. VDDs are 32-bit programs that operate at Ring 0.
* They communicate with the actual hardware through an OS/2 layer called the '''Virtual Device Helper (VDH)'''. The VDH monitors the availability of the hardware device and allows the DOS application access when it is free.
* All VDDs are loaded from the CONFIG.SYS file and begin with the letter V. They are located in the \OS2\MDOS\ subdirectory on the drive which OS/2 is installed
  
'''Device Driver Device Driver Description''' 

* '''[[VAPM.SYS]]''' This driver is used to support Advanced Power Management under DOS. If your system does not have APM, then you don't need this driver and it can be removed from CONFIG.SYS.
* '''[[VCDROM.SYS]]''' This driver provides DOS CD-ROM support. If you do not use DOS programs that require CD-ROM support, you can remove this driver from CONFIG.SYS.
* '''[[VCOM.SYS]]''' This driver provides DOS COM support. If you do not use DOS programs that require access to COM ports, you can remove this driver from CONFIG.SYS.
* '''[[VDPMI.SYS]]''' This driver, along with VDPX.SYS, provides DOS Protected Mode Interface memory support. If you do not use DOS programs that require DPMI you can remove this driver from CONFIG.SYS. Note that this driver is required for Windows.
* '''[[VDPX.SYS]]''' This driver, along with VDPMI.SYS, provides DOS Protected Mode Interface memory support. If you do not use DOS programs that require DPMI, you can remove this driver from CONFIG.SYS. Note that this driver is required for Windows.
* '''[[VEMM.SYS]]''' This driver provides support for the DOS virtual expanded memory manager. If you do not use DOS programs that require expended memory you can remove this driver from CONFIG.SYS.
* '''[[VMOUSE.SYS]]''' This driver provides mouse support in the DOS and WIN-OS/2 environment. If you do not use DOS or WIN-OS/2 programs that require mouse support, you can remove this driver from CONFIG.SYS.
* '''[[VSVGA.SYS]]''' This driver provides DOS SVGA support. If you do not use DOS or WIN-OS/2 programs, you can remove this driver from CONFIG.SYS.
* '''[[VPCMCIA.SYS]]''' This driver provides DOS PCMCIA support. If you do not use DOS programs that require PCMCIA, you can remove this driver from CONFIG.SYS.
* '''[[VVGA.SYS]]''' This driver provides DOS VGA support. If you do not use DOS or WIN-OS/2 programs you can remove this driver from CONFIG.SYS.
* '''[[VWIN.SYS]]''' This driver provides WIN-OS/2 support. If you do not use WIN-OS/2 programs you can remove this driver from CONFIG.SYS. The VWIN.SYS driver also requires the VDPX.SYS, VDPMI.SYS, and VXMS.SYS to be loaded.
*  '''[[VW32S.SYS]]''' This driver provides support for the Win32s APIs under WIN-OS/2. If you do not use WIN-OS/2, or Windows programs that use Win32s, then you can remove this Driver from CONFIG.SYS.
* '''[[VXGA.SYS]]''' This driver provides DOS XGA support. If you do not use DOS or WIN-OS/2 programs, you can remove this driver from CONFIG.SYS.
* '''[[VXMS.SYS]] /UMB''' This driver provides support for the DOS virtual extended memory manager. If you do not use DOS programs that require extended memory, you can remove this driver from CONFIG.SYS.

===III) Presentation Drivers===
* The I/O interface of the Presentation Manager (PM) uses these driver types so only PM-Applications use these drivers (indirectly). These drivers handle the PM device contexts to draw to a virtual device (e.g. printer and screen). Presentation Drivers are implemented with 32 bit code running in ring 3 and some parts with 16 bit, running in ring 2 to gain I/O access.
* The Presentation Manager I/O interface for output devices is a high-level interface. This interface is similar to the API call interface, which uses the program stack to communicate with, or pass parameters to, the presentation drivers.
* These drivers are special-purpose I/O routines operating with I/O privileges at Ring 2 or Ring 3.
* Their main function is to process function calls made by the Presentation Manager interface on behalf of Presentation Manager applications. Hardcopy presentation drivers, or drivers that directly support file printing, communicate with OS/2 device drivers through the file system emulation functions. Display presentation drivers interface directly with the hardware.
* Presentation drivers are dynamic link library modules that are supplied as files and identified by the extension DRV. When the Presentation Manager interface is initialized, the display presentation driver is loaded and enabled automatically. Other presentation drivers (for example, the hardcopy presentation drivers) are loaded and enabled when an application calls the DevOpenDC function to open the device.
* Presentation drivers service requests only from applications running in Presentation Manager sessions in OS/2 mode. Output data and requests for information are passed to the presentation driver as function calls to the presentation driver interface.
* The definition of the call interface is given in terms of the codes, and data is passed to the presentation driver interface through the program stack.
* Header and include files are shipped with the OS/2 operating system to provide support for building presentation drivers that are written in C or assembler language. These files contain function prototypes, defined values, and data structures used by the various functions.

=== Application to driver communication ===
Applications can only communicate with drivers by using the following kernel API functions: 

1. [[DosOpen]]()

2. [[DosClose]]()

3. [[DosRead]]()

4. [[DosWrite]]()

5. [[DosDevIOCtl]]()

The advantage in using the standard file API functions also for character DD's is, that redirection is possible for these devices too. The character DD's name is used as the filename for these functions.

== Now we can discuss about Physical Device Driver ==
  
=== PDD execution context ===
Each driver operates in three different contexts. 

1)INIT Mode

2)Kernel Mode (context mode)

3)Interrupt Mode (and timer mode)

====INIT Mode:====
This mode is exclusively used at OS/2 boot time (driver load). The code in this mode runs at ring 3 privilege level. In this mode, the driver has access to some "standard" OS/2 API's and has I/O privilege! This mode is only used once and therefore the code in this mode only runs at boot time. The driver developer should not spend too much time to make this code fast...

====Kernel Mode (context mode)====
If one of the above 5 API functions are used, the kernel calls the driver and routes the function request with the parameters to the driver. This is the typical operation of the driver. The driver will run in the context of the application which made the function call. The code, which implements this mode, is called the strategy routine. This code should be fast...
- spend more time

====Interrupt Mode (and timer mode):====
In this mode, the driver is called via an interrupt. The driver will NOT run in a specific context! This code should be fast, and very fast if it is a timer interrupt.

= The Drivers Layout =
* PDD are written in 16:16, protected mode addressing schema. The first segment needs to be the data segment. OS/2 expects a data structure at the very first position of a driver, called the "Device Driver Header". Because this is data, the first segment needs to be the data segment. Data, which is accessed by the interrupt handler, must reside in this segment.
  
* The code segment follows directly after the data segment. Code for the interrupt handler must reside here.
  
* The code for the INIT-mode could be placed at the end of the code segment. So it could be freed after running, because it only runs once.

= PDD header =
The PDD header defines the characteristics of a driver. 
                                        
{| border="1"
|-
| '''SNO''' 
| '''Field Description''' 
| '''Length in Bytes''' 
|-
| A 
| far
pointer to next device header 
| 4 
|-
| B 
| Device
attribute 
| 2 
|-
| C 
| 16
bit offset to strategy routine 
| 2 
|-
| D 
| 16
bit offset to inter-device-driver-communication(IDC)
routine 
| 2 
|-
| E 
| Driver
name (character DD) / number of units (blockDD) 
| 8 
|-
| F 
| Reserved 
| 8 
|-
| G 
| Capabilities
bit strip 
| 8 
|}
 
=== A) far pointer to next device header ===
This pointer should be set to &shy;1 (ffffffff) in the driver's code. While
loading the drivers, OS/2 builds a linked list for all drivers by using
this field. If the driver supports multiple devices, there is one header
for each device. Only the last header should be set to &shy;1 the other
ones need to be linked together. 

=== B) device attribute ===
Describes the characteristics of the physical device driver to the system. 
'''CHR (bit 15)'''

Set, if the physical device driver operates in character mode. Bit 15 is the
device type bit. Use bit 15 to tell the system if the device driver is
a block or character device. For block device drivers, bit 15 is 0. For
character device drivers, bit 15 is 1.

'''IDC (bit 14)'''

Set, if the physical device driver participates in inter-device-driver communication
(IDC). Bit 14 is the IDC bit and indicates that the offset to the IDC entry
point in the physical device driver header is set.

'''IBM (R) (bit 13)'''

Set, if non-IBM block format (block device drivers only). For block device drivers,
bit 13 indicates the method which the physical device driver uses to determine
the media type. If a block device driver uses information in the BIOS Parameter
Block (BPB) to determine the media type, bit 13 should be set to 1. If
the physical device driver uses the media descriptor byte to determine
the media type, bit 13 must be 0.


'''SHR (bit 12)'''

Set, if the device driver supports shared-device access-checking (character
devices). Bit 12 is the shared bit. It is set if the device name is not
to be protected by the sharer. Bit 12 has no meaning for block device drivers
and must be 0. If clear (default), file system sharing rules do not apply
to the device, and the physical device driver provides contention control.
If set, file system sharing rules apply to the device, just as these rules
apply to any other file system name. In addition, any given physical device
can have only one logical name. (Devices cannot have aliases.)


'''OPN (bit 11)'''

Set, if the device driver supports removable media (block devices) or device
open/close (character devices). For block device drivers, bit 11 is the
removable media bit. If set, this bit indicates that the physical device
driver handles removable media. For character device drivers, bit 11 is
the open/close bit. If set, this bit indicates that the physical device
driver must receive OPEN and CLOSE request packets.

'''bit 10'''

Reserved=0.

'''bits 9-7'''

bits 9-7 indicate the physical device driver function level, where:
                         
{| border="1"
|-
| '''Bit 9''' 
| '''Bit 8''' 
| '''Bit 7''' 
| '''Description''' 
|-
| 0 
| 0 
| 1 
| OS/2 driver (default) [Level 1 driver] 
|-
| 0 
| 1 
| 0 
| Supports DosDevIOCtl2 and shutdown requests [Level 2 driver]  
|-
| 0 
| 1 
| 1 
| Uses a capabilities strip bit in the header [Level 3 driver]  
|} 

'''bit 6-4'''

Reserved=0.

'''CLK (bit 3)'''

Set, if CLOCK device. Bit 3 is the clock device bit. It is used by a character
device driver to indicate the system clock device.

'''NUL (bit 2)'''

Set, if NULL device. Bit 2 is the NULL attribute bit. It is used by character
devices only. Bit 2 is used to tell the OS/2 operating system if the character
device driver is a NULL device. Although there is a NULL device attribute
bit, the NULL device cannot be reassigned.

'''SCR (bit 1)'''

Set, if standard output device (STDOUT). For character devices, bits 1 and 0
are the standard input or standard output bits. These bits are used to
tell the OS/2 operating system if the character device driver is the new
standard input or standard output device.

'''KBD (bit 0)'''

Set, if standard input device (STDIN). See above.

=== C) 16 bit offset to strategy routine ===
This is the entry point to the code running in kernel mode. The kernel is using this address to call the strategy routine.  

=== D) 16 bit offset to inter-device-driver-communication (IDC) routine ===
This address could be called by other device drivers to provide IDC.  
E) driver name (character DD) / number of units
(block DD)

For character DD's, the name needs to be in uppercase, left oriented and filled up with blanks until the length is 8 bytes. The device name takes precedence over file names! To avoid conflicts, sometimes a driver's name uses special symbols, like a $ sign. Block DD's fill in the number of supported units.

=== F) reserved ===
reserved area for future use  

=== G) capabilities bit strip ===
Level 3 device drivers have an additional 8 byte field appended to the device header. Each bit of this new field is a flag indicating whether or not a particular feature is supported.  

'''bit 0'''

Set to 1, if DosDevIOCtl2 request packets are supported, and if shutdown support is provided.

'''bit 1'''

For block device drivers, this bit is reserved and must be set to 0. Block device drivers indicate their ability to support higher than 16 MB. For character device drivers, this bit is set to 1 (if memory addressing above 16 MB is supported).

'''bit 2'''

Set to 1, if the physical device driver supports parallel ports.

'''bit 3'''

Indicates that the physical device driver is participating in the adapter device driver (ADD) strategy, which selects an alternate INIT request packet format from the kernel.

'''bit 4'''

If set to 1, the Initialization Complete Command (1Fh) is supported.

'''bits 5-31'''

Reserved.
Must be set to 0.

= How PDD's work =
Strategy routine: 
# If an application wants to communicate with the PDD, it calls one of the above kernel functions (e.g. DosOpen(), DosWrite(), ...).
# The kernel does some parameter checking and builds a data structure called request packet.
# The kernel calls the strategy entry point in the device driver and passes a pointer to the request packet. Pointers in the request packet (only for read/write requests) are already translated into a 32 bit physical address (already locked and verified), which is done automatically by the kernel. The strategy routine may build a request queue for further requests. Addresses received by IOCTL calls, are virtual addresses, not locked and not verified
# If the request can be answered in a short time, the strategy routine sets the return status in the request packet and ends. If the request can't be answered quickly (maybe the hardware isn't ready until yet), the driver should call a function to block the application thread. If the interrupt routine recognizes that the device is ready, the thread can be resumed. This mechanism is necessary to guarantee the multitasking mechanism. Code in the DD never preempts by the scheduler! You need to block the applications thread every time, if you can't directly deliver the result to the application. If the request can be answered directly, but it takes a lot of other calculation time In the strategy routine, yield the CPU every 3 milliseconds with a special function call.
# NO "standard" OS/2 API function call can be made in this mode! Only special device-helper-functions can be used!
  
Interrupt routine: 
# The interrupt routine can be preempted by higher priority interrupts.
# If time critical device checking is performed, it's a good idea to disable interrupts (for a very short time), to avoid preemption.
# If the application thread has been blocked in the strategy routine, it can be resumed from the interrupt routine (if the data is available).
# NO "standard" OS/2 API function call can be done in this mode! Only special device-helper-functions can be used!
  
INIT routine: 
# After the device driver is loaded (via a DEVICE= or BASEDEV= statement in CONFIG.SYS), this routine is called via the strategy routine. The request packet is marked as an INIT command.
# Command line parameters can be read.
# Because the context of this routine is a kernel thread, running at ring 3 with I/O privilege, some device initialization can be done here.
# Some "standard" API functions can be used in this mode:
  
; [[DosBeep]] : (Generate sound from the speaker) 
; [[DosCaseMap]] : (Perform case mapping)
; [[DosChgFilePtr]] : (Change (move) file read/write pointer)
; [[DosClose]] : (Close file handle)
; [[DosDelete]] : (Delete file)
; [[DosDevConfig]] : (Get device configuration)
; [[DosDevIOCtl]] : (I/O control for devices)
; [[DosFindClose]] : (Close find handle)
; [[DosFindFirst]] : (Find first matching file)
; [[DosFindNext]] : (Find next matching file)
; [[DosGetEnv]] : (Get address of process environment string)
; [[DosGetInfoSeg]] : (Get address of system variables segment)
; [[DosGetMessage]] : (Get system message with variable text)
; [[DosOpen]] : (Open file)
; [[DosPutMessage]] : (Output message text to indicated handle)
; [[DosQCurDir]] : (Query current directory)
; [[DosQCurDisk]] : (Query current disk)
; [[DosQFileInfo]] : (Query file information)
; [[DosQFileMode]] : (Query file mode)
; [[DosRead]] : (Read from file)
; [[DosSMRegisterDD]] : (Register session switch notification)
; [[DosWrite]] : (Synchronous write to file)

= Device Helper Functions =
# Only these functions can be called for kernel services in the kernel and interrupt mode. Some of them could be called at INIT mode. The interface is called DevHlp interface, which provides these functions.
# One very important parameter is received with the first request packet while the driver gets initialized. This is a far pointer to the DevHlp entry point which needs to be saved by the driver to call the DevHlp functions, whenever needed!
# You need to look at the PDD reference guide to find out, which function can be called with which context. Not all functions are available at kernel (task time), interrupt and INIT context.
# There are about 90 DevHlp functions documented so far.
  
=== The functions can be grouped together into the following categories ===
1. Advanced BIOS Calls (ABIOS) 

2. Character Queue Management

3. PDD-VDD Communication Services

4. Context Hook Services

5.Interrupt Management

6. Memory Management

7. Monitor Management

8. Process Management

9. Request Queue Management

10. Semaphore Management

11. System Clock Management

12. System Services

13. Timer Services

==The Request Packet==
The Request Packet, which is received by the driver’s strategy routine, is divided into two different parts. The "Request Packet Header" and the "Command Specific Data".  The following request packet commands have been documented so far:
{|class="wikitable"
!Code||Function||Block DD||Character DD
|-
| 0 || INIT || X || X 
|-
| 1 || MEDIA CHECK || X ||
|-
| 2 || BUILD BPB || X ||
|-
| 4 || READ || X || X
|-
| 5 || NONDESTRUCTIVE READ NO WAIT || X || X
|-
| 6 || INPUT STATUS || || X
|-
| 7 || INPUT FLUSH|| || X
|-
| 8 || WRITE || X || X
|-
| 9 || WRITE WITH VERIFY || X || X
|-
| A || OUTPUT STATUS|| || X
|-
| B || OUTPUT FLUSH|| || X
|-
| D || OPEN DEVICE|| X|| X
|-
| E || CLOSE DEVICE|| X|| X
|-
| F || REMOVABLE MEDIA|| X||
|-
| 10 || GENERIC IOCtl|| X|| X
|-
| 11 || RESET MEDIA|| X||
|-
| 12|| GET LOGICAL DRIVE MAP|| X||
|-
| 13|| SET LOGICAL DRIVE MAP|| X||
|-
| 14|| DEINSTALL|| ||X
|-
| 16|| PARTITIONABLE HARD DISKS|| X||
|-
| 17|| GET HARD DISK/LOGICAL UNIT MAP|| X||
|-
| 1C|| SHUTDOWN || X|| X
|-
| 1D|| GET DRIVER CAPABILITIES|| X||
|-
| 1F|| INITIALIZATION COMPLETE|| ||X
|}

[[Category:Driver Articles]]