Sometimes the fault is not in our stars but in ourselves

Date:November 30, 2005 / year-entry #367
Tags:other
Orig Link:https://blogs.msdn.microsoft.com/oldnewthing/20051130-16/?p=33153
Comments:    14
Summary: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...

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. Brian Friesen says:
    November 30, 2005 at 11:21 am

    Did you charge him for finding his bug? :)

  2. dave says:
    November 30, 2005 at 12:14 pm

    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:
    November 30, 2005 at 2:48 pm

    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:
    November 30, 2005 at 2:53 pm

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

    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/base/getting_the_system_version.asp

  5. useless says:
    November 30, 2005 at 3:45 pm

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

  6. Chris Conti says:
    November 30, 2005 at 3:55 pm

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

  7. Mike Dunn says:
    November 30, 2005 at 4:16 pm

    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:
    November 30, 2005 at 4:51 pm

    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:
    November 30, 2005 at 5:07 pm

    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:
    November 30, 2005 at 5:19 pm

    "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:
    November 30, 2005 at 6:04 pm

    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:
    November 30, 2005 at 8:25 pm

    I use:

    HKLMSOFTWAREMicrosoftWindows NTCurrentVersionProductName

    or

    HKLMSOFTWAREMicrosoftWindowsCurrentVersionProductName

    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:
    December 1, 2005 at 6:10 pm

    @brian:

    >> 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:
    December 2, 2005 at 2:29 pm

    "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?

    http://www.mustek.com.tw/Download/html/english-xp.html

    :)

Comments are closed.


*DISCLAIMER: I DO NOT OWN THIS CONTENT. If you are the owner and would like it removed, please contact me. The content herein is an archived reproduction of entries from Raymond Chen's "Old New Thing" Blog (most recent link is here). It may have slight formatting modifications for consistency and to improve readability.

WHY DID I DUPLICATE THIS CONTENT HERE? Let me first say this site has never had anything to sell and has never shown ads of any kind. I have nothing monetarily to gain by duplicating content here. Because I had made my own local copy of this content throughout the years, for ease of using tools like grep, I decided to put it online after I discovered some of the original content previously and publicly available, had disappeared approximately early to mid 2019. At the same time, I present the content in an easily accessible theme-agnostic way.

The information provided by Raymond's blog is, for all practical purposes, more authoritative on Windows Development than Microsoft's own MSDN documentation and should be considered supplemental reading to that documentation. The wealth of missing details provided by this blog that Microsoft could not or did not document about Windows over the years is vital enough, many would agree an online "backup" of these details is a necessary endeavor. Specifics include:

<-- Back to Old New Thing Archive Index