Javatpoint Logo
Javatpoint Logo

How to Install Wine on Ubuntu 16.04 LTS?

Introduction

Wine is an open-source and free compatibility layer that permits computer games and application software to be improved for Microsoft Windows to execute on Unix-like OSes. Wine offers its compatibility layer for the runtime system of Windows (also known as runtime environment), which converts Windows API calls into POSIX API calls, remaking the Windows directory structure and giving alternative Windows system libraries implementations, system services via wine server, and several other elements (like msiexec, the Windows Registry Editor, and Internet Explorer). Predominantly, Wine is specified with reverse engineering (black-box testing) to ignore copyright issues.

  • The choice of "Wine is Not an Emulator" was the outcome of a naming analysis as the Wine Project name in August 1993 and acknowledged to David Niemi.
  • There are a few confusions led by a recent FAQ with Windows Emulator and other false sources that occur after the name of the Wine Project is set.
  • No virtualization or code emulation appears when executing a Windows application upon Wine.
  • Usually, emulation would refer to compiled code execution intended for a single processor by recompiling/interpreting software active on a distinct processor.
  • Although the name occurs in the forms of wine and WINE sometimes, the project developers have been allowed to standardize the Wine form.
  • Primarily, Wine is developed for macOS and Linux, and well-maintained packages are available for both as of July 2020.

History of Wine

In 1993, Eric Youngdale and Bob Amstadt initiated the Wine Project as a way of running Windows apps on Linux. Wine was influenced by two products of Sun Microsystems, the Wahi for Solaris OS and the Public Windows Initiative, an attempt to bring the Windows API completely reimplemented as an ISO standard in the public domain but declined because of load from Microsoft in 1996.

Originally, Wine targeted 16-bit apps for Windows 3.x, but focuses on 64-bit and 32-bit variants, which have become the classic on new OSes as of 2010. The project came from an analysis on Usenet in June 1993 in comp.os.linux. Since 1994, Alexander Julliard has administered the project.

The project has affirmed difficult and time-consuming for the developers, often because of incorrect and incomplete Windows API documentation. While Microsoft documents almost all Win32 functions extensively, a few areas like protocols and file formats have no incomplete or publicly available specification through Microsoft, and Windows contains low-level undocumented functions, obscure bugs, and undocumented behavior that Wine precisely must duplicate to permit some apps to work correctly. The Wine team has done reverse engineering in several file formats, and function calls in such fields as thunking.

Originally, the Wine project published Wine upon a similar MIT License to the X Window System, although owing to consideration about proprietary releases of Wine not sharing their modifications back to the main project, work has utilized the LGPL as of March 2002 for its licensing.

Design of Wine

The aim of Wine is to partially or fully operate the Windows APIs that are needed by programs that the Wine users want to execute over the Unix-like system.

Underlying architecture

The Microsoft Windows programming interface comprises largely of DLLs (dynamic-link libraries). These include several wrapper sub-routines for the kernel system calls and the NTOS kernel-mode program. A classic Windows program calls a few Windows dynamic-link libraries, which calls user-mode user32/gdi libraries in turn, which utilizes the kernel32.dll responsible to deal with the kernel via system calls in turn.

  • The system-call layer is treated as confidential to Microsoft programmers because documentation isn't available publicly, and released interfaces each depend on a subsystem active over the kernel.
  • There are several programming interfaces worked as services that execute as isolated processes besides these.
  • Applications negotiate with user-mode services by RPCs.
  • Wine operates the Windows ABI (application binary interface) in user space entirely instead of a kernel module.

Mostly, Wine duplicates the hierarchy along with services given by the kernel normally in Windows rather than given by a daemon called the wineserver, whose aim is to operate common Windows functionality, signal translation into natural Windows exceptions, and assimilation with the X Window System. Although Wineserver operates a few Windows kernel aspects, it's not possible to utilize natural Windows drivers along with it because of the underlying architecture of Wine.

Applications and libraries

Wine permits to load of both Unix-shared objects and Windows DLLs for its Windows programs. The most common Windows DLL's built-in implementation of it, called USER32, GDI32, KERNEL32, and NTDLL, utilizes the shared object technique as they must utilize functions inside almost all operating systems.

