65

Believe it or not, my installer is so old that it doesn't have an option to detect the 64-bit version of Windows.

Is there a Windows DLL call or (even better) an environment variable that would give that information for Windows XP and Windows Vista?

One possible solution

I see that Wikipedia states that the 64-bit version of Windows XP and Windows Vista have a unique environment variable: %ProgramW6432%, so I'm guessing that'd be empty on 32-bit Windows.

This variable points to Program Files directory, which stores all the installed program of Windows and others. The default on English-language systems is C:\Program Files. In 64-bit editions of Windows (XP, 2003, Vista), there are also %ProgramFiles(x86)% which defaults to C:\Program Files (x86) and %ProgramW6432% which defaults to C:\Program Files. The %ProgramFiles% itself depends on whether the process requesting the environment variable is itself 32-bit or 64-bit (this is caused by Windows-on-Windows 64-bit redirection).

npocmaka
  • 55,367
  • 18
  • 148
  • 187
Clay Nichols
  • 11,848
  • 30
  • 109
  • 170
  • Related to http://stackoverflow.com/questions/1738985/why-processor-architecture-always-returns-x86-instead-of-amd64 – Leif Gruenwoldt Nov 27 '11 at 16:17
  • I posted the MSDN / Perl answer here: http://stackoverflow.com/questions/2030039/how-can-i-determine-the-bitness-of-the-os-using-perl-on-windows/8406831#8406831 – Mark Lakata Dec 06 '11 at 21:08
  • Why not use a new installer? o_O – DanRedux Apr 24 '12 at 09:27
  • Refer to: - If you're using [.NET](http://en.wikipedia.org/wiki/.NET_Framework): [How to detect Windows 64-bit platform with .NET?](http://stackoverflow.com/questions/336633/how-to-detect-windows-64-bit-platform-with-net) - If you want to use it outside .NET: [How to detect programmatically whether you are running on 64-bit Windows](http://blogs.msdn.com/oldnewthing/archive/2005/02/01/364563.aspx) – cletus Mar 02 '09 at 02:39
  • For Java, see also http://stackoverflow.com/questions/4748673/how-can-i-check-the-bitness-of-my-os-using-java-j2se-not-os-arch . (In brief, don't rely on os.arch.) – Andy Thomas Aug 23 '13 at 16:35
  • 1
    `I see that Wikipedia states that the 64-bit version of Windows XP and Windows Vista have a unique environment variable: %ProgramW6432%, so I'm guessing that'd be empty on 32-bit Windows.` Not quite. Windows XP seems to leave alone references to environment variables it doesn't know about. I.e `echo %ProgramW6432%` causes `%ProgramW6432%` to be echoed, rather than a null string. You should still be able to use this however, with a statement like: `if "%ProgramW6432%" == "Program Files" echo 64-bit OS detected` or `if not "%ProgramW6432%" == "Program Files" echo 32-bit OS detected` – rossmcm Feb 12 '14 at 21:29
  • Also see: http://stackoverflow.com/questions/29074673/iswow64process-always-returns-true-how-to-detect-32-64-platform – Gabriel Mar 16 '15 at 10:56

24 Answers24

63

To check for a 64-bit version of Windows in a command box, I use the following template:

test.bat:

@echo off
if defined ProgramFiles(x86) (
    @echo yes
    @echo Some 64-bit work
) else (
    @echo no
    @echo Some 32-bit work
)

ProgramFiles(x86) is an environment variable automatically defined by cmd.exe (both 32-bit and 64-bit versions) on Windows 64-bit machines only.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Dror Harari
  • 3,076
  • 2
  • 27
  • 25
  • Are those Environment Variables you're testing there? And by the answer "yes, no", are you answering the question : "Is this the 64 bit version of Windows"? – Clay Nichols Apr 25 '12 at 13:16
  • 1
    I've just checked on both 32 and 64 bit Windows 7 systems, and it works as advertised. Nice. – Kuba hasn't forgotten Monica Mar 18 '13 at 18:53
  • 3
    Note that braces for `if` work in XP+. If you care about Win98 that is ;-). – Nux May 06 '14 at 13:48
  • It's also simple enough to use without any additional cookbooks with tools such as Chef, which is a bonus. – northerncodemonkey Oct 01 '14 at 14:08
  • Tested, I think this should be the accepted answer. – Amr Lotfy Apr 04 '15 at 13:45
  • On my windows7, this won't work when used in a script inside an if block: "if defined ProgramFiles(x86) (" gives ") was unexpected at this time." And quoting "ProgramFiles(x86)" doesn't work either. – mosh Sep 04 '16 at 11:16
  • The variable ProgramFiles(x86) seems to serve interoperability between 32-bit and 64-bit parent and child processes. An SS64.com article Detecting 64 bit vs 32 bit shows tricks to detect 64-bit hardware, OS and processes. https://ss64.com/nt/syntax-64bit.html – eel ghEEz Feb 23 '17 at 17:09
