在C++Builder里创建可以被Visual C++使用的DLL

　在前两篇文章里，我们讨论了如 何在C++Builder工程里调用用MS Visual C++创建的DLL。这篇文章讨论相反的一种情形，举例说明如何用C++Builder创建一个DLL，使它可以在Visual C++工程里调用。

• 简介: 为什么这个这么难
• 指导方针摘要
• 例1: 隐式连接
• 例2: 显式连接
• 例3: 用#define组装隐式连接
• 例4: 用stdcall函数隐式连接
• 结论

简介：为什么这个这么难

　　如果你用BCB创建了一个DLL，它可以被BCB的可执行文件调用，你知道这种使用DLL的方式没什么难度。当你构造一个DLL，BCB生成一 个带“.LIB”扩展名的引入库。把这个LIB文件添加到你的工程里。连接器按引入库决定DLL内部调用。当你运行你的程序时，DLL隐式的被载入，你不 必去考虑DLL内部调用工作是。

　　当EXE文件是由Microsoft Visual C++编译的时候，情况会变得比较复杂。有3个主要的问题。首先，BCB和MSVC对DLL中的函数命名方式是不一致的。BCB使用一种习惯，MSVC使 用另一种不同的习惯。当然，两种习惯是不兼容的。命名问题在如何在C++Builder工程里使用VC++编译的DLL那篇文章里已经讨论过了。表1总结 了各个编译器在各自的调用习惯下，导出的MyFunction函数。注意Borland给__cdecl函数前加了一个下划线，而MSVC没有。另一方 面，MSVC认为导出的__stdcall函数前面带有下划线，后面还有一些垃圾。

表1: Visual C++ and C++Builder 命名习惯

调用习惯  　　　　　VC++命名       VC++(使用了DEF)     C++Builder命名
-----------------------------------------------------------------------
__stdcall           _MyFunction@4   MyFunction          MyFunction
__cdecl             MyFunction      MyFunction          _MyFunction

　　第2个问题是Borland引入库与MSVC不是二进制兼容的。当你编译DLL时，由BCB创建的引入库不能被MSVC用来连接。如果你想使用 隐式连接，那么你需要创建一个MSVC格式的引入库。另一种可选择的办法就是采用显式连接（LoadLibrary和GetProcAddress）。

第3个问题是不能从DLL里导出C++类和成员函数，如果你想让MSVC的用户也可以调用它。好吧，那不完全属实。你的DLL能导出C++类，但是 MSVC不能使用它们。原因就是C++成员函数名被编译器改编（mangled）。这个改编的名字结果了DLL。为了调用在DLL里被改编的函数，你必需 知道被改编的是哪个函数。Borland和Microsoft使用了不同的名字改编方案。结果是，MSVC不能恰好看到Borland编译的DLL里的 C++类和成员函数。

注意: Borland和Microsoft没有采用相同的方式改编函数，因为依照ANSI C++标准，C++编译器不被假定追随相同的指导方针。名字改编只是实现的细节。

　　这三个问题使得Borland创建的DLL可以在MSVC里被调用变得非常困难，但并非不可能的。这篇文章描述了一套指导方针，你可以跟着制作 与Microsoft兼容的BCB DLL。我们讨论四种不同的技术。三种采用引入库隐式连接调用，一种在运行时利用显式连接。

指导方针摘要

　　你可以跟着下面的指导方针摘要列表建造你的DLL。第1个列表讨论隐式连接；第2个列表描述显式连接；第3种技术采用#define组装隐式连 接；最后一个例子利用假的MSVC DLL工程为__stdcall函数创建引入库。

技术1: 隐式连接
------------------------------------------------------------------------------
1- 使用__cdecl调用习惯代替__stdcall。
2- 导出简单的"C"风格函数，没有C++类或成员函数。
3- 确定你有一个 extern "C" {} 包围你的函数原型。
4- 创建DEF文件，包含与Microsoft兼容的导出函数别名。别名也就是不包含前面的下划线。
   DEF文件内容如下:

   EXPORTS
   ; MSVC name    = Borland name
     Foo          = _Foo
     Bar          = _Bar

5- 把DEF文件加入到你的工程里重新编译它。
6- 把DLL和DLL头文件拷贝到你的MSVC工程目录里。
7- 运行impdef为DLL创建第2个DEF文件。这个DEF文件用来创建引入库。
     > impdef mydll.def mydll.dll
