Creating Windows INF Files

Updated: December 4, 2001

To be installed, drivers for the Microsoft Windows 2000 and later operating systems must have an INF file. An INF file is a text file that contains all the necessary information about the device(s) and file(s) to be installed, such as driver images, registry information, version information, and so on, to be used by the Setup components.

Windows INF files do not contain installation scripts. The installation procedures are part of a Win32 installer application, such as the New Device wizard and the Add/Remove Hardware wizard, with each INF file acting as a resource.

Besides installing support for a device, an INF file can initialize a new setup class for the device. Such an INF has a ClassInstall32 section.

On This Page

  General Guidelines for INF Files
  Specifying the Source and Target Locations for Device Files
  Creating a Cross-Platform and/or Dual-Operating System INF File
  Creating International INF Files
  Tightening File-Open Security in a Device INF File

General Guidelines for INF Files

INF files have some common parts and follow a single set of syntax rules, but they are also as different as the variety of devices that are supported on a Windows machine. In addition to this article, you should consult the following sources of information when writing an INF file:

• The INF Files Sections and Directives reference material in the Windows 2000 DDK documentation.

• The Windows 2000 DDK documentation for your class of device. For example, if your device is a graphics adapter, see the Graphics Drivers section of the documentation.
  

• Windows 2000 DDK tools for INF files. The Windows 2000 DDK provides some tools to assist with writing INF files. See the tools directory in the DDK for information on tools such as GenINF and ChkINF.
  

• Sample INF files and INF files for similar devices. The Windows 2000 DDK includes INF files for its sample drivers. Peruse the sample drivers to see if there are INF files for devices similar to your device.
  

Create or modify an INF file using any text editor in which you can control the insertion of line breaks. If your INF contains non-ASCII characters, save the file as a Unicode file. Note that ChkINF does not support Unicode files.

An INF file that ships with the Windows 2000 operating system must have a file name of xxxxxxxx.inf, where "xxxxxxxx" is no longer than eight characters. The name of an INF file that ships separately from the operating system is not limited to eight characters.

 Top of page

Specifying the Source and Target Locations for Device Files

When Setup processes copy, rename, and delete file statements in an INF file, it determines the source and target locations for the files. To determine these locations, Setup assesses whether the driver ships with the operating system or separately and examines various INF file sections and entries including SourceDisksNames, SourceDisksFiles, LayoutFile, Include, Needs, and DestinationDirs. This section describes how Setup determines source and target locations and provides guidelines to help you correctly specify these locations.

Source Media For INFs that Ship Separately from the Operating System

INFs for drivers that are delivered separately from the operating system specify where the files are located using SourceDisksNames and SourceDisksFiles sections. If such an INF contains Include and Needs entries in the DDInstall section, those entries specify additional possible source locations.

If an INF has SourceDisksNames and SourceDisksFiles sections and no Include entries, the SourceDisksNames and SourceDisksFiles sections must list all the source media and source files in the kit, except for the catalog and INF files.

Catalog files must be in the same location as the INF file. Catalog files must not be compressed.

Source Media For INFs that Ship with the Operating System

If the files to support the device are included with the operating system, the INF must specify a LayoutFile entry in the Version section. Such an entry specifies where the files reside on the operating system media. An INF that specifies a LayoutFile entry must not include SourceDisksNames and SourceDisksFiles sections.

Only system-supplied INFs should reference layout.inf directly. OEM and IHV INF files that ship with the operating system can reference a common install section in a system-supplied INF (such as mf.inf) and the system-supplied INF references the layout.inf file.

Source Media and INFs that Contain Include and Needs Entries

If an INF has SourceDisksNames and SourceDisksFiles sections and Include and Needs entries, Setup uses the main INF file plus any of the "included" INF files to locate source media. It is especially important with included files to be as precise as possible when specifying source media and source file locations.

Consider the hierarchy of included INFs shown in Figure 1.

Figure 1 Sample Hierarchy of Included INF Files

In Figure 1, the INF for a multifunction device, MyMfDevice.inf, includes the system-supplied mf.inf file. In turn, the system-supplied mf.inf includes the system-supplied layout.inf file. When Setup searches for source media from which to copy a file referenced in MyMfDevice.inf, it looks for a SourceDisksFiles section in MyMfDevice.inf and in any included INF files that reference the file to be copied. Setup searches MyMfDevice.inf first, but it does not guarantee the order in which it searches the included INFs.

Decorated SourceDisksFiles sections take precedence over undecorated sections, even if the decorated section is in an included file. For example, for the INFs shown in Figure 1, if layout.inf contains a [SourceDisksFiles.x86] section and MyMfDevice.inf only contains an undecorated [SourceDisksFiles] section, Setup will use the decorated section from layout.inf first when installing on an x86 machine. Therefore, an INF that includes other INFs should contain section names that use platform extensions.

Typically, a vendor-supplied INF should specify the location of the files in its driver package and should not cause Setup to search included INFs for file locations. In other words, a vendor INF that copies files should specify both a SourceDisksNames and a SourceDisksFiles section, those sections should be decorated with platform extensions, and those sections should contain information for all the files directly copied by the INF. In addition, it is helpful if the vendor file names are as unique as possible, unless the installation is explicitly replacing a vendor-supplied file that shipped with the operating system.

Specifying Target Locations for Device Installation Files

An INF file specifies the target location for device files with a DestinationDirs section. The DestinationDirs section should always be specified in the same INF file as the section with the copy, rename, or delete statements.

A DestinationDirs section should include a DefaultDestDir entry.

If an INF has copy, rename, or delete sections but no DestinationDirs section, and the INF includes other INFs, Setup searches the included INFs for target location information. However, the order in which Setup searches the included files is not deterministic. Therefore, there is a risk that Setup will, for example, copy files to a location not intended by the INF writer. To avoid such confusion, always specify a DestinationDirs section in an INF that contains copy, rename, or delete sections. The DestinationDirs section should include at least a DefaultDestDir entry and can list sections in the INF that copy, rename, or delete files.

 Top of page

Creating a Cross-Platform and/or Dual-Operating System INF File

You can use system-defined extensions to create a single INF file for cross-platform installations and/or for dual-operating system installations. The extensions enable you to create decorated section names and decorated directives. Such decorations specify which DDInstall sections and related directives are relevant to each platform and/or operating system. You can create an INF that installs support for a device on the x86 platform for Windows 2000, on an alternate future platform for Windows 2000, on all Windows 2000 platforms, on Windows 9x platforms, or on all of the above.

For example, if your device supports Windows 2000 platforms and Windows 9x platforms, you would create an INF with two or more "parallel" DDInstall sections that have the following extensions to control what is installed on each platform and/or for each operating system:

• [install-section-name.NTx86] contains Windows 2000-specific instructions for installing the device or set of device-compatible models on all Windows 2000 x86-based platforms.

• [install-section-name.NT] contains Windows 2000-specific instructions for installing the device or set of device-compatible models on all Windows 2000 platforms. Currently,
  .NT represents the same set of platforms that are defined by .ntx86. If non-x86 platforms are supported by Windows 2000 in the future, .NT will represent the set containing .ntx86 platforms and those new platforms.

• [install-section-name] contains Windows 9x-specific instructions. Undecorated sections are also fallback sections for Windows 2000 platforms. Setup uses undecorated sections on Windows 2000 if it cannot locate the appropriate decorated sections. However, to prevent Windows 2000 sections from being used on Windows 9x by mistake, you should decorate any Windows 2000-specific
  DDInstall and related sections with the .ntx86 or .nt extensions.

Windows Setup processes these DDInstall sections as follows:

• On Windows 98, Setup processes the undecorated section and ignores any sections with .nt* platform extensions.

• On Windows 2000:

  • Setup checks for install sections with the platform-specific extensions, such as .ntx86. If present, Setup processes the section appropriate for the current platform. Setup checks for platform-specific install sections in the INF being processed and in any included INF files (that is, any INFs included with Include entries).

  • If there are no specific platform extensions, Setup checks for a DDInstall.nt section in the INF or any included INFs. If present, Setup processes the DDInstall.nt section.

  • If there is no DDInstall.nt section, Setup processes the undecorated section.

A DDInstall section with a platform extension also can set up additional per-device(s) sections of the INF. In particular for device and driver installations, it sets up the Windows 2000-required DDInstall.Services and, possibly, also DDInstall.HW, DDInstall.CoInstallers, DDInstall.LogConfigOverride, and/or DDInstall.Interfaces sections. In dual-operating system and/or cross-platform device/driver INF files, specify the appropriate extension immediately following the INF-writer-defined section name as, for example, install-section-name.NTx86.HW.

If there are one or more decorated DDInstall.NT and/or DDInstall.NTx86 section(s) in an INF file, that INF must have parallel decorated and undecorated additional per-device(s) sections. That is, if a dual-operating system INF has both DDInstall and DDInstall.NT sections and it has a DDInstall.HW section, it also must have a parallel DDInstall.NT.HW section (if the device or driver requires a .HW section for Windows 2000).

