LoadLibrary and AfxLoadLibrary
Processes call LoadLibrary (or AfxLoadLibrary) to explicitly link to a DLL. If the function succeeds, it 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 in explicit linking—for example, GetProcAddress and FreeLibrary.
LoadLibrary attempts to locate the DLL by using the same search sequence that is 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 that is already mapped into the address space of the calling process, the function returns a handle of the DLL and increments the reference count of the module.
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 that has no corresponding call to the FreeLibrary function.
For MFC applications that load extension DLLs, we recommend that you use AfxLoadLibrary instead of LoadLibrary. AfxLoadLibrary handles thread synchronization before you call LoadLibrary. The interface (function prototype) to AfxLoadLibrary is the same as LoadLibrary.
If 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 ask the user to 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 of any DLLs. On these operating systems, the current directory is searched first when files are loaded. If you do not qualify the path of the file, a file that is not the intended one might be loaded.