Wine: qué es y cómo corre apps de Windows sin emular

⏱️ Lectura: 16 min

El 18 de octubre de 2026, el desarrollador Thomas Frohwein envió a la lista openbsd-ports un port experimental que lleva Wine en Linux también a OpenBSD. El detalle técnico que lo hizo posible: emular por software el registro de segmento %gs, porque OpenBSD no permite fijar su base directamente. Con ese obstáculo resuelto, docenas de programas de Windows de 64 bits (desde Notepad++ hasta el remaster de The Witcher 3) ya corren sobre un sistema que durante tres décadas no tuvo ningún interés en la compatibilidad con Windows.

📑 En este artículo

1. TL;DR
2. ¿Qué es Wine?
3. Por qué importa el port a OpenBSD
4. Cómo funciona Wine por dentro
5. Ejemplos de código y cómo empezar con Wine en Linux
6. Casos de uso reales
7. Errores comunes y buenas prácticas
8. Wine en Linux comparado con otras alternativas
9. Profundizando: el problema del registro %gs y WoW64
10. Preguntas frecuentes
    1. ¿Wine en Linux necesita una licencia de Windows?
    2. ¿Qué diferencia hay entre Wine y Proton?
    3. ¿Por qué algunos programas de Windows no funcionan con Wine?
    4. ¿Es seguro instalar un .exe desconocido con Wine?
    5. ¿Corren juegos de 32 bits en el nuevo port de Wine a OpenBSD?
    6. ¿CrossOver es lo mismo que Wine?
11. Referencias
    1. 📚 Artículos relacionados

Que esto ocurra justo cuando la mayoría del software de Windows ya es de 64 bits no es casualidad.

TL;DR

• Wine traduce llamadas de la API de Windows a llamadas POSIX nativas, sin emular el procesador.
• Un port experimental suma Wine a OpenBSD desde el 18 de octubre de 2026 emulando el registro %gs.
• WoW64 sigue sin funcionar en ese port: solo corren programas Windows de 64 bits, no los de 32.
• WINEARCH y WINEPREFIX permiten tener varias versiones de Windows simuladas en la misma máquina.
• Proton de Valve y CrossOver de CodeWeavers usan el mismo motor de traducción que Wine.

¿Qué es Wine?

Wine es una capa de compatibilidad de código abierto que traduce llamadas de la API de Windows a llamadas equivalentes del sistema operativo anfitrión, sin emular el procesador ni usar una máquina virtual; permite correr Wine en Linux, macOS, FreeBSD y, desde octubre de 2026, también en OpenBSD.

El proyecto arrancó en 1993, antes incluso de que existiera Windows 95, pensado originalmente para correr aplicaciones de 16 bits de Windows 3.1 sobre Linux. Desde entonces se extendió a macOS, FreeBSD, NetBSD y Solaris; OpenBSD era, hasta este anuncio, uno de los pocos sistemas Unix mayores sin un port siquiera experimental.

El nombre es un acrónimo recursivo, Wine Is Not an Emulator, es decir «Wine no es un emulador». La distinción importa porque emuladores como QEMU o DOSBox interpretan instrucción por instrucción de otro procesador, lo que cuesta rendimiento. Wine, en cambio, deja que el procesador ejecute el código x86 nativo del programa de Windows tal cual; solo reemplaza las bibliotecas del sistema que ese programa llama (kernel32.dll, user32.dll, ntdll.dll) por versiones propias que traducen cada función a su equivalente en Linux, macOS o BSD.

Por eso un programa de Windows corre bajo Wine casi a la misma velocidad que en Windows real: la CPU no tiene que traducir nada, solo las llamadas al sistema operativo cambian de destino. El proyecto WineHQ mantiene además un catálogo público, el AppDB, donde la comunidad califica miles de programas según cuán bien funcionan antes de que alguien los instale.

Por qué importa el port a OpenBSD

OpenBSD es, dentro del mundo Unix, el sistema que más desconfía del código ajeno: su equipo prioriza la auditoría de código y el aislamiento por encima de la compatibilidad. Que ese proyecto reciba un port de Wine confirma un cambio real: la mayoría del software para Windows que la gente todavía necesita ya es de 64 bits, no de 32.

El propio Frohwein lo resume en el anuncio: hay un interés creciente por Wine distinto al de hace 5 o 10 años, justamente porque buena parte del software para Windows se mudó a 64 bits en ese tiempo. Eso simplifica el trabajo de un port nuevo. No hace falta resolver WoW64 (la capa que permite correr binarios de 32 bits sobre un Windows de 64 bits) para que el port ya sea útil con el software actual.

