知了博客

今天，分析MFC与WTL的消息映射，比较难理解的有下面两点：
1.MFC,AfxCbtFilterHook转到AfxWndProc,
2.WTL(ATL),CWndProcThunk把窗口指针跳转到WindowProc,并把hWnd改成窗口指针.
补充阅读资料：

ATL Windowing中的汇编：_stdcallthunk分析
from:http://songminart.spaces.live.com/blog/cns!18F1A4E47724A2D!178.entry

1. 指令指针寄存器与正在执行指令指针关系：
I: CPU正在执行指令；
xIP: CPU指令指针寄存器内容；
xIP(I): CPU正在执行的指令I的指针；
LEN(I): 指令I的长度。
1）顺序执行：xIP = xIP(I) + LEN(I);
2）相对跳转：xIP = xIP(I) + LEN(I) + REL_DISPLACEMENT_CONST;
3）绝对跳转：xIP = Target_CONST;
2. ATL:: _stdcallthunk 代码片断（节选自atlstdthunk.h）
struct _stdcallthunk
{
DWORD m_mov; // mov dword ptr [esp+0x4], pThis (esp+0x4 is hWnd)
DWORD m_this; //
BYTE m_jmp; // jmp WndProc
DWORD m_relproc; // relative jmp
BOOL Init(DWORD_PTR proc, void* pThis)
{
m_mov = 0x042444C7; //C7 44 24 0C
m_this = PtrToUlong(pThis);
m_jmp = 0xe9;
m_relproc = DWORD((INT_PTR)proc - ((INT_PTR)this+sizeof(_stdcallthunk)));
// write block from data cache and
// flush from instruction cache
FlushInstructionCache(GetCurrentProcess(), this, sizeof(_stdcallthunk));
return TRUE;
}
//some thunks will dynamically allocate the memory for the code
void* GetCodeAddress()
{
return this;
}
// code ignored ……
};
3. 数据作为代码运行
实际使用时，_stdcallthunk结构作为代码使用。经过Init（）后，被解释为以下两条指令(X86机器)：
Mov dword ptr[esp+4], pThis_CONST;
Jmp REL_DISPLACEMENT_CONST;
其中 pThis_CONST是CWindowXXX的指针；
REL_DISPLACEMENT_CONST是跳转到实际WndProc的相对偏移量。那为什么 REL_DISPLACEMENT_CONST是 “_relproc = DWORD((INT_PTR)proc - ((INT_PTR)this+sizeof(_stdcallthunk))); ”呢？稍候解释。
下面是一个可能的伪码例子：
WNDPROC pWndProc = (WNDPROC)( _stdcallthunkOBJ. GetCodeAddress() );
SetWindowLongPtr( hwnd, GWLP_WNDPROC, pWndProc);
4. 两条指令的解释
当WndProc被调用时，程序堆栈如下：(地址约定：高地址在上，低地址在下)
LPARAM
WPARAM
UINT
HWND ß esp+4
RetAddr( from WNdProc) ß esp
所以当第一条指令Mov dword ptr[esp+4], pThis_CONST 执行后，程序堆栈如下：
LPARAM
WPARAM
UINT
pThis_CONST ß esp+4
RetAddr( from WNdProc) ß esp
当第二条指令Jmp REL_DISPLACEMENT_CONST 执行时，xIP和xIP（I）的关系如下(重复地址约定：高地址在上，低地址在下)：
Others …. ß_stdcallthunk结构的基址+_stdcallthunk结构大小
Jmp ….. (第二条指令) ß xIP（I）
Mov ….. (第一条指令) ß_stdcallthunk结构的基址
由于xIP = xIP(I) + LEN(I) + REL_DISPLACEMENT_CONST;
显然 xIP(I) + LEN(I) = _stdcallthunk结构的基址+_stdcallthunk结构大小；
又因为 REL_DISPLACEMENT_CONST = _relproc = DWORD((INT_PTR)proc - (_stdcallthunk结构的基址+_stdcallthunk结构大小)；
所以 xIP = xIP(I) + LEN(I) + REL_DISPLACEMENT_CONST = （_stdcallthunk结构的基址+_stdcallthunk结构大小）+ （DWORD((INT_PTR)proc - (_stdcallthunk结构的基址+_stdcallthunk结构大小)）
= proc；
既下一条将要执行的指令是实际WndProc的首条指令。
如果使用绝对寻址，要好理解的多，可能是基于性能考虑，使用相对寻址。X64使用寄存器绝对寻址（rcx rax），好理解一些，但显然须符合调用约定。
5.总结
1) 数据被解释为代码；
2) 相对跳转正好跳到实际WndProc。


