Sharing of process address space

[Benjamin Kalytta]

Hello,

I'm trying to find a solution for direct sharing of process address
space (in user mode if possible).

I know that there is CreateFileMapping/NtCreateSection API to create
file mappings to be shared across process boundary. But I didn't find a
solution to direct share current process address space like:

ShareAddressSpace(void* Base, size_t Size, wchar_t* ShareName);

And in second process simply call something like:

void* Base = OpenAddressSpace(wchar_t* ShareName);

What I want is simply to map another process image into current process
for accessing it's win32 resources. Of course I could call LoadLibrary
etc. but since the process is still loaded anyway I think it would be
easier to just map that process into current address space.

Is there any good solution?

Regards,
Benjamin Kalytta

[Ivo Beltchev]

Probably you need something like ReadProcessMemory?

Also I may be wrong, but I think that if you LoadLibrary in multiple
processes the library will need only one set of physical pages. The same
physical pages will be mapped to different virtual pages in each process.

I think I am oversimplifying it a bit and there are conditions when this
is not true (resolving address references, address randomization, etc).

Maybe people more knowledgeable than me will chime in.

Ivo

[Don Burn]

Why would you want this? The file mapping model has been used by every OS I
have ever seen that wants data sharing, and sharing of code has been done by
DLL's for over 40 years.

--
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

"Benjamin Kalytta" <bka...@web.de> wrote in message
news:hd6cua$5tn$1...@news.eternal-september.org...

> __________ Information from ESET NOD32 Antivirus, version of virus
> signature database 4584 (20091108) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>

__________ Information from ESET NOD32 Antivirus, version of virus signature database 4584 (20091108) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

[Marvin Landman]

Ivo is right. You should load the DLL file to your address space using
LoadLibrary or LoadLibraryEx and access the resources because the
physical pages are shared.

You can use Read and WriteProcessMemory if you really have to but those
are very expensive in terms of performance.

If you want a fast solution just load the file to your address space and
let kernel take care of physical memory sharing.

Marvin

[Benjamin Kalytta]

Thank you Ivo and Marvin, I think LoadLibrary would be the best for me.
But I still think the image will be loaded twice since it is no dll but
an executable file.

Regards,
Benjamin Kalytta

[Remy Lebeau]

"Benjamin Kalytta" <bka...@web.de> wrote in message
news:hd6cua$5tn$1...@news.eternal-september.org...

> What I want is simply to map another process image into current

> process for accessing it's win32 resources.

Use LoadLibraryEx(LOAD_LIBRARY_AS_DATAFILE) for that. You can then use
FindResource() and other resource-related API functions.

--
Remy Lebeau (TeamB)

[Marvin Landman]

Use LoadLibraryEx("file.exe", NULL, LOAD_LIBRARY_AS_DATAFILE |
LOAD_LIBRARY_AS_IMAGE_RESOURCE)

I believe that this way you image will not be relocated either but I'm
not sure. Even if it's relocated only the pages that contain absolute
virtual addresses are copied in memory. But since resources use relative
virtual addresses I believe that there will be no relocation just mapping.

Marvin