This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author mhammond
Recipients cgohlke, koen, loewis, mhammond, tarek, techtonik
Date 2011-02-18.06:06:42
SpamBayes Score 7.27814e-11
Marked as misclassified No
Message-id <>
I'm failing to get a new pywin32 out of the door due to this issue.  I've spent a few hours playing with this and I think the analysis is generally correct here.  The key thing is that when using distutils, the extensions end up with a manifest (albeit one without a reference to the CRT) whereas the extensions shipped with Python have no manifest at all.

I agree with Martin that it seems strange the CRT fails to be used even though the CRT is obviously already loaded, but it seems to be a fact.  I can't find much on this, but suspect it relates to the different "activation contexts" in use and how the activation contexts are designed to allow side-by-side loading of DLLs; Windows doesn't know if the version of the DLL already loaded is suitable.  I also guess that the fact the DLL has *any* manifest means they use a more strict interpretation of things (ie, refuse to use already loaded ones) whereas a dll with no manifest gets given a little more slack.

I can confirm that with the attached patch, pywin32 builds and installs fine on a machine without the CRT installed globally - so I'm +1 on this patch with one caveat:  The check for '.pyd' should either be expanded to include '.dll', or else the check should just use the 'target_desc == CCompiler.EXECUTABLE' condition already used.

I'm happy to make the change once I get some feedback and/or guidance about where I should check this in - I believe it is too late for python 2.6 which is a shame...
Date User Action Args
2011-02-18 06:06:44mhammondsetrecipients: + mhammond, loewis, techtonik, koen, tarek, cgohlke
2011-02-18 06:06:44mhammondsetmessageid: <>
2011-02-18 06:06:43mhammondlinkissue7833 messages
2011-02-18 06:06:42mhammondcreate