Proton is both a friendly fork of Wine + a wrapper around Wine + forks of libraries and tools used by both Wine & Proton. Some of the forks are more blessed & tested versions than forks.

Source is here: https://github.com/ValveSoftware/Proton

Notice that includes a lot of git submodules; the big one is Wine, but it also includes forks of dependencies such as ffmpeg.

I don't know what they did exactly, but it sounds way, way better than regular Wine. Like, it's a coin toss whether a game works in regular Wine at all, and another coin toss for whether it works well. Even the Steam client is ultra glitchy in Wine. Which makes sense, it's really hard to emulate a Windows environment.

Wine is major part of Proton, so if it works on proton it's usually possible to get it working on wine. (Changes to Proton branch of wine are regularly incorporated back into Wine).

What proton is - its a tested distribution of wine and its libraries AND nice wrapper around wine, that helps setting everything up so it just works.

If you want to get games working on linux, proton is the easiest and best way to go. But if you want to get some of the programs running, that are not supported under proton, wine might work.

Ok. So when I'm having issues with a game, probably I'm missing whatever version of a lib I need, or running Wine on M1 Mac is bringing its own challenges.

Steam does a few things at once to make this system work so well. There's just Wine itself and Valve-sponsored work and improvements to it, the automatic usage of DXVK and similar newer translation-to-Vulkan systems for DirectX support vs. Wine's classic alternatives, there's Steam automatically creating wine prefixes per-game, there's a separate but related container system, the "Steam Linux Runtime" that allows both Proton and native Linux games to have a stable, known set of libraries to target and support vs. the dizzying array of distributions and versions that otherwise typifies supporting Linux.

On the other hand, having that corporate support and isolation from the system sometimes cuts both ways: stock Proton often has worse support for audio and video codecs than a classic Wine install with the proper system libraries, because Valve actually has to worry about patents and licensing for them. They've come up with a system where the layer they otherwise use for sharing cached shaders can also share transcoded media files, but it's not always a seamless experience.

tbf what makes proton unique is that they mostly not use forks and instead work with upstream and just pin point their dependencies and use cherry-pick after they forked a major.

What does "fork of wine" mean concretely? As in, what does Proton give me that Wine doesn't? The way you make it sound is that it's a "Wine distribution"; is that correct? Or does it do more?

It's not really a fork, more like a distribution as you might be familiar with it, or built on top of Wine. Without Wine, there probably wouldn't have been any Proton.

I think parent mean "fork" in the strict sense that there are two source codes "versions" of Wine: upstream, which is the official wine you get when doing `apt-get install wine`, `pacman -Ss wine` or whatever. Then there is Valves own clone of that same codebase, but with additional patches on top of it. Many changes are game specific, at least in the beginning, but many are also generalized and eventually "upstreamed" to the official Wine repository.

So in a way, they maintain their own fork with their own set of patches, and some of those patches makes their way to the "original" Wine while some don't.

Integer upscaling, for a start.