NDISTAPI Interface (NDIS 5.1)
Note NDIS 5. x has been deprecated and is superseded by NDIS 6. x. For new NDIS driver development, see Network Drivers Starting with Windows Vista. For information about porting NDIS 5. x drivers to NDIS 6. x, see Porting NDIS 5.x Drivers to NDIS 6.0.
This topic introduces the NDIS TAPI interface as it applies to NDIS WAN miniport drivers. Subsequent topics describe the implementation of operations that use this interface.
This section describes the OID requests that define the interface between the NDISTAPI driver, NDISWAN and underlying NDIS WAN miniport drivers. Each OID request that is described in the Microsoft Windows Driver Development Kit (DDK) and the Windows Driver Kit (WDK) has a corresponding Service Provider Interface (SPI) function that is defined in the Telephony Software Development Kit (SDK), which is documented in the Microsoft Windows SDK.
NDIS WAN miniport driver developers should consult the SPI specifications when designing and implementing drivers. Note that function definitions and parameters might differ slightly between the NDISTAPI specification and the SPI specification, in which case the developer should adhere to the NDISTAPI specification.
For a complete listing of the TAPI OIDs, see TAPI Objects.
Definitions for these OIDs are provided in ntddndis.h. Definitions for NDIS_TAPI_EVENT messages are provided in ndistapi.h.
The extent to which a given NDIS WAN miniport driver supports this interface depends in large part on the discretion of the miniport driver developer and the capabilities of the underlying hardware.
Requests that the NDIS WAN miniportdriver developer chooses not to support should be completed with the NDIS_STATUS_TAPI_OPERATIONUNAVAIL status code. The NDIS WAN miniport driver can indicate what types of requests it supports (which can vary over time depending on line, address, or call state) by setting or clearing specific bits in the members of structures present in some of the OID_TAPI_GET_XXX requests (for example, the ulAddrCapFlags member in the LINE_ADDRESS_CAPS structure used with OID_TAPI_GET_ADDRESS_CAPS).
Query information-type requests differ from set information-type requests in that one or more members in the request structure, denoted by the OUT prefix in the structure definition, are reserved for information to be passed back to the calling process. Members prefixed with IN should be considered read-only. The first member in all query information requests, ulRequestID, is reserved for future use, and should be ignored.
For a complete listing of TAPI query information OIDs, see TAPI Query Information Requests.
Set information requests return no information other than completion status. All request structure members should be considered as read-only, and should not be modified by NDIS WAN miniport drivers. The first member in all query information requests, ulRequestID, is reserved for future use, and should be ignored.
For a complete listing of TAPI set information OIDs, see TAPI Set Information Requests.