Python DLL in Windows Folder

[Ross Ridge]

Ross Ridge writes:
> No, that doesn't follow from the requirements given.  The only exception
> for something that isn't a service or device driver is for backwards
> compatibility.  Also, pretty much any DLL supports side-by-side
> installation.

<martin at v.loewis.de> wrote:
>Hmm. How do I have to build and install python25.dll exactly to make
>that work? How do applications have to link against it?

As I said before, I know how futile it is to argue that Python should
change it's behaviour.  I'm not going to waste my time telling you what
to do.  If you really want to know how side-by-side installation works,
you can try reading the Windows SDK documentation.

>> The backwards compatibility exception doesn't apply when the name of
>> the DLL changes.
>
>Chapter and verse of the spec?

It's a logical conclusion that results from the fact an application
can't have a dependecy on a DLL that doesn't exist yet.  Putting FOO.DLL
in a different directory than BAR.DLL was installed in won't break any
existing application that uses BAR.DLL.

>> If the name of the DLL changes, the shared location
>> its installed to can also change.
>
>No. The existing applications still require Python to be located on
>the path, even if they are rebuilt against the new DLL.  This is
>source backwards compatibility, not binary backwards compatibility.

No, simply by changing the name you've prevented backwards compatiblity
with the old DLL.  You can't argue you're trying to maintain backwards
compatibilty with an old DLL when you've already broken compatibility
with it.  Since the existing applications have to be rebuilt to use the
new DLL they also can be changed to use it from a new shared location.

						Ross Ridge

-- 
 l/  //	  Ross Ridge -- The Great HTMU
[oo][oo]  rridge at csclub.uwaterloo.ca
-()-/()/  http://www.csclub.uwaterloo.ca/~rridge/ 
 db  //