[Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python

[Mark Hammond]

Sorry for the delay in responding to this stuff - Im at the MS PDC, and
demoing a new Python compiler that I'm suddenly allowed to talk about - but
that isnt the point of this mail :-]

> This is really bad.  Normally under Windows, DLL names do not change
> unless the API exported is changed in a major way.  For example,
> there have been several versions of mfc42.dll without changing the
> name.

Yes, and each of these versions has broken various programs.  Of all
people, Im surprised to see you falling for the MS hype, Jim.  MS have
openly admitted, on a number of occasions, that Windows has "DLL hell", and
has made a huge effort to address this in the .NET framework.  The Python
community has itself been bitten by "bogus" MFC42.dll files that MS profess
to be compatible.  If MS can't get it right with their resources, I don't
like our chances!

> What this means is that if the new Python 2.0 (1.6?) simply names
> its DLL python15.dll just as before, everything Just Works almost.
> That is, it Just Works provided that foo.pyd only calls Python
> C functions whose interface has not changed.

IMO, this constrains us too much.  We can't afford this - we simply dont
have the resources.

> You can support Python 1.5 and 1.6 by removing the python*.dll
> from the Windows directories, and putting it in the directory
> of python.exe so it goes with the proper executable.

We have discussed this over and over and over, ad nauseum.  If you believe
the earlier discussions were bunk, please refute them.  Otherwise, simply
re-asserting something that we have previously proven to be incorrect
doesnt help anyone.

> > trying to solve here?  So far, the only problem that came up was that
> > on Windows, you get an obscure crash when trying to load an extension
> > built for Python 1.5(.x).
>
> Yes, and this is a major problem, and is un-Windows-like.

:-)  "Major Crashes" are un-Windows like?  What is happening to this
group - It amusing that this statement could be made without the Linux
geeks making smart-arsed comments :-)  Looks like Billy Boy really _is_
taking over the world :-)

> No, just keep the old name "python15.dll".  Old foo.pyd will
> still work if they use only Python C functions with the same
> interface.

And as long as we go to extraordinary efforts to maintain binary
compatibility.  We are under resourced as it is - I dont believe we can do
this.

> Individual *.pyd authors will have to advise users whether
> they need to upgrade to new *.pyd versions or not.

This is where we are now.  I agree that we should not crash, but it seems
to me you havent solved anything - individual .pyd authors needing to tell
users about each individual .pyd isnt a solution.

> > You can already get the version string by
> > looking at Py_GetVersion() -- this also answers the question of how a
> > version is represented.
>
> True.  And on Windows, there is a standard Version resource
> string which gives the DLL version, and can be read without
> loading the DLL.  This string is referenced by the Wise (and
> other) installers to decide whether a DLL is newer and should
> be replaced.

Im not sure how this helps us.  Do you mean that "initfoo" should use the
Windows resource/version APIs to determine if it can load?

> > On Windows, link-time compatibility is broken whenever we change the
> > second digit of the version number, e.g. 15, 16, 20.
>
> Yikes, lets not let that happen!

Ideally, I agree.  However, Im not sure how we can make this happen!  Any
ideas on how we can achieve this?  And I mean in a practical sense, rather
than with a hand-waving abstract theory - ie, specifically what
developement practices should change, or be put in place, to ensure this?

Mark.