Wine (software)

WineTemplate:Efn is a free and open-source compatibility layer to allow application software and computer games developed for Microsoft Windows to run on Unix-like operating systems. Developers can compile Windows applications against WineLib to help port them to Unix-like systems. Wine is predominantly written using black-box testing reverse engineering, to avoid copyright issues. No code emulation or virtualization occurs. Wine is primarily developed for Linux and macOS.

In a 2007 survey by desktoplinux.com of 38,500 Linux desktop users, 31.5% of respondents reported using Wine to run Windows applications.<ref>Template:Cite web</ref> This plurality was larger than all x86 virtualization programs combined, and larger than the 27.9% who reported not running Windows applications.<ref>Template:Cite web</ref>

History

Bob Amstadt, the initial project leader, and Eric Youngdale started the Wine project in 1993 as a way to run Windows applications on Linux. It was inspired by two Sun Microsystems products, Wabi for the Solaris operating system, and the Public Windows Interface,<ref>Template:Cite newsgroup</ref> which was an attempt to get the Windows API fully reimplemented in the public domain as an ISO standard but rejected due to pressure from Microsoft in 1996.<ref>Template:Cite web</ref> Wine originally targeted 16-bit applications for Windows 3.x, but Template:As of focuses on 32-bit and 64-bit versions which have become the standard on newer operating systems. The project originated in discussions on Usenet in comp.os.linux in June 1993.<ref>Template:Cite newsgroup</ref> Alexandre Julliard has led the project since 1994.

The project has proven time-consuming and difficult for the developers, mostly because of incomplete and incorrect documentation of the Windows API. While Microsoft extensively documents most Win32 functions, some areas such as file formats and protocols have no public, complete specification available from Microsoft. Windows also includes undocumented low-level functions, undocumented behavior and obscure bugs that Wine must duplicate precisely in order to allow some applications to work properly.<ref>Template:Cite interview</ref> Consequently, the Wine team has reverse-engineered many function calls and file formats in such areas as thunking.Template:Citation needed

The Wine project originally released Wine under the same MIT License as the X Window System, but owing to concern about proprietary versions of Wine not contributing their changes back to the core project,<ref>Template:Cite web</ref> work as of March 2002 has used the LGPL for its licensing.<ref>Template:Cite web</ref>

Wine officially entered beta with version 0.9 on 25 October 2005.<ref>Template:Cite web</ref> Version 1.0 was released on 17 June 2008,<ref>Template:Cite web</ref> after 15 years of development. Version 1.2 was released on 16 July 2010,<ref>Template:Cite web</ref> version 1.4 on 7 March 2012,<ref name="Wine 1.4 release">Template:Cite web</ref> version 1.6 on 18 July 2013,<ref name="wine1.6">Template:Cite web</ref> version 1.8 on 19 December 2015<ref name="wine1.8">Template:Cite web</ref> and version 9.0 on 16 January 2024.<ref name="wine9.0">Template:Cite web</ref> Development versions are released roughly every two weeks.

Wine-staging is an independently maintained set of aggressive patches not deemed ready by WineHQ developers for merging into the Wine repository, but still considered useful by the wine-compholio fork. It mainly covers experimental functions and bug fixes. Since January 2017, patches in wine-staging begins to be actively merged into the WineHQ upstream as wine-compholio transferred the project to Alistair Leslie-Hughes, a key WineHQ developer. Template:As of, WineHQ also provides pre-built versions of wine-staging.<ref>Template:Cite web</ref>

Corporate sponsorship

The main corporate sponsor of Wine is CodeWeavers, which employs Julliard and many other Wine developers to work on Wine and on CrossOver, CodeWeavers' supported version of Wine. CrossOver includes some application-specific tweaks not considered suitable for the upstream version, as well as some additional proprietary components.<ref>Template:Cite news</ref>

Canadian software developer Corel for a time assisted the project, chiefly by employing Julliard and others to work on it. Corel had an interest in porting WordPerfect Office, its office suite, to Linux (especially Corel Linux). Corel later cancelled all Linux-related projects after Microsoft made major investments in Corel, stopping their Wine effort.<ref>Template:Cite news</ref>

Other corporate sponsors include Google, which hired CodeWeavers to fix Wine so Picasa ran well enough to be ported directly to Linux using the same binary as on Windows; Google later paid for improvements to Wine's support for Adobe Photoshop CS2.<ref>Template:Cite web</ref> Wine is also a regular beneficiary of Google's Summer of Code program.<ref>Template:Cite mailing list</ref>