En la práctica, el equipo probó decenas de programas de 64 bits con éxito, documentados con capturas y grabaciones en vivo. El caso más vistoso es el remaster de The Witcher 3, publicado apenas un mes antes del anuncio, que corre agregando vkd3d-proton para traducir las llamadas de Direct3D 12 a Vulkan.

Cómo funciona Wine por dentro

Un ejecutable de Windows (.exe) usa el formato PE (Portable Executable). Wine incluye su propio cargador de PE: un programa que lee ese formato, reserva memoria para cada sección y resuelve qué DLL necesita cada función importada, igual que haría el cargador real de Windows.

La diferencia está en qué hay detrás de cada DLL. Wine reimplementa las bibliotecas del sistema de Windows, no copia las de Microsoft, como bibliotecas .dll.so: comparten el nombre y las funciones que exporta una DLL real, pero el código que corre adentro traduce cada llamada a su equivalente POSIX. CreateFileW termina llamando a open(); VirtualAlloc termina llamando a mmap().

sequenceDiagram
    participant App as App de Windows (.exe)
    participant Wine as kernel32.dll.so (Wine)
    participant Kernel as Kernel del sistema
    App->>Wine: CreateFileW("datos.txt")
    Wine->>Kernel: open("datos.txt", O_RDWR)
    Kernel-->>Wine: file descriptor
    Wine-->>App: HANDLE de Windows
    Note over App,Kernel: la CPU ejecuta el codigo x86 del exe sin traducir instrucciones

Esa reescritura puede ir por dos caminos cuando el programa necesita una DLL que Wine no reimplementa del todo: usar la versión builtin (la de Wine) o cargar la DLL nativa de Windows si el usuario la copió a mano, algo configurable por proceso con la variable WINEDLLOVERRIDES. Esta flexibilidad explica por qué algunos juegos necesitan que el usuario copie una DLL específica, por ejemplo de .NET o de Visual C++, para funcionar: Wine prioriza su propia implementación, pero puede cederle el paso a la original si hace falta.

Ejemplos de código y cómo empezar con Wine en Linux

En Debian o Ubuntu, el paquete se llama wine64 y conviene habilitar los repositorios de 32 bits incluso para correr solo programas de 64 bits, porque algunas bibliotecas base de Wine siguen siendo de 32 bits. En macOS, brew install --cask wine-stable instala la build mantenida por Homebrew.

sudo dpkg --add-architecture i386
sudo apt update
sudo apt install wine64 wine32:i386
wine --version

El último comando confirma que la instalación funcionó: imprime algo como wine-9.0 (el número exacto depende de la versión empaquetada por tu distribución).

wine notepad.exe

La primera vez que se ejecuta cualquier comando de Wine, el programa crea su carpeta de configuración (el «prefix») antes de abrir la ventana. La terminal muestra una línea como esta:

wine: created the configuration directory '/home/usuario/.wine'

Ese directorio ~/.wine es un C: virtual completo: ahí viven el registro de Windows simulado, las carpetas «Program Files» y «Usuarios», y la configuración que controla winecfg.

WINEDEBUG=+loaddll wine notepad.exe 2>&1 | head -3

Esto activa el canal de depuración loaddll, que imprime cada biblioteca que Wine resuelve antes de abrir la ventana. Una línea típica se ve así:

trace:loaddll:load_native_dll Loaded L"C:\windows\system32\kernel32.dll" at 0x7bc00000: builtin

La palabra final, builtin, confirma que esa DLL puntual la resolvió Wine y no una copia nativa de Windows.

#include <windows.h>
#include <stdio.h>

int main(void) {
    printf("Tiempo de actividad reportado por Wine: %lu ms\n", GetTickCount());
    return 0;
}

winegcc -o uptime uptime.c
./uptime

La salida cambia en cada corrida porque GetTickCount() devuelve los milisegundos desde que arrancó el prefix, pero el formato es siempre el mismo, por ejemplo Tiempo de actividad reportado por Wine: 48213028 ms. Lo importante acá es que ./uptime es un binario ELF nativo, no un .exe: winegcc lo enlazó directo contra la implementación de Win32 de Wine, así que corre sin pasar por wine. Esto es Winelib, el otro modo de usar el proyecto además de ejecutar binarios de Windows ya compilados.

Para comprobar qué versión de Windows está reportando un prefix dado, alcanza con pedirle a cmd.exe que se identifique:

wine cmd /c ver

