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

[robert]

Martin v. Löwis wrote:

> robert wrote:
 >
> codecs are in python24.dll, mscvr71, mfc71 and all are not.
> However, they are not in core - the operating system demand-pages code,
> loading into core memory only what is being used. So if you don't use
> the codecs, they are not loaded into core.
> 
> While mscvr71 is likely loaded into core (even though it is not in
> python24.dll), mfc71.dll does not play a role at all in Python 2.4.
> Python is written entire in C, not in C++.

yes, yet as a consequence win32xx is forced to be linked against 
MFC71.dll (no other functional reason): another MegaByte which I'd need 
to package most times - while mfc42 from VC6 is pre-installed on each 
Windows.

> 
>>* Is there a fundamental reason that the C-RTL of VC6 (which is
>>pre-installed on on all Windows today) is not sufficient for current
>>Python and extensions? instable?
> 
> 
> The compiler that is used (VS 2003) won't ship it, and links with
> msvcr71.dll. That's why that library version is used.

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 )

>>In case not: As the short living VS 2003 compiler is now more rare than
>>the good old VC6, wouldn't it be better to switch back to VC6 for Py2.5
>>or at least to VC6 libs (which are maybe "free" of dev-license as they
>>sit on each Windows).
> 
> Better in what respect? Predictability of software development?
> Certainly not: the development will be more predictable if a decision
> that was once taken is implemented as promised.

2.4 and 2.5 compiled stuff is anyway not interchangeable - thus at 
alpha-stage a (down) step to a common system lib would probably have no 
countable negative effects at all.

> 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.

>>Maybe a suitable policy: the default crtl for Python should better be
>>the default library of the OS and not that of a random compiler which is
>>currently hip?
> 
> That would make a good policy if the OS had a system C library. Windows
> doesn't. Windows NT does have a CRT, namely crtdll.dll - but you weren't
> suggesting to use that one, were you?

msvcrt4 is probably a reliable system C lib and still used by most apps. 
  Think it doesn't lack Pythons needs.

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?


>>* can't the Mingw/gcc be used together with Windows default crt/mfc libs
>>for Python2.5 ? - Python getting away the from this MS studio (lib)
>>harassment?
> 
> Sure, you can use gcc/mingw to build extensions for Python 2.4 and
> Python 2.5.

yes, the lib is 90% the object of concern.

> 
>>* how many (serious) python users require to build distributable
>>installers (which have carry the python-rtls and non-default crtl's)?
> 
> 
> Apparently not many. I repeatedly asked for contribution of a

That would be very intersting for me - number about where (project type, 
LOC, #-of-users) and how (system, distribution, ..) python is used.
Is there already something. Maybe a research/poll in this NG would be 
feasible.

> specification how pythonxy.dll should be modularized, and never
> received one.

Maybe most a most simple cutoff criteria with "costs" does it magically.
Basic proposal:

cost = (C1 * module-size - C2 * frequency-of-module-usage)

I'd suggest:
cutoff cost = 0
C1 = 1/200kB
C2 = 1/80%


Example CJK codecs:
cost = 500k/200k - 30%/80% = 2.13   =>  too expensive by far

Example zlib:
cost = 70k/200k - 95%/80% = -0.84   =>  go in



-robert