Valve works with CodeWeavers to develop Proton, a Wine-based compatibility layer for Microsoft Windows games to run on Linux-based operating systems. Proton includes several patches that upstream Wine does not accept for various reasons, such as Linux-specific implementations of Win32 functions.

Design

The goal of Wine is to implement the Windows APIs fully or partially that are required by programs that the users of Wine wish to run on top of a Unix-like system.

Basic architecture

The programming interface of Microsoft Windows consists largely of dynamic-link libraries (DLLs). These contain a huge number of wrapper sub-routines for the system calls of the kernel, the NTOS kernel-mode program (ntoskrnl.exe). A typical Windows program calls some Windows DLLs, which in turn calls user-mode gdi/user32 libraries, which in turn uses the kernel32.dll (win32 subsystem) responsible for dealing with the kernel through system calls. The system-call layer is considered private to Microsoft programmers as documentation is not publicly available, and published interfaces all rely on subsystems running on top of the kernel. Besides these, there are a number of programming interfaces implemented as services that run as separate processes. Applications communicate with user-mode services through RPCs.<ref name="archi">Template:Cite web</ref>

Wine implements the Windows application binary interface (ABI) entirely in user space, rather than as a kernel module. Wine mostly mirrors the hierarchy, with services normally provided by the kernel in Windows<ref>See the "Windows service" article</ref> instead provided by a daemon known as the wineserver, whose task is to implement basic Windows functionality, as well as integration with the X Window System, and translation of signals into native Windows exceptions. Although wineserver implements some aspects of the Windows kernel, it is not possible to use native Windows drivers with it, due to Wine's underlying architecture.<ref name="archi"/>

Libraries and applications

Wine allows for loading both Windows DLLs and Unix shared objects for its Windows programs. Its built-in implementation of the most basic Windows DLLs, namely NTDLL, KERNEL32, GDI32, and USER32, uses the shared object method because they must use functions in the host operating system as well. Higher-level libraries, such as WineD3D, are free to use the DLL format. In many cases users can choose to load a DLL from Windows instead of the one implemented by Wine. Doing so can provide functionalities not yet implemented by Wine, but may also cause malfunctions if it relies on something else not present in Wine.<ref name="archi"/>

Wine tracks its state of implementation through automated unit testing done at every git commit.<ref>Template:Cite web</ref>

Graphics and gaming

While most office software does not make use of complex GPU-accelerated graphics APIs, computer games do. To run these games properly, Wine would have to forward the drawing instructions to the host OS, and even translate them to something the host can understand.

DirectX is a collection of Microsoft APIs for rendering, audio and input. As of 2019, Wine 4.0 contains a DirectX 12 implementation for Vulkan API, and DirectX 11.2 for OpenGL.<ref name="wine-40">Template:Cite web</ref> Direct2D support has been updated to Direct2D 1.2.<ref name="wine-40"/> Wine 4.0 also allows Wine to run Vulkan applications by handing draw commands to the host OS, or in the case of macOS, by translating them into the Metal API by MoltenVK.<ref name="wine-40"/>

XAudio

Template:As of, Wine 4.3 uses the FAudio library (and Wine 4.13 included a fix for it) to implement the XAudio2 audio API (and more).<ref>Template:Cite web</ref><ref>Template:Cite web</ref>

XInput and Raw Input

Wine, since 4.0 (2019), supports game controllers through its builtin implementations of these libraries. They are built as Unix shared objects as they need to access the controller interfaces of the underlying OS, specifically through SDL.<ref name="wine-40"/>

Direct3D

Much of Wine's DirectX effort goes into building WineD3D, a translation layer from Direct3D and DirectDraw API calls into OpenGL. As of 2019, this component supports up to DirectX 11.<ref name="wine-40"/> As of 12 December 2016, Wine is good enough to run Overwatch with D3D11.<ref>Template:Cite web</ref> Besides being used in Wine, WineD3D DLLs have also been used on Windows itself, allowing for older GPUs to run games using newer DirectX versions and for old DDraw-based games to render correctly.<ref>Template:Cite web</ref>

