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 carlkl
Recipients carlkl, erik flister, eryksun, paul.moore, steve.dower, tim.golden, zach.ware
Date 2015-06-15.20:36:47
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> Windows itself is the primary user of msvcrt.dll. 
> A Windows 7 installation has over 1500 DLLs and over 
> 350 executables in System32 that depend on msvcrt.dll. 
> Windows developers such as Raymond Chen get a bit annoyed 
> when projects link directly with msvcrt.dll.

In case of mingw32 or mingw-w64 msvcrt linkage is the usual standard due to licensing reasons. The CRT has to be stated as a 'System' library, see This is case for msvcrt.dll only. VC runtimes can be linked as well, but this runtime DLLs should'nt deployed alongsinde with the application in this case.

As described above python binary extensions has to be linked against the very same VC runtime that is used for Python itself to avoid mixing runtimes in one application. Mixing is considered as evil, see

An important question for Steve concerning python-3.5:

python-3.5b2 is linked against the newly introduced 'universal CRT', that is without any doubt a SYSTEM LIBRARY. However, heap memory managment functions and other functions are linked against VCRUNTIME140.dll instead of the ucrtbase.dll. Is this the intended behavior? 

The symbol memset: this symbol is exposed from ucrtbase.dll as well as vcruntime140.dll. Is it necessary to link python binaries against vcruntime140.dll as well, or is linkage against ucrtbase.dll sufficient?
Date User Action Args
2015-06-15 20:36:47carlklsetrecipients: + carlkl, paul.moore, tim.golden, zach.ware, eryksun, steve.dower, erik flister
2015-06-15 20:36:47carlklsetmessageid: <>
2015-06-15 20:36:47carlkllinkissue24429 messages
2015-06-15 20:36:47carlklcreate