8- 运行Microsoft的LIB工具，用上一步创建的DEF文件创建COFF引入库。调用格式为：
     > lib /DEF mydll.def
9- 把用LIB.EXE创建的LIB文件添加到你的MSVC工程里。

技术2: 显式连接
------------------------------------------------------------------------------
1- 使用__cdecl或__stdcall，如果你使用__stdcall可以跳过第4,5步。
2- 导出简单的"C"风格函数，没有C++类或成员函数。
3- 确定你有一个extern "C" {}包围你的函数原型。
4- 如果你使用__cdecl，那么你可能想去掉导出函数前面的下划线，但你不必这么做。你可以用例1的第4,5步去掉下划线。如果你没有去掉下载线，在调用 GetProcAddress函数时函数名必须前面的下划线。
5- 把DLL拷贝到MSVC工程目录里。
6- 在MSVC应用程序中，使用LoadLibrary API函数载入DLL。
7- 调用GetProcAddress API在DLL里查找你想要的调用函数，保存GetProcAddress函数返回的函数指针。当你想调用函数的时候，提取函数指针。
8- 当你用完DLL时调用FreeLibrary。

技术3: 用#define组装隐式连接
------------------------------------------------------------------------------
1- 用__cdecl调用习惯代替__stdcall。
2- 导出简单的"C"风格函数，没有C++类或成员函数。
3- 确定你有一个extern "C" {}包围你的函数原型。
4- 在你的DLL头文件里，为每一个导出函数名创建一个#define。
   #define会调用预编译器在每一个函数名前加上下划线。因为我们只想为MSVC创建别名，所以代码检查_MSC_VER。

     #ifdef _MSC_VER
     #define Foo _Foo
     #define Bar _Bar
     #endif

5- 把DLL和DLL头文件拷贝到MSVC工程目录里。
6- 运行impdef为DLL函数DEF文件。
     > impdef mydll.def mydll.dll
7- 使用Microsoft的LIB工具为DEF文件创建COFF格式的引入库。
     >lib /def mydll.def
8- 把LIB.EXE创建的LIB文件添加到MSVC工程里。

技术4: 用__stdcall函数隐式连接
------------------------------------------------------------------------------
1- 当建造你的DLL时使用__stdcall调用习惯。
2- 导出简单的"C"风格函数，没有C++类或成员函数。
3- 确定你有一个extern "C" {}包围你的函数原型。
4- 为MSVC创建一个引入库。这一部分比较困难。你不能用LIB.EXE为__stdcall函数创建引入库。你必须创建一个由MSVC编译的的假的 DLL。这样做，按这些步骤：
     4a- 用MSVC创建一个不使用MFC的DLL
     4b- 从BCB里拷贝覆盖DLL头文件和DLL源代码
     4c- 编辑你的DLL源代码，抛开每一个例程的函数体部分，使用一个假的返回值返回
     4d- 配置MSVC工程生成的DLL，采用和BCB DLL同的的名字
     4e- 把DEF文件添加到MSVC工程，禁止它对__stdcall命名进行修饰(_Foo@4)
5- 编译第4步得到的虚假DLL工程。这将会生成一个DLL(你可以把它丢到垃圾筒里)和一个LIB文件(这是你需要的)。
6- 把从第5步得到的LIB文件添加到你需要调用这个BCB DLL的MSVC工程里。LIB文件会确保连接。为MSVC可执行文件配置BCB DLL(不是虚假DLL)。

注意: 　　一般情况下，隐式连接比显式连接要优先考虑，因为对程序员来说隐式连接更简单，而且它是类型安全的(错误发生在连接时而不是运行时)。不管用哪 种方法，当你在编译器间共享DLL时，如果你选择坚持使用隐式连接，就必须为每一个编译器创建兼容的引入库。创建兼容的引入库比用显式连增加的负担就是要 注意更多的要求。

 

注意: 　　如果你想使你的DLL可以被Visual Basic的开发者使用，显式连接的指导方针同样适用。如果你想把你的DLL给VC开发者，按显式连接的指导方针，采用__stdcall调用习惯。

 

下面4个部分详细描述每一种技术。

例1: 显式连接

　　这个例子详细描述了上一部分技术1的指导方针。技术1的指针方针可以分为两组。1-5项处理在BCB这边编译DLL；6-9项处理在MSVC这 边使用DLL。我们将沿这条主线分别进行讨论。

