When you install 32-bit CPython 'for the current user
only' on 64-bit Windows, the installation does not show
up in the Windows 'Add/Remove Programs' dialog (a.k.a.
'Programs and Features' dialog on Windows 7). It does
not show up there even for the current user.

I tested this CPython installation behaviour with the
following CPython versions:
  * 2.3.4 - works correctly
  * 2.5.4 - works correctly
  * 2.6.0 - works correctly
  * 2.6.2 - works correctly
  * 2.6.3 - does not work correctly
  * 2.6.4 - does not work correctly
  * 2.6.6 - does not work correctly
  * 2.7.6 - does not work correctly
  * 3.3.3 - does not work correctly
  * 3.3.5 - does not work correctly
  * 3.4.0 - does not work correctly

All this has been tested using one Windows 7 SP1 (x64)
machine and using only CPython 3.4.0 installation on
another.

Several related observations, indicating that this could
be some sort of a Windows Installer misconfiguration
issue possibly solvable in the CPython installer:

* The same does not occur when you install a 64-bit
  CPython version - its entry is correctly displayed in
  the 'Add/Remove Programs' dialog.

* 32-bit CPython installer still correctly detects that a
  specific 32-bit version has already been installed,
  even if that previous installation is not listed in the
  'Add/Remove Programs' dialog.

* When you ask Windows using its WMI interface to list
  all the products installed on it (e.g. by running
  'wmic product list' on the command-line), all the
  installed CPython versions are correctly displayed,
  even the 32-bit versions not displayed in the
  'Add/Remove Programs' dialog.

I compared MSI packaging related CPython source code
(Tools/msi folder) in 2.6.2 & 2.6.3 releases but failed to
see anything suspicious there. It could be that the
observed beaviour change between those two versions is a
result of the final release packager changing his used
Windows Installer version, but I have not rebuilt CPython,
and its MSI installer to test this theory out.

Here is a possible 'workaround' for the issue, but it
will take someone more knowledgeable about the Windows
Installer infrastructure to say if the workaround can be
applied directly as a clean solution or if it could have
hidden consequences.

Each 32-bit installation on 64-bit Windows has its own
'Uninstall' registry key under:

> HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall

named after its Windows Installer assigned GUID, e.g.:

> HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\{A37F2D73-72D1-364D-BA5D-CEA430BCC040}

In that key there is a value named 'WindowsInstaller'
which for CPython installations has the value '1' (of
type REG_DWORD).

If you change that value to '0' (again, of type REG_DWORD),
the installation's 'Add/Remove Programs' dialog entry will
get displayed correctly, and user will be able to run the
installation (reinstall/change/uninstall) from there.

This issue can confuse a regular user in the following
scenario:

1. User uses 'for current user only' Python installations.

2. User expects to be able to see all installed software
   listed in the 'Add/Remove Programs' dialog and does
   not know that the listing presented there might be
   incomplete, how to use WMI to get an alternative
   listing or have any other indication that he should
   look for some external software providing this
   listing.

3. User has 32-bit & 64-bit CPython 3.4.0rc3 installed on
   his machine.

4. User uninstalls the 64-bit CPython 3.4.0rc3 version
   and installs a new 64-bit CPython 3.4.0 release. No
   problems there.

5. User now wants to remove the old 32-bit CPython
   3.4.0rc3 installation from his computer.

6. User checks the 'Add/Remove Programs' dialog and does
   not see the installation listed there.

7. User checks the 32-bit CPython 3.4 related Start menu
   folder for an uninstall link, but all the links there are
   related only to the 64-bit CPython 3.4.0 installation.

8. User checks the 32-bit CPython 3.4.0rc3 installation
   target folder (where its python.exe and other files are
   located) but finds no uninstaller there either.

9. Since there is no uninstaller to be found for this CPython
   installation, user assumes it is ok to just delete its
   folder and does so.

10. User attempts to install a new 32-bit CPython 3.4.0
    installation and that breaks dues to not being able to
    uninstall a detected previous installation.

If user thinks of it - he can now work around this by finding
an old installation package for the previously installed
32-bit CPython version, running that, choosing to first
repair the current installation and then run the installation
again to remove the current installation.

Or clean up the previous installation's Windows Installer
related registry entries by hand (painful & error prone).

Or be unable to ever install a new version. :-)

And, speaking from personal experience :-D, if he does apply
the workaround he can 'feel dumb' about not locating and
trying out the original installation before removing the
original installed data and cuss & fuss about nothing around
him instructing him to look into that possibility. :-D

If nothing else, this could be 'patched up' by having
CPython's Windows installer that fails to uninstall a
previous installation, suggest manually repairing the
previous installation by running its installation package
directly before attempting to rerun this installation. It
could also reporting the original installation's install
package location on disk, as read from the registry
(Windows Installer makes a copy under some random generated
name which user is unlikely to find by simple trial & error).

Here are some more Windows Installer notes taken down
when originally researching this issue on my end.
Hopefully they can be of some use to anyone researching
the issue further:

- each installation gets a GUID key identifying it

- the installation GUID key can be converted into a
  corresponding product key using the following
  algorithm:

def guid_to_product_key(guid):
    """guid = string in format {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}"""
    parts = guid.lstrip("{").rstrip("}").split("-")
    key = []
    # Reverse the first 3 parts.
    for p in range(3):
        key.extend(reversed(parts[p]))
    # Swap character pairs in remaining parts.
    for part in parts[3:]:
        for i in range(len(part) // 2):
            key.append(part[2 * i + 1])
            key.append(part[2 * i])
    return "".join(key).upper()

- some Windows Installer registry keys related to a
  specific installation:

  Example installation GUID key:
    {a37f2d73-72d1-364d-ba5d-cea430bcc040}
  Example product key:
    37D2F73A1D27D463ABD5EC4A03CB0C04
  Installed for example user with SID:
    S-1-5-21-2100645858-3408510361-1554613642-1000

  HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Uninstall\{a37f2d73-72d1-364d-ba5d-cea430bcc040}
  HKEY_CURRENT_USER\Software\Microsoft\Installer\Products\37D2F73A1D27D463ABD5EC4A03CB0C04
  HKEY_CURRENT_USER\Software\Microsoft\Installer\Features\37D2F73A1D27D463ABD5EC4A03CB0C04

  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-21-2100645858-3408510361-1554613642-1000
\Products\37D2F73A1D27D463ABD5EC4A03CB0C04
  HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\{A37F2D73-72D1-364D-BA5D-CEA430BCC040}

  Product key listed under several different subkeys under:
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-21-2100645858-3408510361-1554613642-1000\Components

  Product key listed under:
    HKEY_CURRENT_USER\Software\Microsoft\Installer\UpgradeCodes\84ED6E56853AD434AAF4A47FD24B17F8
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UpgradeCodes\84ED6E56853AD434AAF4A47FD24B17F8

There was a request on the python-dev to check this on windows 8.
I confirm the same behavior.

Windows 8.1 Pro 64bit
Python 3.4.0 32bit (release)

Installed current user:
Does not show up in Add/Remove Programs
Installer correctly sees installation and can remove it
"wmic product" correctly sees installation

Presumably this can be incorporated into the ongoing work on the Windows installer.

If Martin wants to fix this for 3.4 he's welcome to, but otherwise this issue is out of date for 3.5.

Based on Steve's last comment on this issue, should this be closed as 'Out of Date'?