Higher-level libraries, like WineD3D, are available for free to utilize the DLL format. In various cases, users can select to load any DLL through Windows rather than the one operated by Wine. Doing so can offer functionalities not yet operated by Wine, which may also lead to malfunctions if it depends on something else not available in Wine.
Wine can track its implementation state by automated unit testing implemented at all git commits.

Gaming and graphics

While almost every office software doesn't use complicated GPU-accelerated graphics APIs, but system games do. Wine would need to go ahead with the drawing instructions to the host operating system and even convert them into something the host can accept.

DirectX is a group of Microsoft APIs for input, audio, and rendering. The 4.0 version of Wine includes an implementation of DirectX 12 for Vulkan API and DirectX 11.2 for OpenGL as of 2019. Also, the 4.0 version of Wine permits Wine to execute Vulkan apps by managing draw commands to the host operating system or by converting them into Metal API through MoltenVK for macOS.

  • XAudio

The 4.3 version of Wine utilizes the FAudio library to operate the XAudio2 Audio API as of February 2019.

  • Direct2D

The 4.0 version of Wine supports the 1.2 version of Direct2D.

  • Raw Input and XInput

Wine provides its support for game controllers from these libraries' built-in implementation since 4.0. They are made as Unix-shared objects because they need to approach the controller interfaces of the base operating system, specifically via SDL.

Direct3D

Much DirectX effort of Wine goes into creating WineD3D, which is a translation layer from DirectDraw and Direct3D API calls into OpenGL. This element supports up to the 11 version of DirectX as of 2019. Wine is fair enough to execute OverWatch using D3D11 as of 12 December 2016.

Also, WineD3D DLLs have been used in Windows itself besides being utilized in Wine, permitting previous GPUs to execute games with newer versions of DirectX and for previous DDraw-based games to correctly render.

User Interface of Wine

Usually, Wine is derived from the wine.program.exe command-line interpreter.

Winecfg

The winecfg utility initiates a GUI with controls for managing common options. It's a configuration utility of GUI added with Wine. It is easy to configure Wine with winecfg by making it unimportant to directly edit the registry, although, if required, it can be done with the added registry editor.

Third-party applications

A few applications need more tweaking than generally installing the software to properly work, such as configuring Wine to use Windows DLLs manually. The Wine project doesn't combine these types of workarounds to the Wine codebase, rather preferring to concentrate on developing the Windows API implementation of Wine. While it concentrates on Wine development on stable compatibility, it will be hard for users to execute applications requiring workarounds.

Various third-party apps consequently have been made to ease those apps usage that doesn't work right away in Wine. The Wine Wiki manages a page of obsolete and current third-party apps.

  • Winetricks is a script to get some basic elements (typically Microsoft fonts and DLLs) and tweak the settings needed for a few apps to run under Wine correctly. It can automate several games and applications installation, such as using any required workarounds.
  • Q4Wine is a free GUI for advanced Wine setup.
  • Wine-Doors is an app management tool for GNOME, which includes functionality for Wine. It's an alternative to WineTools, which focuses on improving the extent and features of WineTools on the actual idea with a more current design approach.
  • Wineskin is a utility to handle Wine engine variants and makes wrappers for macOS.
  • IEs4Linux is a utility to get every Internet Explorer version, including the 4 to 6 version and the 7 version.
  • PlayOnLinux is a free app to easily get Windows games in Linux.
  • Bottles is a free graphical runners manager and Wine prefix for GTK4+Libadwaita-based Wine. It offers a bottle versioning and repository-based dependency install system to recover an older state.
  • Bordeaux is a GUI configuration manager of Wine that executes winelib applications. Also, it supports installing third-party utilities, games and apps and the ability to utilize custom configurations.
  • WineGUI is an open-source and free graphical interface to handle Wine. It permits us to easily establish Wine bottles and get Windows games and applications.

Functionality of Wine

The Direct3D portion developers of Wine have continued to use new features, including pixel shaders, to enhance game support. Also, Wine can use natural DLLs directly, hence enhancing functionality, but after that, a Windows license is required unless except the DLLs are shared with the app itself.

Also, Wine contains its open-source implementations of various Windows programs, including Windows Explorer, Internet Explorer, Control Panel, WordPad, and Notepad. The Wine AppDB (Application Database) is an online community-maintained database of which Windows programs implements with Wine.

Backward compatibility

Wine guarantees great backward compatibility with many Windows applications, such as those specified for Windows 3.1x. It can mimic several Windows versions needed for a few programs. However, the support of Windows 2.x and Windows 1.x was discarded from the 1.3.12 version of Wine development.

