What is the sequence that an application locate its required dlls?

[pctest]

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/d...s/dllproc/base/load_time_dynamic_linking.asp.

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.

Thank you for any help.

 

[teriviret]

I think I can answer three of your questions:

1. It doesn't matter if another app has the same DLL already loaded. The app will still search for the DLL in the same way it would search for it if it wasn't already loaded in the other app.

2. I don't know the answer to this one, sorry.

3. No difference - registerring a DLL just adds COM registry keys, which only affects COM, not DLL loading in general

4. No difference that I know of, with two exceptions -- (1) .manifest files, but you already said to disregard that, and (2) Windows 2000 has a "DLL redirection" feature: [URL unfurl="true"]http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/load_time_dynamic_linking.asp[/url]

 

[pctest]

Hi teriviret,

I have found this excellent article about 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.

 

[teriviret]

Interesting -- I didn't know about side-by-side installations...

To answer your first question, I think when they're talking about ActiveX servers, they mean the case where the DLL is loaded indirectly by COM, not directly by calling LoadLibrary() from your app, or by it showing up in dependency walker. An ActiveX server DLL is loaded like that only if your app is creating an instance of the ActiveX component via CoCreateInstance() or similar function. If you are loading the DLL directly by calling LoadLibrary(), it is definitely not being loaded by COM as an ActiveX server.

You can tell if a DLL is a COM component by trying to register it using the "regsvr32" program. Pass the path to the DLL as a command-line argument to that program. If it comes back and says it was successfully registered, then it is definitely COM and possibly ActiveX. You could also look at the symbols the DLL exports, and check to see if it provide the function "DllRegisterServer". This is the funtion that "regsvr32" calls. Its presence almost always means the DLL has some COM components.

Now ActiveX components are a special kind of COM component. You can't really tell by inspection whether a COM server has ActiveX components and not just regular non-ActiveX components in it. One way I can think of is to use "oleview" or some other program and look to see if any registered ActiveX components specify the DLL for their InprocServer32 path. (In "oleview" all the ActiveX components are under the category called "Controls").

To answer your second question, if you are calling LoadLibrary() directly in your client program, just look to see if you specified the DLL by name or by full path. If you aren't calling LoadLibrary() directly, but the DLL shows up in the dependency walker, I believe in this case the DLL is always loaded by name and not by full path (I could be wrong, but I've never seen a DLL loaded by full path in this way).