Reliably Checking Windows Bitness (32-bit or 64-bit) With a Tiny C++ App

I threw myself right into the bitness fire this afternoon, trying to figure out how to reliably determine if a Windows OS is 32-bit or native 64-bit.  I tried all sorts of things, everything from a VB Script, to a few tiny C++ programs built to issue WMI queries.  I tried using WMI to read the OSArchitecture property from its "SELECT * FROM Win32_OperatingSystem" output, but that failed miserably on Windows XP.  As it turns out, the OSArchitecture property you can read via WMI wasn't added until Vista.  Nice.  So how do we check for 64-bit Windows XP?

After about an hour or so of searching, I stumbled across this post which described in reasonable detail what I needed to:

"In your code, you first need to check the size of IntPtr, if it returns 8 then you are running on a 64-bit OS. If it returns 4, you are running a 32 bit application, so now you need to know whether you are running natively or under WOW64. To get this information you will need to call kernel32.dll API "IsWow64Process" using PInvoke, this API returns a Boolean 'true' if you are running under WOW64, that means you are running 32 bit application on a 64-bit Windows system. Be careful however to check the OS version before calling this API, only XP SP2 and implements this one."

How could Microsoft make something that should be so easy, so complicated?  What a FAIL.

I then found this post, that offered up a nice little 32-bit C++ app one can compile and run to check the real, actual bitness of the OS.  For the most part, it does exactly what the first post said I needed to do, with the exception of checking the size of IntPtr's.  I cleaned it up a little bit, and successfully compiled it on 32-bit Windows XP with Microsoft Visual C++ 2005 (Version 8.0.50).  This app checks the bitness of the OS by discovering if it's running under WOW64, or natively as a 32-bit app.  WOW64 stands for Windows-on-Windows, it's the 64-bit only kernel subsystem that lets 32-bit apps run on 64-bit Windows.  The bitness checker starts and then asks the Windows kernel if it's running under WOW64.  If it is running under WOW64, that clearly means it's a 32-bit app (as compiled) running on a 64-bit OS.  If it's not running in WOW64, then we're on a 32-bit OS ...

#include "stdafx.h"
#include <iostream>
#include "comutil.h"

#define RESPONSE_32_BIT "32"
#define RESPONSE_64_BIT "64"

using namespace std;

typedef BOOL (WINAPI *IW64PFP)(HANDLE, BOOL *);

int main(int argc, char **argv){

  BOOL res = FALSE;

  // When this application is compiled as a 32-bit app,
  // and run on a native 64-bit system, Windows will run
  // this application under WOW64.  WOW64 is the Windows-
  // on-Windows subsystem that lets native 32-bit applications
  // run in 64-bit land.  This calls the kernel32.dll
  // API to see if this process is running under WOW64.
  // If it is running under WOW64, then that clearly means
  // this 32-bit application is running on a 64-bit OS,
  // and IsWow64Process will return true.
  IW64PFP IW64P = (IW64PFP)GetProcAddress(
            GetModuleHandle(L"kernel32"), "IsWow64Process");

  if(IW64P != NULL){
    IW64P(GetCurrentProcess(), &res);
  }

  cout << ((res) ? RESPONSE_64_BIT : RESPONSE_32_BIT) << endl;

  return 0;
  
}

Will output "32" on 32-bit Windows and "64" on 64-bit Windows.  Download the pre-built .exe and .cpp source here.

• Tested and worked on:  32-bit Windows XP Professional SP3, 32-bit Windows Vista Enterprise SP2, 64-bit Windows Vista Enterprise, 32-Bit Windows 7 Home Premium, 64-bit Windows 7 Home Premium.
  
  
• Did NOT test on: 64-bit Windows XP. I don't have a 64-bit Windows XP box lying around. If you have one, and you can check this code for me, please let me know and I'll be happy to update this post and give you credit for testing it for me. @cmsimike confirmed on 10/27/09 that my bitness checker also works perfectly on 64-bit Windows XP.
  
  
• Roger confirmed on 11/12/09 that my bitness checker also works on 32-bit Windows Server 2003 and 64-bit Windows Server 2008.  Thanks, Roger!
  

Cheers.