Some work is ongoing to move the Direct3D backend to Vulkan API. Direct3D 12 support in 4.0 is provided by a "vkd3d" subproject,<ref name="wine-40"/> and WineD3D has in 2019 been experimentally ported to use the Vulkan API.<ref name="wine-46">Template:Cite web</ref> Another implementation, DXVK, translates Direct3D 8, 9, 10, and 11 calls using Vulkan as well and is a separate project.<ref>Template:Citation</ref>

Wine, when patched, can alternatively run Direct3D 9 API commands directly via a free and open-source Gallium3D State Tracker (aka Gallium3D GPU driver) without translation into OpenGL API calls. In this case, the Gallium3D layer allows a direct pass-through of DX9 drawing commands which results in performance improvements of up to a factor of 2.<ref name="d3d9">Template:Cite web</ref> As of 2020, the project is named Gallium.Nine. It is available now as a separate standalone package and no longer needs a patched Wine version.<ref name="Gallium.Nine">Template:Cite web</ref>

User interface

Wine is usually invoked from the command-line interpreter: wine program.exe.<ref name=man_wine>Template:Cite web</ref>

winecfg

File:Winecfg in Wine 10.0 applications screenshot.png

A screenshot showing how Wine can be configured to mimic different versions of Windows, going as far back as Windows 2.0 in the 32-bit version (64-bit Wine supports only 64-bit versions of Windows)

There is the utility winecfg that starts a graphical user interface with controls for adjusting basic options.<ref name=linuxconfig>Template:Cite news</ref> It is a GUI configuration utility included with Wine. Winecfg makes configuring Wine easier by making it unnecessary to edit the registry directly, although, if needed, this can be done with the included registry editor (similar to Windows regedit).

Third-party applications

File:PlayOnLinux-Screenshot.png

PlayOnLinux

Some applications require more tweaking than simply installing the application in order to work properly, such as manually configuring Wine to use certain Windows DLLs. The Wine project does not integrate such workarounds into the Wine codebase, instead preferring to focus solely on improving Wine's implementation of the Windows API. While this approach focuses Wine development on long-term compatibility, it makes it difficult for users to run applications that require workarounds. Consequently, many third-party applications have been created to ease the use of those applications that do not work out of the box within Wine itself. The Wine wiki maintains a page of current and obsolete third-party applications.<ref>Template:Cite web</ref>

• Winetricks is a script to install some basic components (typically Microsoft DLLs and fonts) and tweak settings required for some applications to run correctly under Wine.<ref>Template:Cite magazine</ref> It can fully automate the install of a number of applications and games, including applying any needed workarounds. Winetricks has a GUI.<ref>Template:Cite web</ref> The Wine project will accept bug reports for users of Winetricks, unlike most third-party applications. It is maintained by Wine developer Austin English.<ref>Template:Cite web</ref>
• Q4Wine is an open GUI for advanced setup of Wine.
• Wine-Doors is an application management tool for the GNOME desktop which adds functionality to Wine. Wine-Doors is an alternative to WineTools which aims to improve upon WineTools' features and extend on the original idea with a more modern design approach.<ref>Template:Cite web</ref>
• IEs4Linux is a utility to install all versions of Internet Explorer, including versions 4 to 6 and version 7 (in beta).<ref>Template:Cite web</ref>
• Wineskin is a utility to manage Wine engine versions and create wrappers for macOS.<ref>Template:Cite web</ref>
• PlayOnLinux is an application to ease the installation of Windows applications (primarily games). There is also a corresponding Macintosh version called PlayOnMac.
• Lutris is an open-source application to install Windows games on Linux.<ref>Template:Cite web</ref>
• Bordeaux is a proprietary Wine GUI configuration manager that runs winelib applications. It also supports installation of third-party utilities, installation of applications and games, and the ability to use custom configurations. Bordeaux currently runs on Linux, FreeBSD, PC-BSD, Solaris, OpenSolaris, OpenIndiana,<ref>Template:Cite web</ref><ref>Template:Cite web</ref> and macOS computers.
• Bottles is an open-source graphical Wine prefix and runners manager for Wine based on GTK4+Libadwaita. It provides a repository-based dependency installation system and bottle versioning to restore a previous state.<ref>Template:Cite web</ref>
• WineGUI is a free and open-source graphical interface to manage Wine. It allows a user to create Wine bottles and install Windows applications or games.<ref>Template:Cite web</ref>

Functionality

File:History Of WineAppDB.gif

App compatibility progress over time, according to Wine AppDB test results.
Template:Legend Template:Legend Template:Legend Template:Legend Template:Legend

