C++/How does an application find its required dlls?
I have found this article which explains DLL Loading: http://home.att.net/~raffles1/dll_loading_rules_in_win32.htm
This article has answered most of my questions. I believe I can understand the article better if you can help me on the following items:
1. How can I tell a dll is an ActiveX server?
2. How can I tell a dll is loaded by LoadLibrary using only the name of the DLL or using the complete path to the DLL?
I wonder whether Dependency Walker will tell me #1 and/or #2.
Thank you for your help.
I guess I do not ask my question too clear. Let me try again.
I want to know the sequence that an application locates its required dlls. I'm looking for more than just the DLL Search Order which is described in http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/lo
or your previour reply. I want to know for the following scenarios:
1. If a dll required by an app is already loaded by another app, what will happen? Does the app use the loaded dll or will locate the required dll based on DLL Search Order?
2. If dll/com redirection is used for an app, what will happen?
3. Does it make a difference for scenario #1 and #2 if the dll is a non-registered dll or registered dll?
4. Does it make a difference for scenario #1, #2, and #3 for the following OS: Windows 98 SE, Windows NT4, Windows 2000, Windows XP, Windows 2003?
Note: I will not use .manifest and .NET technology so those technology can be ignored. Also, I'm not the author of the required dlls. The required dlls are MS dlls and other vendor's dlls such as Crystal Reports.
When an application loads, how does it find its required dlls?
I think the following ways are how an application may find its required dlls but I don't know in which order:
1. Based on DLL Search Order
2. Based on registry information
3. Loaded DLLs
4. Application folder if dll/com redirection is used (.local file)
My understanding is that some types of dlls (I don't what types) are not required to be registered so I guess #2 won't apply to those dlls.
Thank you for any help.
Peter, Thank you for your question.
This appears to be a Windows question, not a C++ programming language question.
From the MSDN Library:
With both implicit and explicit linking, Windows first searches the set of pre-installed DLLs such as the performance library (KERNEL32.DLL) and the security library (USER32.DLL). Windows then searches for the DLLs in the following sequence:
1. The directory where the executable module for the current process is located.
2. The current directory.
3. The Windows system directory. The GetSystemDirectory function retrieves the path of this directory.
4. The Windows directory. The GetWindowsDirectory function retrieves the path of this directory.
5. The directories listed in the PATH environment variable.
Note that the LIBPATH environment variable is not used.
1. If a dll required by an app is already loaded by another app, Windows will increment the lock count on the module (represending the dll file) info block in memory and map the dll into memory, sharing pages with the other processes that are using that module. No searching in the file system is done.
2. I'm not sure what you mean by "dll/com redirection".
3. I'm not sure what you mean by "registered dll". Do you mean an activex control?
4. I do not think there are any major differences in dll-loading functionality among the various versions of Windows, but there are undoubtedly minor differences. I am not an expert in all the versions of Windows.
Peter, Wow, I didn't know that there were so many special cases!
1. I don't think there is any reliable way to examine a DLL and determine if it could be an ActiveX server. Of course, the presence of exported functions with names like DllGetClassObject, DllCanUnloadNow, and especially DllRegisterServer and DllUnregisterServer, are very strong indicators.
2. I can't imagine that a module loaded into memory has any associated indication of the specific pathname or method by which it was loaded. I believe the info block only contains the complete pathname ("exe path"), as well as the (internal) module name. The module name comes from the LIBRARY keyword in the DEF file, if any. If no such name was specified, the module name is the filename part of the complete path of the DLL.
I don't think the Dependency Walker helps much.
I suggest that you post your questions at www.experts-exchange.com, which is more advanced than allexperts.com.