What are windows IPC methods
Asked Answered
L

5

6

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 external program can send data/commands to that dll, to steer the other program, or get data from it ?

I mean, in the past that meant DDE, I think that was back in Windows 3.11/95 times. What can I use today? Which one is easiest ? Which one is fastest?

Lording answered 27/4, 2010 at 13:53 Comment(0)
L
8

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.
Lipophilic answered 27/4, 2010 at 13:57 Comment(2)
Just to make this list complete i would mention this link to MSDN that lists all available methods msdn.microsoft.com/en-us/library/windows/desktop/… i believe that two the best methods are Pipes and SharedMemory although i did not compare their performance so far and with this implementation, particularly for C#, Shared Memory seems to be the fastest and easiest although i do not know whether it allows communication via network like Pipes do codeproject.com/Articles/138290/…Deafen
Seems that these two links finally allow everyone to choose the most appropriate method en.wikipedia.org/wiki/Inter-process_communication and here can be found some pros and cons - https://mcmap.net/q/169240/-comparing-unix-linux-ipcDeafen
S
6

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.

Sofer answered 27/4, 2010 at 14:0 Comment(0)
D
1

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.

Densitometer answered 20/5, 2020 at 6:38 Comment(0)
S
0

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

Synovitis answered 9/1, 2012 at 12:59 Comment(0)
R
0

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++

Ruminate answered 22/2, 2013 at 15:7 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.