Windows inf file structure

Summary of INF Sections

The following summarizes the system-defined sections that can be used in INF files. System-defined section names are case-insensitive. For example, version, VERSION, and Version are equally valid section-names within an INF file.

This section describes the INF file sections in the same order that they generally appear in most device INF files. However, these sections actually can be specified in any arbitrary order. Windows finds all sections within each INF file by section name, not by sequential order, whether system-defined or INF-writer-defined.

Version Section
This is a required section for every INF file. For installation on Windows 2000 and later versions of Windows, this section must have a valid Signature entry.

SignatureAttributes Section
This section of the INF defines a set of files to be embedded-signed as part of Hardware Certification. These additional signatures are required for devices with certain special needs. Examples are Protected Environment media playback, Early Launch Antimalware, and third party HAL extensions.

SourceDisksNames Section
This section is required if the INF file has a corresponding SourceDisksFiles section. This section is required to install IHV/OEM-supplied devices and their drivers from distribution media included in packaged products. It is also required in such an INF file that installs either of the following:

A co-installer DLL to supplement the operations of a system-supplied device class installer or co-installers (see also DDInstall.CoInstallers later in this list)

A new class installer DLL to supplement the operations of the OS’s device installer (see also ClassInstall32)

This section identifies the individual source distribution disks or CD-ROM discs for the installation. By contrast, the system-supplied INF files each specify a LayoutFile entry in their Version sections and provide at least one other INF file detailing the source distribution contents and layout of all software components to be installed.

SourceDisksFiles Section
This section identifies the locations of files to be installed from the distribution media to the destinations on the target computer. An INF file that has this section must also have a SourceDisksNames section.

DestinationDirs Section
Device/driver INF files have a DestinationDirs section to specify a default destination directory for INF-specified copies of the files supplied on the distribution media or listed in the INF layout files. This section is required unless the INF file installs a device, such as a modem or display monitor, that has no files except its INF to be installed with it.

ControlFlags Section
This section controls whether an INF file is used only to transfer files from the distribution media.

Generally, most INF files for device drivers and for the system class installers have this section so they can exclude at least a subset of Models entries from the list of manually installable devices to be displayed to end-users. INF files that only install PnP devices suppress the display of all model-specific information.

Manufacturer Section
This section is required in INF files for devices and their drivers.

The Manufacturer section of a system device class INF is sometimes called a «Table of Contents,» because each of its entries references an INF-writer-defined Models section, which, in turn, references additional INF-writer-defined sections, such as a per-models-entry DDInstall section, DDInstall.Services section, and so forth.

Models Section (per Manufacturer entry)
This section is required to identify the devices for which the INF file installs drivers. It specifies a set of mappings between the generic name (string) for a device, the device ID, and the name of the DDInstall section, elsewhere in the INF file that contains the installation instructions for the device.

An INF file that installs one or more devices and drivers for a single provider would have only one Models section, but system INF files for device classes can have many INF-writer-defined Models sections.

DDInstall Section (per Models entry)
This section is required to actually install any devices that are listed in a Models section in the INF file, along with the drivers for each such device. A DDInstall section can be shared by more than one Models section.

Читайте также:  Postgresql client mac os

DDInstall.Services Section
Starting with Microsoft Windows 2000, this section is required as an expansion of the DDInstall section for most kernel-mode device drivers. This includes any WDM drivers (exceptions are INF files for modems and display monitors). It controls how and when the services of a particular driver are started, its dependencies (if any) on underlying legacy, and so forth. This section also sets up event-logging services by a device driver if it supports event logging.

DDInstall.HW Section
This optional section adds device-specific (and typically, driver-independent) information to the registry or removes such information from the registry, possibly for a multifunction device or to install one or more PnP filter drivers.

DDInstall.CoInstallers Section
NoteВ В If you are building a universal or mobile driver package, this section is not valid. See Using a Universal INF File.

This optional section registers one or more device-specific co-installers supplied on the distribution media to supplement the operations of the system’s device installer or of an existing device class installer.

A co-installer is an IHV/OEM-provided Win32 DLL that typically writes additional configuration information to the registry or performs other installation tasks that require dynamically generated, machine-specific information that is not available when the device’s INF file is created. For more information, see Writing a Co-installer.

DDInstall.FactDef Section
NoteВ В If you are building a universal or mobile driver package, this section is not valid. See Using a Universal INF File.

