DDK中INF文件详解

安装一个驱动程序一个后缀是INF的文本文件控制设备驱动程序自动的安装。

INF格式类似于WIN 下的老式的.INI文件，但是复杂些。

一个INF文件允许自动的或者在对话框的帮助下安装驱动程序文件。

驱动程序安装结束后对系统产生两个持久的影响:1. 描述驱动程序的系统注册表入口，它的加载顺序和任何适当的配置数据。

2. 驱动程序文件被拷贝到适当的系统路径。

INF文件是影响这些改变的标准的机制，它可以提供定制安装。

使用INF文件自动安装INF文件随着硬件和驱动程序一起提供，INF文件的结构和内容是驱动程序作者的责任。

INF文件结构INF文件是被分(section)成几个部分的文本文件，每个部分被指定一个标识符号﹐它被中括号([])括起来﹒一些部分的命名是必须的﹐而其它部分是驱动程序特定的﹒每个部分是一些安装动作﹐或者连接或者列举其它部分﹒文件中各个部分的顺序是不重要的﹐因为每个部分都是被命名和连接的﹒一个部分继续直到另一个部分或者遇到文件结束﹒每个部分的标识符号是独一无二的名字﹐为了保持与WIN98的兼容﹐它的长度被限制在28个字符之内﹐可以包含下划线和圆点字符﹐在引用整个名字的前提下﹐可以包含空格字符﹒文件内容的一般格式如下:entry = value [, value...]entry是指令﹐关键词或者文件名﹐value是entry被应用的属性﹒entry或者value名字可以指定为一个使用百分号(%)的代替一些具体数据的字符串﹐分割INF文件的[Strings]提供一个特殊语言ID的值。

Version 部分一个有效的INF文件从一个命名为[Version]的部分开始，它像一个INF文件的头和标识。

