[Yzöwl]

And this from the commandline / batch

WMIC CPU GET ADDRESSWIDTH /VALUE|FIND "=64">NUL 2>&1&&ECHO=[64bit]||ECHO=[x86]

[bphlpt]

GSM, I'm really not trying to argue with you.

gunsmokingman, on 03 March 2013 - 03:17 AM, said:

These are your words that you posted

Quote

PROCESSOR_ARCHITECTURE will be equal to "x86" even though you are running a 64-bit OS on a 64-bit processor.

Yes I said that. But you seem to have missed the first part of the sentence:

bphlpt, on 02 March 2013 - 08:23 PM, said:

But its value is important to check for since in that same unique circumstance that PROCESSOR_ARCHITEW6432 is defined, PROCESSOR_ARCHITECTURE will be equal to "x86" even though you are running a 64-bit OS on a 64-bit processor.

And again, I'm only quoting directly from Microsoft. My only explanation for your results is that the process that was running was a 64-bit process.

Cheers and Regards

This post has been edited by bphlpt: 03 March 2013 - 01:56 PM

[Geej]

PROCESSOR_ARCHITECTURE6432 comes into picture only when 32-bit application is running on x64 OS.
You might find this MSDN article useful.
It describes how x64 OS handles 32-bit applications.
Running 32-bit Applications (Windows)
Also read 'WOW64 Implementation Details'. It mentions PROCESSOR_ARCHITEW6432 environment variable.

In short, PROCESSOR_ARCHITECTURE6432 is not a variable to check your OS bitness.
PROCESSOR_ARCHITECTURE6432 is (as I see it) transparent to the user as it is how the operating system handles internally 32-bit program within a x64 os.

[bphlpt]

I give up. LOL I guess nobody reads or believes MS.

Cheers and Regards

[gunsmokingman]

bphlpt

1:\ Posted code in wrong language, the poster wrote this in VBS
2:\ What you posted was no better than my original post.
3:\ Microsoft you keep saying that, but you have not provided any links to support what you claim.
4:\ Geej and I have posted links to support our claims.
5:\ Yzöwl provided a Cmd script, of VBS from what I read the most accurate way to get OS bit

[bphlpt]

GSM

1:\ Posted code in wrong language, the poster wrote this in VBS - No argument, you are the VBS expert, not me. I just posted the logic of what is recommended to test for, a Batch script command to accomplish that, a link to another discussion about this issue, and a link to an MSDN blog - David Wang at MS - which explains the reasoning behind the recommended solution.

3:\ Microsoft you keep saying that, but you have not provided any links to support what you claim. - Link to MSDN blog was indirectly posted in post #8. The link was available in the discussion thread I linked to here. The link was given in that thread at least three times and the code was also copied from there into the thread. In case folks didn't want to read the full discussion to get the actual MSDN blog link, I then posted the actual MSDN blog link in post #10, and again above, and I'll post it yet again here for your convenience - David Wang at MS. I don't know if David is still with MS or not, but he was part of the MS IIS team for at least five years and blogged at http://blogs.msdn.com from 2004 - 2008. Then on top of that, I posted a copy of almost the entire blog post in post #10 in case people didn't even want to bother going to the MSDN site to read it for themselves. I don't know how much more I need to post to "support what I claim".

It also ends up that this same logic is implemented in the Windows Assessment and Deployment Kit (ADK) for Windows 8/WinPE 4.0. Microsoft Example in ..\Windows Kits\8.0\Assessment and Deployment Kit\Deployment Tools\DandISetEnv.cmd:

@Echo off 

