DLLs And Exes

Running the Executable Module


When an executable file is invoked, the operating system loader creates the virtual address space for the process.

Then the loader maps the executable module into the process' address space. The loader examines the executable's

import section and attempts to locate and map any required DLLs into the process' address space.

Because the import section contains just a DLL name without its pathname, the loader must search the user's disk

drives for the DLL.

 

Here is the loader's search order:

   1. The directory containing the executable image file

  
   2. The Windows system directory returned by GetWindowsDirectory

  

   3. The 16-bit system directory—that is, the System subfolder under the Windows directory

  

   4. The Windows directory returned by GetSystemDirectory

  

   5. The process' current directory
   

   6. The directories listed in the PATH environment variable

Notice that the application current directory is searched after the Windows directories. This change occurred in

 

Windows XP SP2 to avoid having fake system DLLs be found and loaded from the application current directory instead

of from their official location in the Windows directories. The MSDN online help mentions how a DWORD value under

HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Control/Session Manager could change this search order, but you

 

should never set it if you don't want to allow malware to compromise your machine. Be aware that other things can affect

 

how the loader searches for a DLL. (See Chapter 20 for more information.)

As the DLL modules are mapped into the process' address space, the loader checks each DLL's import section as well.

If an import section exists (and usually it does), the loader continues to map the additional required DLL modules

into the process' address space. The loader keeps track of the DLL modules that it is loading and maps a module

only once even if multiple modules require that module.

If the loader cannot locate a required DLL module, An error message box will come up.

After all the DLL modules have been located and mapped into the process' address space, the loader fixes up all

references to imported symbols. To do this, it again looks in each module's import section. For each symbol listed,

the loader examines the designated DLL's export section to see if the symbol exists. If the symbol does not exist

(which is very rare), the loader displays a error message box .

 

If the symbol does exist, the loader retrieves the RVA of the symbol and adds the virtual address of where the DLL

module is loaded (the location of the symbol in the process' address space). It then saves this virtual address in

the executable module's import section. Now, when the code references an imported symbol, it looks in the calling

module's import section and grabs the address of the imported symbol, and it can thus successfully access the

imported variable, function, or C++ class member function. When the dynamic link is complete, the process'

primary thread begins executing, and the application is finally running!

Naturally, it takes the loader quite a bit of time to load all these DLL modules and fix up every module's impor

section with the proper addresses of all the imported symbols. Because all this work is done when the process

initializes, there is no run-time performance hit for the application. For many applications, however, a slow

initialization is unacceptable. To help improve your application's load time, you should rebase and bind your

executable and DLL modules. Few developers know how to do this, which is unfortunate because these techniques

 

are extremely important. The system would run much better if every company performed these techniques. In fact, I

believe that operating systems should ship with a utility that automatically performs these operations.