Explain the working mechanism of a DLL?

To understand the mechanism of a DLL lets take an example of an application App1 and C library as DLL. Application App1 calls as C function fopen() at run time.

During compilation and linking: App1.c

#include<stdio.h>

inr main(int argc, char *argv[])
{
  FILE *fp = NULL;
  fp = fopen(<file>, mode);
  fclose(fp);
}

Here App1 uses prototype of fopen() from stdio.h. This is an exported function of C library.
Also App1 has been linked with C library import file. After linking the binary of App1 has CODE/.TEXT, .DATA, .BSS and one extra section .idata. This .idata section contains the information of imported function and corresponding name of DLL.
Here the information is like
Name of the DLL: msvcrt.dll
Import function list: fopen(), fclose(), ..

Now lets us look into the sections of msvcrt.dll/C library executable. It has as normal CODE/.TEXT, .DATA, .BSS and one extra section .edata.

This export section contains a list of functions it exposes to the external world.
Export function list for msvcrt.dll: fopen(), fclose(), ..

Now suppose user executes App1. A chain of events occurs inside system.

• Operating system shell and loader reads and verifies this executable.
• Loader loads the code and data segments in memory.
• Creates BSS section and prepare stack.
• Before going to execution it looks for the imported DLLs from .idata section.
• It recursively loads all the dependent DLLs. If the specified DLL is already loaded then it only shares the pages to this task. If corresponding DLL not found or found corrupted then it quits.
• Now dynamic linker links all the imported symbols of App1 to all the exported symbols of the DLL. This is done by putting appropriate virtual address of exported function in imported function pointer list entries in .idata section of App1.
• In this way it resolves all the symbols in the import table. If wrong version of dll is loaded or some of the imported function are not available then it quits.
• Finally if all goes well. It starts execution.
• When App1 calls an imported function it actually calls the corresponding entry in import table. As the import table entry contains the proper virtual address of the function thus it jums to the function inside DLL.

The above steps are true for implicit linking. For explicit linking we do not use .idata section thus loader does not load the DLL at startup. It loads at runtime. For this user has to implement this import table mechanism all by itself by the use of function pointer/function pointer list. We have explained this explicit linking mechanism in detail in later section named [What is implicit and explicit linking in dynamic loading?].

About our authors: Team EQA

You have viewed 1 page out of 27. Your DLL learning is 0.00% complete. Login to check your learning progress.

‹ # ›