EB JMP 相对地址跳转
from: http://hi.baidu.com/xiamisun/blog/item/758584efa0a224f0b2fb958b.html
我们经常在inline hook中看到类似下面的一些代码：
BYTE JmpAddress[5]={0xE9,0,0,0,0}; //跳转到HOOK函数的地址
*(ULONG*)(JmpAddress +1) = (ULONG)MyMessageBox -((ULONG)MessageBox +5);
0xE9 在汇编中是JMP指令,但是JMP绝非只是这一个操作码,下面是JMP可能的一些操作码：
操作码 伪码指令 含义
EB 　cb JMP rel8 相对短跳转（8位），使rel8处的代码位下一条指令
E9 　cw JMP rel16 相对跳转（16位），使rel16处的代码位下一条指令
FF 　/4 JMP r/m16 绝对跳转（16位），下一指令地址在r/m16中给出
FF 　/4 JMP r/m32 绝对跳转（32位），下一指令地址在r/m32中给出
EA 　cb JMP ptr16:16 远距离绝对跳转， 下一指令地址在操作数中
EA 　cb JMP ptr16:32 远距离绝对跳转， 下一指令地址在操作数中
FF 　/5 JMP m16:16 远距离绝对跳转， 下一指令地址在内存m16:16中
FF　 /5 JMP m16:32 远距离绝对跳转， 下一指令地址在内存m16:32中
所以上面代码中的E9 表示这个JMP是个相对地址跳转,所以我们用HOOK后的(ULONG)MyMessageBox减去HOOK后的((ULONG)MessageBox +5)就得到了它们之间的偏移了 。而这里+5是因为相对地址跳转并不是相对当前代码的偏移而是下一条指令的代码。


ATL Under the Hood Part 5
from:http://www.codeproject.com/kb/atl/atl_underthehood_5.aspx
#include <iostream> #include <windows.h> using namespace std; class C; C* g_pC = NULL; typedef void(*pFUN)(); #pragma pack(push,1) // structure to store the machine code struct Thunk {     BYTE    m_jmp;          // op code of jmp instruction     DWORD   m_relproc;      // relative jmp }; #pragma pack(pop) class C { public:     Thunk    m_thunk;     void Init(pFUN pFun, void* pThis)     {         // op code of jump instruction         m_thunk.m_jmp = 0xe9;         // address of the appripriate function         m_thunk.m_relproc = (int)pFun - ((int)this+sizeof(Thunk));         FlushInstructionCache(GetCurrentProcess(),                                  &m_thunk, sizeof(m_thunk));     }     // this is cour call back function     static void CallBackFun()     {         C* pC = g_pC;         // initilize the thunk         pC->Init(StaticFun, pC);         // get the address of thunk code         pFUN pFun = (pFUN)&(pC->m_thunk);         // start executing thunk code which will call StaticFun         pFun();         cout << "C::CallBackFun" << endl;     }     static void StaticFun()     {         cout << "C::StaticFun" << endl;     } }; int main() {     C objC;     g_pC = &objC;     C::CallBackFun();     return 0; }
深入剖析WTL—WTL框架窗口分析
from:http://industry.ccidnet.com/art/1081/20021111/30384_5.html

