- WDDM traslada la gestión de GPU a Dxgkrnl y miniports, alejándola de Win32k.
- ReactOS ya inicia drivers de pantalla WDDM y negocia modos vía VidPn y CDD.
- Un stack XDDM sólido sigue siendo imprescindible para avanzar en WDDM y DWM.
- ReactOS 0.4.15 mejora drivers, LiveUSB, rendimiento y da pasos hacia amd64.
ReactOS lleva tanto tiempo en desarrollo que muchos de los colaboradores actuales ni siquiera habían nacido cuando empezó a gestarse, pero su objetivo sigue intacto: ofrecer una experiencia ABI compatible con Windows capaz de ejecutar software y controladores pensados para el sistema de Microsoft. En los últimos años, uno de los frentes más ambiciosos del proyecto ha sido ponerse al día con el soporte de hardware.
Ese proceso ha desembocado en una meta clave: acercarse a la arquitectura moderna de controladores gráficos de Windows. Hablamos de WDDM, el modelo que sustituyó a XDDM desde la era de Vista. Dentro del ecosistema de ReactOS, explorar WDDM significa comprender cómo cambió la gestión de la GPU, qué piezas del sistema se reestructuraron y por qué no basta con “activar” un driver para que todo funcione como en Windows.
Qué es WDDM y por qué marca la diferencia
WDDM, el Windows Display Driver Model, introdujo una reforma profunda en la pila gráfica: trasladó el control de la GPU desde componentes como Win32k hacia un núcleo especializado (Dxgkrnl.sys) que se comunica con miniports del fabricante. Cada revisión (1.0, 1.1, 1.2 y sucesivas) define qué interfaces ofrece el sistema y cómo se implementan, un concepto distinto al de los feature levels de Direct3D que se ven en DxDiag.
Esta arquitectura, más modular y exigente, va más allá de lo que XDDM ofrecía. En WDDM, Dxgkrnl actúa como orquestador, y el driver del proveedor facilita puntos de entrada y contratos claros. Esa separación permite introducir mejoras como la memoria de vídeo virtualizada, un planificador de GPU y, en general, más estabilidad al mover parte de la lógica a modo usuario.
Durante años, la documentación práctica para profundizar en drivers de vídeo fue escasa para ambas arquitecturas, lo que complicaba el avance. Con la madurez de drivers de GPU abiertos, la comunidad ha ganado referencias reales para entender cómo se comportan los ICD de OpenGL, el soporte de Vulkan y las transiciones entre modelos.
¿Qué pasó con XDDM? Compatibilidad, restos y el punto de ruptura
Desde Windows 8, el sistema exige que el driver de GPU sea WDDM; sin embargo, XDDM no desapareció del todo. Windows Vista y 7 permitían cargar controladores XDDM sin quejarse, y todavía quedan mecanismos heredados que conviven con WDDM. El módulo que carga los ICD de OpenGL, por ejemplo, apenas cambió entre versiones.
La comunicación en WDDM hacia el miniport es más directa. Win32k conserva un salto de syscall que Dxgkrnl rellena con la interfaz adecuada, reduciendo la implicación del viejo subsistema en la lógica de GPU. De hecho, cuando arranca el sistema, se observan rutinas específicas para enlazar WDDM con el viejo mundo de Win32k sin mezclar arquitecturas.
Hay dos drivers de pantalla que conviene conocer al detalle: TSDDD.dll y CDD.dll. El primero, TSDDD, se carga manualmente en la sesión 0 y es un driver XDDM muy básico que apenas escribe en memoria en blanco. En la familia NT5.x (como la base de ReactOS), una inicialización de vídeo fallida suele acabar en un bugcheck por fallo de vídeo; en Vista y posteriores, esa situación “real” ya no se da gracias al segundo componente.
CDD.dll es el interesante. A la vez que actúa como un driver XDDM, emite IOCTLs para hablar con WDDM. Es el único camino por el que Dxgkrnl y Win32k se comunican con sentido durante la operación gráfica moderna. Durante la inicialización, Win32k consulta adaptadores pero la respuesta acaba sobrescrita con cdd.dll, garantizando el puente hacia WDDM. Un punto crítico: una vez activa WDDM, no es posible ejecutar un driver XDDM en paralelo.
ICD de OpenGL, Vulkan y la relación con el sistema
Los ICD de OpenGL se cargan mediante el módulo tradicional, y su flujo no varía en exceso entre Vista, 7, 8 y posteriores, lo que facilitó pruebas cruzadas usando ICD de diversas generaciones. Vulkan se comporta de manera parecida: el sistema delega en esas capas la interacción con la GPU, pero en WDDM el miniport y Dxgkrnl establecen el “contrato” real del hardware.
Esta estructura híbrida explica por qué aún vemos restos de XDDM conviviendo con WDDM en componentes del sistema. El puente CDD.dll permite que Win32k siga cumpliendo su rol clásico sin bloquear la ruta moderna, mientras Dxgkrnl y el miniport asumen la tarea crítica de gestionar la GPU.
Compilar drivers WDDM para pruebas en ReactOS
Para arrancar un driver WDDM hace falta una pieza auxiliar: displib.lib del WDK, que expone el punto de entrada para inicializar el driver y “despertar” a Dxgkrnl sin enlazar contra él. El flujo es particular: se invoca la API de inicialización, se pasan estructuras de datos a Dxgkrnl y, a continuación, Dxgkrnl devuelve el control llamando al callback de arranque del miniport del proveedor.
Ese callback suministra las interfaces para el resto de la comunicación con Dxgkrnl. En este punto, Win32k no pinta nada en el inicio del miniport, lo cual es una diferencia fundamental respecto al mundo XDDM. Esta adaptación fue directa de implementar en ReactOS, abriendo la puerta a importar y compilar drivers WDDM que, además, siguen funcionando en Windows.
WDDM en ReactOS: enfoque de pantalla primero
Los D3DKMT APIs se emplean para aceleración DirectX y OpenGL, así que para el primer experimento en ReactOS se optó por centrarse en lo básico: conseguir salida de vídeo. Aquí entra en juego el universo VidPn (Video Presentation Network) y el soporte de hardware asociado dentro de Dxgkrnl.
Desde Windows 8 existen los llamados KMDOD, una variante de miniports de WDDM que prescinden de la aceleración 3D. Son más fáciles de entender y de iniciar: permiten gestionar modos de vídeo, monitores y trayectorias sin depender del planificador y otros subsistemas complejos de Dxgkrnl.
Para ReactOS, el experimento consistía en construir un Dxgkrnl mínimo que consultase los modos disponibles vía VidPn, se los entregara a CDD y activase CDD cuando Dxgkrnl estuviera listo. El resultado: el sistema comenzó a hablar con su primer driver WDDM y a mostrar imagen en condiciones reales.
Primeros éxitos: BasicDisplay.sys y drivers de proveedores
Al cargar BasicDisplay.sys en ReactOS, la conclusión fue inesperadamente positiva: WDDM resultó ser más tolerante de lo previsto. Incluso era posible iniciar drivers de proveedor únicamente para la parte de visualización, sin pedirles aceleración 3D.
En pruebas posteriores, aparecieron salidas de vídeo con más controladores, incluyendo un driver de Nvidia de la era de Windows 7, lo cual permitió a ReactOS mover monitores modernos a su resolución y frecuencia nativas. El cuello de botella no fue Win32k, sino la compatibilidad con el hardware real que todavía se está ampliando.
Por qué XDDM sigue siendo crucial en el camino a WDDM
Aunque el objetivo final sea WDDM, ReactOS necesita que su stack XDDM esté en muy buen estado. La razón es que componentes como CDD.dll y el propio DWM dependen de que el viejo mundo rinda bien para hacer de puente hacia el nuevo. De hecho, DWM introduce exigencias que la implementación actual de Win32k en ReactOS aún no puede cubrir del todo, si bien hay avances continuos.
También se ha acelerado el soporte para GPUs AMD bajo XDDM, un paso importante para estabilizar el terreno antes de abrir la veda a drivers WDDM más complejos. La ruta escogida es incremental: primero pantalla y modos, luego más piezas del rompecabezas.
Diferencias clave entre XDDM y WDDM
Uno de los cambios más notables al pasar de XDDM a WDDM es la gestión de fallos. Con WDDM, gran parte de la lógica del driver se desplaza a modo usuario, lo que significa que un cuelgue del driver no tiene por qué tumbar el sistema completo. Además, el planificador de GPU y la memoria virtualizada permiten un reparto más fino de recursos.
En XDDM, Win32k llevaba mucho más peso y la comunicación con el hardware era más rígida. En WDDM, Dxgkrnl impone un contrato claro a los miniports, y Win32k queda como puente para el subsistema de ventanas. Esto habilita nuevas capacidades como el DWM, compositing y presentaciones más fiables.
- Planificación y aislamiento del trabajo de GPU frente al enfoque monolítico de XDDM.
- Memoria de vídeo virtual y mejor manejo de recursos compartidos.
- Mayor estabilidad al migrar lógica del driver a modo usuario.
- Integración con DWM y rutas de presentación modernas.
Limitaciones actuales y trabajo en curso
Si bien el arranque de drivers de pantalla WDDM en ReactOS ya es una realidad en pruebas, la compatibilidad de hardware sigue marcando el ritmo. Los dispositivos reales exigen soportes muy específicos, y cada salto requiere ampliar subsistemas: desde plug and play hasta gestión de memoria y watchdogs.
En el arranque, también se observa comunicación entre watchdog, Win32k y Dxgkrnl para preparar el despacho de las APIs D3DKMT dentro de Dxgkrnl; se trata de un momento puntual de inicialización, pero suma requisitos a la hora de reproducir el comportamiento de Windows con fidelidad.
Estado del proyecto, comunidad y llamada a colaborar
El empuje reciente hacia WDDM ha venido acompañado de más actividad en torno al hardware. Hay artículos técnicos donde se detalla el proceso y se invita a contribuir vía donaciones, GitHub o divulgación. Se trata de un frente grande y de largo recorrido: cada miniport y cada ruta de presentación añaden matices.
Conviene recordar, de paso, la naturaleza del proyecto: ReactOS no es Linux ni Unix. Para un análisis comparativo, está escrito desde cero para ser compatible a nivel binario con Windows, lo que permite ejecutar software y drivers de Windows de forma nativa, sin recurrir a capas de compatibilidad tipo Wine/Proton, aunque el proyecto también colabora con ese ecosistema FOSS para mejorar resultados.
Novedades prácticas: ReactOS 0.4.15 y mejoras del sistema
Más allá de WDDM, la versión 0.4.15 ha traído un buen lote de cambios: nuevos controladores de almacenamiento que mejoran estabilidad y compatibilidad con unidades USB, así como drivers de red renovados. También se han retocado fuentes, el shell del escritorio, APIs de Windows, temas y cuadros de diálogo.
Se han introducido mejoras en cachés y gestión de memoria que repercuten en rendimiento. Además, se añadió compatibilidad con LiveUSB tras modificaciones profundas en el gestor de Plug and Play del kernel, abriendo la puerta a más drivers de terceros. La interfaz gráfica recibió pequeños ajustes para facilitar su manejo frente al instalador en modo texto USETUP.
En el apartado de audio, ya es posible iniciar con la pila de sonido de Windows, aunque persisten aristas por pulir. También destaca que 0.4.15 es la primera versión con soporte para la arquitectura de 64 bits (amd64) hasta el escritorio, si bien no hay imagen oficial de 64 bits todavía porque se está trabajando en WOW64.
La corrección de errores ha sido intensa: iconos del escritorio mal asignados resueltos, iconos de la barra de tareas con mejor tamaño y compatibilidad nativa con archivos ZIP. Todo ello apunta a mejorar la experiencia de uso básica mientras se ataca la compatibilidad de hardware.
Descarga, instalación y requisitos mínimos
Las imágenes de ReactOS 0.4.15 están disponibles en SourceForge. Es posible probar en máquina virtual (recomendado para empezar) o instalar en hardware real con una unidad USB creada con utilidades como Rufus, igual que harías con un Windows estándar.
Los requisitos son modestos: CPU x86 (Pentium o posterior), 64 MB de RAM, al menos 450 MB de disco en una partición FAT16/FAT32 y unos 2 GB adicionales si piensas instalar software o juegos. Con estos mínimos, equipos de la última década o incluso anteriores pueden mover el sistema en escenarios de pruebas.
Recomendaciones de uso y expectativas realistas
A día de hoy, ReactOS es un proyecto experimental. No se recomienda como sistema principal si necesitas funcionalidades modernas y compatibilidad total con aplicaciones recientes. Para ejecutar software más nuevo, Wine/Proton en Linux sigue siendo una ruta muy estable y con un ecosistema grande de soporte.
Aun así, la singularidad de ReactOS lo convierte en el único sistema abierto que ejecuta binarios de Windows sin capas intermedias al estilo emuladores. Ese enfoque lo hace interesante para laboratorios, retrocompatibilidad, análisis y entornos controlados donde se quiera estudiar el comportamiento de aplicaciones y drivers.
Contexto comunitario y mensajes habituales
En foros y espacios sociales, es frecuente ver recordatorios del estilo: ReactOS es un sistema para PC que puede ejecutar programas y drivers de Windows. A veces también se muestran contadores de miembros y usuarios conectados, simples indicadores de vitalidad comunitaria que, sin valor técnico, apuntan al interés creciente por el proyecto.
La narrativa mediática reciente incluso ha señalado la coincidencia temporal entre el final del soporte de algunas versiones de Windows y los avances de ReactOS hacia WDDM. Más que una ironía, es un síntoma de que la comunidad está alineando prioridades para seguir siendo relevante frente al hardware y a los controladores actuales.
Al final, todo este esfuerzo converge en un mismo punto: construir una base sólida donde WDDM pueda asentarse sin renunciar al legado XDDM que aún hace de pegamento entre mundos. Con CDD.dll como puente, Dxgkrnl como cerebro y miniports mejor entendidos gracias a drivers abiertos, el camino está trazado, aunque quede terreno por cubrir.
Mirando todo lo anterior, el soporte WDDM en ReactOS está dejando de ser una promesa vaga para convertirse en un conjunto de hitos tangibles: drivers de pantalla que inician, modos que negocian bien y monitores que funcionan a plena resolución. Falta escalar la compatibilidad de hardware, completar piezas como WOW64 y seguir afinando Win32k y DWM, pero la dirección es clara y la comunidad ya empuja en esa dirección.
Redactor apasionado del mundo de los bytes y la tecnología en general. Me encanta compartir mis conocimientos a través de la escritura, y eso es lo que haré en este blog, mostrarte todo lo más interesante sobre gadgets, software, hardware, tendencias tecnológicas, y más. Mi objetivo es ayudarte a navegar por el mundo digital de forma sencilla y entretenida.