浅析C++Builder调用Visual C++ DLL

使用C++Builder调用Visual C++ DLL 创建的DLL不会比调用C++Builder 建造的DLL 难，首先，Borland 和 Microsoft 在 OBJ 和引入库的文件格式上不同Visual C++ 使用 COFF 库格式，而 Borland 使用 OMF 格式。

这就意味着你不能把一个 Microsoft 生成的引入库添加到C++Builder 的工程里。感谢 Borland IMPLIB 这个实用工具，文件格式的不同得以克服。
两个产品在连接名字（linker name）习惯上也不同。

这是 C++Builder 调用 Visual C++ DLL 的主要障碍。在 DLL 或 OBJ 里的每一个函数有一个连接名字。连接器用连接名字在连接期间解决（resolve）声明了原型的函数。如果连接器不能找到它认为是程序需要的连接名字的函数，它将产生一个未解决的外部错误（unresolved external error）。

关于函数连接名字，Borland 和 Microsoft 在下面两点上不同：
1- Visual C++有时修饰导出的 __stdcall 函数。
2- Borland C++Builder 在引入这个被修饰的函数时，认为是 __cdecl 函数。

那么，这件事为什么这样重要呢？拿分歧#1 __stdcall 调用习惯来说。如果你用 Visual C++ 创建了一个 DLL，它包含一个 __stdcall 修饰的函数叫做 MyFunction()，Visual C++ 将给函数一个连接名字，为 _MyFunction@4。当 Borland 连接器设法解决调用构造这个函数的时候，它认为要找一个名为 MyFunction 的函数。因为 Visual C++ DLL 引入库不包含叫作 MyFunction 的函数，Borland 连接器报告一个未解决的外部错误，意识是没有找到函数。

解决这三个问题的方法要依赖 Visual C++ DLL 的编译方式。我把整个过程分为二步。
第1步：识别在 Visual C++ DLL 里使用的调用习惯为了与命名习惯缠结交战，你必须首先确定在 DLL 里函数使用的调用习惯。你可以通过查看 DLL 的头文件来确定。在 DLL 头文件里的函数原型形式如下

第2步：检查 DLL 里的连接名字如果在第 1 步中显示 DLL 利用 __stdcall 调用习惯，你需要进一步检查 DLL，确定 Visual C++ 在创建它时采用的命名习惯。Visual C++ 默认情况下要修饰 __stdcall 函数，但如果写这个 DLL 的程序员在他们的工程里增加一个 DEF 文件，可以阻止命名修饰。如果供应商没有使用 DEF 文件，你的工会稍微繁琐一些。
命令行工具 TDUMP 允许你检查 DLL 导出函数的连接名字。下面向 DLL 调用 TDUMP 的命令。

TDUMP 能报告许多关于 DLL 的信息。我们仅对 DLL 的导出函数感兴趣。-ee 命令选项指示 TDUMP 仅列出导出信息。-m 开关告诉 TDUMP 按 DLL 函数的原始格式显示。如果没有 -m 开关，TDUMP 将尝试把修饰过的函数转化为人们易读的格式。如果 DLL 很大的话，你应该重定向 TDUMP 的输出到一个文件里（通过附加的 > MYDLL.LST）。

TDUMP 为源程序清单 A 和 B 的测试 DLL 输出如下：