Not always true. There's plenty of 32bit code that can't trivially be ported over to 64bit, even if you have the full source for all the dependencies. e.g. maybe the file formats have padding or pointer width assumptions - now you need a compatibility shim whenever loading/saving the files. Maybe the code has implicit padding assumptions, which are not documented anywhere - now you'll get occasional random functionality bugs that are a huge effort to catch and debug.
It is not always a matter of flipping a compile-time switch for the developers, even if they are still around, and have all the source, and all the libraries and whatnot.
For example, on X86_64, the ISA provides additional GPRs that aren't just 64-bit versions of the 32-bit register. For example, rax is the 64-bit version of eax, but IIRC you also have r0-7, for which there is no 32-bit equivalent. Furthermore, the ABI (at least on Windows) specifies a different function calling convention versus X86.
Additionally, I imagine there additional instructions/ops on x86_64 over x86. I dont know how else the cpu would distinguish add %eax, 1 from add %rax, 1, both of which are legal when the cpu is running in 64-bit mode.
I recall seeing a cool talk on how to confuse or crash many debuggers by doing something clever in assembly. The idea is you would write a block of polyglot 32 and 64-bit x86/64 assembly (i.e. binary that is both a valid x86 and x86_64 instruction sequence), switch the cpu from 32 to 64 bit mode at the end of the sequence, then branch back to the start of the block and reinterpret the same instructions as 64-bit rather than 32. You could use this technique to frustrate reverse engineering.
32bit MacOS was never used on x86 as far as I know. And even PPC 32bit was a very small number of machines a very long time ago. Not sure about 32bit iPads and iPhones.
But, I’ve never seen a project using rust on iOS. Does anyone have an example of this?
I guess it’s not open source. :(
In particular, the quicktime runtime / codecs (until quicktime x) was only x86, and various VFX apps on OS X had to write RPC code to communicate with it as a 32-bit process from 64-bit land.
TLDR: No recent Apple OSes support running 32-bit at all.
I only mention it because the timing was a surprise to everyone in the industry.
macOS Mojave 10.14 (released 2018) supports running 32-bit apps.
iOS 10 (released 2016) supports running 32 bit apps.
I would agree that iOS 10 is not recent, in the context of the iOS timeline. I would disagree that macOS Mojave is not recent, given that Apple still has numerous show-stopper bugs in the upgrade process to Catalina.
