[C++-sig] Can boost_python dll be delay loaded?

[Niall Douglas]

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.