views:

633

answers:

3

Hi,

I'm playing with C dlls to hook global Windows events and the next step is sending some event data (nothing huge) to a C# application.

As I want this communication to be as fast as possible, I'm analysing two options: Named Pipes and Memory Mapped Files.

I know that .NET 4 brings MMF in a native way, but I have to target .NET 2, as the existence of Win98 clients is still possible. I also know that there are ways to manage MMF with .NET 2 via Windows API (and some folks have even built some wrappers to it).

In this context, I'd like to know:

  1. Are there any big disadvantages (performance mainly) in choosing Named Pipes instead of MMF? Important to remeber that I'll not transfer huge amount of data;
  2. Are there any security issues involved in NP or MMF (targeting .NET 2)?
  3. Is there any better choice than those?

Thank you in advance.

Filipe

+1  A: 

Option 1: Expose a COM interface on one of your C# objects and call that from your C++ application.

Option 2: Use C++/CLI - you can use the Win32 API to hook global windows events and expose a .Net class on the other side for your C# clients to use directly.

Of course, neither of these options answers your question on Named Pipes vs. Memory mapped Files, but I think either of these will be simpler unless you have a specific need to keep these as separate processes.

Tarydon
Tarydon, thanks for your answers. Before considering your options, that's important to know that global hooks attach it's piece of code (the DLL) to every process executing on the machine, so they have to be written using native code.I don't know if Option 1 is really possible, as the COM dependency would be attached to every executing process (maybe possible, but but not performatic). Option 2 isn't possible as far as I can see. As the code would be attached to every process, my C# client wouldn't have a single point class to deal with (that's why I'm thinking about named pipes).
jfneis
A: 

If the target application has a window that you can send messages to, and the amount of data you are sending is relatively small, consider using the WM_COPYDATA message to pass the information.

This message was designed for simple inter-process communication (where the target has a GUI), can be used by a native or a .NET application with nearly zero effort, will have no impact on the system other than whatever pressure you put on the memory by creating the data you are passing around, and is available on all Windows systems from Windows 95.

http://msdn.microsoft.com/en-us/library/ms649011(VS.85).aspx

DannySmurf
A: 

Can't tell about MMF much as I've not tried to use it, but from the look of it, it looks like a bit too complex to set up things. After wrapping the P/invokes, to be able to expose the Named Pipes as a stream with .NET 2.0 (I've created look-alikes of the 3.5 System.Core classes), it is quite easy to send packets of data either way IF you can set the permissions right to have things working on Vista/7 more restrictive policies.

Probably you'd better have the Server stream in the C# Application, and have your possible myriad instances of clients in native code poking things up (I'm not sure you'll be able to share a single instance started before hooking with all the processes you inject the dll, so I think your are going to have multiple clients).

I've gave up DLL hooking for Vista/7 altogether for that matter.

Monoman