Wine 11 reescribe a nivel de kernel cómo Linux ejecuta juegos de Windows y logra grandes mejoras de rendimiento

• Se rediseñó por completo a nivel de kernel la arquitectura para ejecutar juegos de Windows en Linux, eliminando el cuello de botella de sincronización basado en wineserver
• El nuevo driver NTSYNC procesa directamente en el kernel los objetos de sincronización de NT y registra mejoras de FPS de hasta más de 8 veces
• Con la finalización de WoW64, ahora es posible ejecutar aplicaciones de Windows de 32 bits en Linux de 64 bits sin bibliotecas adicionales
• Mejoras en el driver Wayland, soporte para Vulkan 1.4 y mejoras en Bluetooth y force feedback amplían la compatibilidad en gráficos y entrada/salida
• El efecto de mejora en rendimiento y estabilidad se extiende a todo el ecosistema basado en Wine, como Proton, SteamOS y Lutris

---

Cambios clave en Wine 11

• Wine 11 no es solo una actualización anual, sino una gran renovación que reescribe a nivel de kernel cómo Linux ejecuta juegos de Windows

  • Además de años de correcciones acumuladas de errores y mejoras de rendimiento, incluye cambios estructurales como soporte para NTSYNC, finalización de WoW64 y refuerzo del driver Wayland
  • Las mejoras de rendimiento también se expanden a proyectos basados en Wine como Proton y SteamOS

Limitaciones anteriores y soluciones temporales

• En el pasado, Wine no podía implementar perfectamente en Linux las primitivas de sincronización NT de Windows (mutex, semaphore, event, etc.)
  • Para sincronizar entre hilos, debía hacer llamadas RPC a wineserver cada vez, y miles de llamadas por segundo provocaban retrasos de fotogramas y tiempos irregulares
• Esync redujo las llamadas a wineserver usando eventfd, pero generaba problemas por los límites de descriptores de archivo
• Fsync es más rápido al basarse en futex, pero requiere parches fuera del kernel principal, por lo que su uso es difícil en distribuciones comunes
  • futex_waitv de Linux 5.16 difiere del diseño original de Fsync y no es un reemplazo completo
• Ambos métodos eran soluciones temporales y no podían implementar con precisión algunas API NT (por ejemplo, NtPulseEvent y el modo wait-for-all de NtWaitForMultipleObjects)

NTSYNC — rediseño de la sincronización a nivel de kernel

• NTSYNC agrega un nuevo driver de dispositivo /dev/ntsync al kernel de Linux para modelar directamente los objetos de sincronización NT de Windows
  • La sincronización se procesa dentro del kernel en lugar de espacio de usuario, eliminando los viajes de ida y vuelta a wineserver
  • El kernel maneja directamente la administración de colas, la semántica de eventos y las operaciones atómicas
• La desarrolladora es Elizabeth Figura, creadora de Esync y Fsync; lo presentó en la Linux Plumbers Conference de 2023 y luego se integró en Linux 6.14

• Cifras de mejora de rendimiento

  • Dirt 3: 110.6 → 860.7 FPS (mejora de 678%)
  • Resident Evil 2: 26 → 77 FPS
  • Call of Juarez: 99.8 → 224.1 FPS
  • Tiny Tina’s Wonderlands: 130 → 360 FPS
  • Call of Duty: Black Ops I quedó en estado completamente jugable

• Diferencias frente a fsync

  • Para quienes ya usan fsync, la mejora puede ser limitada, pero en juegos con cuellos de botella multihilo las mejoras son drásticas
  • Al estar incluido en el kernel principal, ya no requiere parches adicionales y puede usarse de inmediato en distribuciones recientes como Fedora 42 y Ubuntu 25.04
  • Viene habilitado por defecto en la beta de SteamOS 3.7.20 y también está activado en Proton GE
  • NTSYNC es el primer caso en la historia de Wine que logra una implementación precisa de sincronización a nivel de kernel

WoW64 completado — integración de la compatibilidad de 32 bits

• La implementación de la arquitectura WoW64 (Windows 32-bit on Windows 64-bit) quedó completada en Wine 11
  • En sistemas Linux de 64 bits, ya no hace falta instalar bibliotecas adicionales de 32 bits para ejecutar aplicaciones de Windows de 32 bits
  • Un único binario detecta automáticamente la arquitectura del ejecutable y la maneja
• Incluye mapeo de memoria OpenGL, passthrough SCSI y hasta soporte para aplicaciones de 16 bits
  • Incluso puede ejecutar software antiguo de Windows de la década de 1990
• Antes, las diferencias de configuración multilib entre distribuciones dificultaban la ejecución, pero ahora Wine lo resuelve internamente

Wayland y otras mejoras importantes

