En 2012, Microsoft presentó Windows 8 y con él una nueva filosofía: cerrar progresivamente la plataforma al modelo de Apple, con su tienda oficial, sus controles y sus restricciones. Para la mayoría de usuarios aquello fue una molestia. Para Gabe Newell, fundador de Valve y responsable de Steam, fue una señal de alarma. Si Windows cerraba el acceso al software, Steam, que llevaba más de una década siendo la tienda de juegos de PC por excelencia, podría quedar a merced de las decisiones de Microsoft. La respuesta de Valve fue apostar por Linux. Lo que nadie esperaba era cómo iban a conseguirlo.
El origen de Wine: un proyecto imposible que nació en 1993
El problema de Linux en los años 90
Linux nació en 1992 y rápidamente atrajo a una comunidad de programadores e ingenieros fascinados por la idea de un sistema operativo libre, gratuito y construido por la propia comunidad. Pero tenía un problema fundamental: casi no había software disponible para él. El sistema dominante era MS-DOS de Microsoft, y toda la industria del software estaba construida sobre él y sobre Windows, que en aquella época no era más que una interfaz gráfica que corría encima de MS-DOS.
En 1992, Bob Amstad, un ingeniero estadounidense, instaló Linux para usarlo como servidor de correo. Enseguida le vio el problema: faltaba software. La comunidad ya había creado un emulador de MS-DOS llamado DOSemu, que permitía ejecutar programas de MS-DOS en Linux. Pero Windows era otra cosa.
El debate que lo inició todo
En la comunidad de Linux empezó a surgir una pregunta: ¿sería posible ejecutar programas de Windows directamente en Linux? Microsoft nunca lo haría (años después, el CEO Steve Ballmer llegaría a calificar Linux de «un cáncer»), así que si iba a ocurrir, tendría que hacerlo la propia comunidad. Los debates técnicos en los foros de la época eran muy pesimistas: la API de Windows, sus librerías, sus llamadas no documentadas… parecía imposible.
Bob Amstad se lanzó igualmente. El 17 de septiembre de 1993 publicó el mensaje original que anunciaba el proyecto: Wine – Windows Emulation Project Mailing List. Se apuntaron unas 700 personas y el proyecto arrancó en medio del caos habitual de cualquier iniciativa colaborativa de esa escala.
Alexander Julliard y el primer solitario
Entre toda esa energía desorganizada apareció un programador suizo que trabajaba en francés: Alexandre Julliard. No llegó con discursos ni teorías. Llegó con código. Consiguió lanzar el juego del solitario de Windows dentro de Linux. Iba lento y no funcionaba perfectamente, pero funcionaba. Julliard tomó el liderazgo técnico del proyecto, organizó el repositorio y convirtió a Wine en algo dirigido y coherente.
Desde afuera, la situación tenía algo de absurdo: cientos de personas trabajando gratis, en su tiempo libre, para conseguir ejecutar el solitario en otro sistema operativo. Pero Wine tenía una carga simbólica mucho mayor. Para la comunidad de Linux, el proyecto representaba la libertad de no depender de Microsoft.
Cómo funciona Windows por dentro: la explicación necesaria
Para entender qué hizo Wine exactamente, primero hay que entender cómo gestiona Windows los recursos del sistema.
El kernel y las librerías de sistema
Un programa es una serie de instrucciones para el procesador. Pero el procesador solo sabe hacer cálculos, mover datos en memoria y operaciones lógicas. Todo lo demás (acceder al disco, mostrar algo en pantalla, leer el teclado, conectarse a internet) requiere intermediarios.
El kernel es el núcleo del sistema operativo: el programa que gestiona todos los recursos del hardware y decide quién puede acceder a qué. Es el director de la orquesta, pero no habla directamente con los programas normales. Para comunicarse con el kernel, los programas usan las librerías de sistema, un conjunto de funciones que hacen de intermediarias.
En Windows, estas librerías son los archivos DLL (Dynamic Link Libraries). Hay DLLs específicas que vienen instaladas con Windows y que son los canales oficiales para acceder a todos los recursos del sistema. Su funcionamiento interno es privado: Microsoft documenta cómo usarlas, pero no cómo funcionan por dentro. El kernel de Windows se encuentra en C:\Windows\System32\ntoskrnl.exe.
En Linux el sistema es equivalente pero completamente distinto en su implementación. Las librerías se llaman .so (shared objects) y, a diferencia de Windows, todo el código es público y abierto. Además, Linux permite que cualquier programa haga llamadas directas al kernel, algo que Windows no permite de forma general.
El formato de los ejecutables
Los programas de Windows se guardan en archivos .exe con un formato interno llamado PE (Portable Executable). Linux usa un formato completamente diferente llamado ELF (Executable and Linkable Format). Un sistema Linux no sabe qué hacer con un archivo PE: no lo reconoce como ejecutable.
La idea genial de Wine: no emular, traducir
Con este contexto, la solución de Wine se puede explicar con claridad. No es un emulador. Wine es una implementación libre de la API de Windows para Linux.
¿Qué significa esto? La comunidad de Wine estudió toda la documentación pública de las DLLs de Windows, las probó sistemáticamente con ingeniería inversa (enviando todo tipo de datos, casos límite, situaciones raras) hasta entender exactamente cómo se comportaban, y luego programó esas mismas DLLs desde cero para Linux: mismos nombres, mismos mensajes de entrada y salida, mismo comportamiento observable. La diferencia es que estas DLLs alternativas, en lugar de hablar con el kernel de Windows, hablan directamente con el kernel de Linux.
Además, Wine incluye un cargador de ejecutables PE para Linux. Esto permite que cuando el usuario ejecuta un .exe mediante Wine, Linux lo cargue en memoria como si fuera un proceso nativo.
El resultado práctico: el programa de Windows se ejecuta, llama a las librerías que espera encontrar, esas librerías responden exactamente como esperaba, y el programa no tiene manera de saber que no está en Windows. Todo funciona porque cada mensaje enviado al sistema recibe la respuesta correcta.
La distinción con un emulador es importante. Un emulador simula el hardware completo (como los emuladores de Game Boy que reproducen el procesador Sharp LR35902). Wine no emula nada: como tanto Windows como Linux están diseñados para ejecutarse en procesadores x86, el código del programa se ejecuta directamente sin traducción. Solo se interceptan las llamadas al sistema.
El problema de los gráficos: DirectX y el cuello de botella
Wine funcionaba razonablemente bien para aplicaciones de oficina, pero los videojuegos eran otro problema. Los juegos usaban DirectX, la API gráfica de Microsoft.
Por qué DirectX era diferente
En los primeros años de las tarjetas gráficas, cada fabricante (3dfx, ATI, Nvidia) tenía su propia forma de comunicarse con sus productos. Era un caos de incompatibilidades. Microsoft creó DirectX como capa universal: el juego habla con DirectX, y DirectX habla con los drivers de cada tarjeta en un lenguaje estándar. Todos los fabricantes adaptaron sus drivers para entender DirectX y así el problema se resolvió, pero el precio fue que DirectX quedó ligado completamente a Windows.
Para Wine, la solución inicial fue interceptar las llamadas a DirectX y traducirlas a OpenGL, la alternativa abierta. Pero la traducción era imperfecta. DirectX y OpenGL tienen modelos internos diferentes, y a medida que DirectX añadía funcionalidades más complejas, la traducción se volvía cada vez más difícil de mantener con buen rendimiento.
La revolución de Vulkan
En 2013, AMD presentó Mantle, una API gráfica de bajo nivel propia que ofrecía mucho mejor rendimiento que OpenGL. Un año después, AMD hizo algo histórico: regaló Mantle al consorcio Khronos Group, los mismos que mantenían OpenGL. En 2016, Khronos usó Mantle como base para crear Vulkan, una API gráfica multiplataforma, de bajo nivel, disponible para Windows, Linux y Android desde el primer día.
Vulkan cambió las reglas. Ya no había que conformarse con OpenGL como alternativa a DirectX en Linux.
DXVK: la pieza que lo cambió todo
En 2017, un programador alemán conocido como Philip Rebll, frustrado con el mal port de Nier: Automata en PC (especialmente en Linux), identificó el problema: la traducción de DirectX a OpenGL dentro de Wine era el cuello de botella. Su solución fue crear DXVK: un traductor de DirectX 9, 10 y 11 a Vulkan.
La diferencia fue inmediata y enorme. DirectX y Vulkan tienen modelos suficientemente similares como para que la traducción sea casi directa, sin apenas carga adicional. Los juegos en Linux empezaron a rendir con un rendimiento prácticamente igual al de Windows, y en algunos títulos incluso superior.
Valve, Proton y la Steam Deck
Codeweavers y la comercialización de Wine
En 1999, Jeremy White fundó Codeweavers, una empresa que tomó Wine como base para crear Crossover: un producto comercial que permitía instalar y usar programas de Windows en Linux y Mac de forma sencilla, sin configuraciones complejas. Jeremy White contrató a Alexandre Julliard como director técnico, dándole por primera vez continuidad económica al proyecto. Crossover Office 2002 fue el primer producto que permitía usar Microsoft Office en Linux de forma relativamente fiable.
El problema de Windows 8 y la apuesta de Valve
Cuando llegó Windows 8 en 2012, Gabe Newell lo vio como una amenaza estructural para Steam: si Microsoft cerraba la plataforma y potenciaba su propia tienda, Steam quedaba en una posición vulnerable. La solución fue Linux. En 2013 Valve anunció las Steam Machines y SteamOS, consolas basadas en Linux. La apuesta llegó demasiado pronto y fracasó: no había suficientes juegos disponibles para Linux.
Pero Valve no abandonó. Siguió trabajando con Codeweavers desde 2014, financiando mejoras en Wine específicamente orientadas a que los juegos de Steam funcionaran en Linux. Cuando apareció DXVK en 2017, la pieza que faltaba estaba por fin disponible.
Qué es Proton exactamente
En 2018, Valve lanzó Proton. Proton no es solo Wine. Es un conjunto de tecnologías integradas:
- Wine como base: el cargador de ejecutables PE y la implementación de la API de Windows.
- DXVK integrado por defecto: traducción de DirectX 9, 10 y 11 a Vulkan.
- VKD3D-Proton: traducción de DirectX 12 a Vulkan, desarrollado por Valve.
- Módulos propios de Valve: integración con la nube de Steam, sincronización de logros, guardado de partidas.
- Configuraciones por juego: parches y ajustes específicos para cada título que Valve ha probado y validado.
La clave de Proton no es solo la tecnología sino la integración. El usuario no instala nada, no configura nada. Abre Steam en Linux y los juegos compatibles simplemente funcionan.
La Steam Deck como prueba definitiva
En 2022, Valve lanzó la Steam Deck, una consola portátil basada completamente en Linux. En un dispositivo donde cada vatio y cada fotograma son críticos, Proton demostró que era capaz de ejecutar juegos diseñados exclusivamente para Windows con una experiencia pulida y optimizada. Ninguno de esos juegos fue pensado para ejecutarse en Linux. Todos corren sobre una capa de traducción que convierte en tiempo real las instrucciones pensadas para Windows en instrucciones que Linux puede ejecutar nativamente.
El estado actual y los límites de Proton
Proton no es infalible. La Steam Deck funciona especialmente bien porque el hardware es siempre idéntico y Valve controla el sistema operativo al completo. En un PC Linux de propósito general, la variabilidad de hardware y configuraciones hace que algunos juegos sigan teniendo problemas.
El talón de Aquiles más visible son los sistemas anti-cheat: juegos como Fortnite, Apex Legends o Destiny 2 usan software de protección que no es compatible con Proton, lo que los hace injugables en Linux por esta vía.
La estrategia de Valve a largo plazo parece clara: hacer crecer el ecosistema Linux lo suficiente como para que los propios desarrolladores tengan incentivos para portar sus juegos de forma nativa, eliminando la necesidad de la capa de traducción. Si las consolas basadas en Linux de Valve alcanzan una base de usuarios significativa, la ecuación económica cambia para los estudios de videojuegos.
Por ahora, lo que Wine, DXVK y Proton han logrado juntos es algo que en 1993 parecía literalmente imposible: que un sistema operativo libre, construido por la comunidad, pueda ejecutar prácticamente cualquier juego diseñado para Windows con un rendimiento equivalente al original.
¿Usas Linux como sistema operativo principal o te has animado a probar la Steam Deck? Cuéntanos tu experiencia en los comentarios.
