New versions breaking extensions, etc.

"Martin v. Löwis" martin at
Sat Dec 11 10:21:22 CET 2004

Jive wrote:
>>The other
>>issue is that the interpreter and the extensions may be linked to
>>different versions of the Microsoft runtime.
> Doesn't Microsoft have an answer for that?

Microsoft's answer to this question is: don't do that. Never
mix different versions of the CRT in a single application.

> There are (at last count) nine skillion ActiveX
> components in the wild.  Surely Microsoft didn't blast them into oblivion
> with dot-net -- did it?

No, it didn't - but so what? The point is that ActiveX controls normally
don't use the CRT in dangerous ways, since they are constrained to use
Co* function calls only.

> I remember having trouble with that last bit once.  But I seem to recall
> there was an easy
> answer.  Something to do with the main ap and the DLL using the same heap or
> some
> such thing.

Something like that, for sure.

[require that extensions be recompiled]
> It would be a Good Thing to put a stop to that requirement, no?

No. The maintenance cost of such a new API would be significantly
higher, and Python would lose some of its attractiveness for C

> No doubt.  I don't understand what the deal is with msvcr71 and all that,

You probably either need to learn what the deal is, or else you have to
trust others that there is no better way.

> That would be good.   But is using VC++ 6.0 right out?  As it stands, I can
> no longer build extensions that will run with a standard dot-net Python 
 > 2.4 release. Or at least I don't know how.

The most easy way to do this is to use VC7.1 (VS.NET 2003). That will
work out of the box (you need to box first, of course).

> Thinking it over, I'm wondering why the Python crowd went with dot-NET in
> the first place.

We did not go to .NET. Python 2.4 has nothing to do with .NET. It just
happens that the C compiler we use ships as part of a product that has
.NET in its name - the C compiler itself is Microsoft Visual C 7.1,
aka Microsoft C 13.10.

That compiler is now used because it has a number of improvements over
Microsoft C 12.00, and because VC6 is no longer commercially available.
Many developers have only VS .NET 2003 available, so if Python would
continue to be built with VC6, those people could not build
extensions for it - they could not even buy the compiler they needed,
anymore. OTOH, people who only have VC6 just need to buy VS.NET 2003,
which is still available. Or else they find out what alternative
compiler arrangements can be made.

> Surely the world would be a better, happier place without MS jerking
> everyone around.

It would surely be better if the operating system shipped with a
compiler, so anybody could rebuild things, and you wouldn't need
binary distributions in the first place :-)


More information about the Python-list mailing list