Re: Python DLL in Windows Folder

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

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

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.

Is that really all that hard to admit?

Ross Ridge

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

Relevant Pages

  • Re: Python DLL in Windows Folder
    ... with the old DLL. ... the requirement for backwards compatibility is not normative. ... I can install in according to 2.6 is the System folder. ... Python 2.5 already exists and has shipped. ...
    (comp.lang.python)
  • Re: PSAPI.DLL Corrupt?
    ... I have none of these applications, nor do I have any other instance of ... but it also results in the same registration error. ... do not help with the install issue I'm seeing. ... It seems that this task creates a "working" dll ...
    (microsoft.public.windows.server.general)
  • Assembly version compatibility issue
    ... I have a common assembly DLL that's installed into GAC (using msi created by ... It contains classes used by all the applications we have. ... and install the newer DLL properly when it's deployed. ...
    (microsoft.public.dotnet.framework)
  • Assembly version compatibility issue
    ... I have a common assembly DLL that's installed into GAC (using msi created by ... It contains classes used by all the applications we have. ... and install the newer DLL properly when it's deployed. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Assembly version compatibility issue
    ... I have a common assembly DLL that's installed into GAC (using msi created by ... It contains classes used by all the applications we have. ... and install the newer DLL properly when it's deployed. ...
    (microsoft.public.dotnet.languages.csharp)