None of the following is original content (I will cite as best I can) but will help aggregate info on this situation.
If you're using .Net 4 or higher, stop reading now. This is built into the framework (check out System.Environment.get_is64bitoperatingsystem)
For all else, there are a number of options I've come across along the way.
Solution 1: Compile Time Directives
Raymond Chen's MSDN Blog:
http://blogs.msdn.com/b/oldnewthing/archive/2005/02/01/364563.aspx
BOOL Is64BitWindows()
{
#if defined(_WIN64)
return TRUE; // 64-bit programs run only on Win64
#elif defined(_WIN32)
// 32-bit programs run on both 32-bit and 64-bit Windows
// so must sniff
BOOL f64 = FALSE;
return IsWow64Process(GetCurrentProcess(), &f64) && f64;
#else
return FALSE; // Win64 does not support Win16
#endif
}
Credits For this solution: @Thorarin points to a dup. thread where Stefan Schultze links to this article. I'm not sure that the thread is a dupe though. The author specifically says that he is checking the OS platform. I'm not sure that the intent is to discover if your application is running in 32bit or 64bit mode.
Solution 2: Pointer Observations
I'll defer to @Max for this one and just add the following MSDN article for extra reading:
http://msdn.microsoft.com/en-us/library/system.intptr.size.aspx
The bit to know: Pointer size on 32bit = 4, on 64bit = 8.
Give the man a point!
Solution 3: Using WinAPI - AKA - To hell w/ .Net, I'll find out my damn self!
http://msdn.microsoft.com/en-us/library/ms684139(v=vs.85).aspx
BOOL WINAPI IsWow64Process(
__in HANDLE hProcess,
__out PBOOL Wow64Process
);
Notes:
There are hacks such as looking for "Program Files(x86)", or looking at your processor architecture flags.
The issues with these methods are that
- They rely on common folder names that may not hold in "custom" installations
- The processor's x64 flag will not always reflect your current runtime state. Are you guaranteed to have compiled for "Any CPU"? Running a 32bit OS on a 64bit processor? etc.
Ideally you should not rely on external indicators and instead look for cues within the current appdomain. We want all solutions (whenever possible) to be bombproof.