【实战】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;
}

顺利解决问题!!

相关推荐
做人不要太理性18 分钟前
【C++】深入哈希表核心:从改造到封装,解锁 unordered_set 与 unordered_map 的终极奥义!
c++·哈希算法·散列表·unordered_map·unordered_set
程序员-King.27 分钟前
2、桥接模式
c++·桥接模式
chnming198731 分钟前
STL关联式容器之map
开发语言·c++
程序伍六七44 分钟前
day16
开发语言·c++
小陈phd1 小时前
Vscode LinuxC++环境配置
linux·c++·vscode
火山口车神丶1 小时前
某车企ASW面试笔试题
c++·matlab
是阿建吖!2 小时前
【优选算法】二分查找
c++·算法
Ajiang28247353044 小时前
对于C++中stack和queue的认识以及priority_queue的模拟实现
开发语言·c++
‘’林花谢了春红‘’8 小时前
C++ list (链表)容器
c++·链表·list
机器视觉知识推荐、就业指导10 小时前
C++设计模式:建造者模式(Builder) 房屋建造案例
c++