[osg-users] [SPAM] Re: Latest SVN: problems withPluginswithoutManifests

Thu Dec 13 09:17:27 PST 2007

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: osg-users-bounces at lists.openscenegraph.org [mailto:osg-users-bounces at lists.openscenegraph.org] 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 <lewandowski at ai.com.pl> 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
  osg-users at lists.openscenegraph.org
  http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20071213/c1a191c3/attachment.htm 