New versions breaking extensions, etc.

["Martin v. Löwis"]

Jive wrote:
> But it makes no difference, no?  The problem is that both Python.exe and the
> extensions are *compiled* to link with a *particular* crt. 

No, that is not (really) the case. They are compiled to link with
msvcrt.lib, which could, at link time, then become msvcrt.dll,
msvcrt40.dll, or msvcr71.dll.

> (How "dyanamic" is that?)

The actual code of the DLL is not provided until run-time - only
at run-time, the precise implementation of the CRT routines is
available - and it indeed may vary from system to system, as different
versions of msvcrt40.dll might be installed (or of python24.dll, for
that matter).

> We could probably kluge around the problem if it were not for the
> fact that one crt might perversely define some struct, (FILE, for example),
> with difference layouts in different crt DLL's. Right?

Wrong. struct FILE binds us the the MS CRT (so the Borland or glibc CRTs
are incompatible), but struct FILE has stayed the same for more than 10
years now, so you can, in principle, mix object files compiled with
different compilers. One would need to check the header files to
determine they are really compatible, but that appears to be the intent,
and Microsoft does not dare to change it (except perhaps for the _ctype
thing, which I don't fully understand).

What really hurts is that the CRT has a number of global variables: the
global FILE objects (FILE 0 to FILE 63, I believe), the global heap,
and the global atexit handlers. If you have multiple CRTs, you get
multiple copies of these globals, and the different routines in the
different CRTs each operate on their own copy of the global variable.

> So it would seem that as far as the crt goes, we are at the mercy of the
> micro soft ones.  They could introduce an incompatible crt at any time.

They could, but they won't. I believe they have long given up changing
or improving the CRT, since that would make things worse in most cases.
The only things they still do is to add new features; the existing ABI
apparently is never touched (again, perhaps except for a _ctype change
I don't understand).

> By the way, I've googled around and found others outside the Python
> community who have run into the same problem.  In some cases, they have
> opted just to stay with VC 6.0.  One said, "At least the 6.0 compiler is 2.5
> times as fast."  Groan.

This is what Python did for 2.3. Already at that time, user pressure
was quite high to move to a more recent compiler; with 2.4, it was
clear that we do need some of the new features (in particular,
ongoing commercial availability, and IPv6 support in winsock.h).

Regards,
Martin