C++ 通过Thunk在WNDPROC中访问this指针实现细节

本文代码使用了一些C++11特性，需要编译器支持。本文仅讨论x86_64平台的相关实现，x86平台理论上只需修改 thunk 相关机器码即可。

THUNK的原理参见之前的一篇博文《C++ 通过Thunk在WNDPROC中访问this指针》

首先定义我们的window类，该类实现对一个Win32窗口句柄的封装。

该类将在构造函数中创建窗口，在析构时销毁窗口；

窗口的消息过程函数(WindowProc)将是一个用机器码在内存中动态构造的thunk，其作用是把收到的4个参数中的第一个也就是窗口句柄替换成window类的this指针，然后把调用传递给window类的静态函数static_procedure；

静态成员函数static_procedure的signature与WNDPROC相似，同为stdcall调用约定，四个参数中仅第一个参数由HWND类型改为了window类指针，该函数的目的省去在thunk中处理虚函数调用，因此它仅简单把调用传递给window类的非静态成员函数procedure；

非静态成员函数procedure是一个protected的虚函数，真正负责消息处理且可以override；

此外由于窗口消息过程函数是在注册Win32窗口类时提供而不是创建窗口时提供，此时window类实例可能尚未构造，因此这是thunk还无法构建，这就需要使用一个临时的WindowProc来进行过度，并负责在收到第一个消息时通过SetWindowLongPtr将窗口过程设置为thunk，这个函数就是first_message_procedure，一个stdcall的静态函数，符合WNDPROC的signature要求；

此外还需要一个单例对象来负责Win32窗口类的注册与消息，该对象的类型及实现稍后考虑，现在仅确定其提供一个name函数来返回Win32窗口类的名字。

class window {
public:
    window();
    virtual ~window() noexcept;
    window(const window& other) = delete;
    window(window&& other);
protected:
    HWND handle() {
        return _handle;
    }
    virtual LRESULT procedure(UINT msg, WPARAM wParam, LPARAM lParam);
private:
    static LRESULT CALLBACK static_procedure(window* thiz, UINT msg,
            WPARAM wParam, LPARAM lParam);
    static LRESULT CALLBACK first_message_procedure(HWND window, UINT msg,
            WPARAM wParam, LPARAM lParam);
private:
    HWND _handle;
    void* _thunk;
private:
    static class window_class _class;
};

首先来看看window类的构造函数的实现。首先我们要使用当前的this指针和static_procedure函数指针来构造一个thunk，然后我们调用Win32 API的CreateWindow/CreateWindowEx函数来创建窗口。在窗口创建过程中，注册Win32窗口类时指定的first_message_procedure将会至少收到1次消息（实际上WM_NCCREATE, WM_CREATE两个消息是一定会出现的，此外还有WM_GETMINMAXINFO），此时CreateWindow/CreateWindowEx尚未返回。 在first_message_procedure中，把收到的HWND句柄存入window类实例中，并调用SetWindowLongPtr来将当前窗口的WindowProc设置为前边构建的thunk的指针。最后当然是返回对procedure成员函数的调用了。也就是说包括第一个窗口消息在内，所有的窗口消息实质上都是由procedure函数处理的。

说到这里，有一个棘手的问题 -- 如何将window类实例指针或引用传递给静态函数 first_message_procedure ？ 鉴于 win32 API 实在是残废，说好了WM_NCCREATE消息是第一个消息，但却很没节操的在前边插一个WM_GETMINMAXINFO消息，而WM_GETMINMAXINFO中又没有那个CREATESTRUCT结构。 当然可以选择忽略WM_NCCREATE消息之前的所有消息，但那一定是万般无奈之后的决定。而这里还有另一条更完美的小路可走：线程本地变量(thread local variable)。因为在 first_message_procedure 收到最初的几个消息并返回之前，CreateWindow/CreateWindowEx不会返回，也就是说我们基本可以断定对first_message_procedure 的调用永远发生在调用CreateWindow/CreateWindowEx的线程上，也就是说通过一个线程本地变量，可以方便的把任何数据传递给first_message_procedure。

thread_local window* _window_creatting = nullptr;

window::window() : _handle(0), _thunk(nullptr) {
    // g_thunk_manager 是一个全局变量，用来管理所有thunk
    _thunk = g_thunk_manager.alloc_thunk(this, static_procedure);

    _window_creatting = this;
    CreateWindowExW(WS_EX_OVERLAPPEDWINDOW, _class.name(), nullptr, WS_TILEDWINDOW, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, 0, 0, get_executable_module(), nullptr);
    _window_creatting = nullptr;

    ShowWindow(_handle, SW_SHOW);
}

