Windows x64 上 32 位和 64 位应用程序之间的进程间通信
我们希望支持一些最近停产的硬件。 硬件驱动程序是一个普通的 32 位 C DLL。 我们没有源代码，并且（出于法律原因）对反编译或逆向工程驱动程序不感兴趣。
硬件快速发送大量数据，因此通信协议需要非常高效。
我们的软件是本机 64 位 C++ 应用程序，但我们希望通过 32 位进程访问硬件。 32 位和 64 位应用程序相互通信的高效、优雅的方式是什么（理想情况下，不涉及发明新协议）？
解决方案应该是C/C++。
更新：一些受访者要求澄清这是用户模式还是内核模式驱动程序。 幸运的是，它是一个用户模式驱动程序。
We'd like to support some hardware that has recently been discontinued. The driver for the hardware is a plain 32-bit C DLL. We don't have the source code, and (for legal reasons) are not interested in decompiling or reverse engineering the driver.
The hardware sends tons of data quickly, so the communication protocol needs to be pretty efficient.
Our software is a native 64-bit C++ app, but we'd like to access the hardware via a 32-bit process. What is an efficient, elegant way for 32-bit and 64-bit applications to communicate with each other (that, ideally, doesn't involve inventing a new protocol)?
The solution should be in C/C++.
Update: several respondents asked for clarification whether this was a user-mode or kernel-mode driver. Fortunately, it's a user-mode driver.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
如果这是一个真正的驱动程序（内核模式），那么你就是 SOL。 Vista x64 不允许安装未签名的驱动程序。 如果这只是一个用户模式 DLL，您可以使用任何标准 IPC 机制来修复。 管道、套接字、进程外 COM，大致按此顺序。 它全部以总线速度运行，因此只要您可以缓冲足够的数据，上下文切换开销就不会造成太大影响。
If this is a real driver (kernel mode), you're SOL. Vista x64 doesn't allow installing unsigned drivers. It this is just a user-mode DLL, you can get a fix by using any of the standard IPC mechanisms. Pipes, sockets, out-of-proc COM, roughly in that order. It all operates on bus speeds so as long as you can buffer enough data, the context switch overhead shouldn't hurt too much.
我只会使用套接字。 如果您将来需要的话，它将允许您通过 IP 使用它，并且您不会受限于一种消息传递 API。 如果将来您希望在其他操作系统或语言上实现此功能，您可以。
I would just use sockets. It would allow you to use it over IP if you need it in the future, and you won't be tied down to one messaging API. If in the future you wish to implement this on another OS or language, you can.
这篇文章可能会引起兴趣。 它讨论了该问题，然后建议使用 COM 作为解决方案。 我不是 COM 的忠实粉丝，但考虑到它在 Windows 领域的普遍性，它可能足够高效。 您可能希望构建您的解决方案，以便可以批量处理数据（您不希望对每一项数据执行一次 COM 调用）。
This article might be of interest. It discusses the problem and then suggests using COM as a solution. I'm not a big fan of COM but given its ubiquity in the Windows universe, it's possible that it might be efficient enough. You will probably want to architect your solution so that you can batch data (you don't want to do one COM call for each item of data).
优雅的？ C++？ 对自己的 DCOM/RPC 调用可能会起作用，或者您可以创建一个命名管道并使用它在两个进程之间进行通信（可能创建一个“CMessage 类”或其他东西），但要注意 x86 和 x64 之间的不同结构对齐。
Elegant? C++? DCOM/RPC calls to yourself might work, or you could create a named pipe and use that to talk between the two processes (maybe create a "CMessage class" or something), though watch out for different structure alignment between x86 and x64.
如果司机确实是一名真正的司机，nobugz 几乎是对的——你将不得不更加努力地工作，你还没有完全 SOL。 一种解决方案是在其他机器（或虚拟机）上安装 Win32，然后使用某种形式的 RPC，例如套接字（如 Pyrolistical 建议的那样）或 UDP 或 MQ，甚至 Tibco Rendezvous（它声称支持非常高的吞吐量，以便处理金融市场产生的大量数据——至少我以前记得是这样）。
If the driver does turn out to be a real driver, nobugz is almost right -- you're going to have to work a lot harder, you're not completely SOL. One solution is to install Win32 on some other machine (or virtual machine) and then use some form of RPC, such as sockets (as suggested by Pyrolistical) or UDP or MQ or even Tibco Rendezvous (which claims to support very high throughput in order to handle the volumes of data generated by the financial markets -- at least that's what I remember from back in the old days).
双方共享的内存映射文件将具有相同的内容。 操作系统必须做一些有趣的指针操作才能实现这一点，但很可能能够以不物理复制内存的方式设置两个视图。 零拷贝已经是最好的了
A memory-mapped file, shared by both sides would have the same contents. The OS will have to do some interesting pointer stuff to make it happen, but quite likely will be able to setup the 2 views in such a way that you're not physically copying memory around. Zero copies is about as good as it gets