• Driver Wayland

  • La copia bidireccional del portapapeles, el soporte para arrastrar y soltar y el escalado del compositor al cambiar de resolución mejoran la compatibilidad con juegos antiguos
  • Se resuelven en gran medida los problemas de compatibilidad de Wine al pasar de X11 a Wayland

• Gráficos y multimedia

  • En X11, EGL pasa a ser el backend OpenGL predeterminado, reemplazando a GLX
  • Se añade soporte para Vulkan 1.4 y decodificación por hardware H.264 basada en Vulkan Video

• Entrada/salida y periféricos

  • Las mejoras en force feedback refuerzan la compatibilidad con volantes de carreras y joysticks de vuelo

  • Soporte para servicios Bluetooth BLE y emparejamiento**,** mejoras en el procesamiento de soundfonts MIDI

    • Se añaden funciones de compresión Zip64, Unicode 17.0.0, escaneo TWAIN 2.0 (64 bits) e IPv6 ping

• Rendimiento y expansión de plataforma

  • Mejora la gestión de prioridad de hilos en Linux y macOS, elevando el rendimiento multihilo
  • Se añade soporte para simular tamaño de página de 4K en ARM64, asegurando compatibilidad en dispositivos Linux basados en ARM

Compatibilidad de juegos y corrección de errores

• Mejora la compatibilidad con títulos importantes como Nioh 2, StarCraft 2, The Witcher 2, Call of Duty: Black Ops II, Final Fantasy XI y Battle.net
• Incluye cientos de correcciones de errores, con mejoras generales en estabilidad y rendimiento

Evaluación general

• La combinación de NTSYNC, WoW64 completado, mejoras en Wayland y correcciones masivas de errores convierte a Wine 11 en el lanzamiento más importante desde Proton
• Mejora el rendimiento y la compatibilidad en todos los proyectos basados en Wine, incluidos Proton, Lutris y Bottles
• Para quienes juegan en Linux, Wine 11 es una versión que definitivamente vale la pena probar

[kh0324]

En conclusión, esto probablemente terminará rompiendo otra vez la compatibilidad con versiones anteriores de varios años de juegos viejos...

Parece que ese es el intercambio equivalente.

[GN⁺]

Comentarios en Hacker News

• Siento un respeto casi infinito por el proyecto Wine
  Intentar reproducir durante 30 años el comportamiento documentado y no documentado de Windows suena como un trabajo tedioso y poco gratificante, pero gracias a eso Wine se volvió un producto realmente útil
  Sobre todo cuando ves juegos viejos funcionando mejor que en Windows, te das cuenta de la enorme atención al detalle y la tolerancia al sufrimiento que requiere

  • Antes evitaba jugar en Linux porque pensaba que Wine no podía funcionar bien de verdad
    A veces probaba algún juego sencillo y pensaba “¿esto sí funciona?”, pero no creía que fuera confiable
    Ahora admito que ese juicio estaba completamente equivocado
  • Aunque es un proyecto realmente excelente, da pena que las apps empresariales como Word, Excel y Outlook todavía no funcionen bien
    Dicen que Excel 2010 fue la última versión en recibir calificación Platinum
    Es interesante que estas apps sean más difíciles que los juegos
  • Wine ejecuta automáticamente pruebas de compatibilidad en varias plataformas
    Si ves la página de resultados de pruebas, queda claro que esta validación sistemática es clave para lograr una alta compatibilidad
  • También vale la pena mencionar ReactOS
    Mucho del conocimiento obtenido en ese proyecto ha fluido hacia el desarrollo de Wine
  • En los 90, cuando usaba OS/2, para correr apps de Windows había que levantar Windows completo
    En ese tiempo quería hacer algo como Wine por mi cuenta, pero no tenía los conocimientos
    Ahora solo uso Linux para servidores, y he oído que también existe Wine para Mac, pero no tengo ninguna app de Windows que realmente quiera ejecutar

• Me sorprendió ver que los cuadros por segundo en juegos subieron muchísimo gracias a Proton
  Que Dirt 3 pase de 110 FPS a 860 FPS, y Resident Evil 2 de 26 FPS a 77 FPS, suena difícil de creer
  Creo que eso fue posible porque Valve le metió mucho dinero al tema

  • Aun así, estas cifras comparan Wine+ntsync con la versión base de Wine, así que hay algo de exageración
    Si se compara con Wine basado en fsync, la mejora es solo de unos cuantos puntos porcentuales
    Aun así, ntsync es claramente una mejora
    Si ves la documentación de ntsync, se trata de un driver de kernel para implementar de forma más precisa en Linux las estructuras de sincronización de Windows
  • También hay que tener cuidado con que la comparación es “cuando no se usaba esync ni fsync”
  • Tengo curiosidad por la relación entre Proton y Wine: quiero saber si Proton es solo el nombre para Valve/SteamOS o si es un proyecto aparte

