[Distutils] [Python-Dev] Adventures with x64, VS7 and VS8 on Windows

["Martin v. Löwis"]

> Very well, leaving linux aside, I don't see why this:
> /win32mount/trunk/PCbuild/
> /x64mount/trunk/PCbuild/
> 
> Is any different from
> /winmount/trunk/PCBuild/win32
> /winmount/trunk/PCBuild/x64
> 
> I don't understand this extraordinary reluctance to add a single extra directory.
> The windows build process is different from any other build process, so even
> If all the other platforms live one directory higher, why must windows?

It doesn't need to, and reluctance is not wrt. to the proposed new
layout, but wrt. changing the current one. Tons of infrastructure
depends on the files having exactly the names that they have now,
and being located in exactly the locations where they are currently
located. Any change to that, whatever minor, will cause problems
to some people.

So for the change to be made, the advantages must clearly outweigh
the incompatibility of the change in the first place.

>>> I say let's just admit that tools can compile for
>>> more than one target.  Let's adapt to it and we will all be happier.
>> You might be; I will be sad. It comes for a price,
> I well understand the benefits, I use it all the time, but the price
> still eludes me.  how can a different name for the output folder
> for a different platform be such a big problem?

When running Python now, I type (after having changed to the source
directory in the cmd.exe window) PCb<tab>pyt<tab><tab> or some
such. To navigate to a subdirectory, I need many more keystrokes.

I find it very painful to invoke python.exe from the
PCbuild8 directory. I don't want that pain to be the default.

> Yes, that is correct.  Well, there is a CRT .exe redist if you want to deploy
> this into the SxS cache, it just has to be run as part of the install process.
> But that may or may not be problematic, I don't know.

Microsoft recommends to use the merge module (.msm), and I think this
is what should be done (if feasible).

>> Why should there be versioning problems with python25.dll? Are there
>> any past issues with incompatibilities with any python2x.dll release?
> Someone could replace the python25.dll that we ship with their own patched
> version, thereby gaining backdoor access to the software.  The way
> windows searches for old style dlls makes this easy.  Using the SxS
> signed loading scheme, you can protect yourself up to a point from such
> attacks.  Of course, this doesn't have to be a problem for vanilla
> python, we can do this on our own for the patched python25 that we
> employ, but it still might be something others could find useful.

I personally think that if hostile users can replace DLLs on your
system, you have bigger problems than SxS installation of pythhonxy.dll,
but perhaps that's just me.

>>> Install in the ProgramFiles folder.
>> Only over my dead body. *This* is silly.
> Bill doesn't think so.  And he gets to decide.

He can decide not to give Python the "Vista ready" logo. If so,
I don't want it. He cannot decide to make the Python installer
to install into a directory with a space in its name by default.

> I mean we do want to play nice, don't we?

Nice to users of Python, sure. I would not have said a word if
the standard directory would have been, say "\usr\bin". However,
they happened to chose "Program Files", making it language dependent,
and putting a space in the name. That space has caused numerous
problems to Python scripts, and I expect changing the default
would cause a lot of problems to end users.

>> What about the registry?
> I don't know about the registry, what is it used for?

For two things, with different importance to different users:
1. File extensions are registered there, e.g. .py and .pyc.
   With two binaries installed, the will stomp over each other's
   file associations; only one of them can win.
2. Python installs keys under
   HL{LM|CU}\Software\Python\PythonCore\<version>, namely
   InstallPath
   InstallGroup
   PythonPath
   Documentation
   Modules

For some of these, add-on libraries and applications may modify
these keys, and the interpreter will pick up the changes.

Again, there can be only one installation on the system
"owning" these settings; two simultaneous installations will
stomp on each other's settings.

> 64 bit windows already ships with dual versions of some apps, notably
> explorer.exe so that shouldn't be a big problem.

The two versions of MSIE actually *are* a big problem, that's
why MS only runs the 32-bit IE, even on Win64 (otherwise, ActiveX
controls downloaded from the net wouldn't work).

Also, while they are both shipped, you can't the two versions of
explorer.exe simultaneously (without trickery), so its far from
simple.

>> But that's not a problem, is it? Writing silently "fails", i.e. it just
>> won't save the pyc files. Happens all the time on Unix.
> It may not silently fail, depending on your user status.  An admin might
> get a confirmation window, for example.

Can you describe the precise scenario which makes that happen? To my
knowledge, Vista will *not* open a confirmation window when Python
attempts to write a .pyc file.

Regards,
Martin