how can I identify if OS is 32 bit or 64 bit in batch file?

[DungFu]

the question is in the title, I am not sure how to do it. Help would be greatly appreciated!

Edited December 31, 2019 by Tripredacus

[darks0ul]

>echo %processor_architecture%
AMD64

Note that this will not work for a script like RunOnceEx.cmd or similar that are called from cmdlines.txt

I mean, this variable is set when the computer makes the first boot after the installation.

Otherwise, try checking if %WinDir%\SysWOW64 exists...

Or you can use AutoIt (@OSArch constant)

[Jito463]

I know this is an older post, but here's what I've always used:

%ProgramFiles(x86)%
IF ERRORLEVEL = 1 GOTO x64
IF ERRORLEVEL = 0 GOTO x86

If it exists (ERRORLEVEL = 1), then it runs the 64-bit (x64) commands

If it does not exist (ERRORLEVEL = 0), then it runs the stanard 32-bit (x86) commands.

Of course, you could do the same with SysWow64 instead. Just pick any file or folder that would only exist in a 64-bit OS.

[Yzöwl]

I know this is an older post, but here's what I've always used:

%ProgramFiles(x86)%
IF ERRORLEVEL = 1 GOTO x64
IF ERRORLEVEL = 0 GOTO x86

If it exists (ERRORLEVEL = 1), then it runs the 64-bit (x64) commands

If it does not exist (ERRORLEVEL = 0), then it runs the stanard 32-bit (x86) commands.

Of course, you could do the same with SysWow64 instead. Just pick any file or folder that would only exist in a 64-bit OS.

I'd suggest not to use that syntax

IF ERRORLEVEL = n is first of all not correct

Also an errorlevel of 0 means that errorlevel was 0 or greater which in all cases would be true.

This would probably replace your command better

IF EXIST "%PROGRAMFILES(X86)%" (GOTO 64BIT) ELSE (GOTO 32BIT)

[jaclaz]

Just for the record.

Errorlevel in NT based systems is a variable:

http://www.911cd.net/forums//index.php?showtopic=18512

http://www.robvanderwoude.com/errorlevel.php

jaclaz

[Jito463]

I know this is an older post, but here's what I've always used:

%ProgramFiles(x86)%
IF ERRORLEVEL = 1 GOTO x64
IF ERRORLEVEL = 0 GOTO x86

If it exists (ERRORLEVEL = 1), then it runs the 64-bit (x64) commands

If it does not exist (ERRORLEVEL = 0), then it runs the stanard 32-bit (x86) commands.

Of course, you could do the same with SysWow64 instead. Just pick any file or folder that would only exist in a 64-bit OS.

I'd suggest not to use that syntax…

IF ERRORLEVEL = n is first of all not correct

Also an errorlevel of 0 means that errorlevel was 0 or greater which in all cases would be true.

This would probably replace your command better

IF EXIST "%PROGRAMFILES(X86)%" (GOTO 64BIT) ELSE (GOTO 32BIT)

It's always worked for me, which is why I used it, but I will admit your version is much cleaner and will probably switch to that. By the way, in your version, the ( ) around the GOTO commands doesn't need to be there.

[Yzöwl]

%ProgramFiles(x86)%
IF ERRORLEVEL = 1 GOTO x64
IF ERRORLEVEL = 0 GOTO x86

If it exists (ERRORLEVEL = 1), then it runs the 64-bit (x64) commands

If it does not exist (ERRORLEVEL = 0), then it runs the stanard 32-bit (x86) commands.

<snip />

<snip />

It's always worked for me, which is why I used it.

It is wrong, the first line would produce an error every time

'expanded or otherwise variable' is not recognized as an internal or external command, operable program or batch file.

For the next line you could have used among others:

IF ERRORLEVEL 1 GOTO x64

IF %ERRORLEVEL%==1 GOTO x64

IF %ERRORLEVEL% EQU 1 GOTO x64

IF %ERRORLEVEL% GEQ 1 GOTO x64

IF NOT ERRORLEVEL 0 GOTO x64

