• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 725
  • Last Modified:

Calling a DLL from a DLL / LoadLibraryEx

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
wannamak
Asked:
wannamak
  • 3
  • 2
1 Solution
 
wannamakAuthor Commented:
Edited text of question
0
 
jkrCommented:
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
 
wannamakAuthor Commented:
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
 
jkrCommented:
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
 
wannamakAuthor Commented:
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
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Cloud Class® Course: Microsoft Azure 2017

Azure has a changed a lot since it was originally introduce by adding new services and features. Do you know everything you need to about Azure? This course will teach you about the Azure App Service, monitoring and application insights, DevOps, and Team Services.

  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now