我们希望支持最近已停用的某些硬件。硬件的驱动程序是一个普通的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个视图，以至于你没有物理地复制内存。零拷贝大约就像它得到的那样好