DLLs and friends

Daniel Murphy yebblies at nospamgmail.com
Sat Nov 24 17:04:05 PST 2012


"Gor Gyolchanyan" <gor.f.gyolchanyan at gmail.com> wrote in message 
news:mailman.2175.1353679685.5162.digitalmars-d at puremagic.com...
> Can someone please explain to me what "_declspec(dllimport)",
> "__declspec(dllexport)" (both of which are just "export" in D) are for,
> what the ".def" files (which are supposed to be if the 
> __declspec(whatever)
> are missing) are for, what is an import library and how this all makes
> sense.
>

When linking an application, the linker creates an import table which 
contains the dllname+functionname of each imported function.  Dlls contain 
an export table giving the address for each exported function.  At load 
time, the loader walks the import table of each module (dlls generally have 
import tables too) and searches for the appropriate function address, which 
it then writes into the import table.

The other thing you need is a import library file - these contain a set of 
mappings from the function's mangled name to the function's exported name. 
This is needed because the 'export name' of the function is not usually the 
same as the mangled name, at least not for windows api functions.  Exported 
functions don't actually need to be named, each has a unique number you can 
import it with.

.def files are essentially a human readable version of the import library 
file.

eg.
App uses CloseHandle
Linker sees symbol _CloseHandle at 4
Finds import definition in kernel32.lib: _CloseHandle at 4 -> 
kernel32.dll:CloseHandle
Adds that entry to the import table
Loader maps in kernel32.dll and resolves the address.

Using LoadLibrary/GetProcAddress is very similar, but happens later in the 
process:

App is loaded:
LoadLibrary maps the dll into the current process (or increases the 
reference count if it's already loaded)
GetProcAddress walks the export table looking for the function. 




More information about the Digitalmars-d mailing list