　　在这个例子里，我们将用BCB建造一个DLL，它导出两个函数: Foo和Bar。两个函数都返回一个整型值。函数原型为:

int Foo (int Value);
int Bar (void);

然后我们在MSVC里建造一个测试EXE，用来调用Borland DLL。

用BCB编译DLL

　　下面两个程序清单包含我们的DLL源代码。清单1要在BCB和MSVC之间共享的头文件；清单2包含我们的DLL函数实现部分。创建一个BCB DLL工程，从清单1和2中拷贝代码粘贴到工程里。或者你可以下载这篇文章的源代码以节省时间。BCB DLL工程已经为你设置好了。(参见最下面的下载部分)

// ----------------------------------------------
// Listing 1- DLL header file
#ifndef BCBDLL_H
#define BCBDLL_H

#ifdef __cplusplus
extern "C" {
#endif

#ifdef BUILD_DLL
#define IMPORT_EXPORT __declspec(dllexport)
#else
#define IMPORT_EXPORT __declspec(dllimport)
#endif

IMPORT_EXPORT int __cdecl  Foo  (int Value);
IMPORT_EXPORT int __cdecl  Bar  (void);

#ifdef __cplusplus
}
#endif

#endif
// ----------------------------------------------

// ----------------------------------------------
// Listing 2- DLL source code
#include <windows.h>
#pragma hdrstop

#define BUILD_DLL
#include "bcbdll.h"

int __cdecl  Foo  (int Value)
{
    return Value + 1;
}

int __cdecl  Bar  (void)
{
    static int ret = 0;
    return ret++;
}
// ----------------------------------------------

　　关于头文件有两个要注意的地方。首先，观察我们用 extern "C" 的方法确保函数名不会被C++编译器改编；其次，注意到在我们建造DLL时，导出函数有一个特殊指示的前缀__declspec(dllexport)。 当我们从MSVC里使用DLL时，函数前缀变为__declspec(dllimport)。这个指示的改变是通过IMPORT_EXPORT宏定义实现 的。

    最后，注意我们显式声明了__cdecl为调用习惯。技术上，我们可以省略__cdecl关键字，因为__cdecl已经是默认的。但是，我想不管怎样把 它列出来是一个好习惯。通过列出调用习惯，你显式的告诉人们你选择了__cdecl作为一个前提。同样，默认的调用习惯在两个编译器里可以通过编译开关改 变。你肯定不想这些编译器开关影响到你DLL的可用性。

    头文件本身满足了指导方针中的1-3项 。我们需要做的下一件事情是处理第4项: 给导出函数建立别名。

    首先，按现在的情况建造DLL代码。其次，运行TDUMP工具检查函数的函数名确实包含前面的下划线。

c:> tdump -m -ee bcbdll.dll
Turbo Dump  Version 5.0.16.12 Copyright (c) 1988, 2000 Inprise Corporation
                    Display of File BCBDLL.DLL

EXPORT ord:0001='_Bar'
EXPORT ord:0002='_Foo'
EXPORT ord:0003='___CPPdebugHook'

 

注意:     使用TDUMP时别忘了用 -m 开关。TDUMP尝试反改编(unmangle)被修饰的名字，使他们更容易阅读。但是，当你查看一个DLL的时候，明智的选择是查看函数的原始格式。 -m 开关告诉TDUMP显示原始函数名。

    像你看到的那样，Foo和Bar都包含前端下划线。至于__CPPdebugHook，你可以不理它，它是幕后操纵的，当它不存在好了。它对你没什么意 义，你也不能让它走开，因此就不要把它放在心上了。

    为了用别名去掉下划线，我们需要做三件事：首先创建DLL的DEF文件；然后调整DEF文件，为Borland名字创建MSVC的别名；最后，把DEF文 件添加到你的BCB工程里，重建DLL。

    要创建DEF文件，对DLL运行Borland的IMPDEF工具。

C:> impdef bcbdllx.def bcbdll.dll

    我选择bcbdllx.def为文件名，因为稍后(在我们创建MSVC引入库之前)我们将使用其它DEF文件。我想避免两者混淆。bcbdllx.def 内容如下:

LIBRARY     BCBDLL.DLL

