Multiple DirectX SDKs on the same O.S. ?

D619d95cddb1edb227f51ef539d15cdc
0
Nautilus 103 Aug 21, 2012 at 12:44

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 : )

1 Reply

Please log in or register to post a reply.

D619d95cddb1edb227f51ef539d15cdc
0
Nautilus 103 Aug 23, 2012 at 13:46

Update:

solved :)

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 environment variable.
Like this:

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 variable.
The syntax is very simple: $(var_name), and it works like a macro.
So that you can express the above paths as:

$(DXSDK_DIR)Include
$(DXSDK_DIR)lib\x86

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 there).
To modify a given variable, type SET, followed by the variable’s name, then the equal sign (=), and finally the new value.
For example:

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 command.

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.

Ciao ciao : )