La respuesta depende de la configuración elegida en winecfg (pestaña «Aplicaciones»); por defecto, las versiones recientes de Wine se identifican como Windows 10, con una salida similar a Microsoft Windows [Version 10.0.19043]. Si un programa necesita identificarse como una versión distinta, cambiarla ahí suele resolver errores de «sistema operativo no soportado».

💡 Tip: si solo necesitás un programa puntual y no sabés por dónde empezar, probá winetricks: automatiza la instalación de dependencias comunes (.NET, Visual C++, fuentes) que muchos instaladores de Windows asumen que ya existen.

Casos de uso reales

El uso más masivo de Wine en Linux hoy es el gaming: Proton, el fork que mantiene Valve, agrega a Wine capas como DXVK y VKD3D, traductores de Direct3D a Vulkan, y es la base de los juegos de Steam que corren en Steam Deck sin estar compilados para Linux.

En entornos corporativos, el camino habitual es CrossOver, el producto comercial de CodeWeavers construido sobre el mismo motor: empresas que migran de Windows a Linux pero dependen de un programa contable o de diseño sin versión nativa lo siguen usando ahí, con soporte pagado y perfiles de compatibilidad ya probados por el fabricante.

El port a OpenBSD agrega un tercer caso, más nicho: administradores y usuarios de seguridad que eligen OpenBSD por su modelo de auditoría pero necesitan una herramienta puntual de Windows sin levantar, para eso, una máquina virtual completa. El propio hilo recomienda probar primero con Notepad++, un editor de texto liviano, antes de intentar algo más pesado.

Errores comunes y buenas prácticas

• Tratar a Wine como un emulador de CPU: la confusión lleva a esperar compatibilidad total con cualquier arquitectura; Wine solo traduce la API de Windows en la misma arquitectura x86/x86-64 del host.
• Mezclar todo en un solo prefix: instalar decenas de programas distintos en el ~/.wine por defecto hace que un instalador rompa la configuración de otro. Crear un WINEPREFIX separado por programa complejo evita ese choque.
• No revisar el AppDB antes de instalar: el catálogo de WineHQ clasifica miles de programas por nivel de compatibilidad (Platinum, Gold, Silver, Bronze, Garbage); saltarse esa consulta significa descubrir los problemas conocidos a mano.
• Correr instaladores desconocidos con el usuario normal: Wine no aísla por defecto el acceso a archivos del instalador que ejecuta. El propio anuncio del port a OpenBSD recomienda crear un usuario sin privilegios aparte para probar software nuevo, mientras exploran si unveil(2) puede limitar qué archivos ve cada proceso de Wine.
• Dar por hecho que WoW64 ya funciona en cualquier port: en el port a OpenBSD todavía no corre software de 32 bits. Antes de probar un .exe conviene revisar con file si es PE32 (32 bits) o PE32+ (64 bits).

Wine en Linux comparado con otras alternativas

Frente a una máquina virtual completa, Wine en Linux comparte el mismo kernel que el sistema anfitrión: no hay un segundo sistema operativo arrancando por debajo, por eso un programa abre casi al instante y sin reservar RAM de forma fija.

Profundizando: el problema del registro %gs y WoW64

El bloqueo que durante años frenó un port de Wine a OpenBSD tenía que ver con cómo Windows guarda los datos de cada hilo en x86-64. Windows usa el registro de segmento %gs para apuntar al TEB (Thread Environment Block, el bloque de memoria con los datos propios de cada hilo); cualquier código, incluido el de Wine, necesita que ese registro apunte al lugar correcto para funcionar.

En Linux, Wine fija la base de %gs con una llamada al sistema específica de ese kernel, arch_prctl(ARCH_SET_GS). OpenBSD no expone una forma equivalente de fijar esa base desde espacio de usuario, algo discutido en el hilo previo de openbsd-tech que menciona el propio anuncio. Sin esa pieza, el cargador de Wine no podía arrancar ningún programa.

flowchart TD
    A["Codigo que usa gs:[offset]"] --> B{"Arquitectura soporta set gsbase?"}
    B -->|"si (Linux: arch_prctl)"| C["TEB real via registro de segmento"]
    B -->|"no (OpenBSD)"| D["Interceptar instruccion con prefijo gs"]
    D --> E["Reescribir el acceso contra un TEB emulado en memoria"]
    C --> F["Programa de Windows corre"]
    E --> F

