Thursday 21st of March 2019


Wine is a translation layer (a program loader) capable of running Windows applications on Linux and other POSIX compatible operating systems. Windows programs running in Wine act as native programs would, running without the performance or memory usage penalties of an emulator, with a similar look and feel to other applications on your desktop.

The Wine project started in 1993 as a way to support running Windows 3.1 programs on Linux. Bob Amstadt was the original coordinator, but turned it over fairly early on to Alexandre Julliard, who has run it ever since. Over the years, ports for other Unixes have been added, along with support for Win32 as Win32 applications became popular. Microsoft had successfully steered its Windows program to the forefront of personal computers. IBM had hopes that OS/2 would catch on, but even they admitted that support of Windows programs was necessary and built the ability into their product.

Sun's acquisition of Praxsys Technologies in September of 1992 led to the development of a product called Wabi. Sun first demonstrated the software at the 1993 Solaris Developers Conference. It allowed users of Solaris x86 and Solaris 2.2 for SPARC to run Windows applications out of the box. Other products at the time allowed Windows programs to be run, but they required machine-level emulation and the installation of DOS and Windows. Wabi was unique in that it allowed Windows windowing calls to be translated directly to X Windows calls. By emulating the rest of the x86 code it was possible to actually run Windows programs faster on a RISC workstation! Wabi's more advanced features included Bitstream's font handling technology to handle TrueType fonts.

Wine's storied history of licensing has sparked many debates. The issue of licensing surrounds itself with two primary areas - the license of the Wine code itself and the license of applications produced using Winelib. The Wine developers' goal is to give people the ability to both implement and add to the Wine project in such a way it doesn't hinder others from doing the same. At the same time they want to give other developers the chance to port their application without the fear of being bound to a software license that prevents them from doing what they want with their creation.

In the beginning, Wine adopted a BSD-style license. At the end of 1999 discussion began about changing the license. Richard Stallman had pointed out that it was incompatible with the GPL which potentially causes problems with any open source project wishing to use Wine code. Most developers didn't see a need to craft a new license and the X11 license, a derivative of the BSD license, had the most support. A vote was called for and in January of 2000 Alexandre announced that it would become the new license of Wine.

In March of 2002 a poll was conducted among both the free and commercial developers of Wine to see if there was interest in moving to a different license. Most developers did not want their code to be appropriated by a commercial entity and there were concerns that might happen. After much debate they chose the Lesser General Public License and on March 9th, 2002 the Wine source code became bound to those terms. The LGPL, often referred to as a "copyleft" license, required the Wine developers to abide by some guidelines:
  • Source code (including all changes from the original Wine sources) must be made available to people who receive a binary of Wine. This also applies if Wine is used as a library, in which case only the source of Wine (including all changes) must be made available.
  • Simply linking with Wine does not mean you need to make the source code available for your program.
The immediate effect was the creation of the ReWind project to further the X11-licensed codebase. Many key developers agreed to allow their additions to be used by both the X11 and LGPL Wine code. Most have decided to focus their efforts on synchronizing with the LGPL'ed Wine and the vast majority of development and new features appear there first. Picking a favorite software license is left as an exercise for the reader.

Shortly after changing the license development began to pick up at a greater pace. More patches began to appear, Alexandre made more CVS commits, and more applications were reported to work. By the end of 2003 DLL separation achieved a milestone with the split of the kernel32/ntdll combination. Most of the architectural changes to support a beta release were in place. Another developer's conference was held in January, 2004 in St. Paul Minnesota sponsored by CodeWeavers. Once again, a roadmap was laid out for tasks that needed to be completed.


  • Binary Compatibility
    • Loads Windows 9x/NT/2000/XP, Windows 3.x and DOS programs and libraries
    • Win32 compatible memory layout, exception handling, threads and processes
    • Designed for POSIX compatible operatings systems (eg. Linux and FreeBSD)
    • "bug-for-bug" compatibility with Windows
  • Graphics
    • X11-based graphics allows remote display to any X terminal
    • X11, TrueType (.ttf/.ttc) and Windows Bitmap (.fon) Fonts
    • DirectX support for games (limited Direct3D support)
    • Support for OpenGL based games and applications
    • Printing via PostScript driver or legacy native Win16 printer drivers
    • Enhanced Metafile (EMF) and Windows Metafile (WMF) driver
    • Desktop-in-a-box or mixable windows
    • Windows MultiMedia (WinMM) layer support with builtin codecs
  • Allows Windows program to interface with:
    • Sound devices via ALSA, OSS, ARTS, JACK, and libaudio
    • Multi-lingual keyboards and CJK input method support via XIM
    • Modems, serial devices
    • Networks (TCP/IP and IPX)
    • ASPI Scanners
    • Windows Tablets via XInput (eg. Wacom)
  • Wine API
    • Designed for source and binary compatibility with Win32 code
    • Win32 API test suite to ensure compatibility
    • Compilable on a wide range of C compilers
    • Permits mixing of Win32 and POSIX code
    • Permits mixing of ELF (.so) and PE (.dll/.exe) binaries in one address space
    • Win32 compatible header files
    • Automatically generated API documentation
    • Resource compiler
    • Message compiler
    • IDL compiler
    • Extensive Unicode support
    • Internationalization -- Wine supports 16 languages
    • Built-in debugger and configurable trace messages
    • External memory checker support using Valgrind
    • Sample programs
Wine is still under development, and it is not yet suitable for general use. Nevertheless, many people find it useful in running a growing number of Windows programs. Please see the Application Database for success and failure reports for hundreds of Windows programs.

Many Linux distributions now include a version of Wine in their own native package manager format (.rpm, .deb, etc.)


Copyright © 2009 Era Core, All rights Reserved.