KomuraSoft LLC
Contáctenos
Menú

¿Las aplicaciones empresariales funcionan en Windows para Arm? — La realidad de la emulación x64 (Prism), las DLL nativas y COM

· Actualizado el: · · Windows on Arm, Arm64, Emulación x64, Integración nativa, P/Invoke, COM, Controladores, C#, .NET, Desarrollo Windows, Consultoría técnica

«El nuevo PC del mes que viene va a ser un Copilot+ PC. ¿Nuestro sistema de negocio funcionará?» — a medida que avanza la adopción corporativa de PC con Snapdragon, cada vez más empresas de desarrollo y departamentos de TI reciben esta pregunta. El catálogo dice «las aplicaciones existentes también funcionan mediante emulación». Pero la aplicación empresarial propia invoca, tras la pantalla en C#, una DLL nativa provista por un proveedor mediante P/Invoke, los informes pasan por un componente COM, y encima hay instalado un controlador para un dispositivo especializado. Ser sinceros: no es fácil responder «¿funciona?» de inmediato.

Adelantemos la respuesta: «la aplicación en sí suele funcionar. Lo peligroso está en lo que la rodea». Mientras que el código x86/x64 en modo usuario queda bastante bien cubierto por la emulación de Windows 11, existe un ámbito claro «fuera del alcance de la emulación»: controladores, extensiones de shell y la mezcla de arquitecturas dentro de un proceso. Y precisamente ese ámbito fuera de alcance es el terreno que las aplicaciones empresariales han utilizado con gusto durante años.

En este artículo repasamos, dentro de lo que se puede verificar en Microsoft Learn, el funcionamiento y los límites de la emulación de Windows on Arm, el principio fundamental de que x64 y Arm64 no se pueden mezclar dentro de un mismo proceso, el problema de combinación específico de las aplicaciones .NET, y el procedimiento práctico para comprobar si la aplicación propia funciona en un equipo Arm.

1. Conclusión resumida

Si tiene prisa, con estos tres puntos es suficiente por ahora.

  1. La aplicación en sí suele funcionar. Windows 11 on Arm puede ejecutar aplicaciones x86/x64 mediante la emulación integrada del sistema operativo, y desde la versión 24H2 el rendimiento ha mejorado gracias a Prism.1
  2. Lo arriesgado es lo «periférico». Los controladores en modo kernel, las DLL que se cargan en otros procesos —como las extensiones de shell o los IME— y el desajuste de arquitectura entre DLL nativas y COM. Que la aplicación funcione o no se decide aquí, no en el cuerpo principal de la aplicación.234
  3. La verificación se resuelve en tres etapas. Inventario de dependencias → comprobación en un equipo Arm real manteniendo x64 → conversión nativa a Arm64 si es necesario. El procedimiento se detalla en el capítulo 6.

Los términos Arm64EC y Arm64X se explican en el capítulo 4; no hace falta memorizarlos aquí. A continuación se detallan estos tres puntos junto con sus fuentes. Vuelva a ellos cuando necesite profundizar.

  • Las aplicaciones puramente administradas (.NET) y las aplicaciones de escritorio x86/x64 normales funcionan casi siempre gracias a la emulación de Windows 11 para Arm. La emulación viene integrada en el sistema operativo y no requiere modificar la aplicación ni añadir componentes.1
  • La emulación solo se encarga del código en modo usuario. Los controladores en modo kernel no se emulan y requieren obligatoriamente una versión nativa de Arm64. Los controladores UMDF y los controladores de impresora también deben coincidir con la arquitectura del sistema operativo.23
  • Las extensiones de shell, los IME, las tecnologías de asistencia y, en general, cualquier «DLL que se cargue en otro proceso» (como el Explorador de archivos) también necesitan recompilarse a Arm64, igual que el sistema. La emulación no puede resolver esto.4
  • Dentro de un mismo proceso no se pueden mezclar x64 y Arm64. Un proceso x64/Arm64EC solo puede cargar binarios x64 y Arm64EC, y un proceso Arm64 solo puede cargar binarios Arm64. Un ejecutable x64 no puede llamar a una DLL Arm64, y tampoco a la inversa.5
  • El mecanismo para superar esta restricción dentro de un único archivo son Arm64EC (código Arm64 nativo que puede convivir con código x64 dentro del mismo proceso) y Arm64X (un binario que aloja código Arm64 y Arm64EC en un solo PE y puede cargarse en cualquiera de los dos tipos de proceso). Los servidores COM in-process o los plugins a los que llaman ambas arquitecturas son el terreno de Arm64X.56
  • .NET ofrece soporte oficial para Windows Arm64 desde .NET 6 (en las versiones actualmente compatibles, .NET 8/9/10, Windows 11/10 en Arm64 figura explícitamente como sistema operativo compatible), y se puede publicar de forma nativa con el RID win-arm64. Por otro lado, si una aplicación AnyCPU se ejecuta con el runtime .NET de Arm64, el proceso corre como Arm64, lo que provoca un problema de combinación: si la aplicación invoca mediante P/Invoke una DLL nativa que solo existe en x64, la carga fallará.785
  • Para el entorno de pruebas, además de un equipo físico (como un Copilot+ PC), puede usar una VM de Windows 11 Arm64 en Azure, o la ISO de Windows 11 Arm64, utilizable con Hyper-V en un equipo Arm o en un Mac con Apple Silicon. Nota: Hyper-V en un equipo x64 no puede crear VM Arm64.910

