What are windows IPC methods

Question

Question: I have a dll that I can load in another program. Now the dll has access to all data/functions in the other program.

Which technology can I use that now an

Answer 1

For simple, fast communication, you might consider Mailslots. They are quite easy to use. You interact with them like you would a file.

Mailslots are most appropriate when you want to broadcast commands to multiple recipients, or receive messages from multiple producers and your design can tolerate the occasional lost message. Named pipes, mentioned above, are better suited for single process-to-single-process, guaranteed-delivery IPC.

The good news

• They are very simple to implmement
• They support asynchronous operation
• They can be used even given Windows Process Isolation. This means you can use them to communicate between different user sessions (e.g. with Windows Services)
• They can broadcast messages to the entire domain by opening a mailslot to "\*\mailslot[path]name". When you write to a mailslot with a name like that, it will send it to every mailslot of that name on every machine in your domain

The bad news

• Only 424 bytes can be transferred over the network. More data can be transferred locally
• They are UDP based, so only use them if losing a message from time to time is okay
• Occasionally (particularly on multi-processor systems), messages can be delivered slightly out of order

Many samples are available, but I don't have enough rep yet to post more than the one on CodeProject in C++

Answer 2

Some common ones are:

• Named Pipes. Fairly easy to implement.
• Shared Memory. A little more work but may be a little bit faster (at least in my testing).
• Sockets. This is fairly simple and very portable but not as high performance. But it is sure nice if you suddenly want to be able to communicate with a process running on a different machine.

Answer 3

COM is the de-facto standard IPC mechanism for Windows-focused applications nowadays.

It allows access across language-barriers, solves the binary interface compatibility problem, does transparent marshalling for you and has different threading models.

sharptooth summarized some facts nicely here.

Answer 4

The OP mentioned sending both data and commands. If both sender and receiver are running in the same user account, a great choice for sending commands would be to define a custom WM_APP or WM_USER message and deliver it with PostMessage(). Windows is still Windows.

If the receiving program has no window, you could always give it an invisible window. If you're not able to do that for some reason, PostThreadMessage() is a fallback option. This is not considered a best practice, because it works outside the purview of the window manager - but it does work.

Of course if the sender and receiver are running in different accounts, PostMessage() and PostThreadMessage() will not work. You'll have to use one of the other methods already mentioned that supports Windows security.

Answer 5

Don't forget Remoting, for higher level possiblities in .NET