Support us on Patreon to keep GamingOnLinux alive. This ensures all of our main content remains free for everyone. Just good, fresh content! Alternatively, you can donate through PayPal. You can also buy games using our partner links for GOG and Humble Store.
We do often include affiliate links to earn us some pennies. See more here.

The Wine 4.6 development release is now available and it includes some rather interesting updates, along with plenty of bug fixes.

Here's the highlights of Wine 4.6:

  • Beginnings of a Vulkan backend for WineD3D.
  • Support for loading Mono libraries from a shared location.
  • Libwine.dll no longer needed when using Wine DLLs on Windows.
  • Regression tests compiled directly to PE format.
  • Support for the Split Button Common Control.
  • Complex structs support in the typelib marshaller.
  • Video capture ported to Video4Linux version 2.
  • Initial version of the Debug Engine DLL.

They also noted 50 bugs have been marked as solved as of this release. As always, this doesn't mean all 50 were fixed in Wine 4.6, as some were only re-tested and found as solved in previous releases. The list of fixes includes Warframe, Mass Effect, a fix for BattlEye, The Sims, Revenant and plenty more.

Wine getting fixes for BattlEye is a curious one, since the official line from BattlEye is that they can only support titles with native ports. It will be very interesting to see if that really is the case or if Wine can get to a stage where it works with it.

You can find the full release announcement here.

Article taken from GamingOnLinux.com.
Tags: Wine
21 Likes
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly. Find me on Mastodon.
See more from me
The comments on this article are closed.
31 comments
Page: «3/4»
  Go to:

Avehicle7887 Apr 14, 2019
The Staging release for 4.6 is out, I just gave it a spin with the newly included esync patches and it's working fine.
Shmerl Apr 14, 2019
Quoting: etonbearsNow, why did I go into that detail? The reason is that this is the mechanism by which DXVK is implemented. Wine does not actually contain a working implementation of D3D10 or D3D11 in winelib.

Not exactly. A lot of D3D11 / D3D10 is already implemented over OpenGL. But that's suboptimal, and implementation is not as complete as DXVK.
Purple Library Guy Apr 15, 2019
Quoting: Shmerl
Quoting: etonbearsNow, why did I go into that detail? The reason is that this is the mechanism by which DXVK is implemented. Wine does not actually contain a working implementation of D3D10 or D3D11 in winelib.

Not exactly. A lot of D3D11 / D3D10 is already implemented over OpenGL. But that's suboptimal, and implementation is not as complete as DXVK.
I think his point was that it's not in winelib; rather it's implemented in dlls, which DXVK then substitutes its own for.
Trias Apr 15, 2019
View PC info
  • Supporter
Quoting: etonbears
Quoting: Purple Library Guy
QuoteBeginnings of a Vulkan backend for WineD3D.
I'm confused about just what this represents and how it interacts with or complements or duplicates DXVK and certain sister projects to DXVK.

It is complicated, but I'll tell you what I believe is true, though this requires some detail ( sorry! ).

The Wine Project contains a native OS library, called "winelib", that implements the lowest level layer of pure 'C' language Windows APIs that is generally known as WIN32. If you have the source code for an WIN32 application, you can compile directly against this "winelib" implementation, resulting in an entirely native binary that you can run directly on your OS.

Wine also provides a "virtual Windows" environment if, as is more usual, you do not have the source code. This environment knows how to read Windows-formatted executables/libraries, and load them into memory to run as if they are native-format for your OS. It also knows how to slectively combine Windows-formatted executables/libraries with the winelib implementation of any WIN32 function calls the executables/libraries make.

This "mixed mode" of Windows-format executable code, combined with the native winelib implementation of WIN32 is enabled by using a Wine virtual filesystem, better known as the "Wine Prefix".

If you look at "C:\windows\*" in your Wine Prefix ( the default location is "~/.wine/" under Linux ) you will see directories full of the same filenames you normally see on windows. But if you look carefully, you will note that all of the libraries ( C:\windows\system32\*.dll, for example ) are tiny files, and all the same size. This is becaus they do not contain any implementation, they are just entry points to winelib; these entry points are what wine refers to as "builtin" versions of windows libraries.

If you use wine to run a Windows-format executable, it uses these tiny "builtin" dlls to invoke the implementation in winelib. But what if you have problems, and the winelib implementation of a windows library does not work well with your Windows application? Well, you CAN try to replace the offending winelib library, by just overwriting the version in the Wine Prefix with one copied from a Windows installation, then run the "winecfg" command to tell wine you have replaced the builtin library. If you are lucky, it solves your problem. If you are unlucky, the problem gets worse, or you end up replacing half of your Wine Prefix trying to work out which combination of dlls works best.

