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

[Kristján Valur Jónsson]

> -----Original Message-----
> From: "Martin v. Löwis" [mailto:martin at v.loewis.de]
>
> That couldn't work for me. I try avoid building on a network drive, and
> with local drives, I just can't have a Windows build and a Linux build
> on the same checkout - they live on separate file systems, after all
> (Linux on ext3, Windows on NTFS, with multi-boot switching between
> them).
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?

> I don't *use* them simultaneously, of course - I cannot work
> on two architectures simultaneously, anyway.
I do so on a daily basis.  I designed PCBuild8 to be easy for interactive
work using VisualStudio, using property sheets and such to group common settings
for easy editing.  During the course of my work, I will edit a file (which is checked
out from Perforce), compile debug for two platforms, test, and repeat.

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

> > 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.
>
> Yes, but then python2x.dll goes into system32, and so will msvcr8.dll,
> no?
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.

>
> >> 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.
>
> Is there a bug report for that?
I don't know.  At any rate, I think any vista issues is a completely
separate thing, something that needs to be handled as a whole, rather
than responding to a particular problem reported in a bug report.
>
> >>> 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.
>
> 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.

> > Install in the ProgramFiles folder.
>
> Only over my dead body. *This* is silly.
Bill doesn't think so.  And he gets to decide.  I mean we do want
to play nice, don't we?  Nothing installs itself in the root anymore,
not since windows 3.1

>
> > Just as C does.  Ah, and
> > this also means that we could install both 32 bit and 64 bit
> > versions, another plus.
>
> What about the registry?
I don't know about the registry, what is it used for?
64 bit windows already ships with dual versions of some apps, notably
explorer.exe so that shouldn't be a big problem.

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

>
> >> Sure, and have they reported problems with Python on Vista (problems
> >> specific to Vista?)
> > Certainly.  We are working on them, of course.
>
> But, of course, they have not been reported.
These are not python errors as such, but rather EVE errors.  We ship the .py
files precompiled and therefore avoid the aforementioned problems.  But we have
had to move all sorts of temporary files out of "program files" and into
"documents and settings/user/local settings/Application Data/CCP/Eve

Kristjan