# Best IPC mechansim for simple x86-x64 communication



## streetfighter 2 (Jan 15, 2011)

I'm writing a program that needs to query all the processes on a x64 vista/7 OS.  Unfortunately that means I need a 32-bit and a 64-bit executable.  I want the vast majority of the code to be in the 64-bit executable but I still need some way of communicating with the 32-bit executable.  I'm only transferring a small amount of simple variable data (like process ID or image name) to the main executable so I don't need a robust IPC mechanism.

I've looked at the MSDN page on IPC and I get the feeling I'm in over my head.  I've used named pipes in the past (because I'm familiar with them on linux) but I'm not sure if it's the best method.

Any help would be appreciated! 

PS.  If it matters I'm probably going to write this in C++, but I'm very flexible.


----------



## W1zzard (Jan 15, 2011)

shared memory, temp file, named pipes in that order

read:
http://social.msdn.microsoft.com/Fo...v/thread/9282b719-fc63-482f-bf42-398e8f03238a


----------



## FordGT90Concept (Jan 15, 2011)

I'd recommend .NET Framework and build the executable for "Any CPU."  It runs at x86 on x86 and AMD64 on x86-64.  One executable for both platforms.

PID and process name are easily accessible via System.Diagnostics.Process.GetProcesses().


----------



## streetfighter 2 (Jan 15, 2011)

FordGT90Concept said:


> I'd recommend .NET Framework and build the executable for "Any CPU."  It runs at x86 on x86 and AMD64 on x86-64.  One executable for both platforms.
> 
> PID and process name are easily accessible via System.Diagnostics.Process.GetProcesses().


I probably should have mentioned that whatever language I use I wasn't planning on using .NET. . .  However given the strengths of .NET when working in a mixed 32/64 environment, I may have to change my mind. 

I was looking at MSDN and it looks like the core function of my program could be reduced to 30 or so lines of code in .NET, as opposed to 100+ in standard C++.  Damn you .NET! 

I'll probably make a prototype of my program in .NET and standard C++ (using shared memory and separate executables) just to see which is faster and lighter.



W1zzard said:


> read:
> http://social.msdn.microsoft.com/Fo...v/thread/9282b719-fc63-482f-bf42-398e8f03238a


I did consider that briefly when I was writing an app some time ago, but after running some tests I was less than impressed by the performance using the WMI.  Perhaps it's time for another try?


----------



## FordGT90Concept (Jan 15, 2011)

FYI, when using processes, there is a pretty big performance penalty when querying the Process.MainModule.  If you can, try to use the Process information from the Process[] array.  There's a lot there (including .Id and .ProcessName) so hopefully you won't have to get access the module.

Also note that GetProcesses() returns some virtual processes like "System Idle Processes."  You may have to add some code which ignores those (if memory serves, their .ProcessName starts with $ which is unique to them).


Most inter-process communication is done via the process handle (.Handle).


I should also note that "Express" versions of Visual Studio are x86 only.  You need the full-fledged Visual Studio in order to compile "Any CPU," "IA64," and "x64" binaries.


----------



## streetfighter 2 (Jan 15, 2011)

FordGT90Concept said:


> I should also note that "Express" versions of Visual Studio are x86 only.  You need the full-fledged Visual Studio in order to compile "Any CPU," "IA64," and "x64" binaries.


I don't really like Visual Studio anyway, so I was planning on trying my hand at Mono and it's C# compiler.  I don't know about Mono's build options.

On the other hand I've read that there are actually a couple ways to trick VS:Express into a different build mode. . . Though I don't mean to switch this thread to a discussion of 32-64 IDEs and compilers.


----------



## FordGT90Concept (Jan 15, 2011)

I haven't done much work with Mono.  All I know is that in order for one of my apps to work on Mono, I had to change all the file paths from \ to /.  That's all it really took to make it work in Windows and Mono.


----------

