I was slightly wrong in what I said originally. The os does not ignore the
searching sequence if the dll is already loaded it just does not load the
module and does not call the dlls entry point with DLL_PROCESS_ATTACH.
Here is the full sequence on LoadLibrary.
An "Activation Context" is basically an in memory copy of relevant bits of a
manifest either loaded from an embedded resource or in the case of an exe
maybe an external file.
1. Try to locate the dll file using the current "Activation Context".
For an application the current activation context will probably be the one
created from the applications manifest either embedded in the exe or read
from a related file.
2. If the file is not located using the activation context (dependant
assembly stuff) then look for it using the normal dll search path.
3. Is still not found give an error.
4. If found but a module with a matching base file name is already
loaded just return a handle to the already loaded dll.
5. If no matching module loaded then map the dll file into the process
address space.
6. Try and create a new "Activation Context" using resource ID 2 from
the new module.
7. If this succeeds then try to resolve any static imports using this
new Activation Context otherwise use the existing one. Perform this whole
process recursively if any new dlls are loaded at this point.
8. Once all static imports have been resolved the call the dlls entry
point (DLL_PROCESS_ATTACH).
9. Only when the dll entry point returns, restore the original
"Activation Context" and return control to the calling app.
However there is one important fact that is missing here. Which I had
forgotten about until I looked again at the osgDB::DynamicLibrary and
remembered this:
DynamicLibrary* DynamicLibrary::loadLibrary(const std::string& libraryName)
{
HANDLE handle = NULL;
std::string fullLibraryName = osgDB::findLibraryFile(libraryName);
if (!fullLibraryName.empty()) handle = getLibraryHandle( fullLibraryName
); // try the lib we have found
else handle = getLibraryHandle( libraryName ); // havn't found a lib
ourselves, see if the OS can find it simply from the library name.
That bit that is missing is that LoadLibrary will not search the activation
context or the search paths if the name supplied to it contains any path
information even a partial one. So in the above code the first call to
LoadLibrary may or may not use the searching mechanism depending on what
findLibraryName returns, but the second call always will!.
Roger
_____
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Serge Lages
Sent: 13 December 2007 15:35
To: OpenSceneGraph Users
Subject: Re: [osg-users] [SPAM] Re: Latest SVN: problems with
PluginswithoutManifests
Hi Wojtek,
On Dec 13, 2007 4:11 PM, Wojciech Lewandowski <[EMAIL PROTECTED]> wrote:
Roger,
I totally agree with you that manifests should probably stay in plugins. I
made my research out of curiosity.
I may add that indeed this mechanism looks like you described. Its
interesting though that problem does disappear only if the executable loaded
MSVCRT DLLs. If they were not loaded by exe but instead loaded later in DLL
loading cascade - problem still remained. That was the case with our
original app. Exe was built with static linking. It was loading our
aditional DLL modules dynamically (through LoadLibrary). These module were
using the same shared MSVCRT DLL libs and OSG libs as OSG Plugins. So when
these modules loaded, proper MSVCRT DLLs were loaded as well. But even after
loading these modules attempts to read some media with osgDB plugins
produced error messages.
On a side note, I have problems in understanding why removing manifest from
plugins could save users time if main libs were still built with manifests
embeded and thus we sitll got the dependecy. Of course its feasible to build
some application using former version of OSG and former MSVCRT and later
update OSG plugins only. But who would do this ? It seems highly rare and
unprobable in practice. But heck, what do I know ? People do so many strange
things with computers these days ;-)
Removing manifest helps when you want to redistribute an OSG application
without asking to the users to install the MS redistributable package.
Removing it from the plugins and not the core dlls is done because the
plugins are distributed into a separated folder, if you don't remove the
manifests, you have to put in each folders where dlls are located a copy of
the CRT dlls, without manifests, you only need to put the CRT dlls into the
executable folder.
Of course it's not a common usage, that's why now the manifests are build by
default. :)
But I suspect that such Plugins in some way would still depend on MSVCRT lib
which was used to build them. If they would work that would be great, but if
they would crash no one would be able to find that the reason that was
incompatibilty in runtime libs (back to the DLL hell ;-).
Regards,
Wojtek
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
