World Wine News

This week, 167 posts consumed 96 K. There were 28 different contributors. 10 (35%) posted more than once. 17 (60%) posted last week too.

The top 5 posters of the week were:

1. 9 posts in 15K by hverbeet at gmail.com (Henri Verbeet)
2. 8 posts in 11K by julliard at winehq.org (Alexandre Julliard)
3. 7 posts in 8K by 00cpxxx at gmail.com (Bruno Jesus)
4. 5 posts in 5K by lauri.kentta at gmail.com (Lauri Kenttä)
5. 3 posts in 3K by stefandoesinger at gmail.com (Stefan Dösinger)

As with the last WWN, this time all the news are written by Stefan Dösinger! I just did the stats.

Enjoy!

Alexandre has released Wine-2.0-rc1 and imposed martial^H^H^H^H^H^H^H code freeze:

The release of 2.0-rc1 marks the beginning of code freeze towards 2.0.
Most of you probably know the drill already, but from now on, only
targeted bug fixes and other "safe" changes, like test fixes,
translation updates, etc. will be accepted.

I know that many people will soon be out for the holidays, but I hope we
can still make significant progress with the open bugs, particularly
with the bugs from the regression list. Now would also be a good time to
retest your favorite applications to make sure that there are no
regressions that we have missed.

As usual, I'll be making release candidates every week, until we run out
of bugs...

Thank you all for helping make Wine 2.0 as good as we can!

Wine‘s Direct3D 11 implementation is making progress! Over the past months Józef Kucia and Matteo Bruni have been slowly, but steadily piling on work in d3d11.dll and wined3d.dll to restructure and add the necessary features. A lot of work is still missing, so don‘t expect fancy titles to run yet. Simpler games have started working a year ago .

Last month Andrew Wesie sent a big patchset consisting of 23 changes to wine-patches that promised to make Blizzard‘s Overwatch run on Wine. Not all of these changes concerned d3d11 – some were changes to the way certain CPU registers are handled in ntdll‘s exception handler. Andrew indicated that those changes are necessary to make the game‘s anti-debug protection work. The d3d-related patches add a few missing d3d11 pieces: Instancing-related shader registers, buffer shader resource views, primitive restart and so on. He also warned that these patches are not enough to make the game run, and more work was needed.

Matteo and Henri Verbeet have provided reviews for the patches. The main concern were missing tests and some implementation details. Andrew has submitted tests and an implementation for two sided stencil, tests for the primitive restart index and the return instruction in shader functions . These patches passed review and are already included in Wine git. Józef has cleaned up Andrew‘s implementation of the return instruction, which is upstream now too.

Besides helping Andrew, Józef has been busy implementing Unordered Access Views (UAVs). They provide read-modify-write access to resources from shaders. Historically resources could either be read (Textures, Buffers) or written to (Render Targets), and it was not allowed to use the same resource for reading and writing at the same time. The OpenGL equivalent of this feature is called image load/store .

An open issue with anything newer than Direct3D9 is that wined3d still depends on legacy OpenGL 2 features and many drivers do not expose some features necessary for d3d10/11 in legacy contexts. With the MaxVersionGL key set wined3d will request a core context, but certain blitting corner cases are still broken. Mesa and the Nvidia binary driver mostly work. On MacOS you are most likely out of luck.

And finally here is a screenshot provided by Andrew showing Overwatch running on his Linux desktop:

Again, the patches necessary to run the game are not in Wine or Wine-Staging yet, and they won’t make it in for Wine 2.0. So don’t hold your breath just yet!

CodeWeavers is running a set of virtual Windows machines to run Wine‘s tests against various Windows versions. These VMs are available for Wine developers under testbot.winehq.org . Francois Gouget is maintaining the Testbot and has posted the results of his recent update work :

The gist of the work was upgrading one of the host machines from Debian 7 to Debian 8.6, which brings in newer versions of QEMU and the Linux kernel. While this fixes a few known test failures, Francois is not happy with the performance of the upgraded machine yet. Memory writes went up mysteriously when restoring the virtual machines, slowing down the test process. Jonas Maebe and Henri Verbeet had some ideas what might be wrong, but at the time of the writing of this article the issue had not been solved yet. The updated host is back in active duty, but running only one virtual machine until the performance can be improved.

Francois has also updated Windows 7 in the client VMs, which caused some test failures that Hans Leidekker has looked into and fixed.

Bruno Jesus tried to fix the old bug 3930 : www.winehq.org/pipermail/wine-patches/2016-December/156112.html . The bug is quite complicated: The affected games – there seem to be a few – uses the old Windows Multimedia Extensions (winmm) API to play sound. Winmm calls callback functions provided by the application. In one of these functions the games call SuspendThread() and put themselves to sleep indefinitely.

This was working at the time the games were written because in Windows 9x winmm had a separate worker thread and called the callback functions from this thread. The callback put the main thread to sleep and would wake it up later, resuming operation. But in Wine and the Windows NT line winmm dispatches messages from the application‘s main thread. Once the winmm callback calls SuspendThread it won‘t be able to wake itself up any more.

Our tests show that Wine behaves like modern Windows versions, and Bruno tried to reproduce the game‘s behavior on a modern Windows version, and sure enough, his test code died the same way the games do on Wine. He found the changelog of the sound middleware responsible for this behavior, and they changed it because it years ago because it was broken on Windows XP . But yet, the games themselves are working fine on the same Windows installation.

A discussion unfolded between Bruno and Andrew Eikum about how to proceed. Bruno‘s patch changed winmm‘s behavior depending on the Windows version set in winecfg. This would require a user to manually configure the Windows version to run these games – with the additional complication that a modern 64 bit WINEPREFIX will not allow you to set anything older than Windows XP – and having version specific code is always ugly. Bruno‘s tests show that Windows has a magic behavior switch for these games which either ignore the SuspendThread call or made winmm behave in a Windows 95 way.

The issue is not yet resolved. Bruno was going to look deeper what triggered the different behavior on Windows and would try to replicate it automatically in Wine. It may require a more complicated shim layer for application compatibility similar to that on Windows or deeper changes in winmm. Either of those involves a lot of work and risk of regressions, so he decided to wait until after the upcoming stable release.

Bill Lionheart wrote to wine-devel about a different kind of problem : He tried to use an amateur radio GPRS tracker with its Windows software and intercept the communication between software and device.

The device shows up on Linux as a USB to serial device - /dev/ttyUSBx. He created a symlink to ~/.wine/dosdevices/com0:, and luckily the Windows software is able to talk to the device and it functions properly. But using the software was not his actual goal.

He unsuccessfully tried Linux tools to sniff serial port traffic and various Windows tools. None of them were able to read the traffic. Christopher Harrington came asked a few questions to make sure Bill‘s setup was correct, which it was.

Henri Verbeet asked for more details about the tools Bill tried: socat and wireshark on the Linux side. They saw outgoing communication, but stopped replies from the device from getting back to the Windows app. But by luck he ran across a tutorial that used a tool called tshark to analyze the USB traffic, which luckily worked. This left Henri a bit puzzled because tshark and wireshark work essentially in the same way, through the usbmon module.

The bottom line is that Bill achieved what he wanted. We‘re all hoping that the records of his endeavor help someone in the future.

*Disclaimer: These lists of changes are automatically generated by information entered into the AppDB. These results are subject to the opinions of the users submitting application reviews. The Wine community does not guarantee that even though an application may be upgraded to 'Gold' or 'Platinum' in this list, that you will have the same experience and would provide a similar rating.