• También hay quien dice que no hay que emocionarse demasiado con la mejora de rendimiento de ntsync
  En la mayoría de los casos, la mejora es de un solo dígito porcentual, y algunos juegos incluso podrían volverse un poco más lentos

  • Para quienes usan un kernel sin parches de fsync, la historia puede ser distinta
  • También salió la opinión de que valdría la pena comparar la diferencia de rendimiento entre Wayland y X11

• Cuando veo este tipo de temas tan de bajo nivel, me da vergüenza sentir que yo solo hago apps CRUD

  • Pero CRUD también tiene valor, y además es bueno para la salud mental
    Una vez escuché la historia de un desarrollador brillante que, tras sufrir por plazos extremos, terminó cambiándose a un trabajo sencillo de CRUD en VB y decía que era “como vacaciones pagadas”
  • Yo también ayudo con cosas simples en Outlook, del tipo “haz clic aquí, luego allá”, pero ese trabajo también es esencial
  • En sentido contrario, dicen que incluso los desarrolladores de bajo nivel sienten que les faltan habilidades cuando tienen que lidiar con sistemas de alto nivel
  • Incluso yo, que hago compiladores, he intentado varias veces construir apps CRUD para proyectos personales y he fracasado
    Probé con Rails, Phoenix y Django, pero no fue nada fácil
    Últimamente he avanzado un poco con ayuda de Claude
  • Las apps CRUD tampoco son cosa menor
    Los requisitos empresariales son tan complejos que la arquitectura puede venirse abajo fácilmente

• Me alegra saber que los miles de dólares que gasté en Valve terminaron usándose para mejorar Wine
  Me da curiosidad cuántos desarrolladores y contratistas ha contratado Valve para esto

  • Dos tercios de los desarrolladores de Wine pertenecen a CodeWeavers, que tiene contrato con Valve y Proton
    O sea, la mayor parte del financiamiento termina yendo por ahí

• Paradójicamente, Wine podría ser autodestructivo
  Si los juegos funcionan bien en Linux, los desarrolladores podrían hacer puertos nativos para Linux y Wine dejaría de ser necesario

  • Pero como la API de Wine es más estable que Linux, incluso podría pasar que Wine se vuelva un objetivo de primera clase
  • En realidad, creo que ocurre lo contrario
    Aunque exista un puerto nativo, ejecutar la versión de Windows con Proton suele ser más estable
    La API de Windows es familiar y no cambia, así que los desarrolladores siguen desarrollando con eso como referencia
  • Hoy en día, “soporte para Linux” en realidad significa hacer que funcione bien en Proton
  • Creo que este tipo de situación es un “buen problema”
  • Además, Wine se usa para muchas más cosas aparte de los juegos, así que aunque aumenten los puertos nativos, la demanda seguirá existiendo
    Como el ABI de Windows sigue siendo más estable, mientras la diferencia de rendimiento sea mínima, resulta más eficiente mantener solo el build de Windows

• Hubo una pregunta sobre si no sería posible implementar ntsync en espacio de usuario usando memoria compartida
  Claude explicó que “para el 95% de los juegos bastaba un enfoque simple, así que no hubo motivación para implementar una lógica compleja de memoria compartida, y cuando la precisión se volvió importante, lo natural fue moverlo al kernel”

  • Pero en la práctica eso es imposible porque Linux no ofrece ese tipo de funcionalidad en espacio de usuario
    ntsync no es solo un wrapper de API, sino un adaptador a nivel kernel que reproduce el comportamiento de sincronización del kernel NT
    Si ves el código fuente, está estrechamente integrado con el scheduler del kernel
  • La documentación del kernel también deja claro que “una implementación en espacio de usuario no puede igualar el rendimiento y la precisión al nivel de Windows”
    Enlace a la documentación

• Es sorprendente ver que Linux reimplemente Windows y encima lo haga mejor
  En un momento en que Microsoft vuelve cada vez más incómodo su propio software, este logro es impresionante

  • En especial, tiene mucho valor que Wine mantenga el soporte de 16 bits que desapareció en Windows de 64 bits
    Muchos juegos antiguos están basados en 16 bits, y aun en juegos de 32 bits, a veces el instalador es de 16 bits

• Si algún desarrollador de Wine ve esta publicación, ojalá haga una charla relacionada en Carolina Code Conference 2026
  La convocatoria para ponentes está abierta hasta el 31 de marzo

• Si quieres lo mismo en macOS, puedes contribuir a este repositorio

  • Pero, siendo sinceros, hay tan pocos juegos para macOS que probablemente casi no haya desarrolladores interesados
    Tengo recuerdos de jugar Bolo, el juego de tanques, en las Mac de la escuela, pero no creo que llegue ni al 1% de la cantidad de juegos de Windows
  • Pero si por razones de rendimiento había que meterlo en el kernel, entonces me pregunto por qué Linux no lo hizo en espacio de usuario