Una columna mía reciente tocó una nota amarga con un desarrollador de software de código abierto. Resulta que la situación de desarrollo de software de Windows on Arm no se reduce únicamente a la disponibilidad de silicio y hardware. sigue leyendo –Jason Perlow
En una publicación de blog reciente, Jason Perlow de MarketingyPublicidad.es sugirió que el principal obstáculo para Windows on Arm es el hardware. Si solo el hardware estuviera disponible, podríamos tener una gran experiencia porque el software y las herramientas para desarrolladores están listos. Esto simplemente no es cierto cuando considera el estado de las herramientas de desarrollo en Windows para Arm.
La cadena de herramientas de desarrollo oficial de Microsoft es bastante mala en Arm. Microsoft no proporciona versiones Arm de Visual Studio, VS Build Tools o incluso Microsoft Visual C++; esperan que los desarrolladores de Arm realicen una compilación cruzada del software C++ en un host x86 o emulen el software x86.
Hay soporte nativo de Arm para .NET y VS Code, pero esto no ayuda a los desarrolladores de C++. Dado que MSVC es de código cerrado, la única forma de obtener soporte nativo para MSVC on Arm es que Microsoft lo implemente. Consulte https://developercommunity.visualstudio.com/t/native-Arm-support-for-visual-studio/1161018
La situación del código abierto no es mejor. No hay implementaciones Arm de los entornos de desarrollo MinGW o MSYS; por lo tanto, ninguna cadena de herramientas Arm GCC o Arm Clang está disponible todavía en Windows. Hay solicitudes de funciones abiertas para que agreguen soporte nativo de Arm, pero aún no está listo. Si va al sitio web de Arm, tienen una página donde puede descargar MinGW GCC para un dispositivo x86 para compilar de forma cruzada para un dispositivo Arm. Realmente dice algo cuando la única forma de compilar su producto en Windows es usar el producto de un competidor.
Otro popular compilador de C++ en Windows es el compilador Intel C++ (ICC). Esto no está disponible en Arm por razones obvias, y requiere que Visual Studio esté instalado de todos modos. Por lo tanto, 0 de 4 compiladores populares de C++ están disponibles para Arm Windows.
Todavía no existe una versión de Python nativa de Arm para Windows. Sin embargo, es probable que esto se resuelva en algún momento de este año: consulte https://bugs.python.org/issue33125
Quizás se pregunte por qué es tan importante tener compatibilidad nativa con Arm para compiladores. Muchos desarrolladores ya realizan compilaciones cruzadas desde sus computadoras a otros dispositivos cuando desarrollan software para teléfonos inteligentes o consolas, entonces, ¿por qué no pueden hacer lo mismo con los dispositivos Arm Windows? Pueden, pero es una experiencia de segunda clase.
La compilación cruzada no es una cadena de herramientas nativa de Arm para Windows
Una computadora con Windows que no puede ejecutar un compilador de forma nativa y necesita otra computadora para realizar una compilación cruzada de binarios/ejecutables para que se ejecute es de la misma clase que un teléfono inteligente, ya que no puede desarrollar y probar en el mismo dispositivo. La diferencia aquí es que los teléfonos inteligentes y las consolas no están destinados a ser plataformas de desarrollo; es posible pero inusual escribir código en su teléfono.
Imaginemos que eres un aspirante a desarrollador de software y vas a la tienda a comprar una computadora para que puedas aprender C++. En la situación A, compra un dispositivo Windows x86, se lo lleva a casa, instala un IDE como Visual Studio, escribe un código C++, presiona un botón y luego su código se ejecuta. Eso es genial, estás desarrollando en una plataforma con soporte de primera clase. Ahora, en la situación B, compra un dispositivo Arm Windows, se lo lleva a casa y se da cuenta de que no hay Visual Studio ni ningún compilador de C++ para su computadora. Entonces, ¿Qué haces? Mucha gente volvería a la tienda y devolvería la computadora y compraría una x86. O, en la situación C, regresa a la tienda para comprar una segunda computadora que es x86, se la lleva a casa, instala Visual Studio, configura un entorno de desarrollo de compilación cruzada, escribe código C++, presiona un botón y espera 10 segundos para que se implemente en el dispositivo Arm. En ese momento, usted, un aspirante a desarrollador, se preguntará por qué no debería desarrollar solo x86 para que solo necesite una computadora y pueda devolver el dispositivo Arm de segunda clase.
Otra desventaja de Windows for Arm es que no admite OpenGL o Vulkan. Incluso si configura una cadena de herramientas de compilación cruzada, no tendrá suerte si su aplicación usa Vulkan. Si tiene una aplicación OpenGL, la sugerencia de Microsoft es usar ANGLE para traducir OpenGL a DirectX.
El mensaje de Microsoft es claro: si desea admitir nuestra nueva plataforma Arm Windows, debe usar nuestras API patentadas. De manera similar, PlayStation, Xbox, Switch y iPhone requieren que los desarrolladores usen API de gráficos patentadas, y ninguno puede ejecutar un compilador, por lo que debe realizar una compilación cruzada desde otro dispositivo. Lo que los desarrolladores escuchan también es claro: Windows for Arm es un sistema operativo de juguete que no puede ejecutar compiladores o API de gráficos estándar de la industria y, por lo tanto, no es una plataforma de desarrollo seria y debe tratarse como un teléfono o una consola.
Siempre que desarrollar en un dispositivo Arm Windows sea una experiencia inferior, los desarrolladores elegirán usar x86 porque tiene soporte de primera clase; nunca le darán a Arm Windows el mismo nivel de soporte que x86.
Este estado de segunda clase hará que los consumidores no deseen un dispositivo Arm si tuvieran que emular x86 para sus aplicaciones de todos modos, lo que lleva a un bucle de comentarios de los desarrolladores que no se preocupan por Arm, ya que es una mala experiencia y tiene pocos usuarios. Esto, a su vez, hace que los fabricantes de hardware no se preocupen lo suficiente por fabricar potentes dispositivos Arm Windows porque pocas personas querrán gastar mucho dinero en un dispositivo de segunda clase. La única forma de comenzar a romper este ciclo es que las principales herramientas de desarrollo, como Visual Studio, admitan Arm.
En comparación, el soporte de Arm para herramientas de desarrollo en macOS y Linux es mucho mejor. GCC, Clang y Python están disponibles para Arm en estos sistemas operativos y funcionan muy bien. Puede descargar versiones nativas de estas herramientas de desarrollo y compilarlas de forma nativa con un dispositivo, y funciona exactamente como cabría esperar.
¿Los desarrolladores pensarían en Apple de manera diferente?
Solo por un momento, me gustaría que se imagine si Apple lanzara Arm macOS sin portar Clang y sin compatibilidad con OpenGL. En esta situación, un desarrollador tendría que obtener una vieja Mac x86 para usarla en el desarrollo y compilación cruzada para Arm Mac. Si esto sucediera, habría un alboroto, lo que generaría temores de que Apple está convirtiendo macOS en iOS, que estaría bloqueado, que si no puede compilar su propio software, pronto no podrá ejecutar su software. Haría que el apoyo de Arm fuera de segunda clase, y la gente lo odiaría.
Desde la perspectiva puramente de un desarrollador de C++, se podría argumentar que Linux tiene mejor compatibilidad con RISC-V que la compatibilidad con Arm de Windows. RISC-V es una arquitectura de CPU de código abierto que es muy nueva y no está lista para los consumidores. Linux en RISC-V no es una gran experiencia, pero todavía hay un compilador disponible para que pueda hacer desarrollo nativo con software nativo en un dispositivo sin compilación cruzada. Esa es una ventaja sobre Windows for Arm.
El primer intento de Microsoft en un dispositivo Arm fue la tableta Surface original lanzada en 2012, que ejecutaba Windows RT (Windows 8 para Arm). Si Microsoft se tomaba en serio la compatibilidad con Arm, debería haber portado MSVC y Visual Studio a Arm en 2012, de forma similar a como Apple tuvo soporte desde el primer día para Xcode y Clang cuando lanzaron las primeras ARM Mac. Mirando su historial, dudo que Microsoft transfiera Visual Studio a Arm pronto. Microsoft tardó hasta 2022 en migrar Visual Studio a la versión de 64 bits de la misma arquitectura. Eso es 19 años después de que se lanzara la primera CPU x86 de 64 bits en 2003, el Athlon 64. Para ser justos, portaron MSVC a x86 de 64 bits en ~ 2005, por lo que hay esperanza, pero para una buena experiencia de desarrollador. , necesitan migrar toda la pila de Visual Studio a Arm.
Compré un Arm MacBook Pro 14″ para desarrollar macOS y Arm para Windows y Linux en Parallels VM. Mi objetivo es admitir Arm macOS y Arm Linux. Sin embargo, dada la situación actual, no haré ningún esfuerzo adicional. en el desarrollo de Arm Windows hasta que Microsoft decida que es una computadora real y que haya soporte nativo de Arm para Visual Studio, MSVC, OpenGL y Vulkan. Estoy seguro de que Microsoft lo logrará eventualmente, pero la simple verdad es que el desarrollador de Windows para ARM las herramientas no están listas hoy incluso si el hardware estaba listo.
Sobre el Autor: Aaron Franke (@aaronfranke7) es un desarrollador de software de código abierto con sede en Texas. Es colaborador habitual de la Proyecto de motor de juego Godot 2D/3Dalgunas de sus contribuciones recientes incluyen portar el motor a la arquitectura de CPU RISC-V y trabajar para mejorar el soporte para arquitecturas que no son x86 en general.
