Why do so many developers provide only 64-bit or x64 builds of their software these days?
Doesn't it make sense to only provide 32-bit versions to cover maximum user base? Considering that 64-bit operating systems do support 32-bit apps whereas the inverse isn't true.
If you release for x32, you'd have covered the maximum users whereas if you release for x64, you'd have covered only that block. At least open source developers who intend for maximum coverage or user-base for their apps should support at least 32-bit (if not both).
Below is a great answer post in this regard, credits Ken Gregg on Quora:
Yes, there are a lot of 32-bit programs still being developed/sold/distributed. No, not every program is 64-bit.
64-bit operating systems on 64-bit hardware can run 32-bit applications. And there are lots of computers still running 32-bit operating systems (and will for quite some time). So, an application developer can release one 32-bit product and cover the 32-bit and 64-bit customers. Releasing and maintaining two products, one 32-bit and one 64-bit, incurs some costs. And providing only a 64-bit version leaves all the 32-bit customers in the dust. It is logical and cost-effective to supply only a 32-bit version to cover both groups, as long as the application doesn’t require 64-bit features.
Of course, the embedded systems arena still has tons of new development of 32-bit, 16-bit, and even 8-bit software/firmware. The choice of an embedded microcontroller is based on cost, availability, and features required, so software developed in this realm runs the gamut of bitness.
From what I can tell, the last 32bit x86 CPU, the Pentium 4, was released in 2006. This means that for conventional applications, you're releasing to support a CPU made 17 years ago.
Frankly I doubt any significant amount of the customer base is using that anymore. It's simply not worth the effort to support a CPU that's almost an adult. Also, you get benefits of the increased memory limit which is pretty important.
Yes, even for budget conscious or restricted groups or individuals, at this point cheap 64-bit computers should be ubiquitous. In the US at least you can buy whole piles of 64-bit Core 2 Duo office machines and laptops for almost nothing.
For phones the situation is a bit different. There, extremely low end 32-bit Android phones were still being sold until relatively recently, but those things were so low-end that they’re likely barely usable as anything but feature phones anyway. Apple hasn’t sold a 32-bit phone since the iPhone 5C was discontinued in 2014.
I've recently started to hear the term "manufactured e-waste" and I think that applies here.
One reason is that 32 bits only provides enough address space to use use 4 gigabytes of RAM. If your program is likely to need more than 4 gigs of ram at any point then going 64 bit is the logical thing to do.
Even if it doesn't use that much RAM, it makes no sense to limit yourself to it when it's extremely rare for anyone to use 32-bit systems.
Maybe not no sense, if your targeted userbase is poor or doesn't have easy access to newer components (eg. my high school IT lab or people in countries like mine where everything tech related is just twice MSRP for some reason and people don't make that much money to begin with. Could be capitalism, or import duties, or both) then it might be a worthwhile tradeoff.
The only reason to publish 32bit binaries is that you used to publish them. People on really old hardware that can't update (not so much because they're poor, but more so because of uptime reasons) need the software updated but without any significant changes. Any software package that was initially developed in the last 10 years and targets Windows will almost certainly never consider making a 32bit build.
The oldest 32-bit hardware is nearly 20 years old though. Of course there were 32-bit OS sold after that, but the userbase that is on on 32-bit systems must be so extremely small and most likely on operating systems that aren't supported anyway.
Very few software companies target these kinds of users as their primary audience, and for the few that has these kind of users as a secondary audience I still can't imagine the ROI by developing a second 32-bit version is anything but negative.
Yea, I was more thinking FOSS.
If, like in my hypothetical, you're targeting a poorer userbase then you're probably not looking to make much of a profit.
With all due respect, would a userbase with 15 year old hardware be expecting modern software? I imagine such an audience is also using old versions of word processors and web browsers. I believe they cut off 32 bit in windows 11 so that also isn't a possibilty.
It's not about what the userbase expects, it's about what you're trying to achieve.
My high school was still using xp around a decade ago so you're definitely not wrong though.
MacOS has stopped supporting 32bit altogether a while ago, not sure which version of MacOS or when.
Windows 10 has stopped having 32 bit installations in 2020 according to a quick search.
While I have no problems with 32bit support, machines that can ONLY run 32bit, whether due to OS or CPU are essentially a niche within a niche, even most “legacy” hardware is capable of running 64bit systems.
I may be wrong since I’m not a dev, but I think it amounts to “Why go through all this for probably 1 or 2 users.”
Ngl I was expecting why not more things support ARM when entering this topic.
MacOS dropped 32-bit support with Catalina, which came out in 2019.
Maybe by Windows 14 we can get rid of Program Files (x86) then?
Maybe, Maybe not.
Microsoft does keep some old parts of the OS going, so I can see it still being there, if in a different form.
But by then it's a really long time so it could go either way.
Like System32 replaced System? 😁
I don't think Windows will ever eliminate support for running 32-bit software, so that folder will always exist.
It seems likely to me that at some point the tradeoffs for continuing to be able to natively run 32-bit software will reach a breaking point. At that point, Microsoft may shift 32-bit compatibility over to a light virtualization layer which transparently runs old software and can be automatically downloaded (similar to language packs) for users who need it.
Naming nitpick:
The architectures are called either x86 or x86-64 (which can be reasonably shortened to x64). There is no architecture named x32.
The reason it's called x86 is this: Many decades ago Intel released CPUs named like the 8086, then the 80186, 80286, 80386, 80486 then simply the i586 for the original Pentium (it's the 586, that's why it's the Pentium). These CPUs all shared a common instruction set (the actual base programming atoms in which the CPU is controlled) which is called x86, where the X is a placeholder for "the stuff before the 86" in the product name. Even though Intel no longer names their CPUs this way they still use the same instruction set (with a lot of extra stuff tacked on).
AMD created an instruction set called x86-64 a few decades ago which extends x86 to handle 64bit numbers.
You have opened up a surprisingly deep and girthy can of worms.
AMD calls its architecture AMD64. If you ask Intel, it'll say its 32-bit architecture is called IA-32 (Intel Architecture 32 [bits]), while the 64-bit version is EM64T (Extended Memory 64 Technology) or Intel® 64 (but never IA-64—that's Itanium). And sometimes IA-32e, for reasons that are never fully explained. The name 'x86-64' (give or take a _) seems to have originated with Linux and been adopted by macOS as well; the BSDs use 'amd64', and Windows, somewhat infelicitously, uses 'x64'.
x32 is in fact a real thing, and refers to the use of 32-bit pointers together with the 64-bit instruction set.
Somehow, no mainstream architecture seems to be safe from naming shenanigans—don't even ask about AArch64/Aarch64/A64/ARM64/ARMv8-... or riscv-alphabetsoup.
Yeah I suspected I was floating in and out of what's correct, but hopefully it's still an improvement to OP's understanding!
Debian uses "amd64" for the 64-bit x86-extension architecture, as well. And back in the day when AMD was the only manufacturer producing chips with that architecture, the name was pretty ubiquitous in the Linux sphere, IIRC.
(On the subject of shenanigans, there also used to be a psuedo-distinction between 386-compatible "x86" and Pentium Pro/II+-compatible "i686", since the latter gets you some very nice additional capabilities but can't be executed by 386, 486 or first-gen Pentium cores. Arch used to make a point out of the fact that their binary packages were compiled for i686, compared to more conservative distros which tended to ship slower, more compatible binaries, before the ubiquity of amd64 rendered the consideration moot.)
The amd64 architecture is already a decade old, and processors have continuously added instructions and registers on top of that baseline. To simplify this mess, four microarchitecture levels (so far) have been defined and can be used as compilation targets, to improve performance. SuSe now requires x86-64-v2 and has opt-in v3 binaries. Arch is still targetting v1 but there's concensus on moving to v3 "when it's ready".
Making a 32-bit build of an application isn't always as simple as just changing the build target in your IDE. Behavioral differences in primitive types and memory limitations aside, many modern operating systems (including Windows and macOS) now only run on 64-bit hardware. This means supporting 32-bit builds will lock you out of any newer libraries or APIs they provide, since 32-bit support is often only maintained for backwards compatibility and not new features.
And even when it is as simple as changing the target ISA, you still need to QA an entirely separate build.
None of this effort is worth it just to expand your pool of potential users by a fraction of a percent.
EDIT: Another thing I didn't think about was the ISAs themselves. In the x86 world, the 32-bit ISA has been static for 15 years, and all new instructions since have been made part of x86-64. This gives the compiler fewer options when optimizing the generated assembly, resulting in potentially worse performance or energy efficiency than a 64-bit build even if the app itself has no inherent requirement for gobs of memory or 64-bit numbers.
My free, cross-platform desktop text editor, KeenWrite, only supports 64-bit architectures because it's more effort to support 32-bit:
On the one hand, this is a DRY violation. On the other, it's a lot less work.
“DRY is a pathway to many abilities some consider to be… premature optimization.”
Wow! Superb job done with the PDF tool. The idea of writing the Index/ToC in YAML and linking it to markdown files is cool and interesting.
Here's some reasons why you might want to run / provide an x86-64 application over a 32-bit application:
The average user doesn't really care if the application is 32-bit or 64-bit, and wouldn't really notice any differences (basically by definition) in cases where the limitations of 32-bit applications don't cause serious problems... But also pretty much everything running a modern operating system (modulo weird embedded Linux land, of course) is going to be running on a 64-bit machine, so I'm really not convinced you would be losing out on a huge market of people if you only provide a 64-bit version of your application. I suspect people will supply both in cases where it's easy, where you're a big company releasing a product you want absolutely everybody to have access to it, and in situations where somebody has asked... But in general I think you'd be okay just supplying x86-64 binaries these days?
There's also the matter of going from supporting one architecture to supporting more than one. The 1 to >1 threshold always adds complexity. If you support multiple platforms you already have to do this, but if you're just supporting Windows then you will look at 32bit releases as an unnecessary complication. Even with less-technical aspects, now you need to make sure users download and run the correct version for their computer. You don't want a 64bit customer to accidentally get the 32bit version. If fact, the number of 64bit customers who accidentally download the wrong version will almost certainly outnumber to amount of 32bit users that exist.