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 ;-) 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 ----- Original Message ----- From: Roger James To: 'OpenSceneGraph Users' Sent: Thursday, December 13, 2007 2:41 PM Subject: Re: [osg-users] [SPAM] Re: Latest SVN: problems with Pluginswithout Manifests Wojtek, I think the problem you are hitting here is caused by the windows library loading code checking if a module (dll, etc) which has the same base file name (i.e. name excluding any path components) as the module to be loaded has already been loaded into the process address space. If a matching module is found then all the manifest, dll redirection, and dll search path stuff is ignored and a handle to the already loaded module is returned. All the VC8 onwards c runtime dlls have a routine in their initialisation code called __check_manifest. This routine attempts to check whether the dll has been loaded via the assembly/manifest mechanism and spits out the R6034 error if it thinks is has not. If you have the c runtime sources (a full install of visual studio) you can put a break point on this function and step into it to see what is happening. This routine is why trying to load the c runtime dlls outside the manifest mechanism is usually a bad idea. Roger ------------------------------------------------------------------------------ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wojciech Lewandowski Sent: 12 December 2007 14:42 To: OpenSceneGraph Users Subject: [SPAM] Re: [osg-users] Latest SVN: problems with Plugins without Manifests Serge, I have created a test solution for my case. It is very simple Exec which dynamically loads DLL where osgViewer is initalized nad run. It allowed me to further narrow the scenario and see where actual problem appears. See attached example. In this example Release version will run but Debug version will crash. Release version works because executable uses shared Mutlithreded DLL CRT but Debug version does not because it was built with Mutlithreaded Debug CRT which is different than OSG plugin build model. It seems that everything is ok when both application, dynamicaly loaded modules, OSG libs and plugins are build using the same code generation model which implies use of the same runtime libs. In our problematic case Apllication was actually built with multithreaded static CRT. But modules were built with Multithread DLL model. In our app I could freely change all projects to Multithread DLL / Multithread Debug DLL and then problem disappeared. On the other hand it is perfectly correct approach to build app using one environment and dynamic modules/plugins using other environment. This is how many plugin sdks work for various comercial apllications. I wonder what will happen when OSG is built using static linking. Regards, Wojtek Lewandowski ----- Original Message ----- From: Wojciech Lewandowski To: OpenSceneGraph Users Sent: Tuesday, December 11, 2007 4:39 PM Subject: Re: [osg-users] Latest SVN: problems with Plugins without Manifests Hi, Serge, Looks like I used the same runtime DLLs and manifest files. Manifests were taken from WinSxS and renamed to Microsoft.VC80.CRT.manifest and Microsoft.VC80.DebugCRT.manifest. Its really puzzling that plugins without manifests work when OSG libs are linked with executables but it does not work for our App when they are linked with dynamically loaded DLLs. I saw your recent submission where you reverted Cmake generation for manifest linking - before Robert puts them into SVN I actived manifest linking in my OSG solution. I gave up. Don't have time for this struggle now. Maybe will get back to this later. On many Microsoft manifest related documentation pages they state that bulids without manifests are not supported so I wouldn't expect that we may be able to resolve this issue. Thanks, Wojtek ----- Original Message ----- From: Serge Lages To: [EMAIL PROTECTED] ; OpenSceneGraph Users Sent: Tuesday, December 11, 2007 9:34 AM Subject: Re: [osg-users] Latest SVN: problems with Plugins without Manifests On Dec 10, 2007 9:49 PM, Wojciech Lewandowski <[EMAIL PROTECTED]> wrote: Thanks for assistance, I will further investigate it. I use XP SP2. Something that may be important here is the fact that our app loads OSG dynamically. We have our program divided into DLL components and some of these components are linked with OSG libs. Components are selected and loaded at run time based on application config. So in in this way OSG is also loaded dynamically. It used to work flawlessly till now. One more thing, I doubt its related, but these XP are Polish language version. I assume you have msvcp80d / msvcp80 / msvcr80 and msvcr80d dlls + release and debug runtime manifests stored in 3rd party binaries or somewhere else on the system path. Where tey are located ? Can you send me these files ? I guess manifest should suffice in case you use standard SP80 VS1 redist (version 8.0.50727.762) . I took my dlls from Windoiws/WinSxS redist directory because I could not find them in the folder where I got VS8 Express installed. Maybe manifest should be modified and differ somehow than the one stored in WinSxS directory ? If I made a mistake then it must have been a manifest which was wrong. Hi Wojciech, The fact that you load OSG dynamically must be the point that make it break... About the msvc*.dll, on my dev machine I use the ones located into WinSxS (without putting them into another directory), and when I redistribute an app, I put the folder joined to this mail into the main binary folder. The simpliest way to solve it is to make it optional in CMake to generate or not the manifests, I will make the change and submit it to Robert this morning. Cheers, -- Serge Lages http://www.tharsis-software.com ---------------------------------------------------------------------------- _______________________________________________ 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
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
