Hi Martin,
I found the same thing, and put a corrected installer at
http://www.dcl.hpi.uni-potsdam.de/home/loewis/python-2.5.1.amd64.msi
Is there any intention to update the msi at python.org? Alternatively, can
I point people at the above file? I've a .msi created by bdist_msi that
works
Hi Martin,
I found the same thing, and put a corrected installer at
http://www.dcl.hpi.uni-potsdam.de/home/loewis/python-2.5.1.amd64.msi
Is there any intention to update the msi at python.org?
No. I would have to bump the version number for that, which I cannot
do - it will need to wait
As you mention, 64 and 32bit programs use different instruction sets.
Therefore, trying to use a 64bit install of Python with IIS configured to
work with 32bits is not going to work. In this case, switching the
configuration of IIS will require the Python user to uninstall the previous
I'm not familiar with how msilib is invoked to create the MSI files in
question, but it does look like setting Win64 to 1 at an early enough
time would cause an Intel64 installer to be built, along with entirely
64-bit components. This wouldn't work for x64 machines, and all
components being
I'm afraid my knowledge of MSI is very limited, so I'm not sure where to
start. One thing I did notice is that msilib\__init__.py has a variable
'Win64' set, hard-coded to 0 - but I've no idea if it is relevant.
Presumably it is relevant to *something*, otherwise it would not have been
On Friday, 13 July 2007, Michael Urman wrote:
Furthermore only one architecture may be set in the template summary,
so an installer may be only one of i386, x64, and Intel64 (although
the latter are assumed to also be able to run i386 binaries).
I suspect I'm still missing something here.
Michael Urman schrieb:
On 7/12/07, Mark Hammond [EMAIL PROTECTED] wrote:
Why wouldn't it work for x64 machines? Is it simply because msilib only
handles Intel64 when that flag is set?
Right - it sets the template summary to include Intel64, not x64.
You might be looking at the wrong
On 7/13/07, Mark Hammond [EMAIL PROTECTED] wrote:
On Friday, 13 July 2007, Michael Urman wrote:
I suspect I'm still missing something here. The title of the page you
referenced before is Using 64-Bit Windows Installer Packages - I suspect
that is different than a 32-Bit installer package
On 7/13/07, Martin v. Löwis [EMAIL PROTECTED] wrote:
Michael Urman schrieb:
Right - it sets the template summary to include Intel64, not x64.
You might be looking at the wrong version. In Python 2.5, it also
sets it to x64, if the PE machine type is 0x8664.
I've looked most closely at
On 7/13/07, Michael Urman [EMAIL PROTECTED] wrote:
That's even easier then, if anything's actually wrong. I'll find some
time this weekend to look at it and report back. Would the one at the
following URL be the correct one to verify?
I've looked most closely at
http://svn.python.org/view/python/trunk/Lib/msilib/__init__.py?rev=47280view=auto,
and from there not even full readings yet, just searching for Win64 to
see what the flag did. No doubt I have missed several intracacies.
Ah, ok. This should get fixed, but it isn't
Assuming this is the right file, the cause of the behavior Mark
reported is pretty clear. While the template summary is indeed x64,
the attributes on the registry components are all 4 instead of 256 |
4, so they are placed in the 32-bit reflected registry. I don't know
if this is desirable
Martin quoting me:
Yes - that is a bit of a shame, as having 32bit components
would allow more flexibility (eg, allow a 64bit install of
Python to work with an IIS configured for 32bit extensions),
but that's something we can deal with later if necessary.
Can you elaborate?
As you
Martin:
Assuming this is the right file, the cause of the behavior Mark
reported is pretty clear. While the template summary is indeed x64,
the attributes on the registry components are all 4 instead of 256 |
4, so they are placed in the 32-bit reflected registry. I don't know
if this is
After installing the x64 version of Python 2.5.1 via the MSI file on
python.org, I noticed most of the registry keys are missing. Further
investigation shows they aren't actually missing, but have simply been
virtualized, so they actually appear under the Wow6432Node key.
This Wow6432Node key is
On 7/12/07, Mark Hammond [EMAIL PROTECTED] wrote:
I'm afraid my knowledge of MSI is very limited, so I'm not sure where to
start. One thing I did notice is that msilib\__init__.py has a variable
'Win64' set, hard-coded to 0 - but I've no idea if it is relevant.
Presumably it is relevant to
Per the requirements documented at
http://msdn2.microsoft.com/En-US/library/aa372396.aspx, the behavior
you describe is expected for a 32-bit installer.
Agreed - but unless I'm missing something, this release is not expected to
be a 32bit installer.
(To install files and
registry to 64-bit
17 matches
Mail list logo