ATL对窗口消息处理函数的封装 ,ATL解决这个问题的方法很巧妙。该方法并不存储这些对应关系，而是使窗口函数接收C++类指针作为参数来替代HWND作为参数。
具体步骤如下：
· 在注册窗口类时，指定一个起始窗口函数。
· 创建窗口类时，将this指针暂时保存在某处。
· Windows在创建该类的窗口时会调用起始窗口函数。它的作用是创建一系列二进制代码（thunk）。这些代码用this指针的物理地址来取代窗口函数的HWND参数，然后跳转到实际的窗口函数中。这是通过改变栈来实现的。
· 然后，用这些代码作为该窗口的窗口函数。这样，每次调用窗口函数时都对参数进行转换。
· 在实际的窗口函数中，只需要将该参数cast为窗口类指针类型。
详细看看ATL的封装代码。
1. 注册窗口类时，指定一个起始窗口函数。
在superclass中，我们分析到窗口注册时，指定的窗口函数是StartWindowProc()。
2. 创建窗口类时，将this指针暂时保存在某处。
3. 一段奇妙的二进制代码
下面我们来看一下一段关键的二进制代码。它的作用是将传递给实际窗口函数的HWND参数用类的实例指针来代替。
ATL定义了一个结构来代表这段代码：
#pragma pack(push,1)
struct _WndProcThunk
{
DWORD m_mov; // mov dword ptr [esp+0x4], pThis (esp+0x4 is hWnd)
DWORD m_this; //
BYTE m_jmp; // jmp WndProc
DWORD m_relproc; // relative jmp
};
#pragma pack(pop)
#pragma pack(push,1)的意思是告诉编译器，该结构在内存中每个字段都紧紧挨着。因为它存放的是机器指令。
这段代码包含两条机器指令：
mov dword ptr [esp+4], pThis
jmp WndProc
MOV指令将堆栈中的HWND参数（esp+0x4）变成类的实例指针pThis。JMP指令完成一个相对跳转到实际的窗口函数WndProc的任务。注意，此时堆栈中的HWND参数已经变成了pThis，也就是说，WinProc得到的HWND参数实际上是pThis。
MFC中消息映射机制分析
from:http://www.lunwenwang.com/Freepaper/Technicalpaper/information/200608/Freepaper_3385.html
摘 要：MFC以层次结构组织起来，比较庞杂，尤其是它的消息映射机制，更是涉及到很多底层的东西。本文通过对整个消息映射机制进行系统的分析，可以帮助程序开发人员更好地了解MFC，进行可视化编程。

关键词：消息驱动；消息映射；MFC 程序设计

