## Input/Output Device Driver Reference

[prev][next][parent][TOC]

### INT 7Fh Software Interrupt and Function Table Call Handling

Following is the sequence of events when a real-mode program issues a software interrupt that has been hooked by a VDD:

1.At create time, VDD installs an interrupt vector hook (InstallHookVect() ).

2.The interrupt vector table gets patched with Address A.

3.Address A points to an illegal real-mode instruction (ARPL).

4.The software interrupt causes transfer to Address A.

5.The execution of the ARPL located there causes a trap.

6.The OS/2 operating system fields the trap.

7.OS/2 hooks into the list of procedures registered for this trap by way of InstallHookVect and calls each one in turn.

8.The hook procedures get passed a pointer to Client Register Frame (CRF).

9.The hook procedures process the call, based on registers passed in the CRF.

10.If the hook procedures interrupt, they call VDHPopInt(), which fills in the return CS:IP in the CRF.

11.The hook procedures return TRUE if they are interrupted; else, FALSE.

12.OS/2 calls the next procedure in the chain if FALSE; else, it returns to CS:IP as filled in the CRF.

See the following figure for the route from a real-mode application to the protect-mode VDD handler.

     [Artwork not shown]

With the IBM Touch Display, the interface to the device driver is by way of a call table, the address of which the application obtains by issuing INT 7F with AX=ABCDH and BX=0H. When it has obtained the call table address ( CTA), it then calls the individual function it requires by calling the address at (CTA) + 4*(FN-1), where FN is the required device driver function number. This cannot be done in the previous sequence, however, because calls cannot be made directly from the DOS (real-mode) application to the OS/2 (protect-mode) VDD.

The mouse INT 33 driver has a related problem in that it has a BASIC entry point located 2 bytes forward of the actual INT 33 vector address. (The first instruction of the INT 33 handler is a jump over the BASIC entry point code.) Therefore, a BASIC application would obtain Address A and then call (Address A + 2), which could be anything.

To resolve this, the VDD must have a real-mode portion that has a software interrupt handler similar to that provided by the DOS driver. Address A, then, is replaced by the address of this handler (Address B) by the VDD at create time, as well as saving Address A in real-mode.

For the particular case of the IBM Touch Display driver, the call table also must be part of the real-mode portion, enabling calls to its entries to be made directly by real-mode applications, with the interrupt handler setting the address of the table in ES:BX as in the real DOS driver, before calling Address A. If the handler received a call that did not belong to it (AX !=ABCDH), then it would call Address A directly.

The entries in the call table then consist of a common call into a router. The router determines the function number from the address from which it was called, then sets up the registers appropriately before calling Address A, as shown in the following figure.

     [Artwork not shown]