混合 32 位和 64 位 P/调用 [英] Mixing 32-bit and 64-bit P/Invokes

问题描述

我遇到了一个我很确定我知道答案的问题，但我想我至少会问一下，看看是否有一些灵丹妙药"可以让我免于头疼.

I've run into a problem that I'm pretty sure I know the answer to, but I figured I'd at least ask and see if there was some "magic bullet" that might save me a huge headache.

这是高级视图.

我有一个托管应用程序.该应用程序通过来自不同供应商的第三方库与硬件接口.我对使用的托管应用拥有完全控制权，对硬件 API 库拥有零控制权.

I have a managed application. This application interfaces with hardware via third-party libraries from different vendors. I have full control over the consuming managed app and zero control over the hardware API libraries.

供应商 A 仅提供 32 位原生 SDK.为了让我们能够在 64 位系统上使用它，我们将应用程序标记为在 32 位模式下运行.一切都很好.

Vendor A provides only a 32-bit native SDK. To allow us to use it on 64-bit systems, we marked the application to run in 32-bit mode. All was well.

我们现在正在与供应商 B 集成，后者在 64 位机器上提供特定于 64 位的本机 API 库.来自供应商 B 的 32 位本机 DLL 无法在 64 位系统上运行(尝试过).如果我构建了一个作为 64 位或 AnyCPU 运行的测试工具，它可以正常工作.如果我将其标记为 32 位，则 P/Invoke 调用将失败.

We are now integrating with Vendor B, which provides 64-bit-specific native API libraries on 64-bit machines. The 32-bit native DLL from Vendor B will not work on a 64-bit system (tried that). If I build a test harness running as 64-bit or AnyCPU, it works fine. If I mark it as 32-bit, it fails on the P/Invoke calls.

似乎供应商 A 和供应商 B 的硬件在 64 位 PC 上是互斥的，但我想知道是否有人对如何解决这个问题有建议.

It seems that Vendor A and Vendor B hardware are going to be mutually exclusive on 64-bit PCs, but I'm wondering if anyone has suggestions on how to possibly work around that.

推荐答案

问题不在于 .NET 或 P/Invoke.这是一个操作系统问题.64 位进程只能加载 64 位 DLL.32 位进程只能加载 32 位 DLL.神奇的 Windows-on-Windows(或 WoW)层可以让 32 位应用程序在 64 位 Windows 上运行，它存在于用户模式进程(EXE 和 DLL)和内核之间.无法在 64 位进程中运行 32 位 DLL.WoW 层存在于其下方.(基本上，WoW 是 64 位 Win32 API 的 32 位包装器，它在进程的 32 位世界和操作系统的 64 位世界之间编组数据和函数调用.)

The problem is not a .NET or P/Invoke. It is an OS issue. A 64-bit process can only load 64-bit DLLs. A 32-bit process can only load 32-bit DLLs. The magical Windows-on-Windows (or WoW) layer that lets 32-bit apps run on 64-bit Windows exists between the user-mode process (EXE and DLLs) and the kernel. There is no way to run a 32-bit DLL inside a 64-bit process. The WoW layer exists below that. (Basically WoW is a 32-bit wrapper around the 64-bit Win32 API, which marshals data and function calls between the 32-bit world of the process and the 64-bit world of the operating system.)

您最好/唯一的选择是在单独的进程中运行您的 32 位和 64 位组件，并使用某种形式的 IPC 进行通信.这具有将核心应用程序与可能不稳定的 3rd 方组件分离的额外好处.如果第 3 方组件崩溃或行为异常，只需重新启动包含该组件的进程即可.

Your best/only option is to run your 32-bit and 64-bit components in separate processes and use some form of IPC to communicate. This has the added benefit of decoupling your core application from potentially unstable 3rd-party components. If a 3rd-party component crashes or misbehaves, it's simply a matter of re-starting the process containing that component.

这篇关于混合 32 位和 64 位 P/调用的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！