[Version]
 
Signature="signature-name"
[Class=class-name]
[ClassGuid={nnnnnnnn-nnnn-nnnn-nnnn-nnnnnnnnnnnn}]
[Provider=%INF-creator%]
[LayoutFile=filename.inf [,filename.inf]... ]
[CatalogFile=filename.cat]
[CatalogFile.nt=unique-filename.cat]
[CatalogFile.ntx86=unique-filename.cat]
[CatalogFile.ntia64=unique-filename.cat] (Windows XP and later versions of Windows)
[CatalogFile.ntamd64=unique-filename.cat] (Windows XP and later versions of Windows)
DriverVer=mm/dd/yyyy[,w.x.y.z]
[DontReflectOffline=1] (Windows Vista and later versions of Windows)
[PnpLockDown=0|1] (Windows Vista and later versions of Windows)
[DriverPackageDisplayName=%driver-package-description%]
[DriverPackageType=PackageType]

By convention, the Version section appears first in INF files. Every INF file must have this section.

Entries

Signature="signature-name"

Must be $Windows NT$, $Windows 95$, or $Chicago$, indicating the operating systems for which this INF is valid. These signature values have the following meanings.

Signature Value	Meaning
$Windows NT$	NT-based operating systems
$Windows 95$	Windows 9x/Me
$Chicago$	All Windows operating systems

The enclosing $'s are required but these strings are case-insensitive. If signature-name is none of these string values, the file is not accepted as a valid INF.

Generally, Setup does not differentiate among these signature values. One of them must be specified, but it doesn't matter which one. You should specify the appropriate value so that someone reading an INF file can determine the operating systems for which it is intended. (For Windows Me installations, Setup generally chooses drivers with $Chicago$ or $Windows 95$ signatures, and only chooses drivers with $Windows NT$ signatures if no others are available.)

Some class installers place additional requirements on how the signature value must be specified. Such requirements, if they exist, are discussed in device type-specific sections of this DDK.

An INF must supply OS-specific installation information by appending system-defined extensions to its DDInstall sections, whether the signature-name is $Windows NT$, $Chicago$, or $Windows 95$. (See Creating INF Files for Multiple Platforms and Operating Systems for a discussion of these extensions.)

Class=class-name

For any standard type of device, this specifies the class name, which is usually one of the system-defined class names like Net or Display as listed in devguid.h, for the type of device to be installed from this INF file. See System-Supplied Device Setup Classes.

If an INF specifies a Class it should also specify the corresponding system-defined GUID value for its ClassGUID entry. Specifying the matching GUID value for a device of any predefined device setup class can install the device and its drivers faster since this helps the system setup code to optimize its INF searching.

If an INF adds a new setup class of devices to the system, it should supply a unique, case-insensitive class-name value that is different from any of the system-supplied classes in devguid.h. The length of the class-name string must be 32 characters or less. The INF must specify a newly generated GUID value for the ClassGUID entry. Also see INF ClassInstall32 Section.

This entry is irrelevant to an INF that installs neither a new device driver under a predefined device setup class nor a new device setup class.

ClassGuid = {nnnnnnnn-nnnn-nnnn-nnnn-nnnnnnnnnnnn}

Specifies the device-class GUID, formatted as shown here, where each n is a hexadecimal digit.

For a Windows 2000 and later (and Windows 98/Me) INF, such a GUID value determines the device setup class subkey in the registry ...\Class tree under which to write registry information for the drivers of devices installed from this INF file. This class-specific GUID value also identifies the device class installer for the type of device and class-specific property page provider, if any.

For a new device setup class, the INF must specify a newly generated ClassGUID value. For more information about creating GUIDs, see Using GUIDs in Drivers. Also see Device Setup Classes.

Provider=%INF-creator%

Identifies the provider of the INF file. Typically, this is specified as an %OrganizationName% token that is expanded later in the INF file's Strings section. The maximum length, in characters, of a provider name is LINE_LEN.

For example, INF files supplied with the system typically specify the INF-creator as %Msft% and define %Msft% = "Microsoft" in their Strings sections.

LayoutFile=filename.inf [,filename.inf]...

Specifies one or more additional system-supplied INF files that contain layout information about the source media required for installing the software described in this INF. All system-supplied INF files specify this entry.

INF files that are not distributed with the operating system should omit this entry, if possible. Instead, such INF files should use Include and Needs entries in DDInstall sections, or they should have SourceDisksNames and SourceDisksFiles sections, or both. INF files not distributed with the operating system should include a LayoutFile directive only if

• they require OS-supplied files as part of their installation, and those files are not installable using OS-provided INF sections that can be referenced by Include and Needs entries, or
• they are used to support Windows 9x/Me. (Windows 9x/Me does not automatically include the layout files referenced by INF files you specify in Include entries, so the including INF must reference the layout files itself with LayoutFile entries.)

CatalogFile=filename.cat

Specifies a catalog (.cat) file to be included on the distribution media of a device/driver. Catalog files are supplied by the Microsoft Windows Hardware Quality Lab (WHQL), after WHQL has tested and assigned digital signatures to driver files. (Contact WHQL for more information about the testing and signing of IHV and/or OEM driver packages.)

