[HN Gopher] Demoting i686-PC-windows-gnu to Tier 2
___________________________________________________________________
Demoting i686-PC-windows-gnu to Tier 2
Author : ingve
Score : 64 points
Date : 2025-05-26 14:16 UTC (8 hours ago)
(HTM) web link (blog.rust-lang.org)
(TXT) w3m dump (blog.rust-lang.org)
| kstrauser wrote:
| That seems reasonable. If you want to keep building software on
| by now ancient hardware, they'll still give you the tools to do
| it. They're just not going to slow down development for the
| platforms most people use to accommodate it anymore.
|
| For context, that platform had 76K downloads. x86_64-unknown-
| linux-gnu had 135M, or about 1800x more.
| DaiPlusPlus wrote:
| > If you want to keep building software on by now ancient
| hardware, they'll still give you the tools to do it
|
| There are other use-cases, though not exactly popular or
| mainstream, but supposing you need dozens, hundreds, maybe even
| over a thousand currently-supported Windows VMs running off a
| single VM host box: you'll achieve a higher VM density with an
| x86 build of an OS compared to the x64 build; right now the
| only option is some cut-down custom build of Windows 10
| Embedded x86[1]
|
| ...though I'm sure no-one outside of a DEFCON or CCC meetup's
| drinking-game will ever find themselves doing this - just so
| long as I get to see it in a youtube video.
|
| [1] EDIT: Turns out they renamed the (non-CE) NT-based Windows
| Embedded to "Windows IoT" - which annoys me because it's
| perfectly allowed to make a Windows IoT build without any
| networking features enabled - so it'd be like calling Apple's
| iPod Touch as Apple's "iPod iPhone".
|
| ----
|
| I'll admit I'm surprised that "x32" (i.e. AMD64 ISA, but with
| 32-bit pointers) was never supported on Windows, nor exactly
| popular on Linux, because (at least before Electon Apps
| existed) plenty of software really has no business using 64-bit
| pointers, so it makes sense to keep 32-bit pointers; another
| benefit-of-sorts is that if your program has a memory-leak then
| it'll crash once the leak hits 4GB - but with 64-bit pointers
| your process might end-up gobbling hundreds of gigs of RAM
| before the next malloc call fails.
|
| While we're at it, let's also bring back Intel's 21-bit
| NEAR/FAR pointers ("segmented memory") if only to keep Rust
| programmers (and their compiler team) on their toes.
| alerighi wrote:
| True, but, the advantage of using 32 bit pointers to save a
| couple of RAM is not that important, since applications
| typically don't use that much pointers, thus if you half the
| size of them you will save probably a couple of kb of RAM.
|
| Maintaining the support for a different architecture only for
| that doesn't make a lot of sense, probably the reason it was
| never supported. RAM is cheap these days so...
| weinzierl wrote:
| _" probably a couple of kb"_
|
| Pointers are everywhere. In real world applications we see
| an increase between a quarter to a third. For example in
| 2016 Mozilla reported 25% increase from 32-bit Firefox to
| 64-bit [1]. Google deemed it necessary to implement pointer
| compression in Chrome to counter the effect. Java also has
| pointer compression.
|
| [1] https://blog.mozilla.org/nnethercote/2016/07/22/firefox
| -64-b...
| alfiedotwtf wrote:
| It's not just a problem for size, don't forget you also
| have to copy bits across busses and several layers of
| cache - and doing so is not instant!
|
| And that's just thinking in terms of logical RAM. You
| then have translation tables which pointers need to index
| into - having them larger makes indexing even more
| slower, compounding the issue
| karmakaze wrote:
| It can be important, but also there are ways of using
| compressed pointers on 64-bit systems for similar savings.
| Search/prompt "What modern systems or programming/runtime
| environments use compressed pointers of some form?" for
| details.
| kstrauser wrote:
| So, the Rust team didn't say they wouldn't support it, but
| more that they couldn't. They're don't have in-house experts
| today who are experienced enough with that platform to
| support it efficiently. I'd say that a person or company who
| needs to run thousands of VMs on a single machine would be
| exactly the right one to step up and adopt it as a
| maintainer.
| adgjlsfhk1 wrote:
| the counterpoint is that if you really are memory stressed,
| you shouldn't be using windows.
| SoftTalker wrote:
| Building on a variety of architectures often shakes out bugs
| that might not be evident otherwise. Seems they are deciding
| those will just be ignored, rather than addressed. Security
| researchers might focus on these for potential exploits.
| comex wrote:
| i686-pc-windows-msvc and i686-unknown-linux-gnu are still
| tier 1. Any bugs that show up in i686-pc-windows-gnu but
| neither of the other two are almost certainly MinGW-specific
| jank, rather than anything that could have security
| implications on other platforms.
| flohofwoe wrote:
| 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 wrote:
| 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
|
| Interestingly, Windows on ARM hasn't made it up to Tier 1 yet.
| hulitu wrote:
| > 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 wrote:
| Not true. Key point: "Cloud savings"
| ChrisSD wrote:
| 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 wrote:
| Does that end up meaning, in practice, that stable releases
| are never broken, but nightly might be, for a tier 2
| target?
| ChrisSD wrote:
| 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 wrote:
| > 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
| adgjlsfhk1 wrote:
| 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 wrote:
| 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/dpao
| liello/rfcs/blob/aarch64tier1/text/38... but we'll see if
| there is enough interest.
| zamadatix wrote:
| 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 wrote:
| 32-bit apps can run natively on 64-bit Windows and are still
| reasonably common.
| flohofwoe wrote:
| 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 wrote:
| 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 wrote:
| 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.
| shdon wrote:
| 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).
| jmclnx wrote:
| _Edit: Seems the article is only for Microsoft Windows, so what
| follows may be a waste of bandwidth :)_
|
| Well I guess this will cause OpenBSD to drop more packages that
| depend upon rust for i386:
|
| https://marc.info/?l=openbsd-misc&m=174696055709421&w=2
|
| FWIW, OpenBSD i386 seems to be on its way to tier 2 anyway:
|
| https://www.openbsd.org/i386.html
|
| I wonder if this could cause NetBSD to start dropping packages
| that need rust on some ports. Right now, due to NetBSD's assume
| Cross-Compiling, I do not think rust is an issue for NetBSD
| (yet).
| mmastrac wrote:
| This makes a lot of sense. Obscure Windows bugs make for unhappy
| developers. Unless you have a local windows setup, the platform
| is challenging to debug. I spent too much time while working at
| Deno on this sort of thing.
| layer8 wrote:
| They are only demoting one of two Windows targets. This isn't
| about Windows, it's about there being no maintainer for one of
| the two toolchains. Unfortunately, it's the open-source
| toolchain that is being demoted.
| josephcsible wrote:
| It's not just one of two. There used to be four Tier 1
| Windows targets, and there are still three: i686-pc-windows-
| msvc, x86_64-pc-windows-gnu, and x86_64-pc-windows-msvc.
| dblohm7 wrote:
| > If you rely on the *-windows-gnu targets and have expertise in
| this area, we would be very happy to have you as a target
| maintainer.
|
| Damn, I'd love to take that on, if only I had the time...
| malkia wrote:
| There is `clang-cl` and `lld` that can link windows executables
| cross platform, targeting "MSVC" without Wine hacks.
| ftco wrote:
| The bigger problem is legal concerns. Shipping MSVC headers
| might violate MS EULA.
___________________________________________________________________
(page generated 2025-05-26 23:02 UTC)