Windows NT Driver >> Pascal

DriverEntry()


C/C++程式的進入點是main(),而對於Windows NT Driver而言,它的進入點則是DriverEntry(),如果沒有export DriverEntry(),系統將無法正確載入驅動程式。

DriverEntry()定義如下 :

function _DriverEntry(:PDriverObject; :PUnicodeString):NTSTATUS; stdcall;

系統透過呼叫DriverEntry()載入驅動程式並傳入兩個參數,第一個參數PDriverObject是指向該驅動程式的資料位置,該位置會包含驅動程式的所有資訊,這些資訊並非全部都提供給使用者使用,有些欄位是Undocument的,保留給系統調度使用,Microsoft可能隨系統不同而修改,因此,建議使用者不要使用這些Undocument欄位的資料。而另一個參數PUnicodeString則是該驅動程式的Registry位置,驅動程式在安裝時,系統都會產生一個註冊表項目(位於CurrentControlSet\Services\),該項目就是當Windows系統啟動時,用來載入驅動程式使用的,Windows系統依據註冊表來決定哪些驅動程式需要被載入以及載入的順序,因此,隨意修改註冊表,可能會導致驅動程式無法被正確載入,嚴重時,可能無法啟動系統。

那在DriverEntry()副程式,需要做哪一些事情呢?
1. 設定Callback
2. 產生新的Device Object
3. 配置其它資源

針對產生新的Device Object,除了給與名稱之外,一般還會建造一條Symbolic Link,該Symbolic Link就是提供給User Application開啟(僅能使用CreateFile() API開啟),還記得呼叫CreateFile()時會提供一個名字嗎?若記得的話,此名字就是驅動程式的Symbolic Link名稱。

那問題又來了,有沒有可能其它驅動程式也使用同一個Symbolic Link名字呢?答案是,肯定會發生的,所以Microsoft建議大家使用GUID的方式註冊,使用者可以使用工具產生新的GUID名稱,並使用該GUID註冊裝置,避免名稱衝突,那User Application又該如何開啟該驅動程式呢?這時候就必須使用Setup API做GUID列舉並取得Symbolic Link名稱,哪一種方式比較好呢?如果是使用Symbolic Link註冊名稱,User Application比較好寫,因為名稱已經知道了,反之,使用GUID註冊的話,User Application需要列舉判斷後才能開啟,所以會比較不好寫,但是優點則是名稱不會衝突。

範例:

function _DriverEntry(pOurDriver:PDriverObject; pOurRegistry:PUnicodeString):NTSTATUS; stdcall;
var
  suDevName: TUnicodeString;
  szSymName: TUnicodeString;
  pOurDevice: PDeviceObject;
  
begin
  // Step 1
  pOurDriver^.MajorFunction[IRP_MJ_CREATE]:= @IrpOpen;
  pOurDriver^.MajorFunction[IRP_MJ_READ]  := @IrpRead;
  pOurDriver^.MajorFunction[IRP_MJ_WRITE] := @IrpWrite;
  pOurDriver^.MajorFunction[IRP_MJ_CLOSE] := @IrpClose;
  pOurDriver^.DriverUnload := @Unload;

  // Step 2
  RtlInitUnicodeString(@suDevName, DEV_NAME);
  RtlInitUnicodeString(@szSymName, SYM_NAME);
  IoCreateDevice(pOurDriver, 0, @suDevName, FILE_DEVICE_UNKNOWN, 0, FALSE, pOurDevice);
  IoCreateSymbolicLink(@szSymName, @suDevName);

  // Step 3
  pOurDevice^.Flags:= pOurDevice^.Flags or DO_BUFFERED_IO;
  pOurDevice^.Flags:= pOurDevice^.Flags and not DO_DEVICE_INITIALIZING;
  Result:= STATUS_SUCCESS;
  end;
end;

Step 1:設定相關對應的Callback,這樣I/O Manager才會知道如何呼叫相對應的副程式。
Step 2:產生一個Device Object(可自己決定名稱),然後建立一條Symbolic Link(可自己決定名稱),Device Object名稱一般是放在Windows特殊資料夾中的Device資料夾,使用者可以使用WinObj程式去查看有哪些Device Object,而Symbolic Link的名稱則是放在DosDevices資料夾(GLOBAL??),那應用程式該如何把完整路徑名稱給CreateFile()呢?答案是加上\.\\關鍵字,有印象開啟COM Port時,需要使用這樣CreateFile("\\.\\\\COM1", ...);的方式嗎?這就是代表完整路徑的意思,在寫COM Port程式時,不一定說是要大於COM9才能加\.\\路徑,其實從COM1就可以開始使用,因為那是Global的名稱表示方式。
Step 3:初始化相關旗標,比較需要注意的是DO_BUFFERED_IO旗標,因為在做裝置讀寫時,User Application跟驅動程式是否共用同一塊Buffer是取決於該旗標,如果使用者設定成DO_BUFFERED_IO,則代表驅動程式有自己獨立一塊Buffer,驅動程式讀取完硬體資料後,會複製到它自己的Buffer,然後再複製到User Application的Buffer,所以速度會比較慢一些,如果要共用同一塊Buffer的話,則把旗標設定成DO_DIRECT_IO即可。

P.S. 需要注意DriverEntry()的回傳值部份,因為回傳值會決定載入驅動程式的成功或失敗,另外,除了DriverEntry()名稱必須固定以外,其餘的Callback副程式名稱都可以隨意命名。


返回上一頁