By the way, in your version, the ( ) around the GOTO commands doesn't need to be there.

Are you sure?

Run this code in your console window

IF EXIST "%PROGRAMFILES(X32)%" (ECHO/32BIT) ELSE (ECHO/64BIT)

Result is:

64BIT

Now run this in your console window

IF EXIST "%PROGRAMFILES(X32)%" ECHO/32BIT ELSE ECHO/64BIT

What is the result?

[Sonic]

... don't try to fight with Yzöwl , he'll always win at "batch" ...

[fastlane65]

I've found recently that IF EXIST %ProgramFiles(x86)% and IF EXIST "%PROGRAMFILES(X32)%" only prove the existence of c:\program files (x86), which can exist on a 32 bit machine.  I have software that creates its home directory in (x86), and if the directory doesn't exist it creates it.  This gives a false positive to the IF EXIST above.  I have started using IF EXIST "C:\Windows\SysWOW64" with the hope that some random program won't create this directory on a 32 bit machine.

[bphlpt]

I've found recently that IF EXIST %ProgramFiles(x86)% and IF EXIST "%PROGRAMFILES(X32)%" only prove the existence of c:\program files (x86), which can exist on a 32 bit machine.  I have software that creates its home directory in (x86), and if the directory doesn't exist it creates it.  This gives a false positive to the IF EXIST above.  I have started using IF EXIST "C:\Windows\SysWOW64" with the hope that some random program won't create this directory on a 32 bit machine.

Relying on only the existence of any particular folder to determine the bitness of the OS has its limitations due to the possibility of running into some "not very well written" setup package, as you have found, even though it does simplify the code. Switching to "C:\Windows\SysWOW64" doesn't really help either, (even though I used to believe that, too), since there are real chances to find some x32/x64 setup package that want to drop some dll or exe into the SysWOW64 folder, and will create it if necessary, no matter what OS you are running.

That is why MS suggests not relying on any file location at all but rather the values of system variables. 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".

 

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

But there have been problems reported even with this method. 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 32bit state so %PROCESSOR_ARCHITECTURE% will return x86 on AMD64 hardware, (example bug over at DriverPacks.net: http://forum.driverpacks.net/viewtopic.php?pid=48416#p48416), and SysWOW64 might not exist yet, though most of the time just checking for SysWOW64 will work here.

There are other situations that even though 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 or you are running a 32bit app, such as a 32bit browser. That's why you have to have 32bit 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 64bit version of Windows on a 32bit 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.

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, since the chance that someone/some setup pack will try to overwrite the existing "%SystemRoot%\SysWOW64\cmd.exe" is less likely.

So a combination method with multiple checks has been developed which checks for the existence of a particular file, not just a folder, along with checking an environment variable:

 

:PROCESSOR:: Detect OS bit-ness on running system.  Assumes 32-bit if 64-bit components do not exist.SET "ARCH=x64"IF NOT EXIST "%SystemRoot%\SysWOW64\cmd.exe" (    IF NOT DEFINED PROCESSOR_ARCHITEW6432 SET "ARCH=x86")

There are several ways that you could use the results of this test to selectively execute code based on the results of the OS bit-ness.

 

SET "ARCH=x64" IF NOT EXIST "%SystemRoot%\SysWOW64\cmd.exe" (     IF NOT DEFINED PROCESSOR_ARCHITEW6432 SET "ARCH=x86" )IF "%ARCH%"=="x64" 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. You could also use GOTO statements which don't use SET statements or you could utilize the value of %ARCH% as part of the path or file name to determine which commands to execute. You could set %ARCH% to x86/x64 or 32/64 or other values depending on your needs. All work perfectly well in batch/command script and are purely programmer's preference.

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 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" 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 above is simply an alternative version of what was suggested by Microsoft. It has been proven to work in circumstances in which just testing for SysWOW64 has failed. So even though just checking for SysWOW64 has also always worked for me in the past, if Microsoft 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.

You can read a more thorough discussion about this subject here.

Cheers and Regards