Detect if os is x86 or x64 using command line?

[vmanda]

Somebody knows the best solution to detect if OS is x86 or x64 using command line?

Wmic return nothing for me, for example.

Something like that should work 100%?

IF NOT EXIST "%windir%\SysWoW64\CMD.EXE" GOTO RUN_X86

:RUN_X64
SPTDinst-v181-x64.exe add /q
GOTO TERMINATE

:RUN_X86
SPTDinst-v181-x86.exe add /q
GOTO TERMINATE

:TERMINATE
EXIT

to create one dual architecturel SPTD, for example?
Edit: Seems that If Command Extensions are disabled GOTO will no longer recognise the :EOF label

[ricktendo64]

Code: Select all

GOTO %PROCESSOR_ARCHITECTURE%

:AMD64
SPTDinst-v181-x64.exe add /q
GOTO END

:X86
SPTDinst-v181-x86.exe add /q
GOTO END

:END
EXIT

[vmanda]

Code: Select all

GOTO %PROCESSOR_ARCHITECTURE%

:AMD64
SPTDinst-v181-x64.exe add /q
GOTO END

:X86
SPTDinst-v181-x86.exe add /q
GOTO END

:END
EXIT

Many thanks, Rick

[mr_smartepants]

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 use:

Code: Select all

:PROCESSOR
:: Detects host OS type on running system.  Assumes 32-bit unless 64-bit components are present.
SET "ARCHP=x86"
IF EXIST "%SystemRoot%\SysWOW64" SET "ARCHP=x64"

The syswow64 folder does NOT exist on any 32-bit OS, so it makes a great indicator.

[OnePiece Alb]

IF /I %PROCESSOR_ARCHITECTURE% == x86 (
CALL :X32
) Else (
CALL :X64
)

http://blogs.msdn.com/b/david.wang/arch ... tness.aspx

Microsoft Example in ..\Windows Kits\8.0\Assessment and Deployment Kit\Deployment Tools\DandISetEnv.cmd

Code: Select all

@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
)

[bphlpt]

I agree with mr_smartepants. With today's Intel and AMD processors almost always being x64 capable, but yet some people still preferring to run x32 based OS, detecting the processor architecture is not enough. You have to check for the OS architecture, and the easiest way to do that using the command line is to check for the presence of "%SystemRoot%\SysWOW64". Unless someone manually created/copied that folder to their x32 OS, it will only be there if the version of Windows is x64. And using mr_smartepants suggested code you don't have to worry about using the GOTO.

Cheers and Regards

[ricktendo64]

I am not convinced PROCESSOR_ARCHITECTURE is meant to be taken literally, I think its the actual OS architecture not the processor

If someone would install x86 windows on a x64 capable pc and run cmd with set command to verify

[vmanda]

I agree with mr_smartepants. With today's Intel and AMD processors almost always being x64 capable, but yet some people still preferring to run x32 based OS, detecting the processor architecture is not enough. You have to check for the OS architecture, and the easiest way to do that using the command line is to check for the presence of "%SystemRoot%\SysWOW64". Unless someone manually created/copied that folder to their x32 OS, it will only be there if the version of Windows is x64. And using mr_smartepants suggested code you don't have to worry about using the GOTO.

Cheers and Regards

Even if someone manually created the SysWOW64 folder, checking for the presence of cmd.exe
into this folder, add one more checkpoint to the script, minimizing the chance of mistakes.

Best regards and many thanks to all for suggestions. vmanda

[5eraph]

Microsoft's example in OnePiece's post appears to be one way to go.

PROCESSOR_ARCHITECTURE changes in XPx64 depending on whether the running instance of CMD.exe is 32-bit or 64-bit. A new environment variable, PROCESSOR_ARCHITEW6432, exists in XPx64 when running the 32-bit instance of CMD.exe.

Code: Select all

>SET PROCESSOR_ARCHITE
PROCESSOR_ARCHITECTURE=x86
PROCESSOR_ARCHITEW6432=AMD64

IF EXIST "%SystemRoot%\SysWOW64" also works to determine OS bitness.

[bphlpt]

@5eraph, what you are describing about the difference in behavior for PROCESSOR_ARCHITECTURE in XPx64 sounds kind of like what is described regarding the IsWow64Process function -

A pointer to a value that is set to TRUE if the process is running under WOW64. If the process is running under 32-bit Windows, the value is set to FALSE. If the process is a 64-bit application running under 64-bit Windows, the value is also set to FALSE.

