AndrewEnsley.com

After reading this, check out Part 2: Using WMI for even more info

Introduction

I recently needed to programmatically determine the Operating System my software is running on.  I was amazed at how difficult it was to find reliable, useful information on this subject.  There were bits and pieces here and there, but almost everyone assumed I had some pre-existing knowledge of the process in one manner or another.  Hopefully, this little series will save somebody some time in the future.

The thing that makes this so difficult is that there are almost as many different ways to detect the operating system as there are operating systems!  It's an unbelievably frustrating experience trying to reinvent this wheel, so I'll try to walk through it here.

Strategies

There are 4 basic strategies:

1. Read and parse information from files in the Windows directory.  This is probably the most difficult and least rewarding method.  The files are different for each generation of OS and the format is not guaranteed in almost any case.
2. Read information from the registry.  This method works a little better, but you still have varying locations for the information based on which OS you're dealing with.
3. Use Environment variables.  Nothing is more reliable.  However, it doesn't give you the nitty-gritty detail you might want.  For example: There's no way to detect XP Home vs. XP Professional.
4. Use WMI to query for information about the OS.  This gives you everything you could possibly want all in one shot.  Unfortunately, it's not supported in pre-NT versions of Windows (of course, this is becoming less and less of a problem).

I started with number 1.  After pulling most of my hair out and wanting to punch my keyboard, I moved on to number 2.  That was a dead end too.  I could have made it work, but I didn't have the patience.  I gave number 3 a try and was very happy...  ...until I decided that the specific version of 2000, XP, Vista, and 7 mattered to me.  So I finally ended up with a combination of 3 and 4.

For part 1 of this series, I'm going to focus on number 3, a.k.a. The Easy Way^tm

The Code

The key to everything is the Environment class.  It has everything we need in a property called OSVersion.  However, the information is a little cryptic (mostly a bunch of numbers), so it takes some work to get a "friendly" value returned.

This first method gives us the Operating system architecture as an integer. The environment variable "PROCESSOR_ARCHITECTURE" is either set to "x86" or doesn't exist on 32-bit versions of Windows. It's always set to something other than "x86" on 64-bit versions of Windows.

For something that seems so simple, this can actually be very confusing. There are two important notes about this method:

1. Even though the physical CPU's architecture may support 64-bit operations, this environment variable will always return the architecture of the OS. So 32-bit Windows running on a 64-bit capable processor will return 32-bit. It's a bit of a misnomer, but provides the information we really want anyway.
2. Even though the CPU is 64-bit capable, and the OS architecture is 64-bit, your .Net program could still be running as a 32-bit application. Sometimes, this information is more useful than knowing whether Windows is 32- or 64-bit. To see if your program is actually running in 64-bit mode, check to see if IntPtr.Size == 8. It will be 4 in 32-bit mode and 8 in 64-bit mode.

Now onto the actual Operating System version. The following code is largely based on what I found on the Microsoft Knowledge Base article: How to determine the Windows version by using Visual C#.

Notice that getOSInfo() returns an empty string if it was unable to determine the OS version.

The code should be pretty self-explanatory, and the great thing is that you don't have to reference any special assemblies. Everything is right there in System.

Want even more information? Don't miss Part 2: Using WMI