Python DLL in Windows Folder

[Chris Mellon]

On Dec 28, 2007 6:41 AM, Ross Ridge <rridge at caffeine.csclub.uwaterloo.ca> wrote:
> Ross Ridge writes:
> > 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.
>
> <martin at v.loewis.de> wrote:
> > 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.
>
> Your choice to use a tool chain that doesn't support side-by-side
> assemblies does not make it impossible.
>

It's worth pointing out that when the choice was made,Windows didn't
support SxS at all and there was no toolchain for it.

> >> 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.
>
> No, the only thing that the guidelines require to be installed in the
> system directory are services and drivers.  The only exception for other
> kinds of applications is when necessary for backwards compatibility.
>

You're not reading the document correctly. The "backwards
compatability" is supporting non SxS libraries.

> >> 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".
>
> Now you're just trying play pointless semantic games.  If you change
> the DLL's name, the DLL is no longer compatibile with those applications.
>

Python 2.5 already exists and has shipped.

> >> 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.
>
> And that's what this all really comes down to.  Because neither you nor
> anyone else is willing to do the work necessary to do the "Right Thing",
> you have chosen not to follow Microsoft's recommended best practices
> for installing Windows applications.  It's not because it's impossible,
> it's because you're unwilling.
>

You're persisting in calling Python an "application", which it clearly
isn't. How relevant these guidelines are at all, since they're
targeted toward end-user boxed software and not toward developers of
third party libraries, is questionable, but lets see what it says.

Section 2.6 *clearly* states that non side by side dlls (which Python
is) can (and, in fact *must*) be placed in the System directory. Note
that making your libraries SxS is *not* a requirement. So if we're
going to follow this (questionable) document at all, Python is
absolutely compliant.