我们希望支持一些最近停产的硬件。硬件驱动程序是一个普通的 32 位 C DLL。我们没有源代码，并且（出于法律原因）对驱动程序的反编译或逆向工程不感兴趣。
硬件快速发送大量数据，因此通信协议需要非常高效。
我们的软件是本机 64 位 C++ 应用程序，但我们希望通过 32 位进程访问硬件。什么是 32 位和 64 位应用程序相互通信的高效、优雅的方式（理想情况下，不涉及发明新协议）？
解决方案应该在 C/C++ 中。
更新：一些受访者要求澄清这是用户模式还是内核模式驱动程序。幸运的是，它是一个用户模式驱动程序。
如果这是一个真正的驱动程序（内核模式），那么你就是 SOL。Vista x64 不允许安装未签名的驱动程序。这只是一个用户模式 DLL，您可以通过使用任何标准 IPC 机制来获得修复。管道、套接字、进程外 COM，大致按此顺序。这一切都以总线速度运行，因此只要您可以缓冲足够的数据，上下文切换开销就不会受到太大影响。
我只会使用套接字。如果您将来需要它，它将允许您通过 IP 使用它，并且您不会被束缚在一个消息传递 API 上。如果将来您希望在其他操作系统或语言上实现此功能，您可以。
这篇文章可能很有趣。它讨论了这个问题，然后建议使用 COM 作为解决方案。我不是 COM 的忠实拥护者，但鉴于它在 Windows 世界中无处不在，它可能足够高效。您可能希望构建您的解决方案，以便您可以批处理数据（您不想为每个数据项执行一次 COM 调用）。
优雅的？C++？对自己的 DCOM/RPC 调用可能会起作用，或者您可以创建一个命名管道并使用它在两个进程之间进行通信（可能创建一个“CMessage 类”或其他东西），但要注意 x86 和 x64 之间的不同结构对齐方式。
如果驱动程序确实是一个真正的驱动程序，那么 nobugz 几乎是正确的——你将不得不更加努力地工作，你还不是完全的 SOL。一种解决方案是在其他机器（或虚拟机）上安装 Win32，然后使用某种形式的 RPC，例如套接字（如 Pyrolistical 所建议的）或 UDP 或 MQ 甚至是 Tibco Rendezvous（它声称支持非常高的吞吐量以便按顺序处理金融市场产生的海量数据——至少这是我在过去记得的）。
双方共享的内存映射文件将具有相同的内容。操作系统将不得不做一些有趣的指针事情来实现它，但很可能能够以这样一种方式设置 2 个视图，即您不会在物理上复制内存。零拷贝几乎和它一样好