[Python-Dev] Registry keys written by x64 installer

["Martin v. Löwis"]

Michael Urman schrieb:
> On 7/12/07, Mark Hammond <mhammond at skippinet.com.au> 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-administrative-installations.aspx

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