表. [Version]部分的条目Manufacturers部分另一个必须的部分是[Manufacturers]﹐这个部分的条目列出了可以使用这个INF文件安装的设备和驱动程序﹐条目的形式是:manufacturer=modelmanufacturer列出被安装的硬件的制造商的INF文件的唯一名字﹒model提供指向INF文件中另一个进一步安装这个模型的部分的指针﹐Models 部分罗列在[Manufacturers]部分的每一个模型﹐在文件中必须有相应的部分﹐model部分的每个条目的形式是:device-description=install-section-name,hw-id[,compatible-id...]device-description描述了设备模型的列表和一个短描述﹒这个字符串在安装的时候在对话框中提供给用户﹐因此它需要提供多种语言的文本﹒install-section-name的值参考[DDInstall]部分﹐也描述了INF文件的另一个进一步安装的部分﹒hw-id是硬件设备在PnP兼容的总线上声明的时候返回的PnP标识符号﹒例如﹐USB\VID_045E&PID_00B标识微软HID(Human Input Device)的USB键盘设备﹒compatible-id可以是任何表示用于任何的包含在列表中的相同安装脚本的数值﹒DDInstall 部分它的名字独一无二的指定从[Models]部分列出的每个制造商的每个模型﹐AddReg条目在语法上是必须的﹐CopyFiles条目对于[DDInstall]部分是重要的﹐它的形式是:CopyFiles=file-list-section[,file-list-section...] 或者CopyFiles=@filename前者是更普通的版本﹐它允许一个指向另一个包含一个安装文件列表的部分的指针﹒然而对于简单的驱动程序的安装﹐可以直接的使用文件名﹒表. [DDInstall]部分条目CopyFiles部分INF文件的[CopyFiles]部分是唯一的名字并且CopyFiles的指示器在[DDInstall]部分﹐它的条目的形式是: destination-filename[,source-filename,temp-filename,flag]表. CopyFiles flag的定义destination-filename是需要复制的文件名﹐如果与源文件名不同﹐source-filename必须被指定﹐temp-filename在WIN98中是为新文件指定一个中间的文件名直到系统重新激活﹐对于WIN2000来说﹐它是无用的﹒flag值指定新的目标文件的部署﹒这些值可以OR起来使它有多个性质﹒应该确认没有互斥的项目﹒因为[CopyFiles]条目的语法不包含指定源文件的磁盘或者路径选项﹐所以﹐必须使用其它的INF文件的部分[SourceDisksNames]和[SourceDisksFiles]﹒[CopyFiles]是复制的源文件名﹐复制的目标则在[DestinationDirs]部分﹒AddReg部分INF文件的[AddReg]部分是唯一的名字﹐并且引用AddReg的指示器在[DDInstall]部分﹒这个部分的目的是提供在系统注册表中添加或者修改条目﹐形式是﹕reg-root[,subkey,value-name,flags,value]reg-root是注册表根的缩写﹐子键描述根键下的键名﹐使用反斜线字符(\)分开子键﹒例如﹐Software\W2KDriverBook\ Driver\Setting是有效的HKCU或者HKLM根键的子键﹒表. AddReg reg-root缩写的意义value-name指定被添加或者修改注册表值﹒每个系统注册表键包含零个或者多个不同数据类型的值﹒注册表编辑器在右边的窗格列出了子键的值﹒值的名字和值的数据也一起显示出来﹒左边的窗格仅仅显示子键﹒flags指定数据的类型﹒表. AddReg flags定义系统注册表对于驱动程序安装的重要性将在后面讨论﹒SourceDisksNames 部分如果INF文件包含的驱动程序文件分布在多个磁盘上﹐INF文件就必须包含[Source-DisksNames]部分﹐这个部分包含文件分布的每个磁盘的人口﹒diskid=disk-description[,tagfile,unused,path]diskid是唯一的分配设置中的名字﹒通常﹐磁盘号从1开始﹐disk-description是一个提示用户合适的磁盘的字符串﹒tagfile值有双重的作用﹒确定在安装过程中用户提供正确的磁盘﹐tagfile值在安装过程继续进行之前被检验﹐如果tagfile文件不存在﹐用户被重新提示插入正确的磁盘﹒如果agfile 值包含.CAB的扩展名﹐表示磁盘上的驱动程序文件是压缩文件﹒path值是一个以root-relative为磁盘根目录的驱动程序文件的路径﹒像tagfile值一样是可选择的﹒SourceDisksFiles 部分INF文件必须包含一个[SourceDisksFiles]部分﹒这个部分列出了在安装驱动程序过程中使用的文件名﹒每个文件都有相应的条目﹒filename=diskid[,subdir,size]diskid值是一个[SourceDisksNames]部分指定的可以找到文件名的磁盘﹐可选的subdir值指定文件的路径﹒可选的size值指定解压缩文件的字节大小﹐安装过程使用这个数据在尝试复制文件之前决定目标系统是否适合安装﹒DestinationDirs部分这是个必须的提供目标路径的部分﹒file-list-section=dirid[,subdir] 或者DefaultDestDir=dirid[,subdir]file-list-section是一个被[CopyFiles]的指示器唤起的部分﹒它指定所有的被指示器复制的文件安装到指定的路径﹒对于DefaultDestDir﹐用于[CopyFiles]中所有的指示器﹐通常与表. DestinationDirsdirid定义部分为了让复制的文件在目标系统中起驱动程序的作用﹐必须通知服务控制管理器(SCM)﹐在WIN2000中安装的每个驱动程序在注册表的HKLM\System\CurrentControlSet\Services下面﹐ServiceType值是1表示内核模式的驱动程序﹒StartType指出在系统引导过程中在何时加载驱动程序﹒ErrorControl值决定在驱动程序加载的过程中如果遇到错误后如何是好﹒ServiceBinary值指出驱动程序的位置(.SYS文件)﹒但是可能会被遗漏﹐如果二进制文件在%windir%\system32\drivers路径并且与HKLM\...\Services下面的子键名的名字相同的时候就发生这种情况﹒部分条目的形式是﹕AddService=ServiceName,[flags],service-install-section[,eventlog-install-section]ServiceName描述服务的名字﹐典型的是驱动程序的名字(没有.SYS扩展名)表. AddService flags定义service-install部分和可选的eventlog-install部分唤起附加的控制服务值条目的INF部分(例如﹐ServiceType和StartType)﹒ServiceInstall 部分[ServiceInstall]部分﹐它的名字在部分的AddService条目中唯一指定﹐控制和安装驱动程序到服务控制管理器﹒表. ServiceInstall 部分条目INF 例子前面介绍的INF文件好象非常复杂﹐这里使用一个例子说明它﹒在下面的例子中﹐INF控制一个由两个文件组成的驱动程序﹒被复制到系统的驱动程序路径﹐被复制到系统的帮助路径(例如﹐WINNT\System32\Drivers和WINNT\Help)﹒[Version]Signature="$Windows NT$"Class=MissilesClassGUID={C9B3D080-6889-11d4-93FC-0000} Provider=W2KDriverBook DriverVer=07/04/2000,; 注释在分号(;)后面[DestinationDirs] ; 指定文件复制的目的地DefaultDestDir=12 ; %windir%\system32\driversCopyLaunchHelp=18 ; standard help directory[Manufacturer]W2KDriverBook=MyMfgName ; 唤起model部分[MyMfgName] ; 开始一个Models部分"ISA Missile Launcher"=InstallLauncher,ISA\Launcher ; 我们的设备列表[InstallLauncher] ; 开始DDInstall 部分CopyFiles=CopyLaunchFiles ; 唤起CopyFiles 部分.CopyFiles=CopyLaunchHelp ; 另一个是help的AddReg=LaunchRegSection ; 唤起AddReg 部分[CopyLaunchFiles] ; 开始CopyFiles部分[CopyLaunchHelp] ; Help文件的CopyFiles部分[LaunchRegSection] ; 开始AddReg 部分HKR,"Parameters","Coordinates",FLG_ADDREG_TYPE_DWORD,0; 给设备提供一个是0的DWORD值[SourceDisksNames] ; 这个部分不是真的需要﹐1="Missile Launcher Driver Files" ; 因为只有两个文件并且在同一个磁盘上[SourceDisksFiles]=1 ; 类似的﹐因为它们在同一个磁盘上﹐=1 ;所以不是真正的需要这个部分[] ; 部分AddService=Launcher,2,LaunchService[LaunchService] ; 设置SCM﹐这样驱动程序就可以运行了ServiceType=1 ; 驱动程序StartType=3 ; 需要时手动加载ErrorControl=1 ; 汇报错误ServiceBinary=%12%\ ; 驱动程序路径使用INF文件一旦驱动程序的INF创建完成﹐必须处理它﹐使它有用﹒手动安装手动的处理INF文件﹐必须使用Windows的文件管理器选择INF文件﹐右击这个文件﹐选择安装﹒在真正的即插即用环境中﹐插入或者移除设备触发相应的驱动程序的安装﹐加载和卸载﹒因此﹐保留手动的安装是为了最初的测试和调试驱动程序﹒自动安装当一个即插即用的设备被插入到一个系统﹐数个子系统相互作用来加载新的驱动程序﹒1. 当设备被插入﹐硬件使用自动侦测和自动配置﹐告诉总线驱动程序设备出现﹒依赖于总线硬件﹐这可能涉及通知总线驱动程序一个新的总线设备列举发生﹒在这一步的最后﹐驱动程序发现新的设备出现并且有一个指定的设备ID﹒2. 内核模式PnP管理器通知用户模式PnP管理器一个新的有一个指定ID的设备出现在系统中﹒3. 用户模式PnP管理器使用WIN2000的Setup API库为新的设备提供一个类似的驱动程序列表﹒为了合适的驱动程序﹐系统使用新设备的class和model查找系统的INF目录(例如﹐WINNT\INF)﹒4. 如果不能找到合适的INF文件﹐系统不进行进一步的动作直到一个有特权的用户进入系统﹒用户被提供一个新的硬件向导﹒用户提供驱动程序的位置和合适的INF文件位置﹒5. 一旦找到INF文件﹐它被使用CfgMgr API库处理﹒驱动程序文件和注册表条目被安装和修改﹒内核模式的PnP管理器主要执行这个步骤﹒6. 基于INF文件的指导﹐内核模式PnP管理器加载任何低层的滤波驱动程序﹐然后是functional驱动程序﹐最后是高层的驱动程序﹒在堆栈中的高层的驱动程序然后发送适当的PnP信息﹐包括IRP_MN_START_DEVICE.添加/移除硬件向导在安装过程中﹐主要的与用户的交互是添加新硬件向导﹒注意有一个制造商的列表(来自于INF文件的[Manufacturers]部分)﹐和Models列表(来自于INF文件的[Models]部分)﹒通常﹐用户手动选择适当的驱动程序去安装和加载﹒如果驱动程序被安装﹐它的DriverEntry和AddDevice例程必须仍然有效﹐这样使请求驱动的硬件满意新代码的设置﹒换句话说﹐手动的选择可能成功的安装﹐但是初始化是失败的﹒Class名字和设备IDs即插即用设备自动安装的过程很大程度上依赖安装程序的定位合适驱动程序的INF文件和文件中各个部分的能力﹒这个部分文章的目的是解释Class名字和设备Ids﹐还有定位INF 文件的过程﹒每个即插即用设备应该有一个唯一的指定硬件模型的标识符号﹒因此提供设备ID给即插即用总线硬件和总线驱动程序﹒当然﹐总线驱动程序在新的设备被插入后的很短时间内请求设备ID﹒设备ID的形式与总线类型有关﹒但是﹐一般看起来是:<enumerator>\<enumerator-specific-device-ID>(例如﹐PCI\VEN_1000&DEV_0001&SUBSYS_00000000&REV_02)对于驱动程序代码﹐一个硬件设备可能汇报多个设备ID﹐它是设备功能上的与很多models兼容的陈述﹒因为INF文件的[Models]部分包含一个hw-id值﹐所以﹐寻找与新安装的设备返回的设备ID相匹配的INF文件中的条目非常简单﹒同样的INF条目允许相兼容硬件的列表的规范有附加的设备Ids形式﹒如果设备ID不能在INF文件中定位精确的匹配﹐就使用兼容的ID﹒另一个为设备定位合适的驱动程序的关键元素是安装类(Setup Class)的观念﹒一系列相关的设备可以共享分层的驱动程序(例如﹐upper或者lower滤波器)﹐甚至在堆栈中个别的驱动程序﹒安装类被GUID 和name唯一的标识﹒微软定义了一系列驱动程序类﹐新的类可能被定义新的硬件组﹒创建新的组之前﹐必须选择一个新的GUID和class名字﹒表. 安装类: 名字和GUIDs自定义安装驱动程序一般提供两个定制驱动程序安装的信息﹒第一﹐提供一个自定义的安装程序代替新硬件安装程序﹐为了提供这个功能﹐自定义的安装程序需要使用提供的例程﹒这个库中的每个函数的形式是SetupDiXxx﹒DDK提供使用这个库的详细资料﹒第二﹐驱动程序可以提供一个自定义的设置设备的向导页﹒在它的工作要完成之前﹐安装程序发送一个DIF_NEWDEVICEWIZARD_FINISHINSTALL请求来提供给驱动程序一个显示自定义页的机会﹒控制驱动程序的加载顺序有时﹐驱动程序的加载顺序是非常重要的﹒可能一个驱动程序依赖另一个驱动程序初始化完成﹒当有这样的依赖产生﹐服务控制管理器(the Service Control Manager)可以取得系统注册表中条目LoadOrderGroup和Dependencies﹐这些值可以在INF文件中的[ServiceInstall]部分指定﹒LoadOrderGroup是命名一个指定的驱动程序加载顺序组的一个号码﹐Dependencies指定在这个驱动程序加载成功之前必须加载的组﹒这样的相互依赖不是公共的﹐也不应该是公共的﹒在一个真正的以设备为中心的环境(支持即插即用)中﹐驱动程序应该使用尽量少的联系的顺序﹒另一方面﹐分层很多的驱动程序的执行需要这些规范是合理的﹒驱动程序的数字签名WIN2000的CD上附带有很多第三方的驱动程序﹒为了分享这些程序﹐需要几个条件﹒加之﹐无论何时尝试在WIN2000上安装一个驱动程序﹐都会收到一个陈述设备驱动程序没有数字签名并且它的确实性没有被微软检验的警告信息﹒下面介绍微软的检验驱动程序的确实性的作用和驱动程序作者和硬件制造商的保证它们的软件包被包含在未来的WIN2000 CD上的负担﹒微软检验驱动程序的原因微软检验驱动程序有两个目标:1. 通过方便的设备驱动程序的发售提供或者促进WIN2000和更多的硬件设备的协同工作能力﹒2. 确定设备驱动程序是稳定的和没有折中系统的完整性﹒因为设备驱动程序操作在内核模式﹐它们可以慢慢的或者很快的使系统崩溃﹒因为系统的不稳定性常常由内核自己引起﹒这样﹐微软为它的操作系统维持一个被鉴定的制造商和驱动程序的目的是明显的﹒当然﹐WIN2000和大多数的硬件的协同工作能力是一个强有力的买点﹒因此﹐微软常常与硬件制造商一起来确保及时地发布兼容的驱动程序﹒为了完成这两个目标﹐微软有专门的提供硬件和驱动程序证明的团队﹐Windows硬件质量实验室(WHQL)﹒数字签名作为WHQL程序的一部分﹐一个被检验过的驱动程序获得一个允许在WIN2000中安装驱动程序并且不会产生警告的数字签名﹒数字签名由几个部分组成:1. 一个被包含在分布式的驱动程序包的目录文件(.CAT)﹐它包含微软分配的数字签名﹒2. 一个在INF文件中[Versions]部分的涉及.CAT文件的条目﹒3. WIN2000的是或者否允许一个没有数字签名的驱动程序安装的策略﹒数字签名有更改检验﹐这样确保驱动程序被使用供货商提供的原始的代码安装﹒它使用密码技术来完成这个目标﹐这个数字签名没有更改驱动程序代码﹒小结Windows 2000和Windows 98的自动的设备驱动程序的安装对于用户来说是一个巨大的进步﹒然而这个步骤需要驱动程序的作者附加的工作﹐至少﹐必须提供一个INF文件﹒。