Skip to main content
Home Forums 68kMLA Binary recompilation from 68k to OS X - why not? — #5
Post #5 by Gorgonops
Source Forum68kMLA
CategoryDevelopment
Post DateSat, 8 Sep 2012 - 23:16
Original URLhttps://68kmla.org/bb/threads/binary-recompilation-from-68k-to-os-x-why-not.26170/
Post
Re-compiling static binaries for one CPU architecture into binaries for another is a rarely-used emulation strategy for a number of reasons. Issues about API translation aside, machine code targeting a CPU directly simply isn't particularly analogous to most compiled languages; CPUs are complicated state machines with their own unique particulars regarding register layout, instruction behavior, quirks, etc, so it's usually necessary to emulate the behavior of said state machine to some degree or another. Even emulators that employ dynamic recompilation techniques generally don't produce code which constitutes a full-up "translated binary". They usually resort to translating and caching snippets into a sort of psuedo-code that is still ultimately executed via a "CPU engine". The translation step "just" speeds things up by eliminating the need to repeatedly perform steps like instruction decoding. There have been some OSes requiring emulation as a core service that have incorporated the ability to cache and save "blobs" of translated code for future use... off the top of my head I'm pretty sure that several IBM mainframe OSes do it, but it's still not strictly a "recompiled binary".

It is of course possible to use a disassembler on a binary, produce a version of it composed of assembly language commands, and run that through a "cross-assembler" targeting another CPU, but that rarely works with non-trivial software. Your disassembler has to be smart enough to figure out all the external library calls and translate them sensibly, it has to be able to accurately distinguish what parts of the binary are actually "code" and what parts are "data"... etc. For something like a classic Mac program that is intimately interwoven with the ROM and OS it's just not likely to work for any real-world software.

That all aside, if what you want is an API translator that works with a classic Mac binary and makes it "native", in the sense that it runs without directly requiring the CPU emulator to execute a complete copy of the MacOS such a thing already exists. ARDI Executor is/was a system for emulating a significant subset of the Mac Toolbox and OS APIs to a sufficient degree to run at least some Classic Mac software on Windows or Linux. (It's basically analogous to how WINE for UNIX systems allows at least some Windows programs to successfully appear to run as native X11 applications.) The source code for it is available, so in principle at least you could port either the Windows API or X11 version of it to run on Carbon/Cocoa instead. Executor displays Mac programs running on it on their own "Desktop", but I imagine with some work you could figure out how to make the emulated programs run "seamlessly", IE, on a transparent desktop intermixed with other windows. If you were willing to put in the work to make it happen then you could then take the Mac application you want to run and package it in an application bundle with your modified version of Executor, configured so double-clicking on the icon would start an Executor session dedicated to running the emulated program.

(I've seen WINE for OS X packaged into an App bundle to run a single dedicated Windows .EXE, so it's not a unique idea.)

The code is there if you really want to hack on it.

mp.ls