ARM64EC expliqué : quand l'utiliser, comment, et la règle de dépendance qui piège tout le monde

ARM64EC est le coin le plus mal compris du développement Windows sur Arm. Il apparaît dans les fils de discussion d’openssl, Qt, Ruby et .NET sous la forme « attendez, ARM64 ou ARM64EC ? » — alors réglons cela.

Les trois choses que les gens confondent

• ARM64 — natif pur Arm64. Le plus rapide, mais un processus Arm64 ne peut que charger des binaires Arm64.
• ARM64EC (“Emulation Compatible”) — une ABI Windows 11 où le code natif Arm64EC et le code x64 émulé coexistent dans un même processus. Les parties Arm64EC s’exécutent en natif ; les parties x64 s’exécutent sous émulation.
• ARM64X — un binaire PE unique qui contient à la fois une vue x64/Arm64EC et une vue pure-Arm64, chargeable par les deux types de processus. Utilisé pour les DLL partagées.

Ce qu’est réellement ARM64EC

C’est un pont pour les applications qui ne peuvent pas passer entièrement en natif en une seule fois — généralement parce qu’elles dépendent d’un plugin, codec ou bibliothèque x64 sans version Arm64. Vous recompilez votre propre code en ARM64EC (vitesse native), et la dépendance x64 continue de fonctionner sous émulation, à l’intérieur du même processus. Windows 11 sur Arm lui-même utilise cela : la plupart du code système appelé par une application x64 est compilé en ARM64EC, de sorte que les applications émulées bénéficient d’appels système à vitesse native sans le savoir.

ARM64EC nécessite le SDK Windows 11 — il n’existe pas sur Windows 10 sur Arm.

La règle de dépendance qui piège tout le monde

C’est l’écueil le plus cité, directement extrait de Microsoft :

Un processus x64 ou Arm64EC peut charger et appeler des binaires x64 et Arm64EC, alors qu’un processus Arm64 ne peut charger que des binaires Arm64.

Donc : un processus ARM64EC charge x64 ✓ et ARM64EC ✓, mais ARM64 pur ✗. Si vous compilez en ARM64EC et tentez d’intégrer une dépendance pure-Arm64, elle ne se chargera pas. Cela piège les personnes qui mélangent une bibliothèque native-Arm64 dans une build EC.

Le guide de migration incrémentale

Le flux de travail prévu est progressif, et l’application continue de fonctionner à chaque étape :

1. Commencez avec votre application x64 entièrement émulée.
2. Recompilez d’abord vos modules les plus intensifs en CPU en ARM64EC — gain de performance maximal par unité d’effort.
3. Continuez module par module.
4. Optionnellement, terminez en natif Arm64 complet une fois que chaque dépendance possède une version Arm64.

ARM64X et l’astuce du redirecteur pur

Si vous distribuez une DLL que les deux processus x64/EC et pure-Arm64 doivent charger, construisez-la en ARM64X — un fichier, deux vues. Un motif astucieux est le redirecteur pur : une minuscule DLL ARM64X sans code qui redirige le chargeur vers la vraie DLL spécifique à l’architecture.

Comment savoir ce que vous avez construit

• link /dump /headers sur le binaire final affiche 8664 machine (x64) (ARM64X) pour le contenu ARM64EC. (Les OBJ/LIB intermédiaires affichent A641 (ARM64EC), un identifiant interne MSVC — pas un type PE final.)
• Dans le Gestionnaire des tâches, une application ARM64EC apparaît comme “ARM64 (x64 compatible)” — voir comment lire la colonne architecture.

ARM64EC vs passer entièrement en natif

ARM64EC est un moyen, pas une destination. Si chaque dépendance possède une version Arm64, l’Arm64 pur est plus rapide et plus simple — pas d’émulation par processus, pas de mélange d’ABI. Utilisez ARM64EC uniquement lorsqu’une dépendance x64 exclusive bloque la voie pure. Commencez par la feuille de route de portage complète et laissez l’audit des dépendances vous dire sur quelle route vous vous trouvez.