Running the Executable Module

[Previous] [Next]

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's address space. The loader examines the executable's import section and attempts to locate and map any required DLLs into the process's address space.

Since 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 process's current directory
3. The Windows system directory
4. The Windows directory
5. The directories listed in the PATH environment variable

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's 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's 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, the user sees one of the two following message boxes: either the one on top for Windows 2000 or the one on the bottom for Windows 98.

After all of the DLL modules have been located and mapped into the process s 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 message box similar to the following two boxes: either the one on top for Windows 2000 or the one on the bottom for Windows 98.

It would be nice if the Windows 2000 version of this message box indicated which function was missing instead of the non-user-friendly error code of 0xC000007B. Oh well maybe the next version of Windows will do this.

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 s 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. Voila the dynamic link is complete, the process s 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 import section with the proper addresses of all the imported symbols. Since 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. I ll discuss rebasing and binding in the next chapter.