Since I haven\'t found an answer to the question asked previously here I\'m trying a different approach.
Is there any way to share memory between two processes?
If you're talking about Windows, the main roadblock is that processes each live in their own virtual address space. You unfortunately can't pass normal memory addresses around from process to process and get the results you'd expect. (Threads, on the other hand, all live in the same address space, which is why threads can see memory in the same way.)
Windows does, however, have a shared memory space that you have to be very careful to manage correctly. Any process that allocates space in the shared memory space is responsible for freeing that memory explicitly. This is in contrast to local memory, which more or less vanishes when the process dies.
See this MSDN sample article for some ideas on how you might use the shared memory space to take over the world. Er, interface with legacy software. Or whatever :) Good luck whatever you end up doing!
Did you try to use pipes (for memory) or even serialization (for your objects)? You can use files to manage memory between processes. Sockets are also good to get communication between processes.
You can try using Boost.Interprocess to communicate between two processes. But to inject code into a previously existing, not supported software, you'll probably have to use @bdonlan's way using WriteProcessMemory.
Although windows supports shared memory through its file mapping API, you can't easily inject a shared memory mapping into another process directly, as MapViewOfFileEx does not take a process argument.
However, you can inject some data by allocating memory in another process using VirtualAllocEx and WriteProcessMemory. If you were to copy in a handle using DuplicateHandle, then inject a stub which calls MapViewOfFileEx, you could establish a shared memory mapping in another process. Since it sounds like you'll be injecting code anyway, this ought to work well for you.
To summarize, you'll need to:
You may find it a bit easier if your stub loads an external library - that is, have it simply call LoadLibrary (finding the address of LoadLibrary is left as an exercise to the reader) and do your work from the library's dllmain entry point. In this case using named shared memory is likely to be simpler than futzing around with DuplicateHandle. See the MSDN article on CreateFileMapping for more details, but, essentially, pass INVALID_HANDLE_VALUE for hFile and a name for lpName.
Edit: Since your problem is passing data and not actual code injection, here are a few options.
Edit 2: Here's a sketch of how you might implement handle or pointer storage for your stub:
.db B8 ;; mov eax, imm32
.dl handle_value ;; fill this in (located at the start of the image + one byte)
;; handle value is now in eax, do with it as you will
;; more code follows...
You could also just use a fixed name, which is probably simpler.
Memory mapping is the way to go, you don't even need to create a permanent memory space, the memory sector goes out of scope when all the processes sharing it are shutdown. There are other ways too. A quick and dirty way of passing data from one C app to another is just to use the OS. At command line type app1 | app2
. This causes app2 to be the output destination of app1 or iow a printf command from app1 would send it to app2 (this is called piping).
You can use Shared Memory