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 locations, the Template Summary must include Intel64 or x64 depending on which architecture, and the component must be marked as 64-bit).

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,

Why wouldn't it work for x64 machines? Is it simply because msilib only handles Intel64 when that flag is set?

and all components being 64-bit may be incorrect: potentially the 64-bit installer should have some 32-bit components.

What 32bit components should a 64bit build of Python include? Perhaps you mean *could* - but IIUC, there is no intention to release 32bit and 64bit versions of Python in a single package (and further, IIUC, no intent on supporting a 32bit and 64bit installation on the same machine, regardless of packaging) I'm afraid its not clear to me if you are agreeing with me (ie, that the registry keys are incorrect), or disagreeing with me (the keys are what you would expect a correct x64 install to create)? I think you are agreeing, but sounding a caution that it might not be trivial to fix, but I would like to be sure... Cheers, Mark

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

Agreed. I was just making clear that I'm not familiar with what the MSI includes, and whether any of the components in a 64-bit install should be 32-bit or not. With the msilib code as is, it appears to be all or nothing, or rely on tweaking a global between calls to start_component.

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.

If you just want to get to the keys it currently sets, there should be an override parameter that causes the registry API to read the 32-bit keys even in a 64-bit process, but I'm not familiar with using _winreg.

using _winreg is (almost) like using the API directly. RegDisable[/Enable]ReflectionKey appears to let the 32bit process see the real keys - I'm not aware of how 64bit apps would enable that reflection, but it probably doesn't really matter for our purposes. In case anyone is interested, I just made a patch to _winreg.c adding these 2 functions (http://python.org/sf/1753245) in case anyone would like to review it.

If there's interest and I can get pointers to where the MSI files are built, I can look into patching it. I don't have a convenient 64-bit Windows machine around to test any changes, though.

I think Tools\msi is what you are looking for, but hopefully Martin will chime in. I'm more than happy to help test. Cheers, Mark

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 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 version and install a different version - but some sites may end up in a dilemma here - they may be *forced* to use IIS in 32bit mode due to no 64bit port for a tool they need, but simultaneously desire a 64bit build of Python for other tasks on that same box.

It's incorrect for a Win64 installer to make the executable components Win32.

Right - I got the impression from Micheal that it was possible for 32bit components to be installed in a 64bit install, but I don't profess to know anything about this.

A 64 bit pythonxy.dll cannot work in a 32-bit IIS - it's a different instruction set. That's not something that you can fix by just installing things differently.

Exactly - which is why I'm suggesting that not "allowing" 64bit and 32bit versions of Python to be installed on the same box will cause inconvenience for some people. I agree such people will be in the minority, and their requirements are not clear, so I'm not pushing for a change of policy here.

...

using _winreg is (almost) like using the API directly. RegDisable[/Enable]ReflectionKey appears to let the 32bit process see the real keys - I'm not aware of how 64bit apps would enable that reflection, but it probably doesn't really matter for our purposes.

They can specify KEY_WOW64_32KEY.

Ah - thanks. Cheers, Mark

On 7/13/07, Mark Hammond 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 installing a 64bit program!

I haven't worked with it enough to know all the intracacies, but the short of what I know is if your template is i386, you can only install to 32-bit locations. If it is x64 or Intel64, then you can only install on machines of those architectures, and the 64-bit locations become available to components marked as 64-bit.

using _winreg is (almost) like using the API directly. RegDisable[/Enable]ReflectionKey appears to let the 32bit process see the real keys - I'm not aware of how 64bit apps would enable that reflection, but it probably doesn't really matter for our purposes. In case anyone is interested, I just made a patch to _winreg.c adding these 2 functions (http://python.org/sf/1753245) in case anyone would like to review it.

http://msdn2.microsoft.com/en-us/library/aa384129.aspx describes the KEY_WOW64_64KEY and KEY_WOW64_32KEY flags, allowing explicit access to either set from either type of application.

I think Tools\msi is what you are looking for, but hopefully Martin will chime in. I'm more than happy to help test.

Thanks, and I see he has, and perhaps I've been looking at an incorrect file... -- Michael Urman

On 7/13/07, "Martin v. Löwis" 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 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.

As we don't want any redirection, setting the flag on all components should be correct.

It may well be fine for the Python installers. Without the flag, locations such as the 64-bit folder destinations resolve to the 32-bit redirected locations, and the registry resolves to the 32-bit reflected registry. The former isn't particularly helpful in any case I can think of (as the non 64-bit locations are available anyway), but the latter could be important if an 64-bit install needs to set 32-bit registry keys.

...

The former, with hints of caution: it appears the unused 64-bit code paths of msilib were created to best serve under incorrect assumptions. With what the code would create (with or without Win64 set), it will not generate the 64-bit registry keys that the 64-bit program will access.

Why do you say that? What registry keys do you think it creates, and what registry keys do you think it should create instead?

Perhaps it's my reading the wrong version (the one I linked above doesn't even have the string x64), or my assumption that msilib would target a more general use case than pure 64-bit / pure 32-bit installers. Or I missed the easy way to interleave 64 and 32-bit components.

There are no "64-bit registry keys" on Windows; Win64 only has "normal registry keys" and "32-bit (i.e. redirected) registry keys".

I find that nomenclature distinction to be more confusing than referring to them "incorrectly" :)

I always test whether the AMD 64 binary installs correctly before releasing it.

And I ran no tests at all, so I defer to you here.

You don't need to provide patches - just tell me what's wrong with the MSI file. I.e. look at it in orca, correct it so that it works correctly, then report what changes you made.

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.amd64.msi (linked from http://www.python.org/download/) -- Michael Urman

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 for some other reason.

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 Mark, can you please report whether that fixes your problem? Regards, Martin

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 only with the corrected version and I'm wondering the best way to get people to test it... Cheers, Mark.

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 isn't use to create the installer. Instead, look at http://svn.python.org/view/python/trunk/Tools/msi/msilib.py?rev=55245&view=markup

Perhaps it's my reading the wrong version (the one I linked above doesn't even have the string x64), or my assumption that msilib would target a more general use case than pure 64-bit / pure 32-bit installers.

Why should it? I have yet to see a use case for that.

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.amd64.msi (linked from http://www.python.org/download/)

Indeed. Regards, Martin