| I also wonder what that means. What target would this software be compiled for? Apple Silicon or x86? If x86, then some feasible but difficult approaches exist, such as a translation layer or providing own reverse-engineered APIs. It would be tremendously difficult to achieve practical usability beyond very limited cases. However, by the time it could be done, won't the x86 macOS target be entirely obsolete? If the target is Apple Silicon, it makes even less sense. The instruction set is ARM + Apple's mods which are proprietary. Moreover, they keep iterating on that instruction set and making new software alongside it. What's to stop Apple from using a Rosetta approach to run their M2 code on M1? If they have a translation layer, they don't need backwards compatibility in the instruction set. So reverse-engineering would be extraordinarily hard - like, beyond human capability for a small team with no insider leaks out of Apple. Can this project keep reverse-engineering the instructions fast enough as Apple iterates on the arch? Not in reality. x86 is hard but this is that, and a moving target (pun intended). So... how? EDIT: Upon looking into it more, it looks like they want to use x86 translation layer Darling + open-source APIs. This seems more like running (maybe) basic GUI applications compiled for Apple's x86 targets that do not rely too heavily on the Apple ecosystem's APIs. So more for fun than for robust day-to-day compatibility akin to Rosetta. So I guess then it doesn't matter that it's a dying target, as it's more of a theoretical thing? The idea is nice, I don't want to dismiss it. I think attempting it could be a lot of fun. They're kind of brave to call it a project aim though, I don't think it's wise to set such expectations. |