EXPORTS
    _Bar                           @1   ; _Bar
    _Foo                           @2   ; _Foo
    ___CPPdebugHook                @3   ; ___CPPdebugHook

    注意到在Foo和Boo前端的下划线。如果DLL把Foo和Bar导出为_Foo和_Bar，当MSVC用户设法建造他们的工程的时候，将看到连接错误。 我们需要剥去下划线。我们用在DEF文件里给函数别名的方法实现。

    DEF文件别名允许我们为真实的函数导出担当代理或占位符的函数名。在DLL里的真实的函数仍然是_Foo和_Bar。代理名将是Foo和Bar(注意没 有了下划线)。当我们给两个函数别名的时候，DLL将导出两个将的符号，它们归诸于原来的函数。

    完成别名， 编辑DEF文件，改变成下面的样子:

LIBRARY     BCBDLL.DLL

EXPORTS
    Bar = _Bar
    Foo = _Foo

    这个DEF文件创建两个新的出口，Foo和Bar，它们分别担当_Foo和_Bar的点位符。把这个DEF文件保存到你的硬盘上。一旦你完成了这些工作， 便可以把DEF文件添加到你的BCB工程里，使用Project-Add菜单项。添加后，BCB会在工程管理器(Project Manager)的树状结构里显示出DEF文件。

    一旦你把DEF文件加入到工程里，做一次完全的重建。工程连接好之后，再次对DLL运行TDUMP，检查从DLL里导出的带下划线函数。

>tdump -m -ee bcbdll.dll
Turbo Dump  Version 5.0.16.12 Copyright (c) 1988, 2000 Inprise Corporation
                    Display of File BCBDLL.DLL

EXPORT ord:0004='Bar'
EXPORT ord:0005='Foo'
EXPORT ord:0002='_Bar'
EXPORT ord:0001='_Foo'
EXPORT ord:0003='___CPPdebugHook'

    对TDUMP的输出有两点要注意的事情要注意。首先，观察Foo和Bar到场了(没有前端下划线)。现在DLL导出函数名与MSVC的一致了。还注意到原 来的函数，_Foo和_Bar，还在那儿。被修饰过的函数仍就从DLL里导出。使用DEF文件别名并不隐藏原来的函数。

    你可能会想把这原来的两个函数用什么办法隐藏起来。但是，这么做将会危害到从BCB工程里使用DLL的人们。记得BCB的连接器期望在那儿有一个前端下划 线。如果你真的用了什么方法从DLL里把_Foo和_Bar隐藏了(以我的知识是不可能实现的)，那么你的DLL从BCB里调用将变得非常困难。

    如果TDUMP的输出没有列出代理函数(不带下划线的函数)，那么返回上一步，检查你的DEF文件。在你可以继续之前，你需要得到别名的出现。如果DLL 看起来OK了，那么该是转到MSVC这边的时间了。

从MSVC里调用DLL

    一旦你拥有了一个被反改编__cdecl函数出口的DLL模型，下一步就是要为MSVC用户生成一个引入库。为这，你将需要刚刚创建的DLL，使用 Borland的IMPDEF实用工具(再一次)，和来自MSVC的LIB.EXE工具。第一步是创建DLL的DEF文件。为这，我建议你拷贝DLL和 DLL头文件到你的MSVC工程目录里，在那儿工作。

C:> impdef bcbdll.def  bcbdll.dll

IMPDEF将创建一个DEF文件，内容如下：

C:> impdef bcbdll.def  bcbdll.dll

LIBRARY     BCBDLL.DLL

EXPORTS
    Bar                            @4   ; Bar
    Foo                            @5   ; Foo
    _Bar                           @2   ; _Bar
    _Foo                           @1   ; _Foo
    ___CPPdebugHook                @3   ; ___CPPdebugHook

打开DEF文件，改变它的内容为：

LIBRARY     BCBDLL.DLL

IMPORTS
    Bar                            @4   ; Bar
    Foo                            @5   ; Foo

    注意到我们移除了包含下划线的函数，和调试钩挂(debug hook)函数。我们还把EXPORT改成了IMPORTS，因为我们现在是在引入函数，而不是导出它们(我怀疑它对MSVC LIB.EXE来说会产生不同)。

    下一步，我们用Microsoft LIB.EXE，从DEF文件那儿创建一个COFF格式的库。语法为：

lib /DEF:bcbdll.def /out:bcbdll_msvc.lib

 

