Determining Win7 32-bit or 64-bit

Started by stevengraff, February 10, 2014, 08:41:06 AM

Previous topic - Next topic

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


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

Deana F.
Technical Support
Wilson WindowWare Inc.

stevengraff

QuoteIt 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.
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

stevengraff

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

td

"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

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

QuoteRedirected 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

Quote from: td on February 11, 2014, 06:48:55 AM
Quote from: stevengraff on February 10, 2014, 06:55:34 PM
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

Quote from: stevengraff on February 11, 2014, 07:13:28 AM
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

QuoteRedirected 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.   
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

td

Quote from: stevengraff on February 11, 2014, 07:03:37 AM
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.
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

stevengraff

Quote from: td on February 11, 2014, 09:26:37 AM
Quote from: stevengraff on February 11, 2014, 07:13:28 AM
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

QuoteRedirected 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

;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




Deana F.
Technical Support
Wilson WindowWare Inc.

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

Quote from: stevengraff on February 12, 2014, 05:26:18 AM
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.

Quote
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).
Quote
Question 2... RegOpenFlags affects affects how subsequent  registry statements behave, true? 'til when? 'til another RegOpenFlags statement?
Correct.
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

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. 
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

stevengraff

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