2. Qué es Windows para Arm — PC con Snapdragon y Prism

Windows para Arm es la versión de Windows que se ejecuta sobre procesadores Arm64. Desde 2024, gran parte de los «Copilot+ PC» —una nueva categoría de PC con Windows 11 equipados con una NPU capaz de más de 40 billones de operaciones por segundo (40+ TOPS)— han adoptado la serie Snapdragon X basada en Arm, lo que ha convertido este tema en algo que los desarrolladores ya no pueden ignorar.1112

Lo que sostiene la compatibilidad con las aplicaciones existentes es la emulación integrada en el sistema operativo. Los puntos clave de su funcionamiento son los siguientes.1

  • El emulador compila JIT bloques de instrucciones x86/x64 a instrucciones Arm64, y almacena en caché el resultado de la conversión por módulo, de modo que los inicios posteriores al primero sean más rápidos.
  • Windows 11 puede emular tanto x86 como x64. Windows 10 on Arm solo puede emular x86, así que, en la práctica, cualquier discusión sobre aplicaciones empresariales x64 presupone Windows 11.
  • En Windows 11 24H2 se introdujo el nuevo emulador Prism, que mejoró el rendimiento respecto al anterior y redujo el uso de CPU. Prism está optimizado para los Qualcomm Snapdragon.
  • Las aplicaciones de 32 bits (x86) se ejecutan sobre la misma capa WOW64 que en la versión x64 de Windows, y reciben la redirección del sistema de archivos y del registro. En cambio, las aplicaciones x64 no tienen capa WOW64: como los binarios del sistema están compilados en el formato Arm64X descrito más adelante, las aplicaciones x64 pueden acceder a todo el sistema operativo (tanto al sistema de archivos como al registro) sin ninguna redirección.1

La información de CPU que ve una aplicación bajo emulación corresponde a un «procesador virtual emulado». Por compatibilidad, incluso GetNativeSystemInfo devuelve valores emulados, así que, si necesita saber si el host real es Arm64, debe usar IsWow64Process2 o GetMachineTypeAttributes.13

Además, para las aplicaciones que presentan problemas bajo emulación, Windows ofrece la posibilidad de cambiar la configuración de emulación (con los perfiles predeterminado/seguro/estricto/muy estricto y ajustes individuales detallados) desde el botón derecho sobre el ejecutable → Propiedades → pestaña Compatibilidad. Es un ajuste que sacrifica rendimiento a cambio de compatibilidad, pero vale la pena recordarlo como vía de escape para el caso de «esto funcionaba en versiones anteriores de Windows on Arm».14

3. Qué funciona y qué no funciona con la emulación

La respuesta a «¿funciona?» depende del tipo de dependencias, no de la aplicación en sí. Antes de entrar en detalle, conviene tener claro dónde termina el alcance de la emulación, capa por capa, para agilizar el resto de las decisiones.

Capa Qué hay ahí ¿La emulación lo resuelve?
Modo usuario / dentro del propio proceso El exe de la aplicación propia y el conjunto de DLL de la misma arquitectura Sí. Funciona sin modificaciones tal cual, en x86/x641
Modo usuario / mezclar otra arquitectura en el mismo proceso Cargar una DLL Arm64 en un proceso x64, por ejemplo No. Se evita con Arm64EC, Arm64X o separando el proceso (capítulo 4)5
Modo usuario / DLL que entra en otro proceso Extensiones de shell, IME, tecnologías de asistencia, plugins de aplicaciones de terceros No. Requiere recompilar según la arquitectura del proceso destino (Arm64)4
Modo kernel Diversos controladores (VPN, productos de seguridad, dongles USB, impresoras virtuales) No. No existe emulación en el kernel; Arm64 es obligatorio23

Las dos fronteras son «dentro o fuera del propio proceso» y «modo usuario o modo kernel». No es exagerado decir que enumerar las dependencias que caen fuera de estas dos fronteras es, en la práctica, todo lo que implica un estudio de compatibilidad con Arm. A continuación se muestra la misma información organizada en las unidades que realmente se evalúan en la práctica.

Categoría Comportamiento en Windows 11 para Arm Fundamento / notas
Aplicación x86/x64 en modo usuario (exe + conjunto de DLL de la misma arquitectura) Funciona con emulación Sin modificaciones, sin instalación adicional1
Aplicación .NET (administrada) Funciona (también admite ejecución nativa Arm64) Ver capítulo 58
Controlador en modo kernel No funciona. Requiere Arm64 nativo No existe emulación en el kernel23
Controlador UMDF / controlador de impresora Requiere el mismo Arm64 que el sistema operativo Aunque la aplicación funcione con emulación, las funciones que dependen del controlador quedan inutilizables3
Extensión de shell / IME / tecnología de asistencia (DLL cargada en otro proceso) Requiere recompilación a Arm64 Menú contextual del Explorador, iconos de almacenamiento en la nube, etc.4
Aplicación x86 que prohíbe la generación dinámica de código No funciona con emulación El emulador genera instrucciones Arm64 en tiempo de ejecución, por lo que se necesita relajar ProcessDynamicCodePolicy4
Juegos que dependen de OpenGL antiguo o de controladores anticheat A veces no funciona OpenGL superior a 3.3 o anticheat sin soporte Arm son obstáculos15
Periféricos (impresoras, escáneres, dispositivos especializados) Depende de si existe un controlador Arm64 Se necesita un controlador Arm64 incluido en el sistema o provisto por el fabricante15
Software antivirus o que «modifica la experiencia de Windows» Requiere verificación individual El soporte Arm ha avanzado, pero se recomienda verificar producto por producto15

