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

[Kristján Valur Jónsson]

> -----Original Message-----
> Nobody proposed to ditch cross-compilation. I very much like
> cross-compilation, I do all Itanium and AMD64 in cross-compilation.
>
> I just want the *file structure* of the output to be the very same
> for all architectures, meaning that they can't coexist in a single
> source directory.
>
Surely there are differences between architectures?  PC uses MSI after all.
Why can't linux be under trunk/linux and pc 86 under trunk/pcbuild8/win32PGO
and 64 under trunk/pcbuild8/x64pgo?  We shouldn't let bad tools keep
us from new ways of doing things, rather we should fix and update the tools.

> No, you use two checkouts, of course.
That´s just silly.  And two visual studios open, and edit the file
in two places too?  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.

> No matter what the next compiler is (VS 2005 or VS 2007/2008), it's
> still *a lot* of work until the VS 2005 build can be used for releasing
> Python. For example, there is no support for the SxS installation of
> msvcr8.dll, using the MSI merge module.
Well, there is some work, which is why I am proposing the Europython
sprint to do it.  But we are almost there.  And that work will be
useful for Orcas, when that comes along.
And btw, there is no need to install the msvcr8.dll.  We can distribute
them as a private assembly.  then they (and the manifest) exist in the same
directory as python2x.dll.  This is a supported distribution mode and how
we distribute the runtime with EVE.

> Not sure whether anything really is needed. Python works fine on Vista.
If you are an administrator.  A limited user will have problems installing
it and then running it.
>
> > 1) supplying python.dll as a Side By Side assembly
>
> What would that improve?
Well, it should reduce dll-hell problems of applications that ship with
python2x.dll.  You ship with and link to your own and tested dll.  We
have some concerns here, for example, now that we are moving away from
embedding python in our blue.dll and using python25.dll directly, that
this exposes a vulnerability to the integrity of the software.
>
> > 2) Changing python install locations
To conform with Windows rules and get a "Vista approved" logo.
Install in the ProgramFiles folder.  Just as C does.  Ah, and
this also means that we could install both 32 bit and 64 bit
versions, another plus.

> > 3) Supporting shadow libraries, where .pyc files end up in a
> different
> >    hierarchy from the .py files.  (useful for many things beside
> VISTA)
>
> Yes, and people had written PEPs for it which failed due to lack of
> follow up.
Interesting.  We are definitely interested in that.  You see, Someone
installs a game or accounting software using vista.  He then runs as a
limited user.  Python insists on saving its .pyc files in the installation
folder, but this is not something that is permitted on Vista.

>
> > 4) Signing the python dlls and executables
> Hmm.
Again, easing the installation experience for vista users.  So that they
don't get a red box about an unknown application requiring administrator
privileges.

>
> Sure, and have they reported problems with Python on Vista (problems
> specific to Vista?)
Certainly.  We are working on them, of course.  Chiefly, we have had to
change where we save all kinds of temporary files.  And we have to be
careful that all our .py files ship as .pyc files.  And we are versioning,
and signing all executables, providing user level manifests and fixing
up the install processes to be more compliant.  I am just saying that this
is something that a standard python distro might want to do too.

Kristjan