In Visual Studio 2008, is there a macro identifying a 64-bit Windows OS?

Here's the problem:

In order to #import the correct version of ADO for my 32-bit program, I need to know whether I'm compiling on a 32-bit Windows OS (meaning the file is in Program Files) or a 64-bit OS (meaning the file is in Program Files (x86)). But I can't find a macro that tells me this, or even a macro that tells me that the processor is 64-bit.

When I test it on 64-bit windows 7 running Visual Studio 2008 E开发者_开发问答xpress, the following pertinent macros are defined:

_M_IX86

X86

But none of the *64 macros appear to be defined, which I suppose would be the case if they are referring to /target/ architectures and not the current machine's architecture.

Is there a preprocessor macro that will tell me whether I am running a 64-bit Windows OS?

And if so, what is it? I'd even settle for one that will tell me whether I'm using a 64-bit processor.

(p.s. I am already aware of this list)

Update

So far, people seem to think that there is no such macro, and copying the DLLs or using environment variables is a better thing to do.

So taking the environment variable hint, I have worked around the problem for developers by putting both folders -- Program Files (x86) and Program Files -- on the include path and using the angle-bracket syntax of #import. However, I suspect that I will need to build release versions for each version of the OS because the ADO DLLs are now part of the OS and are not redistributable. Looking into that.

Check for this: _WIN64

Described here:

http://msdn.microsoft.com/en-us/magazine/cc300794.aspx

I use this and it works.

Your situation is more complex in that you want to know the OS rather than the type of compilation. I use Windows x64 all the time but I compile both 32 bit and 64 bit applications. _WIN64 is only defined when I am compiling a 64 bit application and not when I am compiling a 32 bit application even though I am always on a Windows x64 machine.

I think you should just set up your include directories differently to hide this complexity. It is good to assume that include directories will vary widely across different machines, thus making the path detection fully automated is likely trying to be too smart for your own good in the long run.

I'm not aware of a macro, but you can use the environment variable PROCESSOR_ARCHITECTURE. Note you can access environment variables from visual studio settings dialog boxes by using the $(PROCESSOR_ARCHITECTURE) notation.

Also, a workaround for your case would be to define an environment variable such as ADO_LIB_DIR, set it to the correct program files directory, and then import the lib or add an include directory with a notation that uses the $(ADO_LIB_DIR) variable. This way all you will have to do when you compile on a new machine is to set the environment variable.

Update: I see there are also $(ProgramFiles) and $(ProgramFiles(x86)) environment variables, so your best bet is probably to use them.

I had the same problem, but not only with ado, but also with other libraries (ESRI). So the solution was the following: In Project Setting -> C/C++ -> Preprocessor -> "Preprocessor Definitions": Added following text: COMPILATION_PLATFORM=$(PROCESSOR_ARCHITECTURE)

And in code I can make a decision just an example how it works:

#if ((COMPILATION_PLATFORM == AMD64) && (_WIN64))
#pragma message( "StdAfx.cpp  >> COMPILATION HOST IS RUNNING on WINDOWS64, Generated code = x64 (64bit)" )
#elif ((COMPILATION_PLATFORM == AMD64) && (_WIN32))
#pragma message( "StdAfx.cpp  >> COMPILATION HOST IS RUNNING on WINDOWS64, Generated code = x86 (32bit)" )
#elif ((COMPILATION_PLATFORM == x86) && (_WIN64))
#pragma message( "StdAfx.cpp  >> COMPILATION HOST IS RUNNING on WINDOWS32, Generated code = x64 (64bit)" )
#elif ((COMPILATION_PLATFORM == x86) && (_WIN32))
#pragma message( "StdAfx.cpp  >> COMPILATION HOST IS RUNNING on WINDOWS32, Generated code = x86 (32bit)" )
#endif

I hope it could help you. Marek