注意:     MSVC命令行实用工具在默认情况下不在你的配置的路径里。你可能需要运行一个MSVC带的批处理文件，使得LIB.EXE可以被直接调用。批处理文件叫 做VCVARS32.BAT，它位于DevStudio安装路径的\VC\BIN子目录下。

    这里，所有艰苦的工作都做完了。现在你需要做就是把你的DLL，MSVC LIB文件，和DLL文件件加入到你的MSVC客户端。要使用DLL，需要添加LIB文件到MSVC工程里，并且在源代码内#include DLL头文件。

    我准备了一个MSVC的简单工程来证明上面的概念。清单3给出客户端DLL的源代码。没什么特别的地方，就是一个main函数，一个DLL头文件 的#include，和对DLL的几个函数调用。主要是你正确的添加了引入库，由LIB.EXE生成的那个，添加到MSVC工程里。

// ----------------------------------------------
// Listing 3- MSVC DLL client code
#include <iostream>
#include <windows.h>
using namespace std;

#include "bcbdll.h"

int main()
{
    cout << "Foo(10) = " << Foo(10) << endl;
    cout << "Bar()   = " << Bar() << endl;
    cout << "Bar()   = " << Bar() << endl;
    cout << "Bar()   = " << Bar() << endl;
    return 0;
}
// ----------------------------------------------

例2:显式连接

    这个例子向你展示了如何从MSVC里使用显式连接调用BCB编译的DLL。用显式连接，你不必摆弄创建一个MSVC兼容的引入库。显示连接不利的是它需要 在用户端做更多的工作，它不及隐式连接类型安全，错误被延期到运行时而不是连接时。虽然显式连接有许多不利因素，但在某些情况下它还是十分有用的。

    在这个例子里，我们将创建一个DLL，它导出两个函数：Foo和Bar。函数的原型同上一个例子一样。

int Foo (int Value);
int Bar (void);

    这一显式连接的指导方针与隐式连接的相仿。我们需要导出简单的C函数，需要防止C++名字改编。如果我们用__cdecl调用习惯，那么我们可能想要为 BCB导出的函数建立别名，以去掉它们前端的下划线。如果我们选择不用别名去掉下划线的方法，那么当按名字载入函数时，我们必须包含下划线。换句话说，当 你对__cdecl函数起作用时，你必须在某几点上处理下划线。你也可以在BCB建造DLL的时候处理下划线，或者在运行时调用DLL时处理它。我们利用 __stdcall代替__cdecl以回避整个讨论的下划线问题。这是我们在这个例子里要做的。清单4和5给出的我们DLL的源代码。

注意:     如果你导出__stdcall函数，至关紧要的是要让客户端应用程序知道。一些人容易犯一个错误，认为使用__stdcall只不过是去掉了 __cdecl函数前面的下划线。别掉进这个陷井。__stdcall函数处理堆栈方式也__cdecl是不同的。如果客户端应用程序把 __stdcall当作__cdecl函数调用(也就是，堆栈将被破坏，客户端程序会死得很难看)，将要发生一些错误。

// ----------------------------------------------
// Listing 4- DLL header file
#ifndef BCBDLL_H
#define BCBDLL_H

#ifdef __cplusplus
extern "C" {
#endif

#ifdef BUILD_DLL
#define IMPORT_EXPORT __declspec(dllexport)
#else
#define IMPORT_EXPORT __declspec(dllimport)
#endif

IMPORT_EXPORT int __stdcall Foo  (int Value);
IMPORT_EXPORT int __stdcall Bar  (void);

#ifdef __cplusplus
}
#endif

#endif
// ----------------------------------------------

// ----------------------------------------------
// Listing 5- DLL source code
#include <windows.h>

#define BUILD_DLL
#include "bcbdll.h"

int __stdcall  Foo  (int Value)
{
    return Value + 1;
}

int __stdcall Bar  (void)
{
    static int ret = 0;
    return ret++;
}
// ----------------------------------------------

    注意这段代码几乎与隐式连接的一模一样。唯一不同的地方就是把Foo和Bar的调用习惯改成__stdcall代替__cdecl。

    现在让我们看一下调用DLL的MSVC程序代码。代码如清单6所示。

// ----------------------------------------------
// Listing 6- MSVC client code
#include <iostream>
#include <windows.h>
using namespace std;

HINSTANCE hDll = 0;
typedef int (__stdcall *foo_type)  (int Value);
typedef int (__stdcall *bar_type)  ();
foo_type Foo=0;
bar_type Bar=0;

void DLLInit()
{
    hDll = LoadLibrary("bcbdll.dll");
    Foo = (foo_type)GetProcAddress(hDll, "Foo");
    Bar = (bar_type)GetProcAddress(hDll, "Bar");
}