1 引言
微软公司提供的MFC基本类库(Microsoft Foundation Classes)，是进行可视化编程时使用最为流行的一个类库。MFC封装了大部分Windows API函数和Windows控件，使得程序的开发变得简单，极大的缩短了程序的开发周期。MFC独创的Document/View框架结构，能够将管理数据的代码和显示数据的程序代码分开，并且设计了一套方便的消息映射和命令传递机制，方便程序员的开发使用。其中消息映射机制本身比较庞大和复杂，对它的分析和了解无疑有助于我们写出更为合理的高效的程序。这里我们分析一下MFC的消息映射机制，以了解MFC是如何对Windows的消息加以封装，方便用户的开发。
2 SDK下的消息机制实现
首先，简单回顾一下SDK下我们是如何进行Windows的程序开发的。Windows程序的运行是依靠外部发生的事件来驱动的，事件由操作系统捕捉，以消息的形式进入消息队列，然后通过消息循环从队列中不断取出消息，送到对应的窗口过程里处理。相对于DOS程序，Windows是以WinMain作为程序的入口点，以下就是一个简化的Win32程序的主体，通过while语句实现消息循环:
WinMain(…)
{
MSG msg;
RegisterClass(…); // 注册窗口类
CreateWindow(…); // 创建窗口
ShowWindow(…); // 显示窗口
UpdateWindow(…);
While(GetMessage(&msg,…)){ // 消息循环
TranslateMessage(…);
DispatchMessage(…);
}
return msg.wParam;
}
其中，msg代表消息，程序是通过GetMessage函数从和某个线程相对应的消息队列里面把消息取出来并放到消息变量msg里面。然后TranslateMessage函数用来把键盘消息转化并放到响应的消息队列里面，最后DispatchMessage函数把消息分发到相关的窗口过程去处理。窗口过程根据消息的类型对不同的消息进行相关的处理。在SDK编程过程中，用户需要在窗口过程中分析消息的类型及其参数的含义，然后做不同的处理，相对比较麻烦；而MFC把消息调用的过程给封装起来，使用户能够通过ClassWizard方便的使用和处理Windows的各种消息。
3 MFC中的消息映射机制
在MFC的框架结构下，“消息映射”是通过巧妙的宏定义，形成一张消息映射表格来进行的。这样一旦消息发生，Framework就可以根据消息映射表格来进行消息映射和命令传递。
首先在需要进行消息处理的类的头文件（.H）里，都会含有DECLARE_MESSAGE_MAP()宏,声明该类拥有消息映射表格：
class CscribbleDoc:public Cdocument
{
…
DECLARE_MESSAGE_MAP()
};
然后在类应用程序文件（.CPP）实现这一表格
BEGIN_MESSAGE_MAP(CInheritClass, CBaseClass)
//{{AFX_MSG_MAP(CInheritClass)
ON_COMMAND(ID_EDIT_COPY,OnEditCopy)
………
//}}AFX_MSG_MAP
END_MESSAGE_MAP()
---- 这里主要进行消息映射的实现，把它和消息处理函数联系在一起。其中出现三个宏，第一个宏是BEGIN_MESSAGE_MAP有两个参数，分别是拥有消息表格的类，及其父类。第二个宏是ON_COMMAND，指定命令消息的处理函数名称。第三个宏是END_MESSAGE_MAP()作为结尾符号。中间的奇怪符号//}}和//{{，是ClassWizard产生的，对程序无影响。
观察DECLARE_MESSAGE_MAP的定义：
#define DECLARE_MESSAGE_MAP () \
private: \
static const AFX_MESSAGE_ENTRY _messageEntries[]; \
protected: \
static AFX_DATA const AFX_MSGMAP messageMap; \
virtual const AFX_MSGMAP* GetMessageMap() const; \
里面又包含了MFC新定义的两个数据结构，如下：
AFX_MSGMAP_ENTRY
struct AFX_MSGMAP_ENTRY
{
UINT nMessage; // windows message
UINT nCode; // control code or WM_NOTIFY code
UINT nID; // control ID (or 0 for windows messages)
UINT nLastID; // used for entries specifying a range of control id's
UINT nSig; // signature type (action) or pointer to message #
AFX_PMSG pfn; // routine to call (or special value)
};
和AFX_MSGMAP
struct AFX_MSGMAP
{
const AFX_MSGMAP* pBaseMap;
const AFX_MSGMAP_ENTRY* lpEntries;
};
其中AFX_MSGMAP_ENTRY结构包含了一个消息的所有相关信息,而AFX_MSGMAP主要作用有两个，一是用来得到基类的消息映射入口地址。二是得到本身的消息映射入口地址。