20

Here is some Delphi code to check whether your program is running on a 64 bit operating system:

function Is64BitOS: Boolean;
{$IFNDEF WIN64}
type
  TIsWow64Process = function(Handle:THandle; var IsWow64 : BOOL) : BOOL; stdcall;
var
  hKernel32 : Integer;
  IsWow64Process : TIsWow64Process;
  IsWow64 : BOOL;
{$ENDIF}
begin
  {$IFDEF WIN64}
     //We're a 64-bit application; obviously we're running on 64-bit Windows.
     Result := True;
  {$ELSE}
  // We can check if the operating system is 64-bit by checking whether
  // we are running under Wow64 (we are 32-bit code). We must check if this
  // function is implemented before we call it, because some older 32-bit 
  // versions of kernel32.dll (eg. Windows 2000) don't know about it.
  // See "IsWow64Process", http://msdn.microsoft.com/en-us/library/ms684139.aspx
  Result := False;
  hKernel32 := LoadLibrary('kernel32.dll');
  if hKernel32 = 0 then RaiseLastOSError;
  try
    @IsWow64Process := GetProcAddress(hkernel32, 'IsWow64Process');
    if Assigned(IsWow64Process) then begin
      if (IsWow64Process(GetCurrentProcess, IsWow64)) then begin
        Result := IsWow64;
      end
      else RaiseLastOSError;
    end;
  finally
    FreeLibrary(hKernel32);
  end;  
  {$ENDIf}
end;
Blorgbeard
  • 101,031
  • 48
  • 228
  • 272
  • 1
    Since stackoverflow is a programming site, this is the programmers answer: using the API intended to answer this question. – Ian Boyd Nov 04 '13 at 18:06
  • 1
    Does it work? Since you test at COMPILE time if the app was build on a 64bit system. Basically, if the app was compiled on 64 bits it will always answer TRUE even, of 32 bits. Am I right? – Gabriel Mar 16 '15 at 10:20
  • Also see: http://stackoverflow.com/questions/29074673/iswow64process-always-returns-true-how-to-detect-32-64-platform – Gabriel Mar 16 '15 at 10:56
  • @Altar no, I'm testing at compile time if the app was built **for** a 64bit system. You can compile 32-bit programs on a 64-bit system. – Blorgbeard Mar 16 '15 at 19:49
  • http://blogs.msdn.com/b/oldnewthing/archive/2005/02/01/364563.aspx and MSDN both suggest that this function is always defined in win32 and win64 so the code could be made simpler by just executing IsWow64Process. – Lothar Jun 16 '15 at 11:38
  • @Lothar [MSDN](https://msdn.microsoft.com/en-us/library/windows/desktop/ms684139.aspx) appears to agree with me.. – Blorgbeard Jun 16 '15 at 19:12
  • My point was your whole code bloat could be reduced to just one line of code. – Lothar Jun 18 '15 at 12:53
  • @Lothar I understand what you are saying, but you are incorrect. Read the msdn link. "Minimum supported client Windows Vista, Windows XP with SP2" -- Win2k, for example, does not have IsWow64Process. The same point is made in the comments of the blog post you linked. – Blorgbeard Jun 18 '15 at 20:21
14

From a batch script:

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

Using Windows API:

if (GetSystemWow64Directory(Directory, MaxDirectory) > 0) 
   // OS is 64bit
else
   // OS is 32bit

Sources:

  1. HOWTO: Detect Process Bitness
  2. GetSystemWow64Directory function
Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Leif Gruenwoldt
  • 13,561
  • 5
  • 60
  • 64
13

I tested the solution I suggested in my question:

Tested for Windows Environment Variable: ProgramW6432

If it's non empty then it's 64 bit Windows.W

Clay Nichols
  • 11,848
  • 30
  • 109
  • 170
  • 2
    The environment variable you listed in your question was ProgramW6432. Here, you list PROCESSOR_ARCHITEW6432. Which one did you use? – Andrew Ensley Mar 17 '09 at 20:43
  • 1
    Thanks Andrew. I found out about this mistake the hard way: when I had someone test it ;-). Should have been: ProgramW6432 .Fixing it now. – Clay Nichols Mar 18 '09 at 13:24
  • 5
    I don't have either of these environment variables (ProgramW6432 PROCESSOR_ARCHITEW6432), on my Vista 64. I do have PROCESSOR_ARCHITECTURE, which is set to x86 or AMD64 – Mike Aug 28 '09 at 18:54
  • Thanks Mike! Now, if I can just figure out if Processor_Architecture is *always* present on Win 64. – Clay Nichols Aug 29 '09 at 03:20
  • Except for PROCESSOR_ARCHITE*, these env variables were added in Win7/Server2008: http://msdn.microsoft.com/en-us/library/aa384274(VS.85).aspx – jturcotte Jul 15 '10 at 11:43
  • 4
    @Mike, @total, @Clay: I do have `ProgramW6432`, `PROCESSOR_ARCHITEW6432` and `CommonProgramW6432` on my 64-bit Vista Enterprise SP2, but only in 32-bit command prompt. Whether or not these variables are defined seems to depend on the bitness of the calling process, not the OS bitness. – Helen Jun 01 '11 at 06:29