void DLLFree()
{
    FreeLibrary(hDll);
}

int main()
{
    DLLInit();

    cout << "Foo() = " << Foo(10) << endl;
    cout << "Bar() = " << Bar() << endl;
    cout << "Bar() = " << Bar() << endl;
    cout << "Bar() = " << Bar() << endl;
    DLLFree();
    return 0;
}
// ----------------------------------------------

    这段代码片段里有许多需要消化的地方。首先也是最重要的，观察代码本身是编译器中立的。你可以在BCB或MSVC里编译它。我首先在BCB里编译它，确信 它可以按我所想的工作。

    第二，注意到代码没有为#include bcbdll.h操心。有一个重要的原因。bcbdll.h为Foo和Bar函数定义的原型。但是，我们不把我们的代码同任何预先定义的那些原型连接。通 常，这些原型的存根来自引入库。但是这个例子示范的是显式连接，当你显示地连接时，是不使用引入库的，在头文件里的Foo和Bar原型对我们来说没多大意 义。

    第三件要注意的事情是关于这段代码里出现的typedef和函数指针，位于源文件的顶部附近。晃式连接需要你在运行时用API GetProcAddrress得到DLL函数的地址。你必须把GetProcAddress返回的结果存储到某个地方。最好的地点是把结果存储到函数指 针里。通过把函数地址存储到函数指针里，你可以使用正常的函数调用语法调用函数(如 Foo(10))。

    typedef声明创建了两个新的类型: foo_type和bar_type。它们都是函数指针类型。foo_type声明了一个指向__stdcall函数的类型，这个函数打官腔一个整型参 数，返回一个整型值。bar_type定义了一个指向__stdcall类型的、没有参数、有一个整型返回值的函数。这些typedef产生了两个效果。 第一，它们提供了清晰的方式来声明函数指针变量Foo和Bar。第二，它们使我们可以很方便的转换GetProcAddress返回的结果。从 GetProcAddress返回的结果是一个指向__stdcall类型的、没有参数、有一个整型返回值的函数。除非你的函数与这个格式相同，否则你需 要转换GetProcAddress的结果(这个转换是显式连接比隐式连接缺管类型安全的原因)。

    在typedef的下面有两个变量Foo和Bar。这两个是函数指针变量。它们会保存我们想要调用的两个函数的地址。注意这些变量的名字是任意的。我选择 Foo和Bar是为了使代码像隐式连接。不要犯这样的错误，Foo和Bar变量名没有与DLL里的真实函数建立连接。我们可以把变量命名为Guido和 Bjarne，如果你想的话。

    在函数指针声明下面，你会看到两个叫DllInit和DllFree的函数实体。这两个实体处理载入DLL，查找导出函数，和在我们使用赛后释放程序库。 用这种方法，其余的代码不知道DLL是显式连接的。它可以像往常一样调用Foo和Bar(或者Guido和Bjarne，如果你改变了名字)。唯一要协调 的是你必须在调用任何DLL程序之前调用DllInit。我们也应当细致的，调用DllFree释放程序库。

注意:     当在命名总题上Borland编译器和Microsoft编译器之间大战之时，GetProcAddress是你的最后一道防线。这包括Borland __cdecl命名带一个前端下划线(如 _Foo)。也包括改编C++名字。如果有人支持你用改编函数名字的DLL，你可以永远传递这些难看的参数，把改编名字给GetProcAddress。 不管你实际上你能调用函数而没碰到其它的什么问题，但是至少你将会有一个机会。

    这就是全部。在MSVC里编译代码，你就完成了。你不必摆弄DEF文件或是引入库。但是在你这边的代码里有些琐碎的工作要处理。

例3: 用#define组装隐式连接

    这个例子展示了可能是从MSVC工程里调用BCB DLL最简单的一种方法，但它也可能是最没有吸引力的一种方法。代码使用一个狡诈的#define，当检查到是Microsoft编译器时给 __cdecl函数前加上下划线。也就是说，我们简单的#define了Foo为_Foo。

    这种技术的优势在于我们不必实行任何别名。 我们能直接导出包含下划线的__cdecl函数。但是，我们仍就必须用Microsoft的LIB.EXE创建一个MSVC兼容的引入库。

    这种技术是关键是MSVC不期望__cdecl函数有任何的修饰(见表1)。它们应当和看起来一样。 如果MSVC应用程序试图执行一个__cdecl函数Foo，它期望在DLL里查找一个没有下划线的函数Foo。如果我们改变MSVC的代码，让它调用 _Foo，那么它将试图在DLL里查找一个叫做_Foo的函数。

    Borland给__cdecl函数前加上了下划线。我们可以哄骗MSVC，让它在调用函数的时候在函数名的前面加一个下划线。紧记我们只想在MSVC这 边添加一个下划线，而不是Borland这边。

    #define组装的DLL代码与例1里清单2的代码完全一样。唯一不同的是DLL头文件。当检测到是MSVC时，DLL头文件为每一个函数原型加一个下 划线。清单7展示了修改后的头文件。

