This is a pretty tiny bug..

The test_reg_class test in test_msvc9compiler.py assumes that there is a
Notepad registry key on Windows systems.  That appears to be false until
Notepad is run the very first time.  I ran into this setting up a build
slave VM, where I never had the need to run Notepad.

I guess it's pretty rare for Notepad not to be run eventually, but
clearly the comments in the test saying the key is always present is
inaccurate, and perhaps a different key should be chosen or at least
have the test not fail if the key is missing.

It also appears that Windows 7 doesn't have that key even after Notepad
is run.

As you now have access to freshly-installed systems: can you propose
such a key?

Well, I can at least start by comparing XP and Win7 immediately
post-installation.  Any suggestions on guidelines to what can be chosen?
 Does it have to be a DWORD, or a 0/1 value, or under HKCU for a
specific reason?

Since I was feeling bad for the Windows 7 build slave not being able to
pass the tests due to this (at least when other tests weren't failing),
I manually added a matching key on the slave pending any test changes.

In looking around, since this test is specifically part of the
msvc9compiler test module, thus presumably we know that VC9 (VS2008) is
installed, how about a key that is VC9 specific?  It would appear that
"HKCU\Software\Microsoft\VisualStudio\9.0\VC\Build Timing" (DWORD,
default 0) is present on a brand new VS 2008 install.  It's also present
in both the full VS version as well as express.

If the test also needs to support VC8 (VS2005), the same key is present
but under "8.0" rather than "9.0" so the test would need to pass if
either worked.

(Oh, and a correction to my last comment about HKCU - I missed that the
Reg.get_value() in the failing part of the test checks multiple roots,
not just HKCU).

> Does it have to be a DWORD, or a 0/1 value, or under HKCU for a
> specific reason?

This notepad test was just to make sure the registry reader works
by returning a known value.

I can change it using:

Reg.get_value("Software\Microsoft\VisualStudio\9.0\VC", "Build Timing")
 == 0


For this test, if you can check that this value is the same on a fresh
win XP and 7, it's perfect. (8.0 doesn't matter here, I can restrict the
build version to 9.0)

Our last comments may have crossed, but as I mentioned in my last one,
yes, as best I can tell from my slaves (XP+VS-Express, XP+VS-Standard,
Win7+VS-Standard), the Visual Studio key is present in a brand new
install.  Note that it is not present in a brand new XP or Windows7
install, but only after Visual Studio (Express or Standard) is
installed.  So it comes along with Visual Studio regardless of platform,
although the key does change according to VS version.

I think that should be fine, since the test is only running in a Visual
Studio environment to start with, so having a VS-based key should be
just as good as a Windows-based key.

Oh, Tarek, something I missed in your last comment - for the "Build
Timing" key, it should probably permit the value to be either 0 or 1,
just as the current test does.  Just in case someone happens to have
build timing turned on.

I made a test on my Express edition on the "FullScreen" value, but I
don't have a "Build Time" one.

Do you have a "FullScreen" key ?

