The parameters to the IOCTL request packet are stored in the following fields in the associated I/O request packet (IRP).
IRP.CurrentStackLocation -> IOControlCode | Function code |
---|---|
IRP.SystemBuffer | Address of parameter buffer (if used) |
IRP.CurrentStackLocation -> InputBufferLength | Length of parameter buffer |
IRP.UserBuffer | Address of data buffer |
IRP.CurrentStackLocation -> OutputBufferLength | Length of data buffer |
Note that under Windows NT, the operating system reserves the low nibble of IOCTL function codes to determine the method used to map the various buffers passed on the DeviceIoControl function call into the driver address space. The various options available to device driver writers are:
Low nibble | IOCTL definition |
---|---|
0 | METHOD_BUFFERED |
1 | METHOD_IN_DIRECT |
2 | METHOD_OUT_DIRECT |
3 | METHOD_NEITHER |
For further details of the memory mapping performed by these various options, refer to the Windows NT DDK documentation.
For a driver function code of ZZ, using memory mapping code M, the IOCTL code passed on the DeviceIoControl function call is 0xZZM.
The function codes are set out as shown below. Note that all other function codes will be returned with the error ERROR_INVALID_DEVICE_REQUEST in the field IoStatus.Status. The Windows NT I/O System validates the address and length of the areas passed as parameter and data packets. If the address validation fails, an exception will be raised.
All requests must return immediately. In general, they are simple, immediate operations, but in the case of Transmit Frame and Receive Frame, the driver must not suspend the calling SNALink thread while waiting for I/O to complete — a relevant return code should be sent instead, allowing the SNALink to retry.
The complete list of functions is as follows:
Function | Function code | Windows NT IOCTL code |
---|---|---|
Set Event/Semaphore Handle | 0x41 | 0x410 |
Set Link Characteristics | 0x42 | 0x420 |
Set V24 Output Status | 0x43 | 0x430 |
Transmit Frame | 0x44 | 0x441 |
Abort Transmitter | 0x45 | 0x450 |
Abort Receiver | 0x46 | 0x460 |
Off-Board Load | 0x47 | 0x470 |
Get/Set Interface Record | 0x61 | 0x613 |
Get V24 Status | 0x62 | 0x622 |
Receive Frame | 0x63 | 0x632 |
Read Interface Record | 0x64 | 0x642 |
In the function descriptions in the following topics, the bit-numbering convention is: The bits in a byte are numbered 0 through 7, where bit 0 is the least significant and bit 7 is the most significant.
Note There is no function for the controlling autodialer across the synchronous dumb card interface. This autodial feature is implemented in the link service itself. The Microsoft link services that support the synchronous dumb card interface first perform the dial operation by sending the dial string containing the server-stored number to a COM port rather than the SDLC chip, and then sending a command to the device driver to raise DTR via an Set V24 Output Status IOCTL.