> 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
18 matches
Mail list logo
