When installing Visual Studio 2008 SP1 on a Windows Vista x64 system, the installer registers the various registry keys under

Software\Wow6432Node\Microsoft\VisualStudio\9.0\

rather than

Software\Microsoft\VisualStudio\9.0\

This is due to some redirection MS is applying to registry names when running 32-bit apps (such as the VS2008 installer) on 64-bit Windows:

http://support.microsoft.com/kb/896459

Since the tools in msvc9compiler.py rely on the registry to find the various dirs, batch files and tools, these operations fail.

A simple solution is to just update the globals at the top of the file to:

VS_BASE = r"Software\Wow6432Node\Microsoft\VisualStudio\%0.1f"
WINSDK_BASE = r"Software\Wow6432Node\Microsoft\Microsoft SDKs\Windows"
NET_BASE = r"Software\Wow6432Node\Microsoft\.NETFramework"

but that would of course have to be done with some extra checks to not break these settings on other Windows systems.

I'm not sure whether this is specific to Windows Vista or also occurs on Windows 7.

This shouldn't be necessary. If a 32-bit Python looks into the registry, it will get automatically redirected to Wow6432Node. If a 64-bit Python looks into the registry, it shouldn't have any interest in values stored in Wow6432Node.

Martin v. Löwis wrote:
> 
> Martin v. Löwis <martin@v.loewis.de> added the comment:
> 
> This shouldn't be necessary. If a 32-bit Python looks into the registry, it will get automatically redirected to Wow6432Node. If a 64-bit Python looks into the registry, it shouldn't have any interest in values stored in Wow6432Node.

Perhaps I wasn't clear:

The VS2008 installer as well as the most of VS tool chain appear
to be 32-bit binaries and thus writes its keys and values into
Software\Wow6432Node\Windows\.

If you then run a 64-bit Python binary, it won't find the keys
under the regular Software\Windows\ reg path.

BTW: This was a fresh Vista and VS2008 installation.

Here's a patch fixing the problem.

If possible, the patch should go into Python 2.7 rc2, since without it, you can't build Python extensions on Windows x64 platforms.

The patch looks good but I am not comfortable with this change until it's tested under other windows/VC flavors.

I'll leave it up to Benjamin to decide whether it goes in rc2

Tarek Ziadé wrote:
> 
> Tarek Ziadé <ziade.tarek@gmail.com> added the comment:
> 
> The patch looks good but I am not comfortable with this change until it's tested under other windows/VC flavors.

The patch is really trivial, but I'll test it on a Windows x86
installation as well today.

Would be great if we could get someone else test it on their
Windows x64 system.

It's strange that noone has noticed this problem while Python 2.6
was out. I know that Martin uses a cross-compiling setup to create
the 64-bit installers, so he wouldn't have noticed, but others
should have seen similar problems, trying to compile extensions
on Windows x64.

I guess most people still use the 32-bit Python installers on Windows
x64 systems.

I am adding srid in the nosy list. I believe he can test those platforms as well if he's around

Win2003 x64, VS2008, vanilla python 2.7rc1 amd64 from python.org.
Building python packages with C extensions works fine. Tested on simplejson, jinja2 (with enabled speedups) and PIL.

Konstantin Zemlyak wrote:
> 
> Konstantin Zemlyak <zart@zartsoft.ru> added the comment:
> 
> Win2003 x64, VS2008, vanilla python 2.7rc1 amd64 from python.org.
> Building python packages with C extensions works fine. Tested on simplejson, jinja2 (with enabled speedups) and PIL.

I assume that you built without the patch applied. Does it also work
with the patch ?

This is the relevant section from the KB article:

"""
When you install a new program or when you run a program on a Windows x64 Edition computer, registry
calls made by 64-bit programs access the HKEY_LOCAL_MACHINE\Software registry sub key without
redirection. WOW64 intercepts registry calls to HKEY_LOCAL_MACHINE\Software that are made by 32-bit
programs, and then redirects them to the HKEY_LOCAL_MACHINE\Software\WOW6432node sub key.
"""

Since VS2008 is a 32-bit application, the registry keys are written
to the HKEY_LOCAL_MACHINE\Software\WOW6432node branch.

64-bit applications such as Python AMD64 don't see this indirection,
so they have to explicitly look in that branch to find VS2008 settings.

I checked the registry on the machine and indeed the VS2008 keys are
only available under the HKEY_LOCAL_MACHINE\Software\WOW6432node branch.

I checked this again using Python 2.7rc1 AMD64 on Windows Vista x64
using VS2008 and get the same error:

error: Unable to find vcvarsall.bat

Here's an updated patch for Python 2.7rc1.

