macOS Updating third-party apps to 64-bit

[Nermal]

As you all know, 32-bit apps are on life support at the moment. However, all the information that I've seen so far on making apps 64-bit-compatible has been aimed at the original developers (effectively "recompile with a new Xcode").

What about if the developer no longer maintains the app? Several years ago, RISC OS went through the same issue; version 5 dropped support for 26-bit apps, but many of these apps were commercial and didn't have source available. But that didn't stop the community. Tools were available which could disassemble the existing binaries. Other tools would then analyse that source and track down which parts needed to be updated for 32-bit compatibility. You could then tweak the code and reassemble, resulting in a "clean" 32-bit app.

I haven't seen any discussion about applying the same tactics to Mac apps. Admittedly my Intel assembly knowledge is nonexistent, and I haven't developed any Mac apps, but I'm wondering whether this sort of thing is technically possible on the Mac.

It may be that going from 32-bit Intel to 64-bit Intel is completely different than 26-bit ARM to 32-bit ARM; does anyone have any insights into how difficult this sort of thing would be?

For the absence of doubt, I'm not suggesting that anyone actually does this; I'm just wondering whether it's possible.

 

[Sydde]

Here is some useful info. 26-bit ARM code used almost exactly the same instruction set as 32-bit, with the placement of the condition code register being the biggest difference.

x86-64 employs an array of marker prefix bytes to identify 64-bit instructions and adds 7 new GPRs, which means that Apple probably uses the added registers as parameter holders in many function/method calls. Converting 32-to-64-bit code is almost certainly more complicated than revising ARM code from the 26-bit architecture to the 32-bit.

Even converting ARM 32-bit apps to 64-bit is probably easier than the Intel conversion, because while the two instruction sets are different in major ways, the fundamental structure is very consistent.

 

[Nermal]

Thanks. Looks like this probably isn't practical then... if only the developers of abandoned software would release the source!

 

[chown33]

In terms of practicality, a virtual environment is probably the best compromise.

That is, setup a virtualized version of the 32-bit version of Mac OS you want to preserve. When you need it for some old files, run it, and edit the file in that virtual OS. When you don't need the old files, shut down the virtual OS. One nice thing about a virtual OS is it's completely generalized, and indifferent to the app you want to use. That is, the same procedure for setting up and running a virtual OS applies to all apps.

If the files are really important, I'd be looking pretty hard for a replacement app or a way to migrate away.

Maybe if you tell us which 32-bit apps you're stuck on, we can suggest other possibilities. Without knowing specifics of the app(s), the only possible solutions will be generalized ones.

 

[Nermal]

That makes sense. Indeed that's pretty much what Classic was, back in the day.

I'm not thinking about specific apps at this stage; I was just wondering whether this was possible in general. Personally, I'm unlikely to jump to 10.15 immediately.

 

[Emanuel Rodriguez]

Thanks. Looks like this probably isn't practical then... if only the developers of abandoned software would release the source!

It might be worth tracking some of those devs down. Some of them won't mind parting with their source code, especially if the project was abandoned. Some might charge, might not. Worth a shot, though.

 

[AphoticD]

In addition to @Sydde ‘s answer, developers of 32-bit apps also had the option of incorporating calls to Apple’s long-standing Carbon frameworks (and other 32-bit-only legacy libraries) seamlessly within a Cocoa app, this often bridged the gap for compatibility with older Mac operating systems as well as offering some functionality which was never fully reproduced in 64-bit Cocoa.

Unfortunately most of the legacy frameworks like Carbon were not re-written for 64-bit, so even if a 32-bit binary could be recompiled with 64-bit abilities, it is likely that several major framework dependancies for that 32-bit designed app would be broken on our modern 64-bit Mac systems.

I agree with the 32-bit VM solution on a modern system. And for apps which are really ancient, you could also emulate a PowerPC Mac OS X (10.4 or earlier) system using the free QEMU on any x86_64 host.