On 30 Jul 2010 at 8:22, David Aldrich wrote: > Thanks for your reply. I have now succeeded in creating a manifest file > for an assembly that includes the boost_python dll's. But I don't > understand how to specify a non-default location for the assembly using > that manifest. I believe this is done using 'probing' in Windows 7 but I > think that is unsupported in XP.
I thought that the application installer registered the DLL manifests at their locations? It's like registering COM or .NET objects, in fact I think it's the same mechanism nowadays. > So maybe I shall have to use delayed loading after all. Which brings me > back to my original question, has anyone succeeded in delay loading > boost_python under Visual C++? Well, the method you outlined ought to be prevented by the system and certainly by any competent anti-virus. It would be ripe for exploitation. As for why it doesn't work when others do, I would guess it's due to how the BPL machinery sets itself up on process init. During static init the BPL library sets up all sorts of runtime information which is later used by BPL clients, and during all of this it is extremely important that everything be kept in precisely the right order. Put another way I would be extremely doubtful that you can delay load the BPL library. Your best bet it would seem now is to have PATH modified on app install, but that is a very lazy way out and is indeed banned in lots of corporate environments. Another alternative is that you could hive off all BPL using code into a separate DLL and have that delay loaded instead. That ought to work, though you really got to wonder at the cost/benefit ratio. HTH, Niall -- Technology & Consulting Services - ned Productions Limited. http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no: 472909. _______________________________________________ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
