前言

MFC是一项比较古老的编程技术，MFC将Win32窗口程序的函数封装成类，简化了编程难度。相对早期编程技术而言，MFC中新颖的就是消息映射了，记得本科时经常写MFC的基于对话框的窗口程序。那个时候对消息映射不理解，只知道这么用就可以了。现在有时间了，就可以研究一下。

代码分析

使用VS2017创建了一个基于对话框的MFC程序，解决方案的名称是Test，在窗口上添加了一个按钮，并且创建了按钮的单击事件，该事件完成MessageBox(L"Hello World!");的弹出。运行时，点击按钮将会产生如下运行结果。

这里，我们主要关注的是这个MFC程序的消息映射部分。在代码中也就是：

BEGIN_MESSAGE_MAP(CTestDlg, CDialogEx)
	ON_WM_SYSCOMMAND()
	ON_WM_PAINT()
	ON_WM_QUERYDRAGICON()
	ON_BN_CLICKED(IDC_BUTTON1, &CTestDlg::OnBnClickedButton1)
END_MESSAGE_MAP()

这是一些宏组合而成的一段代码，需要对宏进行展开。代码未进行宏展开前是这样的：

代码宏展开后是这样子的：（为了便于观察，我又删除了影响阅读的内容,调整了代码的格式，但并未改变程序的逻辑）

从展开的代码可以看出，这个消息映射部分展开成两个函数，分别是CTestDlg::GetMessageMap()和CTestDlg::GetThisMessageMap()。注意：CTestDlg是本Test窗口的窗口类的类名。

CTestDlg::GetMessageMap()函数是直接调用了本类的CTestDlg::GetThisMessageMap()函数。而CTestDlg::GetThisMessageMap()函数内部则更简单，仅仅是创建了2个静态全局变量：_messageEntries数组和messageMap变量。然后返回messageMap的地址。静态全局变量在编译的时候就会初始化完毕并且不再改变值。因此CTestDlg::GetThisMessageMap()函数实际上就是仅仅返回了messageMap的地址。

_messageEntries数组元素的类型是AFX_MSGMAP_ENTRY，其定义可以通过查看源代码进行查看。如下：

能够看出结构中重要的部分是：nMessage消息类型、nID控件的ID、pfn回调函数的地址。

这个结构体表明了MFC中消息映射的保存方式：保存在AFX_MSGMAP_ENTRY结构体中。

_messageEntries数组的长度等于映射的消息数量+1，最后一个是NULL，表明消息映射结束。

再次查看消息映射的部分：

实际上BEGIN_MESSAGE_MAP宏定义了CTestDlg::GetMessageMap()函数和CTestDlg::GetThisMessageMap()函数的前部分，CTestDlg::GetThisMessageMap()的中间部分由BEGIN_MESSAGE_MAP和END_MESSAGE_MAP之间的消息映射宏定义，而END_MESSAGE_MAP宏则完成了CTestDlg::GetThisMessageMap()后半部分的定义。

而这两个函数的声明则在CTestDlg的头文件中用宏来定义。

综上可以看出，MFC的消息映射通过宏来简化定义和严格规范，而这些宏的实质就是在为窗口类添加两个成员函数GetMessageMap()和GetThisMessageMap()，以便父类进行调用（由于本类未调用，那父类一定进行了调用），而这两个函数中GetMessageMap()是虚函数的实现，那么我们寻找CTestDlg类的父类对这两个函数的定义。我们不断的查找父类发现类的继承关系如下：

CTestDlg <- CDialogEx <- CDialog <- CWnd <- CCmdTarget <- CObject

我们在CWnd类中查找到了对GetMessageMap()函数的调用，调用发生在CWnd::OnWndMsg(UINT message, WPARAM wParam, LPARAM lParam, LRESULT* pResult)函数中，如下图所示：

我们查看CWnd类对本函数的实现：

好吧，CWnd类对这两个函数也是用宏进行定义的。

那么，我们在其基类中继续寻找吧。终于，在CCmdTarget中找到了对GetMessageMap()的定义：

这里的定义已被子类们反复重写了，已经没有用了。不过，我们看到了子类对这两个函数的定义与CCmdTarget类的定义形式上是一致的。

此时，思考下，微软为什么从CWnd类开始都使用宏来定义这两个函数呢？

这是因为MFC的控件都会继承该类；另外，用宏定义能够故意的将这两个函数拆分，可以防止MFC编写者不按照约定编写这个函数也可以防止在这两个函数中添加其它的代码。也就是说，微软为了强制要求MFC程序员一定要这样编写，不这样编写就编译不通过。如果不用宏而让MFC程序员手动编写的话，MFC程序员很容易不按照规范来，虽然编译通过了，但是却无法正常运行。

好了，看到这里，我们大概了解了消息映射的基本思路，为了获得MFC程序的事件消息对应的函数只需获得messageMap这个静态全局变量的地址就好了。因为它的第二个元素记录了_messgaeEntries数组的地址。获得了这个地址，就可以轻松的查看所有的MFC窗口程序的事件的回调函数地址了。

在获得messageMap地址之前，我们先来做一些有趣的事情。

我们在CTestDlg类的GetMessageMap()函数处下断点：

点击Visual Studio 2017的调试按钮进行调试，发现成功在该处命中断点：

查看调试窗口下方的调用堆栈选项卡窗口，可以看到调用来自mfc140ud.dll，双击跟进去，来到了第2207行。（注意：随着MFC库版本不同。对应的mfcxxx.dll文件也不同，调试的时候需要加载该dll的符号文件，才能查看这个dll的源码）

发现调用源头的确是在CWnd::OnWndMsg(UINT message, WPARAM wParam, LPARAM lParam, LRESULT* pResult)函数中。该函数依然是一个虚函数。

这也验证了上面的猜想。注意：由于mfc具有不同的版本，因此会有不同的诸如mfcxxx.dll的文件与之对应。那么dll里的函数地址就不是固定的。因此，我们没有必要从mfc的dll着手找到messageMap的地址。

说了这么多，如何才能用最快的方式得到消息映射的回调函数地址呢？

回调函数地址定位方法

方式一：利用虚函数表

前面讲到GetMessageMap()函数是窗口类的一个虚函数，那么可以通过mfc程序的窗口类，在创建该类的对象的时候获得的this指针，找到虚函数表。虚函数表里面一定有一个是GetMessageMap()函数的地址，然后再跟进去找到GetMessageMap()函数的地址，最后拿到函数的返回值存放在eax寄存器中，就是messageMap的地址。那么messageMap+4就是消息映射的AFX_MSGMAP_ENTRY数组。然后在这个数组里面就能找到消息映射的回到函数的地址。

问题1：如何快速获得窗口类的实例化对象的this指针？

MFC程序在启动时会调用getMoudleHandleA函数，在其后面会接着call _twinmain函数，这个函数的内部只有一个调用，即call afxWinMain函数，该函数的返回值，保存在eax中即是this指针。

问题2：通过this指针找到虚函数表？

This指针保存的值是对象关联的私有成员的起始地址，这个起始地址就是对象的虚函数表之后是其它成员的数据。

找到虚函数表后就可以在这个表中确定GetMessageMap()函数的地址。接下来的事情就顺理成章了。

方式二：内存搜索法

为什么要使用内存搜索呢？

因为保存AFX_MSGMAP_ENTRY数组的数据声明的时候就是全局静态变量。这表明，一般而言：这个数组一定存放在mfc程序的exe镜像的全局数据区域，并且这些数据是在编译的时候确定的，在程序运行的时候不会对这些数据进行修改（可能会在程序运行之前被操作系统使用重定向功能修改）。我们再思考一下，一般一个mfc程序都是用模版创建的，而且只要mfc程序员不刻意修改消息映射部分的代码，那么消息映射中必定含有如下部分：