In Wine, backward compatibility is generally preferable to that of Windows because newer Windows versions can pressurize users to update Windows apps and may break rejected software forever because nobody is there to adjust the program for the modifications in the OS.

64-bit applications

In December 2008, prior 64-bit Windows applications support was included in the 1.1.10 version of Wine. The support is treated as stable as of April 2019. The two Wine versions are created separately, and only creating wine64 generates an environment only able to run x86-64 applications as a result.

Wine includes stable WoW64 build support as of April 2019, which permits both 64-bit and 32-bit Windows applications to execute in a similar Wine instance. First, one must create the 64-bit version, and after that, create the 32-bit version representing the 64-bit version to operate such a build.

MS-DOS

Early Microsoft Windows versions run over MS-DOS, and several Windows programs may rely on MS-DOS programs to be accessible. Wine doesn't have good MS-DOS support, but starting with the 1.3.12 version with development, Wine tries to run MS-DOS programs inside DOSBox when DOSBox is present in the system. Because of a bug, current Wine versions incorrectly recognize Windows 2.x and Windows 1.x programs, trying to execute them in DOSBox.

Winelib

Wine offers Winelib, which permits its shared-object Windows API implementations to be utilized as the original libraries for any Unix program. It permits Windows code to be created into natural Unix executables. Also, Winelib Implements on the ARM platform since October 2010.

Non-x86 architectures

Solaris SPARC support was abandoned in the 1.5.26 version.

  • Windows RT, Windows CE, and ARM

Wine offers ARM processor support and the Windows variants that execute on it. Wine can execute Win32/ARM apps intended for open Windows RT devices as of April 2019. The support for Windows CE is missing.

  • Wine for Android

Alexander Julliard represented an early demonstration of Wine active on the Android operating system of Google on 3 February 2013 in Brussels at the FOSDEM talk. For Android, experimental WINE builds were published in late 2017. Routinely, it has been ever since upgraded by the official developers. The default build doesn't operate cross-architecture simulation by QEMU, and ARM variants were only executing ARM apps that utilize the Win32 API as a result.

Microsoft applications

By default, Wine uses Windows builds of Mono and Gecko to replace the.NET Framework and Internet Explorer of Microsoft. Wine includes built-in implementations of VBScript and JScript. Anyone can download and execute the installers of Microsoft for those programs manually or through winetricks.

Other Wine versions

  • CrossOver: CodeWeavers advertises CrossOver specifically to run Microsoft Office and several Windows apps, such as a few games. CodeWeavers engages Alexander Julliard to operate on Wine and shares almost all of its code for the Wine project with the LGPL. For Intel-based Apple Macintosh systems, CodeWeavers also published a new version known as CrossOver Mac on 10 January 2007. Notably, CrossOver can execute on the x64-only macOS versions using a method called "wine32on64", unlike upstream wine.
    CrossOver contains the functionality of CrossOver Pro lines and CrossOver Games; therefore, CrossOver Pro and CrossOver Games are no longer present as individual products as of 2012. CrossOver Games was developed for executing Windows video games. It did not concentrate on giving the most stable Wine version, unlike CrossOver. Rather, experimental aspects are offered for supporting newer games.
  • Proton: Valve introduced a new Wine variation called Proton, developed to combine with the Linux variant of the Steam software of the company on 21 August 2018.
  • WINE@Etersoft: Etersoft, the Russian company, has been improving a proprietary Wine version since 2006. WINE@Etersoft provides its support for famous Russian applications.

In this tutorial, we will install Wine on Ubuntu 16.04 LST operating system. This installation process includes the following steps.

Wine Installation

1) Locate Windows Software Center

Software Wine 1

Open it and type wine in search bar.

Software Wine 2

Click on install button to start installation. After installation, it shows a notification that application has installed successfully.

Now, search wine to check that it is present in menu. Type wine, it shows output like below.

Software Wine 3

Well, wine has installed successfully, now, we can execute any windows application by right clicking and selectingopen with wine windows program. As we did below.

Software Wine 4





Youtube For Videos Join Our Youtube Channel: Join Now

Feedback


Help Others, Please Share

facebook twitter pinterest

Learn Latest Tutorials


Preparation


Trending Technologies


B.Tech / MCA