Thanks for all this info. Its quite useful what you have found. We have another
completely non OSG related problem where your observations might help.
Its particularly interesting that manifest checking is done by runtime DLLs
itselves - so everyone can look at the runtime source code and see where their
problem lies.
Thanks again.
Wojtek
----- Original Message -----
From: Roger James
To: 'OpenSceneGraph Users'
Sent: Thursday, December 13, 2007 5:51 PM
Subject: Re: [osg-users] [SPAM] Re: Latest SVN: problems
withPluginswithoutManifests
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
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
