Sometimes the fault is not in our stars but in ourselves

An earlier name for Windows Server 2003 was Microsoft Windows .NET Server, and in the final weeks leading up the the product's release, we received the following bug from a beta tester:

When I call the GetVersionEx function on build 3773, the OS name is still reported as "Microsoft Windows .NET Enterprise Server". I have attached a sample program illustrating the bug.

I found this kind of confusing, because the GetVersionEx function doesn't return a human-readable product name. Intriguged, I took a look at the sample program and it wasn't too hard to see where the bug was. The program contained the lines

if ( osvi.dwMajorVersion == 5 && osvi.dwMinorVersion == 2 )
   lstrcpyn(szOS, L"Microsoft Windows .NET", MAX_PATH);

In other words, the program had the incorrect string hard-coded into it.

I reported my findings back to the person who submitted the bug, and the response was "Oops, sorry about that."

Comments (14)
  1. Did you charge him for finding his bug? :)

  2. dave says:

    Another thing that puzzled me was, why was MAX_PATH considered to be a suitable upper limit on the name that marketing assigns to a product?

  3. Chris Conti says:

    Well, how DO you reliably (meaning all the way back to Win95) get the OS name? What about back to NT v.x?

  4. James Moore says:

    I was surprised there is no built in function to do this. All I could find was

  5. useless says:

    It makes no sense to get the os name as a string.

  6. Chris Conti says:

    uh, yeah. At least until you want the string for some utility or asset tracking code.

  7. Mike Dunn says:

    Chris> OSVERSIONINFO and OSVERSIONINFOEX have all the flags that identify the OS, it just take a bit of bit-fiddling to work it out in some cases (eg, you have to look for VER_SUITE_PERSONAL in wSuiteMask to tell XP Pro from XP Home).

  8. Chris Conti says:

    I know about those- the problem is generally future compatibility. Prior to windows 2000, you could take "Windows NT" and add the version number. Now you have to revise and re-release code for every OS version that comes out, just to get the string that’s printed on the front of the box, or in the System Properties dialog/propsheet.

    Admins really don’t like to see software report Windows NT 5.2 if they know that the brand-spankin’ new OS they installed is Windows 2003. Who could’ve guessed that NT 5.1 would have been XP? Or that 6.0 would be Vista (assuming it doesn’t change before it actually ships)?

  9. Dave says:

    For code decisions, it’s better to look at bits or use LoadLibrary to see if what you want is there. But it sure would be nice if Windows could provide a string that was complete, accurate, and matched the marketing name that was sold to the user. For example, where does OSVERSIONINFOEX tell me that the version I have is Media Center Edition? If I show an MCE user that they simply have Windows XP, will they think my program is wrong and lose confidence in its accuracy?

    This is what the SDK recommends:

    "You can also detect which version of the Windows XP Media Center Edition is running by querying the following registry entry:

    HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionMedia CenterIdent

    If the value retrieved is less than 2.0, the version running is Windows XP Media Center Edition (the initial version); if the value is 2.0 or greater and less than 3.0, the version running is Windows XP Media Center Edition 2004; and if it is 3.0 or greater and less than 4.0, the version running is Windows XP Media Center Edition 2005."

    Of course that code would be at the end of a long train of code that would query some combination of GetVersionEx, OSVERSIONINFO,OSVERSIONINFOEX, IsWow64Process, SOFTWAREMicrosoftWindows NTCurrentVersionCurrentType, and SOFTWAREMicrosoftWindows NTCurrentVersionSubVersionNumber.

    All I want is a STRING! Even the CPU makers gave up a few years ago and put one in CPUID to prevent this kind of nonsense.

  10. Chris Conti says:

    "For code decisions, it’s better to look at bits or use LoadLibrary…"

    I completely agree. It’s just annoying that you can’t get an accurate human-readable string for the purposes of, well, being read by a human.

    Not that I would actually label most admins as human, but that’s a different discussion.

  11. AndyC says:

    The easiest way to get the OS name as a string is via WMI, it’s the caption properly of Win32_OperatingSystem.

    Don’t help so much for older versions but should be pretty future proof.

  12. Brian says:

    I use:

    HKLMSOFTWAREMicrosoftWindows NTCurrentVersionProductName



    It’s probably the wrong way to do it (since querying the registry is generally frowned upon) but it works for my use.

  13. mikeb says:


    >> It’s probably the wrong way to do it (since querying the registry is generally frowned upon) but it works for my use. <<

    I’m just waiting of Raymond’s upcoming "Old New Thing" article about how this behavior caused all sorts of compatibility issues.

    I mean, what’s going to happen to your program when MS comes out with the

    HKLMSOFTWAREMicrosoftWindows VistaCurrentVersionProductName

    registry key?

  14. Dave says:

    "I use: HKLM…ProductName"

    That string is non-specific. My XP Pro SP2 system says "Microsoft Windows XP" so to get a complete description you’ll still need to do all the API/registry black magic to add the service pack and modifiers like "Media Center Edition 2005".

    When Microsoft comes out with "Windows Vista Home Theater Edition 2007" we’ll be back editing strings and spelunking new API/registry values our programs can avoid looking dumb to the user who knows what version of Windows they bought.

    BTW, Brian, you didn’t write this piece of software did you?


Comments are closed.

Skip to main content