Traducido al contexto de las aplicaciones empresariales, las señales de alarma son las siguientes.

  • Clientes VPN, agentes de gestión de activos, productos de seguridad — son en esencia controladores de kernel. Es necesario confirmar con el proveedor si existe una versión compatible con Arm64.
  • Autenticación por dongle USB, equipos especializados (instrumentos de medición, terminales de pago, etc.) — lo decisivo es si el controlador del dispositivo se ofrece para Arm64.
  • Herramientas que «añaden funciones al Explorador de archivos» — como las extensiones de shell se cargan en el Explorador Arm64, no funcionan si se dejan en x64.
  • Aunque la aplicación principal no encaje en ninguno de estos casos, si el instalador incluye un controlador (por ejemplo, una salida a PDF mediante un controlador de impresora virtual), se topa con el mismo problema.

4. No se pueden mezclar arquitecturas dentro de un proceso — La realidad de P/Invoke y COM

Desde la era de 32 bits existe la regla ineludible de que «un proceso de 64 bits no puede cargar una DLL de 32 bits»16. Windows para Arm tiene una regla con la misma estructura. La documentación oficial resume así las reglas de carga posibles.5

Arquitectura del proceso DLL x64 DLL Arm64EC DLL Arm64 DLL Arm64X
Proceso x64 / Arm64EC Se puede cargar Se puede cargar No se puede Se puede cargar
Proceso Arm64 No se puede No se puede Se puede cargar Se puede cargar

Los dos mecanismos que aparecen aquí son la clave para diseñar la compatibilidad con Arm.

  • Arm64EC (Emulation Compatible) es una ABI de código nativo Arm64 que, al seguir la convención de llamadas, el uso de la pila y el diseño de datos de x64, puede convivir dentro del mismo proceso con código x64 ejecutado por emulación. Cuando una aplicación x64 se ejecuta en Windows 11 on Arm, la mayor parte del código del sistema operativo que se carga en ese proceso está compilado en Arm64EC y corre a velocidad nativa sin que la aplicación lo sepa. Aunque las DLL dependientes se mantengan en x64, esto permite una migración gradual: ir convirtiendo a Arm64EC el propio código, empezando por el más crítico, para mejorar el rendimiento poco a poco.5
  • Arm64X es un formato binario que aloja en un solo archivo PE tanto el código Arm64 tradicional como el código Arm64EC. Se comporta como una DLL x64 si el proceso que la carga es x64, y como una DLL Arm64 si el proceso es Arm64, por lo que resulta idóneo para una DLL que podría ser llamada desde procesos de ambas arquitecturas. La documentación oficial menciona como situaciones que requieren Arm64X: «un servidor COM de 64 bits al que llaman tanto aplicaciones x64 como Arm64», «un plugin que se carga tanto en aplicaciones x64 como Arm64» y «un binario único que se inyecta en procesos x64 o Arm64».6

Concretemos el impacto real en las aplicaciones empresariales.

Caso 1: ejecutable x64 + DLL nativa x64 (P/Invoke). Si todo el proceso está unificado en x64, funciona íntegramente dentro de la emulación. No es posible mezclar una DLL Arm64 con la idea de «acelerar solo una parte» (según la tabla anterior, no está permitido).

Caso 2: servidor COM in-process. Un servidor in-proc de COM es simplemente una DLL, así que se le aplica directamente la regla de la tabla anterior. Desde un cliente x64 solo se puede usar una DLL COM x64 (o Arm64EC/Arm64X), y en cuanto se convierte la aplicación a Arm64 nativo, la DLL COM x64 deja de poder cargarse. Si se necesita compatibilidad con ambas arquitecturas, hay que convertir la DLL a Arm64X, o aplicar la técnica probada desde la era 32↔64 bits de separar el COM en un proceso externo o dividirlo con IPC (separar los procesos y comunicarlos mediante comunicación entre procesos). Cruzar la barrera de arquitectura mediante una frontera de proceso ha sido, desde siempre, la fórmula básica.166

Caso 3: alojar plugins propios o ser alojado como plugin. Formas como los complementos de Excel, los plugins de paquetes empresariales o el middleware de impresión —en las que la propia DLL se carga en el proceso de otra aplicación— deben ajustarse a la arquitectura de esa otra aplicación. A la inversa, si la aplicación propia aloja plugins, hay que prever el alcance del impacto: convertir la aplicación propia a Arm64 dejará inutilizables todos los plugins de terceros en x64.

Por cierto, se puede comprobar de qué tipo es un binario concreto desde el símbolo del sistema para desarrolladores.5

link /dump /headers MyLibrary.dll

Solo hay que fijarse en la línea que aparece justo después de FILE HEADER VALUES. La documentación oficial muestra una salida con este formato.5

File Type: EXECUTABLE IMAGE
FILE HEADER VALUES
    8664 machine (x64) (ARM64X)

Así se interpreta esa línea machine.

