Windows has been available on Arm for a few years, and while software support has progressed there have always been some limitations, and emulated x86/x64 code on Arm does not usually run as fast as native ARM32/ARM64 code.
So far developers had a binary choice: run their x86/x64 app on Arm using emulation, or port the entire app to Arm, But Microsoft has now come up with a solution that mixes x64 emulation and native Arm with ARM64EC (Emulation Compatible).
That means developers won’t need to port the complete app to Arm, but instead could do so step-by-step and focus on part of the code where native Arm support makes the most difference.
Microsoft explains:
ARM64EC is a new application binary interface (ABI) for Windows 11 on ARM that runs with native speed and is interoperable with x64. An app, process, or even a module can freely mix and match ARM64EC and x64 as needed. The ARM64EC code in the app will run natively while any x64 code will run using Windows 11 on ARM’s built-in emulation.
…
the ARM64EC ABI follows x64 software conventions including calling convention, stack usage, and data alignment, making ARM64EC and x64 interoperable. Apps built as ARM64EC may contain x64 code but do not have to, since ARM64EC is its own complete, first-class ABI for Windows.
Microsoft is using ARM64EC in Windows 11 where all binaries have been rebuilt with ARM64EC in order to let x64 apps run native system code. They are also using the new ABI with 64-bit Office for Arm, not for the main program that is written using native Arm code, but for existing x64 plugins that can work normally with the updated program.
So I’d expect a significant performance boost in Windows 11 on Arm compared to Windows 10 for a significant number of programs. Developers can download the latest Windows Insider SDK build and Visual Studio Preview (version 16.11 preview 2 or later) to get started with porting apps to ARM64EC.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
There’s quite a risk in doing this. The risk is to corner themselves again with a shitty ABI. They took two decades to mostly support 64-bit on x86 just because of their LLP64 model with 32-bit centric data types (byte/word/dword) that made it very hard to port applications to run natively on 64-bit. Here the risk to do that again is high. On ARM chars are normally unsigned, like on PPC. Making ARM code work like x86 will mean changing this, thus being unable to rely on standard ARM libs. But once some new libs are written to work like… Read more »
ARM defines the ABI for their processors as a standard[1]. This ensures interoperability between compilers. The ABI is responsible for ensuring that a procedure called will have its arguments in a well defined order regardless of compiler used (such as with shared libraries). Over time, x86 has had many calling conventions[2]: cdecl, stdcall, fastcall, thiscall, ms-x64, sysv-amd64, etc. This specification replaces the ARM standard calling convention with ms-x64 removing the requirement for “thunking” between calling conventions when using x86-64 architecture DLLs. However, it also reduces performance of the native ARM application. This occurs due to applying the same “register starvation”… Read more »
Is Microsoft seriously thinking an hybrid solution is the way to go?
You can throw as many libraries as you want at it, ARM is not x86, and it will never be. Make an ARM native OS once and for all.