[install-section-name.Interfaces] |
[install-section-name.nt.Interfaces] |
[install-section-name.ntx86.Interfaces]
[install-section-name.ntia64.Interfaces]
AddInterface={InterfaceClassGUID} [, [reference string] [,[add-interface-section] [,flags]]] ...
[Include=filename.inf[,filename2.inf]...]
[Needs=inf-section-name[,inf-section-name]...]
Each per-Models DDInstall.Interfaces section can have one or more AddInterface directives, depending on how many device interfaces a particular device/driver supports.
To support existing device interfaces, such as any of the system's predefined kernel-streaming interfaces, specify the appropriate InterfaceClassGUID values in this section.
To install a component, such as a class driver, that exports a new class of device interfaces, an INF also must have an INF InterfaceInstall32 section.
For more information about device interfaces, see Device Interface Classes.
Needs entries cannot be nested. (For further information on the Needs entry and restrictions on its use, see Specifying the Source and Target Locations for Device Files.)
The DDInstall section name must be referenced by a device/models-specific entry under the per-manufacturer Models section of the INF file. For information about using the system-defined .nt, .ntx86, and .ntia64 extensions in cross-platform and dual-OS INF files, see Creating INF Files for Multiple Platforms and Operating Systems.
If a given {InterfaceClassGUID} is not installed already, the operating system's setup code installs that device interface class in the system. If an INF file installs one or more new device interface classes, it also has an [InterfaceInstall32] section identifying the GUID for the new class..
For more information about how to create a GUID, see Using GUIDs in Drivers. For the system-defined interface class GUIDs, see the appropriate system-supplied header, such as ks.h for the kernel-streaming interface class GUIDS.
When a driver is loaded, it must call IoSetDeviceInterfaceState once for each {InterfaceClassGUID} value specified in the INF's DDInstall.Interfaces section that the driver supports on the underlying device, to enable the interface for runtime use by higher level components. Instead of registering support for a device interface in an INF, a device driver can call IoRegisterDeviceInterface before making its initial call to IoSetDeviceInterfaceState. Usually, a PnP function or filter driver makes this call from its AddDevice routine.
This example shows the DDInstall.NT.Interfaces section in the dual-OS INF file for the system-supplied WDM audio device/driver shown as examples for the INF DDInstall section and the INF DDInstall.Services section.
;
; following AddInterface= are all single lines (without
; backslash line continuators) in the system-supplied INF file
;
[WDMPNPB003_Device.NT.Interfaces]
AddInterface=%KSCATEGORY_AUDIO%,%KSNAME_Wave%,\
WDM_SB16.Interface.Wave
AddInterface=%KSCATEGORY_AUDIO%,%KSNAME_Topology%,\
WDM_SB16.Interface.Topology
AddInterface=%KSCATEGORY_AUDIO%,%KSNAME_UART%,\
WDM_SB16.Interface.UART
AddInterface=%KSCATEGORY_AUDIO%,%KSNAME_FMSynth%,\
WDM_SB16.Interface.FMSynth
; ...
[Strings] ; only immediately preceding %strkey% tokens shown here
%KSCATEGORY_AUDIO% = "{6994ad04-93ef-11d0-a3cc-00a0c9223196}"
KSNAME_Wave = "Wave"
KSNAME_UART = "UART"
KSNAME_FMSynth = "FMSynth"
KSNAME_Topology = "Topology"
; ...
AddInterface, DDInstall, InterfaceInstall32, IoRegisterDeviceInterface, IoSetDeviceInterfaceState