LRESULT CALLBACK window::first_message_procedure(HWND handle, UINT msg, WPARAM wParam, LPARAM lParam) {

    window* w = _window_creatting;
    w->_handle = handle;
    SetWindowLongPtrW(handle, GWLP_WNDPROC, (LONG_PTR) w->_thunk);
    return w->procedure(msg, wParam, lParam);
    return 0;
}

LRESULT CALLBACK window::procedure(UINT msg, WPARAM wParam, LPARAM lParam) {
    return DefWindowProcW(_handle, msg, wParam, lParam);
}
LRESULT CALLBACK window::static_procedure(window* thiz, UINT msg, WPARAM wParam, LPARAM lParam) {
    return thiz->procedure(msg, wParam, lParam);
}

首先说上边提到的window_class类比较简单，该类的构造函数接受两个参数，一个是win32窗口类的名字，一个是默认的窗口过程(WindowProc)，（这里一切从简，理论上应该多传些参数进去，比如窗口图标、背景刷子等），在构造函数中通过Win32 API注册这个窗口类，并在析构时注消。该类的实现细节不作过多讨论，仅仅是调用RegisterClass/RegisterClassEx和UnRegisterClass函数而已。以下是类的原型

class window_class {
public:
    window_class(const std::wstring class_name, WNDPROC wndproc);
    ~window_class();
    LPCWSTR name() const {
        return (LPCWSTR) (intptr_t) _atom;
    }
private:
    ATOM _atom;
};

下边就是重点了thunk构建了。 这里使用一个thunk_manager的类来负责管理thunk的构建与释放。由于DEP（数据执行保护）的问题，无法使用默认的栈内存或堆内存来构建thunk，这些内存是不可执行的。这里需要通过Win32 API中的VirtualAllocEx/VirtualAlloc和VirtualFree/VirtualFreeEx来向系统申请或返还可执行内存。为简单起见，我们预估一下程序需要同时使用的thunk的数量，一次性向系统申请足够的内存，免去内存管理的麻烦。比如我们一次性申请4M内存来（对于现在的机器，4M一般也不算什么大内存），每个thunk大概占用32个字节，也就是足够13万多个thunk，一般应用场合足矣。这里使用一个virtual_memory类来专门管理VirtualAllocEx/VirtualAlloc和VirtualFree/VirtualFreeEx，在构造时调用 VirtualAllocEx/VirtualAlloc 申请内存，在析构时调用VirtualFree/VirtualFreeEx释放内存。而 thunk_manager 专门负责在这些内存中为正在构造的窗口找到一块空闲之地，并把构造机器码填入这块内存；在窗口销毁后，把其使用过的thunk内存重新标记为空闲供后续窗口重复使用。需要留心的是thunk_manager需要线程安全。

struct thunk_code_type {
    uint8_t mov_rax_1[2];             // mov &window_instance to rax
    uint8_t object[sizeof(window*)];
    uint8_t mov_rax_to_rcx[3];        // mov rax to rcx
    uint8_t mov_rax_2[2];             // mov &first_message_procedure to rax
    uint8_t procedure[sizeof(window_procedure_type)];
    uint8_t jump_rax[3];              // jmp to [rax]
#ifdef _WIN64
    thunk_code_type(const window*w, window_procedure_type proc) :
            mov_rax_1 { 0x48, 0xb8 }, object { 0 }, //
            mov_rax_to_rcx { 0x48, 0x89, 0xc1 }, mov_rax_2 { 0x48, 0xb8 }, //
            procedure { 0 }, jump_rax { 0x48, 0xff, 0xe0 } {
        *reinterpret_cast<const window**>(&object) = w;
        *reinterpret_cast<window_procedure_type*>(procedure) = proc;
    }
#else
#error Only x86_64 is supported now.
#endif
    ~thunk_code_type() {
    }
};

struct thunk_type{
    thunk_code_type code;
    volatile long flag;
};

thunk_manager::thunk_manager(size_t max_count) :
        _memory(sizeof(thunk_type) * max_count, true), _max_count(max_count) {
}
thunk_manager::~thunk_manager() {
}
void* thunk_manager::alloc_thunk(const window* w, window_procedure_type proc) {
    thunk_type* memory = reinterpret_cast<thunk_type*>(_memory.get());
    thunk_type* end = memory + _max_count;
    for (thunk_type * p = memory; p < end; p++) {
        auto ret = InterlockedBitTestAndSet(&p->flag, 0);
        if (!ret) {
            new (&p->code) thunk_code_type(w, proc);
            return p;
        }
    }
    throw std::bad_alloc();
}
void thunk_manager::free_thunk(void* thunk) {
    thunk_type* p = reinterpret_cast<thunk_type*>(thunk);
    InterlockedBitTestAndReset(&p->flag, 0);
}

文中所有代码兼容 gcc 4.8.2 ( mingw64) with posix threading model，启用 -std=c++11 选项；其它编译器未测试。