Is the DLL fully loaded or just some features?

Question

When a program uses a dynamic shared library, does it load the DLL completely (so that you can almost erase the DLL from disk while the application is running) or does it load only part of the DLL according to its needs at any given time during the life of the application?

Answer 1

DLL is fully loaded. DLLs are the same as EXEs in almost every aspect; the only big difference between the two: the dlls are not executable. It does not have a function main() - the beginning of the program .

Answer 2

I don’t know how the details work on Windows (on Linux, I know the responsible code in the kernel well), but at least on * nix systems that delete an entry on the file system, the contents of the file remain untouched as long as there is a handle / handle file, open on it; only after closing the last file descriptor / processing blocks on the storage device can be overwritten. Windows is POSIX certified, so it follows this behavior.

DLL files are not loaded into pre-allocated memory. They are mapped to memory . This causes the reverse side of the swap memory. Instead of exchanging RAM for disk, the contents of the file are mapped to the address space of the process and ends in RAM via the disk / file cache. The same goes for shared objects on * nix operating systems. But there are significant differences between Windows and * nix systems related to moving, exporting characters, etc.

Answer 3

It loads in its entirety, as indicated. The special part is not that you cannot run DLLs, it is that DLL memory pages are usually shared across process boundaries.

If a process tries to write to a page, a copy of this page will be taken and the copy will be visible only to this process (it is 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 (MMF or "sections" in the kernel-mode language). This means that the DLL file supports MMF, which represents the loaded DLL. This is the same as passing a valid file descriptor (not INVALID_HANDLE_VALUE ) to CreateFileMapping, as well as (part of) the reason you cannot delete the DLL when it is in use .

In addition, there are some DLLs that do not contain code at all. Such a DLL can also be loaded into a process that has not been executed for the same processor. For example. The x86 DLL resource loads fine in the x64 application.