Whoever can make a compatibility layer that successfully translates x86/64 to arm and vice versa and make it widely available will be a major player in the market. Valve has already somewhat done something similar with proton and Apple with Rosetta 2.
Apple developed it as a stopgap. In the Windows world x86/64 will be around for a long long time. Not sure if anyone is willing to support something like that for the next 10 years.
Proton and Rosetta 2 are two totally different beasts.
One allows windows programs to run on non-windows hosts and one translates x86 to Arm.
I’m not aware of Proton doing anything like Rosetta 2 and if it did Steam would have probably used an Arm chip in their Steam Deck instead of an x86.
Maintaining 2-way compatibility doesn’t seem like an important goal. One way, x86->Arm, sure but not Arm->x86. Apple clearly sees x86 as a dead end for its own product lines and we will see if the rest of the industry follows suit over time. Of course there is a ton tied up in x86 but aside from legacy apps or games I don’t have much need of x86 in my life.
Even the servers I run are trending towards Arm due to the power savings. AWS graviton stuff is like ~25-30% cheaper than x86 last I looked
I understand proton isn’t the same thing, it was just an example of a compatibility layer…and how would a bidirectional compatibility layer not be beneficial? X86 in servers may be going away and even that’s debatable, but x86 isn’t going anywhere in the consumer space. Graviton chips are great, but they’re useless if there’s no viable way to translate those x86 legacy applications over to ARM without breaking the bank until your business is ready to transition the workload to ARM.
Amazon was working on a compatibility layer specifically for this purpose, however I suspect they’ve given up because they’ve slowly added Intel and AMD chipsets back into their general purpose ec2 class for newer generations and there hasn’t been a single word about compatibility with graviton other than just use arm based workloads.
You just can’t move to ARM because it’s cheaper, that’s just not going to work. You need to make the effort to move away from x86 and adopt applications that are arm native before making that jump. With a compatibility layer it doesn’t matter, that’s where the money is, if I can build a compatibility layer that translates an x86 binary to an arm binary, then I can move those workloads to the cheaper and more efficient server class.
It’s a different problem under the same name. You’re comparing apples to oranges by comparing WINE and Rosetta.
WINE (as I understand it) explicitly does its best to maintain the instructions and basically just implements functions that are missing.
Rosetta actually changes out every instruction (and presumably has to do a WINE-like thing as well to handle dynamically linked code, though in theory this is more of a 1-to-1 mapping since you’re not swapping OSes).
if there’s no viable way to translate those x86 legacy applications over to ARM
For a properly written application that doesn’t have a lot of third party binary dependents… This really shouldn’t be that big of a job. You just recompile the code on ARM, test, and fix any bugs.
I’d speculate that most of the time this stuff comes up like: “this was written for Windows with some very specific Microsoft libraries/tech in mind and we want to run it on Linux and ARM as cost cutting measures.”
Granted, it’s not unusual for a large enough code base to contain some code that wasn’t written in an architecture neutral way/does some shady stuff.
I’m not comparing Rosetta and proton…I’m just using them as examples of compatibility layers that make their products viable. I frankly don’t give a shit about the inner workings of Rosetta or proton, but thanks for clarifying I guess.
I guess it depends on how you define “real processing power”. I run Windows on Arm on my Mac Studio through Parallels. I installed Steam and played Civ 4 and it’s great. Sure, it’s an old game but it runs smoothly.
It’s gotta be Microsoft building it into Windows. The Apple Silicon transition wouldn’t have been nearly as smooth if people had to pay for, say, CrossOver or something to use their Intel apps. And the tepid response to the ARM Surface models makes me think that it’s a must, despite the UWP dream.
The good news is that Rosetta 2 shows it can be done extremely well!
I could be wrong but that might be Linux only. Windows and MacOS both have their own proprietary compatibility layers, but Windows had shit support for theirs for years which hurt their reputation badly.
Whoever can make a compatibility layer that successfully translates x86/64 to arm and vice versa and make it widely available will be a major player in the market. Valve has already somewhat done something similar with proton and Apple with Rosetta 2.
Apple developed it as a stopgap. In the Windows world x86/64 will be around for a long long time. Not sure if anyone is willing to support something like that for the next 10 years.
Proton and Rosetta 2 are two totally different beasts. One allows windows programs to run on non-windows hosts and one translates x86 to Arm.
I’m not aware of Proton doing anything like Rosetta 2 and if it did Steam would have probably used an Arm chip in their Steam Deck instead of an x86.
Maintaining 2-way compatibility doesn’t seem like an important goal. One way, x86->Arm, sure but not Arm->x86. Apple clearly sees x86 as a dead end for its own product lines and we will see if the rest of the industry follows suit over time. Of course there is a ton tied up in x86 but aside from legacy apps or games I don’t have much need of x86 in my life.
Even the servers I run are trending towards Arm due to the power savings. AWS graviton stuff is like ~25-30% cheaper than x86 last I looked
I understand proton isn’t the same thing, it was just an example of a compatibility layer…and how would a bidirectional compatibility layer not be beneficial? X86 in servers may be going away and even that’s debatable, but x86 isn’t going anywhere in the consumer space. Graviton chips are great, but they’re useless if there’s no viable way to translate those x86 legacy applications over to ARM without breaking the bank until your business is ready to transition the workload to ARM.
Amazon was working on a compatibility layer specifically for this purpose, however I suspect they’ve given up because they’ve slowly added Intel and AMD chipsets back into their general purpose ec2 class for newer generations and there hasn’t been a single word about compatibility with graviton other than just use arm based workloads.
You just can’t move to ARM because it’s cheaper, that’s just not going to work. You need to make the effort to move away from x86 and adopt applications that are arm native before making that jump. With a compatibility layer it doesn’t matter, that’s where the money is, if I can build a compatibility layer that translates an x86 binary to an arm binary, then I can move those workloads to the cheaper and more efficient server class.
It’s a different problem under the same name. You’re comparing apples to oranges by comparing WINE and Rosetta.
WINE (as I understand it) explicitly does its best to maintain the instructions and basically just implements functions that are missing.
Rosetta actually changes out every instruction (and presumably has to do a WINE-like thing as well to handle dynamically linked code, though in theory this is more of a 1-to-1 mapping since you’re not swapping OSes).
For a properly written application that doesn’t have a lot of third party binary dependents… This really shouldn’t be that big of a job. You just recompile the code on ARM, test, and fix any bugs.
I’d speculate that most of the time this stuff comes up like: “this was written for Windows with some very specific Microsoft libraries/tech in mind and we want to run it on Linux and ARM as cost cutting measures.”
Granted, it’s not unusual for a large enough code base to contain some code that wasn’t written in an architecture neutral way/does some shady stuff.
I’m not comparing Rosetta and proton…I’m just using them as examples of compatibility layers that make their products viable. I frankly don’t give a shit about the inner workings of Rosetta or proton, but thanks for clarifying I guess.
FEX-Emu is basically that. They’re still in an early state but they showed Sonic Mania running perfectly a few days ago.
Here is an alternative Piped link(s):
Sonic Mania running perfectly
Piped is a privacy-respecting open-source alternative frontend to YouTube.
I’m open-source; check me out at GitHub.
Windows on ARM is a thing, it will run x86 binaries.
Gord forbid those binaries want to do any actual work though…
I don’t follow?
Windows on ARM will run x86 binaries. But if these binaries require any real processing power, they choke or run really really slowly.
I guess it depends on how you define “real processing power”. I run Windows on Arm on my Mac Studio through Parallels. I installed Steam and played Civ 4 and it’s great. Sure, it’s an old game but it runs smoothly.
Someone should revive transmeta and gear it towards arm.
It’s gotta be Microsoft building it into Windows. The Apple Silicon transition wouldn’t have been nearly as smooth if people had to pay for, say, CrossOver or something to use their Intel apps. And the tepid response to the ARM Surface models makes me think that it’s a must, despite the UWP dream.
The good news is that Rosetta 2 shows it can be done extremely well!
Isn’t that just box64/box86
I could be wrong but that might be Linux only. Windows and MacOS both have their own proprietary compatibility layers, but Windows had shit support for theirs for years which hurt their reputation badly.