Windows Mobile 上的简单 IPC？
在 Windows Mobile 上的 C++ 项目（即没有 .NET）中，我正在寻找一种在两个独立运行的应用程序之间轻松通信的方法。 应用程序 A 将运行服务，而应用程序 B 将向用户提供一些功能 - 为此 B 必须调用 A 的某些功能。 我宁愿不在 COM 中实现任何东西。
事实上，我不想进行任何类型的序列化或类似操作（即这将排除使用套接字/管道/文件），而是让 B 将所有参数和指针传递给 A，就像 A 是 B 的一部分一样。此外，应用程序 C、D 和 E 应该能够在仅运行一个 A 实例的情况下执行相同的操作。
我应该补充一点，B 有时应该向 A 返回一个数组（或 std::vector 或 std::map），其中之前的大小是未知的。
这在 Windows Mobile 和其他平台上可能吗？
In a C++ project (i.e. no .NET) on Windows Mobile, I am looking for a way to easily communicate between two independently running applications. Application A would run a service, whereas application B would provide the user some functionality - for which B has to call some of A's functions. I would rather not go through implementing anything in COM.
In fact, I would prefer not to do any kind of serialization or similar (i.e. this would exclude using sockets/pipes/files), but rather have B pass all parameters and pointers over to A, just like if A were part of B. Also, apps C, D and E should be able to do the same with only one instance of A running.
I should add that B sometimes is supposed to return an array (or std::vector or std::map) to A where the size is not previously known.
Is this possible on Windows Mobile and possibly other platforms?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
您不能只是跨进程共享数据。 我不推荐COM。 Windows CE 中不存在管道。 最好的路线是内存映射文件（就像在桌面上一样）或点对点消息队列（与桌面上的不同）。 哪个更好取决于您的使用场景。
不要按照建议尝试将跨进程内存与 VirtualAlloc 一起使用，因为这是一种不安全的黑客行为，并且在 CE 6.0 或更高版本上不受支持，因此您最终会在 WinMo 7 及更高版本下崩溃。
我不建议使用 Windows 消息和 WM_COPYDATA。 它速度慢、笨拙并且很容易出错。
大家，在没有使用过平台的情况下，请不要仅仅为了获得声誉点而回答问题。 如果您不知道该平台，请让其他人帮助该人，而不是让他白费力气。
You can't just share data across processes. I don't recommend COM. Pipes do not exist in Windows CE. Your best route is either a memory mapped file (like on the desktop) or a point to point message queue (nothing like on the desktop). Which is better depends on your usage scenario.
Do not try to use cross process memory with VirtualAlloc as suggested, as it's an unsafe hack unsafe and is not supported on CE 6.0 or later so you'll end up breaking under WinMo 7 and later.
I do not recommend using windows messages and WM_COPYDATA. It's slow, kludgy, and highly prone to errors.
People, please don't just answer questions when you've not used the platform just to try to gain reputation points. If you don't know the platform, let someone else help the guy instead of sending him on a wild goose chase.
既然您只需要应用程序 (B) 与服务 (A) 进行通信，为什么不直接使用
CreateFile和DeviceIoControl以及一组定义的 IOCTL 呢？Since you only need the application (B) to communicate with the service (A), why don't you just use
CreateFileandDeviceIoControlwith a defined set of IOCTLs?这是一个很好的起点 - http://msdn.microsoft.com /en-us/library/aa446520.aspx
您决定哪个选项最适合您的需求。
Here is the good source to start with - http://msdn.microsoft.com/en-us/library/aa446520.aspx
You decide which option is the best fit for your needs.
您已经涵盖了几乎所有可用的基础； COM、管道、套接字、内存映射文件。 Windows 中的所有进程都有完全独立的内存空间，因此如果不使用其中一种 IPC 机制，就无法共享任何内容。
You've covered pretty much all of the bases available; COM, pipes, sockets, memory mapped files. All processes in Windows have completely separate memory spaces, so you can't share anything without using one of those IPC mechanisms.
在 Windows Mobile 上，我似乎记得所有进程都映射到相同的地址空间。 因此，在两个进程中创建具有已知名称和/或类名的消息窗口，并在每个进程中使用 FindWindow 来查找另一个进程。
然后，SendMessage 带有 WM_APP 定义的消息 id 和指向要在 wParam 或 lParam 中传输的数据的指针。
如果我错了，移动设备确实对进程内存进行了分区，那么只需使用 WM_COPYDATA（在桌面上使用内存映射，因此速度非常快）在应用程序之间发送数据。
On Windows Mobile I seem to remember that all processes are mapped into the same address space. So, create message windows in both processes with known names and or class names and use FindWindow in each process to find the other.
Then, SendMessage with a WM_APP defined message id and a pointer to the data to transmit in wParam or lParam.
If I am wrong and Mobile does partition process memory, then just use WM_COPYDATA which - on the desktop uses memory mapping and so is really fast - to send data between the apps.