Línea machine Tipo de binario
8664 machine (x64) x64
8664 machine (x64) (ARM64X) Parcialmente recompilado como Arm64EC (se ve como x64 desde un proceso x64)
AA64 machine (ARM64) Arm64
AA64 machine (ARM64) (ARM64X) Arm64X. Se puede cargar tanto en procesos x64 como Arm64

Como la salida es larga, en la práctica conviene encadenarla con link /dump /headers MyLibrary.dll | findstr machine para extraer solo esa línea. Si se examina con el mismo comando un OBJ/LIB intermedio de la compilación, aparece A641 machine (ARM64EC), pero se trata de un identificador interno de MSVC, no del valor machine final del EXE/DLL.5

Si solo quiere comprobar una aplicación que ya está en ejecución, también puede mostrar la columna «Arquitectura» en la pestaña «Detalles» del Administrador de tareas. Las aplicaciones cuyo ejecutable está compilado en Arm64EC aparecen como ARM64 (x64 compatible).5

5. El caso de las aplicaciones .NET — La trampa de AnyCPU y la detección de arquitectura

.NET (la línea Core) ofrece soporte oficial para Windows Arm64 desde .NET 6, y en las versiones actualmente compatibles (.NET 8/9/10) Windows 11/10 en Arm64 figura explícitamente como sistema operativo compatible. Para publicar, basta con indicar win-arm64 como RID.177

<!-- csproj: publicar para Arm64 nativo -->
<PropertyGroup>
  <TargetFramework>net8.0-windows</TargetFramework>
  <RuntimeIdentifiers>win-x64;win-arm64</RuntimeIdentifiers>
</PropertyGroup>

dotnet publish -r win-arm64 -c Release

Si la aplicación es solo código administrado puro, con esto la conversión nativa a Arm64 está prácticamente completa: el JIT se limita a generar código Arm64 y, en general, no hace falta modificar el código fuente. En el caso de las aplicaciones .NET Framework, .NET Framework 4.8.1 añadió soporte nativo para Arm64 (para equipos Arm64 con Windows 11; el runtime 4.8.1 no admite aplicaciones Arm64 nativas en equipos Arm con Windows 10). Las aplicaciones Framework que se mantienen en compilación x64 se consideran ejecutadas mediante emulación.1819

El problema es la combinación cuando se invoca una DLL nativa mediante P/Invoke. En un equipo Arm, la vieja creencia de que «al ser una aplicación .NET, con AnyCPU funciona en cualquier parte» se desmorona.

  • Si se ejecuta con el SDK/runtime .NET de Arm64, la aplicación corre por defecto como un proceso Arm64.8
  • Un proceso Arm64 no puede cargar una DLL x64 (según la tabla del capítulo 4). Es decir, aunque el código propio en AnyCPU quede intacto, la carga de la DLL nativa x64 invocada mediante DllImport fallará.5
  • Por el contrario, una aplicación publicada como win-x64 corre íntegramente en x64 y funciona dentro de la emulación (junto con la DLL nativa x64). En este caso no se obtiene el rendimiento nativo de Arm64, pero es la configuración con mayor compatibilidad de funcionamiento.12

Lo que parece un comportamiento errático de «a veces funciona y a veces no» suele ser, en realidad, un desajuste entre la arquitectura del proceso y la arquitectura de las dependencias nativas. Como primer paso para diagnosticar el problema, tener preparado en el código una forma de comprobar con qué arquitectura corre el proceso en ejecución simplifica enormemente la investigación.

using System.Runtime.InteropServices;

// Arquitectura del propio proceso (X64 si está bajo emulación x64)
Console.WriteLine($"Process: {RuntimeInformation.ProcessArchitecture}");

// Arquitectura real del sistema operativo (Arm64 en un equipo Arm)
Console.WriteLine($"OS: {RuntimeInformation.OSArchitecture}");

Un detalle importante: OSArchitecture solo empezó a devolver «la arquitectura real del sistema operativo, sin la capa de emulación» a partir de .NET 7. Antes de eso, bajo emulación devolvía X64, así que cualquier código en .NET 6 o anterior que use esta API para determinar «si es un equipo Arm» no funcionará como se espera.2021

A continuación se resumen los puntos de control específicos de .NET.

  • Recursos nativos de paquetes NuGet: un paquete que solo tiene runtimes/win-x64/native no ofrece nada en qué apoyarse al publicar para win-arm64. Hay que verificar el contenido del paquete (o el repositorio) para comprobar si existe el recurso win-arm64. El RID es precisamente el mecanismo para «distribuir recursos específicos de cada plataforma».7
  • Configuración del SDK en el equipo de desarrollo: en un equipo Arm, la versión Arm64 de .NET se instala en la ruta habitual C:\Program Files\dotnet\, mientras que el SDK x64 se instala en C:\Program Files\dotnet\x64\, y ambos pueden coexistir. La arquitectura con la que se ejecuta dotnet run cambia según hacia dónde apunten PATH o DOTNET_ROOT, así que téngalo presente durante las pruebas.17
  • Cómo interpretar la excepción: un desajuste de arquitectura en un ensamblado administrado se manifiesta como BadImageFormatException (la referencia oficial indica explícitamente, como condición para que ocurra, «la carga de un componente dirigido a una plataforma diferente»).22

6. Lista de verificación de compatibilidad Arm para la aplicación propia

En la práctica, resulta eficiente verificarlo en las siguientes tres etapas.

