Hubbry Logo
Wine (software)Wine (software)Main
Open search
Wine (software)
Community hub
Wine (software)
logo
8 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Wine (software)
Wine (software)
Wine (software)
View on Wikipedia
from Wikipedia

Wine
Original authorsBob Amstadt, Eric Youngdale
DevelopersWine authors[1]
(1,989)
Initial release4 July 1993; 32 years ago (1993-07-04)
Stable release
10.0[2] Edit this on Wikidata / 21 January 2025
Repositorygitlab.winehq.org/wine/wine
Written inC
Operating system
PlatformIA-32, x86-64, ARM
Available inMultilingual
TypeCompatibility layer
LicenseLGPL 2.1 or later[6][7]
Websitewinehq.org

Wine[a] 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, except on Apple silicon Mac computers, where Rosetta 2 is used to translate x86 code to ARM code. 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.[9] This plurality was larger than all x86 virtualization programs combined, and larger than the 27.9% who reported not running Windows applications.[10]

History

[edit]

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,[11] 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.[12] Wine originally targeted 16-bit applications for Windows 3.x, but as of 2010 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.[13] 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.[14] Consequently, the Wine team has reverse-engineered many function calls and file formats in such areas as thunking.[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,[15] work as of March 2002 has used the LGPL for its licensing.[16]

Wine officially entered beta with version 0.9 on 25 October 2005.[17] Version 1.0 was released on 17 June 2008,[18] after 15 years of development. Version 1.2 was released on 16 July 2010,[19] version 1.4 on 7 March 2012,[20] version 1.6 on 18 July 2013,[21] version 1.8 on 19 December 2015[22] and version 9.0 on 16 January 2024.[23] 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. As of 2019, WineHQ also provides pre-built versions of wine-staging.[24]

Corporate sponsorship

[edit]

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.[25]

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.[26]

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.[27] Wine is also a regular beneficiary of Google's Summer of Code program.[28]

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

[edit]

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

[edit]

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.[29]

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[30] 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.[29]

Libraries and applications

[edit]

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.[29]

Wine tracks its state of implementation through automated unit testing done at every git commit.[31]

Graphics and gaming

[edit]

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.[32] Direct2D support has been updated to Direct2D 1.2.[32] 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.[32]

XAudio
As of February 2019, Wine 4.3 uses the FAudio library (and Wine 4.13 included a fix for it) to implement the XAudio2 audio API (and more).[33][34]
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.[32]

Direct3D

[edit]

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.[32] As of 12 December 2016, Wine is good enough to run Overwatch with D3D11.[35] 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.[36]

Some work is ongoing to move the Direct3D backend to Vulkan API. Direct3D 12 support in 4.0 is provided by a "vkd3d" subproject,[32] and WineD3D has in 2019 been experimentally ported to use the Vulkan API.[37] Another implementation, DXVK, translates Direct3D 8, 9, 10, and 11 calls using Vulkan as well and is a separate project.[38]

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.[39] 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.[40]

User interface

[edit]

Wine is usually invoked from the command-line interpreter: wine program.exe.[41]

winecfg

[edit]
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.[42] 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

[edit]
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.[43]

  • 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.[44] It can fully automate the install of a number of applications and games, including applying any needed workarounds. Winetricks has a GUI.[45] The Wine project will accept bug reports for users of Winetricks, unlike most third-party applications. It is maintained by Wine developer Austin English.[46]
  • 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.[47]
  • IEs4Linux is a utility to install all versions of Internet Explorer, including versions 4 to 6 and version 7 (in beta).[48]
  • Wineskin is a utility to manage Wine engine versions and create wrappers for macOS.[49]
  • 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.[50]
  • 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,[51][52] 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.[53]
  • 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.[54]

Functionality

[edit]
App compatibility progress over time, according to Wine AppDB test results.
  Software works flawlessly
  Software works flawlessly after configuration
  Minor problems with the software
  Major problems with the software
  Completely non-functional software
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.[55] 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.[56]

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

[edit]

Wine ensures good backward compatibility with legacy Windows applications, including those written for Windows 3.1x.[57] Wine can mimic different Windows versions required for some programs, going as far back as Windows 2.0.[58] However, Windows 1.x and Windows 2.x support was removed from Wine development version 1.3.12. If DOSBox is installed on the system[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,[59] a functionality not found in 64-bit versions of Microsoft Windows.[60][61] WineVDM allows 16-bit Windows applications to run on 64-bit versions of Windows.[62]

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).[63] When using the raw streams or curses backends, Windows applications will run in a Unix terminal.

64-bit applications

[edit]

Preliminary support for 64-bit Windows applications was added to Wine 1.1.10, in December 2008.[64] As of April 2019, 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.[65]

As of April 2019, 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.[65] This functionality is seen from at least 2010.[66]

MS-DOS

[edit]

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.[67] Due to a bug, Wine also incorrectly identifies Windows 1.x and Windows 2.x programs as MS-DOS programs, unsuccessfully attempting to run them in DOSBox.[68]

Winelib

[edit]

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.[69]

Non-x86 architectures

[edit]

Support for Solaris SPARC was dropped in version 1.5.26.

ARM, Windows CE, and Windows RT

[edit]

Wine provides some support for ARM (as well as ARM64/AArch64) processors and the Windows flavors that run on it. As of April 2019, 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,[70] but an unofficial, pre-alpha proof-of-concept version called WineCE allows for some support.[71]

Wine for Android

[edit]
Microsoft Solitaire running on WINE 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.[72]

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.[4] 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.[73]

Microsoft applications

[edit]

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.[74] However Google Chrome gets a gold rating (as of Wine 5.5-staging),[75] and Microsoft's IE replacement web browser Edge, is known to be based on that browser (after switching from Microsoft's own rendering engine[76]). 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,[77] and the development of IEs4Linux is inactive.

Other versions of Wine

[edit]

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,[78] although newer releases have had an increasingly complete implementation.[79]

CrossOver

[edit]
Main article: CrossOver (software)

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.[80] Unlike upstream wine, CrossOver is notably able to run on the x64-only versions of macOS,[81] using a technique known as "wine32on64".[82]

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.[83]

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.[84]

Proton

[edit]
Main article: Proton (software)

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).[85] 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.[85] Proton entered public beta immediately upon being announced.[85]

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.[85] Some of the specific improvements incorporated into Proton include Vulkan-based Direct3D 9, 10, 11, and 12 implementations via vkd3d,[86] DXVK,[38] and D9VK[87] multi-threaded performance improvements via esync,[88] improved handling of fullscreen games, and better automatic game controller hardware support.[85]

Proton is fully open-source and available via GitHub.[89]

WINE@Etersoft

[edit]
Main article: WINE@Etersoft

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).[90]

Other projects using Wine source code

[edit]

Other projects using Wine source code include:

  • WineVDM, a.k.a. OTVDM, a 16-bit app compatibility layer for 64-bit Windows[62]
  • 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, ReactOS cannot directly reuse Wine's NTDLL, USER32, KERNEL32, GDI32, and ADVAPI32 components.[91][92] In July 2009, Aleksey Bragin, the ReactOS project lead, started[93] a new ReactOS branch called Arwinss,[94] and it was officially announced in January 2010.[95] Arwinss is an alternative implementation of the core Win32 components, and uses mostly unchanged versions of Wine's user32.dll and gdi32.dll.
  • WineBottler,[96] 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.[97]
  • 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.[98]
  • 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.[36]
  • 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.[99]

Discontinued

[edit]
  • 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.[100]
  • 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.
  • Darwine: 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.[101][102] Its PowerPC version relied on QEMU.[103] Darwine was merged back into Wine in 2009.[104][105]
  • 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.[106] 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,[107] 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.[108]

Reception

[edit]

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

Security

[edit]

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[109] 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.[110] For this reason the developers of Wine recommend never running it as the superuser.[111] Malware research software such as ZeroWine[112] 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.[113][114]

Wine vis-à-vis native Unix applications

[edit]

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.[original research?] An article describes the weaknesses of OS/2 which killed it, the first one being:

