Vino (software)

Ajustar Compartir Imprimir Citar
Software de compatibilidad con Windows

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

WINE project.png

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

Una captura de pantalla que muestra cómo se puede configurar Vino para imitar diferentes versiones de Windows, yendo tan lejos como Windows 2.0 en la versión de 32 bits (64-bit Wine admite sólo versiones de 64 bits de Windows)

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

PlayOnLinux

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.

Funcionalidad

Aplicar el progreso de compatibilidad con el tiempo, según los resultados de la prueba Wine AppDB.
El software funciona impecablemente
El software funciona impecablemente después de la configuración
Problemas menores con el software
Principales problemas con el software
Software completamente no funcional

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

WINE Solitaire corriendo en 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:

Discontinuado

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.