Which is a way of saying that just because the processor is capable of running the x64 OS, or that you have the x64 OS installed, doesn't mean that you are running a x64 process at that particular instant in time. But they also say:

For compatibility with operating systems that do not support this function, call GetProcAddress to detect whether IsWow64Process is implemented in Kernel32.dll. ... Note that this technique is not a reliable way to detect whether the operating system is a 64-bit version of Windows because the Kernel32.dll in current versions of 32-bit Windows also contains this function.

So that is not important for what vmanda was wanting to test for - the OS bitness. I don't think that vmanda's way of testing for the existence of "%SystemRoot%\SysWOW64\cmd.exe" will do any harm, but I've only seen others test for "%SystemRoot%\SysWOW64", and that's what I use, as apparently do you and mr_smartepants as well. I mean if someone was going to manually create the SysWOW64 folder, they could just as easily create the cmd.exe file inside it, even if it was a zero byte file, so I don't think that provides much extra protection, really.

Cheers and Regards

[vmanda]

I mean if someone was going to manually create the SysWOW64 folder, they could just as easily create the cmd.exe file inside it, even if it was a zero byte file, so I don't think that provides much extra protection, really.

Is not about someone, is about some "not verry well written" setup package.
The Internet is full of this kind of stupid setup packages, that come sometimes,
to acomplish many verry well written programs. Sometimes, software developers
are verry good in his programming language, C++ for example, but are less experienced
into solving packaging and distributing software, inno setup, for example.

There are real chances to find some x32/x64 setup package that want to drop some dll
or exe into SysWOW64 folder, and to create it, even if you are running into one x86 OS.
But the chance that someone/some setup pack to try to overwrite the existing
cmd.exe, is less efective. Maybe just some kind of malware, can try to replace cmd.exe
that allready come with OS.

Maybe one combined method, checking PROCESSOR_ARCHITECTURE and plus,
checking for %windir%\SysWOW64\cmd.exe will approach to the desired 100%.

[5eraph]

A reliable result for OS bitness can be obtained by checking PROCESSOR_ARCHITECTURE and PROCESSOR_ARCHITEW6432 without checking folders or files, provided that nobody changed either value in the registry at "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment".

Code: Select all

IF /I "%PROCESSOR_ARCHITECTURE%"=="x86" (
  IF DEFINED PROCESSOR_ARCHITEW6432 (CALL :x64) ELSE (CALL :x32)
) ELSE (CALL :x64)

Checking for the presence of a file or folder relies upon nobody creating the file or folder to be checked. But it does simplify the code.

Code: Select all

IF EXIST "%SystemRoot%\SysWOW64\cmd.exe" (CALL :x64) ELSE (CALL :x32)

[mr_smartepants]

Maybe one combined method, checking PROCESSOR_ARCHITECTURE and plus, checking for %windir%\SysWOW64\cmd.exe will approach to the desired 100%.

Yes, there is no one check that would conclusively identify the OS "bit-ness". Checking for the presence of the syswow64 folder makes the identification about 90% accurate. To approach 100% accuracy would require a combination of checks & cross-checks as 5eraph points out.
It's all a balance of convenience with the code against the required accuracy.

Oh, and %PROCESSOR_ARCHITEW6432% doesn't always work.
This is on Win7 x64 on my Q6600 system.

Code: Select all

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:\Windows\system32>echo %PROCESSOR_ARCHITECTURE%
AMD64

C:\Windows\system32>echo %PROCESSOR_ARCHITEW6432%
%PROCESSOR_ARCHITEW6432%

C:\Windows\system32>

The variable isn't defined, even on a known 64-bit system.

[bphlpt]

@mr_smartepants, that's because that variable only exists when:

A new environment variable, PROCESSOR_ARCHITEW6432, exists in XPx64 when running the 32-bit instance of CMD.exe.

So that variable does NOT exist if running a 32 bit process on a 32 bit OS or when running a 64 bit process on a 64 bit OS, but ONLY while running a known 32 bit process on a known 64 bit OS. Just like the IsWow64Process function I described above. It's confusing.

Cheers and Regards

[Chilltownnj]

I've pretty much been using this since beta Win7

IF DEFINED ProgramFiles(x86) (SET bit=x64) ELSE (SET bit=x86)
Goto %bit%


I'm sure i could use another defined variable but for some reason I stuck with this one.

It's one thing if someone or a program could create a c:\programfiles (x86)\ folder, it's another thing to have that variable actually be set in windows by someone or a program.

Guess i'll use IF DEFINED Syswow64 from now on since it's a tad bit shorter and works well with what i've just tested also.

