Solved

Calling a DLL from a DLL / LoadLibraryEx

Posted on 1999-01-05
5
665 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

Courses: Start Training Online With Pros, Today

Brush up on the basics or master the advanced techniques required to earn essential industry certifications, with Courses. Enroll in a course and start learning today. Training topics range from Android App Dev to the Xen Virtualization Platform.

Question has a verified solution.

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

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…
After several hours of googling I could not gather any information on this topic. There are several ways of controlling the USB port connected to any storage device. The best example of that is by changing the registry value of "HKEY_LOCAL_MACHINE\S…
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 …

808 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