@jernej__s @dosnostalgic I’m well aware of DEC’s FX!32. Running 32-bit apps built for cheaper 32-bit x86-32 hardware on pricy 64-bit hardware running 32-bit apps was a bravely doomed strategy, in retrospect. DEC couldn’t do 64-bit with FX!32 (joke: FX!64) because Microsoft couldn’t do 64-bit. (The 1999 Microsoft PDC in Denver describing how easy their planned 64-bit migration was to be was amusing, having then just gone through a 32- to 64-bit OS migration else-platform.)

DEC also had DECmigrate (VEST and TIE, and later AEST and TIE) for migrating apps from OpenVMS VAX to Alpha and from OpenVMS Alpha to Itanium. SimH (which I’ve coincidentally mentioned in a joke recently) works well, as does UTM.

Lots of other platforms gave have or have had emulators or translators.

Among its other weirdnesses, Itanium had a feedback-based translator for executables, which sorta-kinda fits here, to incorporate observed run-time behavior back into the existing executables. Basically, post-linking feedback tuning thst produced different executables. This as the compilers inherently lacked visibility into the run-time memory state and latencies of a particular Itanium processor, and had to guess. One name ror this stuff was OM, and its translatiin escaped me at the time.

Of what I’ve worked with for app (and not system) emulators, Rosetta was both the most transparent, and the most compatible.