ARM64EC explicado: Cuándo usarlo, cómo y la regla de dependencia que confunde a todos

ARM64EC es la parte más incomprendida del desarrollo en Windows on Arm. Aparece en hilos de incidencias de openssl, Qt, Ruby y .NET como «espera, ¿ARM64 o ARM64EC?» — así que aclaremos esto.

Las tres cosas que la gente confunde

• ARM64 — Arm64 puro nativo. Más rápido, pero un proceso Arm64 solo puede cargar binarios Arm64.
• ARM64EC («Emulation Compatible») — una ABI de Windows 11 en la que el código Arm64EC nativo y el código x64 emulado coexisten en un mismo proceso. Las partes ARM64EC se ejecutan de forma nativa; las partes x64 se ejecutan bajo emulación.
• ARM64X — un único binario PE que contiene tanto una vista x64/Arm64EC como una vista Arm64 pura, cargable por cualquier tipo de proceso. Se usa para DLL compartidas.

Qué es realmente ARM64EC

Es un puente para aplicaciones que no pueden volverse completamente nativas de un salto — generalmente porque dependen de un plugin, códec o biblioteca x64 que no tiene una compilación Arm64. Vuelves a compilar tu propio código como ARM64EC (velocidad nativa), y la dependencia x64 sigue ejecutándose bajo emulación, dentro del mismo proceso. El propio Windows 11 en Arm usa esto: la mayor parte del código del SO que llama una app x64 está compilado como ARM64EC, por lo que las apps emuladas obtienen llamadas al sistema a velocidad nativa sin saberlo.

ARM64EC requiere el SDK de Windows 11 — no existe en Windows 10 en Arm.

La regla de dependencia que confunde a todos

Este es el error más citado, tomado directamente de Microsoft:

Un proceso x64 o Arm64EC puede cargar y llamar a binarios tanto x64 como Arm64EC, mientras que un proceso Arm64 solo puede cargar binarios Arm64.

Por lo tanto: un proceso ARM64EC carga x64 ✓ y ARM64EC ✓, pero ARM64 puro ✗. Si compilas ARM64EC e intentas incluir una dependencia Arm64 pura, no se cargará. Esto atrapa a quienes mezclan una biblioteca Arm64 nativa en una compilación EC.

El manual de migración incremental

El flujo de trabajo previsto es gradual, y la aplicación sigue funcionando en cada paso:

1. Empieza con tu app x64 completamente emulada.
2. Recompila primero tus módulos con mayor uso de CPU como ARM64EC: máximo rendimiento por unidad de esfuerzo.
3. Continúa módulo por módulo.
4. Opcionalmente, termina en Arm64 nativo completo una vez que todas las dependencias tengan una compilación Arm64.

ARM64X y el truco del redireccionador puro

Si distribuyes una DLL que tanto procesos x64/EC como procesos Arm64 puros necesitan cargar, compílala como ARM64X — un archivo, dos vistas. Un patrón útil es el redireccionador puro: una pequeña DLL ARM64X sin código que redirige el cargador a la DLL real correcta para la arquitectura específica.

Cómo saber lo que has compilado

• link /dump /headers en el binario final muestra 8664 machine (x64) (ARM64X) para contenido ARM64EC. (Los OBJ/LIB intermedios muestran A641 (ARM64EC), un ID interno de MSVC — no un tipo PE final).
• En el Administrador de tareas, una app ARM64EC aparece como “ARM64 (x64 compatible)” — consulta cómo leer la columna de arquitectura.

ARM64EC frente a ir completamente nativo

ARM64EC es un medio, no un destino. Si todas las dependencias tienen una compilación Arm64, Arm64 puro es más rápido y sencillo — ni emulación por proceso, ni mezcla de ABI. Recurre a ARM64EC cuando, y solo cuando, una dependencia exclusiva de x64 bloquee el camino puro. Empieza desde la guía completa de migración y deja que la auditoría de dependencias te indique en qué camino estás.