Do dll and process share memory?

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

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 on other sites
Processes have address spaces. Threads and modules in a process access that process' address space; they don't have their own.

Share on other sites
Quote:
 Original post by Hunter_Exhey if i load up a dll in my process do that dll use the same memorylike 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 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 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 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 on other sites
Quote:
 Original post by Shannon BarberThreads 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 BarberStatic 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 BarberThere 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 BarberEach 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.

• What is your GameDev Story?

In 2019 we are celebrating 20 years of GameDev.net! Share your GameDev Story with us.

(You must login to your GameDev.net account.)

• 15
• 14
• 46
• 22
• 27
• Forum Statistics

• Total Topics
634046
• Total Posts
3015224
×