Hacker News Reader

Comment by richardwhiuk | Hacker News Reader

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.

View on HN

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

Usually the backwards compatibility is good enough, that updating to declare support for it has almost no positive gain.

(Even more so where updating to explicitly support the new version means dropping old versions.)

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.

True that this is annoying, but there is a solution. https://stackoverflow.com/a/25986612/82294

Now we just have to wait until that method gets abused enough by devs and microsoft ends up spoofing that too.

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.

> Since you cannot predict the UUID for future Windows versions, you cannot pretend to be compatible with them.

Until a clueless product manager tells you to just iterate through all possible UUIDs to check :)

If I had a dollar every time I had to explain this to a PM or a CISO (!!)...

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

Can’t you use build number for Windows?

Reply on news.ycombinator.com