Determining Win7 32-bit or 64-bit

[stevengraff]

I had been using:

bit64=RegExistKey(@REGmachine, "Software\wow6432Node")

But I found out this is not a reliable method. A user's machine has this key, but is actually a 32-bit version of Win 7.

What's a/the best, most reliable, easiest way to determine this?

[JTaylor]

WinMetrics()

Jim

[stevengraff]

x=winmetrics(-7)

returns 2 if 64-bit or 0 for everything else.

[Deana]

It is never a good idea to directly access registry keys stored under WOW6432node.

I use WinMetrics to determine the Platform bitness:  http://techsupt.winbatch.com/webcgi/webbatch.exe?techsupt/tsleft.web+WinBatch/64-bit+How~To~Check~If~Computer~Is~Running~A~32~Bit~or~64~Bit~Operating~System.txt

Local machine bitness can be determined using the WinMetrics Function.   

Code (winbatch) Select Expand

If WinMetrics(-7)|WinMetrics(-2)==3 Then Pause('Windows Bitness','64-bit Platform')
Else Pause('Windows Bitness','32-bit Platform')


[stevengraff]

It is never a good idea to directly access registry keys stored under WOW6432node.

Why?

[td]

MSFT states, "The Wow6432Node key is reserved. For compatibility, applications should not use this key directly."  MFST states similar warnings in multiple places in several different ways in the Win32 API registry function documentation.

Experience also indicates that accessing the key can sometimes cause unexpected outcomes depending on the combination of OS bitness, OS version, and application bitness.

Practically, you can get by with it until you can't.

[stevengraff]

Surely it couldn't hurt just to read it though, right?

[td]

Surely it couldn't hurt just to read it though, right?

Wrong.

[stevengraff]

Ugh! This is like particle physics? The mere act of observing it changes it?!

[stevengraff]

Here's an excerpt from what appears to be a fairly authoritative source,  http://msdn.microsoft.com/en-us/library/windows/desktop/aa384232(v=vs.85).aspx

Redirected keys are mapped to physical locations under Wow6432Node. For example, HKEY_LOCAL_MACHINE\Software is redirected to HKEY_LOCAL_MACHINE\Software\Wow6432Node. However, the physical location of redirected keys should be considered reserved by the system. Applications should not access a key's physical location directly, because this location may change. For more information, see Accessing an Alternate Registry View.

As I read this, it admonishes us to avoid accessing the actual physical keys, but we should, instead, rely on the Wow6432Node version of the keys, which represent mappings, or pointers, to the actual keys. The redirection protects us from failure in case the key's physical location should move.

[snowsnowsnow]

Surely it couldn't hurt just to read it though, right?

Wrong.

It'd be nice if you could amplifiy on this.  ISTM that there are two ways in which it could be a problem:

1) Because it is unreliable - i.e., you might not get the results you expect.  This is the soft version of things.

1a) An even softer version of this is: It works OK now, but is not guaranteed to work in the future.   I.e., your code, although perfectly fine now, is not "future-proof".

2) (The hard version)  The mere act of looking at it might cause what the C folks call "undefined behavior" - which could result in your hard drive being reformatted.

[td]

Here's an excerpt from what appears to be a fairly authoritative source,  http://msdn.microsoft.com/en-us/library/windows/desktop/aa384232(v=vs.85).aspx

Redirected keys are mapped to physical locations under Wow6432Node. For example, HKEY_LOCAL_MACHINE\Software is redirected to HKEY_LOCAL_MACHINE\Software\Wow6432Node. However, the physical location of redirected keys should be considered reserved by the system. Applications should not access a key's physical location directly, because this location may change. For more information, see Accessing an Alternate Registry View.

As I read this, it admonishes us to avoid accessing the actual physical keys, but we should, instead, rely on the Wow6432Node version of the keys, which represent mappings, or pointers, to the actual keys. The redirection protects us from failure in case the key's physical location should move.

I believe you are misreading it. It is telling you to use registry views which is not the same thing as using "Wow6432Node".  Both Win32 and WinBatch provide methods for accessing views independent of ever specifying "Wow6432Node".  But if you choose not to use registry views and use "Wow6432Node" instead, that is your privilege.  Do diligences has been performed.

[edit] To elaborate a little more, you cannot assume that because you can see "Wow6432Node" using regedit.exe that you will also be able to always "see" the key using the win32 registry API functions the WinBatch relies on.   

[td]

Ugh! This is like particle physics? The mere act of observing it changes it?!

The Heisenberg principle has been metaphorically applied to many things but in the world of computer science, it is usually reserved for descriptions of quantum computing.

[stevengraff]

