Vino (software)
Wine es una capa de compatibilidad gratuita y de código abierto que tiene como objetivo permitir que el software de aplicación y los juegos de computadora desarrollados para Microsoft Windows se ejecuten en sistemas operativos similares a Unix. Wine también proporciona una biblioteca de software, llamada Winelib, contra la cual los desarrolladores pueden compilar aplicaciones de Windows para ayudar a migrarlas a sistemas similares a Unix.
Wine proporciona su capa de compatibilidad para el sistema de tiempo de ejecución de Windows (también llamado entorno de tiempo de ejecución) que traduce las llamadas a la API de Windows en llamadas a la API de POSIX, recreando la estructura de directorios de Windows y proporcionando implementaciones alternativas de bibliotecas del sistema de Windows, servicios del sistema a través de wineserver
y varios otros componentes (como Internet Explorer, el Editor del Registro de Windows y msiexec). El vino se escribe predominantemente utilizando ingeniería inversa de pruebas de caja negra, para evitar problemas de derechos de autor.
La selección de "Wine is Not an Emulator" ya que el nombre de Wine Project fue el resultado de una discusión de nombres en agosto de 1993 y se le atribuye a David Niemi. Existe cierta confusión causada por una pregunta frecuente anterior que utiliza Emulador de Windows y otras fuentes no válidas que aparecen después de establecer el nombre del proyecto Wine. No se produce emulación de código ni virtualización cuando se ejecuta una aplicación de Windows en Wine. "Emulación" por lo general, se referiría a la ejecución de código compilado destinado a un procesador (como x86) mediante la interpretación/recompilación de software que se ejecuta en un procesador diferente (como PowerPC). Si bien el nombre a veces aparece en las formas WINE y wine, los desarrolladores del proyecto acordaron estandarizar la forma Wine.
Wine está desarrollado principalmente para Linux y macOS y, a partir de julio de 2020, hay paquetes bien mantenidos disponibles para ambas plataformas.
En una encuesta realizada en 2007 por desktoplinux.com a 38.500 usuarios de equipos de escritorio Linux, el 31,5 % de los encuestados informaron que usaban Wine para ejecutar aplicaciones de Windows. Esta pluralidad fue mayor que todos los programas de virtualización x86 combinados, así como también mayor que el 27,9 % que informó que no ejecutaba aplicaciones de Windows.
Historia
Bob Amstadt, el líder del proyecto inicial, y Eric Youngdale comenzaron el proyecto Wine en 1993 como una forma de ejecutar aplicaciones de Windows en Linux. Fue inspirado por dos Sun Microsystems' productos, Wabi para el sistema operativo Solaris y Public Windows Initiative, que fue un intento de volver a implementar completamente la API de Windows en el dominio público como un estándar ISO, pero fue rechazado debido a la presión de Microsoft en 1996. Wine originalmente apuntó a 16- aplicaciones de bits para Windows 3.x, pero a partir de 2010 se centra en las versiones de 32 y 64 bits que se han convertido en el estándar en los sistemas operativos más nuevos. El proyecto se originó en discusiones sobre Usenet en comp.os.linux en junio de 1993. Alexandre Julliard ha dirigido el proyecto desde 1994.
El proyecto ha resultado lento y difícil para los desarrolladores, principalmente debido a la documentación incompleta e incorrecta de la API de Windows. Si bien Microsoft documenta ampliamente la mayoría de las funciones de Win32, algunas áreas, como los formatos de archivo y los protocolos, no tienen especificaciones disponibles públicamente de Microsoft, y Windows también incluye funciones de bajo nivel no documentadas, comportamiento no documentado y errores oscuros que Wine debe duplicar con precisión para permitir que algunas aplicaciones para funcionar correctamente. En consecuencia, el equipo de Wine ha realizado ingeniería inversa de muchas llamadas a funciones y formatos de archivo en áreas como el procesamiento de datos.
El proyecto Wine publicó originalmente Wine bajo la misma licencia MIT que el sistema X Window, pero debido a la preocupación de que las versiones propietarias de Wine no contribuyeran con sus cambios al proyecto central, el trabajo a partir de marzo de 2002 ha utilizado la LGPL para su Licencia.
Wine ingresó oficialmente a la versión beta con la versión 0.9 el 25 de octubre de 2005. La versión 1.0 se lanzó el 17 de junio de 2008, luego de 15 años de desarrollo. La versión 1.2 se lanzó el 16 de julio de 2010, la versión 1.4 el 7 de marzo de 2012, la versión 1.6 el 18 de julio de 2013 y la versión 1.8 el 19 de diciembre de 2015. Las versiones de desarrollo se publican aproximadamente cada dos semanas.
Wine-staging es un conjunto independiente de parches agresivos que los desarrolladores de WineHQ no consideran listos para fusionarse con el repositorio de Wine, pero que la bifurcación wine-compholio aún considera útiles. Cubre principalmente funciones experimentales y correcciones de errores. Desde enero de 2017, los parches en la puesta en escena del vino comienzan a fusionarse activamente en WineHQ aguas arriba, ya que wine-compholio transfirió el proyecto a Alistair Leslie-Hughes, un desarrollador clave de WineHQ.
Patrocinio corporativo
El principal patrocinador corporativo de Wine es CodeWeavers, que emplea a Julliard y a muchos otros desarrolladores de Wine para trabajar en Wine y en CrossOver, CodeWeavers' versión compatible de Wine. CrossOver incluye algunos ajustes específicos de la aplicación que no se consideran adecuados para la versión anterior, así como algunos componentes patentados adicionales.
La participación de Corel durante un tiempo ayudó al proyecto, principalmente al contratar a Julliard y otros para trabajar en él. Corel tenía interés en migrar WordPerfect Office, su paquete ofimático, a Linux (especialmente a Corel Linux). Corel luego canceló todos los proyectos relacionados con Linux después de que Microsoft hiciera grandes inversiones en Corel, deteniendo su esfuerzo en Wine.
Otros patrocinadores corporativos incluyen a Google, que contrató a CodeWeavers para arreglar Wine de modo que Picasa funcionara lo suficientemente bien como para trasladarse directamente a Linux utilizando el mismo binario que en Windows; Más tarde, Google pagó por mejoras en el soporte de Wine para Adobe Photoshop CS2. Wine también es un beneficiario habitual del programa Summer of Code de Google.
Diseño
El objetivo de Wine es implementar total o parcialmente las API de Windows que requieren los programas que los usuarios de Wine desean ejecutar sobre un sistema similar a Unix.
Arquitectura básica
La interfaz de programación de Microsoft Windows se compone principalmente de bibliotecas de vínculos dinámicos (DLL). Estos contienen una gran cantidad de subrutinas contenedoras para las llamadas al sistema del kernel, el programa NTOS kernel-mode (ntoskrnl.exe). Un programa típico de Windows llama a algunas DLL de Windows, que a su vez llaman a las bibliotecas gdi/user32 en modo usuario, que a su vez usan el kernel32.dll (subsistema win32) responsable de tratar con el kernel a través de llamadas al sistema. La capa de llamadas al sistema se considera privada para los programadores de Microsoft, ya que la documentación no está disponible públicamente y todas las interfaces publicadas dependen de subsistemas que se ejecutan sobre el núcleo. Además de estos, hay una serie de interfaces de programación implementadas como servicios que se ejecutan como procesos separados. Las aplicaciones se comunican con los servicios en modo usuario a través de RPC.
Wine implementa la interfaz binaria de aplicaciones (ABI) de Windows completamente en el espacio del usuario, en lugar de como un módulo del núcleo. Wine refleja principalmente la jerarquía, con servicios normalmente provistos por el kernel en Windows en lugar de un demonio conocido como wineserver, cuya tarea es implementar la funcionalidad básica de Windows, así como la integración con el sistema X Window y la traducción de señales a nativo. Excepciones de Windows. Aunque Wineserver implementa algunos aspectos del kernel de Windows, no es posible usar controladores nativos de Windows con él, debido a la arquitectura subyacente de Wine.
Bibliotecas y aplicaciones
Wine permite cargar archivos DLL de Windows y objetos compartidos de Unix para sus programas de Windows. Su implementación integrada de las DLL de Windows más básicas, a saber, NTDLL, KERNEL32, GDI32 y USER32, utiliza el método de objeto compartido porque también deben utilizar funciones en el sistema operativo host. Las bibliotecas de nivel superior, como WineD3D, son libres de usar el formato DLL. En muchos casos, los usuarios pueden optar por cargar una DLL desde Windows en lugar de la implementada por Wine. Si lo hace, puede proporcionar funcionalidades que Wine aún no implementa, pero también puede causar fallas de funcionamiento si se basa en algo más que no está presente en Wine.
Wine realiza un seguimiento de su estado de implementación a través de pruebas unitarias automatizadas realizadas en cada confirmación de git.
Gráficos y juegos
Si bien la mayoría del software de oficina no utiliza complejas API de gráficos aceleradas por GPU, los juegos de computadora sí lo hacen. Para ejecutar estos juegos correctamente, Wine tendría que reenviar las instrucciones de dibujo al sistema operativo anfitrión e incluso traducirlas a algo que el anfitrión pueda entender.
DirectX es una colección de API de Microsoft para procesamiento, audio y entrada. A partir de 2019, Wine 4.0 contiene una implementación de DirectX 12 para la API de Vulkan y DirectX 11.2 para OpenGL. Wine 4.0 también permite que Wine ejecute aplicaciones Vulkan entregando comandos de dibujo al sistema operativo host o, en el caso de macOS, traduciéndolos a la API Metal de MoltenVK.
- XAudio
- En febrero de 2019, Wine 4.3 utiliza la biblioteca FAudio (y Wine 4.13 incluyó una solución para ella) para implementar la API de audio XAudio2 (y más).
- XInput and Raw Input
- El vino, desde 4.0 (2019), admite controladores de juego a través de sus implementaciones integradas de estas bibliotecas. Se construyen como objetos compartidos Unix, ya que necesitan acceder a las interfaces de controlador del sistema operativo subyacente, específicamente a través de SDL.
- Direct2D
- Soportes de vino 4.0 Direct2D 1.2.
Direct3D
Gran parte del esfuerzo de DirectX de Wine se dedica a crear WineD3D, una capa de traducción de Direct3D y DirectDraw API llama a OpenGL. A partir de 2019, este componente admite hasta DirectX 11. A partir del 12 de diciembre de 2016, Wine es lo suficientemente bueno para ejecutar Overwatch con D3D11. Además de usarse en Wine, las DLL de WineD3D también se han usado en el propio Windows, lo que permite que las GPU más antiguas ejecuten juegos con versiones más nuevas de DirectX y que los juegos antiguos basados en DDraw se reproduzcan correctamente.
Se está trabajando para trasladar el backend de Direct3D a la API de Vulkan. La compatibilidad con Direct3D 12 en 4.0 la proporciona "vkd3d" subproyecto, y WineD3D se ha portado experimentalmente en 2019 para usar la API de Vulkan. Otra implementación, DXVK, traduce llamadas de Direct3D 9, 10 y 11 usando Vulkan también y es un proyecto separado.
Wine, cuando está parcheado, puede ejecutar alternativamente los comandos de la API de Direct3D 9 directamente a través de un Gallium3D State Tracker gratuito y de código abierto (también conocido como controlador de GPU de Gallium3D) sin traducción a llamadas a la API de OpenGL. En este caso, la capa Gallium3D permite un paso directo de los comandos de dibujo DX9, lo que resulta en mejoras de rendimiento de hasta un factor de 2. A partir de 2020, el proyecto se llama Gallium.Nine. Está disponible ahora como un paquete independiente separado y ya no necesita una versión parcheada de Wine.
Interfaz de usuario
Wine generalmente se invoca desde el intérprete de línea de comandos: wine program.exe
.
Vinocfg
Existe la utilidad winecfg
que inicia una interfaz gráfica de usuario con controles para ajustar las opciones básicas. Es una utilidad de configuración de GUI incluida con Wine. Winecfg facilita la configuración de Wine al hacer innecesario editar el registro directamente, aunque, si es necesario, esto se puede hacer con el editor de registro incluido (similar a regedit de Windows).
Aplicaciones de terceros
Algunas aplicaciones requieren más ajustes que simplemente instalar la aplicación para que funcionen correctamente, como la configuración manual de Wine para usar ciertas DLL de Windows. El proyecto Wine no integra dichas soluciones alternativas en el código base de Wine, sino que prefiere centrarse únicamente en mejorar la implementación de Wine de la API de Windows. Si bien este enfoque enfoca el desarrollo de Wine en la compatibilidad a largo plazo, dificulta que los usuarios ejecuten aplicaciones que requieren soluciones alternativas. En consecuencia, se han creado muchas aplicaciones de terceros para facilitar el uso de aquellas aplicaciones que no funcionan desde el primer momento dentro de Wine. El wiki de Wine mantiene una página de aplicaciones de terceros actuales y obsoletas.
- Winetricks es un script para instalar algunos componentes básicos (típicamente Microsoft DLLs y fuentes) y ajustes de tweak necesarios para que algunas aplicaciones funcionen correctamente bajo Wine. Puede automatizar completamente la instalación de una serie de aplicaciones y juegos, incluyendo la aplicación de cualquier solución de trabajo necesaria. Winetricks tiene un GUI. El proyecto Wine aceptará informes de fallos para usuarios de Winetricks, a diferencia de la mayoría de aplicaciones de terceros. Es mantenido por el desarrollador de vinos Austin Inglés.
- Q4Wine es un GUI abierto para la configuración avanzada del vino.
- Puertas de vino es una herramienta de gestión de aplicaciones para el escritorio GNOME que añade funcionalidad a Wine. Wine-Doors es una alternativa a WineTools que pretende mejorar las características de WineTools y extenderse sobre la idea original con un enfoque de diseño más moderno.
- IEs4Linux es una utilidad para instalar todas las versiones de Internet Explorer, incluyendo versiones 4 a 6 y versión 7 (en beta).
- Wineskin es una utilidad para gestionar Las versiones de los motores del vino y crear envolturas para macOS.
- PlayOnLinux es una aplicación para facilitar la instalación de aplicaciones de Windows (principalmente juegos). También hay una versión Macintosh correspondiente llamada PlayOnMac.
- Lutris es una aplicación de código abierto para instalar fácilmente juegos de Windows en Linux.
- Burdeos es un propietario Gerente de configuración de Wine GUI que dirige aplicaciones de vinlib. También admite la instalación de utilidades de terceros, la instalación de aplicaciones y juegos, y la capacidad de utilizar configuraciones personalizadas. Burdeos Actualmente se ejecuta en computadoras Linux, FreeBSD, PC-BSD, Solaris, OpenSolaris, OpenIndiana y macOS.
- Botellas es un gráfico de código abierto Prefijo de vino y gestor de corredores para Vino basado en GTK. Proporciona un sistema de instalación de dependencia basado en repositorios y versión de botellas para restaurar un estado anterior.
- WineGUI es una interfaz gráfica gratuita y de código abierto para gestionar el vino. Le permite crear fácilmente botellas de vino e instalar aplicaciones o juegos de Windows.
Funcionalidad
Los desarrolladores de las partes de Direct3D de Wine han seguido implementando nuevas funciones, como sombreadores de píxeles, para aumentar la compatibilidad con los juegos. Wine también puede usar archivos DLL nativos directamente, lo que aumenta la funcionalidad, pero luego se necesita una licencia para Windows a menos que los archivos DLL se hayan distribuido con la propia aplicación.
Wine también incluye sus propias implementaciones de código abierto de varios programas de Windows, como Bloc de notas, WordPad, Panel de control, Internet Explorer y Windows Explorer.
La base de datos de aplicaciones de Wine (AppDB) es una base de datos en línea mantenida por la comunidad sobre qué programas de Windows funcionan con Wine y qué tan bien funcionan.
Compatibilidad con versiones anteriores
Wine garantiza una buena compatibilidad con versiones anteriores de las aplicaciones antiguas de Windows, incluidas las escritas para Windows 3.1x. Wine puede imitar diferentes versiones de Windows requeridas para algunos programas, desde la versión 2.0 de Windows. Sin embargo, la compatibilidad con Windows 1.x y Windows 2.x se eliminó de la versión de desarrollo de Wine 1.3.12. Si DOSBox está instalado en el sistema (ver más abajo en MS-DOS), la versión de desarrollo de Wine 1.3.12 y posteriores, sin embargo, mostrarán el "Windows 2.0" opción para que la versión de Windows imite, pero Wine aún no ejecutará la mayoría de los programas de Windows 2.0 porque las funciones de MS-DOS y Windows no están integradas actualmente.
La compatibilidad con versiones anteriores de Wine es generalmente superior a la de Windows, ya que las versiones más nuevas de Windows pueden obligar a los usuarios a actualizar las aplicaciones heredadas de Windows y pueden romper el software abandonado para siempre, ya que nadie ajusta el programa para los cambios en el sistema operativo. En muchos casos, Wine puede ofrecer un mejor soporte heredado que las versiones más nuevas de Windows con "Modo de compatibilidad". Wine puede ejecutar programas de Windows de 16 bits (Win16) en un sistema operativo de 64 bits, que utiliza una CPU x86-64 (64 bits), una funcionalidad que no se encuentra en las versiones de 64 bits de Microsoft Windows. WineVDM permite que las aplicaciones de Windows de 16 bits se ejecuten en versiones de Windows de 64 bits.
Wine es parcialmente compatible con las aplicaciones de la consola de Windows y el usuario puede elegir qué backend usar para administrar la consola (las opciones incluyen flujos sin procesar, curses y user32). Al usar los backends raw streams o curses, las aplicaciones de Windows se ejecutarán en una terminal Unix.
Aplicaciones de 64 bits
En diciembre de 2008, se agregó soporte preliminar para aplicaciones de Windows de 64 bits a Wine 1.1.10. Desde abril de 2019, el soporte se considera estable. Las dos versiones de Wine se construyen por separado y, como resultado, solo compilar wine64 produce un entorno que solo es capaz de ejecutar aplicaciones x86-64.
A partir de abril de 2019, Wine tiene soporte estable para una compilación de WoW64, lo que permite que las aplicaciones de Windows de 32 y 64 bits se ejecuten dentro de la misma instancia de Wine. Para realizar una compilación de este tipo, primero se debe compilar la versión de 64 bits y luego compilar la versión de 32 bits que hace referencia a la versión de 64 bits. Al igual que WoW64 de Microsoft, el proceso de compilación de 32 bits agregará las partes necesarias para manejar programas de 32 bits a la compilación de 64 bits. Esta funcionalidad se ve desde al menos 2010.
MS-DOS
Las primeras versiones de Microsoft Windows se ejecutan sobre MS-DOS, y los programas de Windows pueden depender de los programas de MS-DOS para poder utilizarse. Wine no tiene un buen soporte para MS-DOS, pero a partir de la versión de desarrollo 1.3.12, Wine intenta ejecutar programas de MS-DOS en DOSBox si DOSBox está disponible en el sistema. Sin embargo, debido a un error, las versiones actuales de Wine identifican incorrectamente los programas de Windows 1.x y Windows 2.x como programas de MS-DOS e intentan ejecutarlos en DOSBox (que no funciona).
Winelib
Wine proporciona Winelib, que permite que sus implementaciones de objetos compartidos de la API de Windows se utilicen como bibliotecas reales para un programa Unix. Esto permite que el código de Windows se integre en los ejecutables nativos de Unix. Desde octubre de 2010, Winelib también funciona en la plataforma ARM.
Arquitecturas no x86
La compatibilidad con Solaris SPARC se eliminó en la versión 1.5.26.
ARM, Windows CE y Windows RT
Wine proporciona cierta compatibilidad con los procesadores ARM (así como con ARM64/AArch64) y las variantes de Windows que se ejecutan en él. A partir de abril de 2019, Wine puede ejecutar aplicaciones ARM/Win32 diseñadas para dispositivos Windows RT desbloqueados (pero no programas Windows RT). Falta la compatibilidad con Windows CE (ya sea x86 o ARM), pero una versión no oficial de prueba de concepto prealfa llamada WineCE permite cierta compatibilidad.
Vino para Android
El 3 de febrero de 2013, en la charla FOSDEM en Bruselas, Alexandre Julliard mostró una demostración inicial de Wine ejecutándose en el sistema operativo Android de Google.
Las compilaciones experimentales de WINE para Android (x86 y ARM) se lanzaron a fines de 2017. Desde entonces, los desarrolladores oficiales las actualizan periódicamente. Las compilaciones predeterminadas no implementan la emulación entre arquitecturas a través de QEMU y, como resultado, las versiones ARM solo ejecutarán aplicaciones ARM que usan la API Win32.
Aplicaciones de Microsoft
Wine, de forma predeterminada, utiliza versiones especializadas de Windows de Gecko y Mono para sustituir Internet Explorer y.NET Framework de Microsoft. Wine tiene implementaciones integradas de JScript y VBScript. Es posible descargar y ejecutar los instaladores de Microsoft para esos programas a través de winetricks o manualmente.
No se sabe que Wine tenga un buen soporte para la mayoría de las versiones de Internet Explorer (IE). De todas las versiones razonablemente recientes, Internet Explorer 8 para Windows XP es la única versión que informa una calificación utilizable en AppDB de Wine, lista para usar. Sin embargo, Google Chrome obtiene una calificación de oro (a partir de la puesta en escena de Wine 5.5), y se sabe que Edge, el navegador web de reemplazo de IE de Microsoft, se basa en ese navegador (después de cambiar del propio motor de renderizado de Microsoft). Winetricks ofrece instalación automática para Internet Explorer 6 a 8, por lo que se puede esperar razonablemente que estas versiones funcionen con sus soluciones integradas.
Una alternativa para instalar Internet Explorer directamente es usar el ahora desaparecido IEs4Linux. No es compatible con las últimas versiones de Wine, y el desarrollo de IEs4Linux está inactivo.
Otras versiones de Wine
El desarrollo central de Wine tiene como objetivo una implementación correcta de la API de Windows en su conjunto y, a veces, se ha retrasado en algunas áreas de compatibilidad con ciertas aplicaciones. Direct3D, por ejemplo, no se implementó hasta 1998, aunque las versiones más recientes han tenido una implementación cada vez más completa.
Cruce
CodeWeavers comercializa CrossOver específicamente para ejecutar Microsoft Office y otras aplicaciones importantes de Windows, incluidos algunos juegos. CodeWeavers emplea a Alexandre Julliard para trabajar en Wine y contribuye con la mayor parte de su código al proyecto Wine bajo la LGPL. CodeWeavers también lanzó una nueva versión llamada CrossOver Mac para computadoras Apple Macintosh basadas en Intel el 10 de enero de 2007.
A partir de 2012, CrossOver incluye la funcionalidad de las líneas CrossOver Games y CrossOver Pro, por lo que CrossOver Games y CrossOver Pro ya no están disponibles como productos individuales.
CrossOver Games se optimizó para ejecutar videojuegos de Windows. A diferencia de CrossOver, no se centró en proporcionar la versión más estable de Wine. En cambio, se proporcionan funciones experimentales para admitir juegos más nuevos.
VINO@Etersoft
La empresa rusa Etersoft ha estado desarrollando una versión patentada de Wine desde 2006. WINE@Etersoft es compatible con aplicaciones rusas populares (por ejemplo, 1C:Enterprise de 1C Company).
Protón
El 21 de agosto de 2018, Valve anunció una nueva variación de Wine, denominada Proton, diseñada para integrarse con la versión de Linux del software Steam de la empresa (incluidas las instalaciones de Steam integradas en su sistema operativo SteamOS basado en Linux y Steam ordenadores de máquinas). El objetivo de Valve para Proton es permitir que los usuarios de Steam en Linux jueguen juegos que carecen de un puerto nativo de Linux (particularmente juegos de catálogo anterior) y, en última instancia, a través de la integración con Steam, así como mejoras en el soporte del juego en relación con la línea principal Wine., para ofrecer a los usuarios "la misma experiencia sencilla de conectar y usar" que obtendrían si estuvieran jugando el juego de forma nativa en Linux. Proton ingresó a la versión beta pública inmediatamente después de ser anunciado.
Valve ya había estado colaborando con CodeWeavers desde 2016 para desarrollar mejoras en el rendimiento de los juegos de Wine, algunas de las cuales se fusionaron con el proyecto original de Wine. Algunas de las mejoras específicas incorporadas en Proton incluyen implementaciones Direct3D 9, 10, 11 y 12 basadas en Vulkan a través de vkd3d, DXVK y D9VK, mejoras de rendimiento de subprocesos múltiples a través de esync, manejo mejorado de juegos de pantalla completa y mejor soporte de hardware de controlador de juego automático..
Proton es totalmente de código abierto y está disponible a través de GitHub.
Otros proyectos que utilizan el código fuente de Wine
Otros proyectos que utilizan el código fuente de Wine incluyen:
- OTVDM, una capa de compatibilidad de aplicaciones de 16 bits para Windows de 64 bits.
- ReactOS, un proyecto para escribir un sistema operativo compatible con las versiones 5.x de Windows NT (que incluye Windows 2000 y sus sucesores) hasta el nivel del controlador del dispositivo. ReactOS uses Código fuente de vino considerablemente, pero debido a diferencias arquitectónicas, el código ReactOS (como DLLs escritos específicamente para él, como ntdll, user32, kernel32, gdi32, y advapi) no se utiliza generalmente en Wine. En julio de 2009, Aleksey Bragin, líder del proyecto ReactOS, inició una nueva rama de ReactOS llamada Arwinss, y fue anunciado oficialmente en enero de 2010. Arwinss es una aplicación alternativa de los componentes principales de Win32, y utiliza en su mayoría versiones sin cambios del usuario de Wine32.dll y gdi32.dll.
- WineBottler, un envoltorio alrededor de Wine en forma de aplicación Mac normal. Gestiona múltiples configuraciones vinícolas para diferentes programas en forma de "botellas".
- Wineskin, un administrador de configuración de Wine GUI de código abierto para macOS. Wineskin crea un envoltorio alrededor del Vino en forma de una aplicación Mac normal. El envoltorio también se puede utilizar para hacer un "puerto" distribuible de software.
- Odin, un proyecto para ejecutar binarios Win32 en OS/2 o convertirlos en formato nativo OS/2. El proyecto también proporciona la API Odin32 para compilar programas Win32 para OS/2.
- Productos de virtualización como Parallels Desktop para Mac y VirtualBox utilizan WineD3D para hacer uso de la GPU.
- WinOnX, un paquete comercial de Vino para macOS que incluye un GUI para agregar y gestionar aplicaciones y máquinas virtuales.
- WineD3D para Windows, un envoltorio de compatibilidad que emula viejas versiones Direct3D y características que fueron eliminadas por Microsoft en recientes versiones de Windows, utilizando OpenGL. Esto a veces hace que los juegos más antiguos funcionen de nuevo.
Discontinuado
- Cedega / WineX: TransGaming Inc. (ahora Findev Inc. desde la venta de sus negocios de software) produjo el software patentado Cedega. Anteriormente conocido como WineX, Cedega representó un tenedor de la última versión con licencia de MIT de Wine en 2002. Al igual que CrossOver Games, TransGaming's Cedega fue concentrado en ejecutar videojuegos de Windows. El 7 de enero de 2011, TransGaming Inc. anunció el desarrollo continuo de Cedega Technology bajo el Programa de Desarrolladores de GameTree. TransGaming Inc. permitió a los miembros seguir utilizando su ID y contraseña de Cedega hasta el 28 de febrero de 2011.
- Sidra: TransGaming también produjo Cider, una biblioteca para Macintoshes de arquitectura Apple-Intel. En lugar de ser un producto de usuario final, Cider (como Winelib) es un envoltorio que permite a los desarrolladores adaptar sus juegos para funcionar nativamente en Intel Mac sin ningún cambio en el código fuente.
- Darwine: un puerto anticuado de las bibliotecas vinícolas a Darwin y a macOS para las arquitecturas PowerPC e Intel x86. Todos los parches para la versión x86 se fusionaron en la rama principal del Vino en 2009. El desarrollo de la versión PPC fue abandonado (y en 2020 Wine 5.11 redujo el apoyo a PowerPC). Mike Kronenberg creó previamente el WineHelper para Darwine para agregar una aplicación de estilo GUI y macOS para interactuar con el Vino, que fue reemplazado posteriormente por WineBottler. Darwine ahora proporciona paquetes compatibles con macOS recopilados en el repositorio Wine.
- E/OS LX : un proyecto que intenta permitir que cualquier programa diseñado para cualquier sistema operativo se ejecute sin la necesidad de instalar realmente cualquier otro sistema operativo.
- Pipelight: una versión personalizada de Wine (wine-compholio) que actúa como envoltorio para plugins de Windows NPAPI dentro de los navegadores Linux. Esta herramienta permite a los usuarios de Linux ejecutar Microsoft Silverlight, el equivalente de Microsoft de Adobe Flash, y el plugin de Unity web, junto con una variedad de otros plugins NPAPI. El proyecto ofrece un amplio conjunto de parches contra el proyecto de Vino de corriente, algunos de los cuales fueron aprobados y añadidos al Vino de corriente. Pipelight es en gran medida obsoleto, ya que los navegadores modernos ya no soportan los plugins NPAPI y Silverlight ha sido deprecated por Microsoft.
Recepción
El proyecto Wine ha recibido una serie de quejas e inquietudes técnicas y filosóficas a lo largo de los años.
Seguridad
Debido a la capacidad de Wine para ejecutar el código binario de Windows, se han planteado preocupaciones sobre los virus nativos de Windows y el malware que afectan a los sistemas operativos similares a Unix, ya que Wine puede ejecutar malware limitado creado para Windows. Un análisis de seguridad de 2018 encontró que 5 de 30 muestras de malware pudieron ejecutarse con éxito a través de Wine, una tasa relativamente baja que, sin embargo, representaba un riesgo de seguridad. Por esta razón, los desarrolladores de Wine recomiendan nunca ejecutarlo como superusuario. El software de investigación de malware como ZeroWine ejecuta Wine en Linux en una máquina virtual, para mantener el malware completamente aislado del sistema host. Una alternativa para mejorar la seguridad sin el costo de rendimiento de usar una máquina virtual es ejecutar Wine en un contenedor LXC, como lo hace el software Anbox por defecto con Android.
Otro problema de seguridad es cuando las especificaciones implementadas están mal diseñadas y permiten comprometer la seguridad. Debido a que Wine implementa estas especificaciones, es probable que también implemente cualquier vulnerabilidad de seguridad que contengan. Una instancia de este problema fue la vulnerabilidad de metarchivo de Windows de 2006, en la que Wine implementó el escape vulnerable SETABORTPROC.
Wine vs aplicaciones Unix nativas
Una preocupación común sobre Wine es que su existencia significa que es menos probable que los proveedores escriban aplicaciones nativas de Linux, macOS y BSD. Como ejemplo de esto, vale la pena considerar el sistema operativo OS/2 Warp de IBM de 1994. Un artículo describe las debilidades de OS/2 que lo mataron, siendo la primera:
OS/2 ofrece una excelente compatibilidad con aplicaciones DOS y Windows 3.1. No, esto no es un error. Muchos proveedores de aplicaciones argumentaron que al desarrollar una aplicación DOS o Windows, alcanzarían el mercado OS/2 además de los mercados DOS/Windows y no desarrollaron aplicaciones nativas OS/2.
Sin embargo, OS/2 tuvo muchos problemas con la aceptación del usuario final. Quizás lo más grave fue que la mayoría de las computadoras vendidas ya venían con DOS y Windows, y muchas personas no se molestaron en evaluar OS/2 por sus méritos debido a que ya tenían un sistema operativo. "Agrupar" de DOS y Windows y el efecto paralizador que esto tuvo en el mercado de los sistemas operativos surgió con frecuencia en Estados Unidos v. Microsoft Corporation.
El proyecto Wine en sí responde a la queja específica de "fomentar" el desarrollo continuo de la API de Windows en una de sus páginas wiki:
Para la mayoría de la gente hay un puñado de programas encerrándolos en Windows. Es obvio que nunca habrá una Microsoft Office portado a Linux, sin embargo versiones más antiguas de programas como TurboTax tampoco serán portadas. Del mismo modo, hay decenas de miles de juegos y aplicaciones corporativas internas que nunca serán portadas. Si desea utilizar Linux y confiar en cualquier aplicación de Windows heredada, algo como Wine es esencial... El vino hace que Linux sea más útil y permite que millones de usuarios cambien quién no podría de otra manera. Esto aumenta enormemente los mercados de Linux, trayendo más desarrolladores comerciales y comunitarios a Linux.
Además, la página Wiki de Wine afirma que Wine puede ayudar a resolver el problema del huevo y la gallina para Linux en el escritorio:
Esto nos lleva al problema de pollo y huevo de Linux en el escritorio. Hasta que Linux pueda proporcionar equivalentes para las aplicaciones anteriores, su cuota de mercado en el escritorio se estancará. Pero hasta que la cuota de mercado de Linux en el escritorio aumente, ningún proveedor desarrollará aplicaciones para Linux. ¿Cómo se rompe este círculo vicioso?
Otra vez, Wine puede proporcionar una respuesta. Al permitir que los usuarios reutilizan las aplicaciones de Windows que han invertido tiempo y dinero en, Wine reduce drásticamente la barrera que impide que los usuarios cambien a Linux. Esto hace posible que Linux despegue en el escritorio, lo que aumenta su cuota de mercado en ese segmento. A su vez, esto hace viable para las empresas producir versiones Linux de sus aplicaciones, y para que nuevos productos salgan sólo para el mercado Linux. Este razonamiento podría desestimarse fácilmente si el Vino sólo fuera capaz de correr Solitario. Sin embargo, ahora puede ejecutar Microsoft Office, aplicaciones multimedia como QuickTime y Windows Media Player, e incluso juegos como Max Payne o Unreal Tournament 3. Casi cualquier otra aplicación compleja se puede hacer para funcionar bien dado un poco de tiempo. Y cada vez que se hace el trabajo para añadir una aplicación a esta lista, muchas otras aplicaciones se benefician de este trabajo y se vuelven utilizables también.
Echa un vistazo a nuestra base de datos de aplicaciones para obtener una idea de lo que se puede ejecutar bajo el vino.
El uso de Wine para juegos ha resultado especialmente controvertido en la comunidad de Linux, ya que algunos sienten que impide, o al menos obstaculiza, el mayor crecimiento de los juegos nativos de Linux en la plataforma.
Microsoft
Hasta 2020, Microsoft no había hecho ninguna declaración pública sobre Wine. Sin embargo, el servicio en línea de Windows Update bloqueará las actualizaciones de las aplicaciones de Microsoft que se ejecutan en Wine. El 16 de febrero de 2005, Ivan Leo Puoti descubrió que Microsoft había comenzado a buscar en el Registro de Windows la clave de configuración de Wine y bloquearía la actualización de Windows para cualquier componente. Como señaló Puoti: "También es la primera vez que Microsoft reconoce la existencia de Wine".
En enero de 2020, Microsoft citó a Wine como una consecuencia positiva de poder volver a implementar las API, en su escrito amicus curiae para Google LLC v. Oracle America, Inc.
Contenido relacionado
Protector de pantalla
Campana OH-58 Kiowa
Notación Z