Dynamic link when loading
When the system starts a program that is dynamically linked to the file, the system is used to locate the DLL of the process to locate the DLL required by the process. Then search the DLL in the following location:
The application loads the current directory system directory. By tabindex = "0" keywords = "base.getsystemDirectory" errorURL = "../common / badjump.htm> getSystemDirectory function can be obtained. 16-bit system catalog. No functions can get the directory, but it is searched. Windows ME / 98/95: The directory does not exist Windows directory. By tabindex = "0" keywords = "base.getWindowsDirectory" error = "../ Common / badjump.htm> getWindowsDirectory can be obtained. The directory listed in the PATH environment variable.
Windows Server 2003, Windows XP SP1: HKLM / System / CURRENTCONTROLSET / Control / Session Manager / SafedllSearchMode default is 1 (search after the current directory after the system and Windows directory).
Windows XP: If HKLM / SYSTEM / CURRENTCONTROLSET / Control / Session Manager / SafedllSearchMode is 1, the current directory is searched after the system and windows directory, but before the directory listed in the PATH environment variable. The default is 0 (search for the current directory before the system and the Windows directory). Note that this value is cached when loading is cached on the basics of each thread.
If the system does not find the required DLL, the process will terminate and display a dialog report error message. Otherwise, the system maps the DLL to the virtual location space of the process and increases the DLL reference count.
Then the system calls the entry point function, the function receives a code indicating that the process is loading the DLL. If the entry point function does not return True, the system will terminate the process and report an error. For more information on entry point functions, see "Dynamic Link Library Entry Point Functions".
Finally, the system modifies the function address table with the startup address of the import DLL function.
The DLL will be mapped to the virtual location space of the process during initialization and is only loaded into physical memory only when needed.
Running dynamic link
When an application is called a loadLibrary or LoadLibraryEx function, the system will try to position the DLL when the dynamic link search order is loaded (see when using the load). If found, the system maps the DLL module to the virtual site space of the process and increase the reference count. If you call LoadLibrary or LoadLibraryEx, the specified DLL its code has mapped to the virtual address space of the calling process, the function returns only the handle of the DLL and adds the DLL reference count. Note: Two DLLs with the same file name and extension but not in the same directory are considered not the same DLL.
The system calls the entry point function in the thread context calling the LoadLibrary or LoadLibraryEx. If there is already a process, the DLL is loaded by calling the LoadLibrary or the LoadLibraryEx function, and the FREELIBRARY is not called, the entry point function will not be called again.
If the system can't find a DLL, or the entry point function returns false, LoadLibrary or LoadLibraryEx will return NULL. If the loadLibrary or LoadLibraryEx call is successful, the handle of the DLL module will be returned. The process can identify the DLL of the getProcadDress, FreeELibrary or FreelibraryAndexitthread function via this handle identifies.
The handle returned by GetModuleHandle can be used by getProcaddress, FreeELibrary or FreElibraryAndexitthread. GetModuleHandle will only be successful when the DLL is linked or the top LoadLibrary, the loadLibraryEx called the address space that is mapped to the process. GetModuleHandle does not increase the reference count of the module. The getModuleFileName function acquires the full path associated with the handle returned by getModuleHandle, LoadLibrary or LoadLibraryEx. The module can return the handle returned by getModuleHandle, LoadLibrary or LoadLibraryEx, and then call GetProcAddress to get the address of the exit function in the DLL.
If you no longer need a DLL module, the process can call freeelibrary or freeelibraryandexitthread (release). These functions will reduce the reference count of the module and if the reference count is 0, the DLL mapping will be canceled from the virtual address space from the process.
Dynamic links with runtime Even if the DLL is unavailable, the process can continue to run, and then the process can achieve the ultimate goal through a change method. For example, if the process cannot find a DLL, it can try another or prompt the user. If the user can provide the full path of the lost DLL, the process can use the path information regardless of whether it is in a normal search path. However, if it is linked when it is loaded, the system will terminate.
When using the runtime dynamic link, if the DLL uses the dllmain function to complete the initialization of each thread of the process, it will generate a problem, because the thread is not called before the thread is called before the LoadLibrary or LoadLibraryEx call. For example, how to deal with this problem, refer to the "Thread Local Storage of Dynamic Link Library".
