INF file details

INF file format requirements
An INF file is a simple text file organized by segments. Some segments are the names defined by the System-defined, while others are named by the writer of the INF file. Each segment contains specific entries and names used to reference additional segments defined elsewhere in the INF file.
INF File Syntax Rules:
1. Required content: the required and optional segments, entries, and commands in a specific inf file depend on the device components to be installed. The endpoint sequence can be arbitrary. Most INF files are installed in the usual sequence to arrange various segments.
2. segment name: each segment of the INF file starts with a segment name enclosed in square brackets. Segment names can be defined by system or inf writers
In Windows 2000, the maximum length of a segment name is 255 characters. In Windows 98, the segment name should not exceed 28 characters. If the INF design is to run on two platforms, the minimum limit must be observed. Segment names, entries, and commands are case-insensitive. In an INF file, if more than two segments have the same name, the system merges their entries and commands into one segment. Each segment ends with the start of another new segment or the end of the file.
3. Mark by string: many values in the INF file, including the segment names defined by the INF writer, can be marked as % strkey %. Each such strkey must be defined in the strings section of the INF file as a value consisting of a series of visible characters.
4. line format, continuation, and comment: each entry or command in the segment ends with a carriage return or line break. In an entry or command, "/" does not have to be used as a display line break; points ";" indicates that the following content is a comment; can be used ", "to separate the entry and the multiple values provided in the command.
INF file example
The following is a complete. inf file, which is the. inf file attached to the driver sample in Windows 2000 ddk usb bulk.
; Installation INF for the Intel 82930 USB bulk Io test board
;
; (C) copyright 1999 Microsoft
;
[Version]
Signature = "$ Chicago $"
Class = USB
Classguid = {36fc9e60-c465-11cf-8056-444553540000}
Provider = % MSFT %
Driverver = 08/05/1999
[Sourcedisksnames]
1 = "bulkusb installation disk ",,,
[Sourcedisksfiles]
Bulkusb. sys = 1
Bulkusb. inf = 1
[Manufacturer]
% Mfgname % = Microsoft
[Microsoft]
% USB/vid_045e & pid_930a.devicedesc % = bulkusb. Dev, USB/vid_045e & pid_930a
; [Precopysection]
; Hkr, nosetupui, 1
[Destinationdirs]
Bulkusb. Files. Ext = 10, system32/Drivers
Bulkusb. Files. inf = 10, INF
[Bulkusb. Dev]
Copyfiles = bulkusb. Files. Ext, bulkusb. Files. inf
Addreg = bulkusb. addreg
[Bulkusb. Dev. nt]
Copyfiles = bulkusb. Files. Ext, bulkusb. Files. inf
Addreg = bulkusb. addreg
[Bulkusb. Dev. nt. Services]
Addservice = bulkusb, 0x00000002, bulkusb. addservice
[Bulkusb. addservice]
Displayname = % bulkusb. svcdesc %
Servicetype = 1; service_kernel_driver
Starttype = 3; service_demand_start
Errorcontrol = 1; service_error_normal
Servicebinary = % 10%/system32/Drivers/bulkusb. sys
Loadordergroup = base
[Bulkusb. addreg]
Hkr, devloader, * ntkern
Hkr, ntmpdriver, bulkusb. sys
HKLM, "system/CurrentControlSet/services/bulkusb/parameters", "maximumtransfersize", 0x10001,4096
HKLM, "system/CurrentControlSet/services/bulkusb/parameters", "debuglevel", 0x10001,2
[Bulkusb. Files. Ext]
Bulkusb. sys
[Bulkusb. Files. inf]
Bulkusb. inf
;---------------------------------------------------------------;
[Strings]
MSFT = "Microsoft"
Mfgname = "Intel"
USB/vid_045e & pid_930a.devicedesc = "bulkusb. sys intel 82930 USB bulk Io test board"
Bulkusb. svcdesc = "bulkusb. sys i82930 bulk Io test driver"
INF file details
From the complete example above, we can have a general impression on the INF file, including the section in the INF file and the writing format of each section. The following describes in detail each section of the INF file.
1. [version] Section
Traditionally, each inf file starts with a version segment, which determines the device type described in the file. The Verson segment in the preceding example has the following statements:
Signature = "$ Chicago $"
Class = USB
Classguid = {36fc9e60-c465-11cf-8056-444553540000}
Provider = % MSFT %
Driverver = 08/05/1999
Signature indicates the operating system that uses this INF file. It can be $ chicage $, $ Windows NT $ (containing a space), or $ Windows 95 $ (containing a space, the delimiters $ are indispensable and the strings are case-insensitive. If the signature value is not one of these valid strings, the INF file will be invalid. If an INF file is used to install the device driver on Windows 2000 and Windows 98, it must use the ddinstall segment to add system-defined extensions and specify the installation information specific to any operating system, regardless of the value of signature.
Class specifies the Class Name of the device. In this example, the USB class is specified. Classguid specifies the guid of the device registry. GUID is a 128-bit identifier. the DDK header file devguid. h defines the guid of the standard device class.
Provide indicates the provider of the INF file. The specific content of % MSFT % will be defined in the strings section. The definition in the example is MSFT = "Microsoft", indicating that the INF file provider is Microsoft.
The driverver entry provides the version information of the entire inf file, and adds the driverver entry to each install segment to provide the driver version information. The driver version entries of the install segment are more specific and have a higher priority than the global driverver entry date of the version segment. When the Operating System Searches for drivers, it selects a driver with a closer driverver date to replace an earlier driver. If an INF does not have a driverver entry, the operating system uses the default date 00/00/0000.
2. [sourcedisknames] Section
This section defines and names one or more disks that contain source files. These source files are used for file copy or rename operations. This segment can have any entry, and each entry corresponds to a source disk. The entry format is as follows:
Disk = % strkey % | "disk-description", [tagfile], [unused], [path]
Diskid indicates a non-negative integer of the source disk. This value can be in hexadecimal or decimal format, but it cannot occupy 4 bytes of storage unit. The right side of the equation specifies a string marked with % strkey % or a pair of quotation marks to describe the content or purpose of the drive letter marked by diskid. During the installation process, the installation program displays the string value to the end user. Tagfile is an optional value that specifies the feature file name provided on the disk. No directory or subdirectory is specified. The installer uses the feature file to verify that the user inserts the correct installation disk. Feature files can only be used for removable media.
The unused value is not used in Windows 2000, but only in Windows 9X. PATH is also an optional option to identify the directory path on the disk that contains the source file. The content of the sourcedisksnames section in the example is as follows:
[Sourcedisknames]
1 = "bulkusb installation disk "...
The example specifies that the source disk is Disk 1. During installation, the installer can display the string "bulkusbinstallation disk" to the end user ".
3. [sourcedisksfiles] Section
This section names the source files used during the installation, flags the disk (or CD-ROM) that contains these source files, and provides the directory path for each file contained on the disk. One sourcesdisksfiles segment can have any number of entries, and each file on the disk has an entry. It contains the entry format
Filename = disked [, [subdir] [, size].
Filename specifies the name of the source file on the disk. The diskid is an integer at the top to indicate the disk that contains the source file.
Diskid specified in the sourcedisksnames segment; subdir is an optional value, which specifies the subdirectory of the file on the source disk. If this entry is omitted, the specified source file is either in the root directory of the given disk or in the directory specified by the path entry in the sourcedisksnames segment. size is also an optional value that specifies the non-compressed length of the given file, it is marked in bytes. The content of the sourcedisksfiles section in the example is as follows:
[Sourcedisksfiles]
Bulkusb. sys = 1
Bulkusb. inf = 1
In this example, the entries are created for the two files, both of which are in Disk 1 and under the root directory.
4. [manufacturer] Section
This section marks the manufacturer of one or more devices installed with the INF file. It also defines the models segment name for the manufacturer's device, that is, the driver installation. Each inf file must have a manufacturer segment.
The manufacturer section of the preceding example has an entry:
[Manufacturer]
% Mfgname % = Microsoft
The string defined by % mfgname % can be found in the strings Section. This example defines mfgname = "Intel", indicating that the device manufacturer is intel. Microsoft on the right is also the name of the models segment of the manufacturer. In INF, a name defined by the INF writer is specified for the models segment of each manufacturer. This name must be applied in the manufacturer segment. The manufacturer models section in the example is as follows:
[Microsoft]
% USB/vid_045e & pid_930a.devicedesc % = bulkusb. Dev, USB/vid_045e & pid_930a
This section belongs to the models segment of the manufacturer. The segment name is defined by the INF compiler and does not belong to the system segment name. Each manufacturer's models segment identifies at least one device, and requires that the vendor ID (VID) and product ID (PID) of the device simultaneously reference the install segment of the device inf file. This section can also specify one or more additional device IDs, because multiple devices are compatible with the device recognized by the initial hardware ID and are also driven by the same driver. When the device manager finds the ID defined by this segment, the Device Manager will find the correct inf file.
The example specifies a device. The vid of the device is 0x045e, And the PID is 0x930a. The VID is allocated by the USB Management Board to each USB chip manufacturer. For example, the vid of Philips is 0x0471, And the vid of Cypres is 0x0547, in this example, the vid is from Intel. The product ID (PID) is defined by various manufacturers. Here vid0x930a is an Intel USB Batch Transfer lab board.
In this example, bulkusbdev on the right of the equation identifies the device with an install segment defined by the INF file writer.
5. [destinationdirs] Section
This section specifies the target directory for all hardware copy, delete, and rename operations. The destinationdirs section in the example is as follows:
[Destinatindirs]
Bulkusb. Files. Ext = 10, system32/Drivers
Bulkusb. Files. inf = 10.inf
The section name defined by the INF file Creator on the left of the entry equation in the destinationdirs section will be saved to the directory specified on the right of the equation, these files can be referenced by the copyfiles, renfiles, and delfiles commands in other places in the INF file. For example, the two sections in the example are defined as follows:
[Bulkusb. Files. Ext]
Bulkusb. sys
[Bulkusb. Files. inf]
Bulkusb. inf
In the destinationdirs segment, 10 on the right of the equal sign of the entry is a logical disk identifier (ldid). It specifies the identifier of the target directory for file operations, followed by a subdirectory, as the destination address for file operations. In this example, the target address of the first file bulkusb. sys is winnt/system32/drivers, and that of the Second file bulkusb. inf is winnt/INF.
The destinationdirs segment can also contain the defaultdestdird entry in the default target directory, which is the target path omitted for all file copy, delete, and rename operations, these files are not explicitly listed in the list of files referenced by other entries. The device information file reference file of Windows DDK has other ldid well-known definitions, as shown in the following table.
Definition of common ldid
Ldid Value
Target directory
00
Null ldid, which can be used to create a new ldid
01
Source disk drive:/path
02
Temporary installation folder, only valid during installation
03
Uninstalling directory
10
Windows Directory
11
System Directory
12
Io sub-system directory
13
Command directory
14
Control Panel directory
15
Printer directory
16
Working category directory
17
INF directory
18
Help directory
19
Registration
20
Font
21
Viewers
22
Vmm32
23
Color directory
24
Application directory
25
Shared directory
26
Winboot
28
Host winboot
30
Root directory of the boot drive
31
Root directory of the host drive of the virtual boot drive
5. Install segments
The Install section contains actual instructions to guide the installation program to install the required software. This section must be referenced in a device or model entry. Each install segment of each models includes an optional driverver entry and one or more commands that reference command segments in information, the segments used for these command indexes contain driver installation files and device-specific and driver-specific information commands written to the Registry. Here, we will first list the common formats of this disconnection.
[Install-section-name]
Install-section-name.nt
Install-section-name.ntx86
[Driverver = mm/DD/YYYY]
[Copyfiles = @ filename | file-list-section]
Addreg = add-registry-Section
[Include = filename. inf]
... ...
... ...
First, we can see three optional segment names. On the Windows 9x platform, an unmodified install segment name [install-section-name] is provided. it specifies the device installation entry. On the Windows 2000 platform
The [install-section-name.nt] segment name is provided if you want to restrict it to x86-based Windows 2000 platforms. The device installer will search for the install segment with the most appropriate suffix. For example, if there are three install segments, the first has no suffix, and the last two have. nt and. ntx86 suffixes respectively. If it is installed in Windows 2000 on the X86 platform, the installer will use. ntx86 segment. If it is installed on a non-Intel Platform running Windows 2000, the installer will use. NT segment; if installed in Windows 98, the installer uses a non-suffix segment. The driverstudiover entry is the version information described above.
☆[ Copyfiles = @ filename | file-list-section]: You can specify a file name to be copied from the source media to the target device, or reference one or more segments defined by information writers, it lists the files to be copied to the target device on the source media. This command is optional, but most segments contain this command.
☆Addreg = add-registry-Section: This command references one or more information writers defined segments, which specify the new subkeys to be written to the Registry, these new keywords may have initial entries. You can also modify the values of existing keywords in these fields. The reference section in the example is as follows:
[Bulkusb. addreg]
Hkr, devloader, * ntkern
Hkr, ntmpdriver, bulkusb. sys
HKLM, "system/CurrentControlSet/services/bulkusb/parameters", "maximumtransfersize", 0x10001,4096
HKLM, "system/CurrentControlSet/services/bulkusb/parameters", "debuglevel", 0x10001,2
HKLM is the root key of the registry. It is short for HKEY_LOCAL_MACHINE. Hkr is related to the Registry keyword, which is most suitable for addreg commands. For example, the "hardware" sub-Key of each device in the Registry :.. /Enum/Enumerator ID/device ID, which is the software sub-key specified by each driver in the corresponding Registry :.. class/class guid/device ID. In addition, there are hkcr, hkcu, HKLM, and HKU.
The Install section of the preceding example is as follows:
[Bulkusb. Dev]
Copyfiles = bulkusb. Files. Ext, bulkusb. Files. inf
Addreg = bulkusb. addreg
[Bulkusb. Dev. nt]
Copyfiles = bulkusb. Files. Ext, bulkusb. Files. inf
Addreg = bulkusb. addreg
The two files to be copied are in the bulkusb. Files. ext and bulkusb. Files. inf segments defined by the INF writer, and the project to be added to the registry is in the bulkusb. addreg segment.
6. Install. Service segment
This section contains one or more addservice commands, which are used to control the time-based and method of service installation of a specific driver, and control the dependencies of this service on other services and the next-level drivers, the definitions in the room are as follows:
Bulkusb. Dev. nt. Services]
Addservice = bulkusb, 0x00000002, bulkusb. addservice
Bulkusb is the name of the service to be installed. For a device, this value is usually the property of the device driver. 0x00000002 is a flag specified by the system. Different tags have different service functions. The last bulkusb. addservice is a specific segment defined by the INF file writer. It includes the service project to be added. Its example is defined as follows:
[Bulkusb. addservice]
Displayname = % bulkusb. svcdesc %
Servicetype = 1; service_kernel_driver
Starttype = 3; service_demand_start
Errorcontrol = 1; service_error_normal
Servicebinary = % 10%/system32/Drivers/bulkusb. sys
Loadordergroup = base
8. [Strings] Section
The [Strings] segment is a string segment. This section defines the strings specified in other segments, and each item in the segment conforms to a string included with the percent sign (%) in other segments. The example is defined as follows:
[Strings]
MSFT = "Microsoft"
Mfgname = "Intel"
USB/vid_045e & pid_930a.devicedesc = "bulkusb. sys intel 82930 USB bulk Io test board"
Bulkusb. svcdesc = "bulkusb. sys i82930 bulk Io test driver"
Geninf software generates the INF file
Windows 2000ddk provides a utility geninf that can generate the INF file. Geninf is a wizard tool for generating INF files. It helps you generate a custom inf file for the Windows 2000 driver. You only need to follow the wizard prompts to fill in the necessary information, he can automatically generate an INF file. However, geninf can only generate but structure INF files, but does not support multi-structure INF files. In addition, geninf may not always generate a completed or fully functional inf file. Therefore, the user ID must be modified as necessary.
After the INF file is generated with geninf, you can also use the chkinf utility provided by Windows 2000 DDK to check whether the structure and syntax of the generated inf file are correct. The chkinf program is a Perl scrip. Therefore, it must be run by the perl interpreter. The detection results are saved in HTML format, including a list of all errors and warnings.