Re: [Boost-users] [Interprocess] How to prevent collision of mapping addresses with DLL Loading on Windows?

Subject: Re: [Boost-users] [Interprocess] How to prevent collision of mapping addresses with DLL Loading on Windows?
From: Eric J. Holtman (eric_at_[hidden])
Date: 2009-12-14 09:47:48

pheres wrote:
> 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 your app is multithreaded, this isn't a failsafe solution.

It will work, exactly until your big demo in front of the VC guys.

> 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.
>
I understand the problem, I'm just telling you that if your
requirements are "must work all the time", then something has
to give, and that something is going to be performance.

> You could call VirtualAlloc() inside DllMain() of your lib as a 
> workaround.
>
That doesn't help me, if someone else has already loaded
something there, as you've already discovered.

> format editor tools and probably manual work. Seems to hacky for anything
> but creating malware.
>
Right.... this is the problem if you don't have the source for main().

> 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...".

How's that supposed to help, if you don't have the source for main?

You really want your DLL to load at 0x30000000.  What happens
if some other vendor also wants that address space?  At that point,
if you're writing a library, and you haven't made yours address
indifferent, the end user is screwed.  He can't use both.