9

See the batch script listed in How To Check If Computer Is Running A 32 Bit or 64 Bit Operating System. It also includes instructions for checking this from the Registry:

You can use the following registry location to check if computer is running 32 or 64 bit of Windows operating system:

HKLM\HARDWARE\DESCRIPTION\System\CentralProcessor\0

You will see the following registry entries in the right pane:

Identifier     REG_SZ             x86 Family 6 Model 14 Stepping 12
Platform ID    REG_DWORD          0x00000020(32)

The above “x86” and “0x00000020(32)” indicate that the operating system version is 32 bit.

Wolf
  • 9,679
  • 7
  • 62
  • 108
Leif Gruenwoldt
  • 13,561
  • 5
  • 60
  • 64
  • 9
    I find the referenced KB article somewhat confusing: They look at whether the CPU is 32 or 64 bit, and from that they determine whether you're running 32-bit or 64-bit Windows? I'm pretty sure you can run 32-bit Windows on a 64-bit CPU. Or maybe I'm missing something.. – daniel kullmann Jun 19 '12 at 13:06
  • @daniel kullmann: Obviously the key will be faked to be X86 as the microsoft kb articel noticed to use HKLM\SYSTEM\CurrentCongtrolSet\Control\Session Manager\Envirornment to determine the actual processor type. – thomiel Jun 26 '13 at 14:50
  • 6
    With regards to `HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\CentralProcessor\0`... - On a Win7 64 bit box, I have the following values: Identifier = "Intel64 Family 6 Model 23 Stepping 6", and Platform ID=1 - On a WinXP 32 box (a VM), I have the following values: Identifier = "x86 Family 6 Model 26 Stepping 5", and Platform ID=1 The point here is ***not*** to rely on Platform ID (as it's not always 0x00000020 for x86). – CJBS Jan 29 '14 at 21:25
  • 2
    On Win8.1x64, `Platform ID` not exist. But here other key `Platform Specific Field 1` which is `0x00000002` (two) – befzz Jul 17 '14 at 20:33
  • 1
    Having 64bit CPU does not entail running 64 bit windows. I have a laptop with 64bit CPU but 32bit windows preinstalled on it. – Artur Feb 02 '15 at 18:35
  • I'm using Window7 x86, Windows 8.1 x64, Windows Xp x86. But I can't find Platform ID on Windows 8.1 and the value is not 0x0000020 on Windows 7 and Windows Xp. – Bryant Jul 28 '17 at 01:40
  • On Win10 x64 on `Intel(R) Xeon(R) CPU E5520 @ 2.27GHz` there is no `Platform ID` but `Platform Specific Field 1` with value 1. – JM Lauer Apr 09 '20 at 08:09
  • Note that referenced KB article (Last Updated: Apr 17, 2018) states : Applies to: Microsoft Windows Server 2003 Datacenter Edition (32-bit x86)Microsoft Windows Server 2003 Enterprise Edition (32-bit x86)Microsoft Windows Server 2003 Standard Edition (32-bit x86)Microsoft Windows Server 2003 Web Edition – JM Lauer Apr 09 '20 at 08:12
8

If you can make API calls, try using GetProcAddress / GetModuleHandle to check for the existence of IsWow64Process which is only present in Windows OS that have 64-bit versions.

You could also try the ProgramFiles(x86) environment variable used in Vista/2008 for backwards compatibility, but I'm not 100% sure about XP-64 or 2003-64.

Good luck!

Jason
  • 985
  • 1
  • 6
  • 12
  • PG(x86) is in at least XP-64 and since XP-64 is more related to 2003-64 than, say, XP original I'd bet it's in 2003-64 too. – Esko Mar 02 '09 at 06:22
  • 2
    According to the MSDN article for IsWow64Process, "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." – Nathan Moinvaziri Aug 13 '12 at 18:46
  • Checking the existence of IsWow64Process is not reliable. Just failed on Windows Xp 32 bit. IsWow64Process is present – Jako Apr 16 '13 at 10:37
  • 2
    Checking for the entry point is not a reliable test, but according to Raymond Chen *calling* that entry point (if present) and checking the return value is. If it's not present or returns FALSE you're on 32-bit Windows, if it returns TRUE you're running under WOW64 so running on a Windows of *at least* 64 bits... – Spike0xff Nov 05 '13 at 19:57
6

I used this within a login script to detect 64 bit Windows

if "%ProgramW6432%" == "%ProgramFiles%" goto is64flag
shA.t
  • 16,580
  • 5
  • 54
  • 111
TallGuy
  • 61
  • 1
  • 1
4

For a VBScript / WMI one-liner that retrieves the actuals bits number (32 or 64) of the OS or the Hardware, take a look at http://csi-windows.com/toolkit/csi-getosbits

Darwin
  • 141
  • 1
  • 1
4

I don't know what language you're using, but .NET has the environment variable PROCESSOR_ARCHITEW6432 if the OS is 64-bit.

If all you want to know is whether your application is running 32-bit or 64-bit, you can check IntPtr.Size. It will be 4 if running in 32-bit mode and 8 if running in 64-bit mode.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Andrew Ensley
  • 11,611
  • 16
  • 61
  • 73
  • This option only works in .net. I need an option that'll work with my installer. – Clay Nichols Mar 17 '09 at 19:04
  • If you force the project to 32-bit (e.g. Project->Propterties and change platform target to x86), the IntPtr.Size value will be 4. – Jader Dias Oct 19 '10 at 15:36
  • @Jader: Right you are. I didn't realize how ambiguous my answer was before, but it was obvious as soon as you pointed it out. I've edited my answer for clarity. – Andrew Ensley Oct 22 '10 at 02:54
3

I want to add what I use in shell scripts (but can easily be used in any language) here. The reason is, that some of the solutions here don't work an WoW64, some use things not really meant for that (checking if there is a *(x86) folder) or don't work in cmd scripts. I feel, this is the "proper" way to do it, and should be safe even in future versions of Windows.

 @echo off
 if /i %processor_architecture%==AMD64 GOTO AMD64
 if /i %PROCESSOR_ARCHITEW6432%==AMD64 GOTO AMD64
    rem only defined in WoW64 processes
 if /i %processor_architecture%==x86 GOTO x86
 GOTO ERR
 :AMD64
    rem do amd64 stuff
 GOTO EXEC
 :x86
    rem do x86 stuff
 GOTO EXEC
 :EXEC
    rem do arch independent stuff
 GOTO END
 :ERR
    rem I feel there should always be a proper error-path!
    @echo Unsupported architecture!
    pause
 :END
Josef
  • 1,467
  • 2
  • 24
  • 40
  • Josef, have you tested this on a 32 bit and 64 bit machine? – Clay Nichols Jul 10 '12 at 14:00
  • My use for this is to have my installer behave differently so I'd need a return value. So I'd call this script and then have it return a value (1 or 0, etc.). – Clay Nichols Jul 10 '12 at 14:02
  • For anyone who's wondering, the ``PROCESSOR_ARCHITECTURE`` variable appears to change for compiled programs. ``echo %PROCESSOR_ARCHITECTURE%`` reported ``AMD64`` on Windows XP x64, but when I ran a 32-bit compiled program using this variable, it came back as ``x86``. – codekoala Sep 24 '14 at 22:02
  • 2
    @codekoala that's why the check for "%PROCESSOR_ARCHITEW6432%" is there! That script works flawlessly for all windows versions >= XP and even if called in a 32bit cmd.exe on a 64bit os! – Josef Sep 25 '14 at 14:08
  • @Josef That environment variable didn't appear to be on the systems I was testing against... Maybe I wasn't looking close enough. – codekoala Sep 25 '14 at 15:39
  • 2
    @Josef Right you are, friend! It's a magic environment variable that didn't show up when I ran ``set``, but it's there in the compiled program. Silly me. Thanks for setting me straight! – codekoala Sep 25 '14 at 15:44
3

A lot of answers mention calling IsWoW64Process() or related functions. This is not the correct way. You should use GetNativeSystemInfo() which was designed for this purpose. Here's an example:

SYSTEM_INFO info;
GetNativeSystemInfo(&info);

if (info.wProcessorArchitecture == PROCESSOR_ARCHITECTURE_AMD64) {
  // It's a 64-bit OS
}

Also see: https://msdn.microsoft.com/en-us/library/windows/desktop/ms724340%28v=vs.85%29.aspx

jcoffland
  • 5,238
  • 38
  • 43
2

I don't know on which Windows version it exists, but on Windows Vista and later this runs:

Function Is64Bit As Boolean
    Dim x64 As Boolean = System.Environment.Is64BitOperatingSystem
    If x64 Then
       Return true
    Else
       Return false
    End If
End Function
Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
nicu96
  • 21
  • 1
1

I use this:

@echo off
if "%PROCESSOR_ARCHITECTURE%"=="AMD64" (
 echo 64 BIT
) else (
 echo 32 BIT
)

It works on Windows XP, tested it on Windows XP Professional Both 64 bit and 32 bit.

user83250
  • 17
  • 1
  • 6
1

In C#:

public bool Is64bit() {
    return Marshal.SizeOf(typeof(IntPtr)) == 8;
}

In VB.NET:

Public Function Is64bit() As Boolean
   If Marshal.SizeOf(GetType(IntPtr)) = 8 Then Return True
   Return False
End Function
Carl Onager
  • 4,112
  • 2
  • 38
  • 66
Renaud Bompuis
  • 16,596
  • 4
  • 56
  • 86
  • 11
    That detects if the application is a 64-bit app. If you force it to 32-bit (e.g. Project->Propterties and change platform target to x86), the return value will be 4. – Raymond Martineau Mar 02 '09 at 05:30
  • Not the answer to this question, this detect if application is compilered as 64bit. – Sun Junwen Aug 20 '13 at 09:38
0

Using Windows Powershell, if the following expression returns true, then it's a 64 bit OS:

(([Array](Get-WmiObject -Class Win32_Processor | Select-Object AddressWidth))[0].AddressWidth -eq 64)

This was taken and modified from: http://depsharee.blogspot.com/2011/06/how-do-detect-operating-system.html (Method #3). I've tested this on Win7 64 bit (in both 32 and 64 bit PowerShell sessions), and XP 32 bit.

CJBS
  • 15,147
  • 6
  • 86
  • 135
0

The best way is surely just to check whether there are two program files directories, 'Program Files'and 'Program Files (x86)' The advantage of this method is you can do it when the o/s is not running, for instance if the machine has failed to start and you wish to reinstall the operating system

jasee
  • 1
0

Interestingly, if I use

get-wmiobject -class Win32_Environment -filter "Name='PROCESSOR_ARCHITECTURE'"

I get AMD64 in both 32-bit and 64-bit ISE (on Win7 64-bit).

Mike Shepard
  • 17,466
  • 6
  • 51
  • 69
0

Another way created by eGerman that uses PE numbers of compiled executables (does not rely on registry records or environment variables):

@echo off &setlocal


call :getPETarget "%SystemRoot%\explorer.exe"


if "%=ExitCode%" EQU "00008664" (
    echo x64
) else (
    if "%=ExitCode%" EQU "0000014C" (
        echo x32
    ) else (
        echo undefined
    )
)


goto :eof


:getPETarget FilePath
:: ~~~~~~~~~~~~~~~~~~~~~~
:: Errorlevel
::   0 Success
::   1 File Not Found
::   2 Wrong Magic Number
::   3 Out Of Scope
::   4 No PE File
:: ~~~~~~~~~~~~~~~~~~~~~~
:: =ExitCode
::   CPU identifier

setlocal DisableDelayedExpansion
set "File=%~1"
set Cmp="%temp%\%random%.%random%.1KB"
set Dmp="%temp%\%random%.%random%.dmp"

REM write 1024 times 'A' into a temporary file
if exist "%File%" (
  >%Cmp% (
    for /l %%i in (1 1 32) do <nul set /p "=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
  )
  setlocal EnableDelayedExpansion
) else (endlocal &cmd /c exit 0 &exit /b 1)

REM generate a HEX dump of the executable file (first 1024 Bytes)
set "X=1"
>!Dmp! (
  for /f "skip=1 tokens=1,2 delims=: " %%i in ('fc /b "!File!" !Cmp!^|findstr /vbi "FC:"') do (
    set /a "Y=0x%%i"
    for /l %%k in (!X! 1 !Y!) do echo 41
    set /a "X=Y+2"
    echo %%j
  )
)
del !Cmp!

REM read certain values out of the HEX dump
set "err="
<!Dmp! (
  set /p "A="
  set /p "B="
  REM magic number has to be "MZ"
  if "!A!!B!" neq "4D5A" (set "err=2") else (
    REM skip next 58 bytes
    for /l %%i in (3 1 60) do set /p "="
    REM bytes 61-64 contain the offset to the PE header in little endian order
    set /p "C="
    set /p "D="
    set /p "E="
    set /p "F="
    REM check if the beginning of the PE header is part of the HEX dump
    if 0x!F!!E!!D!!C! lss 1 (set "err=3") else (
      if 0x!F!!E!!D!!C! gtr 1018 (set "err=3") else (
        REM skip the offset to the PE header
        for /l %%i in (65 1 0x!F!!E!!D!!C!) do set /p "="
        REM next 4 bytes have to contain the signature of the PE header
        set /p "G="
        set /p "H="
        set /p "I="
        set /p "J="
        REM next 2 bytes contain the CPU identifier in little endian order
        set /p "K="
        set /p "L="
      )
    )
  )
)
del !Dmp!
if defined err (endlocal &endlocal &cmd /c exit 0 &exit /b %err%)

REM was the signature ("PE\0\0") of the PE header found
if "%G%%H%%I%%J%"=="50450000" (
  REM calculate the decimal value of the CPU identifier
  set /a "CPUID=0x%L%%K%"
) else (endlocal &endlocal &cmd /c exit 0 &exit /b 4)
endlocal &endlocal &cmd /c exit %CPUID% &exit /b 0
npocmaka
  • 55,367
  • 18
  • 148
  • 187
0

Here is a simpler method for batch scripts

    @echo off

    goto %PROCESSOR_ARCHITECTURE%

    :AMD64
    echo AMD64
    goto :EOF

    :x86 
    echo x86
    goto :EOF
Max
  • 161
  • 2
  • 4
0

Answer for Newer Versions of Windows

Today, I posted some code on another question and an explanation of how to do this with IsWow64Process2 for Windows 10 version 1511 or later and Windows Server 2016. Additionally, the code determines if the process is 32 or 64 bit and whether the process is running under the WOW64 emulator.

One of the main reasons I have posted the answer is because while there were several suggestions to use IsWow64Process2, no code that I saw showed how.

Please see the answer here: https://stackoverflow.com/a/59377888/1691559

Xitalogy
  • 1,592
  • 1
  • 14
  • 17
0

You can use the module from npm called @wider/utils_where-am-i. This runs in any javascript environment on a windows machine and elsewhere such as linux. On a windows machine it delivers an object which has { os: 'win32' } or { os : 'win64' }. It can run as legacy plain javascript say in wshell, in classic ASP or nodeJS

0

I tested the following batch file on Windows 7 x64/x86 and Windows XP x86 and it's fine, but I haven't tried Windows XP x64 yet, but this will probably work:

If Defined ProgramW6432 (Do x64 stuff or end if you are aiming for x86) else (Do x86 stuff or end if you are aiming for x64) 
Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Match
  • 21
  • 2
0

I know this is ancient but, here's what I use to detect Win764

On Error Resume Next

Set objWSHShell = CreateObject("WScript.Shell")

strWinVer = objWSHShell.RegRead("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\BuildLabEx")

If len(strWinVer) > 0 Then
    arrWinVer = Split(strWinVer,".")
    strWinVer = arrWinVer(2)
End If

Select Case strWinVer
Case "x86fre"
strWinVer = "Win7"
Case "amd64fre"
    strWinVer = "Win7 64-bit"
Case Else
    objWSHShell.Popup("OS Not Recognized")
    WScript.Quit
End Select
Verbose
  • 138
  • 5
-2

Check the Registry for the existence of HKLM\SOFTWARE\Wow6432Node - If it's there, the system is 64-bit - 32-bit, otherwise.

  • 3
    I'd caution against using the existence of the `HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node` key in the registry -- It just takes one other (incorrect) program to install something there on a 32 bit OS to cause this method to fail -- that's the reason I found this page in the first place! – CJBS Jan 29 '14 at 21:24