For the past months I’ve been developing an utility that is supposed to
employ different DirectX versions, as opposed to the latest one only.
I’m about to install a second [DirectX] SDK on the same system. And if
it goes as planned, I’ll install even more.
But I never tried this before. And before I screw up a healthy O.S.
without the means to roll back (short of a wide reinstall that would
consume a day) I’d ask if anyone has experience with this and can warn
me about pitfalls.
I’d prefer to avoid the use of separate O.S. (one to each SDK) as I
don’t have the HDD space to afford it.
The IDE I work with is Microsoft Visual Studio.
Thanks in advance.
Ciao ciao : )
Please log in or register to post a reply.
Different SDK’s can coexist nicely on the same target system - so long
they install at all, of course.
However Visual Studio can only make use of 1 (one) at a time, meaning
that there’s some manual labor to do, however quick.
The trick is to make use of the environment variables, which are
placeholders known to the IDE that evaluate to absolute folder paths.
Expert Visual Studio users will know of this already. But for the
less-than-experts, like me, here’s a useful explanation:
When installing a DIrectX SDK, the environment variable DXSDK_DIR is
automatically created by the installer, and it is set to whatever main
folder you installed the SDK in.
For example, in my case I have:
DXSDK_DIR=C:\Program Files\Microsoft DirectX SDK (June 2010)\
Weird enough the IDE won’t make use of it (at least this is my case),
and in the paths setup for headers and libs you may see the full folder
paths explicitly spelled out, instead of making clever use of the
C:\Program Files\Microsoft DirectX SDK (June 2010)\Include
C:\Program Files\Microsoft DirectX SDK (June 2010)\lib\x86
Know that you can edit those paths to make use of the DXSDK_DIR
The syntax is very simple: $(var_name), and it works like a
So that you can express the above paths as:
And then when you want to compile against a different SDK version you
simply change the value held in the DXSDK_DIR environment variable
and restart Visual Studio.
To view, modify, remove or even add new environment variables, you can
use the Visual Studio console prompt (find this in the Start Menu within
the program group of your Visual Studio).
At the prompt type SET and press the Enter key.
This will list all the environment variables currently known, among
which you’ll find DXSDK_DIR (you may have to search a bit, but it’s
To modify a given variable, type SET, followed by the variable’s
name, then the equal sign (=), and finally the new value.
C:\>set DXSDK_DIR=C:\Program Files\Microsoft DirectX 7 SDK\
(you can setup a batch file to automate the switching, don’t you forget)
Type HELP at the prompt for a list of console commands.
Or type directly HELP SET to receive specific help on the SET
Know that modern Visual Studio IDE’s allow you to change the environment
variables directly from the Project Properties window. That’s a far
nicer way of doing it, and if you have one such version it’s better to
use that interface. Otherwise the console method I just described will
work regardless of IDE version.
NOTE: Double check the final paths you are spelling once the
environment variable is changed. Two SDK’s very distant in time (like
SDK 7 and SDK 9) will likely place their \Include and \Lib
folders on different paths, relatively to the main_SDK_folder.
In my case the SDK 9 used the path: C:\main_SDK_folder\lib\x86
But the SDK 7 used the path: C:\main_SDK_folder\lib
They won’t match, and should I switch the DXSDK_DIR to point from
SDK 9 to SDK 7, the compiler would fail to find the library files since
the path pointed to doesn’t exist (\lib\x86).
A painless solution is to manually copy the SDK 7 .lib files in a
brand new \x86 folder manualy created under the \lib folder of
the SDK 7, in order to match the relative path expected by the IDE (just
leave the original files where they are to avoid breaking anything).
Maybe someday this will be helpful to somebody else.