OS/2 offered excellent compatibility with DOS and Windows 3.1 applications. No, this is not an error. Many application vendors argued that by developing a DOS or Windows app, they would reach the OS/2 market in addition to DOS/Windows markets and they didn't develop native OS/2 applications.[115]

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:

For most people there remain a handful of programs locking them in to Windows. It's obvious there will never be a Microsoft Office ported to Linux, however older versions of programs like TurboTax won't be ported either. Similarly, there are tens of thousands of games and internal corporate applications which will never be ported. If you want to use Linux and rely on any legacy Windows application, something like Wine is essential... Wine makes Linux more useful and allows for millions of users to switch who couldn't otherwise. This greatly raises Linux marketshare, drawing more commercial and community developers to Linux.[116]

Also, the Wine Wiki page claims that Wine can help break the chicken-and-egg problem for Linux on the desktop:[117]

This brings us to the chicken and egg issue of Linux on the desktop. Until Linux can provide equivalents for the above applications, its market share on the desktop will stagnate. But until the market share of Linux on the desktop rises, no vendor will develop applications for Linux. How does one break this vicious circle?

Again, Wine can provide an answer. By letting users reuse the Windows applications they have invested time and money in, Wine dramatically lowers the barrier that prevents users from switching to Linux. This then makes it possible for Linux to take off on the desktop, which increases its market share in that segment. In turn, this makes it viable for companies to produce Linux versions of their applications, and for new products to come out just for the Linux market.

This reasoning could be dismissed easily if Wine was only capable of running Solitaire. However, now it can run Microsoft Office, multimedia applications such as QuickTime and Windows Media Player, and even games such as Max Payne or Unreal Tournament 3. Almost any other complex application can be made to run well given a bit of time. And each time that work is done to add one application to this list, many other applications benefit from this work and become usable too.

Have a look at our Application Database to get an idea on what can be run under Wine.

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.[118][119] 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.[120] This use-case has led to running Wine on Windows itself via Windows Subsystem for Linux or third-party virtual machines,[citation needed] as well as encapsulated by means such as BoxedWine[121] and otvdm.[122]

Microsoft

[edit]

Until 2020, Microsoft had not made any public statements about Wine. However, the Windows Update online service blocks 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.[123] 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.[124]

In August 2024, Microsoft donated the Mono Project, a reimplementation of the .NET Framework, to the developers of Wine.[125]

See also

[edit]

Notes

[edit]

References

[edit]

Further reading

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Wine (software)

View on Grokipedia
from Grokipedia
Wine is a free and open-source compatibility layer that allows applications designed for Windows to run on operating systems, such as , macOS, and BSD systems. Originally an acronym for "Wine Is Not an Emulator," it functions by translating calls into equivalent calls, enabling Windows software to integrate directly with the host environment without the performance or memory overhead associated with full emulation or virtualization. Development of Wine began in 1993, when Bob Amstadt started the project to enable Windows 3.1 applications to run on . Since its inception, the project has been primarily led by developer Alexandre Julliard, who took over early in its history. After more than 15 years of effort, Wine reached its first stable 1.0 release in 2008, marking a significant milestone in its compatibility capabilities. The software is licensed under open-source terms and is developed collaboratively by a global community of volunteers, who contribute roughly half of the codebase, supplemented by commercial sponsors including , a company that builds proprietary products based on Wine. Wine supports a wide range of Windows APIs and remains portable across various POSIX-compliant platforms, with no inherent performance penalties for running compatible applications. The project maintains an estimated user base in the millions and depends on community involvement for testing application compatibility via the Wine Application Database, reporting bugs through its tracker, and discussing issues on dedicated forums. As of January 2026, Wine continues active development, with the latest stable release being version 10.0 and ongoing development releases, such as 10.5, incorporating updates like improved Mono engine support and enhanced graphics handling.

History

Origins and Development

The Wine project originated in 1993 when Bob Amstadt initiated development as a method to execute applications on operating systems. This effort addressed the growing dominance of Windows software while leveraging the emerging popularity of , aiming to provide compatibility without the overhead of full emulation. The first public release of Wine appeared in 1993, marking the project's debut as an open-source initiative under the X11 , a permissive variant similar to the BSD license. Early development emphasized translating calls into equivalent and X11 system calls on-the-fly, focusing on x86 architecture to enable native execution of Windows binaries without requiring the underlying Windows operating system. This approach avoided the performance penalties associated with virtual machines, prioritizing seamless integration of Windows applications into environments. In 1994, Alexandre Julliard assumed leadership of the project, having been one of its initial contributors; he has maintained this role ever since, steering its technical direction and community coordination. Under Julliard's guidance, the project transitioned in to the GNU Lesser General Public License (LGPL), which facilitated greater commercial adoption by allowing proprietary extensions while preserving open-source principles. From its inception through the mid-2000s, Wine progressed from rudimentary implementations of core DLLs—often supplemented by user overrides with native Windows libraries—to a more robust, self-contained reimplementation of the Windows API. This evolution enabled support for increasingly complex applications, establishing Wine as a foundational tool for cross-platform software compatibility by 2000.

Major Releases and Milestones

Wine's journey toward stability culminated in the release of version 1.0 on June 17, 2008, marking the first version after 15 years of development and providing a reliable foundation for running Windows applications on systems. This milestone ensured consistent behavior for developers integrating Wine into their workflows. The release of Wine 2.0 on January 24, 2017, represented another pivotal update, introducing enhanced 11 support with partial asynchronous compute capabilities and 64-bit compatibility on macOS, which significantly boosted performance for gaming and applications. These advancements underscored Wine's growing emphasis on gaming optimizations, enabling smoother rendering in resource-intensive titles. In 2024, Wine 9.0, released on January 16, arrived with over 7,000 changes, including improved support through loader compatibility for ARM64 Windows binaries and the completion of PE/Unix module separation for better cross-architecture execution. This version also introduced experimental architecture as a major re-architecting milestone, alongside an initial Wayland driver for basic window management on . By 2025, Wine 10.0, released on January 21, further enhanced Wayland integration with native support, including rendering, proper popup positioning, and HiDPI scaling improvements for high-resolution displays. The update also featured an experimental driver and a new opt-in FFmpeg backend, contributing to refined debugging and media handling capabilities. Complementing these releases, Wine-Staging was introduced in 2014 as a parallel branch to accelerate the rollout of experimental features through staged integration, allowing users and developers to test patches not yet ready for the mainline while fostering feedback. This approach has enabled quicker adoption of innovations, such as early explorations, before their stabilization in core versions. As of November 2025, development continues with the 10.x series, reaching version 10.19 in bi-weekly releases featuring improvements such as support for memory mapping in mode.

Corporate Involvement

CodeWeavers initiated its sponsorship of the Wine project in 2002 by launching CrossOver, a commercial product based on Wine, and committing to contribute all related modifications back to the open-source effort. This involvement enabled the funding of full-time developers, including project leader Alexandre Julliard, providing essential resources for sustained and ensuring the project's technical advancement. As the primary corporate backer, has focused on enhancing Windows application compatibility across platforms. The Wine project operates under the fiscal sponsorship of the , a 501(c)(3) non-profit organization that manages donations to support core activities, including the annual WineConf developer conference. WineConf, first held in , gathers Wine contributors to review progress, plan features, and foster collaboration among the global development community. These events, funded through donations, have played a key role in coordinating efforts and maintaining project momentum since their inception. During the 2010s, provided code contributions to bolster Wine's capabilities, including collaborations on kernel-level features like User-Mode Instruction Prevention to improve hardware compatibility and in rendering. supported Wine's expansion through its Summer of Code program, funding student-led initiatives that advanced the Android port, enabling Windows applications to run on mobile systems. These corporate inputs from hardware and tech giants addressed specific technical challenges in cross-platform execution. Valve's entry in via Steam Play and the compatibility layer marked a pivotal resource infusion, with the company funding dedicated development teams and upstreaming enhancements to Wine's core codebase. This partnership, involving joint work with , dramatically improved gaming performance and compatibility on , accelerating Wine's adoption in high-impact scenarios. Proton's modifications, such as Vulkan-based translations, were progressively integrated back into Wine, benefiting the broader ecosystem. CrossOver serves as a notable commercial derivative of Wine, offering a polished interface and support for enterprise users while channeling innovations upstream.

Design

Core Architecture

Wine functions as a that enables the execution of Windows applications on operating systems by implementing Windows APIs through POSIX-compliant calls, thereby avoiding the need for a Windows or emulation of the underlying hardware. This translation approach allows Wine to load and run Windows executables directly on the host system, replacing Windows-specific behaviors with equivalent Unix functionality while maintaining compatibility with the Windows . Central to Wine's structure are key components that emulate the environment. The Wine prefix serves as an isolated , typically located at ~/.wine, containing a simulated Windows (e.g., the drive_c directory) and emulated registry hives stored in files such as system.reg and user.reg to replicate the without altering the host system. NT syscall thunking is handled by the ntdll.dll module, which intercepts kernel calls and forwards them to the underlying Unix kernel via interfaces. Wine supports the loading of Windows binaries in the (PE) file format through its built-in loader, which parses the executable structure and maps it into the host process memory. To ensure compatibility, Wine employs mechanisms, allowing native Windows DLLs to be overridden or supplemented with Wine's open-source implementations, which are loaded dynamically to provide the necessary stubs and translations. The API translation process relies on interception via hooks embedded in Wine's DLLs, where Windows function calls are captured and redirected to Unix equivalents; for instance, Win32 API calls for window management are mapped to X11 protocol operations on Unix desktops. This layered interception occurs at runtime, enabling transparent substitution without modifying the original application code. Graphics handling is briefly referenced through sub-components like WineD3D, which translates higher-level Windows graphics APIs to OpenGL for rendering. Beginning with Wine 9.0 (released in 2024), the project introduced a new (Windows-on-Windows 64-bit) architecture. This allows 32-bit Windows applications to run natively on 64-bit Wine prefixes without relying on the older thunking layers, reducing overhead and expanding compatibility for legacy software on modern systems. Wine operates on a multi-process model to manage complexity and isolation, with the wineserver acting as a dedicated daemon process that facilitates (IPC) and . The wineserver emulates Windows kernel services, such as handle management, thread coordination, and , using Unix sockets and semaphores to relay requests between Wine processes and the host OS, ensuring consistent behavior across multiple Windows-like applications running concurrently.

Component Libraries

Wine implements a range of modular component libraries that emulate key Windows subsystems, enabling compatibility with various application functionalities. Central to this are the core libraries, including kernel32.dll, which manages process creation, memory allocation, thread handling, and file input/output operations by mapping calls to Unix equivalents. Similarly, user32.dll provides support for elements such as windows, menus, and message handling, facilitating the creation and interaction of graphical user interfaces. gdi32.dll offers primitives for drawing lines, shapes, and text, interfacing briefly with higher-level rendering components for basic 2D operations. Additional subsystem-specific libraries address specialized Windows features. ntdll.dll delivers low-level NT kernel APIs, including system calls for security, registry access, and native object management, serving as the foundational layer between user-mode applications and the Wine server. shell32.dll emulates shell functions akin to those in Windows Explorer, such as file operations, context menus, and system dialogs for tasks like browsing directories and launching applications. For networking, wininet.dll handles high-level internet protocols including HTTP, FTP, and , while Winsock emulation through ws2_32.dll supports socket-based communications, translating Windows network APIs to sockets on the host system. File I/O operations are primarily routed through kernel32.dll, which abstracts Windows file handling to Unix file descriptors, with Wine's drive mapping feature allowing users to assign Windows drive letters to host directories for seamless access to local and networked storage. This mapping supports integration with host file systems. Over time, Wine's library ecosystem has evolved to incorporate stubs and partial implementations for contemporary Windows APIs. By the early 2020s, development efforts added initial stubs for WinRT libraries, enabling basic support for modern components and facilitating compatibility with newer applications.

Graphics Rendering

Wine's graphics rendering subsystem primarily relies on the X11 backend for window management and display handling on operating systems, a foundation established since the project's early development in the 1990s to interface with the for creating and managing windows, handling input events, and rendering 2D graphics. This backend leverages Xlib and XRender extensions to emulate Windows' low-level drawing primitives, enabling compatibility with legacy applications that depend on direct screen access without modern compositing. For enhanced performance in 2D operations, Wine's implementation of the (GDI) utilizes XRender for accelerated blitting, line drawing, and bitmap manipulation, reducing CPU overhead compared to pure software fallback modes. DirectDraw, the Windows API for 2D hardware-accelerated graphics, is emulated in Wine through a combination of GDI-based software rendering and an OpenGL-accelerated path via the WineD3D library, which translates DirectDraw calls to OpenGL for smoother performance in full-screen or overlaid surfaces. Users can configure the renderer to prioritize OpenGL for or revert to GDI for compatibility with older hardware lacking robust OpenGL support, though the former offers better scalability for complex scenes by offloading computations to the GPU. This dual approach ensures broad compatibility while optimizing for systems with varying graphics capabilities. In 2019, with the release of Wine 4.0, support for the API was introduced as a low-level, cross-platform rendering backend, enabling more efficient graphics pipelines by providing direct access to modern GPU features like management and reduced driver overhead. integration in Wine facilitates translation of higher-level Windows graphics calls to native commands, improving rendering efficiency on and other platforms without relying solely on translations, particularly beneficial for resource-intensive visualizations. Subsequent updates, such as Wine 5.0's 1.1 conformance, further refined this support for broader hardware compatibility. For modern user interface elements, Wine handles —a hardware-accelerated 2D graphics —and DirectWrite—a text layout and rendering library—starting with core implementations in Wine 1.8 (2014), which added support for font loading, text shaping, and basic geometry drawing using DirectX Intermediate Language (DXIL) shaders backed by . These s enable vector-based rendering, gradient brushes, and subpixel text , essential for applications with rich UIs like web browsers or . Improvements in Wine 3.0 (2018) extended with outline stroking, gradient implementations, and GDI interoperability, while enhancing DirectWrite with advanced line spacing, bold simulation, and thread-safe caching for better scalability in multi-threaded scenarios. , as a higher-level , builds upon these foundational 2D and text rendering capabilities for 3D extensions. Performance considerations in Wine's graphics stack include offscreen rendering modes, which allow applications to generate without displaying them on a visible window, useful for non-interactive tasks like image processing or server-side rendering. By default enabled for in Wine 1.5.10 and later, this mode bypasses window system overhead, potentially boosting frame rates by up to several times in benchmarks for compute-heavy workloads, though it requires sufficient GPU memory to avoid swapping. Such optimizations are particularly relevant for batch applications, where direct-to-texture rendering minimizes latency compared to on-screen . Wine 9.0 (2024) introduced an experimental Wayland graphics driver, enabling direct support for the Wayland display server protocol as an alternative to X11. This driver improves integration with Wayland-based desktops, offering better security, smoother compositing, and reduced latency for graphics-intensive applications, though it remains experimental and may require configuration for full functionality.

Gaming Optimizations

Wine has progressively enhanced its support to better accommodate video games, beginning with the WineD3D component that translates 9 (D3D9) calls to for rendering. This approach, integral to Wine's graphics subsystem, enables compatibility for older games relying on D3D9 while leveraging the host system's drivers for performance. For more demanding titles, WineD3D's backend provides a foundational layer, though it can introduce overhead in complex scenes compared to native implementations. Advancing to newer APIs, Wine incorporates DXVK for Direct3D 10 and 11 (D3D10/11), which translates these calls directly to for superior efficiency and reduced latency in modern games. Similarly, VKD3D handles 12 (D3D12) by converting it to , allowing high-fidelity rendering in titles that utilize advanced features like variable rate shading. These -based layers, often enabled via environment variables in Wine configurations, significantly outperform the older translations for multi-threaded rendering pipelines common in contemporary gaming. To address synchronization bottlenecks in multi-threaded games, Wine introduced ESYNC in the 3.7 development release (2017), an eventfd-based mechanism that minimizes CPU wakeups by optimizing thread signaling. This reduces overhead in CPU-bound scenarios, such as those in open-world games with numerous AI entities, leading to smoother frame rates on multi-core processors. FSYNC, an evolution using futexes introduced in Wine 4.0 (2019), further refines this by providing even lower-latency synchronization, particularly beneficial for real-time inputs in competitive multiplayer titles. Both features integrate seamlessly with Wine's server process, enhancing overall responsiveness without requiring kernel modifications. A more recent advancement is ntsync, introduced in Wine development releases starting in 2024 and fully integrated by late 2025 in versions like 9.0 and 10.x. Ntsync leverages a dedicated driver to emulate synchronization primitives (events, semaphores, mutexes) more accurately and efficiently, approaching native Windows performance. This improves stability and responsiveness in multi-threaded games, serving as a successor to ESYNC and FSYNC for better compatibility with demanding titles. Wine benefits from upstream integration of battle-tested patches originating from Valve's Proton project, which are tailored for games and periodically merged into mainline Wine releases. These patches address game-specific quirks, such as DLL overrides and registry tweaks, improving stability for titles like those in the Source engine family. By adopting these refinements, Wine gains broader compatibility for 's vast library, ensuring that optimizations honed through extensive testing on distributions are available to all users. Mesa driver optimizations, such as enhanced acceleration structures in RADV and ANV as of 2024, have improved ray tracing support in VKD3D for Wine and Proton, enabling real-time ray tracing at playable resolutions in titles like without excessive VRAM overhead. On GPUs, VKD3D-Proton variants integrated into Wine 10.x deliver closer parity to native 12 ray tracing, particularly in path-traced scenes.

User Interface

Built-in Tools

Wine provides several native utilities integrated into its core distribution to facilitate setup, configuration, and troubleshooting of Windows applications running under the . These tools emulate key aspects of the Windows environment, allowing users to manage prefixes, dependencies, , and without relying on external software. They are invoked via command-line interfaces and often feature graphical components for ease of use on systems. The primary configuration tool is winecfg, a graphical editor that enables users to set up drive mappings, override DLL loading behaviors (such as native versus built-in), and emulate specific Windows versions like or older editions to improve application compatibility. Introduced in 2000 as part of Wine's early development efforts, winecfg also handles audio device selection, graphics driver configurations, and environment variables, making it essential for initial prefix customization and per-application tweaks. For managing dependencies, winetricks serves as a community-maintained script that automates the installation of non-free components, such as runtimes, Visual C++ redistributables, and fonts, which are often required for Windows software to function properly under Wine. Maintained since , it offers a menu-driven interface to download and integrate these elements into a Wine prefix, bypassing manual registry edits or complex scripting. Process management and debugging are handled by wineserver and winedbg, respectively. Wineserver acts as a central daemon , emulating Windows kernel services like process creation, thread synchronization, and to coordinate Wine's runtime environment. Complementing this, winedbg provides a capable of attaching to running processes, inspecting memory, setting breakpoints, and supporting both native Win32 executables and Winelib applications, with options for remote debugging via GDB integration. Registry and system settings are accessible through emulations of Windows utilities like regedit and the control panel. Regedit offers a tree-based interface for viewing, editing, importing, and exporting registry keys stored in the Wine prefix, mirroring the Editor to allow precise adjustments for application-specific configurations. Similarly, the control panel emulation provides graphical access to simulated Windows system applets for tasks like display settings, user accounts, and hardware management. wineconsole enhances support for terminal-based Windows applications by managing console input/output, character encoding, and cursor operations, ensuring better compatibility for command-line tools and legacy DOS-like programs within Wine environments.

External Interfaces

PlayOnLinux and PlayOnMac are graphical user interfaces (GUIs) designed to simplify the management and execution of Windows applications on and macOS, respectively, by leveraging Wine as the underlying . These tools, which have been available since 2007, allow users to create and manage multiple isolated Wine prefixes—virtual environments that encapsulate application-specific configurations, libraries, and dependencies—to prevent conflicts between different software installations. By providing a point-and-click interface for installing scripts, selecting Wine versions, and configuring options like or audio drivers, PlayOnLinux/PlayOnMac abstracts the complexities of command-line Wine usage, making it accessible for non-technical users to run games and productivity applications. Lutris serves as an open-source game launcher that integrates Wine runners to facilitate the installation and execution of Windows-based video games on systems. Launched in 2014, it acts as a centralized platform where users can import games from sources like , GOG, or , automatically applying community-curated Wine configurations, dependencies, and runner versions (such as Wine-GE or Proton) tailored for optimal performance. This integration extends to managing Wine prefixes per game, enabling seamless updates and troubleshooting through a unified , while supporting additional layers like DXVK for DirectX-to-Vulkan to enhance compatibility and frame rates in demanding titles. Bottles provides a sandboxed environment for running Windows software on distributions, utilizing isolated Wine instances to enhance and . Available in major package repositories and as a , it creates self-contained "bottles" that bundle Wine with preconfigured dependencies, runners, and environment variables, isolating applications from the host to mitigate risks like registry or file overwrites. This approach is particularly useful in distributions like or , where Bottles can be installed via native tools and used to deploy gaming or productivity setups without affecting global Wine configurations. Command-line wrappers such as Box86 enable Wine usage in hybrid x86/ARM architectures by emulating x86 binaries on ARM-based Linux devices, allowing Windows applications to run in resource-constrained environments like single-board computers. Box86 intercepts Wine's x86 library calls, translating them to native ARM instructions for improved efficiency over full emulation, and supports setups where a 32-bit x86 Wine prefix is paired with ARM host libraries for graphics and audio. This wrapper is invoked directly from the terminal, such as box86 wine program.exe, facilitating lightweight integration for scenarios like running legacy games on Raspberry Pi without requiring a full x86 system. Wine's integration with package managers like apt in streamlines its installation and maintenance, providing users with a straightforward method to deploy the system-wide. By adding the official WineHQ repository via sudo add-apt-repository and then executing sudo apt install winehq-stable, users obtain a verified build complete with 32-bit support, dependencies, and updates through standard apt update cycles, ensuring compatibility with 's ecosystem without manual compilation. This approach contrasts with direct downloads by leveraging 's auditing and dependency resolution for reliable, easy deployment across versions like or staging.

Functionality

Compatibility Layers

Wine employs several mechanisms to maintain compatibility with legacy and diverse Windows software, enabling seamless execution on systems through targeted overrides, databases, and emulations. A primary tool for addressing application-specific compatibility issues is Winetricks, an auxiliary script that automates the installation of Windows redistributables, fonts, and other components into a Wine prefix. It facilitates DLL overrides by allowing users to prioritize native Windows DLLs over Wine's built-in implementations, which is essential for applications relying on proprietary or incompletely emulated libraries. Additionally, Winetricks supports the configuration of shim databases—collections of compatibility shims that apply targeted fixes, such as registry tweaks or hooks, to resolve bugs in specific programs, mirroring Microsoft's Application Compatibility Toolkit approach. The Wine Application Database (AppDB), maintained by the WineHQ community, serves as a central repository for compatibility information, cataloging over 29,000 application versions with user-submitted test reports and ratings ranging from (flawless operation) to Trash (unrunnable). This database helps developers and users identify working configurations, common workarounds, and version-specific quirks, fostering iterative improvements in Wine's core. To support legacy software, Wine previously emulated the Windows 3.x environment for running 16-bit applications, leveraging thunking layers to translate 16-bit calls into 32-bit equivalents. This capability was limited on 64-bit hosts since around 2014 due to kernel changes; Wine 5.0 focused on 32-bit and 64-bit support. As of 2025, subsequent development releases like 10.16 have added limited 16-bit support in compatible modes. Wine incorporates built-in fixes for prevalent compatibility challenges, including adjustments for timing bugs—where applications expect precise event timing—handled via Wine's server-side event dispatching to synchronize with host system clocks. File path conversions are also natively managed, transparently mapping Windows-style paths (e.g., C:) to Unix equivalents while preserving case-insensitivity and drive letter semantics for application transparency. These core layers ensure broad without requiring external interventions for many scenarios. In 2025, Wine's development releases, such as version 10.0, added stubs and partial implementations for Windows 11-specific APIs, enhancing support for applications dependent on newer system interfaces like advanced task scheduling and components. As of November 2025, development release 10.19 includes further enhancements to and other features. As an extension, these layers enable 64-bit Wine prefixes to host 32-bit applications via emulation.

Architecture Support

Wine has supported 64-bit integer operations since the release of version 1.1.10 in December 2008, marking the initial implementation of preliminary 64-bit Windows application compatibility. This foundational support enabled basic handling of 64-bit data types and binaries, though full runtime execution remained limited until subsequent developments. Experimental support for running 32-bit apps on 64-bit Wine was introduced in later versions, with significant improvements starting in Wine 8.0 (2023), allowing 32-bit applications to run on 64-bit hosts through architecture-specific thunking layers. This mode bridges the gap between 32-bit and 64-bit environments, reducing dependency on separate installations and improving overall compatibility on systems. Support for ARM64 architectures began with experimental builds targeting Windows on ARM (WoA) around 2020, facilitated by community efforts and toolchain adaptations like those from Linaro. These early implementations focused on emulating ARM64 Windows binaries via cross-architecture translation, though performance was constrained by the need for additional emulation layers. Native aarch64 support arrived in Wine 9.0, released in January 2024, through the completion of PE (Portable Executable)/Unix binary separation, enabling direct execution of ARM64 Windows applications without x86 emulation overhead. Subsequent releases, including Wine 10.0 in 2025, extended this with full ARM64EC compatibility, allowing hybrid modules that mix ARM64 and x86 code for enhanced Windows app portability on ARM hardware. Wine supports cross-compilation for non-Linux Unix-like systems, including and Solaris, via official build configurations that adapt the core libraries to POSIX-compliant environments. On , Wine integrates through the ports collection, providing runtime support for Windows binaries with native kernel interactions. For Android, an official port known as Wine for Android, started in 2012, provides ARM and x86 builds for direct execution of Windows executables on mobile devices; as of 2025, builds up to 7.0 are available. Community adaptations include Termux-based installations using proot and Box64 for ARM64 emulation, enabling Wine deployment in Android's Linux subsystem without root access. Emulation for legacy mobile platforms includes partial support for Windows CE and RT through specialized stubs and compatibility layers. Wine provides basic Windows CE API implementations for cross-architecture scenarios, often via forks like Wine-CE, which extend the core to handle CE-specific binaries on ARM hosts. For and (UWP) apps, Wine incorporates runtime stubs for essential APIs, allowing limited execution of sideloaded .appx packages when paired with Winetricks for UWP framework installation. In 2025, experimental enhancements introduced initial support, with ongoing build fixes enabling compilation and basic runtime on RISC-V hardware, though full integration remains in development.

Application Integration

Winelib enables developers to compile Windows applications directly as native Unix binaries by providing a set of headers, libraries, and tools that map calls to Unix equivalents. This approach avoids the runtime translation layer used for running pre-compiled Windows executables, resulting in better performance and tighter integration with the host system. The toolkit includes implementations of key Win32 APIs, allowing applications to be built using standard Windows development tools like or , but targeted for Unix platforms such as or BSD. For instance, Winelib has been utilized in open-source projects seeking Windows compatibility, including , which incorporates Wine's user-mode DLL implementations derived from Winelib to share development efforts on Win32 API support. Since Wine 1.3.12 in 2011, experimental support for 16-bit MS-DOS applications has been integrated via an embedded DOSBox emulator, allowing legacy DOS programs to run within the Wine environment without requiring a separate DOSBox installation. This integration handles 16-bit real-mode execution by translating DOS interrupts and memory models to Unix equivalents, facilitating the preservation and execution of older software on modern Unix systems. The feature supports common DOS applications and games, though it remains experimental and may require configuration tweaks for optimal compatibility. Wine facilitates seamless interaction between Windows applications and the host Unix desktop through shared and drag-and-drop mechanisms. The synchronization uses the X11 selection protocol (or Wayland equivalents in newer versions) to exchange text, images, and files bidirectionally, enabling copy-paste operations across native and Wine-hosted applications. Similarly, drag-and-drop support leverages the host window manager's protocols to allow files and data to be dragged from Unix file managers into Wine windows or vice versa, enhancing usability for tasks like file transfers in . These features are enabled by default in most configurations and rely on Wine's windowing subsystem for protocol bridging. Audio output in Wine is bridged to Unix sound systems primarily through the ALSA driver, which serves as the core interface for low-level hardware access, and the driver added in Wine 1.8 for higher-level session management. The ALSA driver handles direct audio device interaction, supporting formats like PCM and , while integration allows for per-application volume control, network streaming, and automatic device switching on desktops using . This bridging ensures that Windows DirectSound and WaveOut calls are routed transparently to the host audio stack, minimizing latency for multimedia and gaming applications. Printing functionality in Wine routes Windows print jobs directly through the CUPS (Common Unix Printing System) backend, introduced as a replacement for the older lpr method in Wine 1.3.5. This integration exposes host printers to Windows applications via the WinSpool API, supporting features like selection, duplex printing, and /PCL rendering based on CUPS filters. Developers can configure printer descriptions and options through CUPS attributes, ensuring compatibility with a wide range of Unix printers without additional drivers. Wine handles Windows installers such as MSI (Microsoft Installer) packages through its built-in msiexec.exe implementation, which parses .msi files and executes installation scripts, database operations, and custom actions using Wine's and DLL support. This allows deployment of complex setups with registry modifications, file extraction, and component registration on Unix filesystems. For third-party formats like , Wine runs the Inno Setup compiler and runtime as standard Windows executables, supporting scripted installations with custom actions, compression, and uninstallers by emulating the necessary Setup calls. These capabilities ensure that many commercial and open-source Windows applications can be installed natively within Wine prefixes.

Microsoft Software Handling

Wine provides varying levels of compatibility for Microsoft Office applications, with built-in fixes enabling core functionality for tools like Microsoft Word and Excel. According to the Wine Application Database (AppDB), older versions of Microsoft Word (up to 2019) achieve a Gold rating for document editing, formatting, and printing with minimal issues in tested configurations, though advanced features such as certain VBA macros receive only partial support due to incomplete automation scripting implementation. Similarly, Microsoft Excel garners a Gold rating for spreadsheet operations and basic charting in Office 2016 (32-bit) and earlier, but complex pivot tables and some macro-enabled workbooks may encounter errors requiring user-configured overrides; newer versions like 365 often have lower ratings. The Office installer itself is rated Platinum across multiple older versions, facilitating seamless setup on Wine prefixes with standard dependencies like MSXML and GDI+. Support for the .NET Framework in Wine has evolved through bridging with Mono, an open-source implementation, since 2009, enabling execution of .NET-dependent Microsoft applications without native Windows runtime. Wine Mono, a customized distribution of Mono integrated into Wine since version 4.0, serves as a replacement for .NET Framework up to 4.8.1, handling common libraries like System.Windows.Forms for GUI apps. In 2022, Wine introduced experimental support for .NET Core via CoreCLR integration, allowing runtime loading of .NET 6 assemblies in select scenarios, though full cross-version compatibility remains limited to avoid conflicts with Mono's legacy bridging. This dual approach ensures that Microsoft software relying on .NET, such as Visual Studio tools, can operate with configurable runtime selection during installation. Internet Explorer emulation in Wine is facilitated by the wineie package, which installs legacy versions (up to IE8) into a Wine prefix to satisfy ActiveX-dependent web applications from . Wineie automates the download and configuration of IE components, enabling rendering of legacy and scripting for tools like older interfaces. For modern browsers, Wine introduced stubs for and Chromium-based rendering in 2024, providing partial WebView2 emulation to support embedded browser controls in applications without full implementation, thus avoiding the need for native Windows browser binaries. Handling proprietary features presents ongoing challenges, including partial ActiveX object linking via Wine's OLE implementation, which supports basic COM interfaces but struggles with custom controls in , often requiring manual registry tweaks. DRM mechanisms in applications like are circumvented through user-space patches, such as disabling protected content checks, though this can lead to playback failures for licensed media without additional libraries like Quartz. Telemetry collection in apps is mitigated by Wine's configuration options to block network endpoints or spoof identifiers, preventing during runtime. For code signing verification, Wine's fakecert utility generates mock certificates to bypass driver and executable validation, essential for installing signed components like updates. As of 2025, Wine's compatibility with applications has advanced, with version 10.0 enhancing support for Win11-specific APIs and UWP stubs, allowing basic execution of Store apps and system utilities.

Derivatives

Commercial Products

CrossOver, developed by , is a prominent commercial derivative of Wine that provides a user-friendly for running Windows applications on macOS and without requiring a Windows . Launched in 2001 shortly after the company's founding, CrossOver incorporates proprietary modifications to the core Wine architecture, including custom patches and automated installation scripts to enhance compatibility with productivity software such as and . These enhancements address common issues in the open-source Wine project, enabling seamless operation of certified applications through a curated compatibility database that lists thousands of tested programs. CodeWeavers operates on a subscription-based , offering annual renewals starting at $39.95 for basic access, with premium options like CrossOver+ at $74 per year that include ongoing updates and . A one-time lifetime license is available for approximately $494, providing perpetual access without renewal fees. As of 2025, CrossOver 25, released in March, builds on native support introduced in prior versions, integrating Wine 10.0 for improved ARM64 performance and stability on macOS devices. This update includes over 5,000 changes, focusing on better handling of suites and broader application support. Another commercial product is WINE@Etersoft, a adaptation of Wine tailored for the Russian market by Etersoft since 2006.) It emphasizes compatibility with key Russian enterprise applications, such as 1C:Enterprise, Consultant Plus, and Garant, while adding support for hardware security keys and integration with Linux-based Russian operating systems. Etersoft provides enterprise-level licensing and technical support, including customized deployments for organizations, through annual subscriptions and perpetual licenses available via their online store. This focus on localized software and regulatory compliance has made it a staple for businesses in seeking Windows application functionality on open-source platforms.

Gaming Adaptations

Proton is a free and open-source compatibility layer developed by , specifically designed to enable Windows-exclusive video games to run on and other operating systems through integration with the client. Built directly on top of Wine since its initial release on August 21, 2018, as part of the Steam Play feature, Proton incorporates Wine's core compatibility mechanisms while adding specialized libraries such as DXVK for Direct3D-to-Vulkan translation and VKD3D-Proton for 12 support, optimizing it for gaming workloads. A prominent community-driven variant is Proton-GE, maintained by developer GloriousEggroll under the repository GloriousEggroll/proton-ge-custom, which extends the official Proton with additional patches, bug fixes, and enhancements not yet merged into Valve's upstream version, such as improved anti-cheat compatibility and custom shader optimizations for specific titles. Released periodically since around 2019, Proton-GE is widely adopted by gamers for its broader game support, often serving as a selectable within Steam's compatibility tools menu. Through Steam Play, Proton seamlessly integrates into the Steam ecosystem, allowing users to enable compatibility for all titles with a single setting, thereby supporting over 15,000 Windows games rated as playable on based on community reports as of 2025. This integration has dramatically expanded Linux gaming accessibility, with Valve's handheld further popularizing Proton by verifying thousands of titles for optimal performance on the device. Proton Experimental represents Valve's rolling-release branch, providing early access to cutting-edge features like enhanced DirectX 12 translation to Vulkan via VKD3D-Proton, enabling support for modern titles that rely on advanced rendering APIs previously challenging on Linux. This layer frequently incorporates upstream Wine improvements and experimental drivers, such as NVIDIA NVAPI support enabled by default in later versions, to address performance bottlenecks in high-end gaming scenarios. Notable performance advancements include the Proton 9.0 series, released starting in May 2024 and updated through 2025, which introduced better multi-core CPU handling and graphics optimizations, alongside support for AMD FidelityFX Super Resolution 3 (FSR 3) frame generation in compatible games, yielding significant uplifts—up to 50% in some 12 titles—without requiring native ports. Complementing these efforts, ProtonDB serves as a community-driven database aggregating user-submitted compatibility reports for Steam titles, categorizing games by tiers from "Borked" to "Platinum" based on playability, performance, and tweaks required, with over 20,000 entries as of late 2025 to guide users in selecting optimal Proton versions.

Other Forks

Darwine was an early open-source project initiated in 2004 to port the Wine libraries to Darwin, the core operating system underlying macOS, enabling the execution of Windows applications on PowerPC and later Intel-based Macs. The effort focused on adapting Wine's compatibility layer to macOS's environment, including integration with Quartz for graphics rendering, but development ceased around 2012 due to challenges in maintaining compatibility with evolving macOS versions and limited community interest. In 2023, community-driven forks and wrappers revived interest in Wine-based solutions for Apple Silicon, such as Whisky, a SwiftUI-based graphical interface that leverages Wine to run Windows applications natively on M-series chips without full emulation, addressing the shift from Intel to ARM architecture. These modern adaptations build on Darwine's foundational concepts but incorporate Apple's Game Porting Toolkit for enhanced performance on ARM hardware. Wine has been adapted for Chrome OS through , the platform's container system, allowing users to install and run the compatibility layer within a Debian-based to execute Windows executables on Chromebooks. This integration, often facilitated by tools like , enables seamless access to Windows software alongside Chrome OS's web-centric features, though it requires enabling support and managing container permissions for optimal functionality. The approach leverages Crostini's lightweight to isolate Wine processes, providing a non-native but practical solution for legacy Windows app support on ARM and x86 Chrome hardware without modifying the core OS. ReactOS, an open-source operating system aiming for binary compatibility with , incorporates select code from Wine—particularly snippets from modules like NTDLL, USER32, and KERNEL32—to enhance its user-mode implementation and support for Windows applications. This reuse, initiated around 2010, helps bridge architectural gaps in ReactOS's design, which combines monolithic elements with modularity for driver compatibility, allowing Wine-derived components to facilitate hybrid NT kernel behaviors without full dependency on systems. The integration focuses on non-kernel elements to avoid licensing conflicts while improving application portability. Experimental forks like wine-vulkan extend Wine's graphics capabilities by prioritizing API support, enabling standalone (VR) applications through direct translation of calls to without intermediate layers. Developed as a personal staging branch, it targets high-performance rendering for VR environments, such as those using , by optimizing shader compilation and resource management for immersive, non-gaming VR experiences on and compatible systems. Wine-Staging serves as a key open-source that aggregates community-submitted patches for testing and refinement before upstream integration into the main Wine repository, fostering innovation in areas like synchronization primitives and file handling. Maintained collaboratively, it includes hundreds of experimental features—such as enhanced support and performance tweaks—that undergo rigorous review to ensure stability, with successful patches gradually merged into upstream releases to benefit the broader Wine ecosystem. This model encourages developer contributions while minimizing risks in the stable branch, often influencing architecture-specific motivations like better ARM compatibility.

Legacy Projects

Several discontinued projects based on Wine demonstrated early efforts to extend its to emerging platforms, though they ultimately faced challenges. The official Wine port for Android began development around 2012, with a public demonstration at the conference in early 2013 by project leader Alexandre Julliard, showcasing the ability to run Windows applications on Android devices. Pre-built packages became available from WineHQ starting with Wine 3.0 in , supporting both x86 and architectures to enable execution of Windows binaries on mobile hardware. Official support effectively ended in 2023 when WineHQ removed the Android build option from its primary downloads page, shifting maintenance to community-driven efforts such as custom compilations and third-party APKs. This transition reflected the difficulties in keeping pace with Android's rapid evolution, including changes to kernel page sizes and app sandboxing that complicated compatibility. Cedega, developed by TransGaming Technologies as a commercial fork of Wine optimized for running Windows games on , was discontinued in February 2011 after over a decade of operation. The company announced the retirement of Cedega's subscription-based gaming service, citing a pivot to broader developer tools under the GameTree Linux initiative, though that project also ceased significant updates by 2012. Some enhancements from Cedega, particularly in rendering and game-specific patches, were upstreamed to the mainline Wine project through LGPL-compatible contributions, benefiting subsequent Wine releases. WineBottler, a macOS-specific tool that bundled Wine to create standalone Mac applications from Windows executables, ended active development in 2019 amid Apple's transition to . This update eliminated support for 32-bit applications, a foundational element of Wine's at the time, rendering many bundled apps incompatible without extensive rewriting. The project's last stable release predated these changes, and no further updates addressed the 64-bit-only requirement, leading to its discontinuation. These projects were discontinued primarily due to escalating maintenance costs for specialized forks and wrappers, as well as platform shifts like Apple's of legacy binary support and Android's increasing restrictions on non-native execution environments. Despite their endings, their code and innovations—such as mobile adaptations and techniques—were partially integrated into core Wine, providing lasting improvements to cross-platform compatibility.

Reception

Security Analysis

Wine operates as a compatibility layer rather than a full virtual machine, which means Windows applications executed through it can potentially access the host system's resources at the user's privilege level, introducing security risks if the application or Wine itself contains exploitable flaws. Unlike isolated environments such as virtual machines, Wine does not provide built-in sandboxing to contain malicious behavior from Windows binaries, allowing applications to interact directly with the host file system, network, and processes unless external measures are applied. To mitigate these risks, users can integrate Wine with systems like or SELinux, which enforce policies to restrict Wine processes to specific directories and capabilities, preventing unauthorized access to sensitive host resources. For example, profiles can confine Wine to its prefix directory, limiting file writes and executions outside that scope. Similarly, SELinux policies can deny heap execution attempts by Wine's preloader, addressing potential vectors. These external integrations are essential, as Wine itself lacks native confinement mechanisms. Historically, Wine has faced vulnerabilities, including in its implementation of Win32 APIs. A notable example is CVE-2018-12932, a heap-based in the enhanced metafile (EMF) handling code within enhmetafile.c, which could lead to denial of service or when processing malformed files. Another instance, CVE-2018-12933, involved an out-of-bounds write in the same component, similarly exploitable for crashes or code execution. Earlier issues, such as CVE-2009-0237 and CVE-2009-0238, demonstrated in Wine's Spoolss and MSVCRT components, potentially allowing . These flaws have been addressed in subsequent releases, with the project maintaining a track record of patching reported issues through its development cycle, though no quarterly patching schedule is formally defined. No major vulnerabilities have been publicly disclosed in recent years (2023–2025), reflecting ongoing community scrutiny of the open-source codebase. Wine contains no inherent backdoors, as its is fully open and auditable by the community, but significant risks arise from executing untrusted Windows binaries, which could harbor capable of exploiting host resources or Wine's emulations. For instance, or other malicious executables may run under Wine and attempt to encrypt files or exfiltrate data from the user's , bypassing Linux-native protections if not sandboxed. Auditing efforts benefit from Wine's open-source status, enabling developers and security researchers to review and test the for flaws, with historical vulnerabilities identified through code analysis and exploit attempts. While not integrated with automated services like OSS-Fuzz, community-driven testing, including manual reviews and bug bounties via WineHQ, has contributed to identifying and fixing issues like the aforementioned buffer overflows. Recommended best practices for secure Wine usage include creating isolated prefixes for individual applications using WINEPREFIX, which confines each environment to a separate directory, limiting potential cross-contamination or damage from a compromised app. Additionally, employing read-only DLL overrides for native Windows libraries reduces the by preventing modifications to critical components, and running Wine under external sandboxes like Firejail further isolates processes from the host. Users should avoid executing untrusted binaries, apply the principle of least privilege by running Wine as a non-root user, and keep the software updated to incorporate security fixes. For high-risk scenarios, such as testing applications, virtual machines are preferable over Wine to ensure complete isolation.

Performance Evaluations

A 2018 Phoronix benchmark showed Wine achieving near-native performance for various desktop applications on hardware of that era. In gaming scenarios, particularly with Vulkan backend support via DXVK, Wine delivers performance ranging from 70% to 120% of native speeds depending on the title and driver optimizations, often matching or exceeding Windows in Vulkan-enabled games due to lower overhead in certain rendering pipelines. The primary sources of performance overhead in Wine stem from the runtime translation of calls to equivalents, introducing latency during initial execution; however, this is significantly mitigated by improved caching mechanisms introduced in versions from 2020 onward, such as enhanced PE module loading and shader pre-caching, which reduce repeated translations by up to 50% in subsequent runs. Key factors influencing Wine's efficiency include elevated CPU utilization during API marshaling—typically 10-20% higher than native—and GPU load variations based on to translation. A notable drawback is the increased for 32-bit applications running on 64-bit hosts under emulation mode due to limitations and thunking layers, potentially leading to higher swapping on memory-constrained systems.

Industry Perspectives

has maintained a neutral to cautiously supportive stance toward Wine since its inception in the , refraining from legal action against the project despite its reimplementation of Windows APIs. In , the company acknowledged efforts to limit Wine compatibility through software updates, but no formal endorsement or endorsement has followed. More recently, in 2024, donated the Mono project—a .NET —to WineHQ, signaling a shift toward on open-source compatibility efforts without direct validation of Wine itself. The open-source community has praised Wine for advancing interoperability, with recognition including SourceForge's Excellence badge for its sustained development and user adoption. However, critics within the community highlight its growing complexity as a barrier to maintenance and broader contribution. In enterprise settings, Wine facilitates the migration of legacy Windows applications to systems, reducing costs associated with or full rewrites, as demonstrated in case studies from compatibility providers. has explicitly endorsed and built upon Wine through Proton, a gaming-focused integrated into , which relies on Wine's core for running Windows titles on and contributes enhancements back to the upstream project. Debates surrounding Wine often center on the ethics of , with the project adhering strictly to and clean-room methods to avoid proprietary code, ensuring legal compliance while enabling compatibility. This approach mitigates concerns over but raises questions about the balance between innovation and in software reimplementation. The European Union's (DMA), effective from 2023 and under ongoing review in 2025, promotes software to foster competition, indirectly supporting tools like Wine that enable cross-platform application execution without . While not specifically addressing Wine, the DMA's mandates on access align with its role in reducing barriers to Unix-native alternatives, though native development remains preferable for optimal performance in many cases.

