Switching from windows-rs to windows-sys

[est31]

There is a huge amount of churn with the windows crate, see microsoft/windows-rs#1720, even though it is a crate that is supposed to be foundational. We can't follow each windows-rs release. They have said however that windows-sys will have breaking changes less often, and that seems to be the case indeed. Therefore, we should switch to windows-sys.

cc @Osspial who has done the winapi -> windows-rs switch.

[Jasper-Bekkers]

Notice that unfortunately windows-sys doesn't really expose COM objects; instead they define the names for them as *mut c_void, see for example https://docs.rs/windows-sys/latest/windows_sys/Win32/Media/Audio/type.IAudioCaptureClient.html

[MarijnS95]

windows-sys was mainly introduced to combat compile times, but in my experience windows hasn't been nearly as bad since introducing proper feature flags to only compile what you need.

I ended up making the same choice in our gpu-allocator crate for needing access to COM and the desire to rid our code-base of error-prone pointer casts and lifetime/refcount issues.

Now that windows is also promised to slow down on releases this doesn't sound like an actionable issue (at all) anymore.

[est31]

@Jasper-Bekkers I see that is a valid point. It is also great news that the maintainers of the windows crate have promised to slow down the release cadence, thanks @Jasper-Bekkers for filing the issue. I'm not sure what their new target is however. Anything faster than "1 semver breaking release per year" will likely be too much for the ecosystem, and I'm not sure if one semver breaking release per year would not be...

It also seems that they expect this churn to stop in the future, so I hope it is indeed a temporary problem.

I'm closing this issue as it seems to be unlikely we want to use windows-sys.

[SkiFire13]

I found this thread before asking whether cpal would/had considered switching from windows to windows-sys.

windows-sys was mainly introduced to combat compile times, but in my experience windows hasn't been nearly as bad since introducing proper feature flags to only compile what you need.

In my experience windows compile times are kinda misleading. When you compile it only for your crate it will be reasonably fast because you're only enabling the feature flags that your crate needs. However when that crate is used in a larger project that windows crate may be shared by more dependencies which will likely enable different feature flags, and in that case the costs will sum (and in my experience it will be worse than just summing them, it seems it doesn't scale exactly linearly).