Note that this is how Windows has worked since 2013.
If you ask what version of Windows you are running, for example with GetVersionEx, Windows will report Windows 8.0. This is true unless your application marks compatibility with a newer version in its manifest, at which point Windows will report whatever the newest version in your manifest is, or whatever version Windows actually is, whichever of the two is older.
It's kind of annoying from an analytics perspective, because you need to upgrade the manifest (and thus the compatibility) to find out how widely adopted a version is, so you can find out if how much effort it's worth putting into validating it as a platform.
> so you can find out if how much effort it's worth putting into validating it as a platform.
I don't understand the logic here. We're talking about the new version of your target OS. You will presumably always need to support it eventually.
IMO if you're large enough to have a testing and validation process at all, you should be including at least the public beta builds in those tests.. By the time it hits RTM if you don't at least know if your software works you're doing it wrong.
Also, if your software is regularly breaking with OS releases and you're not doing something that requires you to be deep in the internals, you're almost certainly doing something significantly wrong and should figure out what that is. The only software I consistently experience breakage with on updates is also the one where their tech support insists that we're being paranoid for refusing to give their users local admin privileges just to run it. I don't think for a second that's a coincidence.
> I don't understand the logic here. We're talking about the new version of your target OS. You will presumably always need to support it eventually.
Maybe not, you might be able to skip a version that had poor adoption. Windows ME, Windows Vista, IE7 and TLS 1.1 never had a very high market share, because people put off updating so long that better things came along.
It’s nice to be able to choose schedules and prioritize work based on metrics. There’s also the fact that you could e.g. drop support for Windows 8.0 if you find out that only 0.1% of your users were using it.
There's an ultimate future-proof solution, though: just generate, in a loop, a series of assemblies that each purport compatibility with Windows ABI vX.Y.Z; spawn those in a separate process; and get them to return what version of Windows they perceive. Once the number stops going up, that's the version you're on.
No real way to get around that without misinforming fresh, valid applications.
> just generate, in a loop, a series of assemblies that each purport compatibility with Windows ABI vX.Y.Z
The Microsoft developers already thought of that trick. What you declare is not compatibility with "Windows ABI vX.Y.Z"; you declare compatibility with an UUID which represents that Windows version. That is, if you're compatible with Windows 8 you say "I'm compatible with 4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38", if you're compatible with Windows 8.1 you say "I'm compatible with 1f676c76-80e1-4239-95bb-83d0f6d0da78", and so on. Since you cannot predict the UUID for future Windows versions, you cannot pretend to be compatible with them.
Is there any API you can go through to get the UUID of the current ABI, all the ones seen by the system, or all of the ones for each windows ABI without network access?
Trivially, you grab the UUIDs from a server somewhere. A smarter trick is to get these UUIDs from the system you're running on.
There used to be some configurations that had kernelbase.dll but not kernel32. (Windows phone used to be like that, maybe windows on arm?) I would consider checking for ntdll instead of kernel32. (Or kernelbase if kernel32 gets file not found.)
This one hit met pretty good a while ago. I had to know if we are running on Windows 8 or Windows 10 and it turned out to be very difficult finding that out.
If you ask what version of Windows you are running, for example with GetVersionEx, Windows will report Windows 8.0. This is true unless your application marks compatibility with a newer version in its manifest, at which point Windows will report whatever the newest version in your manifest is, or whatever version Windows actually is, whichever of the two is older.