Reserve a range in virtual memory at link time

This is a discussion on Reserve a range in virtual memory at link time within the Windows Programming forums, part of the Platform Specific Boards category; Hi all, is there any linker option (VC++ 2005) or something similar to force the winXp loader to keep a ...

  1. #1
    Registered User
    Join Date
    Nov 2006
    Posts
    519

    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!

  2. #2
    Registered User
    Join Date
    Nov 2006
    Posts
    519
    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.

  3. #3
    Registered User
    Join Date
    Nov 2006
    Posts
    519
    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)

  4. #4
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,548
    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 Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  5. #5
    Registered User
    Join Date
    Nov 2006
    Posts
    519
    Quote Originally Posted by Elysia View Post
    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 View Post
    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.

  6. #6
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,548
    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 Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  7. #7
    Registered User
    Join Date
    Nov 2006
    Posts
    519
    Quote Originally Posted by Elysia View Post
    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 View Post
    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...
    Last edited by pheres; 12-09-2009 at 10:20 AM.

  8. #8
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,548
    Well, I'm afraid I can't give you any solutions, so you'll have to waits for mats :P
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  9. #9
    Registered User
    Join Date
    Aug 2006
    Posts
    99
    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.

  10. #10
    Registered User
    Join Date
    Nov 2006
    Posts
    519
    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.

  11. #11
    Registered User
    Join Date
    Sep 2004
    Location
    California
    Posts
    3,246
    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.
    bit∙hub [bit-huhb] n. A source and destination for information.

  12. #12
    Registered User
    Join Date
    Nov 2006
    Posts
    519
    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.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Help with insert/delete binary search tree
    By Nazgulled in forum C Programming
    Replies: 39
    Last Post: 03-25-2009, 04:24 PM
  2. Help! -Linked Lists, Memory Allocation, Time Steps, Debugg
    By MetallicaX in forum C Programming
    Replies: 2
    Last Post: 03-14-2009, 08:50 PM
  3. Replies: 1
    Last Post: 03-30-2004, 01:57 PM
  4. I apologize. Good bye.
    By doubleanti in forum A Brief History of Cprogramming.com
    Replies: 14
    Last Post: 05-03-2002, 06:51 PM
  5. Exporting Object Hierarchies from a DLL
    By andy668 in forum C++ Programming
    Replies: 0
    Last Post: 10-20-2001, 01:26 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21