Is it possible to share an existing chunk of RAM with another process?

2
votes

Background

I have an existing 32 bit application which has a rather big chunk of RAM (>128 MB) allocated (via malloc/new) and populated with some image data (multiple frames worth). A read only pointer (const char *) to the start of this chunk of RAM is accessible to the application's plugins via a SDK-API call. Other API calls are available to retrieve the meta data such as width/height/bit depth and so on. I have no/little control over this application outside the SDK-API calls.

I have yet another 64 bit application (under my control) which requires the above data as input and requires significantly more RAM due to up sampling/3D volume reconstruction which warrants the 64 bit process.

The Problem

I wish to share the physical memory mapped to this existing pointer in the 32 bit process (which was not originally created via calls such as CreateFileMapping/MapViewOfFile but through malloc/new operator calls) with the 64 bit process.

Is it even possible ?

Typically I'd create a same sized shared memory in the 32 bit process, copy the contents over and use some synchronization method to signal the data is available. In my case however, the 32 bit process is also getting crowded with many plugins and therefore it is very near the limits of available free virtual space. There is a chance MapViewOfFile might fail because of the memory fragmentation. Since I only need a read only copy of the chunk of RAM, I was trying avoid additional allocation and copying.

I am targeting 64 Bit Windows 7, Visual C++ 2010/2015

1
c++windowsmemory-managementipcshared-memory
You have made sure your 32 bit application (and the plugins) are Large Address Aware ? Else it gets a 31 bits address space. – MSalters
There's a thing called CheatEngine which does something like this. Source code is available here: cheatengine.org/downloads.php – 0xbaadf00d
@0xbaadf00d Thanks, I will look into this. If this works similar to how a debugger operates, while it might be "technically feasible", I fear it might not be an "acceptable" solution due to other factors beyond my control. – Shreyas Murali
Note that the address space only restricts the size of each view, not the size of the shared memory itself. If necessary, you could map 128 MB and copy it in 4 kB chunks ! So, practically, try to grab a 128 MB view, and if that fails repeatedly halve the view size. – MSalters
ReadProcessMemory (called by the 64-bit process, having been given a pointer to the original buffer by the 32-bit process plugin) would be a simple solution. I imagine it is at least as efficient as any other supported method. – Harry Johnston

1 Answers

1
votes

No. For starters, "shared memory" are actually shared pages. Your malloc call is by no means guaranteed to return page-aligned memory. Furthermore, those shared pages must be created in a free region of your virtual address space, but malloced memory is backed by allocated and unshared pages.