所謂“協作安裝程序”，在ddk文檔里面稱作co-installer，有人將它翻譯成“共同安裝程序”。但是，
從ddk文檔對co-installer功能的描述來看，我個人覺得翻譯成“協作安裝程序”更恰當些。

ddk文檔對co-installer的描述：A co-installer is a Microsoft® Win32® DLL that assists in
device installation. Co-installers are called by Setup API as "helpers" for Class
Installers.簡單地翻譯一下：協作安裝程序是一個Win32 DLL,它輔助設備的安裝。協作安裝程序
由Setup API調用，作為類安裝程序的“助手”。

在本論壇搜索了一下有關“協作安裝程序”的帖子，發現這方面的帖子很少。我想之所以這樣，是因為
大家在驅動開發過程中可能很少有需要用到協作安裝程序的地方?；蛘哒f本來有些地方可以使用，但可能
因為不太了解這方面的東西，所以沒有想到去用它。

這兒，我想介紹一個關于協作安裝程序的應用實例。

開發過USB設備驅動的朋友，不知有沒有碰到過下面的問題：如果你的設備驅動程序沒有經過數字簽名，
那么，在XP系統下，你在每個USB口上第一次插上你的USB設備時，系統都會要求你裝一次驅動程序。
這種感覺是很不好的。我們希望能像大多數USB移動盤一樣，插上設備就自動安裝驅動，然后就可以對
設備進行訪問了。

如何讓我們的USB設備插上后，系統也能自動為它安裝驅動，而不需要煩勞用戶手動安裝呢？解決此問題
的核心技術在于編寫一個類協作安裝程序。

首先，有一個問題大家要清楚，USB設備第一次插到機器上的一個USB口上時，系統要為它
裝一次驅動程序。我們以USB設備為例，來了解一下支持熱插拔的PnP設備的安裝過程：
（1）設備插入系統，USB總線驅動向內核PnP管理器報告有新設備接入系統；
（2）內核PnP管理器向USB總線驅動詢問設備的具體信息，比如PID和VID等；
（3）內核PnP管理器將設備的信息報告給用戶層的PnP管理器，并要求它為新設備安裝驅動；
（4）用戶層PnP管理器調用系統的Setup組件來為設備安裝驅動；
（5）Setup使用設備VID和PID到%Windir%\\inf下尋找適合它的inf文件，并獲得一個可用于設備的驅動程序列表；
（6）Setup在生成驅動程序列表的時候，會檢查inf文件是否經過數字簽名，如果沒有經過數字簽名，
Setup會將此inf文件負責安裝的驅動程序設置成“不可信任的”驅動程序；
（7）Setup對驅動程序列表中的各驅動程序信息進行分析，選擇最匹配設備的驅動程序進行安裝；

這里，有必要提一下“不可信任的驅動程序”這個概念。這個概念在xp之后才有的，2k和98沒有。在Setup
生成的驅動程序列表中，每個驅動程序的信息結構中都有一個Rank字段。在xp中，0x0 < Rank <= 0x3FFF的
驅動程序被認為是“可信任的”；0x8000 <= Rank <= 0xFFFF的驅動被認為是“不可信任的”。如果我們的
驅動程序沒有經過數字簽名，那么它的Rank值肯定落在0x8000到0xFFFF之間。

再回到前面的安裝過程，如果驅動程序中有適合設備的“可信任”驅動程序，那么系統自動對它進行安裝；
如果驅動程序列表中的所有驅動程序都是“不可信任的”，那么系統就會彈出“發現新硬件”向導，要你提
供更好的驅動程序，或者要你確認安裝“不可信任的”驅動程序。這就是為什么在xp系統下，即便你在一個
USB口上已經安裝了設備的驅動程序，你再換個口插上設備，系統又會提示你安裝驅動程序的原因。

說了半天，我想現在各位肯定都明白過來了：影響設備驅動程序自動安裝的主要原因，是因為我們的
驅動程序被系統認為是“不可信任的”。而系統判斷一個驅動程序是否“可信任”，是通過驅動程序信息結
構中的Rank字段的值來判斷的。那么，如果我們能把我們的驅動程序信息中的Rank值修改到“可信任”空間，
那么系統是否就會信任我們的驅動程序，而自動對它進行安裝呢？答案是，有可能。我不敢說肯定可以，原因
后面會提到。但是，如何修改驅動程序信息的Rank值呢？這就要用到“協作安裝程序”。

