4 ms·

This reads like it only affects the 32-bit target (which tbh is surprising to see supported at all, since afaik there are no more supported 32-bit Windows versi

This reads like it only affects the 32-bit target (which tbh is surprising to see supported at all, since afaik there are no more supported 32-bit Windows versions?)

wtallis 1y ago
Yes, only the 32-bit target, and only the gnu toolchain. Compiling on Windows using the Microsoft toolchain to target 32-bit Windows will still be on the Tier 1 list: https://doc.rust-lang.org/rustc/platform-support.html https://doc.rust-lang.org/rustc/platform-support.html Interestingly, Windows on ARM hasn't made it up to Tier 1 yet.
- hulitu 1y ago
  > Windows on ARM hasn't made it up to Tier 1 yet. Windows on ARM is irelevant. Surface is Microsoft's offering to keep execs away from Apple. And just like Apple, they are toys. All relevant Windows software is x86(-64).
  - malkia 1y ago
    Not true. Key point: "Cloud savings"
- ChrisSD 1y ago
  To be clear, tier 2 targets are still expected to be well supported. It just doesn't require CI to pass after every PR (meaning PRs aren't blocked on fixing tier 2 specific issues). However, the target is officially distributed and target maintainers are still expected to fix any blocking issues before a release. If they can't then it's likely the target will be demoted to tier 3. Windows on ARM couldn't be tier 1 until recently as there weren't Windows ARM github runners. Now that there are I think it likely that it'll be promoted to tier 1.
  - wging 1y ago
    Does that end up meaning, in practice, that stable releases are never broken, but nightly might be, for a tier 2 target?
    - ChrisSD 1y ago
      More or less, yes. It is guaranteed that tier 2 at least builds so they'll be a nightly available every day though it's possible they might have a serious bug. To be honest though that's always a risk for nightlies even with tier 1 targets. Tests don't catch every potential problem (even if they do catch a lot) which is why there is a beta period before a release.
- nikic 1y ago
  > Interestingly, Windows on ARM hasn't made it up to Tier 1 yet. An RFC for that has been submitted recently: https://github.com/rust-lang/rfcs/pull/3817 https://github.com/rust-lang/rfcs/pull/3817
- adgjlsfhk1 1y ago
  the problem with Windows on Arm is CI. Qualcomm cancelled their dev kit, so you run graviton/Ampere VMs, but it's pretty difficult to do automated tests on the hardware that all 5 users have.
  - zamadatix 1y ago
    There are Windows ARM GitHub runners now. I'm honestly not sure the dev kit would have helped, the existing Windows ARM hardware could be had for cheaper - just nobody cared to bother with it. This is looking to go for it though https://github.com/dpaoliello/rfcs/blob/aarch64tier1/text/3817-promote-aarch64-pc-windows-msvc-to-tier-1.md https://github.com/dpaoliello/rfcs/blob/aarch64tier1/text/38... but we'll see if there is enough interest.
zamadatix 1y ago
Windows 10 32 bit Home is supported until October. Some other 32 bit variants will remain in support until ~the end of the decade.
layer8 1y ago
32-bit apps can run natively on 64-bit Windows and are still reasonably common.
- flohofwoe 1y ago
  Yes, and it's good that it is supported for running old apps. But IMHO there is little reason to build new Windows apps as 32-bit executables.
  - layer8 1y ago
    It’s friendly to users running older or LTSC versions (officially supported until 2032) on older hardware and/or in resource-constrained environments (RAM, power efficiency). There’s a large class of programs who are perfectly fine with 2 GB or less.
  - jeroenhd 1y ago
    Though I don't expect Windows targeting tools to leverage it much, using 32 bit pointers can be quite an efficient method to save memory when keeping track of lots of small objects. You're limited by 4GiB of memory per process, of course, but by switching to 32 bit you're practically halving the space spent on pointers. Using smaller pointers also allows for better data locality and better cache efficiency depending on your data layout. If you're not close to hitting 4GiB of RAM, a few free percentage points in performance aren't a bad deal. Microsoft isn't going to deprecate 32 bit application support any time soon, so you may as well take advantage. That said, so few people have need for it that the deprecation into tier 2 support is probably the right choice. Whatever the 32 bit ABI can do, a custom allocator can probably do just as well on x64. Oh, and Office stll comes in 32 bit mode for some reason. If you're building an Office plugin, you may need 32 bit code.
    - flohofwoe 1y ago
      The upside is 32-bit pointers, but the downside is the small register set of x86. Best would be 64-bit ISA with 32-bit pointers, but I don't know if Windows supports such a mode.
shdon 1y ago
Technically there still is, for a few more months. There is a 32-bit version of Windows 10, and that won't end mainline support until October (and then a while of extended support, for those who wish to pay for such).
- deleted 1y ago
  [deleted]