File:WineHQ ratings.svg

WineHQ application ratings over the time.

The developers of the Direct3D portions of Wine have continued to implement new features such as pixel shaders to increase game support.<ref>Template:Cite web</ref> Wine can also use native DLLs directly, thus increasing functionality, but then a license for Windows is needed unless the DLLs were distributed with the application itself.

Wine also includes its own open-source implementations of several Windows programs, such as Notepad, WordPad, Control Panel, Internet Explorer, and Windows Explorer.<ref name=list_of_commands>Template:Cite web</ref>

The Wine Application Database (AppDB) is a community-maintained on-line database about which Windows programs works with Wine and how well they work.

Backward compatibility

Wine ensures good backward compatibility with legacy Windows applications, including those written for Windows 3.1x.<ref name="winelegacy">Template:Cite web</ref> Wine can mimic different Windows versions required for some programs, going as far back as Windows 2.0.<ref name="Wine Windows 2.0">Template:Cite news</ref> However, Windows 1.x and Windows 2.x support was removed from Wine development version 1.3.12. If DOSBox is installed on the systemTemplate:Citation needed (see below on MS-DOS), Wine development version 1.3.12 and later nevertheless show the "Windows 2.0" option for the Windows version to mimic, but Wine still will not run most Windows 2.0 programs because MS-DOS and Windows functions are not currently integrated.

Backward compatibility in Wine is generally superior to that of Windows, as newer versions of Windows can force users to upgrade legacy Windows applications, and may break unsupported software forever as there is nobody adjusting the program for the changes in the operating system. In many cases, Wine can offer better legacy support than newer versions of Windows with "Compatibility Mode". Wine can run 16-bit Windows programs (Win16) on a 64-bit operating system, which uses an x86-64 (64-bit) CPU,<ref>Template:Cite web</ref> a functionality not found in 64-bit versions of Microsoft Windows.<ref>Template:Cite web</ref><ref>Template:Cite web</ref> WineVDM allows 16-bit Windows applications to run on 64-bit versions of Windows.<ref>Template:Cite web On GitHub.</ref>

Wine partially supports Windows console applications, and the user can choose which backend to use to manage the console (choices include raw streams, curses, and user32).<ref>Template:Cite web</ref> When using the raw streams or curses backends, Windows applications will run in a Unix terminal.

64-bit applications

Preliminary support for 64-bit Windows applications was added to Wine 1.1.10, in December 2008.<ref>Template:Cite mailing list</ref> Template:As of, the support is considered stable. The two versions of Wine are built separately, and as a result only building wine64 produces an environment only capable of running x86-64 applications.<ref name="Build">Template:Cite web</ref>

Template:As of, Wine has stable support for a WoW64 build, which allows both 32-bit and 64-bit Windows applications to run inside the same Wine instance. To perform such a build, one must first build the 64-bit version, and then build the 32-bit version referencing the 64-bit version. Just like Microsoft's WoW64, the 32-bit build process will add parts necessary for handling 32-bit programs to the 64-bit build.<ref name="Build"/> This functionality is seen from at least 2010.<ref>Template:Cite web</ref>

MS-DOS

Early versions of Microsoft Windows run on top of MS-DOS, and Windows programs may depend on MS-DOS programs to be usable. Wine does not have good support for MS-DOS, but starting with development version 1.3.12, Wine tries running MS-DOS programs in DOSBox if DOSBox is available on the system.<ref>Template:Cite web</ref> However, due to a bug, current versionsTemplate:Update inline of Wine incorrectly identify Windows 1.x and Windows 2.x programs as MS-DOS programs, attempting to run them in DOSBox (which does not work).<ref>Template:Cite web</ref>

Winelib

Wine provides Winelib, which allows its shared-object implementations of the Windows API to be used as actual libraries for a Unix program. This allows for Windows code to be built into native Unix executables. Since October 2010, Winelib also works on the ARM platform.<ref>Template:Cite web</ref>

Non-x86 architectures

Support for Solaris SPARC was dropped in version 1.5.26.

ARM, Windows CE, and Windows RT

Wine provides some support for ARM (as well as ARM64/AArch64) processors and the Windows flavors that run on it. Template:As of, Wine can run ARM/Win32 applications intended for unlocked Windows RT devices (but not Windows RT programs). Windows CE support (either x86 or ARM) is missing,<ref>Template:Cite web</ref> but an unofficial, pre-alpha proof-of-concept version called WineCE allows for some support.<ref>Template:Cite web</ref>