Now, why did I go into that detail? The reason is that this is the mechanism by which DXVK is implemented. Wine does not actually contain a working implementation of D3D10 or D3D11 in winelib. The "correct" way to fix this would be to join the Wine project, learn all about the existing winelib code-base and coding practices, then design and implement a harmonious, bug-free, maintainable implementation of D3D10/11 within winelib. What Philip Rebohle decided to do was create a replacement for the set of DLLs that normally provide D3D10/11 in Windows, using Vulkan to implement the D3D features, then you simply drop these DLLs into a Wine Prefix, use winecfg to indicate you are overriding the builtin implementation for these DLLs, and magically your game works.

I can completely understand why Philip did it this way, as it means he does not impact the Wine Project at all, does not nead to learn how to be part of it, and can just get on with making DXVK work in a development environment he is comfortable with.

However, there is a problem with this. While 4 of the 5 DLLs DXVK replaces are stand-alone and independent, DXGI.DLL is not. DXVK will allow you to run D3D10 and D3D11 games, but breaks games using WineD3D, which also implements DXGI.DLL. This is why the Wine developer was trying to coordinate DXGI use with Philip Rebohle.

I'm sure this will get sorted out eventually.

One of the best explanation I've heard. Thanks!
Spirimint Apr 15, 2019
Do i get i right? This can solve Problems with DirectX9?
Games with DirectX9 still not running very good in my System.
Still trying to get Anno 1404 and Settlers 2 to get work.


Last edited by Spirimint on 15 April 2019 at 10:10 am UTC
etonbears Apr 17, 2019
Quoting: Shmerl
Quoting: etonbearsNow, why did I go into that detail? The reason is that this is the mechanism by which DXVK is implemented. Wine does not actually contain a working implementation of D3D10 or D3D11 in winelib.

Not exactly. A lot of D3D11 / D3D10 is already implemented over OpenGL. But that's suboptimal, and implementation is not as complete as DXVK.

I'm aware some of the D3D10/11 APIs are implemented in Wine, but not enough to class it as a working implementation, in my opinion. Certainly not enough to run anything I tried, though I'm sure some games will work. It may be that the inadequacies of OpenGL make it difficult to reimplement D3D11, but according to the wine devs themselves, the main reason for not finishing was that they had other (rent-paying) priorities.
Shmerl Apr 17, 2019
At one point The Witcher 3 almost worked using wined3d, except for a few remaining bugs and annoying hangs on Polaris cards. So I'd say they were pretty far along, but dxvk surely surpassed that.
etonbears Apr 17, 2019
Quoting: SpirimintDo i get i right? This can solve Problems with DirectX9?
Games with DirectX9 still not running very good in my System.
Still trying to get Anno 1404 and Settlers 2 to get work.

As far as I know, DXVK implements D3D10 and D3D11, but not D3D9 or D3D12. So, I guess that would be "no" in answer to your question. Wine does, of course already have D3D9 support, but it sounds like it doesn't work well for you.

A quick Internet search suggests that Settlers 2 for Windows is actually an OpenGL game, and Anno 1404 is D3D10. I'm assuming you have the re-master versions, since the Settlers games were originally DOS-based - I used to quite enjoy them myself back in the 90s.

Anyway, if you have the remaster of Anno 1404, maybe DXVK will help you, after all.
etonbears Apr 17, 2019
Quoting: ShmerlAt one point The Witcher 3 almost worked using wined3d, except for a few remaining bugs and annoying hangs on Polaris cards. So I'd say they were pretty far along, but dxvk surely surpassed that.

The Witcher 3 always seemed closer to working properly in WineD3D than some others, that's certainly true. I've not managed to finish the Witcher 2 yet, so it wasn't something I tried. Quite a few games I did try either didn't get past the first few screens, or were significantly broken if the game did run. DXVK seems to have overtaken WineD3D in most people's minds, but I'm sure the wine devs will do a very good job when they have time to get a Vulkan back-end working.
cRaZy-bisCuiT Apr 17, 2019
Quoting: SpirimintDo i get i right? This can solve Problems with DirectX9?
Games with DirectX9 still not running very good in my System.
Still trying to get Anno 1404 and Settlers 2 to get work.

Instead of "Settlers 2" you could also play "Return to the Roots". It's a Open Source implementation of the game and it does run very well and plays like Settlers II.
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
The comments on this article are closed.