Reserve a range in virtual memory at link time

Hi all,

is there any linker option (VC++ 2005) or something similar to force the winXp loader to keep a defined memory range free so it does not load any .dll at this address?

Background is that I need a fixed range of size 0x10000000 for interprocess communications in every process which takes part. The range has to be at the same offset in every process (e.g 0x40000000 to 0x50000000), so I can store pointers inside that area that are valid in every process.

Problem is if the loader decides to load some .dll into my configured memory range before I even have the chance to reserve this part of memory during run time some client can't take part on the interprocess communication.

In short I want to force the system to keep a memory range like 0x40000000-0x50000000 untouched till run time.

Any Ideas?

Thank you in advance!

I found out about the /FIXED and /BASE linker parameters so it would be possible to force fading of all .dll modules I built myself to some other address range than I want to reserve for the inter process communication. Unfortunately there are still the windows .dll modules which I can't link with /BASE myself so it's not a 100% solution.
Better would be a method to force the windows loader/linker to not touch memory range X.

Maybe a minimal example helps better understanding what my exact problem is

Code:

---

#include <windows.h>

int main()
{


  VirtualAlloc(
      (LPVOID)0x40000000, //reserve memory at a designated address 0x40000000
      0x10000000, //size of memory to reserve is 256MB
      MEM_RESERVE, //reserve the memory for myself, OS can't use it for anything else afterwards
      PAGE_EXECUTE_READWRITE //security flag, doesn't matter here
    );
}

---

The call to VirtualAlloc will fail if the memory range is already reserved for something else.
The biggest reason that this range is already reserved is dynamic loaded DLL modules. And I can't find a way to prevent the loader to load any DLL module to 0x40000000. (This address is just an example)

I would ask why you need such a thing. It is unsafe and can cause compatibility problems, I believe.
I don't believe you can stop Windows from loading stuff in a specific virtual memory range before you get to runtime where you can reserve a virtual address range.

Quote:

---

Originally Posted by Elysia

I would ask why you need such a thing. It is unsafe and can cause compatibility problems, I believe.

---

I need it for a special kind of IPC and it would be safe if I could convince the windows runtime linker to not touch the memory region of my choice.
It has to only be compatible with the hardware I built around it, so this is not a concern.

Quote:

---

Originally Posted by Elysia

I don't believe you can stop Windows from loading stuff in a specific virtual memory range before you get to runtime where you can reserve a virtual address range.

---

As I cant find any solution I tend to think the same. But it's illogically. On the one hand the OS gives you fine grained control over the virtual memory of your own process (set fixed base addresses, reserve defined ranges with VirtualAlloc) but on the other hand it falls in your back.

Yes, but the question is if you have such control over the loader.
The virtual memory when the process is running (ie VirtualAlloc & co) are unrelated to the loader which maps the different parts into the program virtual space.

Quote:

---

Originally Posted by Elysia

Yes, but the question is if you have such control over the loader.

---

In fact I was awaiting a proposal like "I once wrote my own loader to solve it", mabe from matsp ;)

Quote:

---

Originally Posted by Elysia

The virtual memory when the process is running (ie VirtualAlloc & co) are unrelated to the loader which maps the different parts into the program virtual space.

---

Of course, but in this case they are interconnected somehow.

I can't imagine that I'm the only one who did ever run into such a problem, even if this kind of IPC is no very common.

A poor solution would be to
-link everything you can static
-Link the self produced DLL's with fixed base address
-Allocate the memory range as the first call in main() (Thats because I found out today that Windows is a ..........: It often loads lot of DLLs delayed at run time, e.g. it loads two additional DLL's if you open a simple file dialog from the programs GUI)
-for the rest (mainly windows or other 3rd party DLLs) hope the best
But this doesn't satisfy me...

Well, I'm afraid I can't give you any solutions, so you'll have to waits for mats :P

Maybe not what you are looking for, but it somehow sounds to me that using Win32's Memory Mapped Files might be a simpler way to acheive what you trying to do.

MMF's allow for multiple processes to access the same data, in a fairly simple manner.

One important requirement for the kind of IPC to use was that it creates a peace of memory which can be mapped to the same base offset in the virtual memory of every process which takes part in the IPC. Reason is that pointers are hold inside the shared memory.
So you have two possibilities
1. use offset instead of pointers and interpret/adapt them inside every single process according to his own base address of the shared memory range. to slow
2. make sure the shared memory is on the same base address inside the virtual address space of every process. fast, but with the problems described here.

Thing is the problems of method two are inherent regarding the requirement for every kind of IPC one could come up with.

Quote:

---

1. use offset instead of pointers and interpret/adapt them inside every single process according to his own base address of the shared memory range. to slow

---

Why do you think this is too slow? Sounds like you just need to do a simple addition or subtraction on each pointer address. I doubt you would notice a speed difference.

It's some tree structure representing a huge terrain geometry which has to be queried fairly often and fast to keep up frame rate.
You are right, I should measure it. But I fear the adoptions needed to transform it to state one are to expensive in this state, so a solution to the original problem would be much better.