It is not a invalid result, it is just that your app is running in compatibility mode. If you include the GUID for Windows 10 today in 2015 then your app is supposed to work without changes on Windows 11 assuming you are not doing undocumented stuff. It is of course impossible to test on Windows 11 now so your app is just supposed to pretend that it is still on 10 which is why the API lies.
IMO, if my application uses only
documented functions and only relies on
documented behavior, there will be
no need for any "compatibility mode" at all! It will continue to work perfectly fine in future Windows versions
without "compatibility" hacks or workarounds – provided that M$ doesn't
intentionally break the
documented behavior, of course. There would be some use case for "compatibility mode", if a
broken application relies on
undocumented behavior (or even bugs) that existed in earlier Windows versions, but not in the current one. But in this case we should rather fix the
broken application than implementing
workarounds that only encourage people to rely on undocumented stuff.
Actually, the "enforced compatibility mode" has great potential to
breaking things. If, e.g., my application relies on the correct
documented behavior of
GetVersionEx(), it will stop working in Windows 8.1. So, following the M$ method, I will need to "fix" my application by adding the required GUID. But on Windows 10 it will break, once again. And I will need to "fix" my application, once again. For every new Windows version I will have to "fix" my application –
again and again!
Without all the "compatibility" mess and if they do
not mindlessly break existing
documented behavior, the very same binary that was originally compiled for Windows XP could still be working perfectly fine in Windows 10.
BTW: If I want to accurately emulate the behavior of Windows N on Windows N+1, there is a solution known for decades -
virtualization.
Your are not really supposed to check the version number anyway, you are supposed to check if a feature exists before using it or whatever fallback mode you might have. Granted, it sucks for logs etc but MS has decided that compatibility for crappy programs is more important than keeping developers happy...
The operating system provides services to the application. So the job of the OS is to
correctly implement these services. If and how the application makes use of these services - the OS doesn't need to care! I decide what I do with the version number in my program. Microsoft's job is to give me the
correct number –
not more,
not less. If the application does something stupid, it's the problem of this application. And it can only be properly fixed inside that particular application. Microsoft's sphere of influence
must end at the application boundary.
Really, you can't punish
every application out there, just because a
few applications do stupid things. If at all, the "compatibility" hacks must be
optional (disabled by default!), so they can be enabled if and only if they are actually needed and/or helpful. Heck, if they think users are too dumb for enabling compat mode themselves, they could have implemented a Blacklist for known "broken" applications.
I use this way to identify the OS Version since Win8/8.1. In case they asl obreak this way I'll do the Windows API way. Until today every Windows Version brings new API commands. A new version has a few new APIs, it is also a try to use LoadLibrary/GetProceAddress to find out what API exist on what OS...
I have been experimenting with this method too. The problem here is: You can only distinguish Windows versions that already existed by the time when you program was compiled. You can
not detect future versions, as you don't know which new API's they are going to add or which NT version the next Windows will have. From this point of view, your solution has the same limitation as the "GUID" workaround.
