The question is why do newer versions of Windows break compatibility so badly?
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.
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.
Unicode is not a binary encoding, perhaps you meant UTF-16/WTF-16, which are binary encoding of Unicode?
My post specifically mentions UTF-16 and WTF-16, too. The term "Unicode string" exists and is well established: https://unicode.org/glossary/#unicode_string.
Windows Unicode strings happen to fit this definition, but of course, so would UTF-8 strings. Either way, in Windows's version of reality the definition is narrowed to mean "potentially ill-formed UTF-16LE encoded string", but that doesn't exactly roll off the tongue, so for better or for worse, "Unicode string" is the consistently and widely used Windows-specific nomenclature.
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.
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?
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.