REM 
REM Sets the PROCESSOR_ARCHITECTURE according to native platform for x86 and x64. 
REM 
IF /I %PROCESSOR_ARCHITECTURE%==x86 ( 
    IF NOT "%PROCESSOR_ARCHITEW6432%"=="" ( 
        SET PROCESSOR_ARCHITECTURE=%PROCESSOR_ARCHITEW6432% 
    ) 
) ELSE IF /I NOT %PROCESSOR_ARCHITECTURE%==amd64 ( 
    @echo Not implemented for PROCESSOR_ARCHITECTURE of %PROCESSOR_ARCHITECTURE%. 
    @echo Using "%ProgramFiles%" 
    
    SET NewPath="%ProgramFiles%" 

    goto SetPath 
)

5:\ Yzöwl provided a Cmd script, of VBS from what I read the most accurate way to get OS bit - Yzöwl posted an alternative Cmd script in post #18 that implements the same logic that David Wang recommends:

Yzöwl, on 03 March 2013 - 05:32 AM, said:

Using that logic then the following should suffice:

ECHO=%PROCESSOR_ARCHITECTURE%' %PROCESSOR_ARCHITEW6432%'|FIND "64'">NUL 2>&1&&ECHO=[64bit]||ECHO=[x86]

Ricktendo, vmanda, mr_smartepants, OnePiece, 5eraph, gora, dumpydooby, ELiTE, and others were all involved in the discussion referenced above. You, and the OP, are welcome to use whatever code works best for you. I just don't know why you keep saying that I am wrong. I did not create the code.

Cheers and Regards

[Geej]

Why are we checking the value of %PROCESSOR_ARCHITEW6432% in a batch file?
Does it affect the OS bitness result?

My common sense tells me since %PROCESSOR_ARCHITEW6432%'s value is dynamic, it makes no diffenece checking this value that will affect the result of OS bitness.

But OS bitness is static. Will this dynmanic value affect a static value?
Shouldn't we be checking something that has a static value and consistent throughout the lifetime while the OS is up & running?

Just another thought...

This post has been edited by Geej: 05 March 2013 - 06:35 AM

[bphlpt]

::sigh:

Geej, The reason that is given in the links I referenced is because %PROCESSOR_ARCHITECTURE%, which you would think is static, gives the "wrong" value IF you are running a 32-bit process in your 64-bit OS. In that particular case, %PROCESSOR_ARCHITECTURE% will indicate x86. According to the references, the quickest, easiest, most reliable way to verify your OS bitness at any time no matter what kind of process you are running, is to look at the two values, %PROCESSOR_ARCHITECTURE% and %PROCESSOR_ARCHITEW6432%, together. As Yzöwl and I have both shown, this is quite easy to do via batch Cmd script. As has been pointed out in other posts in this thread, there are other methods through VBS, wmic, etc to also check other values for OS bitness. I am not saying they are wrong, or slower, or more inaccurate. I am only reporting what I have read and I have seen verified.

Cheers and Regards

[gunsmokingman]

This was a quote from one of your another discussion link.

Quote

Ah, but %PROCESSOR_ARCHITECTURE% only detects the arch of the CPU. What if you have a 32-bit OS on a 64-bit CPU?

 Return_x86.png (48.28K)
Number of downloads: 10

I tested the script from my Win 7 desktop from a CD based 32 bit OS and as you can see it return the x86 or 32 bit,
I have this CPU Type and it a 64 bit CPU.

Let get this straight, this is the caption from David Wang HOWTO: Detect Process Bitness and not
HOW TO Detect OS Bitness.

[bphlpt]

gunsmokingman, on 05 March 2013 - 01:38 PM, said:

Let get this straight, this is the caption from David Wang HOWTO: Detect Process Bitness

Yes, that is the title of the blog. Thank you for looking at it.

