技术小记3(dll)

在VC中，若用了__declspec(dllexport )   ，就可不用.DEF文件了。.DEF文件主要用于指定程序的输入。 
对于C++程序动态链接库，一般都要加上extern   "C "，以便能为C所调用。
DEF文件定义你么输出的函数映射，这是属于老式程序的方式；现在，如果已经在源文件的函数定义中加了__declspec(dllexport)，就不需要
在DEF文件中在定义了。

2.
#define _DLL_EXPORT //应该写在这吗？

#ifdef _DLL_EXPORT
#define DLLAPI __declspec(dllexport)
#else
#define DLLAPI __declspec(dllimport)
#endif

#ifdef __cplusplus
extern "C" {
#endif
//1.注意DLLAPI顺序，否则DLL会到不出该函数
DLLAPI char*  GetTestValue(); 
DLLAPI int  GetIntValue();


#ifdef __cplusplus
}
#endif


3.dll返回的堆对象的指针调用程序可以使用，但不能删除，反过来也是一样的,否则崩溃

网上找到的一个解释:

主要是由于CRT库造成的，重载new/delete，不使用malloc/free分配内存，换成RtlAllocateHeap之类的

dll中可能调用了类似malloc的CRT函数来分配内存，由于CRT本身的原因不允许跨模块释放

 调用程序给dll传递一个局部变量，dll依然可以使用

跨进程传递std::string参数会崩溃

此是老问题了，即跨module（exe、dll）间申请/释放内存违例的问题，对发生在传递c++对象并使用时，不仅仅发生在std::string上

原因是由于程序中使用的内存管理多来源于crt提供的例程，而非直接使用操作系统的接口，这些例程都需要维护一些module全局数据（例如维护池、维护空闲块、或者标记已申请的块等等，不同的实现中有不同的作用），当他们被静态连编时，实际上这些“全局数据”就不“全局”了，不同的module各自为政，每份module都有自己的“全局数据”，自身的内存信息不为他人所知，module A的合法内存快自然不可能通得过module B的合法性验证

解决问题的方法有：
1、不要跨module传递c++对象，或者避免释放跨module申请的内存

2、将参与合作的module统统以multithreaded dll方式链入crt库，让他们的“全局”数据真正全局，注意，所有有交互的module都需要动态链入crt，

不推荐第二种方式

4.DllMain()所在文件不需要包含DLL导出头文件 

也就是说只要有(extern "C") _declsepc(dllexport), 放在任何一个地方都可以，简单的就是直接写在dllmain下面了

5.导出类

若完全导出类，则类的函数都要导出，调用者需要知道类的全部，这种方式不好，可以换位导出接口函数，内部实现内部类的工作。

（这种情况下用#pragma comment(lib, "dll.lib")）的方式调用

6.为什么要用extern "C"

C++没有Name-Mangling的方案，各个编译器的规则也不同，调用方式也导致Name-Mangling不同

如：如extern “c” __stdcall的调用方式就会在原来函数名上加上写表示参数的符号，而extern “c” __cdecl则不会附加额外的符号。

dll中的函数在被调用时是以函数名或函数编号的方式被索引的，如果不用extern "C",则导出函数名被修改，调用GetProcAddress将无法查找到该函数

所以一般情况下需要确保dll’里的函数名是原始的函数名。分两步：一，如果导出函数使用了extern”C” _cdecl，那么就不需要再重命名了，这个时候dll里的名字就是原始名字；如果使用了extern”C” _stdcall，这时候dll中的函数名被修饰了，就需要重命名。二、重命名的方式有两种，要么使用*.def文件，在文件外修正，要么使用#pragma，在代码里给函数别名。

7.dllimport

_declspec(dllexport)很有必要 _declspec(dllimport)却不是必须的，但是建议这么做。因为如果不用_declspec(dllimport)来说明该函数是从dll导入的，那么编译器就不知道这个函数到底在哪里，生成的exe里会有一个call XX的指令，这个XX是一个常数地址，XX地址处是一个jmp dword ptr[XXXX]的指令，跳转到该函数的函数体处，显然这样就无缘无故多了一次中间的跳转。如果使用了_declspec(dllimport)来说明，那么就直接产生call dword ptr[XXX]，这样就不会有多余的跳转了

8.__stdcall带来的影

 这是一种函数的调用方式。默认情况下VC使用的是__cdecl的函数调用方式，如果产生的dll只会给C/C++程序使用，那么就没必要定义为__stdcall调用方式，如果要给Win32汇编使用（或者其他的__stdcall调用方式的程序），那么就可以使用__stdcall。这个可能不是很重要，因为可以自己在调用函数的时候设置函数调用的规则。像VC就可以设置函数的调用方式，所以可以方便的使用win32汇编产生的dll。不过__stdcall这调用约定会Name-Mangling，所以我觉得用VC默认的调用约定简便些。但是，如果既要__stdcall调用约定，又要函数名不给修饰，那可以使用*.def文件，或者在代码里#pragma的方式给函数提供别名（这种方式需要知道修饰后的函数名是什么）。
