Those benchmark numbers are slightly misleading, as they are a comparison of Wine+ntsync against Wine+nothing. There has been a somewhat fast "fsync" library built around Linux's futex and the gains over Wine+fsync are modest (just a few % in most cases).

That said, Wine+ntsync is still a win, just not a 8x improvement like the Dirt 3 benchmark suggests.

(And it case it's not clear, ntsync is https://docs.kernel.org/userspace-api/ntsync.html, which is a driver for Linux that offers syncronization primitives (mutex, semaphore, events) that more closely match the semantics of the Windows primitives. It's easier to do a direct implementation in Wine to support code compiled for Windows that expects to be talking to an NT kernel.)

> There has been a somewhat fast "fsync" library built around Linux's futex

The article actually goes into that in quite a bit of detail about that.

Yeah but to the commenter I was replying to, I don't think it was clear that detail was relevant to the benchmark numbers they were quoting.

Do they have any other usecase behind Wine? My guess would be MS SQL server, but is that correct?

Starting with SQL Server 2017, native Linux support exists. Probably because of Azure.

Ironically, SQL Server AFAIK in order to run on Linux uses what basically amounts to a Microsoft reimplementation of Wine. Which always makes me wonder if they'll ever get rid of Windows altogether someday in favour of using Linux + a Win32 shim. I think there are still somewhat strong incentives nowadays to keep NT around, but I wouldn't be that surprised it this happened sometime down the line.

It's a Windows container. It runs the NT kernel and a few minimal other things. The closest would be the Nano Server container

AFAIK it's more like a reimplementation of NT APIs in userspace - aka basically Wine with extra steps, or Linux UM. There was a slide deck going around about Project Drawbridge, here: https://threedots.ovh/slides/Drawbridge.pdf

Though like the article mentions, fsync doesn't work out of the box (requiring kernel patches).

* when not using esync nor fsync

So, what's the relationship between Wine and Proton? Is Proton just the SteamOS/Valve name for it, or is it actually it's own project?

More or less Wine + some experimental patches not yet I twgrated in mainstream wine + a buch of DirectX translation libraries + close steam integration.

There's also Proton-GE [1], which is even more experimental and adds some bleeding edge fixes and features.

I've heard it's pretty good for fixing video playback/rendering (e.g. cutscene) issues if both the stable and the experimental branch of Proton can't make it work.

[1] https://github.com/GloriousEggroll/proton-ge-custom

A lot of what Proton-GE brings from my understanding is a larger support for Media Foundation, which can't be added to Proton itself because of license issues (Proton is from a commercial company, where Proton-GE is from an individual).

So aside from the stuff that has been implemented differently, running Proton instead of Proton GE is like trying to game on Windows N editions.

Though currently Proton has not yet shipped a release which uses Wine 11.

That makes sense. I thought they were entirely separate tbh but it makes sense that they'd share a lot of DNA.

I absolutely love my Ally running SteamOS. Incredible work by... everyone involved, really.

There is also UMU Launcher[0] which is basically all that without the Steam integration/dependencies so you can run games from GOG and other stores (it is a command-line tool but launchers like Heroic can use it behind the scenes). I used to install dxvk, etc manually but in recent months i switched to it as it tends to work much more seamlessly for games (i did disable its autoupdates though).

[0] https://github.com/Open-Wine-Components/umu-launcher

It's a distribution of Wine with some extra stuff added, importantly DXVK (directx => vulkan layer) and a lot of game specific workarounds.

Read the last sentence in that paragraph, those numbers are a bit disingenuous:

> Those benchmarks compare Wine NTSYNC against upstream vanilla Wine, which means there's no fsync or esync either. Gamers who use fsync are not going to see such a leap in performance in most games.

That makes Wine on Linux even more amazing.

It means these games were already running well in Linux and even better now.

Having done a multi targeted project in the 2005 range. I can tell you. The APIs that both systems provide are quite expansive and do quite a bit. However there is a mismatch on details and gaps. In this case the NT mutex system is 'there' in linux however the way it works is subtly different. You have to basically emulate waitforxxxxxxobject set of windows calls. Getting that right and performant can be quite a challenge.

My particular challenge was similar in around how threads were created destroyed and signals between them (such as mutex). We ended up making our own wrappers to insure the different platforms acted the same. Even something simple as just moving between two supposedly 'same' linux distros could be different depending on what the ODM did to their packages and supported libs. Having a dedicated linux object that acts exactly like the windows one would have made that code much simpler to do.

Another place where there is a huge impedance mismatch is in the permission system. In many ways the VMS/NT way is wildly detailed. Linux can do that but you have to emulate it or use it directly and hope you get it right on both sides. There are several places where windows/linux have the same functionality but the APIs are different enough that multi platform support is kinda awful to do.