3 ms·

So I’m totally unfamiliar with x32 but say that there is all kinds of 32bit apps that are just too big for a single person to port to 64bit (or simply too big t

So I’m totally unfamiliar with x32 but say that there is all kinds of 32bit apps that are just too big for a single person to port to 64bit (or simply too big too old) is this a silver bullet of being able to rebuild 32bit apps to run as 64bit ones?! Seems like the kind of thing that OS X desperately needed...

skissane 6y ago
No, that's not what x32 is for. On x86-64, Linux supports legacy 32-bit apps (i386 ABI) and native 64-bit apps (x86-64 ABI). However, the x32 ABI isn't either of those. x32 is actually a hybrid 32-bit/64-bit architecture, that lets you use some of the newer features of x86-64 (such as increased number of registers) while keeping 32-bit memory addresses. The theory behind it is that for apps that don't really need a 64-bit address space, 32-bit pointers consume less RAM than 64-bit ones. Using less RAM can have flow-on performance benefits – you fit more in the CPU cache, etc. While x32 is a nice idea in theory, it never really took-off. It is adding a lot of complexity (a third architecture for distributions to support) in exchange for merely modest performance improvements. And it has nothing to do with backward compatibility – that is the role of the i386 ABI, not the x32 ABI. i386 ABI gives binary backward compatibility, x32 ABI requires a recompile. It might be a little bit easier to port from i386 to x32 than from i386 to x86-64, given the pointers remain 32-bit; however, in practice, people either just stick with the existing i386 ABI binaries, or skip it and make the code changes for 64-bit. > Seems like the kind of thing that OS X desperately needed... Apple didn't have to discontinue 32-bit application support for macOS. They made a commercial decision that doing so would save on engineering resources. It ultimately had a business/financial motivation not a purely technical one. It possibly made their task of implementing x86 emulation on ARM somewhat easier. However, they always could have either (a) invested more to support emulating 32-bit x86 on ARM as well (b) limited x86 emulation on ARM to 64-bit but continue supporting 32-bit on native x86. The fact that they didn't do either (a) or (b) – again, ultimately a business/commercial decision about where to invest, not a technical one. (And the truth is, 32-bit application support isn't completely discontinued. x86-64 macOS still supports running 32-bit code, as demonstrated by the Codeweavers branch of Wine. They removed the 32-bit libraries from the OS, and blocked the execution of 32-bit Mach-O executables, but there still exists an API which applications like Wine can use to manually set up a 32-bit address space and run some 32-bit code in it.)
- scruffyherder 6y ago
  The code weaver approach doesn’t sound like something like hat is accessible to small time people... did they have to build their own thunking layers? Sounds like it’s easier to rebuild as a Win32 and have OS X users use wine then. I know a company the size of Apple can’t be expected to be some kind of stable dev platform like how Microsoft treats Windows where I can still run Win32 stuff from 1993 on Windows 10 x64. Maybe one day Apple might take an interest in the desktop again but it seems so unlikely.
  - skissane 6y ago
    > The code weaver approach doesn’t sound like something like hat is accessible to small time people... did they have to build their own thunking layers? It wasn't easy, no. They had to do two things: 1) Fork clang and extensions to C to support mixed 32-bit and 64-bit address spaces 2) Get a special code-signing entitlement from Apple allowing them to call the API to enable 32-bit code execution (not required if you are okay with disabling SIP) Lots of technical details here: https://www.winehq.org/pipermail/wine-devel/2019-December/156602.html https://www.winehq.org/pipermail/wine-devel/2019-December/15... Yeah, this is a monumental effort that few other than Codeweavers could replicate, and I believe they got some help from Apple engineering to do it. They've open sourced their code, but they aren't upstreaming it into mainstream Wine – having to use a forked C compiler is just a bit too much.

skissane 6y ago

No, that's not what x32 is for. On x86-64, Linux supports legacy 32-bit apps (i386 ABI) and native 64-bit apps (x86-64 ABI). However, the x32 ABI isn't either of those. x32 is actually a hybrid 32-bit/64-bit architecture, that lets you use some of the newer features of x86-64 (such as increased number of registers) while keeping 32-bit memory addresses. The theory behind it is that for apps that don't really need a 64-bit address space, 32-bit pointers consume less RAM than 64-bit ones. Using less RAM can have flow-on performance benefits – you fit more in the CPU cache, etc. While x32 is a nice idea in theory, it never really took-off. It is adding a lot of complexity (a third architecture for distributions to support) in exchange for merely modest performance improvements. And it has nothing to do with backward compatibility – that is the role of the i386 ABI, not the x32 ABI. i386 ABI gives binary backward compatibility, x32 ABI requires a recompile. It might be a little bit easier to port from i386 to x32 than from i386 to x86-64, given the pointers remain 32-bit; however, in practice, people either just stick with the existing i386 ABI binaries, or skip it and make the code changes for 64-bit. > Seems like the kind of thing that OS X desperately needed... Apple didn't have to discontinue 32-bit application support for macOS. They made a commercial decision that doing so would save on engineering resources. It ultimately had a business/financial motivation not a purely technical one. It possibly made their task of implementing x86 emulation on ARM somewhat easier. However, they always could have either (a) invested more to support emulating 32-bit x86 on ARM as well (b) limited x86 emulation on ARM to 64-bit but continue supporting 32-bit on native x86. The fact that they didn't do either (a) or (b) – again, ultimately a business/commercial decision about where to invest, not a technical one. (And the truth is, 32-bit application support isn't completely discontinued. x86-64 macOS still supports running 32-bit code, as demonstrated by the Codeweavers branch of Wine. They removed the 32-bit libraries from the OS, and blocked the execution of 32-bit Mach-O executables, but there still exists an API which applications like Wine can use to manually set up a 32-bit address space and run some 32-bit code in it.)

scruffyherder 6y ago
The code weaver approach doesn’t sound like something like hat is accessible to small time people... did they have to build their own thunking layers? Sounds like it’s easier to rebuild as a Win32 and have OS X users use wine then. I know a company the size of Apple can’t be expected to be some kind of stable dev platform like how Microsoft treats Windows where I can still run Win32 stuff from 1993 on Windows 10 x64. Maybe one day Apple might take an interest in the desktop again but it seems so unlikely.
- skissane 6y ago
  > The code weaver approach doesn’t sound like something like hat is accessible to small time people... did they have to build their own thunking layers? It wasn't easy, no. They had to do two things: 1) Fork clang and extensions to C to support mixed 32-bit and 64-bit address spaces 2) Get a special code-signing entitlement from Apple allowing them to call the API to enable 32-bit code execution (not required if you are okay with disabling SIP) Lots of technical details here: https://www.winehq.org/pipermail/wine-devel/2019-December/156602.html https://www.winehq.org/pipermail/wine-devel/2019-December/15... Yeah, this is a monumental effort that few other than Codeweavers could replicate, and I believe they got some help from Apple engineering to do it. They've open sourced their code, but they aren't upstreaming it into mainstream Wine – having to use a forked C compiler is just a bit too much.