[翻譯]Win32中安全的子類化 (2)

Win32中安全的子類化 (1) 

Win32子類化規則

有兩條規則應用到Win32下的執行個體子類化和全域子類化。

子類化僅被允許用在進程內，一個應用程式不能子類化屬於另一個進程的視窗或視窗類別。

這條規則的起因很簡單：Win32進程具有獨立的進程地址空間。在一個特定的進程裡，一個視窗過程有一個地址，而在另一個不同的進程裡，這個地址值並未指向這個視窗過程，結果就是，在一個進程中，使用從另一個進程獲得的地址替換後的地址並不能獲得期望的結果，因此32位的Windows不允許這種地址替換髮生。SetWindowLong和SetClassLong函數中防止了這種類型的子類化發生。你不能子類化屬於另一個進程的視窗或視窗類別，你能做的就到此為止。

不過，也還是有些途徑能讓你把子類化的功能用到每一個進程上。只要能得到位於某個進程地址空間裡的某個函數，你就能該進程裡的任何東西進行子類化。有幾個方法可以達到這個目的，其中最容易（也是最不講理的）的一個方法就是在下面這個註冊表鍵中添加一個動態連結程式庫名稱：
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Windows\APPINIT_DLLS

這個鍵導致Windows把你的DLL附加到系統裡的每一個進程上。你的DLL需要一些能在它要子類化的事件發生時被喚醒的方法，通常一個WH_CBT鉤子可以實現。這個DLL可以監視HCBT_CREATEWND 事件，然後子類化它想子類化的視窗。例子程式CTL3D就使用了WH_CBT鉤子去實現它的子類化，儘管它沒有使用註冊表鍵為每個進程實現子類化，想要得到CTL3D功能的應用程式可以把他連結到進程裡。

另一個把你的子類化代碼附加到每個進程的方法是使用一個系統鉤子。當一個系統鉤子在另一個進程的上下文中被調用時，系統就把包含這個鉤子的DLL載入到這個進程空間中。範例CTL3D 的代碼按照使用當前線程中本地WH_CBT 鉤子的方式使用系統WH_CBT 鉤子。

第三個把子類化代碼附加到另一個進程方法更複雜：它使用OpenProcess， WriteProcessMemory和 CreateRemoteThread 函數將代碼注入其它進程。我並不推薦這個方法，並且不打算更詳細地介紹怎麼實現這個方法。如果有人堅持要使用這個方法， Jeffrey Richter 曾說過他計劃在Microsoft Systems Journal中他的一個即將開闢的Win32 Q&A專欄中描述這項技術。

現在很多Windows 3.1的應用程式子類化其它進程來擴充操作和增加一些很酷的功能。當Windows轉向一個物件導向的系統時，對象連結和嵌入技術(OLE)提供了更好的辦法去實現這些功能。在Windows的未來版本中，子類化其它進程可能會變得更加困難，而使用OLE也許會更容易。我推薦的是，只要可能，你應該讓你的應用程式轉向OLE，而不要子類化其它進程。

子類化操作不要直接使用原視窗過程地址。

在Win16中，一個應用程式會去使用從SetWindowLong或 SetClassLong函數返回的視窗過程地址來直接調用視窗過程，畢竟傳回值只是一個簡單的指向函數的指標，為什麼不使用它呢？在Win32中，這種做法卻是個禁忌。SetWindowLong或 SetClassLong函數的傳回值可能根本不是原視窗過程的指標。Win32可能會返回指向一個資料結構的指標，該資料結構能被用來調用當前的視窗過程。這種情況發生在Windows NT中，當一個應用程式用一個非Unicode的視窗過程子類化一個Unicode視窗時，或者用一個Unicode的視窗過程子類化一個非Unicode視窗時。在這兩種情況下，作業系統必須為視窗收到的訊息執行一個Unicode和ANSI之間的轉換。如果應用程式直接使用指向這個結構的指標調用視窗過程，應用程式會立即導致一個異常。使用SetWindowLong或 SetClassLong函數返回的視窗地址的唯一做法是將傳回值作為參數調用CallWindowProc函數。

Win32中安全的子類化 (3)