Wine [a] es una capa de compatibilidad libre y de código abierto que permite que el software de aplicación y los juegos de computadora desarrollados para Microsoft Windows se ejecuten en sistemas operativos tipo Unix . Los desarrolladores pueden compilar aplicaciones de Windows contra WineLib para ayudar a trasladarlas a sistemas tipo Unix. Wine se escribe predominantemente utilizando ingeniería inversa de pruebas de caja negra , para evitar problemas de derechos de autor . No se produce ninguna emulación de código ni virtualización . Wine se desarrolla principalmente para Linux y macOS .
En una encuesta realizada en 2007 por desktoplinux.com a 38.500 usuarios de escritorios Linux, el 31,5% de los encuestados afirmó utilizar Wine para ejecutar aplicaciones de Windows. [8] Esta pluralidad fue mayor que la de todos los programas de virtualización x86 combinados, y mayor que el 27,9% que afirmó no ejecutar aplicaciones de Windows. [9]
Bob Amstadt, el líder inicial del proyecto, y Eric Youngdale comenzaron el proyecto Wine en 1993 como una forma de ejecutar aplicaciones de Windows en Linux . Se inspiró en dos productos de Sun Microsystems , Wabi para el sistema operativo Solaris y la Interfaz Pública de Windows , [10] que fue un intento de lograr que la API de Windows se reimplementara por completo en el dominio público como un estándar ISO pero fue rechazado debido a la presión de Microsoft en 1996. [11] Wine originalmente apuntaba a aplicaciones de 16 bits para Windows 3.x , pero a partir de 2010 [actualizar]se centra en 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 en Usenet en comp.os.linux en junio de 1993. [12] Alexandre Julliard ha liderado el proyecto desde 1994.
El proyecto ha resultado ser una tarea ardua y que ha llevado mucho tiempo 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 públicas y completas disponibles de Microsoft. 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 funcionen correctamente. [13] En consecuencia, el equipo de Wine ha realizado ingeniería inversa de muchas llamadas de función y formatos de archivo en áreas como el procesamiento thunk . [ cita requerida ]
El proyecto Wine originalmente lanzó Wine bajo la misma Licencia MIT que el Sistema X Window, pero debido a la preocupación acerca de que las versiones propietarias de Wine no aportaran sus cambios al proyecto principal, [14] el trabajo a partir de marzo de 2002 ha utilizado la LGPL para su licencia. [15]
Wine entró oficialmente en fase beta con la versión 0.9 el 25 de octubre de 2005. [16] La versión 1.0 se lanzó el 17 de junio de 2008, [17] después de 15 años de desarrollo. La versión 1.2 se lanzó el 16 de julio de 2010, [18] la versión 1.4 el 7 de marzo de 2012, [19] la versión 1.6 el 18 de julio de 2013, [20] la versión 1.8 el 19 de diciembre de 2015 [21] y la versión 9.0 el 16 de enero de 2024. [22] Las versiones de desarrollo se lanzan aproximadamente cada dos semanas.
Wine-staging es un conjunto de parches agresivos mantenidos independientemente que los desarrolladores de WineHQ no consideran listos para fusionarse en el repositorio de Wine, pero que aún así la bifurcación de wine-compholio los considera útiles . Cubre principalmente funciones experimentales y correcciones de errores. Desde enero de 2017, los parches en wine-staging comenzaron a fusionarse activamente en el upstream de WineHQ cuando wine-compholio transfirió el proyecto a Alistair Leslie-Hughes, un desarrollador clave de WineHQ. A partir de 2019 [actualizar], WineHQ también proporciona versiones preconstruidas de wine-staging. [23]
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 , la versión de Wine compatible con CodeWeavers. CrossOver incluye algunos ajustes específicos de la aplicación que no se consideran adecuados para la versión original , así como algunos componentes propietarios adicionales. [24]
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 trasladar WordPerfect Office , su suite ofimática , a Linux (especialmente Corel Linux ). Corel canceló más tarde todos los proyectos relacionados con Linux después de que Microsoft hiciera importantes inversiones en Corel, deteniendo su iniciativa Wine. [25]
Otros patrocinadores corporativos incluyen a Google , que contrató a CodeWeavers para arreglar Wine para que Picasa funcionara lo suficientemente bien como para ser portado directamente a Linux usando el mismo binario que en Windows; Google luego pagó por mejoras en el soporte de Wine para Adobe Photoshop CS2 . [26] Wine también es un beneficiario regular del programa Summer of Code de Google. [27]
Valve trabaja con CodeWeavers para desarrollar Proton , una capa de compatibilidad basada en Wine para que los juegos de Microsoft Windows se ejecuten en sistemas operativos basados en Linux . Proton incluye varios parches que Wine no acepta por diversas razones, como implementaciones específicas de Linux de funciones Win32. La participación de Valve en el desarrollo de Proton (y, por lo tanto, la mejora de los juegos de Linux ) ha ayudado a mejorar la compatibilidad de Wine con los juegos de Windows. [28]
El objetivo de Wine es implementar total o parcialmente las API de Windows que requieren los programas que los usuarios de Wine desean ejecutar en un sistema tipo Unix.
La interfaz de programación de Microsoft Windows se compone en gran parte de bibliotecas de vínculos dinámicos (DLL). Estas contienen una gran cantidad de subrutinas contenedoras para las llamadas del sistema del núcleo, el programa de modo kernel NTOS (ntoskrnl.exe). Un programa típico de Windows llama a algunas DLL de Windows, que a su vez llaman a las bibliotecas gdi/user32 de modo usuario, que a su vez utilizan el kernel32.dll (subsistema win32) responsable de tratar con el núcleo a través de llamadas del sistema. La capa de llamadas del sistema se considera privada para los programadores de Microsoft ya que la documentación no está disponible públicamente y las interfaces publicadas dependen todas de subsistemas que se ejecutan sobre el núcleo. Además de estas, hay una serie de interfaces de programación implementadas como servicios que se ejecutan como procesos separados. Las aplicaciones se comunican con los servicios de modo usuario a través de RPC. [29]
Wine implementa la interfaz binaria de aplicación (ABI) de Windows completamente en el espacio de usuario , en lugar de como un módulo del núcleo . Wine refleja principalmente la jerarquía, con servicios normalmente proporcionados por el núcleo en Windows [30] en lugar de ser proporcionados por 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 en excepciones nativas de Windows. Aunque wineserver implementa algunos aspectos del núcleo de Windows , no es posible usar controladores nativos de Windows con él, debido a la arquitectura subyacente de Wine. [29]
Wine permite cargar tanto DLL de Windows como objetos compartidos de Unix para sus programas de Windows. Su implementación incorporada 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 usar funciones en el sistema operativo host. Las bibliotecas de nivel superior, como WineD3D, pueden usar el formato DLL. En muchos casos, los usuarios pueden elegir cargar una DLL de Windows en lugar de la implementada por Wine. Hacerlo puede proporcionar funcionalidades que Wine aún no implementa, pero también puede causar fallas si se basa en algo más que no está presente en Wine. [29]
Wine rastrea su estado de implementación a través de pruebas unitarias automatizadas realizadas en cada confirmación de Git. [31]
Si bien la mayoría del software de oficina no utiliza API de gráficos acelerados por GPU complejos, los juegos de computadora sí lo hacen. Para ejecutar estos juegos correctamente, Wine tendría que enviar 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 renderizado, audio y entrada. A partir de 2019, Wine 4.0 contiene una implementación de DirectX 12 para Vulkan API y DirectX 11.2 para OpenGL. [32] Wine 4.0 también permite que Wine ejecute aplicaciones Vulkan entregando comandos de dibujo al sistema operativo anfitrión o, en el caso de macOS, traduciéndolos a la Metal API de MoltenVK . [32]
Gran parte del esfuerzo de Wine en DirectX se destina a la creación de WineD3D, una capa de traducción de las llamadas a la API de Direct3D y DirectDraw a OpenGL . A partir de 2019, este componente es compatible con DirectX 11. [32] A partir del 12 de diciembre de 2016, Wine es lo suficientemente bueno como para ejecutar Overwatch con D3D11. [35] Además de usarse en Wine, las DLL de WineD3D también se han utilizado en Windows, lo que permite que las GPU más antiguas ejecuten juegos que usan versiones más nuevas de DirectX y que los juegos antiguos basados en DDraw se representen correctamente. [36]
Se está trabajando en la migración del backend de Direct3D a la API de Vulkan. La compatibilidad con Direct3D 12 en la versión 4.0 la proporciona un subproyecto "vkd3d" [32] , y en 2019 WineD3D se ha adaptado experimentalmente para utilizar la API de Vulkan. [37] Otra implementación, DXVK, traduce también las llamadas a Direct3D 9, 10 y 11 utilizando Vulkan y es un proyecto independiente. [38]
Wine, cuando se aplica el parche, puede ejecutar comandos de API Direct3D 9 directamente a través de un rastreador de estado Gallium3D gratuito y de código abierto (también conocido como controlador de GPU Gallium3D) sin traducción a llamadas de API OpenGL. En este caso, la capa Gallium3D permite un paso directo de comandos de dibujo DX9, lo que da como resultado mejoras de rendimiento de hasta un factor de 2. [39] A partir de 2020, el proyecto se llama Gallium.Nine. Ahora está disponible como un paquete independiente y ya no necesita una versión parcheada de Wine. [40]
Wine generalmente se invoca desde el intérprete de línea de comandos: wine program.exe. [41]
_--_main_tab.png/1280px-Winecfg_in_32-bit_mode_(v_5.5)_--_main_tab.png)
Existe la utilidad winecfgque inicia una interfaz gráfica de usuario con controles para ajustar las opciones básicas. [42] Es una utilidad de configuración 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 ).
Algunas aplicaciones requieren más ajustes que simplemente instalar la aplicación para que funcionen correctamente, como configurar manualmente 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 centra 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 de forma inmediata dentro de Wine. La wiki de Wine mantiene una página de aplicaciones de terceros actuales y obsoletas. [43]
Los desarrolladores de las partes Direct3D de Wine han seguido implementando nuevas características como sombreadores de píxeles para aumentar la compatibilidad con los juegos. [55] Wine también puede usar DLL nativas directamente, lo que aumenta la funcionalidad, pero en ese caso se necesita una licencia para Windows a menos que las DLL se distribuyan con la propia aplicación.
Wine también incluye sus propias implementaciones de código abierto de varios programas de Windows, como el Bloc de notas , WordPad , el Panel de control , Internet Explorer y Windows Explorer . [56]
La base de datos de aplicaciones 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.
Wine garantiza una buena compatibilidad con versiones anteriores de aplicaciones de Windows, incluidas aquellas escritas para Windows 3.1x . [57] Wine puede imitar diferentes versiones de Windows requeridas para algunos programas, desde Windows 2.0 . [58] 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 [ cita requerida ] (ver más abajo sobre MS-DOS), la versión de desarrollo de Wine 1.3.12 y posteriores muestran de todos modos la opción "Windows 2.0" para la versión de Windows a imitar, 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 aplicaciones heredadas de Windows y pueden romper el software no compatible para siempre ya que no hay nadie que ajuste el programa a 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 el "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), [59] una funcionalidad que no se encuentra en las versiones de 64 bits de Microsoft Windows. [60] [61] WineVDM permite que las aplicaciones de Windows de 16 bits se ejecuten en versiones de 64 bits de Windows. [62]
Wine soporta parcialmente las aplicaciones de consola de Windows , y el usuario puede elegir qué backend usar para administrar la consola (las opciones incluyen raw streams, curses y user32 ). [63] Al usar los backends raw streams o curses, las aplicaciones de Windows se ejecutarán en una terminal Unix.
En diciembre de 2008, Wine 1.1.10 agregó soporte preliminar para aplicaciones de Windows de 64 bits . [64] A partir de abril de 2019 [actualizar], el soporte se considera estable. Las dos versiones de Wine se compilan por separado y, como resultado, solo compilar wine64 produce un entorno solo capaz de ejecutar aplicaciones x86-64. [65]
A partir de abril de 2019 [actualizar], Wine tiene soporte estable para una compilación de WoW64 , 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 haciendo 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. [65] Esta funcionalidad se observa al menos desde 2010. [66]
Las primeras versiones de Microsoft Windows se ejecutan sobre MS-DOS , y los programas de Windows pueden depender de programas MS-DOS para ser utilizables. 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 MS-DOS en DOSBox si DOSBox está disponible en el sistema. [67] Sin embargo, debido a un error, las versiones actuales [ necesita actualización ] de Wine identifican incorrectamente los programas de Windows 1.x y Windows 2.x como programas MS-DOS, intentando ejecutarlos en DOSBox (lo que no funciona). [68]
Wine ofrece 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 incorpore a los ejecutables nativos de Unix. Desde octubre de 2010, Winelib también funciona en la plataforma ARM . [69]
El soporte para Solaris SPARC se eliminó en la versión 1.5.26.
Wine ofrece cierta compatibilidad con procesadores ARM (así como ARM64/AArch64) y las versiones de Windows que se ejecutan en ellos. A partir de abril de 2019 [actualizar], Wine puede ejecutar aplicaciones ARM/Win32 destinadas a dispositivos Windows RT desbloqueados (pero no programas Windows RT). Falta compatibilidad con Windows CE (tanto x86 como ARM), [70] pero una versión de prueba de concepto pre-alfa no oficial llamada WineCE permite cierta compatibilidad. [71]
El 3 de febrero de 2013, en la charla FOSDEM en Bruselas, Alexandre Julliard mostró una demostración preliminar de Wine ejecutándose en el sistema operativo Android de Google . [72]
Las compilaciones experimentales de WINE para Android (x86 y ARM) se lanzaron a fines de 2017. Los desarrolladores oficiales las han actualizado de manera rutinaria desde entonces. [4] 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 usen la API Win32. [73]
Wine, de forma predeterminada, utiliza compilaciones especializadas de Windows de Gecko y Mono para sustituir a 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 de forma manual.
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 de utilizable en AppDB de Wine, lista para usar. [74] Sin embargo, Google Chrome obtiene una calificación de oro (a partir de Wine 5.5-staging), [75] y se sabe que el navegador web de reemplazo de IE de Microsoft, Edge, está basado en ese navegador (después de cambiar del propio motor de renderizado de Microsoft [76] ). 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 alternativas integradas.
Una alternativa para instalar Internet Explorer directamente es utilizar el ahora obsoleto IEs4Linux . No es compatible con las últimas versiones de Wine, [77] y el desarrollo de IEs4Linux está inactivo.
El desarrollo básico de Wine apunta a una correcta implementación de la API de Windows en su conjunto y a veces ha quedado rezagado en algunas áreas de compatibilidad con ciertas aplicaciones. Direct3D, por ejemplo, permaneció sin implementar hasta 1998, [78] aunque las versiones más recientes han tenido una implementación cada vez más completa. [79]
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. [80] A diferencia de Wine, CrossOver es notablemente capaz de ejecutarse en las versiones de macOS solo para x64, [81] utilizando una técnica conocida como "wine32on64". [82]
A partir de 2012, CrossOver incluye la funcionalidad de las líneas CrossOver Games y CrossOver Pro, por lo tanto, CrossOver Games y CrossOver Pro ya no están disponibles como productos individuales. [83]
CrossOver Games fue optimizado 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 dar soporte a los juegos más nuevos. [84]
El 21 de agosto de 2018, Valve anunció una nueva variante de Wine, llamada Proton, diseñada para integrarse con la versión Linux del software Steam de la compañía (incluidas las instalaciones de Steam integradas en su sistema operativo SteamOS basado en Linux y las computadoras Steam Machine ). [85] El objetivo de Valve para Proton es permitir que los usuarios de Steam en Linux jueguen juegos que carecen de un puerto nativo para Linux (particularmente juegos del catálogo anterior) y, en última instancia, a través de la integración con Steam, así como mejoras en el soporte de juegos en relación con Wine, para brindarles a los usuarios "la misma experiencia simple de conectar y usar" que obtendrían si estuvieran jugando el juego de forma nativa en Linux. [85] Proton entró en beta pública inmediatamente después de ser anunciado. [85]
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 han fusionado con el proyecto Wine. [85] Algunas de las mejoras específicas incorporadas en Proton incluyen implementaciones de Direct3D 9, 10, 11 y 12 basadas en Vulkan a través de vkd3d , [86] DXVK , [87] y D9VK [88] mejoras de rendimiento multiproceso a través de esync, [89] manejo mejorado de juegos de pantalla completa y mejor soporte de hardware de controlador de juego automático. [85]
Proton es completamente de código abierto y está disponible a través de GitHub. [90]
La empresa rusa Etersoft ha estado desarrollando una versión propietaria de Wine desde 2006. WINE@Etersoft soporta aplicaciones rusas populares (por ejemplo, 1C:Enterprise de 1C Company ). [91]
Otros proyectos que utilizan el código fuente de Wine incluyen:
El proyecto Wine ha recibido numerosas quejas y preocupaciones técnicas y filosóficas a lo largo de los años.
Debido a la capacidad de Wine para ejecutar código binario de Windows, se han planteado preocupaciones sobre virus nativos de Windows y malware que afectan a sistemas operativos tipo Unix [111] 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, representó un riesgo de seguridad. [112] Por esta razón, los desarrolladores de Wine recomiendan nunca ejecutarlo como superusuario . [113] El software de investigación de malware como ZeroWine [114] 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 que se comprometa la seguridad. Debido a que Wine implementa estas especificaciones, es probable que también implemente cualquier vulnerabilidad de seguridad que contengan. Un ejemplo de este problema fue la vulnerabilidad de Windows Metafile de 2006 , que vio a Wine implementar el escape vulnerable SETABORTPROC. [115] [116]
Una preocupación común sobre Wine es que su existencia significa que los proveedores tienen menos probabilidades de escribir aplicaciones nativas para Linux, macOS y BSD. Como ejemplo de esto, vale la pena considerar el sistema operativo de IBM de 1994, OS/2 Warp . [¿ Investigación original? ] Un artículo describe las debilidades de OS/2 que lo mataron, siendo la primera:
OS/2 ofrecía una excelente compatibilidad con las 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, llegarían al mercado de OS/2 además de a los mercados DOS/Windows y no desarrollaron aplicaciones nativas de OS/2. [117]
Sin embargo, OS/2 tuvo muchos problemas con la aceptación del usuario final. Quizás el más grave fue que la mayoría de las computadoras vendidas ya venían con DOS y Windows, y mucha gente no se molestó en evaluar OS/2 en función de sus méritos porque ya tenían un sistema operativo. La "combinación" de DOS y Windows y el efecto paralizante que esto tuvo en el mercado de sistemas operativos fueron temas que se trataron con frecuencia en el caso Estados Unidos contra Microsoft Corporation .
El propio proyecto Wine 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, todavía quedan unos cuantos programas que los limitan a Windows. Es obvio que nunca habrá un Microsoft Office portado a Linux, pero tampoco se portarán versiones anteriores de programas como TurboTax. De manera similar, hay decenas de miles de juegos y aplicaciones corporativas internas que nunca se portarán. Si quieres usar Linux y dependes de alguna aplicación heredada de Windows, algo como Wine es esencial... Wine hace que Linux sea más útil y permite que millones de usuarios cambien a Linux, algo que de otra manera no podrían. Esto aumenta enormemente la cuota de mercado de Linux, atrayendo a más desarrolladores comerciales y comunitarios a Linux. [118]
Además, la página Wine Wiki afirma que Wine puede ayudar a resolver el problema del huevo y la gallina en Linux en el escritorio : [119]
Esto nos lleva al problema del huevo y la gallina en el caso de Linux en el escritorio. Hasta que Linux pueda ofrecer equivalentes para las aplicaciones mencionadas, 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 puede romper este círculo vicioso?
Una vez más, Wine puede proporcionar una respuesta. Al permitir que los usuarios reutilicen las aplicaciones de Windows en las que han invertido tiempo y dinero, Wine reduce drásticamente la barrera que impide a los usuarios cambiar a Linux. Esto hace posible que Linux despegue en el escritorio, lo que aumenta su participación de mercado en ese segmento. A su vez, esto hace que sea viable para las empresas producir versiones Linux de sus aplicaciones y que salgan nuevos productos solo para el mercado Linux. Este razonamiento podría descartarse fácilmente si Wine solo fuera capaz de ejecutar Solitaire. 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 puede ejecutarse bien con un poco de tiempo. Y cada vez que se realiza ese trabajo para agregar una aplicación a esta lista, muchas otras aplicaciones se benefician de este trabajo y también se vuelven utilizables.
Eche un vistazo a nuestra base de datos de aplicaciones para tener una idea de lo que se puede ejecutar en Wine.
El uso de Wine para juegos ha resultado especialmente controvertido en la comunidad Linux, ya que algunos sienten que está impidiendo, o al menos obstaculizando, un mayor crecimiento de los juegos nativos de Linux en la plataforma. [120] [121] Sin embargo, una peculiaridad es que Wine ahora puede ejecutar aplicaciones y juegos de 16 bits e incluso de 32 bits que no se inician en las versiones actuales de Windows de 64 bits . [122] Este caso de uso ha llevado a ejecutar Wine en el propio Windows a través del Subsistema de Windows para Linux o máquinas virtuales de terceros , [ cita requerida ] así como encapsulado por medios como BoxedWine [123] y Otvdm. [124]
Hasta 2020, Microsoft no había hecho ninguna declaración pública sobre Wine. Sin embargo, el servicio en línea 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 verificar el Registro de Windows en busca de la clave de configuración de Wine y bloquearía Windows Update para cualquier componente. [125] 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 reimplementar las API, en su escrito amicus curiae para Google LLC v. Oracle America, Inc. [126]
En agosto de 2024, Microsoft donó el Proyecto Mono , una reimplementación de .NET Framework , a los desarrolladores de Wine. [127]
Por lo general, empezamos con la documentación disponible, implementamos una primera versión de la función y, a medida que encontramos problemas con las aplicaciones que llaman a esta función, corregimos el comportamiento hasta que sea lo que la aplicación espera, que suele estar bastante lejos de lo que indica la documentación.
Hay un par de diferencias con d3d1x:
[...]
está escrito en C en lugar de C++ y no depende de la horrible herencia múltiple con
[...]
Hasta ahora he probado Skyrim, Civilization 5, Anno 1404 y StarCraft 2 en los controladores nvc0 y r600g, que funcionan bastante bien, hasta a x2 los fps que obtengo con wined3d (Nota: todavía no se ha realizado una evaluación comparativa exhaustiva).
.svg/1280px-Free_and_open-source_software_logo_(2009).svg.png){kind=logo}