As you just proved, even though your actual physical hardware processor chip in your system is a 64-bit processor, (From what you posted it is, correct?) , if you run a 32-bit OS, or process, on it, at the time that 32-bit process is running, the System variable %PROCESSOR_ARCHITECTURE% will indicate it is (at least acting as) a 32-bit processor as far as the software is concerned. The code you posted indicates that you commented out all reference to %PROCESSOR_ARCHITEW6432% so that it is not involved in this test at all, correct? The value of %PROCESSOR_ARCHITECTURE% alone is what triggered your message box, correct? Which is why %PROCESSOR_ARCHITECTURE% alone is not a sufficient test for OS bitness. It also requires testing the value, or at least the existence, of %PROCESSOR_ARCHITEW6432%. The variable %PROCESSOR_ARCHITECTURE% by itself really is only an indicator of process bitness and not OS bitness. (In a 32-bit OS, they are one and the same, of course.) And as you have seen, it has nothing at all to do with the CPU's hardware bitness.

Regardless of the title of the blog, the heading above the code is:

Quote

The logic that I use from a program to detect whether the OS is 32bit or 64bit looks like this:

IF PROCESSOR_ARCHITECTURE == amd64 OR
PROCESSOR_ARCHITEW6432 == amd64 THEN
// OS is 64bit
ELSE
// OS is 32bit
END IF

Another way to test for the same thing is:

IF PROCESSOR_ARCHITECTURE == x86 AND
PROCESSOR_ARCHITEW6432 NOT DEFINED THEN
// OS is 32bit
ELSE
// OS is 64bit
END IF

Cheers and Regards

This post has been edited by bphlpt: 05 March 2013 - 03:16 PM

[Geej]

Since David Wang post caption is "HOWTO: Detect Process Bitness"
and bphlpt also quoted from his post it is "The logic that I use from a program to detect whether the OS is 32bit or 64bit looks like this:"
So here we have a conflict of information from his post.

However, MSDN post is that PROCESSOR_ARCHITEW6432 is an environment variable use in 'WOW64 Implementation Details (Windows)'
Here is another quote ss64.com where he quoted David Wang post too. (But look at the title: it is 32 bit or 64 bit process detection)

Hence the batch file is really a process bitness check, not OS bitness.

Just to lighten this discussion, MS also provide an article how to determine whether a computer is running a 32-bit version or 64-bit version of the Windows operating system.
The best part of it is in the 'Next Steps'. (Call support if unsure, LOL)

Regards

[gunsmokingman]

Truthfully I was expecting the AMD64 to be returned.

I added a couple more line to get CPU ID and X6432, I was expecting that my CPU ID would be the same'.
 Return_x86_1.png (51.42K)
Number of downloads: 12  x64Return.png (92.48K)
Number of downloads: 8

I also tested on my x64 adding Wscript.Path, my Scripting App is 32 bit
 x86AppScrpitPath.png (100.55K)
Number of downloads: 7


X6432 this variable the only constant thing about it is value of Nothing, so it totally useless in a VBS environment.
Here is a full list of Technet Environment Variables


Here is my theory on a 32 bit OS the CPU is in x86 mode any will not run any 64 bit apps, on 64 bit OS you are running
in x64 bit mode period. Individual process can exists in either 32 or 64 bit architecture on 64 bit OS.

I would like to see someone install a x86 Os on to a x64 CPU and keep it at 64 bit and have more than 4 Gb of ram. This
does not include using any type of virtual machine

[bphlpt]

gunsmokingman, on 05 March 2013 - 06:56 PM, said:

Here is my theory on a 32 bit OS the CPU is in x86 mode any will not run any 64 bit apps, on 64 bit OS you are running
in x64 bit mode period. Individual process can exists in either 32 or 64 bit architecture on 64 bit OS.

EXACTLY!!!

Cheers and Regards

[bphlpt]

Geej, on 05 March 2013 - 06:43 PM, said:

...
So here we have a conflict of information from his post.
...
Hence the batch file is really a process bitness check, not OS bitness.
...
Just to lighten this discussion, MS also provide an article how to determine whether a computer is running a 32-bit version or 64-bit version of the Windows operating system.
The best part of it is in the 'Next Steps'. (Call support if unsure, LOL)

I appreciate you trying to lighten the mood. But I don't think there is a conflict of information in David Wang's blog. I'll stand by what was as posted as the "heading" of the code snippet itself. The result of the code snippet indicates the OS bitness. The value of %PROCESSOR_ARCHITECTURE% by itself is an indicator of process bitness..

