问题标签 [name-decoration]

在我的公司，我们使用.def文件来指定需要导出的符号。（我希望我可以使用更现代和自动化的技术，不幸的是，那些决定生活在八十年代的人）。

写一个.def文件，使用手动复制粘贴既无聊又容易出错，但到目前为止我可以忍受它。

但是，我需要为.defDLL 的 64 位版本编写一个类似的文件。几个函数的名称装饰发生了变化，我想知道是否有一种方法可以.def从 32 位版本生成 64 位版本的文件。

您知道任何可能对我有帮助的工具吗？这甚至是现实的吗？我真的不想再手动一次了。欢迎任何解决方案，即使是涉及编写我自己的工具的解决方案。

谢谢你。

一般来说，我观察到nm在 Linux 上使用的是T符号名称（我感兴趣）在不同的计算机上保持一致，即使我不使用extern "C". 我的观察正确吗？

注意我在所有计算机上都使用 gcc。

使用 depends ，我发现即使使用extern "C".

首先，我创建了一个名为 的简单 dll SimpleDll.dll，它的头文件：

它的源代码：

然后我在另一个项目中调用它，它工作正常：

但是，当我打电话GetProcAddress获取它的地址时，它不起作用！

谢谢你的帮助。（PS：我在 Windows7 上使用 VS2010）
更新：
这是文件的依赖行者显示的SimpleDll.dll内容：

我想使用Windows API 的 PatchAPI来应用一些补丁。补丁的应用是在 mspatcha.dll 中实现的，它应该位于一个人的 system32 文件夹中。

在阅读了各个地方（例如他们的 ref 和谷歌搜索）之后，我还没有找到链接到这个 DLL 的正确方法。我想静态链接，处理 LoadLibrary 似乎很混乱，有点违背了他们的 patchapi.h 标头的目的。由于我没有找到要链接的 .lib 文件，因此我使用以下命令创建了自己的文件：

1) 转储箱 /exports C:\windows\system32\mspatcha.dll

2) 创建一个 mspatcha.def 文件，写一个“EXPORTS”行，然后为出现在 dumpbin 输出中的每个函数名写一行

3) 库 /def:mspatcha.def /out:mspatcha.lib

虽然我确定这不是与 patchapi 进行静态链接的正确方法，但我还没有找到正确的方法。无论如何，在执行了这些步骤并编写了一个由单个调用 ApplyPatchToFileExA() 构成的简单测试用例之后，我仍然在符号 _ApplyPatchToFileA@16 上收到链接器错误。查看我新创建的 mspatcha.lib 的导出符号，这些函数似乎使用了错误的命名约定

D:\tmp\mspatcha>dumpbin /exports mspatcha.lib|找到“ApplyPatchToFileExA”

除非我错了，否则这表明 lib 使用 cdecl 导出函数，而 dll 使用 stdcall（或至少将函数声明为 _stdcall）。请参阅：Microsoft Windows 中的 C 名称修饰。

我的问题是：在我的应用程序中使用 mspatcha.dll 的正确方法是什么，以及我从 dll 创建库以便进行静态链接的过程有什么问题？

我的终端的详细输出可以在这里找到：http: //pastebin.com/q4FV4Se6

我有一个第三方 LIB，它的符号导出为纯 C/cdecl，因此例如dumpbin.exe /SYMBOLS报告两者都__imp_nvmlInit被nvmlInit导出。

但是在 Visual Studio 2010 中，当我尝试导入它们时，头文件将具有

但是当我尝试编译时，出现以下错误：

main.obj：错误 LNK2019：函数 _main 中引用的未解析的外部符号 _nvmlInit

如何阻止 Visual Studio 查找带有前导下划线的符号？__declspect(dllimport)不起作用，因为它装饰为__imp__nvmlInit（一个下划线太多）。

谢谢。

在我的 DDL 中，我定义了以下函数：

如您所见，我已经尝试了多种方法来使其正常工作...

我在我的winform中声明如下：

在我的 System::Windows::Forms::Form Load 事件中，我有以下代码：

在我的 System::Windows::Forms::Form Shown 事件中，我有以下代码：

我认为问题一定出在我通过 HWND 发送的方式上，但是我一直在搜索一整天，找不到替代方法。

我也试过设置 this->Visible = false; 但后来我不知道如何触发它从 DLL 中恢复可见（滥用 sendmessage？）。

我不是 C++ 程序员，我通常只用托管语言编程，所以任何帮助（和耐心表示赞赏。

谢谢，

缺口。

注意

我无法解释的一件奇怪的事情是我不能从 WinForm 本身调用 ShowWindow。它会抛出这个宝石：

[编辑1]

汉斯帕桑特说：

您在 ShowWindow() 尝试中收到的链接器错误消息也是您当前代码无法正常工作的强烈暗示。您忘记添加错误检查代码，GetProcAddress() 可能会失败并返回 NULL 指针。它将，该功能不会由“hideme”名称导出。在 32 位版本中，它将导出为“_hideme”，请注意下划线。添加它以指示该函数使用 __cdecl 调用约定。ShowWindow 上的链接器错误演示了 C++ 名称修饰，您忘记了 #include windows.h 并为 ShowWindow 编造了您自己的不正确声明。

