Eric J. Holtman wrote:
It's not 100% reliable (because at some point, you're going to have to VirtualFree the slice so the shared memory lib can use it), but it's better than most alternatives. Yes, I VirtualFree exactly one statement before initializing the IPC.
If *you're* writing the code that uses the shared memory block, I would *strongly* encourage you to attempt to re-write it so that you don't need to have it loaded into the same address location in all processes. I have a tree like structure in the shared memory using pointers (which have to be valid inside every process, therefore the need for fixed base address) as connection elements. The structure is fairly big and queried right often. If I use offsets instead pointers and convert that to pointers using the difference in the base addresses I get about 1/10th of the original performance.
(like, where I'm writing a lib, and using their lib, but I didn't write "main"). You could call VirtualAlloc() inside DllMain() of your lib as a workaround.
I found one other possibility to get some code (which could alloc and therefore reserve the memory) executed possibly before any run time linking occurs: Creating a thread local storage callback. But it involves some PE format editor tools and probably manual work. Seems to hacky for anything but creating malware. I can't believe that Windows does not offer a way to solve this problem more elegantly, e.g. through setting some option somewhere which states like "if you load any DLL, do it, but do not relocate it between 0x... and 0x...". MS should know that the described problem could happen, but I'm unable to find something in their docs. Best Regards Joerg