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 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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