This section should be included in the INF file of any manually installed non-PnP device. It specifies the factory default hardware configuration settings, such as the bus-relative I/O ports, IRQ (if any), and so forth, for the card.

DDInstall.LogConfigOverride Section
NoteВ В If you are building a universal or mobile driver package, this section is not valid. See Using a Universal INF File.

This section is used to create an override configuration, which overrides the hardware resource requirements that a Plug and Play device’s bus driver reports.

DDInstall.Interfaces Section
If a driver exports the functionality of a device interface class, therefore creating a new instance of the interface class, such as kernel-streaming still-image capture or data decompression, its INF file can have this section.

InterfaceInstall32 Section
If a to-be-installed component, such as a new class driver, provides one or more new device interface classes to higher-level components, its INF file has this section. In effect, this section bootstraps a set of device interfaces for a new class by setting up whatever is needed to use the functionality that the interface class provides.

DefaultInstall Section
An INF file’s DefaultInstall section will be accessed if a user selects the «Install» menu item after selecting and holding (or right-clicking) on the INF file name.

Strings Section
This section is required in every INF file to define each %strkey% token specified in the INF. By convention, the Strings section (or sections if the INF provides a set of locale-specific Strings sections) appears last in all system-supplied INF files for ease of maintenance and localization.

Some sections listed here, especially those with Install in their names, can contain directives that reference additional INF-writer-defined sections. Each directive causes particular operations to be performed on the items listed under the appropriate type of INF-writer-defined section during the installation process.

The set of valid entries and directives for any particular section in the previous list is section-specific and shown in the formal syntax of the reference for each of these sections. Additionally, see Summary of INF Directives for a summary of the most commonly used directives.

Optional entries and directives within each such section are shown enclosed in unbolded brackets, as for example:

[Version] . [Provider=%INF-creator%] . The Provider entry in a [Version] section is optional in the sense that it is not a mandatory entry in every INF file.

General Syntax Rules for INF Files

An INF file is a text file organized into named sections. Some sections have system-defined names and some sections have names determined by the writer of the INF file.

Читайте также:  Qemu bridge network linux

Each section contains section-specific entries that are interpreted by device installation components (class installers, co-installers, SetupAPI). Some entries begin with a predefined keyword. These entries are called directives.

Some INF file entries are basically pointers from one section to another, for a specific purpose. For example, an INF AddReg directive identifies a section that contains entries that instruct Windows to modify the registry. These entries sometimes include additional arguments (required or optional) for Windows to interpret during installation.

Other INF file entries do not point to other sections, but supply information that Windows uses during installation, such as file names, registry values, hardware configuration information, flags, and so on. For example, an INF DriverVer directive supplies driver version information.

When Windows begins an installation, it first looks for an INF Version section to verify the validity of the INF file and to determine where installation files are located. Then it starts the installation by finding an INF Manufacturer section. This section contains directives to INF Models sections, which in turn provide directives leading to various INF DDInstall sections, based on the hardware ID of the device being installed.

The following syntax rules govern the required and optional contents of INF files, the format of section names by using string tokens, and line format, continuation, and comments.

Case Sensitivity

  • Section names, entries, and directives are case-insensitive. For example, version, VERSION, and Version are equally valid section name specifications within an INF file.

Required and Optional Contents

The set of required and optional sections, entries, and directives in any particular INF file depends on the type of device/driver or component (such as an application or device class installer DLL) to be installed.

The set of sections, section-specific entries, and directives required to install any particular device and its drivers also depends somewhat on the corresponding class installer. For more information about how the system-supplied class installers handle device-type-specific INF files, see the device-type specific documentation in the WDK.

Within syntax definitions, optional entries are delimited by unbolded brackets ([,]). On the other hand, bold brackets ([, ]) are required elements of the entry in which they are contained. In the following example, the brackets around Version are required, while the brackets around Class=class-name indicate this entry is optional.

Section Names

Sections can be specified in any order. Most INF files list sections in a particular order, by convention, but Windows finds sections by name, not by location within the INF file.

Each section in an INF file begins with the section name enclosed in brackets ([ ]). The section name can be system-defined or INF-writer-defined.

For example, [Manufacturer] specifies the start of the system-named Manufacturer section, while [Std.Mfg] represents a particular INF-writer-defined Models section name.

A section name has a maximum length of 255 characters on Windows 2000 and later versions of Windows.

