【实战】CEF框架集成MFC DLL的一些坑

文章目录

MFC作为微软的长期主力开发套件之一,之前很多设备开发的C/S端界面都是通过MFC框架来做的,而在我自己的CEF项目中,会集成很多之前的DLL来完成设备驱动和开发。所以,在CEF项目开发中,肯定会碰到一些和原有的MFC代码集成的工作。

最近收集了几个在集成工作中的坑,自己做个记录,如果能帮到各位,请各位点赞收藏。感谢

DLL 导出方式,函数指针的坑

在其中的一个DLL集成中,这个DLL提供的头文件中有如下的一个函数:

virtual int GetInfo(CString& nVersion) = 0;

这里的形参CString就是MFC框架中的一个字符串库,因为我嫌麻烦,而且判断我在我自己的项目中不需要用到这个函数,也不想在CEF框架中再将MFC的一些库打包进来,这样会降低编译速度,也会增加项目打包后的大小。

所以我第一次的解决方法就是将这个函数从头文件中注释掉。

灾难就是因为这一条注释引起的。

问题出现

注释掉这个函数后,集成顺利进行,而且能顺利控制设备完成一些操作。但发现的问题是,这个DLL提供的所有设备驱动函数中,有部分可以执行,有部分不能执行,而且不能执行的错误很夸张,直接是内存越界,整个程序coredown:

这让我百思不得其解,还找提供DLL的同事增加日志等,结果发现出错的操作函数直接无法进入。

然后又对了编译参数等等,所有的编译参数都对了一遍,结果还是不行。因为这个问题项目停了两三天。

问题解决

直到有一次查看了一下这个DLL的导出方式:

extern "C"
{
	DLL_API	APIHANDLE* CreateHandleObj();
    
	DLL_API void	DeleteHandleObj(APIHANDLE*);
}

也就是说,这个DLL是导出的这个操作类对象,而不是方法。

  1. 如果DLL导出的是方法的话,那么在DLL会把这些方法加载到内存后,将这些方法的内存地址都导出,在程序中调用这些方法的话,就可以直接通过函数指针的方式访问这些地址,完成函数调用。
  2. 如果DLL导出的是类对象的话,那么DLL只会导出这个对象的函数首地址,然后通过函数指针的方式,一个一个的去做函数移动,然后移动到响应内存位置,再完成函数调用。

那么我的问题就出在这里,比如DLL中有20个函数,我将上面那个函数注释掉之后,上层的应用程序就只会认为DLL中有19个函数。

而注释掉的函数如果是在第10个位置的话,那么前9个函数的调用都是没问题的,都可以通过函数指针的方式移动获取到相应的内存地址。

但是这个函数和这个函数后续的函数地址就会发生错位,就会发生上面提到的内存越界访问的问题!!

解决的方案就是恢复这个函数。

CEF集成MFC

如果不注释那个函数,就要解决CString的问题,也就是要集成MFC。

afxwin.h

一般所有的MFC程序都会集成这个头文件: afxwin.h,这个头文件包括了大部分的MFC基础类,当然也包括了CString这个类。

预编译

visual studio提供了预编译的能力,像mfc这种固定的框架头文件,没必要放在业务头文件中,在visual studio创建的项目中,一般都会有一个pch.h的文件,这个头文件中的内容就是visual studio会提前编译好的。

所以,集成MFC的第一步就是将afxwin.h放到pch.h中:

// pch.h: 这是预编译标头文件。
// 下方列出的文件仅编译一次,提高了将来生成的生成性能。
// 这还将影响 IntelliSense 性能,包括代码完成和许多代码浏览功能。
// 但是,如果此处列出的文件中的任何一个在生成之间有更新,它们全部都将被重新编译。
// 请勿在此处添加要频繁更新的文件,这将使得性能优势无效。

#ifndef PCH_H
#define PCH_H

// 添加要在此处预编译的标头
#include "framework.h"

#include <afxwin.h>         // MFC 核心组件和标准组件

#endif //PCH_H

在visual studio中可以配置这个预编译能力:

编译参数修改

集成MFC还需要修改一个编译参数:

这里需要选择MFC库,使用DLL的话,就表示在你的程序中,MFC的功能是以DLL方式存在的,如果是静态库的话,就会把MFC的lib库打入到你的应用程序里。

我选择的是DLL库。

DLL重命名

最后一个坑,因为我集成MFC的DLL也是一个DLL程序,在没有集成MFC之前,我的DLL命名就是visual studio默认的命名:

BOOL APIENTRY DllMain( HMODULE hModule,
                       DWORD  ul_reason_for_call,
                       LPVOID lpReserved
                     )
{
    switch (ul_reason_for_call)
    {
    case DLL_PROCESS_ATTACH:
    case DLL_THREAD_ATTACH:
    case DLL_THREAD_DETACH:
    case DLL_PROCESS_DETACH:
        break;
    }
    return TRUE;
}

但是集成了MFC之后,也就是上面提到的集成了MFC的DLL之后,再编译就会提示DllMain重定义,也就是说和MFC的DLL中的DllMain冲突了,所以这里需要改个名字即可:

BOOL APIENTRY DllMainMyOwn( HMODULE hModule,
                       DWORD  ul_reason_for_call,
                       LPVOID lpReserved
                     )
{
    switch (ul_reason_for_call)
    {
    case DLL_PROCESS_ATTACH:
    case DLL_THREAD_ATTACH:
    case DLL_THREAD_DETACH:
    case DLL_PROCESS_DETACH:
        break;
    }
    return TRUE;
}

顺利解决问题!!

相关推荐
半盏茶香21 分钟前
【C语言】分支和循环详解(下)猜数字游戏
c语言·开发语言·c++·算法·游戏
小堇不是码农28 分钟前
在VScode中配置C_C++环境
c语言·c++·vscode
Jack黄从零学c++30 分钟前
C++ 的异常处理详解
c++·经验分享
捕鲸叉6 小时前
创建线程时传递参数给线程
开发语言·c++·算法
A charmer6 小时前
【C++】vector 类深度解析:探索动态数组的奥秘
开发语言·c++·算法
Peter_chq6 小时前
【操作系统】基于环形队列的生产消费模型
linux·c语言·开发语言·c++·后端
青花瓷8 小时前
C++__XCode工程中Debug版本库向Release版本库的切换
c++·xcode
幺零九零零9 小时前
【C++】socket套接字编程
linux·服务器·网络·c++
捕鲸叉9 小时前
MVC(Model-View-Controller)模式概述
开发语言·c++·设计模式
Dola_Pan10 小时前
C++算法和竞赛:哈希算法、动态规划DP算法、贪心算法、博弈算法
c++·算法·哈希算法