Pages

Tuesday, January 8, 2019

Working on Wine Part 2 Wine Build Process

Andrew Eikum a CodeWeavers employee and Wine developer is writing a series of post to introduce people to Wine usage and development.

This is a series of guides intended to introduce software developers to the Wine ecosystem. It will cover what Wine is, how to use Wine, how to debug Wine, how to fix Wine, and what to do with your fix once you've made it.

The guide will be published throughout January.

  • Part 1 describes what Wine is and provides a short description of various popular forks of Wine.
  • Part 2 describes Wine's build process.
  • Part 3 describes how to use Wine as a developer.
  • Part 4 describes how to debug Wine in general.
  • Part 5 describes Wine's source tree layout and how to edit the source.
  • Part 6 describes how you can send your work upstream.

Wine is effectively an operating system, including all of the libraries that a Windows system provides, such as support for 3D graphics, networking, audio, and a graphical user interface, as well as dozens of support libraries that software can use like XML parsers, file format readers and writers, multimedia playback, and much more. As such, it is a very complex piece of software. Building Wine is not a trivial task.

Much of this process depends on your particular operating system, and operating system version. This guide will not get into particulars for every operating system, but instead describe the process in general. Specific guides are available at the WineHQ Wiki.

Acquiring Wine


While you can grab the Wine source from many places, the only useful place for Wine developers is to clone the Wine Git repository.

Wine uses the typical configure && make && make install process of other autoconf-based software projects.

Choosing 32-bit or 64-bit


Microsoft Windows started shipping support for 64-bit software in the mid-2000s. Wine also has support for running 64-bit Windows software. The way this works in Wine is you effectively build it twice: once for 64-bit software and again for 32-bit software. Wine will choose the correct library architecture for a given executable at runtime.

Unfortunately, building for both architectures can be complicated on Linux. Many Linux distros have poor support for installing software for multiple architectures. Since most of the software that distros support is open source, and since open source software can be built for any architecture, there is little reason to support alternate architectures. However, the Windows software that you want to run is likely to require 32-bit support. Distros that do provide multi-arch support often do it only for Wine. To be blunt, that's a fairly small usecase, and so these 32-bit libraries are often treated as second class citizens.

macOS is even worse. Apple is dropping 32-bit support entirely sometime in 2019. No one knows exactly what this will mean for users of unsupported, 32-bit-only software, including Wine users, but it doesn't look good.

In any case, 32-bit support is required to run most Windows software, so it is effectively required if you want to build Wine. It is also strongly recommended that you build 64-bit Wine as well, since more and more Windows software is being built for the 64-bit architecture. This guide will show you how to build both.

Building Wine


By default, configure will run in 32-bit-only mode. To support both 64- and 32-bit software (called "WoW64"), we want to first build 64-bit Wine and then make a build of 32-bit Wine which references the 64-bit Wine.

Wine's configure script will search your system for the libraries Wine needs to run Windows software. It takes a while to run. At the bottom of the output, it will warn you about any missing packages. Any missing packages that are critical will be marked with WARNING text. You are strongly suggested to install these missing packages before continuing, or your Wine may be missing critical features.

For example:

    $ cd src/
    $ mkdir wine.win64
    $ cd wine.win64
    $ ../wine/configure --enable-win64
    [ much truncated output ]
    configure: vkd3d 64-bit development files not found, Direct3D 12 
won't be supported.
    configure: WARNING: libjpeg 64-bit development files not found, JPEG 
won't be supported.


You can see my system is missing the 64-bit VKD3D package. This is OK, since I don't care about Direct3D 12 support for the applications that I want to run. On the other hand, if I did want to run some Direct3D 12 games, then I would need to fix this problem and re-run configure.
However, it is also missing the libjpeg package. This is bad news. Lots of applications will require JPEG support and may behave badly if it fails, so Wine gives me a big WARNING. I should install 64-bit libjpeg and re-run configure.

Continue installing packages and re-running configure until you are happy with the missing package state. Then build Wine with make. A typical Wine build for a single architecture can take between 20 and 60 minutes, depending on the speed of your CPU and hard drive. It is strongly recommended to run make with a -jN flag appropriate to your CPU count. ccache will also significantly speed up future Wine builds. You can build Wine with ccache using CC='ccache gcc' at configure-time.

Hopefully your build will complete without errors. At this point, you can run 64-bit Windows applications. However, most Windows software does require 32-bit support at some point, often for the installer or some background process and services. So let's get a 32-bit build started, using the same process:


    cd ../
    mkdir wine.win32
    cd wine.win32
    ../wine/configure --with-wine64=../wine.win64
    [ much truncated output ]
    configure: vkd3d 32-bit development files not found, 
