Desde la aparición de Windows 10 y su anuncio de ser un SaaS (Software as a service, software como un servicio), Microsoft ha iniciado una carrera interminable para ofrecer lo mejor de su capital humano para llevar a los usuarios un sistema operativo fácil de usar, y una plataforma confortable para crear y solucionar problemas a través de la filosofía de la universalidad de las aplicaciones para desarrolladores. No obstante, la vida útil de un software en esta era se ha reducido a tal punto que Redmond debe encargarse de seguir mejorando sus productos, y siempre mostrando mejores optimizaciones de ellos mismos. Es por ello que Microsoft está desarrollando subsistemas multiarquitectura en los laboratorios especiales del Grupo de Sistemas Operativos de la compañía, y esto se tiene planeado implementarlo posteriormente en Redstone 2.
¿Que es un subsistema multiarquitectura?
Normalmente una aplicación al ser desarrollada debe ser creada orientada a una arquitectura de sistema operativo; recordemos que Microsoft soporta con Windows 10 cuatro arquitecturas: x86, x64, ARM, en donde se encuentran los dispositivos móviles, y SoC, esta última en donde se incluyen las Hololens y Xbox. En procura de que Windows 10 sea un solo sistema operativo, los desarrolladores del Grupo de Sistemas Operativos han trabajado para que su kernel posea lo necesario para que sea un todo para todos, del que conocemos como OneCore. La versión 2.0 de OneCore aún posee algunas limitaciones, sobre todo por el hecho de cómo se administra la creación y debugging de las aplicaciones universales desde herramientas de desarrollo como Visual Studio y sus respectivos Kits de Desarrollo.
Si bien un compilador/enlazador automatiza la creación de los ejecutables necesarios para cada arquitectura, esto no quiere decir que sea lo óptimo para el desarrollo. Para solventar este inconveniente, Microsoft ideó crear subsistemas que sean capaces de ser invocados creando un solo ejecutable independiente de la arquitectura en la que estamos orientando el desarrollo de nuestra aplicación. Esto quiere decir que aún más se busca unificar y agilizar la creación de nuevo código sin que se requiera llenar el disco duro de instalaciones de SDKs por cada arquitectura.
¿Cómo funciona un subsistema multiarquitectura?
Realmente es un poco complejo de entender, sin embargo las ventajas para el desarrollador son notorias. Un ejecutable que es creado desde una solución en Visual Studio, por ejemplo, invocará o llamará las librerías o dependencias que él necesita para ejecutarse, es decir, serán los actores intermediarios en tiempo de ejecución; el subsistema que está apto (es decir, cumple los requisitos) para poder responder ese invocado exitosamente será el que ejecute la orden, así se cumple el principio de menos esfuerzo y divide y vencerás. Para Windows será un respiro debido a la forma como Microsoft planteó la administración y gestión de los llamados a las APIs del kernel desde la versión 3.1 del sistema operativo, además que permitirá una optimización sustanciable en los recursos, dejando poco a poco de lado la filosofía de los sistemas monolíticos. Dan Staples hizo un articulo muy interesante y explica detalladamente cómo funciona el proceso de invocado de código multiarquitectura desde la programación a bajo nivel utilizando la inyección DLL y el Heaven Gate de Windows.
¿Y eso ya no está implementado en las aplicaciones universales?
No. En realidad lo que se implementó en las aplicaciones universales es la generación de ejecutables por arquitectura. Si no eres desarrollador, te comento que una aplicación universal consta de 4 ejecutables, cada uno para su arquitectura (x86, x64, ARM y Hololens/Xbox), lo mismo sucede para sus dependencias. Actualmente, cuando un usuario quiere descargar una aplicación desde la Tienda, ésta es capaz de detectar cuál arquitectura está haciendo la petición de descarga y por ello sabe que si quieres descargar MetroTube en PC no debe lanzar la petición para la versión ARM. Microsoft quiere implementar este mismo principio para las compilaciones de ejecutables, dejándole el trabajo sucio al kernel y a los enlazadores/compiladores y desligar a la Tienda de estas validaciones.
Donde sí Microsoft ha implementado el principio de sistemas multiarquitectura es en el TAEF, que en español viene siendo el Marco de Trabajo de Pruebas de Ejecución y Creación de Software. Con ello Microsoft y OEMs puede realizar el proceso de QA de sus aplicaciones para Windows ejecutando una sola línea de comando y localizando posibles errores en tiempo de ejecución.
Actualmente el desarrollo de subsistemas multiarquitectura está en una etapa muy verde, sin embargo ya se comenzó a adoptar para el futuro del sistema operativo como una forma de impulsar la eficacia en el desarrollo de aplicaciones universales.
Gracias a Patrick con la corrección del final del soporte de la arquitectura Itanium desde Windows Server 2008 R2.
Estáte al día de todas las noticias con nuestro canal de Telegram ¡Síguenos!
