Other meanings of Wine (software)
Open-source software
Wine is a compatibility layer for running Windows applications on Unix-like operating systems. Rather than emulating an entire computer, it implements much of the Windows application programming interface (API) over operating-system services supplied by Linux, macOS, and other Unix-like systems. The project can load many Windows executables directly, while retaining access to native filesystems, graphics stacks, audio systems, and input devices.1
Wine is an implementation of Windows programming interfaces rather than a conventional virtual machine. Its name was originally an acronym for “Wine Is Not an Emulator,” emphasizing that it translates and re-creates operating-system interfaces instead of simulating an entire x86 computer.1 A Windows program generally remains a Windows Portable Executable (PE) file, a format documented by Microsoft, and Wine supplies the surrounding runtime expected by that program.5
The project began in 1993, initially as an effort to run Windows applications on X Window System environments. It later expanded across Unix-like platforms and became a large free-software project with contributions from both volunteers and commercial developers. Wine is released under the GNU Lesser General Public License, allowing its libraries to be used by both open-source and proprietary software under the license’s conditions.1
Wine works by mapping Windows API calls onto services provided by the host operating system. Its libraries reproduce interfaces such as Win32, the registry, process and thread management, networking, window creation, and common controls; an application therefore interacts with Wine’s implementations while the host kernel and desktop stack perform the underlying work.2
The system includes a loader for Windows executables, a collection of dynamic-link libraries, and a configurable “Wine prefix” that acts as an isolated Windows-like environment containing a drive layout, registry files, and application settings. Programs may run in 32-bit or 64-bit environments, and separate prefixes can prevent incompatible dependencies from interfering with one another. Wine can also call selected native Windows DLLs when licensing and compatibility requirements permit, although mixing native and Wine-provided components can create configuration problems.4
Wine is useful when a Windows application has no satisfactory native Unix version, but compatibility is application-specific rather than absolute. Programs may fail because they depend on undocumented Windows behavior, kernel drivers, copy-protection systems, unusual multimedia components, or tightly integrated versions of Microsoft Office and .NET. The Wine Application Database records community testing and configuration information, while the project’s own documentation describes installation, debugging, and configuration practices.2
Common uses include running productivity software, older games, engineering tools, educational programs, and automated test suites on Linux or other Unix-like systems. Graphics support combines Wine’s Direct3D-related libraries with host graphics APIs; other projects build on Wine for specialized gaming environments. Valve’s Proton, distributed through Steam Play, is a prominent downstream technology that combines Wine with additional components and integration work rather than being identical to the upstream Wine project.6
Wine’s compatibility model includes several less visible layers that explain both its flexibility and its limits. A prefix is not merely a folder of program files: it contains a simulated Windows environment whose registry and drive mappings can be rebuilt, copied, or selected per application. Wine also supports a broad range of host architectures and can run some 16-bit or legacy software through specialized paths, although modern 64-bit operating systems and applications often expose limitations in old assumptions about memory, installers, and drivers.3
Development is partly guided by reverse engineering and behavioral testing because Microsoft’s implementation details are not all publicly specified. Regression testing is consequently central: a change that improves one application can expose an incompatibility in another. Wine’s source tree contains both reimplemented Windows components and Unix-facing utilities, and its release process regularly incorporates fixes for narrow applications as well as major subsystems.3 This incremental character distinguishes Wine from a single fixed compatibility specification.
Wine is distinct from full-system virtualization and from emulation of a complete Windows computer; its compatibility depends on the individual application and its dependencies.
Help improve the encyclopedia. Reports go straight to the site manager.