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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4