msvcr71.dll necessary? - Re: Which compiler will Python 2.5 / Windows (Intel) be built with?

["Martin v. Löwis"]

robert wrote:
> hmm, yet msvcrt4 is obviously preinstalled on each Windows - and its in
> Windows Update Process. Its tagged:  "4.20 - OS use only. DO NOT
> DISTRIBUTE")
> Think, in principle its possible to compile against that with
> VS2003/2005... ?
> ( think msvcrt4 is not delivered extra even in the python2.3 installer )

Unfortunately, you also need the header files and an import library
to link against this library. Likewise, for applications that bundle
MFC, you need the corresponding set of header files and libraries.

Microsoft does not provide import libraries for msvcrt4.dll anymore.

>> Making more users happy? Certainly not, either. Some users request that
>> VS2005 is being used, not that VC6 is being used. Other users request
>> that Python 2.5 continues to be built with VS 2003. You can't please
>> everybody.
> 
> Yet if the C runtime lib (distribution) problem is solved, the question
> of the compiler becomes irrelevant.  Everybody could use his compiler
> without worry - a soft recommendation could be in the Python2.5 doc's to
> link extensions also against the same common basic ctrl in order to keep
> the numer of libs small.

Unfortunately, that is a real technological challenge. Where do you get
the header files and import libraries, and how do you explain to your
compiler to use those instead of the ones it comes with?

> there is also a "msvcrt.dll" - also updated by the Windows system. maybe
> its on each Windows ?  On XP it has version 7. What is this?

It used to be possible to link with it. See

http://msdn2.microsoft.com/en-us/library/abx4dbyh(VS.80).aspx

This is now a "known DLL", and meant for use by system-level components
only.

> Maybe most a most simple cutoff criteria with "costs" does it magically.
> Basic proposal:
> 
> cost = (C1 * module-size - C2 * frequency-of-module-usage)

Unfortunately, that criterion cannot be determined in an objective
manner. It's not possible to determine frequency-of-module-usage
in any meaningful way for existing modules, let alone for modules
that are contributed and to be included only in the upcoming
release.

Regards,
Martin