Hey, Scripting Guy! How can I determine the version of DirectX installed on a computer?

— ML

Hey, ML. How can you determine the version of DirectX installed on a computer? That’s an important question, and we’ll get to that in a moment. Before we do that, however, there’s an even more important issue we need to address: quicksand. Until very recently the Scripting Guy who writes this column wasn’t aware of this, but, as it turns out, quicksand won’t actually suck you all the way under, the way it does in the movies. That’s because the human body is less dense than the quicksand; at worst you might sink in to your waist or so. (And yes, that means that there actually is something more dense than the Scripting Guys.) Granted, you’ll find it hard to get out should you sink in that far, and while you’re stuck there you might die of thirst or be eaten by a lion or something. But you won’t actually drown.

Ironically, it proved easier to get bogged down in DirectX than it does to get bogged down in quicksand. We knew that the DirectX version number was stored in the registry, and we even had a vague idea where this information could be found in the registry (HKEY_LOCAL_MACHINE\Software\Microsoft\DirectX as it turns out). What we weren’t ready for was the actual value stored in the registry; for example, on our test computer that value happens to be 4.09.00.0904. That’s fine, except that this is a fairly new computer and we were pretty sure it had DirectX 9.something installed. Suddenly we began to get this sinking feeling, if you know what we mean.

But all’s well that ends well: to determine the version of DirectX all we need to do is retrieve the registry value and then convert that to the “real” version of DirectX. Coincidentally enough, that’s exactly what this script does:

Const HKEY_LOCAL_MACHINE = &H80000002

strComputer = "."

Set objRegistry=GetObject("winmgmts:\\" & strComputer & "\root\default:StdRegProv")

strKeyPath = "Software\Microsoft\DirectX"
strValueName = "Version"

objRegistry.GetStringValue HKEY_LOCAL_MACHINE, strKeyPath, strValueName, strValue

Select Case strValue
    Case "4.02.0095"
        strVersion = "1.0"
    Case "4.03.00.1096"
        strVersion = "2.0"
    Case "4.04.0068"
        strVersion = "3.0"
    Case "4.04.0069"
        strVersion = "3.0"
    Case "4.05.00.0155"
        strVersion = "5.0"
    Case "4.05.01.1721"
        strVersion = "5.0"
    Case "4.05.01.1998"
        strVersion = "5.0"
    Case "4.06.02.0436"
        strVersion = "6.0"
    Case "4.07.00.0700"
        strVersion = "7.0"
    Case "4.07.00.0716"
        strVersion = "7.0a"
    Case "4.08.00.0400"
        strVersion = "8.0"
    Case "4.08.01.0881"
        strVersion = "8.1"
    Case "4.08.01.0810"
        strVersion = "8.1"
    Case "4.09.0000.0900"
        strVersion = "9.0"
    Case "4.09.00.0900"
        strVersion = "9.0"
    Case "4.09.0000.0901"
        strVersion = "9.0a"
    Case "4.09.00.0901"
        strVersion = "9.0a"
    Case "4.09.0000.0902"
        strVersion = "9.0b"
    Case "4.09.00.0902"
        strVersion = "9.0b"
    Case "4.09.00.0904"
        strVersion = "9.0c"
    Case "4.09.0000.0904"
        strVersion = "9.0c"
End Select

Wscript.Echo strVersion

Incidentally, don’t be deterred by the size of this script; most of the code involves converting the possible registry values. As you’re about to see, the script itself is extremely simple.

How simple? Well, we start out by defining a constant named HKEY_LOCAL_MACHINE and setting the value to &H80000002; we’ll use this constant to tell the script which registry hive to connect to. We then use this code to bind to the WMI service on the local computer:

strComputer = "."

Set objRegistry=GetObject("winmgmts:\\" & strComputer & "\root\default:StdRegProv")

And yes, like most WMI scripts we could just as easily bind to the WMI service on a remote computer. How? That’s easy; simply assign the name of the remote computer to the variable strComputer. For example, this block of code connects us to the WMI service on the remote computer atl-fs-01:

strComputer = "atl-fs-01" 
Set objRegistry=GetObject("winmgmts:\\" & strComputer & "\root\default:StdRegProv")

After making the connection we assign values to a pair of variables. The variable strKeyPath is assigned the path within the HKEY_LOCAL_MACHINE registry hive; for this script, that happens to be Software/Microsoft/DirectX. Meanwhile, the variable strValueName gets assigned the name of the actual registry value within the DirectX key we want to work with. For this script, that happens to be the Version value.

Once these values are assigned we then call the GetStringValue method in order to read the DirectX version from the registry:

objRegistry.GetStringValue HKEY_LOCAL_MACHINE, strKeyPath, strValueName, strValue

Nothing too fancy there: we simply call GetStringValue, passing – in order – the constant HKEY_LOCAL_MACHINE, the “in” parameters strKeyPath and strValueName, and the “out” parameter strValue. What’s all this in-and-out stuff? Well, an in parameter is a value you supply to a method; by contrast, an out parameter is a value that a method returns to you. In other words, we give GetStringValue a variable name – strValue – and, in return, GetStringValue will assign to that variable the value read from the registry. For example, after we execute the GetStringValue method on our test machine, strValue will be equal to 4.09.00.0904.

Of course, we don’t really want strValue to be equal to 4.09.00.0904; instead, we want it to be equal to the “real” version of DirectX (9.0c). To convert the 4.09.00.0904 to a version number we’re all more familiar with we simply set up a Select Case statement that examines the value read from the registry and then assigns the more-commonly-used version number to a variable named strVersion. For example, here’s the code that converts 4.09.00.0904:

Case "4.09.00.0904"
    strVersion = "9.0c"

All that’s left now is to echo back the value of strVersion. See? We told you it was pretty simple.

You know that’s an interesting question: were all those old Tarzan movies and all those old episodes of Gilligan’s Island lying to us when they showed the bad guy getting trapped in quicksand and slowly sinking beneath its inexorable grip? (One interesting property of quicksand is that it only seems to work on bad guys; good guys can always figure a way to get out of it. Also, while quicksand can suck a man down in no time – and, again, it’s always a man, never a woman – it invariably leaves his hat floating on the surface. Go figure.)

To be honest, we don’t know whether they were lying or not. However, considering the fact that almost everything the Scripting Guy who writes this column knows about science and geography he learned from Gilligan’s Island, well, let’s hope they were just taking artistic license. (Which is fine with us. After all, where would the Scripting Guys be without, uh, “artistic license?”)