实际上，MFC把所有的消息一条条填入到AFX_MSGMAP_ENTRY结构中去，形成一个数
组，该数组存放了所有的消息和与它们相关的参数。同时通过AFX_MSGMAP能得到该数组的首地址，同时得到基类的消息映射入口地址。当本身对该消息不响应的时候，就可以上溯到基类的消息映射表寻找对应的消息响应。
现在我们来分析MFC是如何让窗口过程来处理消息的，实际上所有MFC的窗口类都通过钩子函数_AfxCbtFilterHook截获消息，并且在钩子函数_AfxCbtFilterHook中把窗口过程设定为AfxWndProc。原来的窗口过程保存在成员变量m_pfnSuper中。
在MFC框架下，一般一个消息的处理过程是这样的。
(1)函数AfxWndProc接收Windows操作系统发送的消息。
(2)函数AfxWndProc调用函数AfxCallWndProc进行消息处理，这里一个进步是把对句柄的操作转换成对CWnd对象的操作。
(3)函数AfxCallWndProc调用CWnd类的方法WindowProc进行消息处理。
(4)WindowProc调用OnWndMsg进行正式的消息处理，即把消息派送到相关的方法中去处理。在CWnd类中都保存了一个AFX_MSGMAP的结构，而在AFX_MSGMAP结构中保存有所有我们用ClassWizard生成的消息的数组的入口，我们把传给OnWndMsg的message和数组中的所有的message进行比较，找到匹配的那一个消息。实际上系统是通过函数AfxFindMessageEntry来实现的。找到了那个message，实际上我们就得到一个AFX_MSGMAP_ENTRY结构，而我们在上面已经提到AFX_MSGMAP_ENTRY保存了和该消息相关的所有信息，其中主要是消息的动作标识和相关的执行函数。然后我们就可以根据消息的动作标识调用相关的执行函数，而这个执行函数实际上就是通过ClassWizard在类实现中定义的一个方法。这样就把消息的处理转化到类中的一个方法的实现上。
(5)如果OnWndMsg方法没有对消息进行处理的话，就调用DefWindowProc对消息进行处理。这是实际上是调用原来的窗口过程进行缺省的消息处理。 所以如果正常的消息处理的话，MFC窗口类是完全脱离了原来的窗口过程，用自己的一套体系结构实现消息的映射和处理。即先调用MFC窗口类挂上去的窗口过程，再调用原先的窗口过程。用户面对的消息参数将不再是固定的wParam和lParam,而是和消息类型具体相关的参数。比如和消息WM_LButtonDown相对应的方法OnLButtonDown的两个参数是nFlags和point。nFlags表示在按下鼠标左键的时候是否有其他虚拟键按下，point更简单，就是表示鼠标的位置。同时MFC窗口类消息传递中还提供了两个函数，分别为WalkPreTranslateTree和PreTranslateMessage。我们知道利用MFC框架生成的程序，都是从CWinApp开始执行的，而CWinapp实际继承了CWinThread类。在CWinThread的运行过程中会调用窗口类中的WalkPreTranslateTree方法。而WalkPreTranslateTree方法实际上就是从当前窗口开始查找愿意进行消息翻译的类，直到找到窗口没有父类为止。在WalkPreTranslateTree方法中调用了PreTranslateMessage方法。实际上PreTranslateMessage最大的好处是我们在消息处理前可以在这个方法里面先做一些事情。举一个简单的例子，比如我们希望在一个CEdit对象里，把所有的输入的字母都以大写的形式出现。我们只需要在PreTranslateMessage方法中判断message是否为WM_CHAR,如果是的话，把wParam(表示键值)由小写字母的值该为大写字母的值就实现了这个功能。
4 小结
MFC通过巧妙的宏定义把消息调用的过程给封装起来，使用户能够通过ClassWizard方便的使用和处理Windows的各种消息。通过对MFC消息映射机制的分析，不仅能够使我们更好的使用MFC类库，同时，对于我们自己设计程序框架和类，无疑也有相当大的帮助。

参考文献：
[1] 侯俊杰 著，深入浅出MFC（第2版）[M].湖北：华中科技大学出版社，2001.5
[2] David J.Kruglinski著，Visual C++技术内幕（第五版）[M].北京：北京希望电子出版社，2001.1