C/C++ What's the best form of IPC for two Windows C++ applications?

AI Thread Summary
The discussion centers on finding a method for fast inter-process communication between two Windows Visual C++ applications, one 64-bit and the other 32-bit. The primary need is to send two integers from the 64-bit application to the 32-bit application multiple times per second, with a focus on one-way communication. Various methods were considered, including using the Windows clipboard, simple file writing, and memory-mapped files. Concerns about file locking errors were raised, and synchronization techniques like semaphores and mutexes were mentioned. Suggestions included using command line parameters to pass handle addresses and exploring the Boost interprocess library. Ultimately, the user opted for a simple file solution, achieving satisfactory read/write rates of 30 Hz, which met their application's requirements without encountering permission errors.
chickenwing71
Messages
41
Reaction score
0
I have two Windows Visual C++ programs that need fast inter-process communication. One is limited to 64-bit because it depends on 8 gigs of ram, and the other is limited to 32-bit because it depends on a proprietary 32-bit .dll

I need to send basically two integers from the 64-bit application to the 32-bit, and update a few times per second. Purely one-way communication.

Would opening the windows clipboard for writing in one process and reading in another work? What about just a simple file? Or would I run into file locking errors? Any better suggestions? I don't want to go and learn some new library or api unless it's absolutely necessary. Thoughts?
 
Technology news on Phys.org
You can use semaphore and/or mutexes to sychronize access between tasks, but sharing handles to objects between tasks is an issue. The issue is passing an handle addresses for duplicatehandle() between tasks. One method is for the first task to allocate handles, and pass it's process id and handle addresses as command line parameters when invoking the second task. Using windows debugger functions it's possible for one task to read or write the memory of a second task, something commonly done by "trainers" for computer games. I've written some mult-threaded (shared memory space) apps, but not a multi-tasking (not shared memory space) app. A .dll has it's own memory space as well as access to the memory space of the calling task (I haven't tried this either).
 
The boost libraries (boost.org) include interprocess library that you might find useful. I haven't tried using it myself.
 
I haven't checked out boost, so can't comment on that. If that doesn't pan out I'd try a memory-mapped file.
 
a memory-mapped file might work, where one program writes to it, and the other reads from it
 
Have you tried creating a Ramdisk?
 
Thanks for all the suggestions! I ended up making a simple file on the disk to write/read from. It's definitely not ideal, and sockets, or pipes or some of the other solutions seem faster, but I'm still getting read/write rates of 30 Hz (even when combined with frequent log file writes), which is more than enough for my application. No permission errors either. I just took the easy way out, and it is more than fast enough for my application.

Thanks!
 
Back
Top