Each section ends at the beginning of a new [section-name] or at the end-of-file mark.

If more than one section in an INF file has the same name, the system merges their entries and directives into a single section.

Unless it is enclosed in double quotation marks characters («), an INF-writer-defined section name must be a unique-to-the-INF unquoted string of explicitly visible characters, excluding certain characters with INF-specific meanings. In particular, an unquoted section name referenced by a section entry or directive cannot have leading or trailing spaces, a linefeed character, a return character, or any invisible control character, and it should not contain tabs. In addition, it cannot contain either of the bracket ([ ]) characters, a single percent (%) character, a semicolon (;), or any internal double quotation marks («) characters, and it cannot have a backslash (\) as its last character.

For example, Std.Mfg and Std_Mfg are unique and valid section names when referenced by an INF file entry or directive, but Std;Mfg (with its internal semicolon) is invalid unless it is enclosed by double quotation marks («).

Specifying an INF-writer-defined section name as a «quoted string« overrides most of the restrictions that were previously described on characters in referenced section names. Such a delimited section name can contain almost any explicitly or implicitly visible characters except the closing bracket (]) as long as the corresponding section in the INF file matches this «quoted string« exactly.

Читайте также:  Свойства видеоадаптера windows 10

For example, «;; Std Mfg « is a valid section-name reference if the corresponding section declaration in the INF file exactly matches the name inside the double quotation marks with respect to its space and semicolon characters as [;; Std Mfg ].

Using String Tokens

Many values in an INF file, including INF-writer-defined section names, can be expressed as string key tokens of the form %strkey%. In the INF Strings section of the INF file, each string key must be associated with a string value that consists of a sequence of explicitly visible characters. If necessary, the setup code converts the string value, into Unicode.

For more information about how to define %strkey% tokens and their respective values, see the description of the INF Strings section.

Line Format, Continuation, and Comments

Each entry and directive in a section ends with a return or linefeed character. Therefore, the text editor used to create an INF file must not insert return or linefeed characters after some arbitrary, editor-determined number of characters.

The backslash character (\) can be used as an explicit line continuator in an entry or directive. However, backslash characters are used also in path specifications. To ensure that a backslash character that appears in a path specification is not misinterpreted as a line continuator, use the following strategy:

For a directive that spans two lines, one of which is an entry that contains a backslash, use quotation marks to delimit the entry that contains the backslash.

Avoid using the backslash character in the manner shown in the following example. Windows ignores the first backslash and interprets the second backslash as a line continuator.

The following syntax is valid and is equivalent to CopyFiles = «SomeDirectory\»,SomeFile ; comment .

Because text after a semicolon is ignored, CopyFiles = «SomeDirectory\» ; comment ,SomeFile does not work.

Comments begin with a semicolon (;) character. When parsing and interpreting an INF file, the system assumes that the following have no relevance to the installation process:

  • Any characters following a semicolon on the same line, unless the semicolon appears within a «quoted string« or %strkey% token
  • Any empty line that contains nothing except a linefeed or return character

Commas separate the values supplied in section entries and directives.

An INF file entry or directive can omit an optional value in the middle of a list of values, but the commas must remain. INF files can omit trailing commas.

For example, consider the syntax for a SourceDisksFiles section entry:

filename=diskid[,[subdir][,size]]

An entry that omits the subdir value but supplies the size value must specify the comma delimiters for both values, as shown in the following example:

filename=diskid,,size

An entry in an INF file that omits the two optional values can have this format:

filename=diskid

In order to include a percent (%) character in values supplied in section entries and directives, escape the percent character with another percent character.

For example, consider this statement in an [add-registry-section] section:

The registry value will be set with the following value:

In order to include a double quote («) character in values supplied in section entries and directives, escape the double quote character with another double quote character. Note that the string must be within a «quoted string«.

For example, consider this statement in an [add-registry-section] section:

HKR,,Example,,»Display an «»example»» string»

The registry value will be set with the following value:

Display an «example» string

INF Size Limits

The maximum length, in characters, of an INF file field, before string substitution and including a terminating NULL character, is 4096.

After string substitution, the maximum length, in characters, of an INF file string is 4096, which includes a terminating NULL character.

However, be aware that Plug and Play (PnP) may impose a more restrictive limit for certain INF file fields that it recognizes or uses, such as device description, driver provider, and device manufacturer.

Оцените статью