Screenshot of "Wine Internet Explorer", a simplistic shell of Wine-Gecko, running on Ubuntu. |
|
| Original author(s) | Alexandre Julliard |
| Developer(s) | Wine authors (1,249) |
| Initial release | 4 July 1993 |
| Stable release | 1.2.3 (April 8, 2011) [±] |
| Preview release | 1.3.36 (December 30, 2011) [±] |
| Development status | Active |
| Written in | C |
| Operating system | Unix-like systems |
| Platform | Cross-platform |
| Size | 18 MB (compressed) |
| Type | Compatibility layer |
| License | GNU LGPL v2.1+ |
| Website | www.winehq.org |
Wine is a free and open source software application that aims to allow computer programs written 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.[1]
Wine is a compatibility layer. It duplicates functions of a Windows computer by providing alternative implementations of the DLLs that Windows programs call, and a process to substitute for the Windows NT kernel. This method of duplication differs from other methods that might also be considered emulation, where Windows programs run in a virtual machine.[2] Wine is predominantly written using black-box testing reverse-engineering, to avoid copyright issues.[3]
The name Wine initially was an acronym for WINdows Emulator.[4] Its meaning later shifted to the recursive backronym, Wine Is Not an Emulator in order to differentiate the software from other emulators.[5] While the name sometimes appears in the forms WINE and wine, the project developers have agreed to standardize on the form Wine.[6]
In a 2007 survey by desktoplinux.com of 38,500 Linux desktop users, 31.5% of respondents reported using Wine to run Windows applications.[7] This plurality was larger than all x86 virtualization programs combined, as well as larger than the 27.9% who reported not running Windows applications.[8]
Contents |
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[9] (an attempt to get Windows API fully reimplemented in the public domain as an ISO standard, but rejected by the entity due to pressure from Microsoft in 1996).[10] Wine originally targeted Windows 3.x (16-bit) application software, but as of 2010[update] focuses on 32-bit and 64-bit applications. The project originated in discussions on Usenet in comp.os.linux in June 1993.[11] Alexandre Julliard has led the project since 1994.
The project has proved 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 official Microsoft specification. Microsoft Windows also includes undocumented low-level functions and obscure bugs that Wine must duplicate precisely in order to allow some applications to work properly.[12] Consequently, the Wine team has reverse-engineered many function calls and file formats in such areas as thunking. More recently some developers have suggested enhanced tactics such as examining the sources of extant free and open-source software.
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,[13] work as of March 2002 has used the LGPL for its licensing.[14]
Wine officially entered beta with version 0.9 on 25 October 2005.[15] Version 1.0 was released on 17 June 2008,[16] after 15 years of development. Version 1.2 was released on 16 July 2010.[17] 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.[18]
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.[19]
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.[20][21]
Wine implements the Windows API entirely in user space, rather than as a kernel module. Services normally provided by the kernel in Windows[22] are provided by a daemon known as the wineserver, the task of which 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 from working, such as some copy-protected titles.
Wine is primarily developed for Linux, but the Mac OS X, FreeBSD, and Solaris ports are currently (as of January 2009) well maintained.[23] Wine is also available for OpenBSD and NetBSD through OpenBSD Ports [24] and NetBSD pkgsrc respectively. 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).[25] Some versions of Wine's DLLs are available for Microsoft Windows,[26] but Wine does not fully compile or run on Windows yet.[27]
The developers of the Direct3D portions of Wine have continued to implement new features such as pixel shaders to increase game support.[28] 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 database of which Windows applications work, and how well they work, with Wine.
Wine ensures good backward compatibility with legacy Windows applications, including those written for Windows 3.1.[29] Wine can mimic different Windows versions required for some programs, going as far back as Windows version 2.0.[30] 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). You can nevertheless select "Windows 2.0" as the Windows version you want to emulate, but Wine still won't run Windows 2.0 programs.
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".[29]
Wine can run 16-bit Windows programs on a 64-bit operating system, which uses an x86-64 (64-bit) CPU (example screenshot on the left). 64-bit versions of Microsoft Windows cannot run 16-bit Windows programs.[31]
Wine partially supports Windows console applications, and the user can choose which backend to use to manage the console (choices include[32] 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.[33] This currently 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.
The 64-bit port of Wine also has preliminary WoW64 support (as of April 2010[update]), which allows both 32-bit and 64-bit Windows applications to run inside the same Wine instance.[34]
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 don't work out of the box within Wine itself. The Wine wiki maintains a page of current and obsolete third-party applications.[35]
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.[42]
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.[43] However, Wine currently also identifies Windows 1.x and Windows 2.x programs as MS-DOS programs, attempting to run them in DOSBox (which does not work). Thus, DOSBox availability breaks Windows 1.x and Windows 2.x support.[44]
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,[45] although newer releases have had an increasingly complete implementation.[46]
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.[47]
CodeWeavers has also recently released CrossOver Games, which is optimized for running Windows video games. Unlike CrossOver, it doesn't focus on providing the most stable version of Wine. Instead, experimental features are provided to support newer games.[48]
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. Members can keep using their Cedega ID and password until 28 February 2011.[49]
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 OS X 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).[50] In 2010[update], Etersoft is going to issue WINE@Etersoft CAD which is oriented towards CAD systems such as AutoCAD, Bricscad, and Compass-3D.
Other projects using Wine source code include:
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.[56] Wine can run much malware, but programs running in Wine are confined to the current user's privileges, restricting some undesirable consequences. This is one reason Wine should never be run as the superuser.[57] Malware research software such as ZeroWine[58] 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 the security vulnerabilities it contains.[59]
A common concern about Wine is that its existence means that vendors are less likely to write native Linux, Mac OS X, 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.[60] | ” |
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.[61] | ” |
Also, the Wine Wiki page claims that Wine can help break the chicken-and-egg problem for Linux on the desktop[62]:
| “ | 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 gaming on the platform.[63][64]
Microsoft has generally 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. Puoti wrote, "It's ... the first time they've broken radio silence on the project."[65]
The Windows Genuine Advantage (WGA) system also checks for existence of Wine registry keys. The WGA FAQ states that WGA will not run in Wine by design, as Wine does not constitute "genuine Windows".[66] When WGA validation detects Wine running on the system, it will notify users that they are running non-genuine Windows and disallow genuine Windows downloads for that system. Despite this, some reports have circulated of the WGA system working in Wine,[67][68] although this loophole has now been closed with the next WGA component update. In the case of Internet Explorer 7, Microsoft has since removed the WGA requirements.[69]