La solución que propone el port, atribuida a Andrii, evita pelear con el kernel. En vez de lograr que OpenBSD fije la base de %gs a nivel de hardware, Wine emula en software cada instrucción que usa el prefijo %gs, reescribiendo ese acceso contra una copia del TEB que mantiene en memoria. Es una emulación acotada a un solo tipo de instrucción, muy distinta de emular el procesador completo como hace QEMU: el resto del programa sigue corriendo con instrucciones x86-64 nativas, sin pasar por ningún interpretador.

Algo similar pasa en Linux con hilos nativos: glibc usa el registro %fs para ubicar los datos locales de cada hilo (TLS), el mismo principio que %gs en Windows, solo que apunta a una estructura distinta. Por eso, cuando un programa de Windows corre bajo Wine en Linux, el sistema termina usando dos registros de segmento con roles distintos al mismo tiempo: %fs para los hilos nativos de Linux y %gs, emulado o no, para el TEB de Windows que necesita el código del programa.

El límite que queda pendiente es WoW64, la capa de Windows (y de Wine) que permite correr binarios de 32 bits arriba de un entorno de 64 bits traduciendo entre ambas convenciones de llamada. Como el port todavía no la implementa, cualquier .exe o .dll de 32 bits es, por ahora, un no-op: ni siquiera llega a arrancar. Antes de probar un programa conviene revisar su arquitectura con file, ya que un PE32 (32 bits) se comporta muy distinto de un PE32+ (64 bits).

⚠️ Ojo: el port a OpenBSD sigue siendo un borrador enviado a revisión (termina con un simple «ok?» en el correo), no un paquete oficial en el árbol de ports todavía. Probarlo hoy implica compilarlo desde el parche adjunto al hilo, no instalarlo con pkg_add.

📖 Resumen en Telegram: Ver resumen

Tu próximo paso: instalá wine64 en una VM o contenedor descartable, corré wine notepad.exe y mirá con WINEDEBUG=+loaddll qué DLL resuelve antes de abrir la ventana.

Preguntas frecuentes

¿Wine en Linux necesita una licencia de Windows?

No. Wine no copia ni distribuye código de Microsoft: reimplementa desde cero las funciones de las DLL del sistema. El propio proyecto aclara en su FAQ oficial que ejecutar un programa con Wine no requiere ninguna licencia de Windows, aunque sí conviene revisar la licencia del programa que se quiere correr.

¿Qué diferencia hay entre Wine y Proton?

Proton es el fork que mantiene Valve para Steam: parte del mismo motor de traducción de Wine y le agrega DXVK y VKD3D, para traducir Direct3D a Vulkan, además de parches específicos para juegos. Muchas de esas mejoras terminan subiendo de vuelta al proyecto original.

¿Por qué algunos programas de Windows no funcionan con Wine?

Porque la compatibilidad depende de qué funciones de la API usa cada programa. Software con anticheat a nivel de kernel, drivers propios o protecciones agresivas contra copia suele fallar porque esas piezas esperan un kernel real de Windows. Antes de instalar algo, conviene revisar su calificación en el AppDB de WineHQ.

¿Es seguro instalar un .exe desconocido con Wine?

No por defecto: Wine no aísla automáticamente qué archivos puede tocar el instalador que corre. La recomendación del propio anuncio del port a OpenBSD, crear un usuario sin privilegios dedicado a probar software nuevo, aplica para cualquier sistema donde se use Wine.

¿Corren juegos de 32 bits en el nuevo port de Wine a OpenBSD?

Todavía no. El port carece de WoW64, la capa que traduce entre binarios de 32 y 64 bits, así que cualquier .exe de 32 bits es un no-op. Solo corre software Windows compilado nativamente para 64 bits.

¿CrossOver es lo mismo que Wine?

CrossOver usa el mismo motor que Wine por debajo, pero es un producto comercial de CodeWeavers con soporte pagado, perfiles de compatibilidad ya probados y, muchas veces, parches que todavía no llegaron a la versión libre del proyecto.

Referencias

• Lista openbsd-ports: el anuncio original del port de Wine a OpenBSD, 18 de octubre de 2026.
• WineHQ: sitio oficial del proyecto Wine, con documentación y el catálogo AppDB de compatibilidad.
• FAQ oficial de Wine: preguntas frecuentes del proyecto, incluida la sección sobre seguridad y malware.
• vkd3d-proton: la capa que traduce Direct3D 12 a Vulkan usada para correr el remaster de The Witcher 3 en el port.
• Wine (software) en Wikipedia: historia y arquitectura general del proyecto, activo desde 1993.

📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.

Imagen destacada: Foto de Rob Wingate en Unsplash