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副程式名稱都可以隨意命名。

返回上一頁