Este texto ha sido generado por Gemini 2.5/3.1 a partir del audio del autor. El contenido y las ideas son íntegramente del autor; la redacción ha sido asistida por IA.
¿Qué pasa, patáticas mías? Aquí vuestro reportero maricharachero para continuar con la serie sobre WinRT. Hoy nos sumergimos de lleno en WinUI 3, y os adelanto que todo lo que os conté sobre WinRT sigue siendo perfectamente válido, porque WinUI no es más que la aplicación práctica de toda esa tecnología para construir las interfaces gráficas de las aplicaciones modernas.
Un Viaje al Pasado: Win32, Handles y los Primeros Frameworks
Para entender WinUI, hay que retroceder. Frameworks como Windows Forms eran, en esencia, una capa relativamente fina que envolvía los componentes nativos de Windows: el botón, el cuadro de edición, el checkbox… todo. Nos abstraían del famoso «handle de ventana» o HWND.
Aquí viene la anécdota para los más jóvenes. En el viejo Win32, todo, absolutamente todo, era una ventana. Por eso se llama Windows. Un simple campo de texto era una ventana con su propio handle. Esto tenía una consecuencia brutal: Windows tenía un número limitado de handles gráficos, unos 65.536.
¿Qué significaba esto? Que si abrías una aplicación gráficamente intensa como el viejo Borland C++ Builder, con sus toolbars llenas de iconitos (cada uno una ventana), y luego abrías otra similar, podías agotar los handles. El resultado era que los gráficos no se veían, o peor, la aplicación reventaba. La única solución era cerrar programas o, en el peor de los casos, reiniciar Windows. ¡Ah, los maravillosos años 90!
La Guerra Civil de Microsoft: La Tumultuosa Llegada de WPF
Luego llegó WPF (Windows Presentation Foundation), que en sus primeras versiones seguía dependiendo de este sistema de handles. Aunque introdujo una capa muy potente encima, con XAML y un sistema de layout que nos ahorraba los cálculos manuales que sufríamos en MFC, su nacimiento fue… complicado.
Cuando Microsoft decidió que la interfaz de Visual Studio debía rehacerse en WPF, se topó con un muro. El equipo de Visual Studio, de los pocos sin pelos en la lengua, les dijo sin rodeos que aquello era «una puta mierda pinchada en un puto palo de mierda». Y tenían razón. Yo mismo, en media hora, reporté 7 u 8 bugs gravísimos en la primera versión. Esas demos espectaculares de Microsoft eran humo; en la práctica, nada funcionaba.
Tras una buena ración de «arrojo de boñigas de mierda» interno, Microsoft se puso las pilas y arregló WPF. La primera versión de Visual Studio con WPF fue lenta y tosca, pero las siguientes mejoraron hasta el punto de que, a partir de .NET Framework 4.7, funciona francamente bien.
El Problema de Estar Atado al Sistema Operativo
¿Cuál fue la solución mágica para arreglar WPF? Integrar su motor directamente en el núcleo de Windows. Las DLLs que antes venían con el instalador de .NET Framework ahora formaban parte del propio sistema operativo. Esto solucionó los problemas de rendimiento, pero creó uno nuevo y gigantesco.
Cada vez que necesitaban corregir un bug o añadir una mejora a WPF, tenían que lanzar una actualización completa de Windows. Esto era insostenible. ¿Recordáis esas actualizaciones de .NET Framework que tardaban una eternidad en instalarse? Probablemente se debían a esto. El sistema estaba recompilando y optimizando el código para tu máquina específica, un proceso lento y pesado.
Nace WinUI 3: La Independencia del Framework
La necesidad de agilidad, especialmente con la llegada de las apps de la tienda de Windows (UWP) y el problema de una ABI (Application Binary Interface) fija, obligó a Microsoft a cambiar de estrategia. Usando la misma tecnología de componentes COM que vimos en WinRT, decidieron sacar el motor de UI fuera del núcleo de Windows.
Así nació WinUI 3. Es, en esencia, la evolución de WPF desacoplada del sistema operativo. Este proceso, como era de esperar, no fue trivial y trajo nuevas ineficiencias. Al tener que comunicar entre el espacio de usuario (anillo 3) y el kernel (anillo 0), se introdujo una latencia que lo hizo más lento en ciertos aspectos.
El Motor de WinUI 3: Dos Hilos y Mucho DirectX
La arquitectura de WinUI 3 es un batiburrillo interesante de tecnologías: Win32, WinRT y, sobre todo, DirectX. Por ahí leí una descripción que sonaba a «método cuántico arquitectónico indispensable», pero en cristiano, se basa en un modelo de dos hilos para lograr su rendimiento.
Por un lado, está el hilo de la UI (UI-Thread), que se encarga de procesar la lógica, ejecutar el código XAML y componer el árbol visual de lo que se va a mostrar. Aquí entran en juego optimizaciones clásicas de Windows, como las áreas de recorte, que evitan redibujar lo que no es necesario.
Una vez compuesto el «qué» se va a pintar, se le pasa el trabajo al hilo del compositor (Compositor-Thread). Este segundo hilo se comunica directamente con el hardware a través de DirectX para renderizar la escena en la pantalla. Esta separación es la clave de su rendimiento en aplicaciones gráficamente intensas, ya que el dibujado no bloquea la lógica de la aplicación.
Adiós al Invoke: Async/Await al Rescate de la UI
Un principio sagrado en el desarrollo de UI es mantener el hilo principal lo más libre posible para que la aplicación siempre responda. Antiguamente, si estabas en un hilo secundario y querías actualizar un texto en la pantalla, tenías que usar Invoke o BeginInvoke para enviar esa orden de vuelta al hilo principal.
WinUI 3, junto con las versiones modernas de C#, simplifica esto drásticamente gracias a async/await. Ahora, desde un método asíncrono, puedes modificar un elemento de la interfaz directamente. El compilador y el framework se encargan por arte de magia de gestionar los hilos y las máquinas de estado para que todo funcione sin bloquear la UI. Se acabó el Invoke.
La Experiencia del Desarrollador: Sin Diseñador Visual pero con Hot Reload
Un cambio importante para los que venimos del mundo clásico es que en WinUI 3 no hay un diseñador visual de XAML en Visual Studio. Si abres un fichero y no ves la vista previa, ya sabes que estás en el mundo moderno.
El flujo de trabajo ahora se basa en ejecutar la aplicación y modificar el XAML en caliente usando la función Hot Reload. Le das a recargar y los cambios aparecen al instante en la ventana. Bueno, en teoría. A veces funciona y a veces no, sobre todo si tocas cosas del patrón MVVM, obligándote a volver al método clásico de cerrar, recompilar y ejecutar.
Conclusión
Y este ha sido nuestro viaje por las entrañas de WinUI 3. Como veis, es el resultado de décadas de evolución, dramas internos en Microsoft y una búsqueda constante por un framework de UI potente y desacoplado. Mucho de esto es historia que he vivido, y otra parte es conocimiento que le he sonsacado a Gemini para complementar mis batallitas.
Por cierto, no he querido dejarme fuera la caótica gestión de versiones de .NET Core, con sus múltiples ABIs incompatibles y esa manía de dejar instaladas 50 versiones en el sistema. Es otro de esos detalles que forman parte de la historia de esta tecnología. ¡Espero que esta explicación os haya aclarado el panorama y os haya entretenido! ¡Adiós, mis pataticas!