Cheers and Regards

This post has been edited by bphlpt: 05 March 2013 - 08:45 PM

[gunsmokingman]

1:\ PROCESSOR_ARCHITECTURE is more than enough to determine if the OS is x86 or x64
2:\ W6432 does not work in VBS, any code posted in Cmd I tried always got more? on every line
3:\ PROCESSOR_ARCHITECTURE is not enough to determine if a individual process is x86 or x64
4:\ There Win32_Processor that has a way to determine OS Bitness, AddressWidth

[bphlpt]

Since you insist on proof:

Spoiler

I made a very simple html file with the following (Don't laugh, I'm not much of a script or HTML coder):

<!DOCTYPE html>
<html>
<head>
<script language="javascript">
function myFunction()
{
var wshell = new ActiveXObject("WScript.Shell");
proc_arch = wshell.ExpandEnvironmentStrings("%PROCESSOR_ARCHITECTURE%");
proc_arch6432 = wshell.ExpandEnvironmentStrings("%PROCESSOR_ARCHITEW6432%");
alert("PROCESSOR_ARCHITECTURE=["+proc_arch+"]\nPROCESSOR_ARCHITEW6432=["+proc_arch6432+"]");
}
</script>
</head>
<body>

<input type="button" onclick="myFunction()" value="Show bitness">

</body>
</html>

Here is the relevant info from System Information:

OS Name                            Microsoft Windows 7 Ultimate
Version                            6.1.7601 Service Pack 1 Build 7601
System Type                        x64-based PC
Processor                          AMD TX(tm)-6100 Six-Core Processor, 3300 MHz, 3 Core(s), 6 Logical Processor(s)
Installes Physical Memory (RAM)    16.0 GB

In the image above:

* On the top is shown the code (test.html)
* On the bottom left is an instance of 32-bit IE9 v9.0.8112.16421 - Update Versions: 9.0.13 (KB2792100)
* On the bottom right is an instance of 64-bit IE9 v9.0.8112.16421 64-bit Edition - Update Versions: 9.0.13 (KB2792100)

I opened the exact same test.html code in a window of each browser. As you can see:

In the 32-bit browser:

%PROCESSOR_ARCHITECTURE% = x86
%PROCESSOR_ARCHITEW6432% = AMD64


In the 64-bit browser:

