【发布时间】:2011-02-12 21:16:34
【问题描述】:
问题:我有一个可以加载到另一个程序中的 dll。 现在 dll 可以访问其他程序中的所有数据/函数。
我现在可以使用哪种技术让外部程序可以向该 dll 发送数据/命令、引导其他程序或从中获取数据?
我的意思是,在过去这意味着 DDE,我认为那是在 Windows 3.11/95 时代。 我今天可以使用什么?哪一个最容易?哪个最快?
【问题讨论】:
问题:我有一个可以加载到另一个程序中的 dll。 现在 dll 可以访问其他程序中的所有数据/函数。
我现在可以使用哪种技术让外部程序可以向该 dll 发送数据/命令、引导其他程序或从中获取数据?
我的意思是,在过去这意味着 DDE,我认为那是在 Windows 3.11/95 时代。 我今天可以使用什么?哪一个最容易?哪个最快?
【问题讨论】:
一些常见的有:
【讨论】:
COM 是当今以 Windows 为中心的应用程序的事实上的标准 IPC 机制。
它允许跨语言访问,解决二进制接口兼容性问题,为您进行透明编组并具有不同的线程模型。
sharptooth很好地总结了一些事实here。
【讨论】:
OP 提到发送数据和命令。如果发送者和接收者都在同一个用户帐户中运行,发送命令 的一个很好的选择是定义自定义WM_APP 或WM_USER 消息并使用PostMessage() 传递它。 Windows 仍然是 Windows。
如果接收程序没有窗口,你总是可以给它一个不可见的窗口。如果由于某种原因您不能这样做,PostThreadMessage() 是一个后备选项。这不被认为是最佳实践,因为它在窗口管理器的范围之外工作 - 但它确实有效。
当然,如果发送者和接收者在不同的帐户中运行,PostMessage() 和 PostThreadMessage() 将不起作用。您必须使用已经提到的支持 Windows 安全性的其他方法之一。
【讨论】:
不要忘记Remoting,在 .NET 中实现更高级别的可能性
【讨论】:
为了简单、快速的沟通,您可以考虑Mailslots。它们非常易于使用。您可以像处理文件一样与它们交互。
Mailslots 最适合当您想要向多个接收者广播命令,或接收来自多个生产者的消息并且您的设计可以容忍偶尔丢失的消息时。上面提到的命名管道更适合单进程到单进程、保证交付的 IPC。
好消息
坏消息
有许多示例可用,但我没有足够的代表发布多个示例 C++ 中的on CodeProject
【讨论】: