Exploring Wine 3.7
Jonni Bidwell can’t afford to buy Central Otago Pinot Noirs, but Wine at least enables him to run programs from the other side.
Sometimes you need to dance with the devil. Running Windows programs and games direct on Linux is easy thanks to the tireless efforts of the Wine project.
L inux is a perfectly adequate replacement for Windows. We’d go further and say it’s vastly superior, in almost every way. Yet sometimes some people have just cause to run Windows applications. This might be because Karen from accounts has sent a Word document full of macros and tables and oddly named fonts that needs to be returned, along with accompanying TPS reports, by the end of the day. Some people want to play games not available on Linux, whether they’re classics from that have long been abandoned, or triple A releases that may never make it to the penguin side.
Many people have a dual-boot arrangement or a separate Windows machine altogether, but rebooting or moving to another room is a chore. Wine can also be useful helping people migrate to Linux, enabling them to use Windows tools until they get used to their Linux equivalents.
For nearly 25 years Wine has made it possible for Linux users to run Windows programs from their OS of choice. The results weren’t always pretty, but if you haven’t checked it out for a while you may be pleasantly surprised.
In the beginning there were just a handful of coders working on the project, but today hundreds of contributors (both volunteers and sponsored) contribute to this most unique of FLOSS projects. It’s rapid fortnightly release cycle means that bugs are squashed quickly, but also that your distro might have trouble keeping up. We’ll show you how to get the latest versions, or even try out some extra patches. And we’ll guide you through setting up DXVK, so you can leverage the power of Vulkan to play DirectX 11 games.
Throughout history, wine has been used as a salve to heal one’s wordly woes. Wine has also been linked with confusion, headaches and regrets. Its namesake in the free software world is in many ways similar: it enables Linux users to run Windows programs, but can lead the user to places they’d rather not be, and confront them with errors they’d rather not see. Wine was formerly a recursive acronym for Wine Isn’t aN Emulator, but that has fallen out of fashion. From far enough away it certainly behaves like an emulator, though what it actually does is translate win32 API calls to Linux ones; there’s no machine-level emulation involved. Once you’ve got it installed (see below), you can − in theory − run a Windows program with a simple $ wine program.exe
Before we hit the proverbial bottle, we should explain how Wine operates. Wine maintains its own virtual Windows install (called a Wine prefix or sometimes a
Wine bottle, so the start of this paragraph was apt) in the ~/.wine directory. There’s a virtual drive_c/ subdirectory inside the Wine prefix replete with the familiar Program Files/ and windows/ directories, and interred in the latter you’ll find a bunch of .DLL libraries. These haven’t been ripped from a Windows install (which would be a lawsuit waiting to happen); rather, these libraries have been reverse-engineered or coded based on API documentation to function as closely as possible to the Windows ones. This isn’t an exact process though, and some applications will need native Windows DLLs to function correctly.
Native DLLs can be manually copied from an existing Windows install to the windows/system32 directory, though some require Registry keys and such to be set up ( Wine actually stores its own settings, as well as Windows ones in databases that can be viewed with its own RegEdit). Most programs will install all the DLLs they need automagically, and installers are generally available for those that don’t. Animals like the Visual C runtimes, for example, are best installed by running (with Wine) the installers available from Microsoft’s website. This process can be automated with the popular Winetricks utility (see below).
In the case where we want to use a native DLL that we have installed, as opposed to one of Wine’s built-ins, we can use Winecfg, Wine’s GUI configuration utility, or let Winetricks to it for us. Besides DLL marshalling,
Winecfg can manage lots of other things (including audio, graphics and virtual drives) from the comfort of a Windows-like dialog. You can also choose which Windows version to imitate from here. By default, the root filesystem is mapped to a virtual Windows drive Z: so any program you run with Wine can access anything that your user can. This means we need to take care what we run. A dodgy executable containing malware could encrypt, or even delete, anything our user has write access to. Even if you change the virtual drive settings, Wine doesn’t provide anywhere near the same amount of isolation as a virtual machine, so it shouldn’t be used for running anything of uncertain provenance. Sipping the Wine When you first run Wine, depending on your distro, it’ll offer to install its own Mono and Gecko libraries. These are used for running .NET applications and rendering HTML respectively. Ubuntu used to provide its own packages for these (called wine-mono and wine
gecko and other distros still do. If your distros provides these packages you should use them, and if not let Wine install them for you. Forgetting they’re not installed can lead to some lengthy pursuits of wild geese.
By default, Wine sets up a 64-bit prefix, which is fine ( Wine implements Windows’ WoW64 subsystem) until you run into a 32-bit application that tries to install some other libraries. Said application will detect its 64-bit environment and duly install libraries with too many bits, which won’t work. We hit this problem with the GoGGalaxy client (detailed at https://bugs.winehq.
org/show_bug.cgi?id=43095). The solution is to use a 32-bit Wine prefix to install GoG, achieved by prefixing the wine command with WINEARCH=win32 . We also ran into another problem with the latest version of
GoGGalaxy. The solution there was to install an older version (get it from https://cdn.gog.com/open/ galaxy/client/setup_galaxy_1.2.17.9.exe) and upgrade.
Fun on Wine
Linux users have much less cause to whine about gaming than in days gone by. But one of Wine’s major use cases is for playing games not available on Linux, so let’s look at how we’d get Steam running on Wine using
Winetricks. It’s just a straightforward matter of: $ winetricks steam Then to run it (things often don’t work when you try and start them from the installer) we need to do: $ cd ~/.wine/drive_c/Program\ Files\ \(x86\)/ Steam/ $ wine Steam.exe -no-cef-sandbox
The last argument works around a long-standing bug that prevents the Store and other parts of the Steam interface from loading. Many games will work without further intervention, but the Wine AppDB ( https://
appdb.winehq.org) should be your first port of call if it all goes pear shaped.
The cross-platform Vulkan graphics API (see LXF211) may bring more exciting games to Linux sooner, or at least offer more efficient ports when they do arrive. Much of the work done by companies such as Aspyr Media and Feral is concerned with translating DirectX calls to OpenGL ones. They’d still have plenty to do if this step was replaced by tweaking Vulkan calls, but the workload would be significantly reduced. This depends on industry adoption, though (many publishers are favouring Microsoft’s new DirectX 12 runtime) and in general it’s a hard sell to get them to cater for a minute Linux audience.
Until that all changes though, Wine can help gamers get their fix. For a long time Wine could only translate DirectX 9 (and below) calls, but support for DX10 and 11 was added to mainline with the 3.0 release in January 2018. There are also a number of projects that aim to provide libraries allowing DirectX games to run over Vulkan. There’s VK9 ( https://github.com/disks86/
VK9) for DirectX 9 calls. This project is still in its infancy, but will hopefully be a boon for fans of older titles.
God of Wine
Then there’s DXVK which does the same for DirectX 11 calls. This project is further along than the former, so let’s give it a whirl. We’ll use a separate Wine prefix to try it out, so that anything you’ve got in the default ~/.wine won’t be upset. You’ll need at least Wine3.5 to be able to use DXVK (so the wine-development packages in Ubuntu 18.04 will be fine) , and it should work with Wine
Staging too. You’ll also need to have hardware that supports Vulkan, as well as drivers that support DXVK (see https://github.com/doitsujin/dxvk/wiki/Driversupport for updates). Binaries are available from the project’s GitHub ( https://github.com/doitsujin/dxvk), you’ll find them in the Releases section, so grab the latest tarball (0.50 at the time of writing) from there and set it up: $ tar xvzf dxvk-0.50.tar.gz $ cd dxvk-0.50/x32 $ WINEPREFIX=~/.winedxvk bash setup_dxvk.sh $ cd ../x64 $ WINEPREFIX=~/.winedxvk bash setup_dxvk.sh
We also need the Vulkan SDK (actually just the ICD loader part of it, but it’s easier to just install the whole shebang) to make use of this goodness. With a recent (more recent than the one currently in the Arch repos) version of Winetricks, this can be done with: $ WINEPREFIX=~/.winedxvk winetricks vulkansdk Otherwise we can run the installer, available at https://vulkan.lunarg.com/sdk/home#windows manually with $ WINEPREFIX=~/.winedxvk wine VulkanSDK1.1.73.0-Installer.exe Next, we need to create a file in our Wine prefix that tells it about our Installable Client Driver (ICD). Create this with nano ~/.winedxvk/windows/winevulkan. json and populate it with the following:
{ “file_format_version”: “1.0.0”, “ICD”: {
“library_path”: “c:\\windows\\system32\\ winevulkan.dll”, “api_version”: “1.0.51” } } keys Now to sideload we need this to dip file. into Run the WINEPREFIX=~/. Registry and add some winedxvk MACHINE\SOFTWARE\Khronos\Vulkan regedit . Then navigate to HKEY_LOCAL_ create a new key called Drivers . Inside this key create a new DWORD (right-click in the right-hand panel) entitled C:\ Windows\winevulkan.json and leave its value as 0. Create another Drivers key at HKEY_LOCAL_ MACHINE\SOFTWARE\Wow6432Node\Khronos\ Vulkan and once again create a C:\Windows\ winevulkan.json DWORD with the value 0. Close Regedit and run the VulkanInfo tool with: $ cd ~/.winedxvk/drive_c $ WINEPREFIX=~/.winedxvk/ wine ./Program\ Files\ \(x86\)/VulkanRT/1.0.68.0/vulkaninfo.exe A newer Vulkan runtime may be available by the time you read this, in which case you’ll need a higher number here. Also, daily builds of DXVK are available from https://haagch.frickel.club/files/dxvk. We ended up having to use these to get around a d3d11.dll not found error, but this will probably be fixed by the time you read this. You can use some ninja wgetting to grab all the files at once: $ wget --recursive -np -R “index.html*” -nH –cutdirs=3 https://haagch.frickel.club/files/dxvk/r1093. c7d2957/ Then re-run the setup scripts, remembering the WINEPREFIX variable as above. If things go wrong the DLL-redirection can be turned of and things reset by appending reset to the scripts.
Fine Wine vintages
WinePBA, another patchset based on WineStaging, has recently been made available by Andrew Comminos, an avid WorldofWarcraft (on Wine) player. Andrew’s efforts are documented at https://comminos.com/
posts/2018-02-21-wined3d-profiling.html. Ultimately, he discovered that during gameplay Wine’s Direct3D 9 thread spent a fair amount of time awaiting work, but that this could be ameliorated through Persistent Buffer Allocation.
CodeWeavers has undertaken the ambitious task of creating a Direct3D 12 to Vulkan translation layer in the form of VKD3D. Although this is being coded by Wine developers, it’s an independent project and so could be attractive to people porting games and other applications in the future. Some titles have already been ported using a pre-packaged Wine, but this approach isn’t suitable for everyone. With VKD3D, some code can be rewritten to run natively, Direct 3D code can be translated and there’s no need to bundle Wine and all its libraries.
As well as installing from your distro’s packages, you could compile your own version of Wine, and include any experimental packages you like, but Wine is a huge project and will take time and effort to compile, so this approach is not for the faint of heart.
Besides the two official versions (Stable and Development), a Staging version is available. This originated with the (now discontinued) Pipelight project, an effort to support the Silverlight browser plugin on Linux, which used to be our only recourse for watching Netflix and the like. Pipelight required its own version of Wine with features rejected for inclusion in mainline Wine. Even though we can now watch Netflix natively, there’s still demand for experimental Wine builds, hence the Staging project. Until its inclusion in Wine 3.5, it was the most convenient way to get the CommandStream Multithreading (CSMT) patches, which in some cases offered an increase in graphics performance. But it’s still a useful build for those wanting to see the latest features.
You may have read that Wine Staging was abandoned in mid-February, but fret not. As is the open source way the project has been forked and is alive and well.
and if you’re feeling brave… “As well as installing from your distro’s packages, you could compile your own version of Wine, and include any experimental packages you like”