Friday, January 18, 2019

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

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

The Wine development release 4.0-rc7 is now available.
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-rc7 (total 13):

  20728  Multiple video players crash when opening audio or video file (MPC-HC v1.6.5, PotPlayer 1.5.x)(FilterGraph_create releases/destroys controlling IUnknown)
  26369  A.R.E.S. Extinction Agenda 1.x (.NET 2.0, XNA 3.1 game) crashes during intro ('quartz' FilterGraph2_Connect must translate HRESULT of failures more correctly)
  29461  BurnPlot (VB6 app) fails to start, complaining with "Run-time error '438'" (WshShell3 'SpecialFolders' collection 'item' method invocation fails)
  34884  Touhou Danmakufu 0.12m's font becomes distorted
  35573  gdi32:fonts test_stock_fonts() fails on Windows 7 in the Japanese and Hebrew locales
  36082  Cannot Read Text In "Question" Boxes On Microsoft Money 2005 Installation
  36084  Microsoft Money 2005 Window Going "Black" After Certain Menu Operations
  43211  NVIDIA GeForce Experience 3.x installer fails due to 'setupapi.SetupDiDeleteDeviceInfo' stub
  44796  Age of Empires II: The Conquerors is broken when CSMT is enabled
  45874  Secret Files 1-2: hardware mouse cursor corrupted
  46212  Multiple games have performance issues (Project CARS, NFS: Hot Pursuit (2010), Gas Guzzlers: Combat Carnage)
  46459  Secret Files 1-2, Ufo: Extraterrestrials: mouse cursor invisible when anti-aliasing and hardware mouse enabled
  46480  Invalid write of size 2 in ntoskrnl.exe/tests/ntoskrnl.c

Run Microsoft Windows Applications and Games on Mac, Linux or ChromeOS save up to 20% off  CodeWeavers CrossOver+ today.

Thursday, January 17, 2019

Working on Wine Part 5 Fixing Wine

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.

Once you've got some idea of what is causing the problem with your application, it's time to go understand how those APIs are implemented in Wine so you can fix it. You may also need to change Wine's code to debug the application in the first place.


Search for existing bugs

Before digging into the source, it's always useful to first search for existing bugs. You can search Wine's Bugzilla for your application, or for the symptoms you're seeing. As you begin to debug your issue, you may find other search terms to try. If you find a bug, you may find some useful analysis or work has already been done for the issue.

You may also want to look through the Wine Staging patches, especially once you have some idea of what the problem is. You may find someone has already written a patch to fix this problem, but it isn't ready to go upstream yet. You can pick up the torch and try to upstream the work.


Wine source layout

Wine implements the Windows operating system, which is composed of libraries, programs, and kernel functionality. You can find the code for Wine's implementation of each of those components in dlls, programs, and server, respectively. To give you some idea of how different components of Wine work together, some important, core components are listed here.
  • dlls/ntdll – This is where many of the core OS APIs are implemented, like file handling, thread creation and synchronization, timing, and much more. Applications typically use kernel32 instead of ntdll directly.
  • dlls/kernel32 – This is the application-facing interface for the core ntdll APIs mentioned above.
  • dlls/user32 – This is where much of the Windows GUI handling lives, like window creation, message handling, terminal services, and so on.
  • dlls/winex11.drv and dlls/winemac.drv – These libraries map the Windows GUI interfaces, and some other platform-specific functions, to the native platform. user32 calls into these platform drivers.
  • dlls/d3d* and dlls/wined3d – These libraries implement the Direct3D graphics API on top of the platform's OpenGL implementation.
  • programs/services – This program manages background services, both those created by Wine and those provided by installed applications.
  • programs/wineboot – This program kicks off initial prefix creation and other tasks when a prefix is booted.
  • programs/winecfg – This is Wine's configuration program.
  • server – The Wine server implements all cross-process functionality, including message routing, multi-process synchronization primitives, registry handling, and much more. The Wine server is always running if an application is running.
While debug channels are often named after the component in which they are declared (e.g. the dsound channel is declared in dlls/dsound), this is not always the case. You can use git grep to find the relevant debug trace line if it isn't obvious.


Writing tests

In most cases, your work should be driven by tests. Study the documentation for the relevant APIs and write tests first to confirm that Windows's implementation behaves how you expect it to. Then, change Wine's source to pass the tests that you wrote.