Etapa Qué hacer Criterio de decisión
① Inventario de dependencias Enumerar las DLL nativas invocadas mediante P/Invoke, los componentes COM, los controladores incluidos, las extensiones de shell y los paquetes NuGet con recursos nativos Si hay cero controladores y extensiones de shell, el panorama es prometedor. Si los hay, verificar el soporte Arm64 de cada proveedor34
② Comprobación en equipo real con emulación Instalar la compilación x64 tal cual en un equipo Arm (o una VM Arm64) y recorrer los principales escenarios de negocio Si funciona, «seguir operando en x64» se convierte en una opción. Donde no funcione, sospechar de dependencias con desajuste de arquitectura1
③ Estudio de compilación nativa Arm64 En .NET, publicar con win-arm64; en C++, añadir la configuración Arm64 y comprobar si la compilación pasa La causa habitual de fallo es la ausencia de una versión Arm64 de alguna biblioteca dependiente. Considerar actualizarla, sustituirla o recurrir a Arm64EC23

También conviene relacionar en qué etapa influye cada uno de los casos vistos en el capítulo 4.

Caso del capítulo 4 Etapa donde influye principalmente Punto a observar
Caso 1: ejecutable x64 + DLL nativa x64 ② Comprobación en equipo real Como todo el proceso está unificado en x64, la probabilidad de que funcione es alta. Lo que hay que verificar no es tanto si funciona, sino si la velocidad está dentro de un rango práctico
Caso 2: servidor COM in-process ① Inventario → decisión en ③ Quién provee esa DLL COM. Verificar si hay previsión de una versión Arm64X, y si no la hay, considerar la separación en un proceso externo
Caso 3: alojar plugins propios o ser alojado como plugin ① Inventario (arquitectura de la contraparte) Convertir la aplicación propia a Arm64 dejará inutilizables los plugins de terceros en x64. Es necesario delimitar el alcance del impacto antes de avanzar a ③

Para las etapas ② y ③, existen las siguientes opciones de entorno de prueba.

  • Equipo físico: un equipo con Snapdragon, como un Copilot+ PC. Tener uno disponible es lo más fiable, incluso para investigar problemas.12
  • VM de Azure: en el portal de Azure se puede filtrar la imagen por Arm64 y crear una VM Arm64 de Windows 11 (tamaño recomendado D2ps_v5, entre otros, basado en Ampere Altra). La ventaja es que se puede empezar a probar sin tener ni un solo equipo Arm físico.9
  • VM local: la ISO de Windows 11 Arm64 se distribuye oficialmente, y se puede crear una VM con Hyper-V en un equipo Arm o en un Mac con Apple Silicon (basado en Arm). Tenga en cuenta que Hyper-V en un equipo x64 no puede crear una VM Arm64.10

El estado de soporte de los productos de terceros se puede consultar en el sitio de referencia que ofrece Microsoft (Windows on Arm Ready Software). Además, para los problemas de compatibilidad de aplicaciones empresariales (LOB) desarrolladas internamente o de aplicaciones de ISV, existe una vía de apoyo oficial llamada App Assure. Que exista una vía disponible antes de llegar a un «no funciona y no hay salida» también resulta un buen argumento para explicárselo al departamento de TI.1215

Los criterios para saber si la propia organización es elegible se resumen a continuación.2425

Elemento Contenido
Posicionamiento Forma parte de los beneficios de FastTrack. Se incluye sin coste adicional en los planes elegibles de Microsoft 365 y Windows
Condiciones de elegibilidad Sigue las condiciones de elegibilidad de FastTrack. El criterio base es haber adquirido 150 licencias o más de un plan elegible por inquilino; entre los planes elegibles se mencionan Microsoft 365 E3/E5, Microsoft 365 Business Premium, Microsoft Intune, Enterprise Mobility + Security, entre otros
Alcance del apoyo Windows 10/11, Microsoft 365 Apps, Azure Virtual Desktop, Microsoft Edge, PC Windows on Arm64, Windows 365. Las aplicaciones elegibles son las LOB desarrolladas internamente, las aplicaciones de ISV y los productos de Microsoft
Canal de solicitud Se solicita mediante el formulario Request for Assistance. La información general del programa está en aka.ms/appassure
Canal adicional para desarrolladores También se ofrece un canal de solicitud para desarrolladores atascados en el trabajo de adaptación a Arm: App Assure Arm Advisory Service

La forma más rápida de saber si la propia configuración de licencias es elegible consiste en cotejar los nombres de plan anteriores con el contenido del contrato del departamento de TI o de compras. Como las condiciones de número de licencias y la lista de planes elegibles pueden cambiar, verifique la información más reciente en la página de condiciones de elegibilidad de FastTrack antes de presentar la solicitud.

7. La solución práctica por ahora — Cómo elegir entre tres opciones

La compatibilidad con Arm no se reduce a la única opción de «convertirlo todo a nativo». Para muchas aplicaciones empresariales, la solución práctica es más bien una combinación gradual de enfoques.

