混合32位和64位P /調用

Question

我遇到了一個問題，我很確定我知道答案，但我想我至少會問，看看是否有一些「魔法子彈「，這可能會讓我非常頭疼。

以下是高級視圖。

我有一個託管的應用程序。此應用程序通過來自不同供應商的第三方庫與硬件進行交互。我完全控制了消費的託管應用程序，並對硬件API庫進行了零控制。

供應商A僅提供32位原生SDK。爲了讓我們能夠在64位系統上使用它，我們將應用程序標記爲以32位模式運行。一切都好。

我們現在正與供應商B集成，供應商B在64位機器上提供64位特定的本機API庫。供應商B的32位原生DLL無法在64位系統上工作（試過）。如果我構建以64位或AnyCPU運行的測試工具，則工作正常。如果我將它標記爲32位，它會在P/Invoke調用中失敗。

似乎供應商A和供應商B硬件將在64位個人電腦上互相排斥，但我想知道是否有人對如何解決這個問題有什麼建議。

Answer 1

問題不在於.NET或P/Invoke。這是一個操作系統問題。一個64位進程只能加載64位DLL。一個32位進程只能加載32位DLL。允許32位應用程序在64位Windows上運行的神奇的Windows-on-Windows（或WoW）層存在於用戶模式進程（EXE和DLL）與內核之間。沒有辦法在64位進程中運行32位DLL。 WoW層位於下方。 （基本上WoW是64位Win32 API的32位包裝器，它封裝了32位世界的進程和操作系統的64位世界之間的數據和函數調用。）

你最好的/唯一的選擇是在單獨的進程中運行32位和64位組件，並使用某種形式的IPC進行通信。這有助於將核心應用程序與潛在不穩定的第三方組件解耦。如果第三方組件崩潰或行爲不當，則只需重新啓動包含該組件的進程即可。

Answer 2

您可以製作一個單獨的32位進程與供應商A進行交互，然後使用WCF與其進行通信。

Answer 3

希望有人可以提出一個更好的選擇，但也許你可以在一個單獨的進程中打包其中一個庫（帶寬最低的連接到你的應用程序），然後與它通信（例如通過套接字）。

Answer 4

由於無法將32位和64位圖像加載到同一進程中，因此必須使用多進程解決方案。