When a program uses a dynamic shared library, does it load the DLL entirely (so you can almost erase the DLL from disk during application is running) or does it load only a part of the DLL according to its need at each time during the runtime life of the application?
Asked
Active
Viewed 1,129 times
9
-
+1, but how is this related to C++? – Armen Tsirunyan Feb 24 '11 at 18:55
-
because I speak specifically about C++ .exe which are using a DLL, but indeed maybe no matter the programming langage use the behavior is always the same – Guillaume Paris Feb 24 '11 at 19:33
-
Using LoadLibrary() puts a lock on the DLL file. You can rename it but you can't write to it. – Hans Passant Feb 24 '11 at 20:04
-
@Hans: ok so it's perfectly valid if I rename DLL fille, replace it with a new one wich will be loaded at next applications's start up ? – Guillaume Paris Feb 24 '11 at 20:18
-
Yes. You can delete the renamed DLL afterward. – Hans Passant Feb 24 '11 at 20:35
3 Answers
7
DLL gets loaded entirely. DLLs are same as EXEs in almost all aspect; the only big difference between them is, DLLs are not executable. It doesn't have main() function - the start of a program.
-
As an addition, a dll has a DllMain function which gets called when the dll is loaded and unloaded – Armen Tsirunyan Feb 24 '11 at 18:56
-
1@Armen: Yeah. But DllMain is more like *initialize* and *deinitialize* function! – Nawaz Feb 24 '11 at 18:57
-
It's like a shared library that's linked to your executable dynamically :P – AJG85 Feb 24 '11 at 19:05
-
2@Armen: `DllMain` is optional. It may be omitted when using the `/NOENTRYPOINT` linker. – André Caron Feb 24 '11 at 19:18
5
I don't know how the details work in Windows (in Linux I know the responsible code in the kernel quite well), but at least in *nix systems deleting a filesystem entry leaves the file contents intact as long there are file descriptor/handles opened on it.; only after closing the last file descriptor/handle the blocks on the storage device may get overwritten. Windows is POSIX certified, so it follows this behaviour.
DLLs are not loaded into preallocated memory. They're memory mapped. This causes kind of the reverse of swap memory. Instead of swapping RAM to a disk, the contents of the file are mapped into process address space and will end up in RAM through disk/file cache. The same goes for shared objects in *nix operating systems. But there are significant differences between Windows and *nix systems deal with relocations, symbol exports and so on.
datenwolf
- 159,371
- 13
- 185
- 298
-
1+1. They are indeed MMFs and the reverse swapping is a good image to explain MMFs in general. – 0xC0000022L Feb 24 '11 at 19:19
-
Similar behavior may be implemented in Windows DLL files using the `/DELAYLOAD` linker flag. See http://msdn.microsoft.com/en-us/library/151kt790.aspx – André Caron Feb 24 '11 at 19:21
-
but i have managed to overwritten the DLL while the application was up – Guillaume Paris Feb 24 '11 at 19:55
-
@Guillaume07: Overwriting is something different than deleting the filesystem entry. This actually "corrupts" the contents. – datenwolf Feb 24 '11 at 19:57
-
@STATUS_ACCESS_DENIED: The reverse swapping is not just a way to explain this thing. In Linux the code responsible for page swapping also deals with memory mapped file access. I don't know the details of how Windows does it though, but it's probably similar. – datenwolf Feb 24 '11 at 19:59
-
@datenwolf: well, that holds for Windows, too. The mechanisms are shared here as well. However, so it's not a just a way to explain this ... huh? I said it's a nice way to explain it (to someone without knowledge of the nethers of the system), i.e. I seconded your argument and now you say it's not ... ah well, it's beyond me. English is not my native language, so this would be it :-| – 0xC0000022L Feb 24 '11 at 20:05
-
@Guillaume07: can we see some code? I am aware of some techniques that worked up until XP SP1 or so for .exe files, but I've never seen anything do what you claim purely from user mode. – 0xC0000022L Feb 24 '11 at 20:06
-
@STATUS_ACCESS_DENIED: I didn't negate, I said that my argument wasn't only a mere example but the actual thing. I just wanted to point that out, since your first comment may mislead some people that there's some different mechanisms at work (+1 for your first comment). – datenwolf Feb 24 '11 at 20:07
-
@André Caron: can you explain what delay-loaded DLLs have to do with datenwolf's explanation or the original question, please. – 0xC0000022L Feb 24 '11 at 20:08
-
@datenwolf: I see. My bad. Seems one cannot edit a comment after some time, so I can't fix it there. Thanks for the +1. – 0xC0000022L Feb 24 '11 at 20:09
0
It's being loaded entirely, as was pointed out. The special part is not that you can't run the DLL, it's that the memory pages of a DLL are usually shared across process boundaries.
Should a process attempt to write into a page, a copy of that page is taken and the copy is only visible to this process (it's called copy-on-write).
DLLs are PE files (i.e. the same as NT drivers or Win32 programs). They are loaded similarly to .exe files into Memory Mapped Files (MMFs, or "sections" in kernel mode parlance). This means that the DLL file is backing the MMF that represents the loaded DLL. This is the same as when passing a valid file handle (not INVALID_HANDLE_VALUE) to CreateFileMapping and it's also (part of) the reason why you can't delete the DLL while it is in use.
Also, there are some DLLs that contain no code at all. Such a DLL can then also be loaded into a process that was not made for the same processor. E.g. the x86 resource DLL loads fine into an x64 application.
0xC0000022L
- 20,597
- 9
- 86
- 152
-
I have a application in production which can't be shutdown, and I need to change the DLL version ,I did it during the application was UP.... – Guillaume Paris Feb 24 '11 at 19:37