Opción Casos adecuados Puntos a tener en cuenta
(a) Mantenerse en x64 y operar con emulación Sin dependencias de controladores ni extensiones de shell, y con un rendimiento suficiente para el uso real El rendimiento ya ha mejorado con Prism (24H2 en adelante). Mantener todo el proceso unificado en x64 y no mezclar binarios Arm6415
(b) Verificar y esperar el soporte Arm64 del proveedor Cuando las DLL nativas o los controladores son de terceros Confirmar la «previsión de disponibilidad de una DLL Arm64 (o versión Arm64X)». Para los controladores no hay más solución que esperar323
(c) Compilación nativa Arm64 Aplicaciones .NET puras, o cuando ya existen versiones Arm64 de todas las dependencias. Cuando el rendimiento o la duración de la batería son requisitos Requiere publicar con win-arm64 y convertir a Arm64 todas las dependencias nativas. Si se alojan plugins, prestar atención al alcance del impacto75

Cuando el volumen de código C++ es grande, existe Arm64EC como término intermedio entre (a) y (c). Permite mantener las DLL dependientes en x64 tal cual y convertir a nativo, de forma gradual, únicamente el código propio, por lo que es la ruta oficial para el caso en que «no se puede migrar de golpe una aplicación x64 enorme».523

En cuanto al entorno de desarrollo, existe una versión nativa de Arm64 de Visual Studio, con un conjunto de herramientas de compilador que permite tener como destino Arm64, x64 y x86 desde un equipo Arm. Las compilaciones para CI también se pueden generar mediante compilación cruzada en las máquinas de compilación x64 existentes, lo que facilita montar una configuración en la que «solo la ejecución de las pruebas se reserva para un equipo Arm real o una VM».2623

8. Resumen

  • Windows 11 para Arm puede ejecutar aplicaciones x86/x64 mediante la emulación integrada del sistema operativo, y desde la versión 24H2 el rendimiento ha mejorado gracias a Prism. La emulación de x64 empieza con Windows 11; Windows 10 on Arm solo emula x86.
  • El alcance de la emulación se limita al modo usuario. Los controladores en modo kernel, UMDF y de impresora, así como las «DLL que se cargan en otro proceso» como las extensiones de shell, los IME y las tecnologías de asistencia, requieren obligatoriamente una versión nativa de Arm64. Que una aplicación empresarial sea viable o no se decide por estas dependencias periféricas, no por la aplicación en sí.
  • Dentro de un proceso no se pueden mezclar x64 y Arm64. Un proceso x64/Arm64EC puede cargar x64 y Arm64EC; un proceso Arm64 solo puede cargar Arm64. Tanto los servidores COM in-process como los plugins siguen la misma regla: para dar soporte a ambas arquitecturas, la fórmula es Arm64X, y para cruzar la frontera del proceso, COM en un proceso externo o IPC.
  • .NET se puede publicar de forma nativa con win-arm64, pero una aplicación AnyCPU que corre sobre un runtime Arm64 se ejecuta como proceso Arm64, así que invocar mediante P/Invoke una DLL nativa disponible solo en x64 fallará. Se puede diagnosticar con RuntimeInformation.ProcessArchitecture / OSArchitecture (esta última desde .NET 7).
  • El procedimiento de verificación consta de tres etapas: «inventario de dependencias → comprobación en equipo real con emulación en x64 → conversión nativa a Arm64 si es necesario». El entorno de prueba se puede preparar con una VM Arm64 de Azure o la ISO Arm64, y las empresas también pueden recurrir al apoyo de App Assure.
  • Por ahora, la solución práctica consiste en combinar «si funciona con emulación, dejarlo así», «verificar el soporte de los proveedores de controladores y DLL» y, según los requisitos, «conversión nativa a Arm64 (en C++, también la migración gradual con Arm64EC)».

Artículos relacionados

Áreas de consultoría relacionadas

KomuraSoft LLC se encarga del estudio de viabilidad de compatibilidad con Windows para Arm de aplicaciones empresariales existentes, del diseño de migración de arquitectura de aplicaciones que incluyen integración con DLL nativas y COM, y del análisis de causa raíz de fallos que «solo ocurren en equipos Arm».

