Add windows-version crate

[kennykerr]

Getting operating system version information simply and reliably is a challenge given the sordid history of versioning APIs on Windows. A simple mechanism that does not require application manifest files is desirable in many instances, particularly for Rust apps that don't necessarily build with Visual Studio and all of its build and packaging conveniences. Here's a simple example:

use windows_version::*;

fn main() {
    println!("Current version: {:?}", OsVersion::current());

    if is_server() {
        println!("Running on a Windows Server release.");
    }

    if OsVersion::current() >= OsVersion::new(10, 0, 0, 12345) {
        println!("Can use a feature available on this version or later.")
    }
}

[kennykerr]

Mainly unsure whether we need something a little less wordy than if Version::new(10, 0, 0, 12345).ge() { ...

Perhaps a helper function like this: if current_ge(10, 0, 0, 12345) {

[ChrisDenton]

Looks cool!

I suspect the two most common use cases for this would be

• Diagnostic purposes (e.g. reporting the version in bug reports)
• Testing if some feature/behaviour can be replied up

I think the former is sufficiently covered by Version::current.

Is there any reason not to implement Ord here? Version::current() > Version::new(10, 0, 0, 12345) would seem nice to have. Especially with some nice const aliases in place of Version::new (not necessarily defined in this crate).

[riverar]

I think I would prefer more verbose names, favoring the clarity that brings over optimizing keystroke count.

OSVersion::is_greater_than(...)
OSVersion::is_less_than(...)
OSVersion::is_at_least(...)

[kennykerr]

The derived implementation of Ord matches what I need:

https://doc.rust-lang.org/stable/std/cmp/trait.Ord.html#derivable

So that simplifies things.

In terms of verbosity, you can use the Ord and PartialOrd trait-provided methods explicitly to make things explicit if needed.

[damyanp]

Windows usually discourages developers from using version checks to determine feature availability. Is there a reason why the Rust APIs should be any treated any differently from other platform APIs?

[riverar]

Windows usually discourages developers from using version checks to determine feature availability. Is there a reason why the Rust APIs should be any treated any differently from other platform APIs?

The lack of robust (or any) feature detection capabilities in Windows makes that advice impractical.

[ChrisDenton]

This looks good to me. I have a few thoughts but nothing that I feel should block merging this.

[tim-weis]

The lack of robust (or any) feature detection capabilities in Windows makes that advice impractical.

We have

• Run-time dynamic linking (alongside delay-loaded DLLs)
• IUnknown::QueryInterface for COM and the WinRT
• ApiInformation for the WinRT

I'd used either of the above for feature detection, and things worked out as advertised.

@riverar Do you have an example where none of the above can be used or report unreliable results? I'm genuinely curious.

[riverar]

@tim-weis Sure!

• An example where I workaround a bug across supported operating systems https://github.com/File-New-Project/EarTrumpet/blob/d6d9f6130178eec3d9d5a5fbcd19a91881966629/EarTrumpet/UI/Themes/Manager.cs#L24-L42
• An example where I check if I can use rounded corner features https://github.com/File-New-Project/EarTrumpet/blob/d6d9f6130178eec3d9d5a5fbcd19a91881966629/EarTrumpet/Extensions/WindowExtensions.cs#L32-L36
• An example where I light up the ability to move audio sessions between devices, introduced in RS4+ https://github.com/File-New-Project/EarTrumpet/blob/d6d9f6130178eec3d9d5a5fbcd19a91881966629/EarTrumpet/UI/ViewModels/AppItemViewModel.cs#L39C2-L40
• An example where I have to nudge our flyout window to align with UI changes in Windows 11 https://github.com/File-New-Project/EarTrumpet/blob/d6d9f6130178eec3d9d5a5fbcd19a91881966629/EarTrumpet/UI/Views/FlyoutWindow.xaml.cs#L169-L173
• An example where I have to workaround a regression where the audio team mistakenly changed some WinRT interface/class IDs (then changed them back) across OS versions https://github.com/File-New-Project/EarTrumpet/blob/d6d9f6130178eec3d9d5a5fbcd19a91881966629/EarTrumpet/Interop/Helpers/AudioPolicyConfigFactory.cs#L11

We might be able to replace some of these checks with error handling and some QIs but that's more work for no value.

[kennykerr]

LoadLibrary and QueryInterface are both great techniques to use and in many cases that's all that you need, but as @riverar points out there are cases where that is insufficient.