我們知道，在設備的安裝過程中，Setup要向設備類安裝程序、類協作安裝程序和設備協作安裝程序發送
“設備安裝功能碼”（如果有這些安裝程序的話）。ddk文檔中又說，類安裝程序和類協作安裝程序可以對
DIF_SELECTBESTCOMPATDRV請求進行處理（設備協作安裝程序不可以）。在對DIF_SELECTBESTCOMPATDRV進行處理
的時候，類安裝程序和類協作安裝程序可以修改驅動程序列表中各驅動程序的信息。答案越來越清晰了，我們
只要寫一個類協作安裝程序，對DIF_SELECTBESTCOMPATDRV進行處理，修改我們想要安裝的驅動程序的Rank值，
那么就可能騙過系統，使系統相信我們的驅動程序，并完成自動安裝。關于編寫協作安裝程序的具體要求和方法，
可以參考ddk文檔中的“Writing a Co-installer（編寫協作安裝程序）”和ddk\src\general\toaster\coinstaller。

接下來，我們來了解一下，在類協作安裝程序處理DIF_SELECTBESTCOMPATDRV時，應該做哪些事情。
（1）首先，調用SetupDiEnumDriverInfo遍歷驅動程序列表，獲得每個驅動程序的信息――一個
SP_DRVINFO_DATA結構。
（2）接著，用（1）中獲得的SP_DRVINFO_DATA作為輸入參數，調用SetupDiGetDriverInstallParams，
獲得驅動程序安裝參數――一個SP_DRVINSTALL_PARAMS結構，其中我們想要修改的Rank赫然在列。你可以按
照自己的需要修改Rank的值，在這兒我們肯定是要把它改為0了（0表示驅動程序與設備最匹配）。
（3）最后，把修改后的SP_DRVINSTALL_PARAMS結構作為輸入，調用SetupDiSetDriverInstallParams將我們修改
的值設置生效。
在類協作安裝程序中只需作如此處理，便可以使Setup此后信任我們的驅動程序，從而達到我們想瞞天過海的目的。

再稍微提一下類協作安裝程序的注冊。協作安裝程序做好了，如何使它參與到設備安裝的過程中來呢？我們
必須注冊它。ddk文檔對此講得非常清楚了，參看“Registering a Class Co-installer”，我就不在這兒把它翻譯出來了。

最后，要提醒一點：必須為我們的usb設備定義一個新的設備setup類，然后將我們的協作安裝程序注冊為這個
setup類的類協作安裝程序。如果我們讓設備仍然屬于usb setup類，并將我們的類協作安裝程序注冊為usb
setup類的一個協作安裝程序，那么在安裝過程中，Setup仍然彈出一些窗體影響我們設備的自動安裝，似乎我們的小聰明
并沒能瞞過它。這就是前面我說修改Rank值為“可信任”只是有可能瞞過系統而不是肯定能夠瞞過系統的原因。為什么會出現
這種情況呢？從現象看，我感覺是usb setup類的類安裝程序仍然發現我們的驅動程序是不可信任的。但是，Setup是以類協作
安裝程序、設備協作安裝程序和類安裝程序的順序調用它們的，在Setup調用usb setup類安裝程序之前，我們已經修改了驅動程序的
Rank值。按理說，它應該不會發現驅動程序是不可信任的。這是一個問題，具體原因我還沒有弄明白，希望有知其所以然者，能給
點提示！不管如何，通過實驗我發現，只要我們定義了新的setup類，那么我們就可以騙過系統Setup組件，使其自動為我們的設備
安裝驅動程序。

就寫這些，有興趣的朋友可以試一下！我不想把具體的實現過程一步一步地寫出來，更不愿提供具體的實現代碼。
因為我認為只要把原理和方法講清楚了（但愿我講得還算清楚），每個人都可以在此基礎上做自己的事情。

不管各位朋友看完之后感覺如何，能夸就夸夸，該罵就罵罵，都頂一下！