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

[Mark Hammond]

> 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

In the former case, assuming python is running from the 'trunk' directory,
all architectures know how to locate the binary directory - it is always
named 'PCBuild'.  In the latter case, the directory name depends on the
architecture.  A number of existing tools already know about the 'PCBuild'
directory, so these tools will not need to be taught anything new for x64.

> I don't understand this extraordinary reluctance to add a 
> single extra directory.

I think that this thread has enumerated the concerns fairly well.  You may
not agree with them, but if you don't understand them it might be worth
re-reading Martin's responses.

Note that I also understand your concerns and goals - I certainly see where
you are coming from - but we have 2 competing goals - "work with as many
existing, external build tools as possible" versus "take this opportunity to
create a new cross-compile-capable x64 build environment for Windows and let
those external tools deal with the breakage".

As I mentioned in a previous email, my personal opinion would be swayed by
looking externally.  Specifically, if we could determine the likelihood of
external build processes (eg, mozilla) working unchanged if we stick with
'PCBuild', and if we could determine the cross-compilation strategy being
adopted by the external libs we use (zlib, bsddb, etc), I think we could
make an informed decision.

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

Please see above - its not a problem if you think of the PCBuild8 process as
the "last step" in a build process - but often it is not.  External tools
that use Python (ie, things you try and build after the Python build has
completed) are impacted.  I understand that you might not use such tools,
but they do exist.

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

I'm not sure I buy this.  If someone has enough access to your machine to
change pythonxx.dll, you are pretty screwed already.

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

Please see PC/getpathp.c in Python source tree.

However, I agree that there are a number of things we could do to help
Python play nicely on Vista.  It might help if we can enumerate the specific
problems and potential solutions in a more formal way (eg, a Python bug)

Cheers,

Mark
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 3360 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-dev/attachments/20070524/c25f579d/attachment.bin