Wine for Android

File:Wine-solitaire-on-android.jpg

WINE Solitaire running on Android

On 3 February 2013 at the FOSDEM talk in Brussels, Alexandre Julliard demonstrated an early demo of Wine running on Google's Android operating system.<ref>Template:Cite web</ref>

Experimental builds of WINE for Android (x86 and ARM) were released in late 2017. It has been routinely updated by the official developers ever since.<ref name="dl.winehq.org" /> The default builds do not implement cross-architecture emulation via QEMU, and as a result ARM versions will only run ARM applications that use the Win32 API.<ref>Template:Cite web</ref>

Microsoft applications

Wine, by default, uses specialized Windows builds of Gecko and Mono to substitute for Microsoft's Internet Explorer and .NET Framework. Wine has built-in implementations of JScript and VBScript. It is possible to download and run Microsoft's installers for those programs through winetricks or manually.

Wine is not known to have good support for most versions of Internet Explorer (IE). Of all the reasonably recent versions, Internet Explorer 8 for Windows XP is the only version that reports a usable rating on Wine's AppDB, out-of-the-box.<ref>Template:Cite web</ref> However Google Chrome gets a gold rating (as of Wine 5.5-staging),<ref>Template:Cite web</ref> and Microsoft's IE replacement web browser Edge, is known to be based on that browser (after switching from Microsoft's own rendering engine<ref>Template:Cite web</ref>). Winetricks offer auto-installation for Internet Explorer 6 through 8, so these versions can be reasonably expected to work with its built-in workarounds.

An alternative for installing Internet Explorer directly is to use the now-defunct IEs4Linux. It is not compatible with the latest versions of Wine,<ref>Template:Cite web</ref> and the development of IEs4Linux is inactive.

Other versions of Wine

The core Wine development aims at a correct implementation of the Windows API as a whole and has sometimes lagged in some areas of compatibility with certain applications. Direct3D, for example, remained unimplemented until 1998,<ref>Template:Cite news</ref> although newer releases have had an increasingly complete implementation.<ref>Template:Cite web</ref>

CrossOver

CodeWeavers markets CrossOver specifically for running Microsoft Office and other major Windows applications, including some games. CodeWeavers employs Alexandre Julliard to work on Wine and contributes most of its code to the Wine project under the LGPL. CodeWeavers also released a new version called CrossOver Mac for Intel-based Apple Macintosh computers on 10 January 2007.<ref>Template:Cite web</ref> Unlike upstream wine, CrossOver is notably able to run on the x64-only versions of macOS,<ref>Template:Cite web</ref> using a technique known as "wine32on64".<ref>Template:Cite web</ref>

As of 2012, CrossOver includes the functionality of both the CrossOver Games and CrossOver Pro lines therefore CrossOver Games and CrossOver Pro are no longer available as single products.<ref>Template:Cite web</ref>

CrossOver Games was optimized for running Windows video games. Unlike CrossOver, it didn't focus on providing the most stable version of Wine. Instead, experimental features are provided to support newer games.<ref>Template:Cite web</ref>

Proton

On 21 August 2018, Valve announced a new variation of Wine, named Proton, designed to integrate with the Linux version of the company's Steam software (including Steam installations built into their Linux-based SteamOS operating system and Steam Machine computers).<ref name="proton_announcement">Template:Cite web</ref> Valve's goal for Proton is to enable Steam users on Linux to play games which lack a native Linux port (particularly back-catalog games), and ultimately, through integration with Steam as well as improvements to game support relative to mainline Wine, to give users "the same simple plug-and-play experience" that they would get if they were playing the game natively on Linux.<ref name="proton_announcement"/> Proton entered public beta immediately upon being announced.<ref name="proton_announcement"/>

Valve had already been collaborating with CodeWeavers since 2016 to develop improvements to Wine's gaming performance, some of which have been merged to the upstream Wine project.<ref name="proton_announcement"/> Some of the specific improvements incorporated into Proton include Vulkan-based Direct3D 9, 10, 11, and 12 implementations via vkd3d,<ref>Template:Cite web</ref> DXVK,<ref>Template:Cite web</ref> and D9VK<ref>Template:Cite web</ref> multi-threaded performance improvements via esync,<ref>Template:Cite web</ref> improved handling of fullscreen games, and better automatic game controller hardware support.<ref name="proton_announcement"/>

Proton is fully open-source and available via GitHub.<ref>Template:Cite web</ref>

WINE@Etersoft

Template:Main The Russian company Etersoft has been developing a proprietary version of Wine since 2006. WINE@Etersoft supports popular Russian applications (for example, 1C:Enterprise by 1C Company).<ref>Template:Cite web</ref>

Other projects using Wine source code

Other projects using Wine source code include:

• OTVDM,<ref>Template:Cite web</ref> a 16-bit app compatibility layer for 64-bit Windows.
• ReactOS, a project to write an operating system compatible with Windows NT versions 5.x and up (which includes Windows 2000 and its successors) down to the device driver level. ReactOS uses Wine source code considerably; however due to architectural differences with ReactOS its code is not generally reused in Wine, such as in the case of ReactOS specific DLLs, such as ntdll, user32, kernel32, gdi32, and advapi.<ref>Template:Cite web</ref> In July 2009, Aleksey Bragin, the ReactOS project lead, started<ref>Template:Cite web</ref> a new ReactOS branch called Arwinss,<ref>Template:Cite web</ref> and it was officially announced in January 2010.<ref>Template:Cite web</ref> Arwinss is an alternative implementation of the core Win32 components, and uses mostly unchanged versions of Wine's user32.dll and gdi32.dll.
• WineBottler,<ref name="winebottler">Template:Cite web</ref> a wrapper around Wine in the form of a normal Mac application. It manages multiple Wine configurations for different programs in the form of "bottles."
• Wineskin, an open source Wine GUI configuration manager for macOS. Wineskin creates a wrapper around Wine in the form of a normal Mac Application. The wrapper can also be used to make a distributable "port" of software.<ref>Template:Cite web</ref>
• Odin, a project to run Win32 binaries on OS/2 or convert them to OS/2 native format. The project also provides the Odin32 API to compile Win32 programs for OS/2.
• Virtualization products such as Parallels Desktop for Mac and VirtualBox use WineD3D to make use of the GPU.
• WinOnX, a commercial package of Wine for macOS that includes a GUI for adding and managing applications and virtual machines.<ref>Template:Cite web</ref>
• WineD3D for Windows, a compatibility wrapper which emulates old Direct3D versions and features that were removed by Microsoft in recent Windows releases, using OpenGL. This sometimes gets older games working again.<ref>Template:Cite web</ref>
• Apple Game Porting Toolkit, a suite of software introduced at Apple's Worldwide Developer Conference in June 2023 to facilitate porting games from Windows to Mac.<ref>Template:Citation</ref>

Discontinued

• Cedega / WineX: TransGaming Inc. (now Findev Inc. since the sale of its software businesses) produced the proprietary Cedega software. Formerly known as WineX, Cedega represented a fork from the last MIT-licensed version of Wine in 2002. Much like CrossOver Games, TransGaming's Cedega was targeted towards running Windows video games. On 7 January 2011, TransGaming Inc. announced continued development of Cedega Technology under the GameTree Developer Program. TransGaming Inc. allowed members to keep using their Cedega ID and password until 28 February 2011.<ref>Template:Cite web</ref>
• Cider: TransGaming also produced Cider, a library for Apple–Intel architecture Macintoshes. Instead of being an end-user product, Cider (like Winelib) is a wrapper allowing developers to adapt their games to run natively on Intel Mac without any changes in source code.
• Template:AnchorDarwine: a port of the Wine libraries to Darwin and Mac OS X for the PowerPC and Intel x86 (32-bit) architectures, created by the OpenDarwin team in 2004.<ref>Template:Cite web</ref><ref>Template:Cite web</ref> Its PowerPC version relied on QEMU.<ref name="Ogasawara2006">Template:Cite book</ref> Darwine was merged back into Wine in 2009.<ref>Template:Cite web</ref><ref>Template:Cite web</ref>
• E/OS LX: a project attempting to allow any program designed for any operating system to be run without the need to actually install any other operating system.
• Pipelight: a custom version of Wine (wine-compholio) that acts as a wrapper for Windows NPAPI plugins within Linux browsers.<ref>Template:Cite web</ref> This tool permits Linux users to run Microsoft Silverlight, the Microsoft equivalent of Adobe Flash, and the Unity web plugin, along with a variety of other NPAPI plugins. The project provides an extensive set of patches against the upstream Wine project,<ref>Template:Cite web</ref> some of which were approved and added to upstream Wine. Pipelight is largely obsolete, as modern browsers no longer support NPAPI plugins and Silverlight has been deprecated by Microsoft.<ref>Template:Cite web</ref>

Reception

The Wine project has received a number of technical and philosophical complaints and concerns over the years.

Security

Because of Wine's ability to run Windows binary code, concerns have been raised over native Windows viruses and malware affecting Unix-like operating systems<ref>Template:Cite newsgroup</ref> as Wine can run limited malware made for Windows. A 2018 security analysis found that 5 out of 30 malware samples were able to successfully run through Wine, a relatively low rate that nevertheless posed a security risk.<ref>Template:Cite journal</ref> For this reason the developers of Wine recommend never running it as the superuser.<ref>Template:Cite web</ref> Malware research software such as ZeroWine<ref>Template:Cite web</ref> runs Wine on Linux in a virtual machine, to keep the malware completely isolated from the host system. An alternative to improve the security without the performance cost of using a virtual machine, is to run Wine in an LXC container, as Anbox software is doing by default with Android.

Another security concern is when the implemented specifications are ill-designed and allow for security compromise. Because Wine implements these specifications, it will likely also implement any security vulnerabilities they contain. One instance of this problem was the 2006 Windows Metafile vulnerability, which saw Wine implementing the vulnerable SETABORTPROC escape.<ref>Template:Cite web</ref><ref>Template:Cite web</ref>

Wine vs. native Unix applications

A common concern about Wine is that its existence means that vendors are less likely to write native Linux, macOS, and BSD applications. As an example of this, it is worth considering IBM's 1994 operating system, OS/2 Warp.Template:Original research inline An article describes the weaknesses of OS/2 which killed it, the first one being:

However, OS/2 had many problems with end user acceptance. Perhaps the most serious was that most computers sold already came with DOS and Windows, and many people didn't bother to evaluate OS/2 on its merits due to already having an operating system. "Bundling" of DOS and Windows and the chilling effect this had on the operating system market frequently came up in United States v. Microsoft Corporation.

The Wine project itself responds to the specific complaint of "encouraging" the continued development for the Windows API on one of its wiki pages: Template:Blockquote

Also, the Wine Wiki page claims that Wine can help break the chicken-and-egg problem for Linux on the desktop:<ref>Template:Cite web</ref> Template:Blockquote

The use of Wine for gaming has proved specifically controversial in the Linux community, as some feel it is preventing, or at least hindering, the further growth of native Linux gaming on the platform.<ref>Template:Cite web</ref><ref>Template:Cite web</ref> One quirk however is that Wine is now able to run 16-bit and even certain 32-bit applications and games that do not launch on current 64-bit Windows versions.<ref>Template:Cite web</ref> This use-case has led to running Wine on Windows itself via Windows Subsystem for Linux or third-party virtual machines,Template:Citation needed as well as encapsulated by means such as BoxedWine<ref>Template:Cite web</ref> and Otvdm.<ref>Template:Cite web</ref>

Microsoft

Until 2020, Microsoft had not made any public statements about Wine. However, the Windows Update online service will block updates to Microsoft applications running in Wine. On 16 February 2005, Ivan Leo Puoti discovered that Microsoft had started checking the Windows Registry for the Wine configuration key and would block the Windows Update for any component.<ref>Template:Cite mailing list</ref> As Puoti noted: "It's also the first time Microsoft acknowledges the existence of Wine."

In January 2020, Microsoft cited Wine as a positive consequence of being able to reimplement APIs, in its amicus curiae brief for Google LLC v. Oracle America, Inc.<ref>Template:Cite web</ref>

In August 2024, Microsoft donated the Mono Project, a reimplementation of the .NET Framework, to the developers of Wine.<ref>Template:Cite web</ref>

See also

• Anbox
• Columbia Cycada
• Darling (software)
• Executor (software)
• List of free and open-source software packages
• Linux kernel API
• Mono (software)
• PlayOnLinux
• PlayOnMac
• ReactOS
• Windows Interface Source Environment
• Windows Subsystem for Linux

Further reading

• Jeremy White's Wine Answers – Slashdot interview with Jeremy White of CodeWeavers
• Template:Cite web
• Appointment of the Software Freedom Law Center as legal counsel to represent the Wine project
• Wine: Where it came from, how to use it, where it's going – a work by Dan Kegel

External links

• Template:Official website