这不是正确的方法，您应该将 Visible 属性设置为 false。就像你试过的那样。为什么你不能将它设置回 true 是非常难以猜测的。

你说的话对我来说毫无意义，有几个原因。

1)

winform 的导入：

如您所知，windows.h 就在其中。

2) ShowWindor 错误不在 DLL 中，我可以调用它，它在 WinForm 代码中。

3）我从来没有导出过ShowWindow，只是我自己的函数。

[/EDIT1]

[EDIT2] Uwe Keim 说：

为什么需要一个额外的 DLL，它只是另一个 DLL 函数的包装器？

我会像在 C# 中那样使用托管 C++ 应用程序中的 PInvoke。SendMessage 的签名将是（在 C# 中）：

正如评论者所说，PInvoke 的东西没有任何意义。

至于 DLL，它必须是一个 DLL，因为我需要一个全局挂钩来响应我的热键和 WH_CBT。在这种情况下，我希望程序开始隐藏并在按下组合键时显示设置屏幕。

程序中的一切都按预期工作，热键就像一个魅力，唯一我不能正确的，是显示应用程序，从 DLL 触发。[/EDIT2]

[EDIT3] 示例代码位于：http : //www.nickkusters.com/CPP_PROBLEM_Demo-NOBIN.zip [/EDIT3]

我想在汇编中编写一个自定义模块并让我的 C++ 函数调用它。我不想从头开始，而是想用 C 编写“草稿”，让编译器生成一个蓝图汇编源，即 /FA 编译器选项生成的列表文件。

但是，我发现生成的所有过程名称都已经是修饰形式。此外，MASM将再次进行自己的名称装饰。因此，如果我在不首先手动取消修饰编译器生成的过程名称的情况下组装我的版本，我会收到链接器错误，因为函数名称不匹配。

是否可以防止这种类型的重复名称装饰？

从 C++ 编译器的角度来看，命名空间只是名称装饰约定吗？我检查了生成的程序集列表，发现除了标识符由命名空间的名称修饰之外，一切看起来都一样。

[ 编辑 ] ==> 为了澄清，在多个目标部署到同一目录的环境中，Planet Earth 已决定约定将“ d”或“ _d”或“ _debug”附加到“ DEBUG”版本（库或可执行文件的） ）。这样的约定可以被认为是“普遍存在的”和“理解的”，尽管（当然）不是每个人都这样做。

类似地，为了解决库的“共享”和“静态”版本之间的歧义，一个常见的约定是附加一些东西来区分静态和共享（如“ myfile.lib”用于 shared-import-lib-on-Windows 和“ myfile_s.lib" 用于 Windows 上的静态导入库）。虽然 Posix 没有这种基于文件扩展名的歧义，但请记住，文件扩展名不用于“链接行”，因此能够显式指定库的“静态”或“共享”版本同样有用.

出于这个问题的目的，“ debug/release”和“ static/shared”都被提升为“装饰文件名根的普遍约定”。

问题： 是否有任何其他部署配置被“提升”到这个级别的“普遍约定”，以便它在文件目标根名称中变得明确？

我目前的猜测是“不”。对于“是”的答案，它需要：给定目标的多个配置旨在“使用”（并因此部署到一个公共目录，这是问题的假设基础）。

过去，我们编译时带有或不带有“web 插件”功能，这同样需要名称修饰，但我们不再构建这些目标（因此我不会作为示例断言）。类似地，我们有时会在有和没有多字节字符支持的情况下进行编译，但我讨厌这样，所以我也不会断言。

[原始问题]

我们正在建立库命名约定/策略，以跨语言和平台应用（例如，我们支持在不同平台上使用多种语言的混合产品，包括 C/C++、C#、Java）。除了传统的桌面（和嵌入式）应用程序之外，一个特定的目标是确保我们处理移动开发的目标/资源（这对我们来说是新的）。

当然，一种选择是为来自不同构建配置的目标提供不同的路径。出于这个问题的目的，决定将所有目标放在一个目录中，并“装饰”库/资源/可执行文件名称以避免基于构建配置的冲突（例如，“DEBUG”v. “RELEASE”、“静态库”v.“共享/DLL”等）

当前的决定与网络上的其他决定类似，我们在其中附加令牌以避免命名冲突：

（以上是 Windows 示例，但这些策略同样适用于我们的 POSIX 系统。）

这些基于：

问题： 我们没有必须单线程编译的遗留应用程序，我的理解是（与 Microsoft 不同）POSIX 系统可以将单线程和多线程目标链接到单个应用程序中而不会出现问题。鉴于当今向多核和多线程的推动，大型企业是否需要建立以下内容来识别“单”与“多线程”编译目标？

...我们是否错过了任何其他目标冲突，例如使用和不使用 STL 进行编译（在 C++ 上）？

顺便说一句，Microsoft 的库命名约定位于：http: //msdn.microsoft.com/en-us/library/aa270400 (v=vs.60).aspx ，它们的 DLL 命名约定位于：http://msdn。 microsoft.com/en-us/library/aa270964(v=vs.60).aspx

一年前关于 SO 的一个类似问题没有谈论线程并且没有引用 Microsoft 约定，可以在以下位置找到：什么是 MSVC dll、静态库和导入库的正确命名约定