The INF File Sections and Directives section in the Windows 2000 DDK shows these extensions as part of the formal syntax statements in the appropriate section references, as for example:

[DDInstall.HW] |
[DDInstall.nt.HW] |
[DDInstall.ntx86.HW]

However, such a formal syntax statement indicates that these extensions are valid, but possibly optional, alternatives to the basic section. It does not indicate that any INF with a DDInstall.NT.HW section also must have every other platform-specific DDInstall.NTxxx.HW section. The writer of a Windows 2000 cross-platform and/or dual-operating system INF file can use any subset of these system-defined extensions to specify the minimum number of decorated sections required for the particular cross-platform and/or dual-operating system device/driver installation.

 Top of page

Creating International INF Files

An INF that will be used in an international market should use %strkey% tokens for all user-viewable text. The string tokens are defined in a [Strings] section, which is typically at the end of the INF file.

To create a single international INF file, the INF can have a set of locale-specific Strings.LanguageID sections, as described in the reference page for the INF Strings Section in the Windows 2000 DDK documentation.

Alternatively, you can create a separate INF for each locale. To reduce duplication and ease maintenance, you can create a main INF file with all the necessary sections and entries, except for the Strings section. Then create a second set of files, where each file contains just the Strings section for a supported locale. Concatenate the main file with each strings file to generate the locale-specific INF files.

If an INF contains characters outside the ASCII range (outside the range 0-127), the INF should be in Unicode format. To create such a file, for example, save the INF as a Unicode file from an application like Notepad. If the INF is not in Unicode format, Setup uses the current locale to translate characters. If the INF is in Unicode format, Setup uses the full character set.

 Top of page

Tightening File-Open Security in a Device INF File

For Windows 2000, Microsoft tightened file-open security in the class installer INFs for certain device classes, including CDROM, DiskDrive, FDC, FloppyDisk, HDC, and SCSIAdapter. If you are unsure whether the class installer for your device has tightened security on file opens, you should tighten security in the device INF.

In the INF file for the device, add the following entry in the [Xxx_AddReg] section:

[install-section-name.HW]  |















[install-section-name.nt.HW] |















[install-section-name.ntx86.HW] 































...















AddReg = Xxx_AddReg















...































[Xxx_AddReg]















...















HKR,,DeviceCharacteristics,0x10001,characteristics















			

The characteristics value is the numeric value of the characteristics to assign to the device. This value is the result of OR'ing one or more FILE_* file characteristics values as defined in wdm.h or ntddk.h. The significant characteristic with respect to security is FILE_DEVICE_SECURE_OPEN, which has a numeric value of 0x100. Setting this characteristic directs the I/O Manager to perform security checks on all open requests for the device. The FILE_DEVICE_SECURE_OPEN characteristic is defined in ntddk.h and wdm.h and is supported on Windows 2000 platforms; this characteristic is not supported on Windows 9x platforms.

A characteristics value of zero directs Setup to ignore the class-wide device characteristics, if any, that were specified in the associated class installer INF.

During device installation, the PnP Manager determines the device characteristics for a device object as follows. The PnP Manager:

1. Retrieves the characteristics settings for the device's class, if any, as specified in the class-installer INF.

2. Retrieves the characteristics for the device, if any, as specified in the device INF. Device-specific settings override class settings.

3. ORs the resulting INF-specified settings with those set in the device object by the driver, either directly or through IoCreateDevice.

4. ORs the device characteristics settings of the FDO and any filter DOs and propagates these settings to the FDO and filter DOs. If the device is in raw mode, and therefore has no FDO, the PnP Manager propagates the device characteristics across the PDO and any filter DOs.

The above steps ensure, for example, that if one driver for a device sets FILE_DEVICE_SECURE_OPEN, that characteristic is propagated to all the device objects for drivers servicing the device.

The PnP Manager ORs and propagates these characteristics after it has called the AddDevice routines for the device's drivers and after the drivers have created their device objects and attached them to the device stack, but before the PnP Manager sends the IRP_MN_START_DEVICE request.

The PnP Manager also propagates the following device characteristics when it propagates FILE_DEVICE_SECURE_OPEN: FILE_REMOVABLE_MEDIA, FILE_READ_ONLY_DEVICE, and FILE_FLOPPY_DISKETTE.

An INF file that has a ClassInstall32 section can set the FILE_DEVICE_SECURE_OPEN characteristic for a setup class of devices. See Tightening File-Open Security in a Class Installer INF File in the Windows 2000 DDK.

 Top of page

Related Links

• How to Publish Drivers on Windows Update