Here's an excerpt from what appears to be a fairly authoritative source,  http://msdn.microsoft.com/en-us/library/windows/desktop/aa384232(v=vs.85).aspx

Redirected keys are mapped to physical locations under Wow6432Node. For example, HKEY_LOCAL_MACHINE\Software is redirected to HKEY_LOCAL_MACHINE\Software\Wow6432Node. However, the physical location of redirected keys should be considered reserved by the system. Applications should not access a key's physical location directly, because this location may change. For more information, see Accessing an Alternate Registry View.

As I read this, it admonishes us to avoid accessing the actual physical keys, but we should, instead, rely on the Wow6432Node version of the keys, which represent mappings, or pointers, to the actual keys. The redirection protects us from failure in case the key's physical location should move.

I believe you are misreading it. It is telling you to use registry views which is not the same thing as using "Wow6432Node".  Both Win32 and WinBatch provide methods for accessing views independent of ever specifying "Wow6432Node".  But if you choose not to use registry views and use "Wow6432Node" instead, that is your privilege.  Do diligences has been performed.

[edit] To elaborate a little more, you cannot assume that because you can see "Wow6432Node" using regedit.exe that you will also be able to always "see" the key using the win32 registry API functions the WinBatch relies on.   

So, if I were relying on something like:

if bit64 then regpath = "Software\wow6432Node\odbc\odbcinst.ini\odbc drivers"
ODBCkeyExists = RegExistKey(@REGmachine, regpath)

to check for the right version of the MySQL driver, I'd be (potentially) on shifting sands?

I'm not sure where else in the registry I would look to find a sure-fire imprint of MySQL's existence! Perhaps somewhere less human-readable?

I thought for something so seemingly surgically limited in scope this would be simpler than adding the odbc extender. It lists the current drivers so succinctly. Presumably the odbc extender is not relying on wow6432Node entries?

[Deana]

2 simple rules to accessing the registry on 64-bit systems:

• NEVER directly access keys stored under WOW6432node.
• If you do want access something under WOW6432node, just set the registry view to 32-bit using RegOpenFlags(32) and specify the key/value without using 'WOW6432node' in the registry path. (In other words use it 's regular 32-bit key/value.)

Reference: http://techsupt.winbatch.com/webcgi/webbatch.exe?techsupt/tsleft.web+WinBatch/Registry+Accessing~Alternate~Registry~View.txt

Here is the code you could use to accomplish reading the registry on a 64-bit system:

Code (winbatch) Select Expand


;Specifies the registry view of the various Reg[..] functions.
RegOpenFlags( 64 )
ret = RegExistKey( @RegCurrent, 'SOFTWARE\ODBC\ODBC.INI')
If ret
    Pause('Notice','ODBC.INI Key Exists. You can now examine the key to see if it contains your driver.')
Else
    Pause('Notice','ODBC.INI Key Does Not Exist')
EndIf


[stevengraff]

Thanks Deana, for leading a blind and wandering soul out of the desert!

(btw, Looks like it's RegOpenFlags ( 1 ) for 32-bit or RegOpenFlags (2) for 64-bit. )

Question 1... since I'm only trying to find, in my case, a 32-bit entry, why bother testing for 64-bitness, why not just use RegOpenFlags(1) without testing? It seems to work fine on a 64-bit Server '08 as well as an XP box, no problem. So, in 64 bits it does what I need, and in 32-bits it's ignored. Just not "good practise?"

Question 2... RegOpenFlags affects affects how subsequent  registry statements behave, true? 'til when? 'til another RegOpenFlags statement?

[td]

Thanks Deana, for leading a blind and wandering soul out of the desert!

(btw, Looks like it's RegOpenFlags ( 1 ) for 32-bit or RegOpenFlags (2) for 64-bit. )

Yes that is true on old versions of WinBatch.  Newer versions use 32 or 64 instead.

Question 1... since I'm only trying to find, in my case, a 32-bit entry, why bother testing for 64-bitness, why not just use RegOpenFlags(1) without testing? It seems to work fine on a 64-bit Server '08 as well as an XP box, no problem. So, in 64 bits it does what I need, and in 32-bits it's ignored. Just not "good practise?"

If you are only looking for the 32-bit registry settings then there is no reason to test the bitness of the OS. Just set the RegOpenFlags parameter to 32 (1).

Question 2... RegOpenFlags affects affects how subsequent  registry statements behave, true? 'til when? 'til another RegOpenFlags statement?

Correct.

[td]

The last answer needs a  bit of qualification.  Depending on your WinBatch version, the registry functions may have an optional view parameter that sets the view for that function only.  This overrides the RegOpenFlags view setting. 

[stevengraff]

After all this unexpected (but welcome) training on the Registry... I need a nap. ::)