Wine has an extensive suite of unit tests. The unit tests comprise well over one million lines of code as of this writing. Any patch you submit must pass all of these tests. Patches should contain more tests proving that the new behavior is correct.

In general, you should focus your work on what a real application actually does. That is, you don't need to implement a bunch of unrelated functionality if the application doesn't actually need it. You should write tests to show how an application is using an API, and how Wine fails to meet its expectations. Then fix Wine to also pass those tests without breaking any existing tests. Any change to Wine has the potential to break other applications. Simply passing tests that you wrote is insufficient reason to change Wine.

You can find the tests for a given component in the tests subdirectory. For example, the tests for dsound live in dlls/dsound/tests. You will find .c files in that directory. The tests start in the START_TEST function and exercise the component being tested. The ok function demonstrates correct behavior. Again, "correct" is defined to mean "like Windows." For example:

    hr = IDirectSound_CreateSoundBuffer(ds, &bufdesc, &primary, NULL);
    ok(hr == S_OK, "CreateSoundBuffer failed: %08x\n", hr);
Here you can see the return value from IDirectSound::CreateSoundBuffer is expected to be S_OK. If it is not S_OK, then the test will fail.

Your tests should demonstrate how your application behaves when interacting with that API. Since you are fixing a bug in Wine's implementation of the API, your tests should demonstrate that Wine will fail without your fix. It isn't necessary, or even recommended, to fully exercise all inputs to an API in the Wine tests. Instead, be thoughtful about how your application might use the API given different inputs from the user, and write tests that reflect those possibilities.

Your tests should be self-contained. They should initialize the necessary functions, test the APIs, and then clean up before continuing. If you need to create files on disk, create them in a temporary location and/or clean them up afterwards. If your test may leave changes to the system, expect to have to clean up after a previous run that crashed, before you run your tests.

After you have written some tests, you need to verify that they pass when run on Windows. To do this locally, run make crosstest, which will use your system's mingw-w64 compiler to build a Windows executable. Run this executable on Windows in the command prompt to verify Windows's behavior. If you do not have a Windows system or VM available, you can upload your patch or test binary to the Wine Test Bot.

Once your tests pass on Windows, run them in Wine with make test. If your tests meaningfully demonstrate a Wine bug, they should fail. Now it is time to fix Wine to pass those tests, as well as all existing tests.


Working with Wine's source

As you develop your fix, there are some rules you should know if you intend to send your work upstream.

For better or worse, Wine does not have a coding style standard and likely never will. The rule is to try to match the surrounding code as best as possible. Especially in older code, you will find a horrible mish-mash of tabs and spaces and brace styles. Do your best to make the code no worse than it was. However, extraneous changes are discouraged as they make review difficult and looking up the source history in Git more cumbersome. If you are changing a line, or even one line in a short code block, it can be re-formatted to be less ugly than it was. But don't reformat an entire function to fit some style, no matter how ugly it is.

Wine only accepts code that adheres to the C89 standard, because some compilers that Wine cares about don't support anything later. The three most common snags here are that your code must declare its variables at the top of the block, you cannot use //-style comments, and function declarations with no arguments must be declared with void arguments:

    int some_function(void);
Resist the urge to gut an entire function or module and re-write it. Small, discrete changes that can be easily understood are the right way to fix Wine. Wine is more than two decades old. There is a lot of hard-won knowledge in much of Wine's source, and throwing out all of that history because it's easier than working in the existing code is not likely to pass review.

Make your changes as obviously correct as possible. Unrelated changes must be placed into their own commits. You should not introduce unused code in an early patch, which begins to be used in a later patch.

Write your patches with the reviewer in mind. It may be unintuitive, but understand that it is more important for your patch to be easy to review than make Wine's code perfect. Reviewer time is one of Wine's most valuable assets. Patches that are easier to review are more likely to pass that review.
Be aware that some tests are "flaky." This is an unfortunate reality of a system as complex as Wine. Ideally all tests would pass on all Windows and Wine environments, but due to bugs, differing platform behavior (especially window managers) and timing differences, they don't. Most modules have well-written tests that should always pass. Some, like the user32 messaging tests, and some audio and graphics tests, fail with some frequency, even on Windows.

Full Article

Run Microsoft Windows Applications and Games on Mac, Linux or ChromeOS save up to 20% off  CodeWeavers CrossOver+ today.

Tuesday, January 15, 2019

