I think you'd be surprised at how many businesses have proprietary applications that their resource stretched & budget starved IT orgs would not want to update.

Consumers probably less so but businesses will definitely care. Translation might be an option for some. However, Rosetta currently only supports limited translation [0].

[0] - https://developer.apple.com/documentation/apple-silicon/abou...

i bet if there is an arm version of the office suite it will be a no brainer. I've seen tons of stuff soley on ms office and maybe a thick client for an erp, which can be run via citrix or other app-v tech

> I think you'd be surprised at how many businesses have proprietary applications that their resource stretched & budget starved IT orgs would not want to update.

Written in assembly language?

Written in VB5. Or in C, but we're not sure where to find the source. Or expecting to be compiled by a 16-bit compiler and run in a DOS box. Or written in some off-brand interpreted language, and the interpreter only runs on x86. Or...

Finding the source isn't free. Finding the archived compiler isn't free. Finding a machine that still can run the compiler isn't free. Re-writing the app isn't free.

Doesn't dynamic binary translation cover these cases? It can't be that performance sensitive if it's written it VB5 and running on modern hardware.

It might. But if you've got a VB5 program that you're still running, are you the kind of person who knows about binary translation? Or do you just say "I'd better keep buying x86 and running Windows forever"?

At the low level you don't know what instruction sets are. At medium to high level you know that despite the instruction set, old non-intensive programs will work fine. I think the range where you're spooked by the instruction set is pretty narrow.

VB6 is still officially under support in Windows Server 2019.

More like their infrastructure is dependent on old versions of tools that they don't want to upgrade, can't build, and only work on x86. Hugely common.

There's an unbelievable amount of software out there for which porting is either not viable or not economical.

At work we use Delphi to produce Windows applications that rely on Win32 and GDI. While Delphi can be used to make say Android apps, if you're going for Win32 you're limited to the x86(-64) compiler.

A lot of the low-level stuff in standard libraries, third-party libraries and in our own code rely on platform details like calling conventions, which will almost certainly be different for a different architecture. Sure it can probably be rewritten, and a lot of code in the standard library already has generic high-level variants as fallback, but it's not going to be a simple recompile for us.

By extension then, our customers rely on the ISA as long as they rely on our application, and our software is key to their operation.

In many cases the dependency is native (not virtualized) Windows and Windows doesn't run natively on any good ARMs.