4 ms·

The question is why do newer versions of Windows break compatibility so badly?

jeremy_wiebe 3y ago
It seems like the Rust team isn't saying that compatibility is broken, just that there is no testing or effort to ensure compatibility. In the end it's similar, but like any project, it comes down to allocation of time and resources. For something like Windows XP, I'd guess the pool of folks interested in targeting it is extremely small.
lambda_garden 3y ago
But why not test? If we don't expect compatibility to break, then it will be little extra effort surely?
- martinky24 3y ago
  This is very naive.
- malcolmgreaves 3y ago
  If you were in this situation yourself, what would you do if you saw a test failure? Is it different from what you'd do if you found it to be a success? If you put it into a tier of support that states "I won't be proactively maintaining compatibility and fixing issues here", then your answer is "nothing." A failing test won't spur you to action, because of the support level. So if the test result doesn't change your behavior, why run the test in the first place?
- kibwen 3y ago
  CI jobs cost money, and every new target has a multiplicative effect on the number of job configurations that need running.
- Tuna-Fish 3y ago
  It's quite a lot of extra effort. The Rust test job is to compile every single public open-source package on the crates.io registry. This is an amazing way to test. But it's also expensive, because that actually takes a lot of machine time.
CuriousCosmic 3y ago
It's not that new versions break compatibility. It's that old versions are missing features that new versions have. Windows is actually astonishingly backwards compatible but the older you want to support in Windows, the more jank your code has to be. Like for example, in the zulip chat (linked in the issue for this change) they mention that the next versions they may drop are those Windows 10 releases prior to May 2019 as that release finally made UTF-8 the standard text encoding and being able to generally assume UTF-8 simplifies a lot of things for developers.
- Longhanks 3y ago
  UTF-8 is still not the standard on Windows, it’s opt-in.
- e4m2 3y ago
  > that release finally made UTF-8 the standard text encoding This is a bit of a reach unfortunately. UTF-16 (most often broken WTF-16) is still the standard text encoding on NT. The manifest change only makes A-suffixed functions always do a "UTF-8 to UTF-16" conversion, instead of the unhelpful "local codepage to UTF-16" conversion. Sure, that's better, but: - Microsoft has expressed no interest in switching the actual underlying encoding to UTF-8, they will likely never do so in NT. - A-suffixed functions only exist for some Win32 API. Newer Win32 functions are defined only taking Unicode strings. All COM, WinRT and native (Rtl/Nt) APIs use Unicode strings as well. The UTF-8 API surface is actually quite small - one might have to step out of the UTF-8 comfort zone in practice. - Performance is being left on the table. Transcoding still has to be done, it would be more beneficial to at least keep it local for optimization purposes. The most trivial, yet still important use case: constant string conversions can't be optimized across DLL boundaries. - Unlike, say, DPI awareness mode, there is no official API to change this behavior at runtime. It has to be done through the manifest, a compiler implicitly embedding such a manifest into every executable it produces is not ideal. TL;DR: It's an improvement, but just barely, so bumping the minimum version just for this "feature" is not worth it IMO. Just bite the bullet and convert to UTF-16 if you have to, it's conceptually simpler and likely faster, too.
  - 3y ago
TillE 3y ago
You can still write code that targets Windows XP and it will run on Windows 11 just fine. There's no compatibility break. The problem is that newer versions of Windows offer plenty of features which make library implementation simpler and/or give better performance. Someone else mentioned some threading/synchronization APIs, which is also the most common non-XP feature I've found in use in various C++ libraries.
mook 3y ago
Given that XP is no_std, it seems plausible that they want to use some newer APIs in the standard library that didn't exist in older versions of Windows?

It seems like the Rust team isn't saying that compatibility is broken, just that there is no testing or effort to ensure compatibility. In the end it's similar, but like any project, it comes down to allocation of time and resources. For something like Windows XP, I'd guess the pool of folks interested in targeting it is extremely small.

lambda_garden 3y ago

But why not test? If we don't expect compatibility to break, then it will be little extra effort surely?

martinky24 3y ago
This is very naive.
malcolmgreaves 3y ago
If you were in this situation yourself, what would you do if you saw a test failure? Is it different from what you'd do if you found it to be a success? If you put it into a tier of support that states "I won't be proactively maintaining compatibility and fixing issues here", then your answer is "nothing." A failing test won't spur you to action, because of the support level. So if the test result doesn't change your behavior, why run the test in the first place?
kibwen 3y ago
CI jobs cost money, and every new target has a multiplicative effect on the number of job configurations that need running.
Tuna-Fish 3y ago
It's quite a lot of extra effort. The Rust test job is to compile every single public open-source package on the crates.io registry. This is an amazing way to test. But it's also expensive, because that actually takes a lot of machine time.

CuriousCosmic 3y ago

It's not that new versions break compatibility. It's that old versions are missing features that new versions have. Windows is actually astonishingly backwards compatible but the older you want to support in Windows, the more jank your code has to be. Like for example, in the zulip chat (linked in the issue for this change) they mention that the next versions they may drop are those Windows 10 releases prior to May 2019 as that release finally made UTF-8 the standard text encoding and being able to generally assume UTF-8 simplifies a lot of things for developers.

Longhanks 3y ago
UTF-8 is still not the standard on Windows, it’s opt-in.
e4m2 3y ago
> that release finally made UTF-8 the standard text encoding This is a bit of a reach unfortunately. UTF-16 (most often broken WTF-16) is still the standard text encoding on NT. The manifest change only makes A-suffixed functions always do a "UTF-8 to UTF-16" conversion, instead of the unhelpful "local codepage to UTF-16" conversion. Sure, that's better, but: - Microsoft has expressed no interest in switching the actual underlying encoding to UTF-8, they will likely never do so in NT. - A-suffixed functions only exist for some Win32 API. Newer Win32 functions are defined only taking Unicode strings. All COM, WinRT and native (Rtl/Nt) APIs use Unicode strings as well. The UTF-8 API surface is actually quite small - one might have to step out of the UTF-8 comfort zone in practice. - Performance is being left on the table. Transcoding still has to be done, it would be more beneficial to at least keep it local for optimization purposes. The most trivial, yet still important use case: constant string conversions can't be optimized across DLL boundaries. - Unlike, say, DPI awareness mode, there is no official API to change this behavior at runtime. It has to be done through the manifest, a compiler implicitly embedding such a manifest into every executable it produces is not ideal. TL;DR: It's an improvement, but just barely, so bumping the minimum version just for this "feature" is not worth it IMO. Just bite the bullet and convert to UTF-16 if you have to, it's conceptually simpler and likely faster, too.
- 3y ago

TillE 3y ago

You can still write code that targets Windows XP and it will run on Windows 11 just fine. There's no compatibility break. The problem is that newer versions of Windows offer plenty of features which make library implementation simpler and/or give better performance. Someone else mentioned some threading/synchronization APIs, which is also the most common non-XP feature I've found in use in various C++ libraries.

mook 3y ago

Given that XP is no_std, it seems plausible that they want to use some newer APIs in the standard library that didn't exist in older versions of Windows?