- Forum
- Windows Programming
- Need some explanation about DLL
Need some explanation about DLL
Hi,
I am not getting what it actually means, as I am trying to understand what DLL is from the Microsoft documentation.
[1]. "Multiple processes that load the same DLL at the same base address share a single copy of the DLL in physical memory. Doing this saves system memory and reduces swapping."
[2]. "Every process that loads the DLL maps it into its virtual address space. After the process loads the DLL into its virtual address, it can call the exported DLL functions."
I will be very helpful if someone explain these in more details.
Thanks
I am not getting what it actually means, as I am trying to understand what DLL is from the Microsoft documentation.
[1]. "Multiple processes that load the same DLL at the same base address share a single copy of the DLL in physical memory. Doing this saves system memory and reduces swapping."
[2]. "Every process that loads the DLL maps it into its virtual address space. After the process loads the DLL into its virtual address, it can call the exported DLL functions."
I will be very helpful if someone explain these in more details.
Thanks
A protected mode operating system protects the system from a single program crashing the entire system. It does this by running each program in its own address space. The rest of this describes Windows.
The loader loads all the program code, and all DLLs that the linker lists. The program is loaded at some base address.
When a DLL is loaded, it's loaded at its base address. That address range is mapped into the processes address space. If multiple programs (or DLLs) load a DLL, if the DLL is already loaded at that base address, it's mapped into the process address space. So multiple programs loading the DLL doesn't cause multiple copies to exit in memory, the one copy is mapped into processes address space.
The exception is when the DLL is loaded and something is occupying that base address. It's loaded elsewhere and mapped in as usual, but it's not shared. When another load request comes alone, it's loaded into yet another address and mapped where needed. In short, the loader forgets where it put it.
Of course, once the DLL code is mapped into a programs address space, it has access to all the exported sybols in the DLL (both code and data).
The loader loads all the program code, and all DLLs that the linker lists. The program is loaded at some base address.
When a DLL is loaded, it's loaded at its base address. That address range is mapped into the processes address space. If multiple programs (or DLLs) load a DLL, if the DLL is already loaded at that base address, it's mapped into the process address space. So multiple programs loading the DLL doesn't cause multiple copies to exit in memory, the one copy is mapped into processes address space.
The exception is when the DLL is loaded and something is occupying that base address. It's loaded elsewhere and mapped in as usual, but it's not shared. When another load request comes alone, it's loaded into yet another address and mapped where needed. In short, the loader forgets where it put it.
Of course, once the DLL code is mapped into a programs address space, it has access to all the exported sybols in the DLL (both code and data).
Last edited on
@kbw
Thanks a lot for the explanation and you time for this! It is really very helpful.
Meaning every program is loaded at some base address.
[1]. Do you mean DLL is loaded at it own base address or it is loaded at the base address of the program?
Also when after the DLL gets loaded and mapped to a program's address space.
what about the Data, which have different value, if the DLL is getting used by two program?
[2]. "When a DLL allocates memory using any of the memory allocation functions (GlobalAlloc, LocalAlloc, HeapAlloc, and VirtualAlloc), the memory is allocated in the virtual address space of the calling process and is accessible only to the threads of that process."
Suppose I have a function in a DLL which dynamically allocated char buffer, and returns a pointer to the allocated buffer.
Can I call delete to that pointer from the program?
As most of the time I find a function provided by the DLL to release it!
Thanks a lot for the explanation and you time for this! It is really very helpful.
Meaning every program is loaded at some base address.
[1]. Do you mean DLL is loaded at it own base address or it is loaded at the base address of the program?
Also when after the DLL gets loaded and mapped to a program's address space.
what about the Data, which have different value, if the DLL is getting used by two program?
[2]. "When a DLL allocates memory using any of the memory allocation functions (GlobalAlloc, LocalAlloc, HeapAlloc, and VirtualAlloc), the memory is allocated in the virtual address space of the calling process and is accessible only to the threads of that process."
Suppose I have a function in a DLL which dynamically allocated char buffer, and returns a pointer to the allocated buffer.
Can I call delete to that pointer from the program?
As most of the time I find a function provided by the DLL to release it!
Last edited on
There's a difference between the virtual address space that each process is assigned and the ring 0 kernel address space.
The DLL is loaded into the system address space and mapped into various process address spaces on demand, depending who requested it.
The linker specifies the default base address for modules (programs and DLLs). Back in the old days when Windows NT was first release (v3.5), Borland ported its WIN16 tools to WIN32. But one oversight was they didn't realise the importance of the DLL base address (because Microsoft didn't document it) and all their DLLs had the same base address--as I've mentioned earlier, this is bad.
Programs can all have the same base address, they won't clash because each program has it's own address space.
In WIN16, all instances of DLLs shared global variables. Unix shared libraries don't work this way. And this was fixed in WIN32. In fact, code and data go into different segments within the executable file, so it's just a matter to deciding what to do with them. In WIN32, only code is shared. Data is not shared, so copies of data segments are given to each process; but it's just a matter of policy.
A side effect of this is the Windows app entry point WinMain. One parameter is the previous instance of the application. This worked in WIN16, but as programs run in different address spaces in WIN32, it's broken and so is never used in a WIN32 program.
You can play around with mapping memory yourself. That's how shared memory works on Windows (and Unix/BSD/Linux too).
The DLL is loaded into the system address space and mapped into various process address spaces on demand, depending who requested it.
The linker specifies the default base address for modules (programs and DLLs). Back in the old days when Windows NT was first release (v3.5), Borland ported its WIN16 tools to WIN32. But one oversight was they didn't realise the importance of the DLL base address (because Microsoft didn't document it) and all their DLLs had the same base address--as I've mentioned earlier, this is bad.
Programs can all have the same base address, they won't clash because each program has it's own address space.
In WIN16, all instances of DLLs shared global variables. Unix shared libraries don't work this way. And this was fixed in WIN32. In fact, code and data go into different segments within the executable file, so it's just a matter to deciding what to do with them. In WIN32, only code is shared. Data is not shared, so copies of data segments are given to each process; but it's just a matter of policy.
A side effect of this is the Windows app entry point WinMain. One parameter is the previous instance of the application. This worked in WIN16, but as programs run in different address spaces in WIN32, it's broken and so is never used in a WIN32 program.
You can play around with mapping memory yourself. That's how shared memory works on Windows (and Unix/BSD/Linux too).
Last edited on
| Suppose I have a function in a DLL which dynamically allocated char buffer, and returns a pointer to the allocated buffer. Can I call delete to that pointer from the program? |
No, you cannot safely delete memory allocated by a DLL from your main executable.
@kbw
Thanks. Now It is making some sense to me!
Anyway can you please share, how you know all these internals?
Any suggestion for me (as I am completely zero in this only know how to use this), reference, books etc.
Again thanks a lot.
Thanks. Now It is making some sense to me!
Anyway can you please share, how you know all these internals?
Any suggestion for me (as I am completely zero in this only know how to use this), reference, books etc.
Again thanks a lot.
Last edited on
@modoran
Thanks for your reply!
Yes, you are right! But I am looking for the explanations and reasons. What actually going underneath!
Thanks for your reply!
Yes, you are right! But I am looking for the explanations and reasons. What actually going underneath!
| When a DLL allocates memory using any of the memory allocation functions (GlobalAlloc, LocalAlloc, HeapAlloc, and VirtualAlloc), the memory is allocated in the virtual address space of the calling process and is accessible only to the threads of that process. |
VirtualAlloc() is the system page allocator on WIN32. HeapAlloc() is a suballocator that manages a block of memory (obtained from VirtualAlloc).
In WIN16, GlobalAlloc() is the main alloator. LocalAlloc() is the allocator that programs can use internally. It all comes from large model DOS programs and its far/near malloc. Anyway, it's all deprecated and the only WIN32 functions that use GlobalAlloc() are those that came over from WIN16; Clipboard, Atom, DDE, COM, ...
If a page is allocated by a DLL function in a process (VirtualAlloc), then any function in the process can free it. That should be obvious.
The problem is that C/C++ programs rarely need pages, they just need blocks of memory without caring about hardware crap, so they always use a suballocator. Memory taken from a suballocator must be free'd back to that suballocator. And that's the basic problem.
Take a Visual C++ built C or C++ app. You can specify how the run time library is linked. If all your modules share the C/C++ runtime library (as a DLL), then you can allocate in one module and free it in another. If you link in any other way, you can't.
Those are the basic issues. For your particular scenario, you'll have to decide if it meets the "one heap" criteria.
| Anyway can you please share, how you know all these internals? |
EDIT: check out
Windows Internals by Russinovich
Windows System Programming by Hart
Last edited on
I highly recommend the book Window via C/C++. It covers windows memory management, processes, and Dll's, among many other things. There's also a similar book Windows System Programming. I haven't read it but I hear only good things about it. Then there's Windows Internals. It isn't a programming book but gives a good overview of the things that make Windows tick.
Topic archived. No new replies allowed.