Wine (recursive acronym for Wine Is Not an Emulator) is a free and open-source compatibility layer that aims to allow computer programs (application software and computer games) developed for Microsoft Windows to run on Unix-like operating systems. Wine also provides a software library, known as Winelib, against which developers can compile Windows applications to help port them to Unix-like systems.
|Original author(s)||Alexandre Julliard|
|Initial release||4 July 1993|
2.0.1 / April 20, 2017
2.10 / June 9, 2017
|Platform||IA-32, i686, x86-64|
|Size||18.0 MB (compressed tar.xz)|
|License||GNU LGPL v2.1+|
It emulates the Windows runtime environment by translating Windows system calls into POSIX-compliant system calls, recreating the directory structure of Windows systems, and providing alternative implementations of Windows system libraries, system services through
wineserver and various other components (such as Internet Explorer, the Windows Registry Editor, and msiexec). Wine is predominantly written using black-box testing reverse-engineering, to avoid copyright issues.
The name Wine initially was an abbreviation for Windows Emulator. The phrase "Wine Is Not an Emulator" is a reference to the fact that no code emulation or virtualization occurs when running a Windows application under Wine. "Emulation" usually refers to the execution of compiled code intended for one processor (such as x86) by interpreting/recompiling software running on a different processor (such as PowerPC). Its meaning later shifted to the recursive acronym Wine Is Not an Emulator in order to differentiate the software from CPU emulators. While the name sometimes appears in the forms WINE and wine, the project developers have agreed to standardize on the form Wine.
In a 2007 survey by desktoplinux.com of 38,500 Linux desktop users, 31.5% of respondents reported using Wine to run Windows applications. This plurality was larger than all x86 virtualization programs combined, as well as larger than the 27.9% who reported not running Windows applications.
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, the Wabi for the Solaris operating system, and the Public Windows Initiative, 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. Wine originally targeted 16-bit applications for Windows 3.x, but as of 2010[update] 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. 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 publicly available specification from Microsoft, it 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. Consequently, the Wine team has reverse-engineered many function calls and file formats in such areas as thunking.
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, work as of March 2002 has used the LGPL for its licensing.
Wine officially entered beta with version 0.9 on 25 October 2005. Version 1.0 was released on 17 June 2008, after 15 years of development. Version 1.2 was released on 16 July 2010, version 1.4 on 7 March 2012, version 1.6 on 18 July 2013. and version 1.8 on 19 December 2015. Development versions are released roughly every two weeks.
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 WineHQ version, as well as some additional proprietary components.
The involvement of 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.
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. Wine is also a regular beneficiary of Google's Summer of Code program.
As the Template:Microsoft APIs convincingly shows, there are a lot of APIs from Microsoft. The goal of Wine is to implement those APIs fully or partially that are required by programs that the users of Wine wish to run on top of a Unix-like system.
The Win32 function calls (over 10,000 library calls) are collectively called the Win32 API.
DirectX is a collection of APIs for rendering, audio and input. While most office software does not make use of these, computer games do. As of 2017, Wine contains a DirectX 9.0c implementation.
Many games which use a Direct3D 9 rendering path can run on top of Wine.
The Gallium3D driver model creates a module called Gallium3D State Tracker. A free and open-source Gallium3D State Tracker was written for Microsoft Direct3D 9 in C (and another one for Direct3D 10 written in C++ which has not been maintained). After some modification to Wine, it is now possible to use Direct3D 9 games without the requirement to translate Direct3D calls into OpenGL calls, thus gaining a huge performance boost.
Direct3D versions newer than 9c are not well supported by Wine.
Microsoft Windows family of operating systemsEdit
The concept underlying the Windows API is exactly contrary to the one underlying the concept of the Linux API. The functions comprising the Linux API are simple, with few parameters and few places where there are multiple ways to perform the same operation. Win32 provides very comprehensive interfaces with many parameters, often with three or four ways of doing the same thing, without the programmer actually knowing the costs, as documentation of the involved system calls is not available outside Microsoft. Additionally Win32 mixes low-level and high-level functions together.
The programming interfaces of the Microsoft Windows family of OSes consist 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). Only programmers at Microsoft write to the system-call layer, as documentation is not publicly available. The published user-mode interfaces all belong to operating system personalities that are implemented using subsystems that run on top of the NTOS layers. As a result, a programmer never knows the cost of sub-routine. But Windows also includes a number of programming interfaces which are implemented as services that run as separate processes. Applications communicate with user-mode services through RPCs.
Unlike Linux, Windows is case insensitive, meaning it does not generally distinguish between upper- and lowercase.
Wine implements the Windows application binary interface (ABI) entirely in user space, rather than as a kernel module. Services normally provided by the kernel in Windows are 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 Wine implements some aspects of the Windows kernel, it is not possible to use native Windows drivers with it, due to Wine's underlying architecture. This prevents certain applications and games from working, for example those using StarForce copy-protection which requires virtual device drivers to be installed.
Wine is primarily developed for Linux, but the macOS, FreeBSD, and Solaris (SPARC was dropped in 1.5.26) ports are currently (as of August 2013[update]) well maintained, although a packaged file for Mac isn't available. Wine is also available for NetBSD and a number of other systems via pkgsrc. Since October 2010, Wine also works on the ARM platform when used as Winelib (which lets developers compile Windows code on Linux using Wine as a library). Some versions of Wine's DLLs are available for Microsoft Windows, but Wine does not fully compile or run on Windows yet.
Wine is usually invoked from the command-line interpreter:
wine [program.exe]. Additionally there is the utility
winecfg that starts a graphical user interface with controls for adjusting basic options.
The developers of the Direct3D portions of Wine have continued to implement new features such as pixel shaders to increase game support. 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.
winecfg 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). Wine also includes its own open-source implementations of several other Windows programs, such as notepad, wordpad, control, iexplore, and explorer.
The Wine Application Database (AppDB) is a community-maintained on-line database about which Windows programs works with Wine and how well they work.
Wine ensures good backward compatibility with legacy Windows applications, including those written for Windows 3.1x. Wine can mimic different Windows versions required for some programs, going as far back as Windows version 2.0. 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 (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 won't run most Windows 2.0 programs because MS-DOS and Windows functions are not currently integrated.
Backward compatibility in Wine is superior to that of Windows, as newer versions of Windows can force users to upgrade legacy Windows applications. In many cases, Wine can offer better legacy support than newer versions of Windows with "Compatibility Mode". Wine can run 16-bit Windows programs on a 64-bit operating system, which uses an x86-64 (64-bit) CPU. 64-bit versions of Microsoft Windows cannot run 16-bit Windows programs.
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). When using the raw streams or curses backends, Windows applications will run in a Unix terminal.
Preliminary support for 64-bit Windows applications was added to Wine 1.1.10, in December 2008. This requires at least gcc version 4.4, and the Wine developers expect that it will take significant time before support stabilizes. However, as almost all Windows applications are currently[update] available in 32-bit versions, and the 32-bit version of Wine can run on 64-bit platforms, this is seen as a non-issue.
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 ABI. 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 don't work out of the box within Wine itself. The Wine wiki maintains a page of current and obsolete third-party applications.
- Winetricks is a script to install some basic components (typically Microsoft DLLs and fonts) required for some applications to run correctly under Wine. The Wine project will accept bug reports for users of Winetricks, unlike most third-party applications. It is maintained by Wine developer Austin English.
- 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.
- IEs4Linux is a utility to install all versions of Internet Explorer, including versions 4 to 6 and version 7 (in beta).
- Wineskin is a utility to manage Wine engine versions and create wrappers for macOS.
- PlayOnLinux is an application to ease the installation of Windows applications (primarily games). There is also a corresponding Macintosh version called PlayOnMac.
- 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, and macOS computers.
Wine will not run Windows CE programs. There is an ongoing project to port Wine to ARM processors, which may in the future be used as a base for a WineCE running Windows CE programs. However, there is a pre-alpha proof-of-concept version of Wine that can run Windows CE programs called WineCE.
Early versions of Microsoft Windows run on top of MS-DOS and Windows programs may depend on MS-DOS programs being runnable. 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. However, due to a bug, current versions of Wine incorrectly identify Windows 1.x and Windows 2.x programs as MS-DOS programs, attempting to run them in DOSBox (which does not work).
Compatibility for Internet ExplorerEdit
Internet Explorer can be installed directly on Wine. However, it is not recommended to do so, since (there is an alternative with Wine and) at least in the past it crashed or does not work well on recent versions of Wine which had poor support for Internet Explorer.
Internet Explorer 5 can be installed on Wine 1.3.9 but crashes frequently. Internet Explorer 5.5 is buggy on Wine 1.3.6, and Internet Explorer 6 refuses to install on Wine 1.6-rc5. Internet Explorer 7 32-bit version does not work very well on 1.5.11, and the 64-bit version does not load web pages on 1.6-rc5. Internet Explorer 8 also crashes constantly on Wine 1.6. Internet Explorer 9 (both 32-bit and 64-bit) and 10 cannot be installed.
Other versions of WineEdit
The core Wine development aims at a correct implementation of the Windows ABI as a whole and has sometimes lagged in some areas of compatibility with certain applications. Direct3D, for example, remained unimplemented until 1998, although newer releases have had an increasingly complete implementation.
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.
CrossOver now 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.
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.
Cedega / WineXEdit
TransGaming Technologies 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 Technologies announced continued development of Cedega Technology under the GameTree Developer Program. TransGaming Technologies allowed members to keep using their Cedega ID and password until 28 February 2011.
TransGaming has 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.
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). For 2010[update], Etersoft was going to issue WINE@Etersoft CAD, which is oriented towards CAD systems such as AutoCAD, BricsCAD, and Compass-3D.
Darwine is a port of the Wine libraries to Darwin and to macOS for both the PowerPC and Intel x86 architectures. All patches for x86 version were merged back into the main branch of Wine in 2009. Development on the PPC version was abandoned. Mike Kronenberg previously created the WineHelper for Darwine to add a GUI and macOS style app for interacting with Wine, which was later replaced by Winebottler. Darwine now provides macOS compatible packages compiled from the Wine repository.
Wine for AndroidEdit
The Pipelight Team has produced a custom version of Wine that acts as a wrapper for Windows NPAPI plugins within Linux browsers. This tool permits Linux users to run Microsoft Silverlight, the Windows version 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, some of which occasionally get approved and added to upstream Wine.
Other projects using Wine source codeEdit
Other projects using Wine source code include:
- 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, but because of architectural differences, ReactOS code (such as dlls written specifically for it, like ntdll, user32, kernel32, gdi32, and advapi) is not generally reused in Wine. In July 2009, Aleksey Bragin, the ReactOS project lead, started a new ReactOS branch called Arwinss, and it was officially announced in January 2010. Arwinss is an alternative implementation of the core Win32 components, and uses mostly unchanged versions of Wine's user32.dll and gdi32.dll.
- Winebottler, a wrapper around Wine in the form of a normal Mac Application. 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.
- 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.
- E/OS, 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.
- Parallels Desktop for Mac, a proprietary product that uses some Wine code for its DirectX handling.
- VirtualBox, a virtual machine that uses some Wine code for its Direct3D handling.
- WinOnX, a commercial package of Wine for macOS that includes a GUI for adding and managing applications and virtual machines.
The Wine project has received a number of technical and philosophical complaints and concerns over the years.
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. Wine can run most malware, but programs running in Wine are confined to the current user's privileges, restricting some undesirable consequences. For this reason the developers of Wine recommend never running it as the superuser. Malware research software such as ZeroWine runs Wine on Linux in a virtual machine, to keep the malware completely isolated from the host system.
Another security concern is when the implemented specifications are ill-designed and allow for security compromise. Because Wine implements these specs, it will also implement any security vulnerabilities they contain.
Wine vs. native Unix applicationsEdit
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. 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.
The Wine project itself responds to these complaints 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.
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.
Microsoft has not made public statements about Wine. However, the Microsoft Update software will block updates to Microsoft applications running in Wine. On 16 February 2005, Ivan Leo Puoti discovered that Microsoft had started checking the Windows Registry for the Wine configuration key and would block the Windows Update for any component. As Puoti noted, "It's also the first time Microsoft acknowledges the existence of Wine."
- Search Results · GitHub
- Search Results · GitHub
- Search Results · GitHub
- Search Results · GitHub
- "Licensing - WineHQ Wiki". WineHQ. Archived from the original on 2017-01-10. Retrieved 2017-01-10.
- "LICENSE". WineHQ. Retrieved 2017-01-10.
- "Winelib". Wine HQ. Retrieved 29 June 2008.
- "WineHQ - About Wine". WineHQ. Retrieved 2017-04-15.
- "Wine architecture". Wine HQ. Retrieved 16 June 2012.
- "Wineserver - WineHQ Wiki". wiki.winehq.org. Retrieved 2017-04-15.
- "Regedit - WineHQ Wiki". wiki.winehq.org. Retrieved 2017-04-15.
- "Msiexec - WineHQ Wiki". wiki.winehq.org. Retrieved 2017-04-15.
- Mckenzie, James (26 December 2009). "Legal Issues". WineHQ Forums.
- WINE FAQ Old meaning of the name even used until 1997
- Wine Is Not an Emulator First proposal to change the meaning of the name WINE
- "Why do some people write WINE and not Wine?". Wine Wiki FAQ. Official Wine Wiki. 7 July 2008. Retrieved 13 July 2008.
- "2007 Desktop Linux Market survey". 21 August 2007. Archived from the original on 24 May 2012. Retrieved 8 October 2007.
- Vaughan-Nichols, Steven J. (22 August 2007). "Running Windows applications on Linux". 2007 Desktop Linux Survey results. DesktopLinux. Archived from the original on 11 February 2010.
- Amstadt, Bob (29 September 1993). "Wine project status". Newsgroup: comp.windows.x.i386unix. Retrieved 13 July 2008.
- "Sun Uses ECMA as Path to ISO Java Standardization". Computergram International. 7 May 1999. Archived from the original on 8 July 2012. Retrieved 13 July 2008.
- Byron A Jeff (25 August 1993). "WABI available on Linux or not". Newsgroup: comp.os.linux.misc. Retrieved 21 September 2007.
- Loli-Queru, Eugenia (29 October 2001). "Interview with WINE's Alexandre Julliard". OSnews (Interview). Retrieved 30 June 2008.
Usually we start from whatever documentation is available, implement a first version of the function, and then as we find problems with applications that call this function we fix the behavior until it is what the application expects, which is usually quite far from what the documentation states.
- White, Jeremy (6 February 2002). "Wine license change". Retrieved 27 April 2010.
- Alexandre Julliard (18 February 2002). "License change vote results". Retrieved 27 April 2010.
- "Beta!". 25 October 2005. Retrieved 9 December 2010.
- "Announcement of version 1.0". Wine HQ. 17 June 2008. Retrieved 1 September 2008.
- Julliard, Alexandre (16 July 2010). "Release News".
- "Wine Announcement". Retrieved 7 March 2012.
- "Wine 1.6 Released". WineHQ. 18 July 2013. Retrieved 18 July 2013.
- "Wine 1.8 Released". WineHQ. 19 December 2015. Retrieved 19 December 2015.
- White, Jeremy (27 January 2011). "Announcing CrossOver 10.0 and CrossOver Games 10.0, The Impersonator". CodeWeavers. Retrieved 28 January 2011.
- Vaughan-Nichols, Steven J. (25 February 2002). "That's All Folks: Corel Leaves Open Source Behind". Linux.com. Retrieved 3 January 2009.
- Kegel, Dan (14 February 2008). "Google's support for Wine in 2007". wine-devel (Mailing list). Retrieved 3 January 2009.
- "Open Source Patches: Wine". Google. Retrieved 7 September 2008.
- Archived Wine FAQ from 2017
- Christoph Bumiller. "Direct3D 9 Gallium3D State Tracker".
there are a couple of differences to d3d1x: [...] it's written in C instead of C++ and not relying on horrific multiple inheritance with [...] So far I've tried Skyrim, Civilization 5, Anno 1404 and StarCraft 2 on the nvc0 and r600g drivers, which work pretty well, at up to x2 the fps I get with wined3d (NOTE: no thorough benchmarking done yet).
- "With Wine Git, You Can Run The D3D11 Blizzard Overwatch Game On Linux". Phoronix. 2016-12-12.
- See the "Windows service" article
- How To Run Windows Software on Mac OS X. Top Net Tools. Retrieved on 31 July 2013.
- "Under what hardware platform(s) and operating system(s) will Wine(Lib) run?". Wine FAQ. Archived from the original on 19 December 2008. Retrieved 3 January 2009.
- "The Wine development release 1.3.4 announcement". Winehq.org. Retrieved 15 October 2010.
- "Wine Win32 Packages". Sourceforge.net. Retrieved 17 October 2010.
- "The Official Wine Wiki: Wine on Windows". Wiki.winehq.org. Retrieved 27 April 2010.
- "WINE". WineHQ. Retrieved 2017-04-29.
- Nick Congleton (2016-10-26). "Configuring WINE with Winecfg". LinuxConfig. Retrieved 2017-04-29.
- "DirectX-Shaders". Official Wine Wiki. Retrieved 3 January 2009.
- "List of Commands". WineHQ. 2016-04-12. Retrieved 2017-04-29.
- "Windows Legacy Application Support Under Wine" (PDF). Retrieved 9 December 2010.
- Strohmeyer, Robert (6 April 2007). "Still need to run Windows apps? Have a glass of wine". Retrieved 9 December 2010.
- "64-bit versions of Windows do not support 16-bit components, 16-bit processes, or 16-bit applications". Retrieved 22 August 2015.
- Savill, John (11 February 2002). "Why can't I install 16-bit programs on a computer running the 64-bit version of Windows XP?". Retrieved 9 December 2010.
- "Text mode programs (CUI: Console User Interface)". Wine User Guide. Retrieved 22 May 2010.
- Lankhorst, Maarten (5 December 2008). "Wine64 hello world app runs!". wine-devel (Mailing list). Retrieved 15 December 2008.
- "Wine64 for packagers". Official Wine Wiki. Retrieved 20 April 2010.
- "Third Party Applications". Official Wine Wiki. Retrieved 3 January 2009.
- "winetricks". Official Wine Wiki. Retrieved 3 January 2009.
- "Wine doors". Wine doors. Retrieved 27 April 2010.
- "IEs4Linux". Tatanka.com.br. Retrieved 27 April 2010.
- "OpenIndiana Bordeaux announcement". OpenIndiana-announce mailing list. Retrieved 1 October 2010.
- "Bordeaux group press release". Bordeaux group site. Retrieved 1 October 2010.
- "ARM support". The Official Wine Wiki. Retrieved 20 August 2011.
- "[Wine] Re: Wine sometime really surprise me". Retrieved 15 February 2013.
- "WineHQ Bugzilla – Bug 26715 – Win1.0 executable triggers Dosbox". Retrieved 15 February 2013.
- "WineHQ – Internet Explorer 5.0". Retrieved 15 January 2014.
- "WineHQ – Internet Explorer 5.5". Retrieved 15 January 2014.
- "WineHQ – Internet Explorer 6.0". Retrieved 15 January 2014.
- "WineHQ – Internet Explorer 7.0 (32-bit)". Retrieved 15 January 2014.
- "WineHQ – Internet Explorer 7.0 (64-bit)". Retrieved 15 January 2014.
- "WineHQ – Internet Explorer 8.0 for NT 5.1". Retrieved 15 January 2014.
- "WineHQ – Internet Explorer 9.0 for NT 6.1 (32-bit)". Retrieved 15 January 2014.
- "WineHQ – Internet Explorer 9.0 for NT 6.1 (64-bit)". Retrieved 15 January 2014.
- "WineHQ – Internet Explorer 10.0 for NT 6.1 (x64)". Retrieved 15 January 2014.
- "So far, I do not manage to install IES4Linux". 22 June 2012.
- Vincent, Brian (3 February 2004). "WineConf 2004 Summary". Wine Weekly News (208). WineHQ.org. Retrieved 3 January 2009.
- "Wine Status – DirectX DLLs". WineHQ.org. Retrieved 3 January 2009.
- "CodeWeavers Releases CrossOver 6 for Mac and Linux". Slashdot. Retrieved 3 January 2009.
- "CrossOver – Change Log – CodeWeavers". Retrieved 9 March 2012.
- "CrossOver Games site". CodeWeavers. 6 January 1990. Retrieved 27 April 2010.
- "GameTree Developer Program". gametreelinux.com. Retrieved 2 January 2011.
- "WINE@Etersoft – Russian proprietary fork of Wine" (in Russian). Pcweek.ru. 21 April 2010. Retrieved 27 April 2010.
- "Mac OS X at WineHQ". WineHQ. Retrieved 20 March 2013.
- "[Phoronix] Wine On Android Is Coming For Running Windows Apps". 3 February 2013.
- "Pipelight: using Silverlight in Linux browsers". FDS-Team. Retrieved 4 April 2014.
- "wine-compholio-daily README". github. Retrieved 4 April 2014.
- "Developer FAQ". ReactOS. Retrieved 25 May 2009.
- "Creation of Arwinss branch". Mail-archive.com. 17 July 2009. Retrieved 27 April 2010.
- "Arwinss at ReactOS wiki". Reactos.org. 20 February 2010. Retrieved 27 April 2010.
- "Arwinss presentation". Reactos.org. Retrieved 27 April 2010.
- "Wineskin FAQ". doh123. Retrieved 7 November 2012.
- Matt Moen (26 January 2005). "Running Windows viruses with Wine". Retrieved 23 October 2009.
- "Should I run Wine as root?". Wine Wiki FAQ. Official Wine Wiki. 7 August 2009. Retrieved 24 August 2009.
- "ZeroWine project home page".
- "Linux/BSD still exposed to WMF exploit through WINE!".
- Michal Necasek. "OS/2 Warp history".
- Bernhard Rosenkraenzer. "Debunking Wine Myths".
- "Why Wine is so important". Retrieved 11 December 2011.
- Ports vs. Wine Gamespot (Article by James Hills)
- An Interview With A Linux Game Porter Phoronix, 3 July 2009 (Article by Michael Larabel)
- Puoti, Ivan Leo (18 February 2005). "Microsoft genuine downloads looking for Wine". wine-devel (Mailing list). Retrieved 23 January 2006.
- Jeremy White's Wine Answers – Slashdot interview with Jeremy White of CodeWeavers
- Jeremy White interview on the "Mad Penguin" web-site, May 25, 2004
- Appointment of the Software Freedom Law Center as legal counsel to represent the Wine project
- Wine: Where it came from, how to use it, where it's going – a work by Dan Kegel