Allow Registry Iterator functions to use a specified WOW64 mode when iterating.

chrome/installer/util/app_commands.cc

Index: chrome/installer/util/app_commands.cc
diff --git a/chrome/installer/util/app_commands.cc b/chrome/installer/util/app_commands.cc
index de7dcc266ebbb4a414f11c01b1c9f622bc1aaedd..4f98a4fac448ef72daba5b293866ff1497eb67a6 100644
--- a/chrome/installer/util/app_commands.cc
+++ b/chrome/installer/util/app_commands.cc
@@ -33,8 +33,10 @@ bool AppCommands::Initialize(const base::win::RegKey& key) {
   RegKey cmd_key;
   LONG result;
   AppCommand command;
-  for (RegistryKeyIterator key_iterator(key.Handle(), kEmptyString);
-       key_iterator.Valid(); ++key_iterator) {
+  for (RegistryKeyIterator key_iterator(
+           key.Handle(), kEmptyString, KEY_WOW64_32KEY);

[grt (UTC plus 2), 2014/10/01 17:14:30]

this is ugly. it so happens that it's correct, but it isn't clear from the
interface.

[Will Harris, 2014/10/01 17:20:21]

yes, and it's not by coincidence, I manually went through every call to check
what access to supply.

I agree it's ugly - I considered:

 - exposing an interface on RegKey to determine what wow64access it had
originally been opened with, then we could pass this into RegistryKeyIterator
 - adding a new constructor on RegistryKeyIterator to take a RegKey instead of a
handle (but I think this would be against chromium coding standard)

If you have any suggestions how this could be made more elegant they would be
appreciated.

[grt (UTC plus 2), 2014/10/01 17:33:49]

I wish I did. The whys and wherefores for these magic bitness values are fairly
hard to understand/remember.

[cpu_(ooo_6.6-7.5), 2014/10/06 19:48:57]

you can have as many constructors as you need, in particular peppering the
codebase with (.., 0) is bad form.

[Will Harris, 2014/10/07 02:03:16]

Done.

+       key_iterator.Valid();
+       ++key_iterator) {
     const wchar_t* name = key_iterator.Name();
     result = cmd_key.Open(key.Handle(), name, KEY_QUERY_VALUE);
     if (result != ERROR_SUCCESS) {