ARM64EC erklärt: Wann man es verwendet, wie, und die Abhängigkeitsregel, die jeden stolpern lässt

ARM64EC ist die am meisten missverstandene Ecke der Windows-on-Arm-Entwicklung. Es taucht in openssl-, Qt-, Ruby- und .NET-Issue-Threads als „Moment, ARM64 oder ARM64EC? auf – also klären wir das.

Die drei Dinge, die Leute verwechseln

• ARM64 — reines natives Arm64. Am schnellsten, aber ein ARM64-Prozess kann nur ARM64-Binärdateien laden.
• ARM64EC („Emulation Compatible“) — eine Windows 11 ABI, bei der nativer ARM64EC-Code und emulierter x64-Code in einem Prozess koexistieren. Die ARM64EC-Teile laufen nativ; x64-Teile laufen unter Emulation.
• ARM64X — eine einzelne PE-Binärdatei, die sowohl eine x64/ARM64EC-Ansicht als auch eine reine ARM64-Ansicht enthält, die von beiden Prozessarten geladen werden kann. Wird für gemeinsam genutzte DLLs verwendet.

Was ARM64EC eigentlich ist

Es ist eine Brücke für Apps, die nicht in einem Sprung vollständig nativ werden können – normalerweise, weil sie von einem x64-Plug-in, Codec oder einer Bibliothek ohne ARM64-Build abhängen. Sie kompilieren Ihren eigenen Code als ARM64EC (native Geschwindigkeit) neu, und die x64-Abhängigkeit läuft weiterhin unter Emulation, innerhalb desselben Prozesses. Windows 11 auf Arm selbst verwendet dies: Der meiste OS-Code, den eine x64-App aufruft, ist als ARM64EC kompiliert, sodass emulierte Apps systemeigene Aufrufe in nativer Geschwindigkeit erhalten, ohne es zu merken.

ARM64EC erfordert das Windows 11 SDK – es existiert nicht unter Windows 10 auf Arm.

Die Abhängigkeitsregel, die jeden stolpern lässt

Dies ist der am häufigsten zitierte Stolperstein, direkt von Microsoft zitiert:

Ein x64- oder ARM64EC-Prozess kann sowohl x64- als auch ARM64EC-Binärdateien laden und aufrufen, während ein ARM64-Prozess nur ARM64-Binärdateien laden kann.

Also: Ein ARM64EC-Prozess lädt x64 ✓ und ARM64EC ✓, aber reines ARM64 ✗. Wenn Sie ARM64EC bauen und versuchen, eine reine ARM64-Abhängigkeit einzubinden, wird diese nicht geladen. Das erwischt Leute, die eine native ARM64-Bibliothek in einen EC-Build mischen.

Das inkrementelle Migrationsleitfaden

Der beabsichtigte Workflow ist schrittweise, und die App läuft bei jedem Schritt weiter:

1. Beginnen Sie mit Ihrer vollständig emulierten x64-App.
2. Kompilieren Sie Ihre rechenintensivsten Module zuerst als ARM64EC neu – maximaler Leistungsgewinn pro Aufwandeinheit.
3. Fahren Sie Modul für Modul fort.
4. Optional abschließend vollständig natives ARM64, sobald jede Abhängigkeit einen ARM64-Build hat.

ARM64X und der Pure-Forwarder-Trick

Wenn Sie eine DLL ausliefern, die sowohl x64/EC- als auch reine ARM64-Prozesse laden müssen, bauen Sie sie als ARM64X – eine Datei, zwei Ansichten. Ein nettes Muster ist der Pure Forwarder: eine winzige, codelose ARM64X-DLL, die den Lader zur korrekten architekturspezifischen echten DLL umleitet.

Wie man erkennt, was man gebaut hat

• link /dump /headers auf der finalen Binärdatei zeigt 8664 machine (x64) (ARM64X) für ARM64EC-Inhalt. (Zwischen-OBJ/LIB zeigen A641 (ARM64EC), eine interne MSVC-ID – kein endgültiger PE-Typ.)
• Im Task-Manager erscheint eine ARM64EC-App als „ARM64 (x64 kompatibel)“ – siehe So lesen Sie die Architekturspalte.

ARM64EC vs. vollständig nativ

ARM64EC ist ein Mittel, kein Ziel. Wenn jede Abhängigkeit einen ARM64-Build hat, ist reines ARM64 schneller und einfacher – keine prozessbezogene Emulation, kein ABI-Mixing. Greifen Sie zu ARM64EC nur dann, wenn eine reine x64-Abhängigkeit den reinen Weg blockiert. Beginnen Sie mit der vollständigen Portierungs-Roadmap und lassen Sie das Abhängigkeitsaudit entscheiden, auf welchem Weg Sie sich befinden.