gunsmokingman Posted March 3, 2013 Posted March 3, 2013 These are your words that you postedPROCESSOR_ARCHITECTURE will be equal to "x86" even though you are running a 64-bit OS on a 64-bit processor.I still say you are wrong the below image show the PROCESSOR_ARCHITECTURE variable is returning AMD64 in VBS and CMD Prompt.. From you posted it should be x86.
Falcor Posted March 3, 2013 Author Posted March 3, 2013 Thanks for all your help, people.I am not too worried about how the code looks until after I have gotten everything working. Once that is taken care of I will clean it up. On to the next problem...
Yzöwl Posted March 3, 2013 Posted March 3, 2013 Detection LogicThe 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 64bitELSE // OS is 32bitEND IFAnother way to test for the same thing is:IF PROCESSOR_ARCHITECTURE == x86 AND PROCESSOR_ARCHITEW6432 NOT DEFINED THEN // OS is 32bitELSE // OS is 64bitEND IFUsing that logic then the following should suffice:ECHO=%PROCESSOR_ARCHITECTURE%' %PROCESSOR_ARCHITEW6432%'|FIND "64'">NUL 2>&1&&ECHO=[64bit]||ECHO=[x86]Alternatively:REG QUERY "HKLM\Hardware\Description\System\CentralProcessor\0" /v Identifier|FIND /I "x86"&&ECHO=[x86]||ECHO=[64bit]
Geej Posted March 3, 2013 Posted March 3, 2013 inf detection logic Just right-click ChkOSbitness.inf and "install"[Version]Signature=$Windows NT$[DefaultInstall]RegisterDLLs=Start.Register[Start.Register]11,,rundll32.exe,,,"advpack.dll,LaunchINFSection %1%\%infname%.inf,Install"[Install.ntx86]RunPostSetupCommands=echo86[Install.ntamd64]RunPostSetupCommands=echo64[echo86]cmd /c echo x86 section is called & pause[echo64]cmd /c echo x64 section is called & pause[Strings]infname=ChkOSbitness
gunsmokingman Posted March 3, 2013 Posted March 3, 2013 Win32_Processor class (Windows)AddressWidthData type: uint16Access type: Read-onlyOn a 32-bit operating system, the value is 32 and on a 64-bit operating system it is 64. This property is inherited from CIM_Processor.So this would be the most effective way of finding out if the OS is x86 or x64Dim Wmi :Set Wmi = GetObject("winmgmts:\\.\root\CIMV2")Dim Obj For Each Obj In Wmi.ExecQuery("SELECT * FROM Win32_Processor") If Obj.AddressWidth = "64" Then MsgBox "64 Os Bit : " & Obj.AddressWidth Else MsgBox "32 Os Bit : " & Obj.AddressWidth End If Next
Yzöwl Posted March 3, 2013 Posted March 3, 2013 And this from the commandline / batchWMIC CPU GET ADDRESSWIDTH /VALUE|FIND "=64">NUL 2>&1&&ECHO=[64bit]||ECHO=[x86]
bphlpt Posted March 3, 2013 Posted March 3, 2013 (edited) GSM, I'm really not trying to argue with you. These are your words that you postedPROCESSOR_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: 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 Edited March 3, 2013 by bphlpt
Geej Posted March 4, 2013 Posted March 4, 2013 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 Posted March 4, 2013 Posted March 4, 2013 I give up. LOL I guess nobody reads or believes MS. Cheers and Regards
gunsmokingman Posted March 4, 2013 Posted March 4, 2013 bphlpt 1:\ Posted code in wrong language, the poster wrote this in VBS2:\ 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 Posted March 5, 2013 Posted March 5, 2013 GSM1:\ 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: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 Posted March 5, 2013 Posted March 5, 2013 (edited) 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... Edited March 5, 2013 by Geej
bphlpt Posted March 5, 2013 Posted March 5, 2013 ::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 Posted March 5, 2013 Posted March 5, 2013 This was a quote from one of your another discussion link.Ah, but %PROCESSOR_ARCHITECTURE% only detects the arch of the CPU. What if you have a 32-bit OS on a 64-bit CPU? 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 Posted March 5, 2013 Posted March 5, 2013 (edited) Let get this straight, this is the caption from David Wang HOWTO: Detect Process BitnessYes, 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:The logic that I use from a program to detect whether the OS is 32bit or 64bit looks like this:IF PROCESSOR_ARCHITECTURE == amd64 ORPROCESSOR_ARCHITEW6432 == amd64 THEN// OS is 64bitELSE// OS is 32bitEND IFAnother way to test for the same thing is:IF PROCESSOR_ARCHITECTURE == x86 ANDPROCESSOR_ARCHITEW6432 NOT DEFINED THEN// OS is 32bitELSE// OS is 64bitEND IFCheers and Regards Edited March 5, 2013 by bphlpt
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now