Michael Urman schrieb:
On 7/12/07, Mark Hammond
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 version. In Python 2.5, it also sets it to x64, if the PE machine type is 0x8664.
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).
Right. That's why I provide three installers.
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.
That's correct. I'm also uncertain what precisely the Win64 flag on a component means, according to http://msdn2.microsoft.com/EN-US/library/aa368007.aspx msidbComponentAttributes64bit means # Set this bit to mark this as a 64-bit component. This attribute # facilitates the installation of packages that include both 32-bit and # 64-bit components. If this bit is not set, the component is registered # as a 32-bit component. # # If this is a 64-bit component replacing a 32-bit component, set this # bit and assign a new GUID in the ComponentId column. When I started to work on this, I found that not setting the Win64 bit at all "does not work", although I forgot the details what precisely failed. I found some articles in the net that suggest that this flag turns off redirection, e.g. http://blogs.msdn.com/heaths/archive/2006/04/14/avoid-overwriting-files-in-a... As we don't want any redirection, setting the flag on all components should be correct.
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? There are no "64-bit registry keys" on Windows; Win64 only has "normal registry keys" and "32-bit (i.e. redirected) registry keys".
With Win64 set it will not even install except on an Itanium system.
I always test whether the AMD 64 binary installs correctly before releasing it.
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.
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.
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. Regards, Martin