Solved

Calling a DLL from a DLL / LoadLibraryEx

Posted on 1999-01-05
5
666 Views
Last Modified: 2013-12-03
Consider application \a\foo.exe, which loads \b\first.dll via LoadLibraryEx( "\\b\\first", NULL, LOAD_WITH_ALTERED_SEARCH_PATH ).  Now, first.dll tries to access \b\second.dll via LoadLibraryEx( "second", NULL, 0 ) or LoadLibraryEx( "second", NULL, LOAD_WITH_ALTERED_SEARCH_PATH )...
both fail.  Just what does the ALTERED_SEARCH_PATH flag apply to?  MS documentation says it applies to "any associated executable modules that the specified module causes to be loaded."  Yes LoadLibrary can't find second.dll -- is there a way around this?  Hardcoding the path to second.dll inside first.dll is not an option.
0
Comment
Question by:wannamak
  • 3
  • 2
5 Comments
 

Author Comment

by:wannamak
ID: 1418116
Edited text of question
0
 
LVL 86

Accepted Solution

by:
jkr earned 150 total points
ID: 1418117
As the docs state:
Note that the standard file search strategy and the alternate search strategy differ in just one way: the standard strategy starts its search in the calling application’s directory, and the alternate strategy starts its search in the directory of the executable module that LoadLibraryEx is loading.

As far as i can see (without hardcoding the path to the DLLs, which is indeed never a good idea), the only options you have are
- to place (both) '\a' and '\b' in your path environment
- install both DLLs in a 'well known' directory (such as the system or the windows directory
- install both DLLs in the application's directory
0
 

Author Comment

by:wannamak
ID: 1418118
The documentation is filled with phrases such as "the function uses the alternate file search strategy to find associated executable modules that the specified module causes to be loaded."  In my mind, my example is one where the "specified module" (first.dll) causes another (second.dll) to be loaded, yet the alternate search strategy fails.  I guess my question boils down to what the alternate search strategy applies to?

It does not apply to the "specified module" being loaded, as
LoadModuleEx( "\\b\\first.dll", NULL, 0 -or- LOAD..PATH ) works fine.

And it does not apply to other modules that the "specified module" loads, as
my original example fails.

For what, I wonder, does LoadLibraryEx search with the alternate strategy?

0
 
LVL 86

Expert Comment

by:jkr
ID: 1418119
As you specified a path in the call, it searches _associated_ modules in the 'alternate' path, e.g. if the DLL you're attempting to load has references to other modules, e.g. to '\\b\\third.dll'.
So, if e.g. '\anypath\anyexe.exe' loads '\b\first.dll' which attmpts to load '\b\second.dll' (explicitly!), the reference to the 'alternate' search path used before is superseded by the new context... If you used an import lib to bind 'second.dll' to 'first.dll', it should work as the docs state.
(And: I absolutely agree about the phrases)
0
 

Author Comment

by:wannamak
ID: 1418120
So the LOAD..PATH flag only applies to other dlls that have been _implicitly_ linked, not _explicitly_ (by LoadLibraryEx)!  For some reason, the fact that it was a parameter to LoadLibraryEx threw me off.  Thanks.
0

Featured Post

Free Tool: IP Lookup

Get more info about an IP address or domain name, such as organization, abuse contacts and geolocation.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

In this article, I will show how to use the Ribbon IDs Tool Window to assign the built-in Office icons to a ribbon button.  This tool will help us to find the OfficeImageId that corresponds to our desired built-in Office icon. The tool is part of…
With most software applications trying to cater to multiple user needs nowadays, the focus is to make them as configurable as possible. For e.g., when creating Silverlight applications which will connect to WCF services, the service end point usuall…
This is Part 3 in a 3-part series on Experts Exchange to discuss error handling in VBA code written for Excel. Part 1 of this series discussed basic error handling code using VBA. http://www.experts-exchange.com/videos/1478/Excel-Error-Handlin…
Microsoft Active Directory, the widely used IT infrastructure, is known for its high risk of credential theft. The best way to test your Active Directory’s vulnerabilities to pass-the-ticket, pass-the-hash, privilege escalation, and malware attacks …

856 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question