Jump to content
  • Advertisement
Sign in to follow this  
Hunter_Ex

Do dll and process share memory?

This topic is 4837 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

hey if i load up a dll in my process do that dll use the same memory like if i load up a dll and the dll loads a value from a pointer in the exe process will i get the real value from the process then? for example will

int variable;
variable = *pointer; // pointer can be 200000 for example


will variable obtain the same value no matter if i call it from the process or dll?

Share this post


Link to post
Share on other sites
Advertisement
Processes have address spaces. Threads and modules in a process access that process' address space; they don't have their own.

Share this post


Link to post
Share on other sites
Quote:
Original post by Hunter_Ex
hey if i load up a dll in my process do that dll use the same memory
like if i load up a dll and the dll loads a value from a pointer in the exe process


I'm not sure what you're trying to ask here.

DLLs are not processes. They don't have their own address space. Any function call in a DLL is executed in the address space of the process. Any pointer can be passed from the main program, to the DLL, and back again, with no problem, because it's just the same address space.

If there are several programs using the same DLL, each has its own address space and its own copy of any dynamically allocated memory.

The DLL appears as if it was just copied into the address space of each process which used it (it isn't *actually* copied, but that doesn't matter)

Mark

Share this post


Link to post
Share on other sites
This is a fairly complex question, because it depends on several different variables that you have yet to state. For instance, are you statically linking or dynamically loading the DLL? COM? What kind of appartments are you using if you are using COM...etc.

In general, a statically linked DLL will have it's functions mapped into the address space of the process that linked to it. Thus they share things like the heap, and other features. However, This isn't always the case, and can cause problems for certain things like when copying strings across DLL boundries. Dynamic linkage, for instance, will often have this problem (although not always).

Share this post


Link to post
Share on other sites
Dynamically loaded dlls are also mapped into the address space of the process. The problem with strings arises when a dll is used to cross process boundaries and an attempt is made to pass a string from one process to another. The typical Win32 approach to dealing with this is to pass the string inside a WM_COPYDATA message.

Share this post


Link to post
Share on other sites

Threads are coerced to have the same address space as the parent process by the kernel.

Static linking of a dll is dynamic linking automated by the compiler (the same thing happens).

There are flags you can set that control whether each dll "instance" shares global variables or has it's own private copy (it will be shared between processes). The code segment is shared.

Each dll needs to initialize the C run-time, so they end up with seperate heaps (malloc/free) and free-stores (new/delete).

As mentioned in another post, if all the dll's use the same shared version of the CRT (e.g. v7 multi-threaded dll), you can get away with passing stuff between them because all the dynamic memory will be allocated by that dll.

Share this post


Link to post
Share on other sites
Quote:
Original post by Shannon Barber
Threads are coerced to have the same address space as the parent process by the kernel.


Coerced? Threads don't have address spaces, processes do.

Quote:
Original post by Shannon Barber
Static linking of a dll is dynamic linking automated by the compiler (the same thing happens).


Automated by the compiler? Seems to me that the linker has more to do with it than the compiler and that the kernel's loader has more to do with the dynamism than either the compiler or the linker.

Quote:
Original post by Shannon Barber
There are flags you can set that control whether each dll "instance" shares global variables or has it's own private copy (it will be shared between processes). The code segment is shared.


#pragma data_seg I presume?

Quote:
Original post by Shannon Barber
Each dll needs to initialize the C run-time, so they end up with seperate heaps (malloc/free) and free-stores (new/delete).

As mentioned in another post, if all the dll's use the same shared version of the CRT (e.g. v7 multi-threaded dll), you can get away with passing stuff between them because all the dynamic memory will be allocated by that dll.


There should be no problem passing strings between dlls loaded into the same process - provided the reason for passing strings isn't to free them. That is to say that a string allocated in dll A needs to be deallocated in dll A, but it can be sent to an output function from dll B for example.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!