// ----------------------------------------------
// Listing 7- DLL header file
#ifndef BCBDLL_H
#define BCBDLL_H

#ifdef __cplusplus
extern "C" {
#endif

#ifdef BUILD_DLL
#define IMPORT_EXPORT __declspec(dllexport)
#else
#define IMPORT_EXPORT __declspec(dllimport)
#endif

// #define kludge. If we are being compiled with MSVC, then just tack on a
// leading underscore because Borland C++ will export Foo and Bar as _Foo
// and _Bar respectively
#ifdef _MSC_VER
#define Foo _Foo
#define Bar _Bar
#endif

IMPORT_EXPORT int __cdecl  Foo  (int Value);
IMPORT_EXPORT int __cdecl  Bar  (void);

#ifdef __cplusplus
}
#endif
#endif
// ----------------------------------------------

    在头文件里，除#define组装之外，你还必须创建一个MSVC兼容的引入库。你可以按前面的步骤完成。对编译好的DLL运行IMPDEF，得到一个 DEF文件。然后运行Microsoft LIB.EXE工具创建一个COFF格式的引入库。这时，你不必考虑去编辑DEF文件。最后，拷贝DLL，COFF引入库，和DLL文件件到你的MSVC 工程里。把LIB文件添加到你的MSVC工程里，重建。

    这是创建MSVC引入库的命令行例子。注意我们不必编辑DEF文件。我们刚好可以把它传递给LIB.EXE。

// Create def file
> impdef bcbdll.def bcbdll.dll

// create COFF import library using MS lib.exe
>lib /def bcbdll.def

例4: 用__stdcall函数隐式连接

    在我们进行之前，让我们调查一下为什么我们需要单独论述__stdcall函数。MSVC没有提供与Borland的IMPLIB相当的工具。你不能攫取 DLL，生成一个MSVC可用的引入库。最接近的工具是LIB.EXE，它可以通过一个DEF文件创建一个引入库。DEF文件必须是手动创建，或利用 Borland的IMPDEF工具生成的。

    没什么大不了的啊？你仍能创建MSVC引入库，只是必须通过中间步骤创建一个DEF文件，然后把它传递给LIB.EXE工具。正确的，在你采用 __cdecl函数的时候。当你转到__stdcall的时候，问题就发生了。问题是Microsoft的LIB.EXE工具为导出__stdcall函 数的DLL生成引入库显得无能为力。

    因为这个原因，我把用__stdcall隐式连接分离出来作为它自己的一部分。我们需要跟着一个不同步骤的次序来创建Microsoft兼容的引入 库。(同样注意到我把这部分放到最后的好理由，至少这些步骤是冗长乏味的)。

    既然我们不能用LIB.EXE为用__stdcall的BCB DLL生成引入库，那我们需要提出一种不同的策略。有一种生成引入库的方法(可能是唯一的方法)，依靠只要你建造一个DLL的，MSVC就可以生成一个引 入库这一事实。如果你建造一个包含__stdcall函数的MSVC DLL，编译器和连接器会正确的分解导出的__stdcall函数，生成引入库。

     那么你会问它会怎么帮助我们呢？毕竟，我们正在用Borland C++编译DLL。在MSVC里创建一个DLL工程有什么好处？我们想让EXE用MSVC编译，但是DLL应当保持在BCB这边。这个问题的答案是我们在 MSVC里编译虚假DLL工程，唯一的目的是生成一个__stdcall的引入库。由MSVC创建的DLL可以被丢到垃圾筒里。我们不需要它。

    这种技术是建立在虚假DLL工程的基础之上的。我们在MSVC里创建一个虚假DLL工程，就是得到生成Microsoft兼容的引入库的好处。于是我们可 以把这个引入库和BCB生成的DLL相结合，再提供给MSVC用户，使得他们可以调用我们的带有__stdcall函数的Borland DLL。

    这是这种技术所必须的几步。首先，用BCB编译你的DLL。用__stdcall调用习惯，导出简单的C函数，用extern "C"包装所有的声明。DLL的代码与例2中清单4和5的代码相同，因此我不把它们再列出来了。第二步是在MSVC里创建虚假DLL工程。编译虚假DLL 工程，盗取生成的引入库。最后一步是把这个引入库添加到任一想要调用Borland DLL的MSVC工程里。

    这一技术最有挑战兴趣的是围绕虚假DLL工程和引入库的基因。建造一个虚假DLL工程，用MSVC创建一个non-MFC DLL工作区。编辑MSVC工程设置，以便使生成DLL的函数与BCB DLL的名字相匹配(在我们的例子里是bcbdll.dll)。这个设置可以在Project-Settings-Link下 找到。从Borland工程目录里拷贝你的DLL头文件源代码到虚假DLL工程目录。如果你的工程由多个CPP文件组成，那么只需拷贝包含导出声明的头文 件。把CPP源代码文件添加到虚假工作区。

    下一步，进入每一个导出函数的定义，删除每个函数实体的代码。以一堆空函数告终。如果函数有返回值，在适当的位置保留返回语句。只是一些虚假的返回值(比 如0)。除丢弃函数体之外，移除任何不必要的#include语句(你应当可以移大部分#include，因为所有的函数体都是空的)。

    我们的BCB DLL与例2的清单4和5包含同样的代码。 清单8展示了同样的代码被修整下来后的版本。这个修整下来后的版被添加到虚假DLL工作区。

