13 ms·

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 vers

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.

dietrichepp 6y ago
True that this is annoying, but there is a solution. https://stackoverflow.com/a/25986612/82294 https://stackoverflow.com/a/25986612/82294
- gruez 6y ago
  Now we just have to wait until that method gets abused enough by devs and microsoft ends up spoofing that too.
  - derefr 6y ago
    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.
    - cesarb 6y ago
      > 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.
      - LambdaComplex 6y ago
        > 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 :)
        anonexpat 6y ago
        If I had a dollar every time I had to explain this to a PM or a CISO (!!)...
      - flingo 6y ago
        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.
- asveikau 6y ago
  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.)
wolrah 6y ago
> 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.
- klodolph 6y ago
  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.
- toast0 6y ago
  > 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.
- richardwhiuk 6y ago
  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.)
numpad0 6y ago
Can’t you use build number for Windows?
deleted 6y ago
[deleted]

dietrichepp 6y ago

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

gruez 6y ago
Now we just have to wait until that method gets abused enough by devs and microsoft ends up spoofing that too.
- derefr 6y ago
  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.
  - cesarb 6y ago
    > 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.
    - LambdaComplex 6y ago
      > 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 :)
      - anonexpat 6y ago
        If I had a dollar every time I had to explain this to a PM or a CISO (!!)...
    - flingo 6y ago
      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.
asveikau 6y ago
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.)

wolrah 6y ago

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

klodolph 6y ago
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.
toast0 6y ago
> 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.
richardwhiuk 6y ago
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.)

numpad0 6y ago

Can’t you use build number for Windows?

deleted 6y ago

[deleted]