四个dll文件引发的“血案”——调用DLL中的函数

喵哥项目的合作公司最近给喵哥出了个难题——项目中激光雷达的模块是公司一个工程师负责的，工程师比较务实，在网上一个VB.NET代码的基础修改了一些细节，就交差了，的确可以用，但是最近工程师退出了这个项目，boss打算让喵哥接手这个模块，喵哥很慌，但还是硬着头皮上了。

面临的问题

1.一个用VB.NET（我不熟悉的语言）编写的程序；         因此我打算把它改写成VC++的形式

2.只有四个dll文件，没有lib和h，当时的我更加慌了；       想着怎么得到lib和h

3.所以我需要在VC++ 中调用四个dll的函数。

解决问题

从一种语言改写到另一种语言，最好的方法是撇开语言的束缚，把程序的功能和执行过程摸清楚，把一些api函数认真记下来，以便以后知道用哪个函数。由于程序比较简单，所以搞起来挺快的。

然后就遇到麻烦了，怎么调用dll文件中的函数？我之前写的程序都是先包含.h和.lib，然后把dll文件放在程序可读的路径下就可以完美的调用函数了。但是，现在只有四个光秃秃的dll，怎么搞？

dll文件是个啥

DLL(Dynamic Link Library)文件为动态链接库文件，又称“应用程序拓展”，是软件文件类型。在Windows中，许多应用程序并不是一个完整的可执行文件，它们被分割成一些相对独立的动态链接库，即DLL文件，放置于系统中。当我们执行某一个程序时，相应的DLL文件就会被调用。一个应用程序可使用多个DLL文件，一个DLL文件也可能被不同的应用程序使用，这样的DLL文件被称为共享DLL文件。值得一提的是，Linux下动态库是.so，静态库是.a。

dll不像exe可以独立执行，而是被其他程序调用，这种使用的特性使得dll经常用于代码复用来提高软件开发的效率。并且dll的暗盒特性使得它相较于提供源码实现代码复用的手段有以下几个优点：

1.不会暴露源代码；

2.不会造成与程序员的代码发生命名冲突；

3.体量小；

4.容易更新。

怎么调用dll

终于到了重头戏，“血案”的根源就是调用dll函数出了问题。

通常有两种调用dll的方法：一种是隐式调用，一种是显式调用。

隐式调用

隐式调用的方法需要采用静态加载，需要dll、h、lib，敢情喵哥之前一直用隐式调用。。。真·结庐在人间，而无车马喧·的“隐士”。

隐式调用要把h文件的路径包含到项目->属性->配置属性->VC++ 目录-> 在“包含目录”；

                     lib文件的路径包含到项目->属性->配置属性->VC++ 目录-> 在“库目录”

                     然后把需要用到的lib文件名拷贝到项目->属性->配置属性->链接器->输入-> 在“附加依赖项”

需要注意的是dll文件最好放在工程路径和可执行文件生成路径下，不过一些大公司的api在安装某些软件时，会把dll文件的路径添加到环境变量中去，所以有时看似不需要管dll文件，实则不然。

隐式调用比较简单粗暴，适合初学者使用，但是如果没有lib文件和头文件怎么办？

由dll文件生成lib和h

1.在VS的命令行工具中执行

dumpbin -exports lmsapi.dll>lmsapi.def

这是在VS2013命令行里执行dumpbin -exports lmsapi.dll显示的界面，生成的def文件也是这个样子的，可见不是所有的dll文件都是?function1@@的形式。

2.把lmsapi.def改成如下形式

LIBRARY"example"
EXPORTlmsapi_close_terminal	@1lmsapi_config = _wsprintfA	@2lmsapi_console_out	@3lmsapi_create_crc	@4lmsapi_get_laser_type	@5lmsapi_laser_data_create	@6lmsapi_laser_data_destroy	@7

后面的@1，@2是按照函数顺序排列。

3.然后执行lib.exe/def:lmsapi.def，可以生成lmsapi.lib和lmsapi.exp文件。lib就可以直接用了。

#pragma comment(lib,"lmsapi.lib")