Referencias

  1. Microsoft Learn, How emulation works on Arm. Sobre que la emulación está integrada en el sistema operativo y puede ejecutar aplicaciones sin modificaciones; que Windows 11 admite tanto x86 como x64 y Windows 10 on Arm solo x86; el mecanismo de conversión JIT de bloques de instrucciones x86 y su caché; Prism en Windows 11 24H2 y su optimización para Snapdragon; y que las aplicaciones x86 reciben redirección mediante WOW64 mientras que las x64 no tienen WOW64 y usan los binarios del sistema en formato Arm64X. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8

  2. Microsoft Learn, How emulation works on Arm. Sobre que la emulación solo admite código en modo usuario y no admite controladores, y que los componentes en modo kernel deben compilarse como Arm64. ↩ ↩2 ↩3 ↩4

  3. Microsoft Learn, Troubleshooting x86 desktop apps. Sobre que todos los controladores en modo kernel, los controladores UMDF y los controladores de impresora deben coincidir con la arquitectura del sistema operativo, y que aunque la aplicación en sí funcione con emulación, las funciones que dependen de un controlador no se pueden usar. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  4. Microsoft Learn, Troubleshooting x86 desktop apps. Sobre que las aplicaciones que hacen que su propia DLL se cargue en un proceso de Windows (extensiones de shell, IME, tecnologías de asistencia) necesitan recompilarse según la arquitectura del sistema (Arm64), y que las aplicaciones x86 que prohíben la generación dinámica de código no se pueden ejecutar con emulación. ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  5. Microsoft Learn, Arm64EC - Build and port apps for native performance on Arm. Sobre la tabla de interoperabilidad según la cual un proceso x64/Arm64EC puede cargar binarios x64 y Arm64EC, y un proceso Arm64 solo puede cargar binarios Arm64; que Arm64EC sigue las convenciones de software de x64 y puede convivir con código x64 dentro del mismo proceso; que la mayor parte del código del sistema operativo cargado en el proceso de una aplicación x64 es Arm64EC; y el método para comprobar el tipo de binario con link /dump /headers. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14

  6. Microsoft Learn, Arm64X PE files. Sobre que Arm64X aloja código Arm64 y Arm64EC en un solo PE y se puede cargar tanto en procesos x64 como Arm64, y sobre las situaciones citadas como necesarias para Arm64X: servidores COM de 64 bits, plugins y DLL inyectadas a los que llaman aplicaciones de ambas arquitecturas. ↩ ↩2 ↩3

  7. Microsoft Learn, .NET RID Catalog. Sobre que win-arm64 está definido como RID de Windows, y que el RID se usa para distribuir los recursos específicos de cada plataforma dentro de un paquete NuGet. ↩ ↩2 ↩3 ↩4

  8. Microsoft Learn, Windows on Arm. Sobre que al ejecutarse con el SDK .NET de Arm64 corre como Arm64 por defecto, que .NET 8/9/10 (las versiones actualmente compatibles) se indican como destino para la ejecución nativa en Arm64, y que las aplicaciones .NET x64 existentes funcionan mediante la emulación x64 del sistema operativo. ↩ ↩2 ↩3

  9. Microsoft Learn, Quickstart: Create a Windows on Arm virtual machine in the Azure portal. Sobre la posibilidad de filtrar por imagen Arm64 en el portal de Azure y crear una VM Arm64 de Windows 11 (tamaño recomendado D2ps_v5, basado en Ampere Altra). ↩ ↩2

  10. Microsoft Learn, Windows 11 Arm ISO files overview. Sobre la distribución de la ISO de Windows 11 Arm64 y la posibilidad de crear una VM con Hyper-V en un equipo Arm o en un Mac con Apple Silicon, y sobre que Hyper-V en hardware x64 no admite VM Arm64. ↩ ↩2

  11. Microsoft Learn, Develop AI applications for Copilot+ PCs. Sobre que Copilot+ PC es una nueva categoría de hardware Windows 11 equipada con una NPU capaz de más de 40 billones de operaciones por segundo (40+ TOPS). ↩

  12. Microsoft Learn, Windows on Arm. Sobre que Windows 10 añadió la ejecución sin modificaciones de x86 y Windows 11 la de x64, que gran parte de los Copilot+ PC adoptan la serie Snapdragon X, y sobre la existencia del sitio de referencia de compatibilidad Arm (Works on Windows on Arm) y del App Assure Arm Advisory Service. ↩ ↩2 ↩3 ↩4

  13. Microsoft Learn, How emulation works on Arm - Detecting emulation. Sobre que una aplicación bajo emulación ve la información de un procesador virtual emulado, que GetNativeSystemInfo también devuelve valores emulados por compatibilidad, y que para detectar un host Arm64 se usan IsWow64Process2 o GetMachineTypeAttributes. ↩

  14. Microsoft Learn, Adjust emulation settings on Arm. Sobre la posibilidad de cambiar la configuración de emulación de Prism (perfiles predeterminado/seguro/estricto/muy estricto y ajustes individuales) desde la pestaña Compatibilidad de las propiedades del ejecutable. ↩

  15. Microsoft Learn, Arm-based Surface devices FAQ. Sobre las limitaciones de los dispositivos Arm (los controladores deben estar diseñados para Arm, los periféricos dependen de un controlador Arm64, los juegos con OpenGL superior a 3.3 o anticheat sin soporte, las aplicaciones de personalización como los IME, la verificación individual del software antivirus) y sobre el apoyo de compatibilidad de App Assure, que incluye las aplicaciones LOB. ↩ ↩2 ↩3 ↩4

  16. Microsoft Learn, Process Interoperability. Sobre que un proceso de 64 bits no puede cargar una DLL de 32 bits (y viceversa), y sobre la fórmula establecida de comunicarse a través de la frontera de arquitectura mediante un servidor COM externo y RPC. ↩ ↩2

  17. Microsoft Learn, Install .NET on Windows. Sobre que Windows 11/10 en Arm64 es compatible con .NET 8/9/10, y que en un equipo Arm la versión Arm64 de .NET se instala en C:\Program Files\dotnet\ y el SDK x64 en C:\Program Files\dotnet\x64\, lo que puede requerir ajustar PATH o DOTNET_ROOT. ↩ ↩2

  18. Microsoft Learn, What’s new in .NET Framework. Sobre que .NET Framework 4.8.1 añadió soporte nativo para Arm64, con ventaja de rendimiento frente al código x64 ejecutado mediante emulación en Arm64. ↩

  19. Microsoft Learn, Develop Apps for Windows IoT Enterprise. Sobre que el soporte nativo de Arm64 de .NET Framework 4.8.1 está orientado a Windows 11, y que el runtime 4.8.1 no admite aplicaciones Arm64 nativas en dispositivos Windows 10. ↩

  20. Microsoft Learn, RuntimeInformation.OSArchitecture under emulation. Sobre que desde .NET 7 OSArchitecture devuelve Arm64 incluso en un proceso bajo emulación en Windows Arm64 (antes devolvía X64), y que para la arquitectura del proceso debe usarse ProcessArchitecture. ↩

  21. Microsoft Learn, RuntimeInformation.ProcessArchitecture Property / RuntimeInformation.OSArchitecture Property. Sobre las API para obtener la arquitectura del proceso en ejecución y la arquitectura real del sistema operativo. ↩

  22. Microsoft Learn, BadImageFormatException Class. Sobre que se produce BadImageFormatException cuando un componente de la aplicación está dirigido a una plataforma diferente (carga de un ensamblado de otra arquitectura). ↩

  23. Microsoft Learn, Add Arm support to your Windows app. Sobre los factores típicos que impiden una compilación Arm64 (bibliotecas dependientes sin soporte, código específico de arquitectura, controladores de kernel) y cómo abordarlos, la opción de recompilar con Arm64EC manteniendo las dependencias x64, cómo obtener un equipo Arm real o una VM para pruebas, y la combinación de compilación cruzada con pruebas en un entorno Arm. ↩ ↩2 ↩3 ↩4

  24. Microsoft Learn, App Assure - Compatibility Cookbook. Sobre que App Assure forma parte de los beneficios de FastTrack y se incluye sin coste adicional en los planes elegibles de Microsoft 365 y Windows, que su alcance de apoyo incluye Windows 10/11, Microsoft 365 Apps, Azure Virtual Desktop, Microsoft Edge, PC Windows on Arm64 y Windows 365, que cubre los problemas de compatibilidad de aplicaciones LOB desarrolladas internamente, aplicaciones de ISV y productos de Microsoft, y que se puede solicitar desde Request for Assistance (aka.ms/appassurerequest). ↩

  25. Microsoft Learn, Eligibility - FastTrack. Sobre que el apoyo de FastTrack se ofrece cuando se han adquirido 150 licencias elegibles o más por inquilino, y sobre los planes elegibles mencionados: Microsoft 365 E3/E5, Microsoft 365 Business Premium, Microsoft Intune, Enterprise Mobility + Security, entre otros. ↩

  26. Microsoft Learn, Visual Studio on Arm-powered devices. Sobre que Visual Studio nativo de Arm64 permite desarrollar en .NET/C++, y que se ofrece un conjunto de herramientas MSVC que permite tener como destino Arm64, x64 y x86 desde un host Arm64. ↩

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

