简介面向具备C基础、正在使用VS2019开发Windows桌面程序的MFC学习者与工程人员这份资料围绕MFC常规动态链接库与扩展动态链接库的封装、导出及非模态调用展开着重解决接口声明、模块加载卸载、调用端对接和链接配置等常见问题适合课程设计、项目复现与旧工程维护时参考。压缩包共224个文件约328.67MB内含h/cpp源码、dll/lib/def导出库与导入库文件、sln/vcxproj工程配置、rc/res界面资源以及pdb、obj、tlog等调试和构建中间产物目录中保留较完整的编译痕迹便于对照排查链接与运行时错误。资源已有1039人学习。其价值在于同时给出常规库与扩展库两类封装例程及配套调用端读者可据此理解AFX_EXT_CLASS导出、静态链接与动态链接差异、AfxLoadLibrary/AfxFreeLibrary及GetProcAddress的调用方式对导出宏、模块切换与资源复用也有涉及可借助现有工程结构较快搭建自己的MFC DLL封装与调用框架。1. 一个非模态窗口卡住的下午这套 VS2019 MFC DLL 例程能省掉什么前阵子改一个老工控上位机主界面是 MFC 对话框客户要把参数配置窗拆成独立模块单独更新。翻完代码最后落地的方案就是这套 VS2019 MFC DLL主程序只留一个按钮窗口逻辑塞进共享 MFC 的常规 DLL弹出来是非模态的用户能一边开着配置窗一边看实时曲线。它提供的是两份能照着抄的骨架——一份常规库、一份扩展库分别给出非模态调用的完整打开与关闭链路并非 Hello World。适合刚接手 vc 老项目、被 DLL 导出名和资源串台折磨过的 C 开发者。2. 工程结构拆解常规库、扩展库、规则库三者在 VS2019 里的真实边界DLL 本身并不复杂真正麻烦的是选错类型之后返工。这套例程把三种形态放在一个解决方案里指的就是让你先看清楚边界再动手。很多人第一次建 MFC DLL 工程看到向导里三个选项随手点第一个结果后面想导出 C 类才发现导出不了整个工程推倒重来。2.1 向导里那三个选项到底差在哪VS2019 新建项目搜「MFC 动态链接库」弹出的向导上有三行选项中文界面大致是「共享 MFC DLL 的规则 DLL」「带静态链接 MFC 的规则 DLL」「MFC 扩展 DLL」。标题里说的「常规库」「规则库」其实是同一个东西的两种叫法都是 Regular DLL只是向导的中文翻译在不同版本里来回变过。真正的区别在导出能力和 MFC 运行时的链接方式上工程类型MFC 链接能导出什么宿主限制典型用途常规库共享 MFC动态/MD _AFXDLLC 风格函数、简单类任何 Win32 程序功能模块、算法库、窗口封装常规库静态 MFC静态/MTC 风格函数任何 Win32 程序给非 MFC 宿主复用扩展库动态/MD _AFXDLL派生自 MFC 类的 C 类必须是 MFC 程序界面插件、框架扩展关键差别在于扩展库导出的类可以继承 CDialogEx、CFrameWnd 这些 MFC 基类宿主拿到就能直接 new常规库不行因为常规库和宿主之间没有共享的 MFC 模块状态直接把 MFC 类跨模块传过去虚表、资源句柄全是对不上的运行起来就是随机崩溃。提示只要宿主是 MFC 程序、又被要求「DLL 里弹窗口」优先选扩展库如果宿主可能是个纯 Win32 或者 C# 壳子那只能走常规库窗口封装成 C 函数导出。2.2 例程的目录与关键文件这套例程的解决方案结构大致是这样我在梳理时按职责重新排了一下MfcDllDemo/ ├─ MfcDllDemo.sln ├─ MfcRegular/ # 常规库共享 MFC DLL 的规则 DLL │ ├─ MfcRegular.vcxproj │ ├─ pch.h / pch.cpp # 预编译头MFC 工程必备 │ ├─ MfcRegular.h/.cpp # DllMain CWinApp 派生类 theApp │ ├─ MfcRegularApi.h/.cpp # 对外导出接口只有这一层暴露给宿主 │ ├─ ModelessDlg.h/.cpp # 非模态窗口本体 │ ├─ MfcRegular.def # 导出名钉死防 x86 修饰 │ └─ MfcRegular.rc # IDD_MODELESS_DLG 在这里 ├─ MfcExt/ # 扩展库 │ ├─ MfcExt.vcxproj │ ├─ ExtDll.cpp # DllMain AFX_EXTENSION_MODULE │ ├─ ExtDlg.h/.cpp # AFX_EXT_CLASS 导出对话框类 │ └─ MfcExt.rc ├─ StaticRuleLib/ # 静态链接 MFC 的常规库对比用 └─ HostApp/ # MFC 宿主对话框程序 ├─ HostAppDlg.h/.cpp └─ HostApp.rc值得单独说一句的是MfcRegularApi.h。例程把「DLL 内部实现」和「对外契约」分成了两个头文件宿主工程的包含路径里只放 Api 那个。这个习惯很值得抄后面改内部类、换窗口实现宿主一行都不用动。2.3 在 VS2019 里把解决方案搭起来从零建一遍顺序别搞反先建库再建宿主。库工程建好之后属性页里有几项必须一次改对改错了后面全是玄学问题平台统一成 x64或者统一 x86不能一个 x64 一个 x86。属性 → 高级 → 字符集全部选「使用 Unicode 字符集」。属性 → C/C → 代码生成 → 运行库共享 MFC 的工程选「多线程调试 DLL (/MDd)」和「多线程 DLL (/MD)」静态的选 /MTd 和 /MT。属性 → 常规 → 在共享 DLL 中使用 MFC这里选「使用 MFC 的动态链接库」预处理器里会自动带上_AFXDLL。把宿主工程的「引用」指向两个库工程或者干脆用#pragma comment(lib, ...)显式挂。导出名这一块例程多给了一个.def文件。原因很简单x86 平台上__declspec(dllexport)导出的extern C函数会被修饰成_MfrShowModeless4这种带下划线和参数长度的名字宿主用GetProcAddress(MfrShowModeless)会直接拿到空指针。; MfcRegular.def —— 把导出名钉死宿主按名字取函数才不会翻车 LIBRARY MfcRegular EXPORTS MfrShowModeless MfrCloseModeless MfrGetDlgCount.def里列过的函数不用再加__declspec(dllexport)加了也不冲突。x64 下本来就没有名字修饰所以这个文件在 x64 配置里属于「用了更稳、不用也活」的保险。3. 常规库核心实现从 CWinApp 到导出函数的完整调用链常规库这一层是整个方案里最容易出错的地方。它虽然也是个 DLL但只要用了共享 MFC就一定有且只有一个 CWinApp 派生对象MFC 的初始化、资源查找、消息泵全都挂在这个对象和它的模块状态上。3.1 导出层只暴露 C 接口把 MFC 关在门里对外头文件的作用是给宿主一个干净的契约里面不能出现任何 MFC 类型连CString都别露。宿主可能是个纯 Win32 程序也可能是个用别的编译器编译的老代码一旦头文件里带了afxwin.h它就编不过了。// MfcRegularApi.h —— 宿主只包含这一个头文件 #pragma once #include windows.h #ifdef MFCREGULAR_EXPORTS #define MFR_API __declspec(dllexport) #else #define MFR_API __declspec(dllimport) #endif // extern C 关掉 C 名字修饰参数和返回值全部用 Win32 原生类型 extern C { MFR_API BOOL MfrShowModeless(HWND hParent); // 打开非模态窗口 MFR_API void MfrCloseModeless(); // 主动关闭宿主退出前必须调 MFR_API int MfrGetDlgCount(); // 当前存活窗口数调试用 }MFCREGULAR_EXPORTS这个宏在库工程的 C/C → 预处理器里定义宿主工程不定义于是同一个头文件在两边分别展开成导出和导入。这是 Windows DLL 最常见的一套写法比维护两个头文件省事得多。参数用HWND而不是CWnd*是有意为之CWnd*是 MFC 对象指针跨模块传等于把本模块的虚表地址交给别人MFC 内部状态一切换就废了。传窗口句柄DLL 内部自己CWnd::FromHandle转一下边界干净。3.2 一个能复用的非模态对话框类非模态窗口类和模态的写法差别不大唯一必须重写的是销毁时机。模态的DoModal是个阻塞函数返回时窗口已经析构非模态的Create立刻返回窗口活得比函数调用长所以「谁 new 的谁 delete」这条规矩得靠PostNcDestroy来兑现。// ModelessDlg.h #pragma once #include afxdialogex.h #include resource.h class CModelessDlg : public CDialogEx { DECLARE_DYNAMIC(CModelessDlg) public: explicit CModelessDlg(CWnd* pParent nullptr); enum { IDD IDD_MODELESS_DLG }; protected: virtual void DoDataExchange(CDataExchange* pDX); // 非模态窗口唯一安全的自删除时机窗口句柄已销毁、对象还活着 virtual void PostNcDestroy(); DECLARE_MESSAGE_MAP() public: afx_msg void OnBnClickedApply(); };// ModelessDlg.cpp #include pch.h #include ModelessDlg.h // 导出层持有这个指针用来判重和主动关闭 extern CModelessDlg* g_pModelessDlg; IMPLEMENT_DYNAMIC(CModelessDlg, CDialogEx) CModelessDlg::CModelessDlg(CWnd* pParent) : CDialogEx(IDD_MODELESS_DLG, pParent) { } void CModelessDlg::DoDataExchange(CDataExchange* pDX) { CDialogEx::DoDataExchange(pDX); } void CModelessDlg::PostNcDestroy() { CDialogEx::PostNcDestroy(); g_pModelessDlg nullptr; // 先让导出层知道指针失效 delete this; // 再自杀顺序反了就是野指针 } BEGIN_MESSAGE_MAP(CModelessDlg, CDialogEx) ON_BN_CLICKED(IDC_BTN_APPLY, CModelessDlg::OnBnClickedApply) END_MESSAGE_MAP()PostNcDestroy是 MFC 留给非模态窗口的标准钩子DestroyWindow走完OnDestroy、窗口句柄失效之后才会调到这里。在这儿delete this是安全的写在OnDestroy里就不一定了——那时候窗口还没彻底销毁后面 MFC 内部还会碰这个对象。g_pModelessDlg用extern声明在头文件外面是为了让导出层和窗口类共享同一个指针。工程小的时候这么写没问题工程大了我一般会收进一个单例或者管理器类里避免全局变量到处飞。3.3 非模态调用的完整链路与关闭导出函数里第一行必须是AFX_MANAGE_STATE这是常规库的保命符。它做的事是把当前线程的 MFC 模块状态从宿主切到本 DLL切完之后AfxGetResourceHandle()才指向本 DLL 的资源段LoadString、AfxMessageBox、对话框模板才找得到。// MfcRegularApi.cpp —— 常规库的导出实现 #include pch.h #include MfcRegularApi.h #include ModelessDlg.h CModelessDlg* g_pModelessDlg nullptr; extern C MFR_API BOOL MfrShowModeless(HWND hParent) { // 切模块状态资源、字符串、对话框模板才会从本 DLL 里找 AFX_MANAGE_STATE(AfxGetStaticModuleState()); if (g_pModelessDlg ! nullptr ::IsWindow(g_pModelessDlg-GetSafeHwnd())) { // 已经开着就前置不重复创建 g_pModelessDlg-ShowWindow(SW_SHOW); g_pModelessDlg-SetForegroundWindow(); return TRUE; } CWnd* pParent CWnd::FromHandle(hParent); g_pModelessDlg new CModelessDlg(pParent); // 注意这里用 Create 而不是 DoModal非模态不能阻塞宿主消息循环 if (!g_pModelessDlg-Create(IDD_MODELESS_DLG, pParent)) { delete g_pModelessDlg; g_pModelessDlg nullptr; return FALSE; } g_pModelessDlg-ShowWindow(SW_SHOW); return TRUE; } extern C MFR_API void MfrCloseModeless() { AFX_MANAGE_STATE(AfxGetStaticModuleState()); if (g_pModelessDlg ! nullptr ::IsWindow(g_pModelessDlg-GetSafeHwnd())) { // DestroyWindow 会走 OnDestroy - PostNcDestroy指针在那边清 g_pModelessDlg-DestroyWindow(); } g_pModelessDlg nullptr; } extern C MFR_API int MfrGetDlgCount() { return (g_pModelessDlg ! nullptr) ? 1 : 0; }几个参数值得单独说清楚。hParent传宿主的窗口句柄非模态窗口挂在它下面宿主最小化时子窗口跟着走关闭宿主时系统也会连带销毁。Create的第二个参数也是父窗口和构造函数里传的是同一个两处必须一致只传一处会出现窗口位置飘到屏幕左上角的情况。MfrCloseModeless这个函数看着多余其实是必需的。宿主退出时如果 DLL 窗口还活着进程卸载 DLL 的那一刻窗口对象就成了野的退出瞬间直接访问违例。正确顺序是宿主OnDestroy里先调MfrCloseModeless()再AfxFreeLibrary。注意AFX_MANAGE_STATE只对当前作用域有效它在栈上放了个对象函数返回时自动还原。所以每个导出函数开头都得写一遍不能只在其中一个里写。4. 扩展库与非模态窗口AFX_EXT_CLASS 类导出和宿主消息循环怎么配合常规库那一套是「函数进出」扩展库这一套是「对象进出」。两者最大的不同在于扩展库和宿主共享同一份 MFC 运行时类可以直接跨模块 new但前提是 DLL 初始化时把自己的模块信息挂进 MFC 的资源链否则宿主永远找不到它里面的对话框模板。4.1 DllMain 里的 CDynLinkLibrary 是资源链的关键MFC 扩展库的 DllMain 不能随便写模板代码里那几行是有讲究的删掉任何一句都会出问题。// ExtDll.cpp —— 扩展库入口MFC 资源链在这里建立 #include pch.h #include ExtDlg.h // 保存本扩展 DLL 的模块信息AFX_EXTENSION_MODULE 由 MFC 定义 static AFX_EXTENSION_MODULE g_extDll { nullptr, nullptr }; extern C int APIENTRY DllMain(HINSTANCE hInstance, DWORD dwReason, LPVOID /*lpReserved*/) { if (dwReason DLL_PROCESS_ATTACH) { // 初始化扩展模块失败必须返回 0否则宿主后面全在错误状态里跑 if (!AfxInitExtensionModule(g_extDll, hInstance)) return 0; // 挂到 MFC 的 CDynLinkLibrary 链上本 DLL 的资源从此可被搜索到 new CDynLinkLibrary(g_extDll); } else if (dwReason DLL_PROCESS_DETACH) { // 宿主进程退出时调用释放扩展模块占用的资源 AfxTermExtensionModule(g_extDll); } return 1; }new CDynLinkLibrary(g_extDll)这一行分配出去的对象是故意不释放的它由 MFC 在模块卸载时统一回收。它的作用是把当前 DLL 的HINSTANCE和资源段挂进一条链表之后 MFC 在AfxFindResourceHandle时就会顺着链表把每个扩展库都问一遍。少了这行宿主调Create(IDD_EXT_DLG)会直接返回失败GetLastError什么也不给你这就是最典型的黑匣子现场。4.2 用 AFX_EXT_CLASS 导出一个对话框类扩展库导出类只要在类声明前加AFX_EXT_CLASS它展开后是__declspec(dllexport)或dllimport靠_AFXEXT宏自动切换。类里的成员函数、消息映射全部跟着导出宿主拿到的是完整的类型信息。// ExtDlg.h —— 扩展库导出的非模态对话框类 #pragma once #include afxdialogex.h #include resource.h class AFX_EXT_CLASS CExtDlg : public CDialogEx { DECLARE_DYNAMIC(CExtDlg) public: explicit CExtDlg(CWnd* pParent nullptr); enum { IDD IDD_EXT_DLG }; protected: virtual void DoDataExchange(CDataExchange* pDX); virtual void PostNcDestroy(); DECLARE_MESSAGE_MAP() };宿主要做的只有三件事包含头文件、挂上.lib、new出来调Create。不需要GetProcAddress也不需要写.def因为链接器在编译期就把符号对上了。// HostAppDlg.cpp —— 宿主侧创建扩展库窗口 #include pch.h #include HostAppDlg.h #include ExtDlg.h // 扩展库头文件 #pragma comment(lib, MfcExt.lib) // 导入库Debug 配置下路径要对 void CHostAppDlg::OnBnClickedExtDlg() { if (m_pExtDlg nullptr) { // 对象由宿主 new 出来析构也由宿主负责跨模块分配风险小 m_pExtDlg new CExtDlg(this); if (!m_pExtDlg-Create(CExtDlg::IDD, this)) { delete m_pExtDlg; m_pExtDlg nullptr; AfxMessageBox(_T(扩展库窗口创建失败先查资源链)); return; } } m_pExtDlg-ShowWindow(SW_SHOW); m_pExtDlg-SetForegroundWindow(); }CExtDlg::IDD这个枚举在宿主侧是可见的因为整个类都导出了。但要注意IDD_EXT_DLG这个资源 ID 的数值在宿主工程里必须不存在否则宿主会优先拿自己的资源去创建出来的界面对不上控件全是空的。4.3 两条消息循环如何协作非模态窗口能被拖动、能响应按钮靠的是宿主线程的消息泵。扩展库窗口Create在宿主 UI 线程上ShowWindow之后它就是一个普通子窗口WM_COMMAND、WM_PAINT全部由宿主的CWinApp::Run分发。这也是为什么非模态窗口不能在工作线程里创建——那个线程没有消息泵窗口画出来就是一块白板点什么都没反应。如果 DLL 里确实需要独立线程常见做法是在那个线程里自己跑一个PeekMessage/DispatchMessage循环线程创建窗口、销毁窗口、退出循环三者成对出现不要指望主线程帮你兜底。这条路坑不少我一般会直接劝退能挪到主线程就挪。宿主退出时的顺序也需要固定下来先m_pExtDlg-DestroyWindow()再让主窗口销毁。如果宿主用AfxLoadLibrary显式加载扩展库还要在退出前AfxFreeLibrary扩展库全程静态链接进宿主的话这一步可以省。5. 踩坑排查DLL 加载失败、资源串台、非模态窗口崩溃的五种现场这些坑基本集中在两个阶段加载期和运行期。区分开之后排查会快很多因为加载期的问题几乎都是配置问题运行期的问题几乎都是模块状态和生命周期问题。5.1 加载期加载不上、创建失败现象一LoadLibrary一直返回 NULLGetLastError是 126 或者 193。原因基本只有两类126 是「找不到模块」通常是 DLL 不在宿主工作目录、PATH、或者没放进输出目录193 是「不是有效的 Win32 应用程序」说白了就是位数不匹配宿主 x64、DLL x86或者反过来。也有一部分是 MFC 运行时缺失DLL 依赖的mfc140u.dll在目标机器上没装。解决办法很直接把四个工程两个库、宿主、静态库的平台配置逐个检查一遍配置管理器里全部对齐再用dumpbin /dependents MfcRegular.dll看一眼依赖缺什么补什么。发布到干净机器上时把 VC 运行库一起打进去别指望用户自己装。现象二LoadLibrary成功了但GetProcAddress返回 NULL。原因通常是导出名被修饰了或者你查的名字大小写、前后缀对不上。x86 下__declspec(dllexport)会把extern C函数修饰成_MfrShowModeless4。解决方式是加.def文件把名字钉死或者用dumpbin /exports MfcRegular.dll把实际导出名打出来宿主照着写。查的时候别用GetProcAddress排除法一个个试浪费时间。5.2 运行期资源、断言与销毁时机现象三非模态窗口弹出来了但界面是英文的或者控件全空、提示文字乱码。原因是常规库的导出函数里漏了AFX_MANAGE_STATE(AfxGetStaticModuleState())当前线程的模块状态还停在宿主那边AfxGetResourceHandle()指向宿主的资源段于是对话框模板按 ID 去宿主里找找到个同 ID 的别的资源就出现了「窗口能显示但内容不对」的诡异现象。解决办法是给每个导出函数第一行都补上AFX_MANAGE_STATE包括那些看起来「只返回个数」的小函数。补完之后还会乱就检查.rc文件的编码和#include afxres.rc有没有漏。现象四窗口关掉之后再点按钮程序直接崩在g_pModelessDlg-ShowWindow上。原因有两个层面。一是PostNcDestroy里delete this之后没把g_pModelessDlg置空指针成了野的二是置空和 delete 的顺序反了先 delete 再判断IsWindow等于拿一个已释放对象的成员去试。解决方式是严格按「置空 → delete this」的顺序走并且在导出函数里判重的时候用g_pModelessDlg ! nullptr ::IsWindow(...)两个条件一起判断。现象五宿主退出时偶发崩溃崩在AfxTermExtensionModule或者 DLL 已经卸载之后的某个回调里。原因是宿主先卸载了 DLL窗口对象还在进程退出前系统给窗口发WM_DESTROY消息映射的代码已经在卸载的模块里跳过去就是访问违例。解决办法是在宿主的OnDestroy里先主动关掉所有 DLL 窗口再走AfxFreeLibrary。这个顺序我踩过一次之后就把它写进了工程模板里所有类似项目一律照抄。6. 二次开发把两份例程收敛成一个可插拔的窗口插件接口例程跑通之后下一步基本都会走到「我有五个窗口都要这么搞」的局面。这时候再把导出函数一个个往上加就不合适了得抽一层接口出来。做法很简单宿主和所有 DLL 共用同一个纯虚接口头文件每个 DLL 只导出一个工厂函数。// IPlugin.h —— 宿主与所有插件 DLL 共享零 MFC 依赖 struct IPlugin { virtual ~IPlugin() {} virtual const wchar_t* Name() const 0; // 显示在菜单上的名字 virtual BOOL Show(HWND hParent) 0; // 非模态打开不做阻塞 virtual void Close() 0; // 宿主退出前必须调 }; typedef IPlugin* (*PFN_CREATE_PLUGIN)(); // 每个 DLL 只导出这一个符号固定叫 CreatePlugin宿主侧用LoadLibraryGetProcAddress(CreatePlugin)遍历插件目录建一个vectorIPlugin*管理起来删除时统一调Close。改造过程中最容易漏的是三件事改造点原来建议导出符号每个功能一个函数只留CreatePlugin资源 ID各 DLL 随便定义统一分段避免和宿主撞号卸载时机宿主退出随手FreeLibrary先 Close 全部插件再卸载验证的时候别只跑 Debug。切 Release 跑一遍两个平台各跑一遍再用dumpbin /dependents确认没有混进静态 MFC 的库。我以前图省事只测 Debug结果 Release 下/MD和/MT混着链上线当天崩在客户机器上那次的教训是配置管理器里四个工程的运行库设置必须一起看不能只看当前活动的那一个。从那以后我每加一个库工程都强制把「平台 字符集 运行库 MFC 链接方式」四项过一遍再开始写代码。希望帮到你。本文还有配套的精品资源点击获取
