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 Express, 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.
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.