[gora]

Code: Select all

Set xOS=x86& If Defined PROCESSOR_ARCHITEW6432 (Set xOS=x64) Else If "%PROCESSOR_ARCHITECTURE%"=="AMD64" Set xOS=x64
Echo %xOS%

[5eraph]

That's simpler than my code above, but it could be even simpler by changing the starting condition. We should need no more than two SET commands.

Code: Select all

SET "xOS=x64"& IF /I "%PROCESSOR_ARCHITECTURE%"=="x86" (IF NOT DEFINED PROCESSOR_ARCHITEW6432 SET "xOS=x86")
ECHO %xOS%

If we're only running architecture specific EXEs then the following code should work most efficiently.

Code: Select all

IF /I "%PROCESSOR_ARCHITECTURE%"=="x86" (
  IF NOT DEFINED PROCESSOR_ARCHITEW6432 GOTO :x86
)

(x64 EXE 1)
(x64 EXE 2)
(x64 EXE 3)
GOTO :eof

:x86
(x86 EXE 1)
(x86 EXE 2)
(x86 EXE 3)

[gora]

Yes. Your code is shorter than 8 bytes!

[mr_smartepants]

Sorry to dig up this old topic but I think you guys are confusing CPU bit-ness with OS bit-ness. We still have unaccounted-for CPU/OS scenarios.

Code: Select all

SET "xOS=x64"& IF /I "%PROCESSOR_ARCHITECTURE%"=="x86" (IF NOT DEFINED PROCESSOR_ARCHITEW6432 SET "xOS=x86")
ECHO %xOS%

