偵探過濾驅動
本文節選自《windows 核心情景分析--採用開源**reactos》一書
至於過濾驅動，則依附於類驅動或埠驅動，目的在於攔截類裝置驅動與埠裝置驅動之間的資訊，以實現某些統計、監視、修改乃至重定向的操作。例如，假定要求對儲存在磁碟上的資訊進行加密，那麼由埠驅動寫入磁碟以及從磁碟讀入的資料就都應該是已加密的，而上面的類驅動卻只能按正常的演算法進行處理，此時就可以在二者之間插入乙個過濾驅動模組，在此模組中實現所有的加密/解密運算。
最底層的模組往往是比較複雜的，因為這種模組通常需要處理中斷，還需要處理dpc函式即「延遲過程請求（delayed procedure call）」。此外，有的底層模組還需要處理dma操作（特別地，處理dma操作的模組常又稱為「介面卡驅動（adapter driver）」）。而中間模組，雖然其處理的演算法和流程也可能是複雜的，卻並沒有中斷處理、dpc、dma這些麻煩。
有必要說明，裝置驅動的堆疊是可以巢狀的。什麼叫巢狀呢？就是一種裝置的埠驅動可以堆疊在另一種裝置的類驅動上面。以usb滑鼠器的驅動為例，自上而下，首先當然是滑鼠器的類驅動，然後是usb滑鼠器的埠驅動。但是這個埠驅動並不直接與硬體介面打交道，因為這種滑鼠器是作為usb裝置出現的，於是在這個埠驅動模組的下面就要放上usb裝置的類驅動，然後是具體usb介面晶元的埠驅動（或小埠驅動）。這樣，就好像是把兩個堆疊又堆疊在一起，這就是所謂巢狀。
讀者也許要問，既然是usb滑鼠器的埠驅動，為什麼就不自己來實現對於usb晶元的驅動呢？那樣當然也是可以的，但是這裡有兩方面的考慮。首先，那樣顯然不符合軟體重用的原則，既然已經有了usb裝置的類驅動和埠驅動，為什麼還要再來實現一遍？再說，即使真要再來實現一遍，也難以保證其正確性。windows的裝置驅動模組並非開源軟體，雖然可以安裝、使用這些模組，卻不知道裡面是如何實現的，所以要自己實現一遍既非易事，更不經濟。其次，即使那確是易事，並且不考慮是否經濟，也還是不合適。這是因為對乙個具體裝置或介面的操作不應「政出多門」，而應該出自同乙個模組的控制，否則就得考慮如何互斥、如何序列化、如何協調的問題。在新開發的模組中或許可以把這些因素和措施考慮進去，可是對於已經存在的模組卻無法再加改變。這樣，勢必就造成要把原來已經存在的模組也丟棄不用，而全都換成自行開發的模組，這當然是不現實的。
鍵盤過濾驅動快捷實現
最近在網上無意中看到一段 主要講述的是windows 下鍵盤過濾驅動的實現方式，這段 很有意識，是一種比較好的一種方法，主要將獲取的鍵盤驅動物件的所有分發函式替換，然後另行處理，具體的 如下 獲取鍵盤驅動物件 status obreferenceobjectbyname unintnamestrin...
驅動筆記15 鍵盤過濾驅動學習筆記
鍵盤過濾驅動對於分層驅動的學習是乙個很好的例子，它相對檔案過濾驅動來說較為簡單，也更容易理解。並不是所有的驅動都需要直接訪問硬體的，事實上幾乎所有的硬體裝置都存在著驅動程式鏈，最底層的驅動程式可以直接訪問硬體，並對上層提供透明服務，最上層的驅動程式只要對接收到的資料進行過濾 格式化等處理即可，這樣大...
檔案過濾驅動的開發 上
當下列情況之一發生時，waitformultipleobjects函式返回 1.乙個或者全部指定的物件在訊號狀態 signaled state 2.到達超時間隔 如下 dword dwwaitstatus handle dwchangehandles 2 監視c windows目錄下的檔案建立和刪除...