// ----------------------------------------------
// Listing 8- dummy DLL source code
#define BUILD_DLL
#include "bcbdll.h"

int __stdcall  Foo  (int Value)
{
    return 0;
}

int __stdcall Bar  (void)
{
    return 0;
}
// ----------------------------------------------

    这时，我们应当可以在MSVC里编译虚假DLL工作。但是在我们编译之前，我们必须再实行一步，以抗击Microsoft编译器的一些特性。我们的虚假 DLL导出__stdcall函数。当Microsoft DLL导出__stdcall函数时，通常都给函数名做了修饰，添加了前端下划线，附加了'@'符号和一个数字的结尾(见文章开始处的表1)。例 如，Foo将被导出为_Foo@4。这不是我们想要的行为。虚假DLL的全部的目的就是为我们的BCB DLL生成MSVC引入库。我们的BCB DLL包含简单的、没有下划线的、__stdcall函数(Foo和Bar)。它没有给生成引入库带来任何好处，因为与修饰的名字(_Foo@4和 _Bar@0)不匹配 DLL包含简单的、没有下划线的、__stdcall函数(Foo和Bar)。它没有给生成引入库带来任何好处，因为与修饰的名字(_Foo@4和 _Bar@0)不匹配。

    幸运地，我们可以防止MSVC修饰虚假__stdcall函数，方法是添加一个DEF文件到虚假DLL工程里。DEF文件简单的列出每一个要导出的函数。 内容如下：

LIBRARY     BCBDLL.DLL

EXPORTS
    Bar
    Foo

注意:     在DEF文件里的程序库名应当与由MSVC生成的虚假DLL名字相匹配，而它转而应当与用BCB创建的DLL名字相匹配。如果这三项不匹配，那么你会运行 出各种不同的错误(通常是未解决的连接器错误)。

    把DEF文件添加到虚假DLL工程里，建造虚假DLL。当MSVC建造DLL工程的时候，它会创建一个引入库。这个引入库是让MSVC用户可以用隐式连接 的方式调用导出__stdcall函数的BCB DLL的关键因素，把它连同你的DLL一起提供给MSVC用户。你的用户应当把这个引入库添加到任何调用你的BCB DLL的MSVC工程里。

结论

    这篇文章提供了四种技术，让Microsoft Visual C++可以调用由BCB编译的DLL。我希望这篇文章把每一种技术描述的很充分(这些内容有的不太容易理解)。为了帮助你理解每一种技术，我为每一种可代 利用的技术制作了例子代码，可以从这儿下载。zip文件解压出四个子目录，一个对应一种技术。每一个子目录包含一个用BCB5 DLL工程的DLL目录，和一个用来调用BCB DLL的MSVC工程的EXE目录。MSVC工程是VC++ 5工程，但它们应当可以在MSVC 6下正常的工作。