Working on Wine Part 4 Debugging Wine

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.
If you've made it this far, then you should have a functioning Wine build and an application installed that has some problem that you want to fix.

Debugging Wine is unlike debugging an application or even most open source libraries and software. As a Wine developer, you typically don't have access to the source of the application. So you have to be able to guess at what the application is trying to do, and then figure out why Wine is failing to meet its requirements.

Applications are often debugged with debuggers, but this is of limited use with Wine. A lot of time is spent in application code, which isn't useful to us, or in OS library or kernel code, which is also often not useful to us. Wine is just the go-between from application code to library or OS code, so debuggers tend to spend a lot more time out of Wine code than in it. Problems in Wine are also often less about bugs than they are missing features. Debuggers don't help here.



Instead, most Wine debugging is done with printf-debugging. Wine developers have introduced copious logging into the libraries. When you run an application with these debug traces enabled, it will spit out large quantities of information about how the application is using the library.

You enable these logs with the WINEDEBUG environment variable. This variable takes a comma-separated list of debug channels. While it has a more complicated syntax than this, usually you just enable channels entirely. For example, to debug a networking issue, you might start with:

    $ WINEDEBUG=+seh,+winhttp,+winsock,+wininet ~/src/wine.win64/wine Steam.exe
This will emit a ton of output on stderr. Usually you redirect to a file:

    $ rm -f out.txt && WINEDEBUG=+seh,+winhttp,+winsock,+wininet 
~/src/wine.win64/wine Steam.exe &>> out.txt
Notice that the redirect is in append mode, to allow for more readable multi-threaded logging. This requires that we delete any old log file first.

This is the basic Wine debugging loop. Run the application with logging enabled, demonstrate the failure, examine the log, add more logging if necessary, and repeat until you understand the problem.


Debugging channels

Wine trace logs have four "severities," called TRACE, WARN, FIXME, and ERR. TRACE is just general debugging, and is silenced by default. WARN indicates some suspicious, but non-fatal condition and is also silenced by default. FIXME indicates some missing feature of Wine and will be printed by default. ERR indicates a serious problem and will also be printed by default.

Wine lets developers output logs on specific channels. These are declared in the C source files with WINE_DECLARE_DEBUG_CHANNEL and WINE_DEFAULT_DEBUG_CHANNEL. Grepping the C files for DEBUG_CHANNEL works great.

It's not always easy to determine which log channels are useful to trace. If you know what general area your problem is in, you can add channels from the relevant Wine libraries. If you don't have any idea, then a log with just +seh is a decent starting place to dig for fixmes and errs.
There are some special debugging channels.

tid and pid will prepend each log line with the Thread ID and Process ID that outputted the log line. tid is enabled by default in recent Wine.

relay will output every API entry point that the application, or other parts of Wine, make a call to. This is extremely verbose, but can be very valuable, especially if you don't know where the problem lies.

timestamp will prepend every log line with a millisecond-resolution timer. This is great if you can estimate when in the log the problem occurred, or are working with timing-sensitive code like audio.


Working with log files

Most WINEDEBUG logs will grow to hundreds of kB and MB of plaintext. Logs of multiple GB are not uncommon, especially relay logs. Many GUI text editors will not handle files of these sizes very well. An editor like vim is recommended.

You should also get familiar with tools like grep, head, and tail to pare log files down to manageable chunks. In particular, grep -v can get rid of uselessly repetitive log lines.
When encountering a new log, a good first step is to grep for err:, warn:, and fixme:. These can indicate problems. You'll likely get a lot of fixmes and probably some warns. If you're getting messages from areas unrelated to the problem you're examining, you can usually ignore them. For example, fixmes from the d3d channel are probably unrelated to a problem with audio.


Log file techniques

One generally useful technique is to find the problem and then search backwards. For example, bad pointer dereferences are a common failure. These can be found in a +seh log by searching for c0000005. Once you've found the failure in the log, you can start going backwards and if you're lucky, find some fixme or err indicating a missing feature. Or in a relay log, you might find some API that is returning a failure, like a bad HRESULT instead of S_OK.

If you don't have an obvious crash point, you can also try to find where in the log things start to go bad. For example, most applications follow a pattern of loading libraries, initializing stuff, normal application processing, then uninitializing stuff and unloading libraries. If you have an application that is quitting unexpectedly, you can search for when shutdown-related code is happening and then start going backwards to try to find the culprit.

