由于 C++ 成員函數(shù)的調(diào)用機(jī)制問題，對C語言回調(diào)函數(shù)的 C++ 封裝是件比較棘手的事。為了保持C++對象的獨(dú)立性，理想情況是將回調(diào)函數(shù)設(shè)置到成員函數(shù)，而一般的回調(diào)函數(shù)格式通常是普通的C函數(shù)，尤其是 Windows API 中的。好在有些回調(diào)函數(shù)中留出了一個額外參數(shù)，這樣便可以由這個通道將 this 指針傳入。比如線程函數(shù)的定義為：
typedef DWORD (WINAPI *PTHREAD_START_ROUTINE)(
LPVOID lpThreadParameter
);
typedef PTHREAD_START_ROUTINE LPTHREAD_START_ROUTINE;
這樣，當(dāng)我們實(shí)現(xiàn)線程類的時候，就可以：
class Thread
{
private:
HANDLE m_hThread;
public:
BOOL Create()
{
m_hThread = CreateThread(NULL, 0, StaticThreadProc, (LPVOID)this, 0, NULL);
return m_hThread != NULL;
}
private:
DWORD WINAPI ThreadProc()
{
// TODO
return 0;
}
private:
static DWORD WINAPI StaticThreadProc(LPVOID lpThreadParameter)
{
((Thread *)lpThreadParameter)->ThreadProc();
}
};
不過，這樣，成員函數(shù) ThreadProc() 便喪失了一個參數(shù)，這通常無傷大雅，任何原本需要從參數(shù)傳入的信息都可以作為成員變量讓 ThreadProc 來讀寫。如果一定有些什么是非從參數(shù)傳入不可的，那也可以，一種做法，創(chuàng)建線程的時候傳入一個包含 this 指針信息的結(jié)構(gòu)。第二種做法，對該 class 作單例限制——如果現(xiàn)實(shí)情況允許的話。
所以，有額外參數(shù)的回調(diào)函數(shù)都好處理。不幸的是，Windows 的窗口回調(diào)函數(shù)沒有這樣一個額外參數(shù)：
typedef LRESULT (CALLBACK* WNDPROC)(HWND, UINT, WPARAM, LPARAM);
這使得對窗口的 C++ 封裝變得困難。為了解決這個問題，一個很自然的想法是，維護(hù)一份全局的窗口句柄到窗口類的對應(yīng)關(guān)系，如：
#include <map>
class Window
{
public:
Window();
~Window();
public:
BOOL Create();
protected:
LRESULT WndProc(UINT message, WPARAM wParam, LPARAM lParam);
protected:
HWND m_hWnd;
protected:
static LRESULT CALLBACK StaticWndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam);
static std::map<HWND, Window *> m_sWindows;
};
在 Create 的時候，指定 StaticWndProc 為窗口回調(diào)函數(shù)，并將 hWnd 與 this 存入 m_sWindows：
BOOL Window::Create()
{
LPCTSTR lpszClassName = _T("ClassName");
HINSTANCE hInstance = GetModuleHandle(NULL);
WNDCLASSEX wcex = { sizeof(WNDCLASSEX) };
wcex.lpfnWndProc = StaticWndProc;
wcex.hInstance = hInstance;
wcex.lpszClassName = lpszClassName;
RegisterClassEx(&wcex);
m_hWnd = CreateWindow(lpszClassName, NULL, WS_OVERLAPPEDWINDOW,
CW_USEDEFAULT, 0, CW_USEDEFAULT, 0, NULL, NULL, hInstance, NULL);
if (m_hWnd == NULL)
{
return FALSE;
}
m_sWindows.insert(std::make_pair(m_hWnd, this));
ShowWindow(m_hWnd, SW_SHOW);
UpdateWindow(m_hWnd);
return TRUE;
}
在 StaticWindowProc 中，由 hWnd 找到 this，然后轉(zhuǎn)發(fā)給成員函數(shù)：
LRESULT CALLBACK Window::StaticWndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
{
std::map<HWND, Window *>::iterator it = m_sWindows.find(hWnd);
assert(it != m_sWindows.end() && it->second != NULL);
return it->second->WndProc(message, wParam, lParam);
}
（m_sWindows 的多線程保護(hù)略過，下同）
據(jù)說 MFC 采用的就是類似的做法。缺點(diǎn)是，每次 StaticWndProc 都要從 m_sWindows 中去找 this。由于窗口類一般會保存窗口句柄，回調(diào)函數(shù)里的 hWnd 就沒多大作用了，如果這個 hWnd 能夠被用來存 this 指針就好了，那么就能寫成這樣：
LRESULT CALLBACK Window::StaticWndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
{
return ((Window *)hWnd)->WndProc(message, wParam, lParam);
}
這樣看上去就爽多了。傳說中 WTL 所采取的 thunk 技術(shù)就是這么干的。之前，只是聽過這遙遠(yuǎn)的傳說，今天，終于有機(jī)會走進(jìn)這個傳說去看一看。參考資料是一篇不知原始出處的文章《深入剖析WTL—WTL框架窗口分析》，以及部分 WTL 8.0 代碼，還有其他亂七八糟的文章。
WTL 的思路是，每次在系統(tǒng)調(diào)用 WndProc 的時候，讓它鬼使神差地先走到我們的另一處代碼，讓我們有機(jī)會修改堆棧中的 hWnd。這處代碼可能是類似這樣的：
__asm
{
mov dword ptr [esp+4], pThis ;調(diào)用 WndProc 時，堆棧結(jié)構(gòu)為：RetAddr, hWnd, message, wParam, lParam, ... 故 [esp+4]
jmp WndProc
}
由于 pThis 和 WndProc 需要被事先修改（但又無法在編譯前定好），所以我們需要運(yùn)行的時候去修改這部分代碼。先弄一個小程序探測下這兩行語句的機(jī)器碼：
LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
{
return 0;
}
int APIENTRY _tWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPTSTR lpCmdLine, int nCmdShow)
{
MessageBox(NULL, NULL, NULL, MB_OK);
__asm
{
mov dword ptr [esp+4], 1
jmp WndProc
}
return 0;
}
最前面的 MessageBox 是為了等下調(diào)試的時候容易找到進(jìn)入點(diǎn)。
然后使用 OllyDbg，在 MessageBoxW 上設(shè)置斷點(diǎn)，執(zhí)行到該函數(shù)返回：
這里我們看到，mov dword ptr [esp+4] 的機(jī)器碼為 C7 44 24 04，后面緊接著的一個 DWORD 是 mov 的第二個操作數(shù)。jmp 的機(jī)器碼是 e9，后面緊接著的一個 DWORD 是跳轉(zhuǎn)的相對地址。其中 00061000h - 0006102Bh = FFFFFFD5h。
于是定義這樣一個結(jié)構(gòu)：
#pragma pack(push,1)
typedef struct _StdCallThunk
{
DWORD m_mov; // = 0x042444C7
DWORD m_this; // = this
BYTE m_jmp; // = 0xe9
DWORD m_relproc; // = relative distance
} StdCallThunk;
#pragma pack(pop)
這個結(jié)構(gòu)可以作為窗口類的成員變量存在。我們的窗口類現(xiàn)在變成了這樣子：
class Window
{
public:
Window();
~Window();
public:
BOOL Create();
protected:
LRESULT WndProc(UINT message, WPARAM wParam, LPARAM lParam);
protected:
HWND m_hWnd;
StdCallThunk m_thunk;
protected:
static LRESULT CALLBACK StaticWndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam);
};
似乎少了點(diǎn)什么……創(chuàng)建窗口的時候，我們是不能直接把回調(diào)函數(shù)設(shè)到 StaticWndPorc 中去的，因?yàn)檫@個函數(shù)是希望被寫成這樣子的：
LRESULT CALLBACK Window::StaticWndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
{
return ((Window *)hWnd)->WndProc(message, wParam, lParam);
}
那么至少需要一個臨時的回調(diào)函數(shù)，在這個函數(shù)里去設(shè)置新的回調(diào)函數(shù)（設(shè)到 m_thunk 上），再由 m_thunk 來調(diào)用 StaticWndProc，StaticWndProc 再去調(diào)用 WndProc，這樣整個過程就通了。
但是，臨時回調(diào)函數(shù)還是需要知道從 hWnd 到 this 的對應(yīng)關(guān)系。可是現(xiàn)在我們不能照搬用剛才的 m_sWindows 了。因?yàn)榇翱谠趧?chuàng)建過程中就會調(diào)用到回調(diào)函數(shù)，需要使用到 m_sWindows 里的 this，而窗口被成功創(chuàng)建之前，我們沒法提前拿到 HWND 存入 m_sWindows。現(xiàn)在，換個方法，存當(dāng)前線程 ID 與 this 的對應(yīng)關(guān)系。這樣，這個類變成了：
#include <map>
class Window
{
public:
Window();
~Window();
public:
BOOL Create();
protected:
LRESULT WndProc(UINT message, WPARAM wParam, LPARAM lParam);
protected:
HWND m_hWnd;
StdCallThunk m_thunk;
protected:
static LRESULT CALLBACK TempWndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam);
static LRESULT CALLBACK StaticWndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam);
static std::map<DWORD, Window *> m_sWindows;
}; 然后實(shí)現(xiàn) Create 和 TempWndProc：
BOOL Window::Create()
{
LPCTSTR lpszClassName = _T("ClassName");
HINSTANCE hInstance = GetModuleHandle(NULL);
WNDCLASSEX wcex = { sizeof(WNDCLASSEX) };
wcex.lpfnWndProc = TempWndProc;
wcex.hInstance = hInstance;
wcex.lpszClassName = lpszClassName;
RegisterClassEx(&wcex);
DWORD dwThreadId = GetCurrentThreadId();
m_sWindows.insert(std::make_pair(dwThreadId, this));
m_thunk.m_mov = 0x042444c7;
m_thunk.m_jmp = 0xe9;
m_hWnd = CreateWindow(lpszClassName, NULL, WS_OVERLAPPEDWINDOW,
CW_USEDEFAULT, 0, CW_USEDEFAULT, 0, NULL, NULL, hInstance, NULL);
if (m_hWnd == NULL)
{
return FALSE;
}
ShowWindow(m_hWnd, SW_SHOW);
UpdateWindow(m_hWnd);
return TRUE;
}
LRESULT CALLBACK Window::TempWndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
{
std::map<DWORD, Window *>::iterator it = m_sWindows.find(GetCurrentThreadId());
assert(it != m_sWindows.end() && it->second != NULL);
Window *pThis = it->second;
m_sWindows.erase(it);
WNDPROC pWndProc = (WNDPROC)&pThis->m_thunk;
pThis->m_thunk.m_this = (DWORD)pThis;
pThis->m_thunk.m_relproc = (DWORD)&Window::StaticWndProc - ((DWORD)&pThis->m_thunk + sizeof(StdCallThunk));
m_hWnd = hWnd;
SetWindowLong(hWnd, GWL_WNDPROC, (LONG)pWndProc);
return pWndProc(hWnd, message, wParam, lParam);
}
差不多可以了，調(diào)試一下。結(jié)果，在 thunk 的第一行出錯了。我原以為地址算錯了神馬的，嘗試把 thunk.m_mov 改為 0x90909090，再運(yùn)行，還是出錯。于是傻掉了……過了好一會兒才意識到，可能是因?yàn)?thunk 在數(shù)據(jù)段，無法被執(zhí)行?？墒牵芫煤芫靡郧芭嫉我粋€敬愛的老師在 TC 中鼓搗程序運(yùn)行時改變自身代碼時，貌似無此問題啊。。。然后查呀查，原來是 Windows 在的數(shù)據(jù)執(zhí)行保護(hù)搞的鬼。于是，需要用 VirtualAlloc 來申請一段有執(zhí)行權(quán)限的內(nèi)存。WTL 里面也是這么做的，不過它似乎維護(hù)了一塊較大的可執(zhí)行內(nèi)存區(qū)作為 thunk 內(nèi)存池，我們這里從簡。最后，整個流程終于跑通了。最終代碼清單如下：
#include <Windows.h>
#include <assert.h>
#include <map>
#include <tchar.h>
#pragma pack(push,1)
typedef struct _StdCallThunk
{
DWORD m_mov;
DWORD m_this;
BYTE m_jmp;
DWORD m_relproc;
} StdCallThunk;
#pragma pack(pop)
class Window
{
public:
Window();
~Window();
public:
BOOL Create();
protected:
LRESULT WndProc(UINT message, WPARAM wParam, LPARAM lParam);
protected:
HWND m_hWnd;
StdCallThunk *m_pThunk;
protected:
static LRESULT CALLBACK TempWndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam);
static LRESULT CALLBACK StaticWndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam);
static std::map<DWORD, Window *> m_sWindows;
};
std::map<DWORD, Window *> Window::m_sWindows;
Window::Window()
{
}
Window::~Window()
{
VirtualFree(m_pThunk, sizeof(StdCallThunk), MEM_RELEASE);
}
BOOL Window::Create()
{
LPCTSTR lpszClassName = _T("ClassName");
HINSTANCE hInstance = GetModuleHandle(NULL);
WNDCLASSEX wcex = { sizeof(WNDCLASSEX) };
wcex.lpfnWndProc = TempWndProc;
wcex.hInstance = hInstance;
wcex.lpszClassName = lpszClassName;
wcex.hbrBackground = (HBRUSH)(COLOR_WINDOW + 1);
RegisterClassEx(&wcex);
DWORD dwThreadId = GetCurrentThreadId();
m_sWindows.insert(std::make_pair(dwThreadId, this));
m_pThunk = (StdCallThunk *)VirtualAlloc(NULL, sizeof(StdCallThunk), MEM_RESERVE | MEM_COMMIT, PAGE_EXECUTE_READWRITE);
m_pThunk->m_mov = 0x042444c7;
m_pThunk->m_jmp = 0xe9;
m_hWnd = CreateWindow(lpszClassName, NULL, WS_OVERLAPPEDWINDOW,
CW_USEDEFAULT, 0, CW_USEDEFAULT, 0, NULL, NULL, hInstance, NULL);
if (m_hWnd == NULL)
{
return FALSE;
}
ShowWindow(m_hWnd, SW_SHOW);
UpdateWindow(m_hWnd);
return TRUE;
}
LRESULT Window::WndProc(UINT message, WPARAM wParam, LPARAM lParam)
{
switch (message)
{
case WM_LBUTTONUP:
MessageBox(m_hWnd, _T("LButtonUp"), _T("Message"), MB_OK | MB_ICONINFORMATION);
break;
case WM_RBUTTONUP:
MessageBox(m_hWnd, _T("RButtonUp"), _T("Message"), MB_OK | MB_ICONINFORMATION);
break;
case WM_DESTROY:
PostQuitMessage(0);
break;
default:
break;
}
return DefWindowProc(m_hWnd, message, wParam, lParam);
}
LRESULT CALLBACK Window::TempWndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
{
std::map<DWORD, Window *>::iterator it = m_sWindows.find(GetCurrentThreadId());
assert(it != m_sWindows.end() && it->second != NULL);
Window *pThis = it->second;
m_sWindows.erase(it);
WNDPROC pWndProc = (WNDPROC)pThis->m_pThunk;
pThis->m_pThunk->m_this = (DWORD)pThis;
pThis->m_pThunk->m_relproc = (DWORD)&Window::StaticWndProc - ((DWORD)pThis->m_pThunk + sizeof(StdCallThunk));
pThis->m_hWnd = hWnd;
SetWindowLong(hWnd, GWL_WNDPROC, (LONG)pWndProc);
return pWndProc(hWnd, message, wParam, lParam);
}
LRESULT CALLBACK Window::StaticWndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
{
return ((Window *)hWnd)->WndProc(message, wParam, lParam);
}
int APIENTRY _tWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPTSTR lpCmdLine, int nCmdShow)
{
Window wnd;
wnd.Create();
MSG msg;
while (GetMessage(&msg, NULL, 0, 0))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
return (int)msg.wParam;
}
剛才有一處，存 this 指針的時候，我很武斷地把它與當(dāng)前線程 ID 關(guān)聯(lián)起來了，其實(shí)這正是 WTL 本身的做法。它用 CAtlWinModule::AddCreateWndData 存的 this，最終會把當(dāng)前線程 ID 和 this 作關(guān)聯(lián)。我是這么理解的吧，同一線程不可能同時有兩處在調(diào)用 CreateWindow，所以這樣取回來的 this 是可靠的。
好了，到此為止，邊試驗(yàn)邊記錄的，不知道理解是否正確。歡迎指出不當(dāng)之處，也歡迎提出相關(guān)的問題來考我，歡迎介紹有關(guān)此問題的新方法、新思路，等等，總之，請各位看官多指教哈。
posted on 2010-10-24 16:44
溪流 閱讀(6666)
評論(40) 編輯 收藏 引用 所屬分類:
C++ 、
Windows