我們希望支持最近已停用的某些硬件。硬件的驅動程序是一個普通的32位C DLL。我們沒有源代碼，並且（由於法律原因）對反編譯或反向驅動程序不感興趣。Windows x64上的32位和64位應用程序之間的進程間通信
硬件快速發送大量數據，所以通信協議需要非常高效。
我們的軟件是本機64位C++應用程序，但我們希望通過32位進程訪問硬件。對於32位和64位應用程序彼此進行通信（理想情況下，不涉及創建新協議），高效優雅的方式是什麼？
該解決方案應該在C/C++中。
更新：一些受訪者詢問澄清這是用戶模式還是內核模式驅動程序。幸運的是，它是用戶模式驅動程序。
如果這是一個真正的驅動程序（內核模式），那麼您就是SOL。 Vista x64不允許安裝未簽名的驅動程序。它只是一個用戶模式DLL，你可以通過使用任何標準的IPC機制來獲得修復。管道，套接字，out-of-proc COM，大致按此順序。它們都以總線速度運行，只要你可以緩衝足夠的數據，上下文切換開銷不應該太大。
This article可能是感興趣的。它討論了這個問題，然後建議使用COM作爲解決方案。我不是COM的忠實粉絲，但鑑於其在Windows世界中的普遍性，它可能足夠高效。您可能會想要構建您的解決方案，以便批量處理數據（您不希望爲每項數據執行一次COM調用）。
優雅？ C++？ DCOM/RPC調用自己可能會工作，或者你可以創建一個命名管道，並使用它來在兩個進程之間進行通信（也許創建一個「CMessage類」或其他），但要注意x86和x64之間的不同結構對齊。
我只是使用套接字。如果您將來需要它，它將允許您通過IP使用它，並且您不會受限於一個消息傳遞API。如果將來您希望在另一種操作系統或語言上實現此功能，則可以。
如果司機確實是一個真正的駕駛員，nobugz幾乎是正確的 - 你將不得不努力工作很多，你不是完全SOL。一種解決方案是在某些其他機器（或虛擬機）上安裝Win32，然後使用某種形式的RPC，例如套接字（如Pyrolistical建議的）或UDP或MQ甚至Tibco Rendezvous（它聲稱支持非常高的吞吐量以處理金融市場產生的大量數據 - 至少這是我從前幾年記憶中的數據）。
由雙方共享的內存映射文件將具有相同的內容。操作系統將不得不做一些有趣的指針來實現它，但很可能會以這樣的方式設置2個視圖，以至於你沒有物理地複製內存。零拷貝大約就像它得到的那樣好