Catalog files are not listed in the SourceDisksFiles or CopyFiles sections of the INF. Setup assumes that the catalog file is in the same location as the INF file.

System-supplied INF files never have CatalogFile= entries because the operating system validates the signature for such an INF against all system-supplied xxx.cat files.

[CatalogFile.nt=unique-filename.cat] |
[CatalogFile.ntx86=unique-filename.cat] |
[CatalogFile.ntia64=unique-filename.cat] |
[CatalogFile.ntamd64=unique-filename.cat]

Specifies another INF-writer-determined, unique file name, with the .cat extension, of a catalog file that is specific to Windows 2000 or later.

If these optional entries are omitted from a dual-operating system INF file, a given CatalogFile=filename.cat is used for validating WDM device/driver installations on all Windows 2000 and later and Windows 98/Me machines. If any decorated CatalogFile.xxx= entry exists in an INF's Version section together with an undecorated CatalogFile= entry, the undecorated entry is assumed to identify a filename.cat for validating device/driver installations only on Windows 98/Me machines.

Note that any cross-platform and/or dual-operating system device/driver INF file that has CatalogFile= and CatalogFile.xxx= entries must supply a unique IHV/OEM-determined name for each such .cat file.

For information about how to use the system-defined .nt, .ntx86, .ntia64, and .ntamd64 extensions, see Creating INF Files for Multiple Platforms and Operating Systems.

DriverVer=mm/dd/yyyy[,w.x.y.z]

This entry specifies version information for drivers installed by this INF. This entry is required beginning with Windows 2000.

For information about how to specify this entry, see INF DriverVer Directive.

DontReflectOffline=1

This directive is for internal use only on Windows Vista and later versions of Windows. This directive must not be used for any reason in a third-party INF file. Note that this directive is present in some inbox driver INF files, and an INF file writer must be careful not to copy this directive along with other INF Version directives that the writer might copy from an inbox driver INF file.

[PnpLockDown=0|1]

Specifies whether Plug and Play (PnP) prevents applications from directly modifying the files that a driver package’s INF file specifies. If the PnpLockDown directive is set to 1, PnP prevents applications from directly modifying the files that are copied by INF CopyFiles directives. Otherwise, if the directive is not included in an INF file or the value of the directive is set to zero, an application with administrator privileges can directly modify these files. Driver files that are protected in this manner are referred to as third-party protected driver files.

To ensure the integrity of a PnP driver installation, applications should not directly modify driver files that are copied by the driver package INF file. Applications should only use the device installation mechanisms provided by Windows to update PnP drivers. Beginning with Windows Vista, a driver package should set PnpLockDown to 1 to prevent an application from directly modifying driver files. Note, however, that some existing applications that uninstall driver packages do directly delete driver files. To maintain compatibility with these applications, the PnpLockDown directive for such driver package should be set to zero.

Although PnP on Windows Vista and later versions of Windows does not require that an INF file include a PnpLockDown directive in order to install a driver, PnP in a future version of Windows might require that INF files for PnP driver packages include the PnpLockDown directive.

DriverPackageDisplayName=%driver-package-description%

Specifies a string token that corresponds to a string key entry in an INF Strings section; the string key entry supplies the driver package display name. Driver Install Frameworks (DIFx) uses the driver package display name to describe the purpose of driver package to end users, as described in Specifying the Driver Package Display Name.

DriverPackageType=PackageType

Specifies the driver package type. Driver Install Frameworks (DIFx) uses the driver package type to determine the type of driver package, as described in Specifying the Driver Package Type.

Comments

When a driver package passes Microsoft Windows Hardware Quality Lab (WHQL) testing, WHQL returns .cat catalog files to the IHV or OEM. Each .cat file contains a digitally encrypted signature for the driver package. The IHV or OEM must list these .cat files in the INF Version section and must supply the files on the distribution media, in the same location as the INF file. The .cat files must be uncompressed.

Note that if an INF Version section does not include at least one CatalogFile or CatalogFile.ntxxx entry, the driver is treated as unsigned, and dates listed in the DriverVer directive will not be displayed in the UI. For more information, see Driver Signing.

Example

The following example shows a Version section typical of a simple device-driver INF, followed by the required SourceDisksNames and SourceDisksFiles sections implied by the entries specified in this sample Version section:

[Version]
Signature="$Chicago$"
Class=SCSIAdapter
ClassGUID={4D36E97B-E325-11CE-BFC1-08002BE10318}
Provider=%INF_Provider%
CatalogFile=aha154_win98.cat
CatalogFile.ntx86=aha154_ntx86.cat
DriverVer=08/20/1999
 
[SourceDisksNames]
;
; diskid = description[, [tagfile] [, <unused>, subdir]]
;
1 = %Floppy_Description%,,,\Win98
2 = %Floppy_Description%,,,\WinNT
 
[SourceDisksFiles]
;
; filename_on_source = diskID[, [subdir][, size]]
;
aha154x.mpd = 1,,
 
[SourceDisksFiles.x86]
aha154x.sys = 2,\x86
 
; ...

[Strings]
INF_Provider="Adaptec"
Floppy_Description = "Adaptec Drivers Disk"
; ...

See Also

DDInstall, SourceDisksNames, SourceDisksFiles, Strings