%PROCESSOR_ARCHITECTURE% = AMD64
%PROCESSOR_ARCHITEW6432% = %PROCESSOR_ARCHITEW6432% [meaning it's value is undefined]


So, to address your previous conclusions,

1:\ PROCESSOR_ARCHITECTURE is more than enough to determine if the OS is x86 or x64 -- FALSE
2:\ W6432 does not work in VBS, any code posted in Cmd I tried always got more? on every line -- It works fine in Javascript, surely there is a way in VBS, unless maybe VBS always runs in 64-bit mode if possible?
3:\ PROCESSOR_ARCHITECTURE is not enough to determine if a individual process is x86 or x64 -- FALSE, or it sure seems like that to me
4:\ There Win32_Processor that has a way to determine OS Bitness, AddressWidth -- From what you've shown me I can't argue with that.

I never said there weren't other ways to determine OS bitness. But you kept saying "my" way was wrong, wouldn't work, and wasn't necessary. I hope I've proven my point. If not, I really don't know what else you want as proof.

Cheers and Regards

[Geej]

bphlpt is right in David Wang's case. I realise I got it wrong.

Base on bphlpt's post #10 detection logic and also Yzöwl's post #18 batch logic,
and using GSM post #11 code but slighly modify, I think the vbscript should look like this:

Dim Act :Set Act = CreateObject("Wscript.Shell") 
Dim SysVar : Set SysVar = Act.Environment("System") 
If SysVar("PROCESSOR_ARCHITECTURE") = "AMD64" OR SysVar("PROCESSOR_ARCHITEW6432") = "AMD64" Then 
   WScript.Echo "x64 OS bit" 
else
   WScript.Echo "x32 OS bit" 
End if

[gunsmokingman]

1:\ Wow trying to put words into my mouth. Please show me anywhere in this thread where I used the code you
posted, and said the results are always correct.

2;\

Dim Act :Set Act = CreateObject("Wscript.Shell")
Dim SysVar : Set SysVar = Act.Environment("System")

Now lets get this correct when I mention PROCESSOR_ARCHITECTURE it in the above context. Show me anywhere in this
thread where I posted second rated code that you produced for your test and got the correct results, they are correct you just
do not understand the context. Do you know what environment ExpandEnvironmentStrings access?
ExpandEnvironmentStrings Method

You shown you don't read my links here a bit about what is access.

Quote

The ExpandEnvironmentStrings method expands environment variables defined in the PROCESS environment space only.

3:\ Perhaps if you had taken the time to read my link to the Environment Variables .You could of scripted something like below
and show that if you used Process will return your results in the HTA that you produced.

Dim Act :Set Act = CreateObject("Wscript.Shell")
Dim SysVar : Set SysVar = Act.Environment("System")
'Dim SysVar : Set SysVar = Act.Environment("Process")
  If Right(SysVar("PROCESSOR_ARCHITECTURE"),2) = "64" Then
    WScript.Echo "64 Bit Os   " & vbTab & SysVar("PROCESSOR_ARCHITECTURE") & _
        vbCrLf & "CPU ID      " & vbTab & SysVar("PROCESSOR_IDENTIFIER") & _
        vbCrLf & "W6432       " & vbTab & SysVar("PROCESSOR_ARCHITEW6432") & _
        vbCrLf & WScript.Path
  Else
    WScript.Echo "32 Bit Os   " & vbTab & SysVar("PROCESSOR_ARCHITECTURE") & _
        vbCrLf & "CPU ID      " & vbTab & SysVar("PROCESSOR_IDENTIFIER") & _
        vbCrLf & "W6432       " & vbTab & SysVar("PROCESSOR_ARCHITEW6432")& vbCrLf & WScript.Path
  End If

Instead you go way out of context post something that I have not reference and using innuendo that I was at fault and wrong.
Again show me where I used ExpandEnvironmentStrings in this thread and say it results are correct.

Using the above code I tested on x86 and x64 OS and it always return the correct results, see if you can produce your results
using my script and using System. I tried on 2 different OS and got always the correct results.

Just for fun I made some minor changes check the results.

Dim Act :Set Act = CreateObject("Wscript.Shell")
Dim SysVar : Set SysVar = Act.Environment("System")
'Dim SysVar : Set SysVar = Act.Environment("Process")
Dim A
  If Right(SysVar("PROCESSOR_ARCHITECTURE"),2) = "64" Then
    A = "64 Bit Os   " & vbTab & SysVar("PROCESSOR_ARCHITECTURE") & _
        vbCrLf & "CPU ID      " & vbTab & SysVar("PROCESSOR_IDENTIFIER") & _
        vbCrLf & "W6432       " & vbTab & SysVar("PROCESSOR_ARCHITEW6432") & _
        vbCrLf & WScript.Path
  Else
    A = "32 Bit Os   " & vbTab & SysVar("PROCESSOR_ARCHITECTURE") & _
        vbCrLf & "CPU ID      " & vbTab & SysVar("PROCESSOR_IDENTIFIER") & _
        vbCrLf & "W6432       " & vbTab & SysVar("PROCESSOR_ARCHITEW6432")& vbCrLf & WScript.Path
  End If 
  WScript.Echo A & vbcrlf & _
  "Test W6432 : " & Act.ExpandEnvironmentStrings("%PROCESSOR_ARCHITEW6432%")  

Results x86 app x64 OS
 MyProof.png (80.89K)
Number of downloads: 3


You can see I am getting the correct results using my scripting app output, you W6432 = AMD64
and Wscript Script Host W6432 = %PROCESSOR_ARCHITEW6432% and each show 64 Bit Os AMD64.

var Act = new ActiveXObject("WScript.Shell");
var Env = Act.Environment("System")
var a, b ="Test W6432\t" + Act.ExpandEnvironmentStrings("%PROCESSOR_ARCHITEW6432%")
var A = new Array(Env("PROCESSOR_ARCHITECTURE"),"CPU ID     \t"+
 Env("PROCESSOR_IDENTIFIER"),"W6432      \t"+Env("PROCESSOR_ARCHITEW6432"),
 "App Path   \t"+WScript.Path)
function MyTest(a){if(Right(A[0],2) == "64")
 {a ="64 Bit Os   \t"+A[0]+"\n\r"+A[1]+"\n\r"+A[2]+"\n\r"+ A[3]+"\n\r"}
 else
 {a ="32 Bit Os   \t"+A[0]+"\n\r"+A[1]+"\n\r"+A[2]+"\n\r"+ A[3]+"\n\r"}
 return a + b}
function Right(str, N){return str.substring(str.length, str.length - N);}
WScript.Echo(MyTest(a))

Same script in Jscript returns the same results
 JsProof.png (106.9K)
Number of downloads: 5

Now in these two scripts it really proves one thing and that is how wrong you are.

Geej, on 06 March 2013 - 09:28 PM, said:

bphlpt is right in David Wang's case. I realise I got it wrong.

Base on bphlpt's post #10 detection logic and also Yzöwl's post #18 batch logic,
and using GSM post #11 code but slighly modify, I think the vbscript should look like this:

Dim Act :Set Act = CreateObject("Wscript.Shell") 
Dim SysVar : Set SysVar = Act.Environment("System") 
If SysVar("PROCESSOR_ARCHITECTURE") = "AMD64" OR SysVar("PROCESSOR_ARCHITEW6432") = "AMD64" Then 
   WScript.Echo "x64 OS bit" 
else
   WScript.Echo "x32 OS bit" 
End if

Not really the SysVar("PROCESSOR_ARCHITEW6432") return nothing in either script

[bphlpt]

I think I realize now that GSM and I have been talking about slightly different things. He is the scripting master after all, as my poor attempts show with my "second rated code", while I come more from a CMD batch scripting background. It seems that he is able to take advantage of abilities via VBScript or Jscript that I did not realize you could do. I did not realize that you could get the value of an Environment Variable at the SYSTEM level, no matter what process you currently were in, if I understand things correctly. This is a completely foreign concept of course to a CMD batch script programmer who only has access to one %PROCESSOR_ARCHITECTURE% variable, for example, the one for the process that he is in. Even after reading his referenced links I still had to reread them a couple of times, stare at his code for a while, and work it through. I'm still learning and I guess that was the new thing I was meant to learn today.

So while I stand by the detection logic I posted in post #10, or Yzöwl's post #18, or Geej's post #37 as the safest logic to use for any script language, (CMD batch, VBScript, or JScript), that is able to run from any process on any Windows OS, (at least XP+), and accurately determine the OS bitness, I also agree that if you are indeed able to to read the Environment Variables at the SYSTEM level, then %PROCESSOR_ARCHITECTURE% alone seems to be just as accurate to determine OS bitness. In this regard GSM was right and I was wrong. I humbly ask his forgiveness for doubting him and I hope we are still friends with no hard feelings.

Cheers and Regards

[gunsmokingman]

bphlpt any Cmd prompt code must of been correct or Yzöwl would of said something

Your hta was correct, retrieving the correct information, it just in VBS JS Environments there more information to
access than Cmd, that where the confusion sets in. As you see there are a couple of Environments, and I have not
tested them all and only these two Process and System and they return different results depending on what
Environments it was being processed by. See you, learned something new from all this.