我们的 64 位二进制文件是否应该与它们的 32 位版本命名不同？答案

【问题标题】：Should our 64bit binaries be named differently from their 32bit versions?我们的 64 位二进制文件是否应该与它们的 32 位版本命名不同？
【发布时间】：2013-06-08 12:11:15
【问题描述】：

到目前为止，我们的应用程序只使用了 32 位二进制文件，这已经足够了。慢慢地，我们看到需要为某些组件引入 64 位版本（除了 32 位版本），主要是为了与我们自己没有编写的其他 64 位组件进行接口。

出现的一个问题是，我们是否要将 64 位组件（EXE + DLL）命名为与 32 位组件相同的名称并将它们放在另一个目录中，或者是否要以不同的方式命名它们（例如 tool.exefor 32bit 和 @ 987654322@ 对于 64 位）并将它们保留在同一目录中。

微软似乎已经为大多数 Windows 组件 (WoW64) 采用了不同目录和相同名称的路线，如果整个应用程序是 64 位的，我们也有理由只使用 Program Files 而不是 64 位。 Program Files (x86) 目录。

但是，在我们的例子中，我们有一个主要是 32 位的应用程序，它使用一些 64 位组件（可执行文件）来完成 64 位的工作，其中一些我们还使用了一个 32 位版本。

那么，我们是重命名组件并将它们放在同一个二进制目录中，还是保持二进制名称相同并将其放在子目录中？

有什么好处和坏处？

【问题讨论】：

当然，这只是一个简单的部署细节。 64 位程序进入 c:\program 文件，32 位程序进入 c:\program 文件 (x86)。没有什么比这更复杂的理由了。
@Hans - 恕我直言，拆分单个应用程序，恰好由多个可执行组件组成 - 请注意这些组件对用户是透明的，只有用户实际启动的 32 位主应用程序-- 将它们分成 PF 和 PF(x86) 目录听起来不是一个好主意。如果主应用程序是 64 位的，它会转到 PF 而不是 PF(x86)，但这里不是这种情况。

标签： windows visual-c++ dll 32bit-64bit binaryfiles

【解决方案1】：

如果我们谈论的是单个应用程序，那么它的所有文件都应该保存在一个目录中，具体而言。含义，PF 或 PF(x86)。但不会四处传播。

关于组件，问问自己这个。 这些组件可以互换使用，还是并行使用？

如果是前者，那么让它们具有相同的名称，这将简化您的部署。但是，如果有可能同时使用两者，例如，一个 DLL 被 32 位进程和您的 64 位帮助进程使用，则拆分名称。否则，您将需要拆分目录结构。

【讨论】：

【解决方案2】：

现在我必须链接到 64 位 boost 库 DLL。

将 64 位 DLL have the same name 提升为 32 位对应项，并在 Boost Build 中提升 there is no built-in way 以更改输出名称 creating additional work，如果您希望它们位于同一目录中。

Looking around，它是seems，例如Qt 在其 DLL 中不包含任何平台或位标记，如果您在同一目录中需要 32 位和 64 位，这将再次产生问题。

因此，如果您的应用程序中有 3rd 方 DLL 依赖项，并且您需要同时安装 32 位和 64 位应用程序，那么，无论您如何命名可执行文件（或您的DLL) 本身，将它们放入不同的目录似乎是一个好主意，因为这样就很容易使用不会“标记”其 DLL 的第 3 方的东西，因为there really isn't a good way 加载不同的 DLL来自同一目录的相同名称（除非您将它们放入 System32 / SysWOW64，否则您不应该这样做）。

【讨论】：