On Sun, Sep 11, 2011 at 11:57 AM, Chris Lambacher <ch...@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 ch...@kateandchris.net _______________________________________________ python-win32 mailing list python-win32@python.org http://mail.python.org/mailman/listinfo/python-win32