can you run this in a shell, to see what value you get for FullScreen, 
and for build time ? (I find it strange that this one has a space btw, I
couldn't find a key with a space on my side)

>>> from distutils.msvc9compiler import Reg
>>> path = r'Software\Microsoft\VisualStudio\9.0'
>>> Reg.get_value(path, u"fullscreen")
>>> Reg.get_value(path, u"build timing")

If you get a value for fullscreen, we can have the same test for VC9 and
VCExpress.

The "Build Timing" key (not Build Time) is the only one at all under
HKCU/VisualStudio/9.0/VC (and actually the only key under the entire
HKCU/VisualStudio tree) on both my XP and Win7 new VS 2008 installation.
 I can't rule out it being part of SP1 which I included in the install,
though I found references on the web to it earlier than that.

It's strange though, because I've also verified that key on the older XP
build slave that was installed with VC Express (and never was installed
with the full version, nor did I use any service packs other than what
was part of VC Express), so I'm a bit surprised that you don't have it
in your install.

I don't have Fullscreen keys in that tree, although I did find a
Fullscreen key under HKCU/Software/Microsoft/VCExpress/9.0 just on my
express installation on XP.  It's possible that key only gets created
when you actually run Visual Studio (which I generally don't on
buildbots), but I suspect the path would differ between express and regular.

There's nothing else that looks viable under HKCU, at least related to
Visual Studio.  All of my other brand-new-install keys are under HKLM
instead, but there's a larger divergence between express and standard. 
It appears that on VC express most keys end up under
HKLM/Software/Microsoft/VCExpress/9.0, while under VS 2008 standard
they're the same path but "VisualStudio" instead.

Another choice that might be pretty safe as an alternate possibility,
but you have to be willing to separate the express and standard checks,
is the HKLM/Software/Microsoft/XXXX/9.0/ApplicationID key.  XXXX is
"VCExpress" or "VisualStudio" and that's also the value of that key.

Alternatively, as siblings to the ApplicationID key, I have two keys
that have common values between the express and standard installs:
"EnablePreloadCLR" and "RestoreAppPath" are both 1 in all installs.  I'm
guessing both represent boolean flags so accepting either 0 or 1 would
work, but that's a guess, so the ApplicationID key may be a better choice.

Oh, BTW, you were missing the VC part of the path in your test.  But if
I run the same code with that corrected on my Win7 box, I get:

>>> from distutils.msvc9compiler import Reg
>>> path = r'Software\Microsoft\VisualStudio\9.0'
>>> Reg.get_value(path, u"fullscreen")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "D:\python\2.6\lib\distutils\msvc9compiler.py", line 62, in get_value
    raise KeyError(key)
KeyError: u'fullscreen'
>>> path = r'Software\Microsoft\VisualStudio\9.0\VC'
>>> Reg.get_value(path, u"build timing")
0

I get the same results on my XP+VS 2008 box but also on my XP + VC
Express box.  (E.g., "fullscreen" doesn't work on any of them)

Ok so, can you confirm this is working on your side ?

VisualStudio 9:

>>> from distutils.msvc9compiler import Reg
>>> path = r'Software/Microsoft/VisualStudio/9.0'
>>> Reg.get_value(path, u"applicationid")
'VisualStudio'
>>> import _winreg
>>> HKCU = _winreg.HKEY_CURRENT_USER
>>> 'VisualStudio' in Reg.read_keys(HKCU, r'Software\Microsoft')
True


VCExpress 9: (works for me on Windows XP - VC ++9.0 Express edition)

>>> from distutils.msvc9compiler import Reg
>>> path = r'Software/Microsoft/VCExpress/9.0'
>>> Reg.get_value(path, u"applicationid")
'VCExpress'
>>> import _winreg
>>> HKCU = _winreg.HKEY_CURRENT_USER
>>> 'VisualStudio' in Reg.read_keys(HKCU, r'Software\Microsoft')
True

Yes to both examples (the first on my VS 2008 full installs on XP and
Windows 7, and the second on my XP with VC++ Express).

Two caveats (that I don't think invalidates the result) though.

First, I can't use forward slashes in the path I supply to
Reg.get_value, they have to be backslashes.  But I'm running the tests
under a Python 2.6.x, so perhaps this was changed in a later release.

At least in my case, the results of Reg.get_value() are unicode strings,
not regular strings.  I thought perhaps your code was under Python 3.x,
but then I saw you were still using u"applicationid" so I'm not sure.

Ooops my bet, that's a typo, it's backlashes you are right.


I'll change the test now, thanks a lot for all the feedback !

There's one more thing we didn't take care of in our change: windows
platforms where people just install Python and run tests, so there's no
VC++ installed.

For them I guess we can use: r'Software\Microsoft\Windows\CurrentVersion'
and look for the u'productid' value, and just make sure its not empty.

Would you mind checking that you have this key on your windows
plartforms ? I've checked on XP.

Oh, my bad - I was working on the assumption that test_msvc9compiler was
testing compiler related stuff, so obviously would have the compiler
installed.  But it makes sense you might test support for that compiler
on a machine other than the one doing the building.

As for ProductId, Windows 7 has that under the "Windows NT" key instead
of "Windows".  My XP systems seem to have it in both places.  Don't know
about earlier Windows versions.

If it's something for general use, how about HKCU\Control
Panel\Desktop\DragFullWindows (REG_SZ, but should be 0 or 1).  Everyone
should have desktop settings.  It's on both my XP and Win7 systems. 
Looking around at http://www.pctools.com/guides/registry/ would seem to
indicate that key should be present on all releases back to Win95,
though some other web references make it unclear if the key is
automatically there on Win9x.  I can do some quick test installs to
verify if I get a moment tonight though.

Alternatively, you could just pick something for Windows 7 and let any
other platform default back to the old Notepad key, perhaps fixing the
error message to suggest running Notepad?  It's not like anyone else has
complained about the test failing before this, and it's only Windows 7
for which running Notepad the first time won't create the necessary key.

I suppose checking for the desktop key first, and falling back to the
notepad key would accomplish the same thing without having to check
platform.

-- David

PS: Have we hit our "ridiculous amount of effort expended against such a
small item" quota yet?  :-)

> If it's something for general use, how about
HKCU\ControlPanel\Desktop\DragFullWindows 

Yes I'll just use this one.

> I can do some quick test installs to verify if I get a moment tonight
though.

Don't worry about it. XP and Windows 7 are enough to make the test
better here. 


> PS: Have we hit our "ridiculous amount of effort expended against 
> such a small item" quota yet?  :-)

Definitely :) 

Thanks for your patience and time.

r76358 and r76360 and r76361

Thanks David !