[python-win32] Loading C extensions in Python 2.6/2.7 from classic ASP

Chris Lambacher chris at kateandchris.net
Sun Sep 11 18:20:34 CEST 2011


On Sun, Sep 11, 2011 at 11:57 AM, Chris Lambacher
<chris at kateandchris.net> wrote:
>>
>> If so, that surprises me.  To get as far as you did, much of the pywin32
>> framework was imported, so all those modules must have imported OK.
>
> I don't know why the imported pyd files are not picking up the version
> from pythoncomloader26.dll, but I got the idea to stop removing msvcrt
> from the manifest from this stack overflow post:
> http://stackoverflow.com/questions/3706293/why-do-no-python-dlls-built-with-msvc-load-with-mod-wsgi
>
> and ended up at these python bugs as the source of the current state of things:
> http://bugs.python.org/issue4120
> http://bugs.python.org/issue4566
>
> Assuming that the fix from bug 4566 has been applied also to
> pythoncomloader26.dll perhaps there is some other kind of interaction
> on Windows 7 x64? I do have a Windows Vista x32 machine I could test
> on. Is it also possible that I am missing some dependency like the
> exact version of msvcr90.dll that is used with the pywin32 build?

Further investigation gets me to:
http://omnicognate.wordpress.com/2009/10/05/winsxs/

In the section called "Creation and Activation of Activation Contexts
by Inline Helpers in the Platform SDK Headers" they enumerate a
potential way we loose the Activation Context. Is
pythoncomloader26.dll protecting itself against that? There is a
potential solution included in that section, but I don't know for sure
that would work in this case. The only thing I *am* sure about is that
*this* cure to dll hell seems to be worse than the disease :(

-Chris

-- 
Christopher Lambacher
chris at kateandchris.net


More information about the python-win32 mailing list