[0]: https://doc.rust-lang.org/nightly/rustc/platform-support.htm...
For all intents and purposes Rust is dropping support for anything bellow Windows 10.
It is suggested in the MCP that a new target can be created for older versions of Windows if members of the community will step up to support it.
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.
Windows XP has been EOL for 9 year already[1], the vast majority of developer don't care about it. And if you happen to be a Rust developer who care about Windows XP you can either stick to an older version of the Rust compiler that still supports it. If you can afford to use a 22-years old OS that hasn't received patches for the past decade, you can probably afford to use an older Rust compiler…
[1]: https://learn.microsoft.com/en-us/lifecycle/products/windows...
And that's perfectly fine. Windows 8.1 is unsupported by Microsoft since early this year, and all older releases were already unsupported.
So, no, the executable code is not the same on XP or 11.
The main effect is to split out Windows 7 and Windows 8 as their own targets, such that
> it also leaves open the door for new targets that can commit to broader support
And thus
> Individuals or organisation(s) who can commit to providing some level of legacy testing and support should go through the normal process for creating new targets.
Feel free to apply.
More likely it's that they have to keep running CI pipelines on those machines, and that's painful the older the OS gets.
I don't think they always emit code that looks the same, otherwise Windows wouldn't have that awesome compatibility mode in their binaries, where you could run a Win10 binary as if it's a WinXP one.
The MCP they're referring to goes into some detail about what's likely to happen. Older versions of Windows could still be community-supported if someone is willing to do so.
They are dropping tier 1 support for Win 7 and Win 8. That means they are no longer going to guarantee that the project builds on those platforms and passes all tests via CI.
As long as it is feasible they will probably keep CI runs for those platforms and if interested parties step up and provide sufficient maintenance support, it will remain tier 2. i.e a guarantee that it builds on those platforms via CI but not necessarily that all features are supported and guaranteed via passing tests.
If interested parties can provide sufficient maintenance that all tests continue passing, it will be tier 1 in all but name. However the rest of the development community won't waste their time with issues like Win 7 and 8's partial support for UTF-8.
And once CI stops being feasible for the compiler team to host, it'll drop down to tier 3. If there's sufficient interest from the community towards maintaining these targets, in practice you should see comparable support to with tiers 1 or 2 however now any CI will be managed externally by the community and the compiler team will stop worrying about changes that could break compilation on those targets.
TLDR: They aren't saying "it'll no longer work" but rather "if you want it to stay maintained for these targets, you have to pitch in dev hours to maintain it and eventually support the infrastructure to do this because we don't see a reason to continue doing this". So if you care for these targets, you'll have to contribute to keep it maintained.
[1]: https://github.com/rust-lang/compiler-team/issues/651
[2]: https://doc.rust-lang.org/rustc/target-tier-policy.html
PS: Good job Microsoft, receive our acknowledgment. Say hello to the busy telemetry guys. /s
It's certainly bound to happen someday. Rust has a lower bound on official support for every OS, not just Windows. For example, Rust doesn't support compiling for Linux kernels older than 2012.