If you have an application that fails on some specific input condition (say, clicking on some UI element), you can actually write to the log at the same time that Wine is. While Wine is debugging, run:

    $ echo '@@@@@@@@' >> out.txt
Then perform your action and observe the failure. Then run it again:
    $ echo '########' >> out.txt
Now you know the failure occurred between the at-symbols and the hashes.

Full Article

Run Microsoft Windows Applications and Games on Mac, Linux or ChromeOS save up to 20% off  CodeWeavers CrossOver+ today.

Phoenicis PlayOnLinux 5.0 - Alpha 2 has been released

Hi everyone!

We wish a happy and successful year! For this first day of 2019, we are glad to release the second alpha version of Phoenicis PlayOnLinux 5.

A new wine builder

We have rewritten from scratch our winebuild platform. To make it short, it is more reliable, more transparent, easier to setup and cross-platform compatible. Any project that needs to use wine could now potentially use it and take advantage of the 1828 different builds. (We admit that some of them are outdated, though).

The winebuild project is open source, uses containers. You can install it on your machine in no time if you want to build wine by yourself.

Support of new wine distributions

Speaking about wine builds, we now support 4 wine distributions:
  • Upstream wine builds are vanilla and unmodified wine (1)
  • Staging wine builds are the wine builds patched by wine-staging
  • Dos support wine builds contains wine and dosbox. (See the next feature)
  • CX contains a wine version patched by codeweavers
We plan to support proton in the next weeks.
All these wine build can be compiled directly through

(1) Except the very old versions that have a specific suffix is their names, like 1.5.3-heap_allocation_v2-avoid_deadlock, but we are going to move them anyway.

DOS Support

Winebuild now provides dos_support distribution. The way these wine binaries works is very simple: Wine launch script has been modified to detect if the given .exe is Win32 or a DOS executable. If it is a DOS executable, it will set-up a dosbox configuration that will behave consistenly with wine:
  • mount drive_c as C: on dosbox
  • if a autoexec.bat file exists inside the prefix, it will run it
  • support of custom DOS configuration per prefix
  • ...
The script framework has also been modified so that you can tweak some dosbox settings directly from a script. Here is an exemple of "advanced" script
9 + "/drive_c/The Elder Scroll 1: Arena/Arena106.exe"); // Arena106.exe is a w32 fine, wine will run
    .cpuCycles("max 95% limit 33000")
    .renderFrameSkip(1); + "/drive_c/The Elder Scroll 1: Arena/ARENA.BAT"); // ARENA.BAT is obviously a MS-DOS file, dosbox will run

GoG support

We've added a way to add a web browser view directly inside script wizards. Thanks to this feature, scripts can now authenticate to any website.
Phoenicis can automatically download and install GoG games from your account, as POLv4 used to do during the past years.

A complete demonstration video of support:
Also, we have made a script pattern for all GoG games: it has drastically simplified them from POLv4. The script are so much easier that we believe that they will be a lot more maintained.

POLv5 script POLv4 script
include(["engines", "wine", "quick_script", "gog_script"]);
var installerImplementation = {
    run: function () {
        new GogScript()
            .author("Quentin P├éRIS")

We are planning to add tons of GoG games in the library so stay tuned!

Installation of verbs directly inside a container

You can now install verbs directly from a wine container.

Standalone packages

  • We are now providing standalone packages that can work on any distribution without the need to install JDK runtime. These packages also remove all the feature that we don't need from the JDK. In the future, there will be probably two sorts of packages, but we want to make things easier for you for now.
  • We now provide macOS packages
  • We also support flatpak

I'd like to thank once again all the developers that helped us during the past weeks, plata, madoar, and also all those of you that contributed by reporting bugs, suggesting improvements, or tested phoenicis-winebuild.

Our next goals is to focus on prefix management (change of wine version inside a prefix, add debugging tools, etc...) and performance optimization.

If you have any suggestion or encounter any bug, we encourage you to come in our Github page: This version is still at alpha-stage, so please be indulgent.
I also take the opportunity of this news to also announce you that PlayOnLinux and PlayOnMac 4.3.4 has been released. They have been updated to support the new winebuild system, and the different windows of the application have been made resizable. It should fix the HDPI issues some of you were encoutering. We continue to maintain these versions until you are 100% satisfied with POLv5

Full Article

Putty for Mac
Putty for Mac