¿Las aplicaciones empresariales x64 normales funcionan en Windows para Arm?
En la mayoría de los casos, sí. Windows 11 on Arm incluye una función de emulación integrada que ejecuta aplicaciones x86/x64 sin modificaciones, y desde Windows 11 24H2 el nuevo emulador llamado Prism también ha mejorado el rendimiento. Sin embargo, la emulación solo se encarga del código en modo usuario: los controladores en modo kernel y las extensiones de shell o IME que se cargan en otros procesos, como el Explorador de archivos, requieren obligatoriamente una versión nativa de Arm64. Considere que la respuesta depende más de las dependencias periféricas que de la aplicación en sí.
¿Se puede llamar a una DLL de Arm64 desde un ejecutable x64?
No se puede. No es posible mezclar binarios x64 y Arm64 dentro de un mismo proceso: un proceso x64 (o Arm64EC) solo puede cargar binarios x64 y Arm64EC, y un proceso Arm64 solo puede cargar binarios Arm64. Lo mismo ocurre en sentido inverso (una DLL x64 desde un ejecutable Arm64): tampoco es posible. Si de verdad necesita una única DLL compatible con ambas arquitecturas, existe el formato Arm64X, que combina código Arm64 y Arm64EC en un solo archivo, o bien puede separar el proceso y comunicarse mediante IPC.
¿Qué se necesita para adaptar una aplicación .NET a Arm64?
.NET 6 en adelante ofrece soporte oficial para Windows Arm64, y en las versiones actualmente compatibles (.NET 8/9/10) Windows 11/10 en Arm64 figura explícitamente como sistema operativo compatible. Basta con indicar el RID (identificador de tiempo de ejecución) win-arm64 al publicar para generar un ejecutable nativo de Arm64. Si la aplicación es puramente código administrado, con esto prácticamente basta, pero si hay DLL nativas invocadas mediante P/Invoke o paquetes NuGet con recursos nativos, hay que verificar si existe una versión Arm64 de cada uno. En el caso de aplicaciones .NET Framework, la versión 4.8.1 admite ejecución nativa en Arm64 sobre Windows 11.
¿Qué tipo de software no funciona en Windows para Arm?
En primer lugar, el software que incluye controladores en modo kernel. Como los controladores no se emulan, los clientes VPN, los productos de seguridad, los dispositivos virtuales y la autenticación por dongle USB, entre otros, no funcionan sin un controlador Arm64. En segundo lugar están las extensiones de shell, los IME y las tecnologías de asistencia, que cargan sus DLL en procesos del propio sistema operativo, así como las aplicaciones que prohíben la generación dinámica de código y los juegos que dependen de OpenGL antiguo o de controladores anticheat. Con los periféricos ocurre lo mismo: que funcionen o no depende de si existe un controlador Arm64.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.

Contactar
Volver al blog