Linux 6.10 To Merge NTSYNC Driver For Emulating Windows NT Synchronization Primitives

[JEBjames]

Michael

Typo

"WIndows NT synchronization primitives" should be "Windows" (lowercase "i")

[Daktyl198]

Not pointless. If you want to report bugs to Wine, you don't want to dig through some long list of downstream stuff you aren't familiar with and aren't using. And Wine developers aren't happy about bugs reported against some heavily modified forks with who knows what and your kitchen sink attached.

So I use what is strictly necessary like I said above. And then reporting bugs makes sense since you can separate and figure out what goes where.

Proton can be a special case since Proton developers handle bugs against it directly, but I'm not using Steam.

So report the bugs to the upstream of whichever patched-up project you have. Proton, Wine-Staging, TKG, etc all have their own git instances with their own issue boards and bug trackers. Report bugs to them, and if they deem the bug to be a problem with vanilla Wine, they can push the bug report upstream.

As it stands, there's really no reason to use -TKG or -GE. Vanilla Wine, Wine-Staging (which could just be considered a testing repo for Wine) and Proton are pretty much all you need. TKG and GE were always hacks upon hacks meant to just get games working that didn't work with Wine or Proton, and while they "worked" they were nasty workarounds. Now, most games that don't exclude Linux via Anticheat settings work just great under standard Proton, and Proton Experimental is quick to adopt proper fixes to any games that don't work. BDO is a great example of this.

Wine is still not perfect, but afaik TKG doesn't do anything that Staging doesn't do, and Staging patches are much more likely to be upstreamed in the future.

[shmerl]

So report the bugs to the upstream of whichever patched-up project you have

It's not efficient to report bugs to a fork maintained by some small group, especially if it's not clear where the bug is. I'd rather report bugs directly to upstream. Especially since so far I saw no need for any of these forks as I said.

So far I report bugs either to upstream Wine or to vkd3d-proton and dxvk. That's about it in what I want to deal with. vs dealing with a ton of different Wine forks.

[DumbFsck]

As it stands, there's really no reason to use -TKG or -GE. Vanilla Wine, Wine-Staging (which could just be considered a testing repo for Wine) and Proton are pretty much all you need. TKG and GE were always hacks upon hacks meant to just get games working that didn't work with Wine or Proton, and while they "worked" they were nasty workarounds.

Wine is still not perfect, but afaik TKG doesn't do anything that Staging doesn't do, and Staging patches are much more likely to be upstreamed in the future.

micheal would you consider making a few benchmarks of wine, Proton, ge and tkd?

There may be a few percent here and there. Not that I personally care if a game is running at 140 and could be running at 150 or whatever. But it could be interesting to see if there is any performance difference,or if it really is just about compatibility.

And some gamers do care about those 5% here and there.

[ssokolow]

Linux wants so much to be like Windows that it even implements functions with 'deprecated' status like NtPulseEvent() into its kernel.

In the name of compatibility, you gotta do what you gotta do. Microsoft has wanted to get rid of the Win32 API for ages, but developers of killer apps keep forcing their hand.

(As impossible as it is, I'd have found it hilarious if Microsoft was forced to support Windows 7 in perpetuity because the ecosystem collectively chose to fight an active campaign to detect and refuse to run on Windows 10 and above. Can you imagine what it would do if things like Photoshop displayed a "Please downgrade" version of the old "This app requires Windows 95, not Windows NT" messages?)

[rmfx]

Linux wants so much to be like Windows that it even implements functions with 'deprecated' status like NtPulseEvent() into its kernel.

Linux implements NT features because game devs don’t want to/cant’t support the 500 linux distributions in the wild.

Since the kernel is not wasted into 500 different versions like distros are, at least a solution can be offered at the kernel level. It’s not perfect but it for sure helps.

[Isaac Dias]

Linux implements NT features because game devs don’t want to/cant’t support the 500 linux distributions in the wild.

Since the kernel is not wasted into 500 different versions like distros are, at least a solution can be offered at the kernel level. It’s not perfect but it for sure helps.

Don't feed the troll.

[furtadopires]

It's not related to filesystems. It's about process synchronization.

That's awesome then, I will make some tests once 6.10 hit my repositories.

[oiaohm]

Linux implements NT features because game devs don’t want to/cant’t support the 500 linux distributions in the wild.

Please remember Valve provides the steam runtimes so games don't need to-do that. Games only need to support the steam runtime to run basically on any Linux distribution as a fairly much native Linux application(as native as a flatpak).

There are other factors here. Like the current Linux 64 bit kernel still support 16bit protected mode for no other reason than for wine to run win16 applications.

Next factor companies like valve have indefinite licenses to sell lots of retro games(think old games) these old games are not like modern ones where maker kills the server and you lose the game so there is no issue selling them but the programmer and the source code they are made from are no longer around in many cases. Yes some of the games valve sells the programmer has been 6 feet under for over a decade..

https://store.steampowered.com/app/9180/Commander_Keen/

Starting January 1st, 2024, the Steam Client will only support Windows 10 and later versions.

As you go to run these retro games you run into the follow problem. Steam client only support Windows 10 or newer on windows you need the steam client to download the game and the game without messing about due to some changed API will not run under Windows 10.

Yes it coming the reality you wish to run these older titles you will be installing Linux because Linux has the legacy windows API support the games and OS modern enough that steam client is happy. Yes fun steam client not working on the OS the game that is steam store needs.

[plandream]

Please remember Valve provides the steam runtimes so games don't need to-do that. Games only need to support the steam runtime to run basically on any Linux distribution as a fairly much native Linux application(as native as a flatpak).

There are other factors here. Like the current Linux 64 bit kernel still support 16bit protected mode for no other reason than for wine to run win16 applications.

Next factor companies like valve have indefinite licenses to sell lots of retro games(think old games) these old games are not like modern ones where maker kills the server and you lose the game so there is no issue selling them but the programmer and the source code they are made from are no longer around in many cases. Yes some of the games valve sells the programmer has been 6 feet under for over a decade..

https://store.steampowered.com/app/9180/Commander_Keen/

As you go to run these retro games you run into the follow problem. Steam client only support Windows 10 or newer on windows you need the steam client to download the game and the game without messing about due to some changed API will not run under Windows 10.

Yes it coming the reality you wish to run these older titles you will be installing Linux because Linux has the legacy windows API support the games and OS modern enough that steam client is happy. Yes fun steam client not working on the OS the game that is steam store needs.

It has been like that for years. If you have the original disc, it's so much easier to run on wine, rather a recent version of windows.