Last edit: 98-06-04 Graham Wideman

Delphi

Overview

The basic model is shown below:

The keys to the whole picture are the kernel functions highlighted in yellow.   These are what the driver uses to install our desired I/O permissions map.  (Some comments on this below.)

The unit gwiopm.pas contains an object GWIOPM_Driver with a number of methods to install the driver, prepare an I/O permissions map and hand that to the kernel.   An I/O permissions map is 8K bytes, with each bit controlling access to one port in the x86's 64K I/O port address space. Bit 0 of Byte 0 controls I/O address 0, and so on.

There are other auxiliary functions to provide some diagnostics and general hacking satisfaction.

OpenSCM: DWORD;
CloseSCM: DWORD;

Install(newdriverpath: string): DWORD;
Start: DWORD;
Stop: DWORD;
Remove: DWORD;

DeviceOpen: DWORD;
DeviceClose: DWORD;

IOCTL_IOPMD_READ_TEST
    (var RetVal: DWORD): DWORD;
IOCTL_IOPMD_READ_VERSION
    (var RetVal: DWORD): DWORD;

IOCTL_IOPMD_CLEAR_LIOPM: DWORD;
IOCTL_IOPMD_SET_LIOPM
  (Addr: Word; B: byte): DWORD;

IOCTL_IOPMD_GET_LIOPMB
  (Addr: Word; var B: byte): DWORD;
IOCTL_IOPMD_GET_LIOPMA(var A: TIOPM): DWORD;

LIOPM_Set_Ports
  (BeginPort: word; EndPort: word; 
   Enable: Boolean): DWORD;

IOCTL_IOPMD_ACTIVATE_KIOPM: DWORD;

IOCTL_IOPMD_DEACTIVATE_KIOPM: DWORD;

IOCTL_IOPMD_QUERY_KIOPM: DWORD;

ErrorLookup(ErrorNum: DWORD): string;

Kernel Functions

These were partly documented by Dale Roberts, and I have experimented with them a little more. So here's what I think they do:

void 
Ke386IoSetAccessProcess(PEPROCESS, int);

void 
Ke386SetIoAccessMap(int, IOPM *); 

void 
Ke386QueryIoAccessMap(int, IOPM *);

In each case you can look at the gwiopm.c source to see how I used them, which follows how Dale Roberts used them, with a little bit of extra experimentation on the Query function.

Further Adventures...

Client-specific IOPM: The gwiopm.sys driver was written with only a single client application in mind.  In fact the whole idea of bypassing NT's resource arbitration/allocation philosophy and  programming directly to the I/O ports presupposes that only one application (or applications that are very friendly) will be using the driver.   However, it would make some sense to modestly redesign gwiopm so that the local IOPM table is client-app specific, rather than global for the driver. This could be done by defining a device extension to hold the port-enable info for each client.

I/O Port Driver:  The port I/O approach shown here takes the point of view that if you're wanting to manipulate ports directly, you probably want as few extraneous mechanisms in the picture as possible.  Hence, the actual cpu I/O instructions are right in your Delphi/assembler code.  However, another point of view would be that even though you are manipulating the hardware, you would still like a "good citizen" driver to arbitrate your port usage.  This, of course, requires a more sophisticated driver that essentially translates your app's "requests" for I/O into actual I/O actions. Such an approach was being taken by   Victor I. Ishikeev in his TVicHW_95 control for Win95 with a promise for an NT version sometime.  Or one could look at the samples in the NT DDK.

Writing Drivers in Delphi:  On the surface, it would appear that this can't be done. The primary reason is that Delphi lacks the compile/link functions to produce a .sys file, not to mention missing the Delphi-ized DDK header files.   However, you can get generic "adapter" drivers which will callback your Delphi code.  There is some overhead involved, but for some situations it could be just the ticket. Other products offer "Wizard"-style driver development, again avoiding the necessity to understand device drivers in depth (one hopes)  See:

• BlueWater System (WinRT)
• Tetradyne (DriverX)
• Vireo (Driver::Agent)

Resources

Start at Cherry Hill:

Go to: