简介：精通MFC（光盘）源代码是一套与《精通MFC》书籍配套的完整示例源码，面向从入门到进阶的C++/Visual C++开发人员，特别适合想深入理解MFC框架结构、窗口消息机制和Windows应用构建流程的读者。压缩包共1114个文件，约8.01MB，以279个h头文件和229个cpp实现文件为主，同时包含rc/rc2界面资源、ico/bmp图形素材、vcproj/sln工程文件以及txt说明文档，各示例均保留了可直接编译运行的工程配置。源码按书籍章节组织，覆盖面向对象基础、窗口与消息处理、CObject序列化、MFC应用框架、消息映射与钩子、对话框数据交换、文档与视图架构、GDI/GDI+绘图、进程与线程、动态链接库、COM组件及托管C++等主题，从底层原理到高层封装均有对应示例；文件命名清晰，便于对照书中的章节编号快速定位。已有513人学习下载，无论是配书阅读、拆解MFC类库实现，还是作为Windows桌面项目开发参考，这份源代码都能提供很实在的参考价值。
1. 先回答“精通MFC（光盘）源代码”到底能给你什么
手头有一套《精通MFC》的配套光盘，或者在资料室、二手书摊翻出这张盘的人，多半是同一类诉求：想通过源代码真正搞懂MFC，而不是停留在“照着教程拖控件”的阶段。这张光盘里的东西不是安装包，也不是一堆零散的.txt讲义，而是一个按章节组织的完整示例工程集——从窗口创建、消息处理到文档/视图架构，每一段代码都能在Visual Studio里打开并编译。它的价值在于：你看到的不是被裁剪过的片段，而是MFC程序从头到尾的完整模样。
但这个标题背后有一个绕不开的现实：光盘里的代码大多是VC6时代的工程格式，直接双击用现在的Visual Studio打开，大概率会翻车——一堆编译错误、字符集警告、头文件找不到。这篇笔记就把“拿到这堆源代码之后怎么用”这件事讲清楚：光盘里到底是什么、怎么在新系统上跑起来、读哪些代码能真正长功力、以及老代码迁移时会踩的坑。适合两类人：要接手MFC老系统的维护者，以及想从Windows API/纯C++跨进MFC门槛的自学者。
2. 光盘里到底有什么：读懂MFC源码包的组织结构
2.1 不要把光盘源码当成一个库，它是一套按章节排列的教学工程
拿到光盘后的第一个错觉是“把它当成一个第三方库，编译出一个.lib然后链接”。这个思路会浪费时间，因为《精通MFC》这一代书籍的配套源码，本质上是“跟随书章节演进的独立工程集合”。每个示例都是完整可运行的Windows程序，有自己的工程文件、资源文件、源文件，彼此之间不构成依赖关系。换句话说，你是在读一本“用工程文件写成的书”，而不是在集成一个SDK。
另一个容易走偏的地方是去翻光盘根目录下的某个“总说明.txt”或“安装说明.txt”，指望有一个一键安装脚本。实际这批光盘大多数只是一堆目录和文件，没有安装程序。真正的索引是目录结构本身——按章节命名的文件夹、每个文件夹下一个示例工程。理解了这个定位，后面所有操作才会有方向：你不是在“部署代码”，而是在“逐个打开、编译、阅读”。
2.2 工程文件才是入口：从.dsw到.sln的演进
打开光盘里的示例文件前，先弄清楚你看到的工程文件属于哪个年代，直接决定你用哪个版本的Visual Studio去打开。VC6时代的工程由两个文件配合描述：.dsw是工作区文件，相当于“解决方案”的前身；.dsp是每个工程的构建描述。到了VS2002/2003之后，.dsw/.dsp被.sln/.vcproj取代；VS2010之后.vcproj又变成.vcxproj。这个演进很重要，因为你在光盘里看到的大概率是.dsw和.dsp，而你的电脑上装的是VS2015以上的IDE。
| 时代 | 工程文件 | 解决方案文件 | 用什么打开 |
|---|---|---|---|
| VC6 | .dsp | .dsw | VS2008及以上版本可转换 |
| VS2002~VS2008 | .vcproj | .sln | 转换向导自动升级 |
| VS2010之后 | .vcxproj | .sln | 直接打开 |
我一般会先在文件管理器里看目录里的文件后缀，再用命令行统计一下.dsw和.dsp的数量。如果全是.dsw/.dsp，那基本可以确定这套代码需要在现代IDE里走一遍“转换-修错-编译”的流程。顺便说一个和源代码管理相关的细节：这批老代码没有.git或.svn历史，本身也没有版本控制痕迹，你一旦用新IDE转换了.dsp，原文件就被改写了。所以在动手转换之前，把整个光盘目录原样复制一份当备份，是给自己留的后悔药。
2.3 圈定核心目录：示例工程、公共代码、资源文件各自的角色
不同批次的光盘目录命名有差异，但基本逃不出这几类内容。第一类是按章节组织的示例工程，通常叫Samples、Chapter、Lesson这类名字，里面每章一个文件夹，对应书上的一节。第二类是公共代码或半成品框架，偶尔会有一个Common或Src目录，放几个被多个示例复用的头文件和实现，比如自定义控件类或工具函数。第三类是资源相关的内容，包括图标、位图、对话框模板；这些资源以.rc文件形式存在，编译时要和resource.h配合读取。
圈定这三个区域之后，学习路径就很清晰：先挑一个最小的示例看入口，理解MFC的启动过程；再挑一个带菜单和状态栏的示例看UI如何联动；最后挑一个文档/视图架构的示例，理解数据和显示的分离。不要一开始就去啃复杂示例或者公共代码，那是本末倒置。光盘里的代码本来就是按书里的教学顺序排的，顺着目录走最省力。
3. 在新系统上把光盘代码跑起来：从解压到F5的最小步骤
3.1 先盘点再动手：用命令行快速看光盘全貌
很多人拿到光盘第一件事是双击.dsw，紧接着弹出一堆“不支持的工程格式”或者转换向导，手忙脚乱点完之后编译，报错几百条，然后就关掉窗口再也不碰了。正确的顺序是先盘点，再选工具链。把光盘里的内容拷到本地硬盘后，用下面的命令快速建立一个“文件地图”：
# 挂在本地目录后，先看两层目录结构，了解整体布局 find /mnt/mfc_disc -maxdepth 2 -type d | head -60 # 统计工程文件和解决方案文件的数量，判断代码属于哪个时代 echo "--- dsw ---"; find /mnt/mfc_disc -name "*.dsw" | wc -l echo "--- dsp ---"; find /mnt/mfc_disc -name "*.dsp" | wc -l echo "--- sln ---"; find /mnt/mfc_disc -name "*.sln" | wc -l # 找出所有包含 MFC 入口函数的源文件，确认核心示例的位置 grep -rn "InitInstance" --include="*.cpp" /mnt/mfc_disc | head -30逻辑说明：前两条命令帮你判断这套代码是纯VC6工程还是混合年代工程——如果.sln数量为零，说明必须走转换流程；如果两种都有，先挑有.sln的示例编译，能更快建立信心。最后一条grep是定位MFC程序入口最快的方法，CWinApp派生类里的InitInstance是每个MFC程序的真正起点，它出现在哪，哪就是可运行的示例。
参数说明：-maxdepth 2限制目录深度，避免输出几百行把终端刷爆；head -60和head -30都是截断输出用，数量大时只看前面部分即可；wc -l统计行数，配合find可以直接得到文件数量。如果你是在Windows环境，可以用PowerShell的Get-ChildItem -Recurse -Filter *.dsw | Measure-Object达到同样效果，思路一样，只是命令语法不同。
3.2 用现代Visual Studio打开老工程：转换向导的几个关键选择
把文件地图建好后，选一个最小示例开始转换。以VS2022为例，直接“打开项目”选择.dsw文件，IDE会提示你需要进行一次永久性转换。这里的第一个关键选择是：转换之前确认你已经勾选了“适用于最新v143生成工具的C++ MFC”组件。没装这个组件，转换后的工程会在链接阶段报cannot open file mfc140.lib之类的错误。第二个关键选择是转换向导里的“目标平台工具集”，默认会给一个较新的v143，不要改成旧版，新版工具集反而对老代码的兼容性更好。
转换完成后不要急着F5，先打开项目属性检查三个地方。第一，“配置属性 → 常规 → MFC的使用”，确认是“在共享DLL中使用MFC”还是“使用静态MFC库”，两种都可以，但要和代码里的预编译头设置一致。第二，“C/C++ → 预处理器 → 预处理器定义”里是否有_WIN32_WINNT或WINVER，没有就补一个，否则老代码经常撞上版本宏报错。第三，“配置属性 → 常规 → 字符集”，这一项决定了CString和TCHAR的解析方式，后面第5章会专门展开。
注意：转换向导会把.dsw和.dsp原文件改写成新格式，而且不可逆。动手之前把原始目录完整复制一份。我就因为没备份，把一章示例转换后编译不过，想回去看原始工程文件对比例子，发现已经被覆盖了，只能重新从光盘抓取。
3.3 第一个能跑的MFC程序：编译顺序与三个关键开关
选一个最简单的示例作为“试金石”，比如书里最前面那个只创建窗口的示例。打开后先编译，不要直接运行——先让编译错误全部清零，再按F5。老代码第一次编译，错误通常集中在几类：头文件找不到、宏未定义、函数名不匹配。头文件找不到大多是MFC组件没装全；宏未定义就是上一节说的_WIN32_WINNT问题；函数名不匹配则是VC6的老API在新SDK里被改名或被安全函数取代。先编译能让你把“环境问题”和“代码问题”分开，别混在一起排查。
// 一个最精简的 MFC 程序结构，光盘里几乎所有示例都长这样 class CMyApp : public CWinApp { public: virtual BOOL InitInstance(); // MFC程序的真正起点 }; class CMainFrame : public CFrameWnd { public: CMainFrame(); // 构造函数里创建窗口 }; BOOL CMyApp::InitInstance() { m_pMainWnd = new CMainFrame; // 创建主窗口对象 m_pMainWnd->ShowWindow(m_nCmdShow); m_pMainWnd->UpdateWindow(); return TRUE; // 返回TRUE才会进入消息循环 } CMyApp theApp; // 全局对象，触发构造函数逻辑说明：这里最反直觉的是最后一行CMyApp theApp。MFC程序没有你手写的WinMain，入口被框架藏在内部，而全局对象的构造时机早于main执行，所以theApp的存在才是整个程序的“第一推动力”。InitInstance里如果不返回TRUE，消息循环不会启动，窗口一闪而过就会退出——这是初学MFC最常见的问题之一。
参数说明：m_nCmdShow是框架传入的进程级显示状态参数，表示窗口启动时是正常显示、最小化还是最大化，不需要你手动赋值。ShowWindow和UpdateWindow的顺序不能反过来，先显示再更新内容，否则窗口会短暂出现空白区域。这个文件在MFC教程里几乎每一章都会出现，但很多人抄了代码却不知道全局对象构造这个隐藏机制，建议在这里打断点看调用顺序。
4. 带着源码学MFC：消息映射、文档/视图与状态栏的代码轨迹
4.1 消息映射不是语法，是查表机制
光盘里的示例代码看多了，你会发现一个高频模式：每个类都把以BEGIN_MESSAGE_MAP开头的宏块放在成员函数定义之后。初学者容易把这套宏当“固定搭配”死记硬背，但真正要理解的是它背后做了一张静态消息路由表。当鼠标点击、按键、菜单命令这些Windows消息到达窗口时，MFC不是靠虚函数去分发，而是查这张表找到对应的成员函数地址再调用。这就是它和C++虚函数机制的本质区别：虚函数是编译期定死的，消息映射是运行期查表，可以只在特定控件、特定命令ID上生效。
BEGIN_MESSAGE_MAP(CMainFrame, CFrameWnd) ON_WM_CREATE() // 窗口创建完成时的消息 ON_COMMAND(ID_FILE_NEW, OnFileNew) // 菜单“新建”命令 ON_COMMAND(ID_APP_EXIT, OnAppExit) // 菜单“退出”命令 ON_UPDATE_COMMAND_UI(ID_INDICATOR_TIME, OnUpdateTime) // 状态栏刷新 END_MESSAGE_MAP()逻辑说明：三个宏代表三种最常见的消息类别。ON_WM_CREATE处理WM_CREATE，是窗口创建后挂接子窗口和初始化的位置；ON_COMMAND处理菜单和按钮的“命令消息”，按ID进行路由；ON_UPDATE_COMMAND_UI处理的是UI刷新消息，专门用来更新菜单的灰色态、勾选态和状态栏文字。理解这三者的区别，就能看懂光盘里大部分示例的消息映射块。
参数说明：ID_FILE_NEW和ID_APP_EXIT是MFC预定义的“标准命令ID”，不需要你自己在resource.h里定义。这就是MFC的约定——框架已经内置了这些菜单项的响应逻辑轮廓，你只需要把自己的函数挂到对应ID上。状态栏里的ID_INDICATOR_TIME则不一样，它是示例自己定义的ID，对应的刷新函数需要你写在消息映射块里，MFC不会自动帮你填充显示内容。
4.2 从光盘示例看Doc/View如何协作
阅读光盘里带“文档/视图”架构的示例时，很多人会卡在一个问题：为什么窗口在视图类里画图，数据却在文档类里存取，这中间的数据是怎么流动的？答案在MFC的“文档模板”设计里。创建文档时，框架同时创建对应的视图框架窗口；视图通过GetDocument()拿到文档指针；文档里的数据改变后，调用UpdateAllViews通知所有视图刷新。这套机制在五六章前的示例里可能还看不出来，但到了涉及多视图的章节，它的价值立刻显现。
BOOL CMyDoc::OnNewDocument() { if (!CDocument::OnNewDocument()) return FALSE; // 基类初始化失败则中止 m_nCount = 0; // 文档持有的“业务数据” return TRUE; // 成功创建新文档 } void CMyView::OnDraw(CDC* pDC) { CMyDoc* pDoc = GetDocument(); // 视图反向拿到文档指针 ASSERT_VALID(pDoc); pDC->TextOut(0, 0, pDoc->GetCountText()); // 读取数据并绘制 }逻辑说明：OnDraw里的绘制动作发生在窗口需要重绘时——拖动窗口、被遮挡后又展示，都会触发WM_PAINT再回调OnDraw。所以不要在OnDraw里放“带副作用”的逻辑，比如修改数据或弹窗，否则窗口一重绘就会执行副作用代码。数据修改应该放在OnNewDocument这类“业务动作”里，改完之后调UpdateAllViews触发重绘，绘制函数只管读数据。
参数说明：ASSERT_VALID是调试期断言，检查指针是不是有效的MFC对象，Release版里会被编译掉。TextOut是GDI最基础的文本输出，坐标单位是像素。如果你想找五子棋MFC代码这类带交互的示例，核心思路就是在这个OnDraw里画棋盘、在视图类里处理WM_LBUTTONDOWN消息计算落子位置，再调InvalidateRect触发重绘——光盘里的Draw示例和Mouse示例正好拆开了这两件事。
4.3 MFC状态栏怎么显示：从静态指示器到动态刷新
如果你搜过“我要将一些信息显示在状态栏”这个问题，光盘里其实给了最正统的答案。MFC状态栏不是一个文本框，而是一个CAfxStatusBar容器里排着一组“指示器格子”，每个格子由字符串资源ID定义。格子的显示内容可以是静态文字，也可以通过ON_UPDATE_COMMAND_UI机制动态刷新。动态刷新的核心思路是：MFC在空闲时地给每个指示器发送一次更新查询，你在更新函数里把文字填进去，它就会显示在格子里。
// 状态栏的格子定义：三个格子的字符串ID static UINT indicators[] = { ID_SEPARATOR, // 左边的信息行，可以显示鼠标坐标等 ID_INDICATOR_CAPS, // 内置指示器，显示“大写” ID_INDICATOR_TIME, // 自定义：显示当前时间 }; void CMainFrame::OnUpdateTime(CCmdUI* pCmdUI) { CTime t = CTime::GetCurrentTime(); // 获取系统时间 CString s = t.Format(_T("%H:%M:%S")); // 格式化为时分秒 pCmdUI->SetText(s); // 把文字填入状态栏格子 pCmdUI->Enable(TRUE); // 让格子保持可见 }逻辑说明：OnUpdateTime是被消息映射块里那行ON_UPDATE_COMMAND_UI关联起来的，它每个“空闲时刻”被MFC调用一次。注意pCmdUI的Enable这个调用——如果注释掉它，状态栏格子在第一次刷新后可能变灰消失，因为指示器的初始状态是禁用。SetText用来填显示内容，但它只对“这个格子”生效，不会影响旁边的格子——每个格子的更新函数是独立的。
参数说明：_T宏的作用是把字符串字面量按当前字符集自动映射成char或wchar_t数组。如果你在项目属性里选了Unicode，_T("%H:%M:%S")就是宽字符字符串；选了多字节，就是窄字符。光盘里的老代码常常直接用"字符串"字面量，在Unicode工程下会编译报错，改成_T包裹是迁移时最机械也最必要的一步。
5. 老代码迁移到新编译器的避坑清单
5.1 fatal error C1189：版本宏没有定义
现象：编译一个从光盘转换来的示例，控制台直接报fatal error C1189: #error : _WIN32_WINNT not defined，整个编译中断，后续的错误信息全都被吞掉。
原因：VC6时代编译器的目标SDK比较老旧，代码里不声明_WIN32_WINNT也没关系，系统默认按当时的Windows版本处理。现代Windows SDK则要求代码明确声明“我面向哪个Windows版本”，不声明就直接用#error拦停编译。这个宏不是可有可无的装饰，它决定了你在代码里能用哪些Windows API——声明成0x0601表示面向Windows 7，声明成0x0A00表示面向Windows 10。
解决：在“项目属性 → C/C++ → 预处理器 → 预处理器定义”里加上_WIN32_WINNT=0x0601或更高版本。改完重新编译，这个错误会消失，连带“找不到Windows SDK头文件”的连环报错也会一起消失。如果你看到的是WINVER相关的C1189，处理方式相同，WINVER控制的是更底层的版本阈值，两个宏最好一起声明保持一致。
5.2 C4996：安全函数替换背后的A/B问题
现象：编译时刷出一片C4996: 'strcpy': This function or variable may be unsafe，有时还伴随警告“请使用strcpy_s”。新人一看头就大——代码明明是照着书抄的，怎么就不安全了？
原因：微软从VS2005开始默认把一批C运行库函数标记为“不安全”，建议使用带_s后缀的“安全版本”。这不是MFC的问题，是C运行库的ABI策略变了。老代码里的strcpy没有缓冲区长度参数，新代码要求传入目标缓冲区大小来防止溢出。MFC环境里更常见的是CString::GetBuffer之后用strcpy往缓冲区拷贝，这种代码在VC6下跑得好好的，到VS2013之后直接飘红。
解决：最省事的做法是在预处理器定义里加_CRT_SECURE_NO_WARNINGS，抑制这些警告，代码原样编译通过。但这不是治本方案——如果代码是生产系统要长期维护，正确的做法是把strcpy(a, b)改成strcpy_s(a, sizeof(a), b)，把sprintf改成snprintf，逐个替换。我的习惯是：学习光盘代码时直接加宏跳过，工作项目里坚决换_s版本。记住这个差别，别在维护老系统时偷懒。
5.3 字符集：多字节与Unicode的混用陷阱
现象：一个示例用多字节字符集编译运行时没问题，改了Unicode之后，到处报“不能将wchar_t转换为char”，或者运行时菜单显示乱码。另一个方向的坑是：代码里用了LPCTSTR和CString，但在某个函数里强转成了char*，结果中文全部变成问号。
原因：VC6时代工程默认“多字节字符集”，VS2010之后的工程默认“Unicode字符集”。这两个世界的字符串类型底层不同——多字节用char数组，Unicode用wchar_t数组。老代码如果大量使用char*硬编码而不是TCHAR适配宏，换到Unicode下必然出问题。反过来，工程不改字符集，但代码里有L"宽字符串"字面量，也会编译报错。
解决：最简单的决策是“工程和代码保持一致”。光盘里的代码按多字节写的，就把项目属性里“字符集”改成“使用多字节字符集”，这一条能让大部分老示例直接复活。如果必须用Unicode，就要把代码里的char改成TCHAR，printf改成_tprintf，所有字符串字面量包上_T宏。另外注意源文件本身的编码：VC6保存的.cpp是GB2312，VS2022默认按UTF-8解析，中文注释可能变成乱码但不会编译错——真正的坑是字符串字面量里的中文字符，编码不对会直接报错。
5.4 .rc资源编译失败：资源文件与资源ID的“玄学”
现象：转换后C++代码编译通过，却在编译.rc资源文件时报错，常见的有“ID冲突”“字符串ID重复定义”，或者资源编辑器打开对话框模板时一片乱码。有人会在网上搜“mfc iwebbrowser2 createex”之类的控件示例，想借鉴代码里的资源定义，结果发现自己的.rc根本编译不过。
原因：老.rc文件保存的编码格式和新版资源编译器期望的不一致，常见于中文Windows环境生成的工程。另外一件常被忽略的事是resource.h里的#define和.rc文件里的ID使用不一致——VC6的IDE自动维护这两个文件，但现代IDE转换后有时没有把新生成的ID同步写回.rc，导致同一个ID被两个不同资源使用。
解决：把.rc和resource.h都用“文件 → 高级保存选项”另存为“简体中文(GB2312) - 代码页936”，再重新编译。ID冲突就打开resource.h搜重复的#define值，手动改掉其中一个并同步更新.rc中的引用。这步没有捷径，我一般先把.rc里所有ID_开头的符号全部列出来，再对照resource.h逐行确认，每次都能抓到冲突。等你把这些老代码塞进现代源代码管理仓库时，记得把编码统一这件事写进提交说明里，不然下次检出的代码又是乱码，这种坑属于“不亲身经历一次很难相信它存在”。
6. 把光盘源码变成你的第一份MFC资产
6.1 用AI工具辅助读代码的边界
现在有人问“对MFC支持比较好的AI工具有哪些”，我的回答是：当翻译器可以，当专家不行。拿AI去逐行解释光盘里的代码，它能把CWinApp的构造和消息映射的宏展开讲得头头是道，这对第一次接触MFC的人帮助很大。但AI对MFC这种老框架的理解存在一个明显弱点——它不熟悉“框架在内部替你做了什么”的细节。比如它可能告诉你ON_UPDATE_COMMAND_UI在“空闲时被调用”，但不会告诉你空闲刷新的触发条件是消息队列空了，如果窗口里有耗时操作卡住主线程，状态栏就会“卡住不刷新”。所以我的用法是：拿AI快速过一遍看不懂的宏和框架调用，再自己翻代码验证它说的对不对，验证的手段就是断点和单步跟踪。
6.2 从“跑起来”到“改得动”的验证方法
光盘代码读完了，怎么确认自己真学会了？我给一个三步验证法。第一步，关掉书和笔记，凭记忆自己写一个最小MFC窗口程序，编译运行通过。第二步，给这个窗口加状态栏和时间显示，就按4.3节那套indicators数组加ON_UPDATE_COMMAND_UI来实现，然后故意把Enable(TRUE)去掉，观察状态栏格子在运行后消失——这个“故意改坏”的过程能验证你是否理解了UI更新机制。第三步，用Spy++查看窗口结构，验证你自己创建的窗口类名和消息路由是否符合预期。如果这三步都能独立完成，光盘里的代码就不再是别的作者的代码，而是你随时能调用的技能。我自己从这套光盘里收获最大的不是具体某个控件用法，而是“消息是被查表派发出来的”这个心智模型——带着这个模型去读任何MFC代码，哪怕是遇到从没见过的示例，也能顺着消息映射块把程序捋通。希望帮到你。
本文还有配套的精品资源，点击获取
