|Important||This document may not represent best practices for current development, links to downloads and other resources may no longer be valid. Current recommended version can be found here. ArchiveDisclaimer|
LoadLibrary and AfxLoadLibrary
Processes call LoadLibrary (or AfxLoadLibrary) to explicitly link to a DLL. If successful, the function maps the specified DLL into the address space of the calling process and returns a handle to the DLL that can be used with other functions used in explicit linking such as GetProcAddress and FreeLibrary.
LoadLibrary attempts to locate the DLL using the same search sequence used for implicit linking. If the system cannot find the DLL or if the entry-point function returns FALSE, LoadLibrary returns NULL. If the call to LoadLibrary specifies a DLL module already mapped into the address space of the calling process, the function simply returns a handle of the DLL and increments the module's reference count.
If the DLL has an entry-point function, the operating system calls the function in the context of the thread that called LoadLibrary. The entry-point function is not called if the DLL is already attached to the process because of a previous call to LoadLibrary with no corresponding call to the FreeLibrary function.
MFC applications loading extension DLLs should use AfxLoadLibrary instead of LoadLibrary. AfxLoadLibrary handles thread synchronization before calling LoadLibrary. The interface (function prototype) to AfxLoadLibrary is the same as LoadLibrary.
If for some reason Windows cannot load the DLL, the process can attempt to recover from the error. For example, the process could notify the user of the error and have the user specify another path to the DLL.
If the code is to run under Windows NT 4, Windows 2000, or Windows XP (prior to SP1), make sure to specify the full path name of any DLLs. On these operating systems, the current directory is searched first when loading files. If you do not quality the path to the file, a file can be loaded that was not intended.