References

  1. https://www.winehq.org/about
  2. https://www.winehq.org/news/2025012101
  3. https://www.winehq.org/about/
  4. https://www.linuxjournal.com/magazine/wine
  5. https://www.codeweavers.com/about/people/julliard
  6. https://dwheeler.com/essays/gpl-compatible.html
  7. https://www.winehq.org/news/2008061701
  8. https://www.winehq.org/announce/2.0
  9. https://www.winehq.org/news/2017012401
  10. https://gitlab.winehq.org/wine/wine/-/releases/wine-9.0
  11. https://www.phoronix.com/news/Wine-10.0-Released
  12. https://gitlab.winehq.org/wine/wine-staging
  13. https://www.winehq.org/news/
  14. https://www.codeweavers.com/about
  15. https://www.codeweavers.com/wine
  16. https://www.winehq.org/donate
  17. https://www.winehq.org/interview/6
  18. https://www.phoronix.com/news/UMIP-Intel-Wine
  19. https://summerofcode.withgoogle.com/archive/2020/organizations/6331124088832000/
  20. https://www.phoronix.com/news/Valve-Upstream-Everything-OSS
  21. https://se-radio.net/2025/09/se-radio-687-elizabeth-figura-on-proton-and-wine/
  22. https://www.codeweavers.com/crossover
  23. https://gitlab.winehq.org/wine/wine/-/blob/master/README.md
  24. https://www.winehq.org/announce/9.0
  25. https://forum.winehq.org/viewtopic.php?t=33901
  26. https://wiki.winehq.org/Wine_Architecture
  27. https://www.winehq.org/announce/6.15
  28. https://www.winehq.org/announce/6.5
  29. https://www.winehq.org/announce/1.4
  30. https://www.winehq.org/announce/4.0
  31. https://www.winehq.org/announce/5.0
  32. https://www.winehq.org/announce/1.8
  33. https://www.winehq.org/announce/3.0
  34. https://wiki.winehq.org/DirectX
  35. https://github.com/doitsujin/dxvk
  36. https://wiki.winehq.org/ESYNC
  37. https://wiki.winehq.org/Ntsync
  38. https://www.codeweavers.com/blog/aeikum/2019/1/3/working-on-wine-part-1-the-wine-ecosystem
  39. https://www.phoronix.com/news/Mesa-2024-Highlights
  40. https://gitlab.winehq.org/wine/wine/-/wikis/Commands/winecfg
  41. https://github.com/Winetricks/winetricks
  42. https://gitlab.winehq.org/wine/wine/-/wikis/Man-Pages/wineserver
  43. https://gitlab.winehq.org/wine/wine/-/wikis/Commands/winedbg
  44. https://www.playonlinux.com/
  45. https://www.playonmac.com/
  46. https://www.playonlinux.com/en/download.html
  47. https://wiki.playonlinux.com/index.php/Main_Page
  48. https://lutris.net/about
  49. https://lutris.net/downloads
  50. https://usebottles.com/
  51. https://flathub.org/apps/details/com.usebottles.bottles
  52. https://docs.usebottles.com/getting-started/environments
  53. https://github.com/ptitSeb/box86
  54. https://ptitseb.github.io/box86/X86WINE.html
  55. https://github.com/ptitSeb/box86/blob/master/docs/X86WINE.md
  56. https://wiki.winehq.org/Ubuntu
  57. https://dl.winehq.org/wine-builds/winehq.key
  58. https://gitlab.winehq.org/wine/wine/-/wikis/Debian-Ubuntu
  59. https://appdb.winehq.org/appdbStats.php
  60. https://www.linaro.org/blog/native-support-for-windows-on-arm-has-arrived/
  61. https://gitlab.winehq.org/wine/wine/-/releases/wine-10.0
  62. https://www.winehq.org/
  63. https://docs.freebsd.org/en/books/handbook/wine/
  64. https://dl.winehq.org/wine-builds/android/
  65. https://github.com/ar37-rs/xow64-wine
  66. https://gitlab.com/wine-ce/wine-ce
  67. https://github.com/Winetricks/winetricks/issues/2225
  68. https://bugs.winehq.org/show_bug.cgi?id=56642
  69. https://gitlab.winehq.org/wine/wine/-/wikis/Winelib-User%27s-Guide
  70. https://www.phoronix.com/news/Wine-Wayland-2024-Plans
  71. https://forum.winehq.org/viewtopic.php?t=35462
  72. https://www.winehq.org/announce/1.3.5
  73. https://gitlab.winehq.org/wine/wine/-/wikis/Commands/msiexec
  74. https://appdb.winehq.org/objectManager.php?sClass=application&iId=1301
  75. https://appdb.winehq.org/objectManager.php?sClass=application&iId=10
  76. https://appdb.winehq.org/objectManager.php?sClass=application&iId=11
  77. https://appdb.winehq.org/objectManager.php?iId=31&sClass=application
  78. https://github.com/wine-mono/wine-mono
  79. https://betanews.com/2025/01/21/wine-10-linux-windows-apps/
  80. https://www.codeweavers.com/about/news/press/20020807
  81. https://www.codeweavers.com/store
  82. https://www.codeweavers.com/blog/balfour/2025/10/9/dont-panic-how-crossover-licenses-work
  83. https://www.codeweavers.com/blog/mjohnson/2025/3/11/experience-next-level-gaming-on-mac-with-crossover-25
  84. https://9to5mac.com/2025/03/11/crossover-25-red-dead-redemption-2-macos/
  85. https://tadviser.com/index.php/Product:WINE%40Etersoft
  86. https://etersoft.ru/about/news/437-wine-etersoft-changes
  87. https://github.com/ValveSoftware/Proton
  88. https://www.gamingonlinux.com/2025/08/7-years-later-valves-proton-has-been-an-incredible-game-changer-for-linux/
  89. https://github.com/GloriousEggroll/proton-ge-custom
  90. https://www.tomshardware.com/software/linux/nearly-90-percent-of-windows-games-now-run-on-linux-latest-data-shows-as-windows-10-dies-gaming-on-linux-is-more-viable-than-ever
  91. https://www.tomshardware.com/software/linux/valve-releases-proton-90-for-linux-improves-nvidia-graphics-and-high-core-count-cpu-compatibility
  92. https://www.gamingonlinux.com/2025/03/competitive-fps-fragpunk-has-launched-on-steam-and-works-on-linux-steam-deck/
  93. https://www.protondb.com/
  94. https://www.macworld.com/article/169622/darwine.html
  95. https://forum.winehq.org/viewtopic.php?t=9947
  96. https://github.com/Whisky-App/Whisky
  97. https://news.ycombinator.com/item?id=38421862
  98. https://chromeunboxed.com/i-installed-playonlinux-on-my-chromebook-so-you-dont-have-to/
  99. https://forum.winehq.org/viewtopic.php?t=38676
  100. https://www.chromium.org/chromium-os/developer-library/guides/containers/containers-and-vms/
  101. https://www.phoronix.com/news/Nzg4OQ
  102. https://neosmart.net/blog/reactos-the-next-windows/
  103. https://github.com/roderickc/wine-vulkan
  104. https://www.khronos.org/assets/uploads/developers/library/2019-cedec/Khronos-CEDEC_Sep19.pdf
  105. https://www.phoronix.com/news/Wine-Staging-10.1-Released
  106. https://github.com/wine-compholio/wine-staging
  107. https://www.neowin.net/news/wine-demoed-on-android-runs-windows-apps/
  108. https://www.codeweavers.com/blog/duboisj/2018/2/27/wine-on-android-a-saturday-afternoon-diversion
  109. https://forum.winehq.org/viewtopic.php?t=37532
  110. https://www.phoronix.com/news/ODk5NA
  111. https://www.phoronix.com/news/MTE3OTI
  112. https://forum.winehq.org/viewtopic.php?t=32590
  113. https://wiki.winehq.org/Security
  114. https://bugs.winehq.org/show_bug.cgi?id=56650
  115. https://www.cvedetails.com/product/47290/Winehq-Wine.html?vendor_id=18623
  116. https://unix.stackexchange.com/questions/231365/wine-and-linux-security
  117. https://www.phoronix.com/review/wine-ubuntu1804-win10
  118. https://www.phoronix.com/news/Wine-10.5-Released
  119. https://www.phoronix.com/news/Wine-10.7-Released
  120. https://www.phoronix.com/news/Wine-10.8-Released
  121. https://forum.winehq.org/viewtopic.php?t=4883
  122. https://news.ycombinator.com/item?id=41372411
  123. https://www.zdnet.com/article/microsoft-admits-targeting-wine-users/
  124. https://news.itsfoss.com/microsoft-donates-mono-project/
  125. https://sourceforge.net/projects/wine/
  126. https://media.codeweavers.com/pub/crossover/case_studies/WinLegacySupport.pdf
  127. https://www.osnews.com/story/30664/valve-forks-wine-to-proton/
  128. https://forum.winehq.org/viewtopic.php?t=7138&start=25
  129. https://onlineethics.org/cases/ethics-and-reverse-engineering
  130. https://digital-markets-act.ec.europa.eu/questions-and-answers/interoperability_en
  131. https://itif.org/publications/2025/02/11/the-eu-interoperability-regulation/
Add your contribution
Related Hubs
User Avatar
No comments yet.