4.新建一个lmsapi.tmp，里面保存函数名

      lmsapi_close_terminal	@1lmsapi_config = _wsprintfA	@2lmsapi_console_out	@3lmsapi_create_crc	@4lmsapi_get_laser_type	@5lmsapi_laser_data_create	@6lmsapi_laser_data_destroy	@7

然后运行undname.exe lmsapi.tmp>lmsapi.txt，从而把函数名解析到lmsapi.txt中。

5.需要用大佬的软件（还没要到），或者自己手动把格式改成.h文件中声明的形式，或者类的形式。

显式调用

显式调用在应用程序在执行过程中随时可以加载DLL文件，也可以随时卸载DLL文件，这是隐式链接所无法作到的，所以显式链接具有更好的灵活性，对于解释性语言更为合适。 

typedef bool(*pConnect)(string ip, int port);HMODULE hMod1 = LoadLibrary(_T("SICK_Communication.dll"));HMODULE hMod2 = LoadLibrary(_T("SICK_FileManagement.dll"));HMODULE hMod3 = LoadLibrary(_T("SICK_LMS5xx-PRO_Library.dll"));HMODULE hMod4 = LoadLibrary(_T("SICKwork.dll"));if (hMod1 == NULL || hMod2 == NULL || hMod3 == NULL || hMod4 == NULL){AfxMessageBox(_T("加载动态链接库失败！"), MB_OKCANCEL | MB_ICONINFORMATION);}else{pConnect fp1 = pConnect(GetProcAddress(hMod1, (LPCSTR)1));if (fp1 != NULL){}else{AfxMessageBox(_T("提取dll中的函数失败！"), MB_OKCANCEL | MB_ICONINFORMATION);}}

显式调用的问题：在DLL文件中，dll工程中函数名称在编译生成DLL的过程中发生了变化（C++编译器），在DLL文件中称变化后的字符为“name标示”。GetProcAddress中第二个参数可以由DLL文件中函数的顺序获得，或者直接使用DLL文件中的”name标示”，这个标示可以通过Dumpbin.exe小程序查看。如果C++编译器下，想让函数名更规范（和原来工程中一样）。

更一般的显式调用

为了解决上部分最后的问题，可以使用 extern “C” 为dll工程中的函数建立C连接，简单的示例工程如下。在DLL创建的工程中，添加cpp文件

#ifdef __cplusplus         // if used by C++ code
extern "C" {                  // we need to export the C interface
#endif__declspec(dllexport) int addfun(int a, int b)
{return a+b;
}#ifdef __cplusplus
}
#endif#include <windows.h>
#include <iostream>
using namespace std;void main()
{typedef int(*FUNA)(int,int);HMODULE hMod = LoadLibrary("cdll.dll");//dll路径if (hMod){FUNA addfun = (FUNA)GetProcAddress(hMod, TEXT("addfun"));//直接使用原工程函数名 if (addfun != NULL){cout<<addfun(5, 4)<<endl;}else{cout<<"ERROR on GetProcAddress"<<endl;}FreeLibrary(hMod);}elsecout<<"ERROR on LoadLibrary"<<endl;
}

然而，以上两种方法都不适用于喵哥的程序，后来发现我的dll是.NET的，C#和VB可以很好的应用，但是喵哥用在VC上是没法实现。主要现象是。

喵哥想生成lib但是，生成的def（其中一个过程）中没有任何函数名，用Dependency也是看不到函数，所以没法转换。所以无法采用隐式调用。

又由于无法看到函数，所以不知道特定函数的指针位置或者函数在dll中的标识，所以显式调用也无法进行。

因此文中的例子是另外一个dll文件，是可以完成这些操作的，但是生成.h文件还是很麻烦。

附

dumpbin和undname是微软vs自带的两个小工具。 前者可以用于查看obj、ilb、dll等文件的符号表，后者可以用于根据Name Mangling之后的字符串反推函数原始声明。 在排查LINK 2019链接错误时，这两个命令较为有用。

参考文献：

https://www.cnblogs.com/woshitianma/p/3681745.html