Why do Wine's implementations suck?

[rmoog]

I've been using Wine for almost 9 years now and I've noticed a common theme. If Wine invents something as a way of supporting some Microsoft API, then that implementation definitely sucks. Here are some examples to back up my claims:

>Wine DirectX9 support:
>>won't work with Sims 2, haven't EVER worked with that game, you can forget about it getting fixed, the bug report has been sitting there since 2005 and it's still open
>>runs orders of magnitudes slower than OpenGL-enabled software for Windows
>Wine .NET 2.0 support through Mono:
>>some elements of GUIs do not render at all
>Wine 64bit prefix:
>>can't install .NET 2.0 for amd64, you can just forget about it, there is a bug report for this but it's been untouched for years
>Wine DirectX11 support:
>despite bold claims and delusions of grandeur exhibited by the people who wrote the release notes for Wine 3.something when this was introduced, it barely works, and when it works, your textures' bitmaps are replaced with output of /dev/urandom

The obvious remedies for these dreadful scenarios are Mesa for offering DirectX9 support (fast but still unable to run Sims 2) and DXVK for offering a state-of-the-art implementation of DX11 over Vulkan.

So, why does Wine suck at implementing these things? Is there any way we can help them?

[rmoog]

My child did play sims 2 (or sims 3)

That's a huge difference. 3 works OOTB without the need for any fancy patches. 2 will refuse to even start unless you use DX9 from Mesa. In that case you'll only get to the neighbourhood overview. Proceeding any further will crash the game.

Tomb Raider 2013 did work fine with DX11 for me.

I haven't tried this game. Fallout 4, Paladins and Overwatch just flat out refused to work. That's why I called Wine's initial announcement of DX11 support delusions of grandeur.

use wine-staging

I am using the staging patches.

[ALRBP]

Wine devs do what they can, but remember that they have to implements API from M$; a company with a lot of money and paid devs and not exactly open.

You can help by contributing to code or donating, but remember that your time and money is probably light years away from M$'s ones.

[computerquip]

WinAPI is goofy and applications that used WinAPI are using it in a goofier way. For instance, did you know when using `WideCharToMultiByte`, the behavior is not-so-obviously different on Windows 7 and Windows 10? If you're converting from WCHAR UTF-16LE to UTF-8, and you specify a default character, this will work perfectly fine on Windows 10. However, on Windows 7, this function will fail. One way is actually wrong. The documentation says this:

For the CP_UTF7 and CP_UTF8 settings for CodePage, this parameter must be set to NULL. Otherwise, the function fails with ERROR_INVALID_PARAMETER.

So, if you're converting to UTF8, you need to set that parameter to NULL. I guarantee you that there are applications that don't do this, now that Windows 10 is more lax about it.

And this some confusing scenario is just one of dozens, if not hundreds or even thousands. Windows has no qualm about being inconsistent between different versions of Windows as well so imagine the same API being slightly different between, Windows ME, 98, XP, Vista, 7, 8, 10, not to mention the different service packs and server editions. There's also a *lot* of cruft in those APIs, like crap you probably haven't even heard of (I still can't believe ActiveX is still a thing).

This is why I love POSIX-like systems. The implementation is defined by the standard, the standard is not defined by the implementation. A system can be standards compliant, or at least be close. You can then expect that behavior and emulating it is much easier. Linux is mostly standards compliant (where it matters at least, there's a lot of POSIX cruft as well).