This reads like it only affects the 32-bit target (which tbh is surprising to see supported at all, since afaik there are no more supported 32-bit Windows versions?)

wtallis 1y ago

Yes, only the 32-bit target, and only the gnu toolchain. Compiling on Windows using the Microsoft toolchain to target 32-bit Windows will still be on the Tier 1 list: https://doc.rust-lang.org/rustc/platform-support.html https://doc.rust-lang.org/rustc/platform-support.html Interestingly, Windows on ARM hasn't made it up to Tier 1 yet.

hulitu 1y ago
> Windows on ARM hasn't made it up to Tier 1 yet. Windows on ARM is irelevant. Surface is Microsoft's offering to keep execs away from Apple. And just like Apple, they are toys. All relevant Windows software is x86(-64).
- malkia 1y ago
  Not true. Key point: "Cloud savings"
ChrisSD 1y ago
To be clear, tier 2 targets are still expected to be well supported. It just doesn't require CI to pass after every PR (meaning PRs aren't blocked on fixing tier 2 specific issues). However, the target is officially distributed and target maintainers are still expected to fix any blocking issues before a release. If they can't then it's likely the target will be demoted to tier 3. Windows on ARM couldn't be tier 1 until recently as there weren't Windows ARM github runners. Now that there are I think it likely that it'll be promoted to tier 1.
- wging 1y ago
  Does that end up meaning, in practice, that stable releases are never broken, but nightly might be, for a tier 2 target?
  - ChrisSD 1y ago
    More or less, yes. It is guaranteed that tier 2 at least builds so they'll be a nightly available every day though it's possible they might have a serious bug. To be honest though that's always a risk for nightlies even with tier 1 targets. Tests don't catch every potential problem (even if they do catch a lot) which is why there is a beta period before a release.
nikic 1y ago
> Interestingly, Windows on ARM hasn't made it up to Tier 1 yet. An RFC for that has been submitted recently: https://github.com/rust-lang/rfcs/pull/3817 https://github.com/rust-lang/rfcs/pull/3817
adgjlsfhk1 1y ago
the problem with Windows on Arm is CI. Qualcomm cancelled their dev kit, so you run graviton/Ampere VMs, but it's pretty difficult to do automated tests on the hardware that all 5 users have.
- zamadatix 1y ago
  There are Windows ARM GitHub runners now. I'm honestly not sure the dev kit would have helped, the existing Windows ARM hardware could be had for cheaper - just nobody cared to bother with it. This is looking to go for it though https://github.com/dpaoliello/rfcs/blob/aarch64tier1/text/3817-promote-aarch64-pc-windows-msvc-to-tier-1.md https://github.com/dpaoliello/rfcs/blob/aarch64tier1/text/38... but we'll see if there is enough interest.

zamadatix 1y ago

Windows 10 32 bit Home is supported until October. Some other 32 bit variants will remain in support until ~the end of the decade.

layer8 1y ago

32-bit apps can run natively on 64-bit Windows and are still reasonably common.

flohofwoe 1y ago
Yes, and it's good that it is supported for running old apps. But IMHO there is little reason to build new Windows apps as 32-bit executables.
- layer8 1y ago
  It’s friendly to users running older or LTSC versions (officially supported until 2032) on older hardware and/or in resource-constrained environments (RAM, power efficiency). There’s a large class of programs who are perfectly fine with 2 GB or less.
- jeroenhd 1y ago
  Though I don't expect Windows targeting tools to leverage it much, using 32 bit pointers can be quite an efficient method to save memory when keeping track of lots of small objects. You're limited by 4GiB of memory per process, of course, but by switching to 32 bit you're practically halving the space spent on pointers. Using smaller pointers also allows for better data locality and better cache efficiency depending on your data layout. If you're not close to hitting 4GiB of RAM, a few free percentage points in performance aren't a bad deal. Microsoft isn't going to deprecate 32 bit application support any time soon, so you may as well take advantage. That said, so few people have need for it that the deprecation into tier 2 support is probably the right choice. Whatever the 32 bit ABI can do, a custom allocator can probably do just as well on x64. Oh, and Office stll comes in 32 bit mode for some reason. If you're building an Office plugin, you may need 32 bit code.
  - flohofwoe 1y ago
    The upside is 32-bit pointers, but the downside is the small register set of x86. Best would be 64-bit ISA with 32-bit pointers, but I don't know if Windows supports such a mode.

shdon 1y ago

Technically there still is, for a few more months. There is a 32-bit version of Windows 10, and that won't end mainline support until October (and then a while of extended support, for those who wish to pay for such).

deleted 1y ago
[deleted]