> 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
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
> 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
> v
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
> > i
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
> 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 desirabl
> I've looked most closely at
> http://svn.python.org/view/python/trunk/Lib/msilib/__init__.py?rev=47280&view=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 is
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?
>
> http://www.python.org/ftp/python/2.5.1/python-2.5.1.
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
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 packa
> 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 installing a 64bit
> program!
Right. You cannot easily have a 32-bit installer install 64-bit
pr
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 wron
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.
> 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
> c
> 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 b
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.
Furthermore only one architecture may be set in the template sum
> 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-
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
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
19 matches
Mail list logo