Direct3D 12 won't be supported.
    configure: WARNING: libjpeg 32-bit development files not found, 
JPEG won't be supported.
    configure: WARNING: libpng 32-bit development files not found, 
PNG won't be supported.
    configure: WARNING: libxml2 32-bit development files not found 
(or too old), XML won't be supported.


Oh my, far more errors here. You need to install the 32-bit versions of all of the same packages. How to do this, and what packages are available in 32-bit, is going to vary widely between distros, and we won't cover this here. Refer to the Wine Wiki for your particular distro.
Again, when you are happy with the state of your packages, run make and go grab lunch. When it's done, you will now be able to run 64- and 32-bit Windows applications in Wine.

Building crosstests


The last stumbling block is cross-compiling the tests so that they can be run on Windows. This isn't technically required the Wine testbot will build a patch file and run it on Windows for you—but it will greatly speed up your development process if you can build the tests locally and run them in a Windows VM that you control.

To build the crosstests, you must have mingw-w64 installed at configure-time. Availability will vary by distro. Run make crosstest at the top-level of the Wine tree to build all of the crosstests.

Full Article


MacOS and Windows software bundles, save up to 90% off the normal retail price only at BundleHunt.
 

Friday, January 4, 2019

Wine development release 4.0-rc5 is now available for Linux FreeBSD and macOS

Wine development release 4.0-rc5 is now available for Linux FreeBSD and macOS

What's new in this release:
  • Bug fixes only, we are in code freeze.
The source is available now. Binary packages are in the process of being built, and will appear soon at their respective download locations.


Bugs fixed in 4.0-rc5 (total 14):

  32218  LTSpice: Objects not resized when the window is resized
  32221  LTspice: component drawing issues when moving
  33719  comctl32:propsheet custom window proc test failure
  34334  MetaTester 5 never sends or receives data
  38721  Resident Evil 5 Gold Edition (Steam) fails to run
  39959  Growtopia v2.20->v2.14 fails (was v2.11 fails) to  run with unhandled exception on x86-64 (2.09 & 2.13 did run ok)
  44485  Delphi 7 debugger generates new exceptions by itself
  45719  comctl32:treeview test_right_click depends on mouse pointer position
  45917  battle.net launcher and mouse position on high DPI monitor
  45984  Skyrim Special Edition does not get past loading screen on high core count or high memory systems
  46266  tzres is constantly being loaded/unloaded when TimeZone information is queried.
  46328  Installer for Tanglet 1.5.3 crashes at target directory selection
  46352  TreePad X Enterprise 12GB (single user) v7.17.0: Generates Error on Startup
  46353  TreePad X Enterprise 12GB (single user) v7.17.0: Horizontal Ruler/Scale Is Different on Startup and Margins Are Different on Open Database

MacOS and Windows software bundles, save up to 90% off the normal retail price only at BundleHunt.
 

Thursday, January 3, 2019

Working on Wine Part 1 The Wine Ecosystem

Andrew Eikum a CodeWeavers employee and Wine developer is writing a series of post to introduce people to Wine usage and development.

About This Guide


This is a series of guides intended to introduce software developers to the Wine ecosystem. It will cover what Wine is, how to use Wine, how to debug Wine, how to fix Wine, and what to do with your fix once you've made it.

The guide will be published throughout January.
  • Part 1 describes what Wine is and provides a short description of various popular forks of Wine.
  • Part 2 describes Wine's build process.
  • Part 3 describes how to use Wine as a developer.
  • Part 4 describes how to debug Wine in general.
  • Part 5 describes Wine's source tree layout and how to edit the source.
  • Part 6 describes how you can send your work upstream.

 

What is Wine?


Wine is an open source reimplementation of Microsoft's Windows operating system on top of various Unix operating systems. It primarily targets Linux and macOS, but can also be run on other systems like FreeBSD, NetBSD, and Solaris. What this means for users is that they can run software that was made for Windows on other operating systems.

Wine does not contain any Microsoft-owned code, so there is no need for a Windows license to run Wine. Instead, the Wine developers have rewritten components of the Windows operating system such that software run in Wine will think it is running on Windows, even though it is actually running on Linux, for example.

As a simple example, consider the Windows CreateFile API. On Windows, an application could call:

    CreateFileA(
        "C:\\some_file.txt",   //lpFileName
        GENERIC_WRITE,         //dwDesiredAccess
        0,                     //dwShareMode
        NULL,                  //lpSecurityAttributes
        CREATE_ALWAYS,         //dwCreationDisposition
        FILE_ATTRIBUTE_NORMAL, //dwFlagsAndAttributes
        NULL                   //hTemplateFile
    );
 