64-bit Windows, 64-bit cmd.exe, 64-bit python, not patched::

	D:\>"c:\Program Files\Python27\python.exe"
	Python 2.7rc1 (r27rc1:81787, Jun  6 2010, 20:03:36) [MSC v.1500 64 bit (AMD64)]
	on win32
	Type "help", "copyright", "credits" or "license" for more information.
	>>> import distutils.msvc9compiler
	>>> distutils.msvc9compiler.get_build_version()
	9.0
	>>> distutils.msvc9compiler.find_vcvarsall(9.0)
	'c:\\Program Files (x86)\\Microsoft Visual Studio 9.0\\VC\\vcvarsall.bat'
	>>>

How did you test? Maybe it's some difference in setup.

Tried msvc9compiler-py27.patch. find_vcvarsall() still works with the same result, while distutils.msvc9compiler.VS_BASE has been changed.

:: 
	>>> distutils.msvc9compiler.find_vcvarsall(9.0)
	u'c:\\Program Files (x86)\\Microsoft Visual Studio 9.0\\VC\\vcvarsall.bat'
	>>> distutils.msvc9compiler.VS_BASE
	'Software\\Wow6432Node\\Microsoft\\VisualStudio\\%0.1f'

Checked registry, 9.0 is only under Wow6432Node.

Konstantin Zemlyak wrote:
> 
> Konstantin Zemlyak <zart@zartsoft.ru> added the comment:
> 
> 64-bit Windows, 64-bit cmd.exe, 64-bit python, not patched::
> 
> 	D:\>"c:\Program Files\Python27\python.exe"
> 	Python 2.7rc1 (r27rc1:81787, Jun  6 2010, 20:03:36) [MSC v.1500 64 bit (AMD64)]
> 	on win32
> 	Type "help", "copyright", "credits" or "license" for more information.
> 	>>> import distutils.msvc9compiler
> 	>>> distutils.msvc9compiler.get_build_version()
> 	9.0
> 	>>> distutils.msvc9compiler.find_vcvarsall(9.0)
> 	'c:\\Program Files (x86)\\Microsoft Visual Studio 9.0\\VC\\vcvarsall.bat'
> 	>>>
> 
> How did you test? Maybe it's some difference in setup.

I'm running the build process using a batch file which is
invoked through a remote shell.

Trying the same build from within a cmd.exe started locally on
the machine does not cause the error messages, so I guess this
does indeed have to do with the way the Python interpreter
is invoked.

Further inspection shows that in case the registry key is not
found, the find_vcvarsall() function uses the OS environment
to find the installation.

With the local cmd.exe, the OS environment does indeed have the
entry that points the function to the installation:

VS90COMNTOOLS

Using the remote shell, those VS2008 env vars are not set and
so the build fails.

Could you check the registry keys on your installation ?

I put these extra log lines into the find_vcvarsall() function to
see what the registry has stored:

    vsbase = VS_BASE % version
    try:
        productdir = Reg.get_value(r"%s\Setup\VC" % vsbase,
                                   "productdir")
    except KeyError:
        productdir = None

    log.info('VS2008 product dir: %s - %s' % (productdir, vsbase))

    # trying Express edition
    if productdir is None:
        vsbase = VSEXPRESS_BASE % version
        try:
            productdir = Reg.get_value(r"%s\Setup\VC" % vsbase,
                                       "productdir")
        except KeyError:
            productdir = None
            log.debug("Unable to find productdir in registry")

    log.info('VS2008 product dir: %s - %s' % (productdir, vsbase))

The output is:

VS2008 product dir: None - Software\Microsoft\VisualStudio\9.0
VS2008 product dir: None - Software\Microsoft\VCExpress\9.0

Konstantin Zemlyak wrote:
> 
> Konstantin Zemlyak <zart@zartsoft.ru> added the comment:
> 
> Tried msvc9compiler-py27.patch. find_vcvarsall() still works with the same result, while distutils.msvc9compiler.VS_BASE has been changed.
> 
> :: 
> 	>>> distutils.msvc9compiler.find_vcvarsall(9.0)
> 	u'c:\\Program Files (x86)\\Microsoft Visual Studio 9.0\\VC\\vcvarsall.bat'
> 	>>> distutils.msvc9compiler.VS_BASE
> 	'Software\\Wow6432Node\\Microsoft\\VisualStudio\\%0.1f'
> 
> Checked registry, 9.0 is only under Wow6432Node.

Thanks for confirming that. So at least my setup is not special and the
keys do indeed have to be updated fir Win64 platforms.

> Using the remote shell, those VS2008 env vars are not set and
> so the build fails.

Seems it doesn't load user profile.

> The output is:
> 
> VS2008 product dir: None - Software\Microsoft\VisualStudio\9.0
> VS2008 product dir: None - Software\Microsoft\VCExpress\9.0

Same for me. Your patch fixes registry lookup.

Applied patch in r82130. Thanks!

Benjamin Peterson wrote:
> 
> Benjamin Peterson <benjamin@python.org> added the comment:
> 
> Applied patch in r82130. Thanks!

Thanks, Benjamin.