举例：
·extern “C” __declspec(dllexport) bool  __stdcall cswuyg();
·extern “C”__declspec(dllimport) bool __stdcall cswuyg();
·#pragma comment(linker, "/export:cswuyg=_cswuyg@0")

9.

*.def文件的用途

指定导出函数，并告知编译器不要以修饰后的函数名作为导出函数名，而以指定的函数名导出函数（比如有函数func，让编译器处理后函数名仍为func）。这样，就可以避免由于microsoft VC++编译器的独特处理方式而引起的链接错误。

也就是说，使用了def文件，那就不需要extern “C”了，也可以不需要__declspec(dllexport)了（不过，dll的制造者除了提供dll之外，还要提供头文件，需要在头文件里加上这extern”C”和调用约定的，因为使用者需要跟制造者必须遵守同样的规则）。

举例def文件格式：

LIBRARY  XX(dll名称这个并不是必须的，但必须确保跟生成的dll名称一样)

EXPORTS

[函数名] @ [函数序号]

 

编写好之后加入到VC的项目中，就可以了。

       另外，要注意的是，如果要使用__stdcall，那么就必须在代码里使用上__stdcall，因为*.def文件只负责修改函数名称，不负责调用约定。

也就是说，def文件只管函数名，不管函数平衡堆栈的方式。

 

如果把*.def文件加入到工程之后，链接的时候并没有自动把它加进去。那么可以这样做：

手动的在link添加：

1）工程的propertiesàConfiguration PropertiesàLinkeràCommand Lineà在“Additional options”里加上：/def:[完整文件名].def

2）工程的propertiesàConfiguration PropertiesàLinkeràInputàModule Definition File里加上[完整文件名].def

 

注意到：即便是使用C的名称修饰方式，最终产生的函数名称也可能是会被修饰的。例如，在VC下，_stdcall的调用方式，就会对函数名称进行修饰，前面加‘_’，后面加上参数相关的其他东西。所以使用*.def文件对函数进行命名很有用，很重要。

动态装入dll，重命名（*.def）的必要性？

因为导出的函数尽可能使用__stdcall的调用方式。而__stdcall的调用方式，无论是C的Name Mangling，还是C++的Name Mangling都会对函数名进行修饰。所以，采用__stdcall调用方式之后，必须使用*.def文件对函数名重命名，不然就不能使用GetProcAddress()通过函数名获取函数指针。

 

2、隐式调用时，头文件要注意的地方？

因为使用静态装入，需要有头文件声明这个要被使用的dll中的函数，如果声明中指定了__stdcall或者extern “C”，那么在调用这个函数的时候，编译器就通过Name Mangling之后的函数名去.lib中找这个函数，*.def中的内容是对*.lib里函数的名称不产生作用，*.def文件里的函数重命名只对dll有用。这就有lib 跟dll里函数名不一致的问题了，当并不会产生影响。DLL的制造者跟使用者采用的是一致函数声明。

 

3、所以到底要不要使用__stdcall 呢？

我看到一些代码里是没有使用__stdcall的。如果不使用__stdcall，而使用默认的调用约定_cdecl，并且有extern ”C”。那么VC是不会任何修饰的。这样子生成的dll里的函数名就是原来的函数名。也就可以不使用.def文件了。

也有一些要求必须使用__stdcall，例如com相关的东西、系统的回调函数。具体看有没有需要。

 

 

4、导出函数别名怎么写？

可以在.def文件里对函数名写一个别名。

例如：

EXPORTS

cswuygTest（别名） = _showfun@4(要导出的函数)

 

或者：

#pragma comment(linker, "/export:[别名] =[NameMangling后的名称]")

 

这样做就可以随便修改别名了，不会出现找不到符号的错误。

 

5、用不用*.def文件？

如果采用VC默认的调用约定，可以不用*.def文件，如果要采用__stdcall调用约定，又不想函数名被修饰，那就采用*.def文件吧,另一种在代码里写的重命名的方式不够方便。

6、什么情况下（不）需要考虑函数重命名的问题？

1）、隐式调用（通过lib）

如果dll的制造者跟dll的使用者采用同样的语言、同样编程环境，那么就不需要考虑函数重命名。使用者在调用函数的时候，通过Name Mangling后的函数名能在lib里找到该函数。

如果dll的制造者跟dll使用不同的语言、或者不同的编译器，那就需要考虑重命名了。

2）、显示调用（通过GetProcessAddress）

       这绝对是必须考虑函数重命名的。