Jump to content

PDRREF:Exported Driver Function Reference: Difference between revisions

From EDM2
Ak120 (talk | contribs)
mNo edit summary
No edit summary
Line 11: Line 11:
!Function||Type
!Function||Type
|-
|-
|DrvInstall||GRE hardcopy
|[[DrvInstall]]||GRE hardcopy
|-
|-
|DrvRemove||GRE hardcopy
|[[DrvRemove]]||GRE hardcopy
|-
|-
|OS2_PM_DRV_DEVICENAMES||GRE hardcopy
|OS2_PM_DRV_DEVICENAMES||GRE hardcopy

Revision as of 17:26, 27 December 2019

Presentation Device Driver Reference for OS/2
  1. Introduction to OS/2 Presentation Drivers
  2. Design Considerations for All Drivers
  3. Graphics Engine/Presentation Driver Design Changes
  4. Design Considerations for Display Drivers
  5. Design Considerations for Hardcopy Drivers
  6. Display Drivers
  7. Distributed Console Access Facility (DCAF) Architecture
  8. Graphics Engine Hardcopy Drivers
  9. Queue Drivers
  10. Port Drivers
  11. Presentation Manager Function Categories
  12. Exported Driver Function Reference
  13. Mandatory and Simulated Graphics Engine Function Reference
  14. Device Support Function Reference
  15. DBIDI Command Structures and Command Flow

Appendixes

A - OS/2 Version Compatibility Considerations
B - Syntax Conventions
C - Format of the Journal File
D - Bit-Map Simulation for 16-Bit Hardcopy Drivers
E - Data Types
F - Notices

Miscellaneous

G - Glossary

Reprint Courtesy of International Business Machines Corporation, © International Business Machines Corporation

This chapter describes the entry points that are exported by the dynamic link library of a presentation driver:

EXPORTS
   OS2_PM_DRV_RING_LEVELS      /* All drivers - Optional  */
   OS2_PM_DRV_ENABLE_LEVELS    /* All drivers - Optional  */
   OS2_PM_DRV_ENABLE           /* All drivers - Mandatory */

The functions in this chapter are listed in the following index table. A detailed description of each function follows the table.

Function Type
DrvInstall GRE hardcopy
DrvRemove GRE hardcopy
OS2_PM_DRV_DEVICENAMES GRE hardcopy
OS2_PM_DRV_DEVMODE GRE hardcopy
FillLogicalDeviceBlock exported entry point
FillPhysicalDeviceBlock exported entry point
DisablePhysicalDeviceBlock exported entry point
EnableDeviceContext exported entry point
DisableDeviceContext exported entry point
SaveDCState exported entry point
RestoreDCState exported entry point
ResetDCState exported entry point
CompleteOpenDC exported entry point
BeginCloseDC exported entry point
InstallPMEngineDisplayHooks exported entry point
QueryDeviceSurface exported entry point
OS2_PM_DRV_QUERYSCREENRESOLUTIONS display driver

Enable Levels

This entry point is the address of a table of ring levels required when calling each of the Enable subfunctions. The table is an array of bytes corresponding to the subfunction numbers, terminating with a byte of 0 (that is, an ASCIIZ string). The most significant six bits of each byte are reserved and must be 0. The remaining two bits of each byte represent the ring level to be used when dispatching the corresponding function in the dispatch table.

   00 = End of Table         10 = Ring 2
   01 = Ring-2-Conforming    11 = Ring 3

Any subfunction that does not have a corresponding byte in the table will be dispatched as Ring-2-conforming. This is the most desirable case from the standpoint of system performance.

Subfunction Type
Unused 0x01
FillLogicalDeviceBlock 0x01
FillPhysicalDeviceBlock 0x03
Unused 0x01
DisablePhysicalDeviceBlock 0x02
All others 0x00

The following example of six bytes would declare FillPhysicalDeviceBlock as Ring 3, DisablePhysicalDeviceBlock as Ring 2, and all other subfunctions as Ring-2-conforming:

  0x01    0x01    0x03    0x01    0x02    0x00

If the address of this table is not exported, all subfunctions will be called as Ring-2-conforming as if the table had contained the single byte 0x00.

Ring Levels

This entry point is the address of a table of ring levels required when dispatching each of the functions hooked in the dispatch table by FillLogicalDeviceBlock. The table is an array of bytes corresponding to the functions in the dispatch table, terminating with a byte of 0 (that is, an ASCIIZ string). The most significant six bits of each byte are reserved and must be 0. The remaining two bits of each byte represent the ring level to be used when dispatching the corresponding function in the dispatch table.

   00 = End of Table         10 = Ring 2
   01 = Ring-2-Conforming    11 = Ring 3

Any function that does not have a corresponding byte in the table will be dispatched as Ring-2-conforming. This is the most desirable case from the standpoint of system performance.

Function Type
GreGetArcParameters 0x01
GreSetArcParameters 0x01
GreArc 0x03
GrePartialArc 0x02
All others 0x00

The following example of five bytes would declare GreArc as Ring 3, GrePartialArc as Ring 2, and all other functions as Ring-2-conforming:

  0x01    0x01    0x03    0x02    0x00

If the address of this table is not exported, all functions will be dispatched as Ring-2-conforming as if the table had contained the single byte 0x00.

QueryScreenResolutions

  • OS2_PM_DRV_QUERYSCREENRESOLUTIONS