Example: WinXP (32-bit) run on AMD64 CPU... The above code would return "x64" because it's only checking the CPU, not the OS status.
There are situations in Win7 install where the eventual install will be x64 but the environment variables are in a 32-bit state so %processor_architecture% will return x86 on AMD64 hardware (example bug over at DriverPacks.net: http://forum.driverpacks.net/viewtopic. ... 416#p48416)

Here's my suggestion (still in work):

Code: Select all

:PROCESSOR
:: Detect OS bit-ness on running system.  Assumes 32-bit unless 64-bit components exist.
SET "ARCH=32"
IF EXIST "%SystemRoot%\SysWOW64" (SET "ARCH=64") ELSE (
  IF DEFINED PROCESSOR_ARCHITEW6432 (SET "ARCH=64")
)

[dumpydooby]

If you're going to rely on file system, I think you should do multiple checks. If you want to make your code there just slightly better, check for "%SystemRoot%\SysWOW64\cmd.exe" because poorly coded installers might create SysWOW64 and/or dump stuff in it without checking architecture as vmanda pointed out above. Checking for cmd.exe would help us in such a scenarios.

[bphlpt]

@mr_smartepants, I think your processor bit-ness test could be slightly simplified with:

Code: Select all

:PROCESSOR
:: Detect OS bit-ness on running system.  Assumes 32-bit if 64-bit components do not exist.

SET "ARCH=64"
IF NOT EXIST "%SystemRoot%\SysWOW64\cmd.exe" (
    IF NOT DEFINED PROCESSOR_ARCHITEW6432 SET "ARCH=32"
)

I also incorporated checking for the existence of "SysWOW64\cmd.exe" instead of just "SysWOW64" as suggested by both vmanda and dumpydooby.

Note the similarity to 5eraph's latest solution posted above, reworked slightly here for ease of comparison:

Code: Select all

SET "xOS=x64"
IF /I "%PROCESSOR_ARCHITECTURE%"=="x86" (
    IF NOT DEFINED PROCESSOR_ARCHITEW6432 SET "xOS=x86"
)

But I believe you are correct that your code catches situations that the other code does not.

Cheers and Regards

[mr_smartepants]

Yup, that is very true. I love this collaboration! You're all awesome.

[Strych9]

I would like to throw a wrench into the discussion...

It seems that we have all forgotten 1 possibility (perhaps more).

We need to not only check the Architecture and or OS bit-ness, we also need to check the "bit-ness" of the current CMD session.

It is possible to run a 32 bit CMD session on a 64 bit OS. This could, for example, cause problems with querying the 64 bit registry from a 32 bit session.

Consider the following:

set CMD=32
set BITS=32
if exist %windir%\syswow64\cmd.exe set BITS=64
:: it is possible to have a 32 bit CMD session on a 64 bit OS
if "%ProgramW6432%"=="%ProgramFiles%" set CMD=64
echo This is a %CMD% bit CMD session on a %BITS% bit OS.

Just my 2 cents...

[bphlpt]

@Strych9,

The last solution posted above should catch your situation, because:

A new environment variable, PROCESSOR_ARCHITEW6432, exists in XPx64 when running the 32-bit instance of CMD.exe.

So that variable does NOT exist if running a 32 bit process on a 32 bit OS or when running a 64 bit process on a 64 bit OS, but ONLY while running a known 32 bit process on a known 64 bit OS.

Cheers and Regards

[ELiTE]

My solution:

Yes, you can run 32 bit commands on a 64 bit system.

32 bit commands are used for 32 bit apps to install on a 64 bit system.

The only thing we need to tell Windows is which command (32 or 64 bit) to run eg:

Code: Select all

@ECHO OFF

IF EXIST "%SystemRoot%\SysWOW64" elite64.exe

IF NOT EXIST "%SystemRoot%\SysWOW64" elite32.exe 

EXIT

or

@ECHO OFF 

IF EXIST "%SystemRoot%\SysWOW64" 64bitapp.exe /switch 

IF NOT EXIST "%SystemRoot%\SysWOW64" 32bitapp.exe /switch

EXIT 

The above script was compiled by me using info from this thread. It runs flawlessly. Windows will make it's command decisions based on the OS Architecture installed.

The processor architecture is irrelevant because a 64 bit OS will not install on a 32 bit processor based system and a 64 bit app will not install on a 32 bit OS.

No other code modifications are necessary to install applications on x86/x64 bit Windows.

This is what works for me.......

[bphlpt]

Sorry ELiTE, but you are wrong. You missed part of the point. Like you, mr_smartepants and I both also used to believe that just checking for the existence of SysWOW64 was enough, and for your situation, deciding whether to install a 32bit or a 64bit version of an app, it most likely is. But there are other situations where that is simply not enough of a test. It is NOT "The ONLY thing we need".

There are situations in Win7 install where the eventual install will be x64 but the environment variables, and the file system at that point, are in a 32-bit state so %PROCESSOR_ARCHITECTURE% will return x86 on AMD64 hardware and SysWOW64 might not exist yet, though most of the time checking for SysWOW64 will work here. There are other situations that just because you have a 64bit processor and a 64bit OS installed, you do NOT want to run or install the 64bit version of an app or driver, you want to run or install the 32bit version, but ONLY when you are already running another 32bit process such as a 32bit CMD session.

You are ONLY able to tell that you are in one of these situations by ALSO checking whether %PROCESSOR_ARCHITEW6432% has been defined, but that check is ONLY valid if you have already determined that the environment variables or file system indicate a 32bit environment. For that situation, if %PROCESSOR_ARCHITEW6432% has been defined, even though %PROCESSOR_ARCHITECTURE%=x86 or SysWOW64 does NOT exist which both normally indicates a 32bit arch, it is actually a 64bit arch. It is only a 32bit arch if %PROCESSOR_ARCHITEW6432% has NOT been defined. I'm sorry if my attempt at explanation doesn't help clear things up, but it can be very complicated. It is also a more robust test to check for the existence of SysWOW64\cmd.exe and not just SysWOW64, as both vmanda and Dumpy Dooby pointed out.

Anyway, please do not over simplify the situation by claiming that checking for the existence of SysWOW64 is "The definitive solution". That is NOT correct. While that test will work most of the time, we don't want to mislead people to think that is all you need for all situations. It is NOT.

Cheers and Regards

[ELiTE]

Anyway, please do not over simplify the situation by claiming that checking for the existence of SysWOW64 is "The definitive solution". That is NOT correct. While that test will work most of the time, we don't want to mislead people to think that is all you need for all situations. It is NOT.

Cheers and Regards

My post edited accordingly. Thanks for your insight. You guys know far more about this than me.....

My Opinion:
As in all areas of life there is always the exception to the rule. There is also a tendency to over analyze any given situation by those seeking the truth.
Also, anyone reading this thread would already have an advanced understanding of the topic. They would be able to form their own opinions/solutions based on what has been posted here.....

[ELiTE]

@bphlpt

After having studied your hypothesis above and doing a little research I have come to the following conclusion;

In 64 bit windows SysWOW64 exists from the point of OS installation on. There is no need to "check" if you're in 64 bit mode or not. In 64 bit Windows you are always in 64 bit mode unless you specify a command be run using the 32 bit cmd.exe.

Once again, the processor architecture was defined at the point of OS installation. You cannot install a 64 bit windows on a 32 bit processor based machine. There is never a situation/time on 64 bit Windows where SysWOW64 does not exist from the point of OS installation forward.

*cmd.exe name changed for identification*

cmd32.exe installs 32 bit files only

cmd64.exe installs 64 bit files only

Files without a 32/64 bit designation are installed by either command exe that is currently in use for the required action.

32 or 64 bit drivers that are loaded before OS installation are automatically assigned a new home Directory by the installed OS version.

Once again, my opinion only.....

[bphlpt]

In 64 bit Windows you are always in 64 bit mode unless you specify a command be run using the 32 bit cmd.exe.

Or you run a 32bit app, such as a 32bit browser. That's why you have to have 32 bit versions of all the various runtimes even when you install a 64bit OS. Once you are in 32bit mode you cannot then call a 64bit app or runtime, just as "You cannot install a 64 bit windows on a 32 bit processor based machine." In any case, if for whatever reason you need to find out which arch mode you are in, you have to check, that's the only way you will know. You cannot just rely on which processor, OS, or file system is in place.

As has been repeatedly said, for the common situations such as deciding whether to install a 32bit or 64bit app, checking for the existence of SysWOW64 is usually sufficient. And as you have said, if you use the built-in automatic methods in Win7 x64, this is often handled for you without you having to do anything special at all. But the check for "arch" or "bit-ness" as discussed in this thread can be used in other stuations besides just app or driver installs. And if, for whatever reason, you are trying to do things manually, then those automatic things don't always work, especially if you specifically choose to not use them. The final method that was derived in this thread is simply an alternative version of what was suggested by Microsoft in the link provided by OnePiece and referenced by 5eraph. It is not my hypothesis. It has been proven to work in circumstances in which your simplified script has failed. So even though just checking for SysWOW64 has also always worked for me in the past, if Microsoft, 5eraph, mr_smartepants, OnePiece, gora, Dumpy Dooby, Ricktendo64, vamanda, and others all agree that the test can be made more reliable and robust with one simple extra check, then to be prepared for any possibility that's what I'm going to do. That's also why I choose to install all the apps and runtimes that I install - to be prepared. You are perfectly within your rights to use or ignore the information provided.

Cheers and Regards

[ELiTE]

You are perfectly within your rights to use or ignore the information provided.

This is a discussion forum. It's not personal. Now, getting back to the issue at hand: I would be most interested in seeing a script posted here that covers all the bases you describe and could be functionally used in a batch/command script to execute various windows tasks.....

[bphlpt]

Code: Select all

SET "ARCH=64" 
IF NOT EXIST "%SystemRoot%\SysWOW64\cmd.exe" ( 
    IF NOT DEFINED PROCESSOR_ARCHITEW6432 SET "ARCH=32" 
)
IF "%ARCH%"=="64" THEN (
    (x64 EXE 1) 
    (x64 EXE 2) 
    (x64 EXE 3) 
  ) ELSE (
    (x86 EXE 1) 
    (x86 EXE 2) 
    (x86 EXE 3) 
)

Is one way that would work. If you look above you will see a couple of slight variations on this same theme. 5eraph offers a way with GOTO statements which don't use SET statements etc. You can also utilize the value of %ARCH% as part of the path or file name to determine which commands to execute. All work perfectly well in batch/command script and are purely programmer's preference.

Cheers and Regards

[ELiTE]

@bphlpt

Similar to what I found Here

Code: Select all

 Detection Logic
 
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 

While detection for whether a process is in WOW64 mode is to simply check for the presence of the PROCESSOR_ARCHITEW6432 environment variable.
 
In Closing...
 
Now, WHEN would one have to do this? Oh... how about when you are a 32bit application and need to:
 •Turn off WOW64 FileSystem Redirection to reach into System32 directory to launch a 64bit process
 •Turn off WOW64 Registry Redirection to read the real HKLM\Software or HKCU\Software values 

Thanks for all. I'll see how I can adapt these various methods into a working script for my installers etc......

[ELiTE]

ELiTE in his never ending quest for truth, justice blah, blah ,blah has uncovered another little jewel of info regarding x64 Windows.

%windir%\System32\cmd.exe is the default for all commands run except for those commands/installers that are 64 bit only specific. All other commands/32-64 installers (move, copy, delete, start /wait etc.) are run using the 32 bit command processor.

This should simplify things for those writing scripts.....

[JayAvedo]

Hi Dave, I have not seen this myself but will take a look too.

OK. My cursor is not there or blinking, but if I start typing, no problem - text appears.

Pressing the 'tab' key should get the cursor to appear in the command line.