Wine will take that CreateFileA call and turn it into a Unix open call:
    open(
        "/home/aeikum/.wine/drive_c/some_file.txt", //path
        O_WRONLY | O_CREAT,                         //oflag
        0644                                        //creation mode
    );
 
The file handle will be returned back to the application, which can then write to the file with a similar implementation mapping WriteFile to Unix's write. Of course the actual implementation of CreateFileA in Wine is far, far more complicated than this (consider the path conversion, for example), but this gives you the gist of what Wine does.

Wine Forks


Since Wine is an open source project, anyone is free to make copies of it and modify it to suit their needs or the needs of their users. There are hundreds of Wine forks, but a few of them have gained prominence and are described here.

"Upstream" Wine


Website: https://www.winehq.org/
This is the "official" version of Wine, from which all other forks are derived. When someone refers to "Upstream" Wine, they are talking about this project. Wine is primarily focused on correctness. Wine contains extensive unit tests which demonstrate the behavior of Windows, and requires that most patches provide tests. All patches must pass the existing tests to be accepted. There is also a strong focus on code quality. Wine is a very large project (it is literally an entire operating system, including a GUI), so technical debt is strongly avoided to keep the project maintainable going forward.

Wine Staging


Website: https://wiki.winehq.org/Wine-Staging
However, Wine's strict patch acceptance requirements means that lots of patches that are unproven, wrong, or dangerous, but useful for users today, would languish in private forks or on the bug tracker. The Wine Staging project (also spelled "wine-staging") is an attempt to gather and maintain these useful patches so users can easily take advantage of them. The Wine Staging community also works to upstream these patches into Wine, so their benefits become available for all Wine users and forks, while also lowering Wine Staging's own maintenance burden. It can also serve as a "testing grounds" for patches which are difficult to prove with unit tests before they are accepted upstream.

CrossOver


Website: http://www.codeweavers.com/
CrossOver is a commercial fork of Wine sold by the CodeWeavers company. It contains many patches that are application-specific hacks and not appropriate for upstreaming. CodeWeavers also maintains an application compatibility database which will pre-install some software components and otherwise modify the Wine environment so that certain applications work better. However, CodeWeavers strongly prefers to implement features correctly and send that work to upstream Wine. CodeWeavers employees perform a significant portion of the work done on Wine.

Proton


Website: https://github.com/ValveSoftware/Proton/
Proton is a fork of Wine created by the Valve software company, which is integrated with their Steam software, a major video game and software distribution platform. Proton is focused on providing a seamless experience for Steam users to run Windows titles on Linux. Like with CrossOver, most of the contributions to Proton are also sent to upstream Wine.

Other forks


There are many, many other forks of Wine. Some are packaged with commercial software and sold as macOS and Linux software. Others are one-off forks created by users for a specific application.

Developing for Wine


Wine isn't perfect, and it's likely you will run into an inadequacy or a bug in your day-to-day Wine usage. Perhaps you are interested in fixing Wine so it will run your application or game, or maybe your employer would like to use Wine and pay you to fix it. This guide will introduce you to how you can build, debug, and fix Wine, and how to send those fixes upstream.

Full Article

MacOS and Windows software bundles, save up to 90% off the normal retail price only at BundleHunt.
 

Wednesday, January 2, 2019

Q4Wine 1.3.11 has been released for Linux and Mac OSX

Q4Wine is a Qt GUI for Wine. It will help you manage wine prefixes and installed applications. It currently supported on Linux, FreeBSD and Mac OS X platforms.

Q4Wine was initially written by Alexey S. Malakhov aka John Brezerk. General idea comes from WineTools scripts which were initially written by Frank Hendriksen.



General features are:

  • Can export Qt color theme into wine colors settings;
  • Can easy work with different wine versions at same time;
  • Easy creating, deleting and managing prefixes (WINEPREFIX);
  • Easy controlling for wine process;
  • Autostart icons support;
  • Easy cd-image use;
  • You can extract icons from PE files (.exe .dll);
  • Easy backup and restore for managed prefixes;
  • Winetriks support;
  • And more: Explore it!;
 Changelog for 1.3.11 :

Fixed:
  • Display of Valve Proton in Processes view BUG-138;
  • Improve all dialogs of choosing files BUG-139;
  • Allow Stop Wine action to kill Valve Proton in Processes view BUG-138;
Updated:
  • Code cleanup: drop Qt4 support;

MacOS and Windows software bundles, save up to 90% off the normal retail price only at BundleHunt.