ARM64EC Explicado: Quando Usar, Como, e a Regra de Dependência que Confunde Todos

ARM64EC é o aspecto mais mal compreendido do desenvolvimento no Windows on Arm. Ele aparece em threads de issues do openssl, Qt, Ruby e .NET como “espera, ARM64 ou ARM64EC?” — então vamos resolver isso.

As três coisas que as pessoas confundem

• ARM64 — puro nativo Arm64. Mais rápido, mas um processo Arm64 pode apenas carregar binários Arm64.
• ARM64EC (“Emulation Compatible”) — uma ABI do Windows 11 onde código nativo ARM64EC e código x64 emulado coexistem em um mesmo processo. As partes ARM64EC rodam nativamente; as partes x64 rodam sob emulação.
• ARM64X — um único binário PE que contém ambas as visões x64/Arm64EC e pura-Arm64, podendo ser carregado por qualquer tipo de processo. Usado para DLLs compartilhadas.

O que ARM64EC realmente é

É uma ponte para aplicativos que não conseguem se tornar totalmente nativos em um único salto — geralmente porque dependem de um plugin, codec ou biblioteca x64 sem uma compilação Arm64. Você recompila seu próprio código como ARM64EC (velocidade nativa), e a dependência x64 continua rodando sob emulação, dentro do mesmo processo. O próprio Windows 11 on Arm usa isso: a maior parte do código do SO que um app x64 chama é compilado como ARM64EC, então aplicativos emulados recebem chamadas de sistema em velocidade nativa sem saber.

ARM64EC requer o SDK do Windows 11 — ele não existe no Windows 10 on Arm.

A regra de dependência que confunde todos

Este é o ponto mais citado como pegadinha, retirado diretamente da Microsoft:

Um processo x64 ou Arm64EC pode carregar e chamar binários x64 e Arm64EC, enquanto um processo Arm64 só pode carregar binários Arm64.

Portanto: um processo ARM64EC carrega x64 ✓ e ARM64EC ✓, mas ARM64 puro ✗. Se você compilar ARM64EC e tentar incluir uma dependência pura-Arm64, ela não será carregada. Isso pega quem mistura uma biblioteca nativa-Arm64 em uma compilação EC.

O manual de migração incremental

O fluxo de trabalho pretendido é gradual, e o aplicativo continua funcionando a cada passo:

1. Comece com seu app x64 totalmente emulado.
2. Recompile seus módulos mais intensivos em CPU como ARM64EC primeiro — ganho máximo de desempenho por unidade de esforço.
3. Continue módulo por módulo.
4. Opcionalmente, termine como Arm64 totalmente nativo assim que todas as dependências tiverem uma compilação Arm64.

ARM64X e o truque do pure-forwarder

Se você distribui uma DLL que tanto processos x64/EC quanto processos puro-Arm64 precisam carregar, compile-a como ARM64X — um arquivo, duas visões. Um padrão elegante é o pure forwarder: uma pequena DLL ARM64X sem código que redireciona o carregador para a DLL real correta específica da arquitetura.

Como identificar o que você construiu

• link /dump /headers no binário final mostra 8664 machine (x64) (ARM64X) para conteúdo ARM64EC. (OBJ/LIB intermediários mostram A641 (ARM64EC), um ID interno do MSVC — não um tipo PE final.)
• No Gerenciador de Tarefas, um app ARM64EC aparece como “ARM64 (x64 compatible)” — veja como ler a coluna de arquitetura.

ARM64EC vs ir totalmente nativo

ARM64EC é um meio, não um destino. Se todas as dependências têm uma compilação Arm64, Arm64 puro é mais rápido e mais simples — sem emulação por processo, sem mistura de ABI. Recorra ao ARM64EC quando, e somente quando, uma dependência exclusiva x64 bloquear o caminho puro. Comece pelo roteiro completo de portabilidade e deixe a auditoria de dependências te dizer em qual estrada você está.