Python DLL in Windows Folder

["Martin v. Löwis"]

> 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.

I did, and determined that it's not possible. We would have to use
assembly manifests, and can't, as the tool chain doesn't support them.

> No, simply by changing the name you've prevented backwards compatiblity
> with the old DLL. 

First, the requirement for backwards compatibility is not normative.
Section 2.6 is entitled "Install any shared files that are not
side-by-side to the correct locations". python25.dll, as a matter of
fact, *is* a shared file that is not side-by-side; the *only* location
I can install in according to 2.6 is the System folder.

> You can't argue you're trying to maintain backwards
> compatibilty with an old DLL when you've already broken compatibility
> with it.

Furthermore, it says "to ensure backward compatibility with those
applications", not "to ensure backward compatibility with the old DLL".
I'm not trying to maintain compatibility with the binaries of those
applications, but with their source.

> 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.

No, they can't, because there is not enough manpower available to change
them.

Regards,
Martin