Windows 8.1 detection

[Anders]

Originally Posted by LoRd_MuldeR

...and give invalid result.

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.

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...

[LoRd_MuldeR]

Originally Posted by Anders

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.

Originally Posted by Anders

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.

Originally Posted by th_mi

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.