Wine [a] es una capa de compatibilidad gratuita y de código abierto que permite que el software de aplicaciones y los juegos de computadora desarrollados para Microsoft Windows se ejecuten en sistemas operativos tipo Unix . Los desarrolladores pueden compilar aplicaciones de Windows con WineLib para ayudar a migrarlas a sistemas similares a 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 está desarrollado principalmente para Linux y macOS .
En una encuesta realizada en 2007 por desktoplinux.com a 38.500 usuarios de escritorio de Linux, el 31,5% de los encuestados informó que utilizaba Wine para ejecutar aplicaciones de Windows. [8] Esta pluralidad fue mayor que todos los programas de virtualización x86 combinados, y mayor que el 27,9% que informó no ejecutar aplicaciones de Windows. [9]
Bob Amstadt, el líder inicial del proyecto, y Eric Youngdale iniciaron 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 Iniciativa Pública de Windows , [10] que fue un intento de volver a implementar completamente la API de Windows en el dominio público como estándar ISO , pero fue rechazado debido a la presión de Microsoft en 1996. [11] Wine originalmente estaba dirigido 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 sobre Usenet en comp.os.linux en junio de 1993. [12] Alexandre Julliard ha liderado 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 o incompletas de Microsoft, y Windows también incluye funciones de bajo nivel no documentadas, comportamientos no documentados y errores oscuros que Wine debe duplicar con precisión para permitir algunas aplicaciones funcionen correctamente. [13] En consecuencia, el equipo de Wine ha realizado ingeniería inversa en muchas llamadas a funciones y formatos de archivos en áreas como thunking . [ cita necesaria ]
El proyecto Wine lanzó 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 principal, [14] el trabajo hasta marzo de 2002 ha utilizado la LGPL para su Licencia. [15]
Wine entró oficialmente en versión 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 de forma independiente que los desarrolladores de WineHQ no consideran listos para fusionarse en el repositorio de Wine, pero que aún se consideran útiles para la bifurcación de Wine-compholio . Cubre principalmente funciones experimentales y corrección de errores. Desde enero de 2017, los parches en Wine Staging comienzan a fusionarse activamente en WineHQ upstream cuando Wine-compholio transfirió el proyecto a Alistair Leslie-Hughes, un desarrollador clave de WineHQ. A partir de 2019 [actualizar], WineHQ también ofrece versiones prediseñadas de puesta en escena de vinos. [23]
El principal patrocinador corporativo de Wine es CodeWeavers , que emplea a Julliard y 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 anterior , así como algunos componentes propietarios adicionales. [24]
La participación de Corel durante un tiempo ayudó al proyecto, principalmente empleando a Julliard y otros para trabajar en él. Corel tenía interés en portar WordPerfect Office , su suite ofimática , a Linux (especialmente Corel Linux ). Posteriormente, Corel canceló todos los proyectos relacionados con Linux después de que Microsoft hiciera importantes inversiones en Corel, deteniendo su esfuerzo con 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; Posteriormente, Google pagó por mejoras en el soporte de Wine para Adobe Photoshop CS2 . [26] Wine también es un beneficiario habitual 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 tanto, en la mejora de los juegos de Linux ) ha ayudado a mejorar la compatibilidad de Wine con los juegos de Windows. [ cita necesaria ]
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 tipo Unix.
La interfaz de programación de Microsoft Windows consta 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 en 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 en modo de usuario, que a su vez utilizan el kernel32.dll (subsistema win32) responsable de tratar con el kernel a través de llamadas al sistema. La capa de llamada 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 kernel. 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 de usuario a través de RPC. [28]
Wine implementa la interfaz binaria de aplicaciones (ABI) de Windows completamente en el espacio del usuario , en lugar de como un módulo del kernel . Wine refleja en gran medida la jerarquía, con servicios normalmente proporcionados por el kernel en Windows [29] en cambio 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 kernel de Windows , no es posible utilizar controladores nativos de Windows con él debido a la arquitectura subyacente de Wine. [28]
Wine permite cargar DLL de Windows y 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 utilizar el formato DLL de forma gratuita. En muchos casos los usuarios pueden optar por cargar una DLL desde Windows en lugar de la implementada por Wine. Hacerlo puede proporcionar funcionalidades que Wine aún no ha implementado, pero también puede provocar fallos de funcionamiento si depende de algo más que no está presente en Wine. [28]
Wine rastrea su estado de implementación a través de pruebas unitarias automatizadas realizadas en cada confirmación de git. [30]
Si bien la mayoría del software de oficina no utiliza API de gráficos complejas aceleradas por GPU, 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. [31] Wine 4.0 también permite a Wine ejecutar aplicaciones Vulkan entregando comandos de dibujo al sistema operativo host o, en el caso de macOS, traduciéndolos a la API Metal de MoltenVK . [31]
Gran parte del esfuerzo de Wine en DirectX se destina a crear WineD3D, una capa de traducción de llamadas API de Direct3D y DirectDraw a OpenGL . A partir de 2019, este componente admite hasta DirectX 11. [31] A partir del 12 de diciembre de 2016, Wine es lo suficientemente bueno para ejecutar Overwatch con D3D11. [34] 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 usando versiones más nuevas de DirectX y que los juegos antiguos basados en DDraw se procesen correctamente. [35]
Se están realizando algunos trabajos para mover el backend de Direct3D a la API de Vulkan. La compatibilidad con Direct3D 12 en 4.0 es proporcionada por un subproyecto "vkd3d", [31] y WineD3D en 2019 ha sido portado experimentalmente para usar la API Vulkan. [36] Otra implementación, DXVK, también traduce llamadas Direct3D 9, 10 y 11 usando Vulkan y es un proyecto separado. [37]
Wine, cuando está parcheado, puede alternativamente ejecutar comandos 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 Gallium3D) sin traducción a llamadas API OpenGL. En este caso, la capa Gallium3D permite un paso directo de los comandos de dibujo DX9, lo que da como resultado mejoras de rendimiento de hasta un factor de 2. [38] A partir de 2020, el proyecto se llama Gallium.Nine. Está disponible ahora como un paquete independiente y ya no necesita una versión de Wine parcheada. [39]
Wine generalmente se invoca desde el intérprete de línea de comandos: wine program.exe. [40]
_--_main_tab.png/1280px-Winecfg_in_32-bit_mode_(v_5.5)_--_main_tab.png)
Existe una utilidad winecfgque inicia una interfaz gráfica de usuario con controles para ajustar las opciones básicas. [41] 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 Wine manualmente para usar ciertas DLL de Windows . El proyecto Wine no integra tales soluciones 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 a los usuarios ejecutar 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 fábrica dentro del propio Wine. La wiki de Wine mantiene una página de aplicaciones de terceros actuales y obsoletas. [42]
Los desarrolladores de las partes Direct3D de Wine han seguido implementando nuevas funciones, como sombreadores de píxeles , para aumentar la compatibilidad con el juego. [54] Wine también puede usar DLL nativas directamente, aumentando así la funcionalidad, pero luego se necesita una licencia para Windows a menos que las DLL se distribuyan con la aplicación misma.
Wine también incluye sus propias implementaciones de código abierto de varios programas de Windows, como el Bloc de notas , WordPad , Panel de control , Internet Explorer y Windows Explorer . [55]
Wine Application Database (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 heredadas de Windows, incluidas aquellas escritas para Windows 3.1x . [56] Wine puede imitar diferentes versiones de Windows requeridas para algunos programas, desde Windows 2.0 . [57] 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 necesaria ] (ver más abajo en MS-DOS), la versión de desarrollo de Wine 1.3.12 y posteriores muestra la opción "Windows 2.0" para que la versión de Windows la imite, pero Wine aún no se ejecutará en su mayor parte. 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 dañar 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), [58] una funcionalidad que no se encuentra en las versiones de 64 bits de Microsoft Windows. [59] [60] WineVDM permite que aplicaciones de Windows de 16 bits se ejecuten en versiones de 64 bits de Windows. [61]
Wine admite parcialmente 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 ). [62] Cuando se utilizan flujos sin formato o backends de curses, las aplicaciones de Windows se ejecutarán en una terminal Unix.
Se agregó soporte preliminar para aplicaciones de Windows de 64 bits a Wine 1.1.10 en diciembre de 2008. [63] En abril de 2019 [actualizar], el soporte se considera estable. Las dos versiones de Wine se construyen por separado y, como resultado, solo la compilación de Wine64 produce un entorno que solo puede ejecutar aplicaciones x86-64. [64]
A partir de abril de 2019 [actualizar], Wine tiene soporte estable para una compilación WoW64 , que permite ejecutar aplicaciones de Windows de 32 y 64 bits dentro de la misma instancia de Wine. Para realizar dicha compilación, 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 el WoW64 de Microsoft, el proceso de compilación de 32 bits agregará las piezas necesarias para manejar programas de 32 bits a la compilación de 64 bits. [64] Esta funcionalidad se ve desde al menos 2010. [65]
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 MS-DOS en DOSBox si DOSBox está disponible en el sistema. [66] Sin embargo, debido a un error, las versiones actuales [ necesitan actualización ] de Wine identifican incorrectamente los programas de Windows 1.x y Windows 2.x como programas de MS-DOS, intentando ejecutarlos en DOSBox (lo cual no funciona). [67]
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 ejecutables nativos de Unix. Desde octubre de 2010, Winelib también funciona en la plataforma ARM . [68]
La compatibilidad con Solaris SPARC se eliminó en la versión 1.5.26.
Wine proporciona cierto soporte para 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 de Windows RT). Falta soporte para Windows CE (ya sea x86 o ARM), [69] pero una versión no oficial de prueba de concepto pre-alfa llamada WineCE permite cierto soporte. [70]
El 3 de febrero de 2013, en la charla FOSDEM en Bruselas, Alexandre Julliard realizó una demostración inicial de Wine ejecutándose en el sistema operativo Android de Google . [71]
A finales de 2017 se lanzaron versiones experimentales de WINE para Android (x86 y ARM). Desde entonces, los desarrolladores oficiales las han actualizado periódicamente. [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 utilicen la API Win32. [72]
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 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. [73] Sin embargo, Google Chrome obtiene una calificación de oro (a partir de la puesta en escena de Wine 5.5), [74] 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 [75] ) . . 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 ya desaparecido IEs4Linux . No es compatible con las últimas versiones de Wine, [76] y el desarrollo de IEs4Linux está inactivo.
El desarrollo central de Wine tiene como objetivo una implementación correcta de la API de Windows en su conjunto y, en ocasiones, se ha quedado atrás en algunas áreas de compatibilidad con determinadas aplicaciones. Direct3D, por ejemplo, permaneció sin implementarse hasta 1998, [77] aunque las versiones más recientes han tenido una implementación cada vez más completa. [78]
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 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. [79] A diferencia de Wine, CrossOver es notablemente capaz de ejecutarse en versiones x64 de macOS, [80] usando una técnica conocida como "vino32on64". [81]
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. [82]
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 admitir juegos más nuevos. [83]
El 21 de agosto de 2018, Valve anunció una nueva variación 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 en las computadoras Steam Machine ). [84] El objetivo de Valve para Proton es permitir a los usuarios de Steam en Linux jugar juegos que carecen de un puerto nativo de 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 la línea principal de Wine, para brindar a los usuarios "la misma experiencia simple plug-and-play" que obtendrían si jugaran el juego de forma nativa en Linux. [84] Proton entró en versión beta pública inmediatamente después de ser anunciado. [84]
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. [84] 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 , [85] DXVK , [86] y D9VK [87] mejoras de rendimiento multiproceso a través de esync, [ 88] manejo mejorado de juegos en pantalla completa y mejor compatibilidad con el hardware del controlador de juegos automático. [84]
Proton es completamente de código abierto y está disponible a través de GitHub. [89]
La empresa rusa Etersoft ha estado desarrollando una versión patentada de Wine desde 2006. WINE@Etersoft admite aplicaciones rusas populares (por ejemplo, 1C:Enterprise de 1C Company ). [90]
Otros proyectos que utilizan el código fuente de Wine incluyen:
El proyecto Wine ha recibido una serie de quejas e inquietudes 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, han surgido preocupaciones sobre los virus y el malware nativos de Windows que afectan a los sistemas operativos tipo Unix [110] , 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, planteaba un riesgo de seguridad. [111] Por esta razón, los desarrolladores de Wine recomiendan nunca ejecutarlo como superusuario . [112] El software de investigación de malware como ZeroWine [113] 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 que implica 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, probablemente también implementará cualquier vulnerabilidad de seguridad que contengan. Un ejemplo de este problema fue la vulnerabilidad del metarchivo de Windows de 2006 , en la que Wine implementó el escape vulnerable SETABORTPROC. [114] [115]
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 de IBM de 1994, OS/2 Warp . [ ¿ investigacion original? ] Un artículo describe las debilidades de OS/2 que lo mataron, siendo la primera:
OS/2 ofrecía una excelente compatibilidad con aplicaciones de DOS y Windows 3.1. No, esto no es un error. Muchos proveedores de aplicaciones argumentaron que al desarrollar una aplicación para DOS o Windows, llegarían al mercado de OS/2 además de los mercados de DOS/Windows y no desarrollaron aplicaciones OS/2 nativas. [116]
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. La "combinación" de DOS y Windows y el efecto paralizador que esto tuvo en el mercado de sistemas operativos surgieron 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 las personas, quedan unos cuantos programas que los bloquean en Windows. Es obvio que nunca se trasladará Microsoft Office a Linux; sin embargo, tampoco se trasladarán versiones anteriores de programas como TurboTax. De manera similar, 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 heredada de Windows, algo como Wine es esencial... Wine hace que Linux sea más útil y permite que millones de usuarios cambien, quienes de otra manera no podrían hacerlo. Esto aumenta enormemente la cuota de mercado de Linux, atrayendo a más desarrolladores comerciales y comunitarios a Linux. [117]
Además, la página Wine Wiki afirma que Wine puede ayudar a solucionar el problema del huevo y la gallina para Linux en el escritorio : [118]
Esto nos lleva al tema del huevo y la gallina de Linux en el escritorio. Hasta que Linux pueda proporcionar equivalentes para las aplicaciones anteriores, su participación de mercado en el escritorio se estancará. Pero hasta que aumente la cuota de mercado de Linux en el escritorio, ningún proveedor desarrollará aplicaciones para Linux. ¿Cómo se rompe este círculo vicioso?
Una vez más, Wine puede dar una respuesta. Al permitir a los usuarios reutilizar 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 viable que las empresas produzcan versiones Linux de sus aplicaciones y que salgan nuevos productos sólo para el mercado Linux. Este razonamiento podría descartarse fácilmente si Wine sólo fuera capaz de ejecutar 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 puede ejecutarse bien con un poco de tiempo. Y cada vez que se realiza el 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 específicamente controvertido en la comunidad Linux, ya que algunos sienten que está impidiendo, o al menos obstaculizando, el mayor crecimiento de los juegos nativos de Linux en la plataforma. [119] [120] Sin embargo, una peculiaridad es que Wine ahora puede ejecutar aplicaciones y juegos de 16 bits e incluso ciertas de 32 bits que no se inician en las versiones actuales de Windows de 64 bits . [121] Este caso de uso ha llevado a ejecutar Wine en Windows a través del subsistema de Windows para Linux o máquinas virtuales de terceros , [ cita necesaria ] , así como encapsulado por medios como BoxedWine [122] y Otvdm. [123]
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. [124] 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 contra Oracle America, Inc. [125]
Por lo general, partimos de cualquier documentación disponible, implementamos una primera versión de la función y luego, cuando encontramos problemas con las aplicaciones que llaman a esta función, arreglamos el comportamiento hasta que sea lo que la aplicación espera, que generalmente está bastante lejos de lo que indica la documentación. estados.
hay un par de diferencias con d3d1x:
[...]
está escrito en C en lugar de C++ y no depende de una 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 x2 los fps que obtengo con wined3d (Nota: aún no se ha realizado una evaluación comparativa exhaustiva).
.svg/1280px-Free_and_open-source_software_logo_(2009).svg.png){kind=logo}
