Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Wine 11 rewrites how Linux runs Windows games at kernel with massive speed gains

xda-developers.com

Post reply on HN
Print view View original

41–50 of 512 posts

Re: Wine 11 rewrites how Linux runs Windows games at kernel with massive speed gains

#41

Post by akdev1l »

orbital-decay wrote: post #21
ticulatedspline wrote: post #4

Wine might be oddly self-defeating. Broad game support on Linux increases the viability of Linux as a desktop, which increases market share, which may result in developers creating Linux ports as a 1st class concern, which don't need Wine to run.

Unlikely. Games need a stable ABI and Win32 is the only stable ABI on Linux.

Proprietary software needs a stable ABI. Not games.

DOOM runs on any Linux system since forever because we had access to the source. You can build it for Linux 2.6 and it’ll probably still work today.

Sadly most games are proprietary

Re: Wine 11 rewrites how Linux runs Windows games at kernel with massive speed gains

#42

Post by foresto »

akdev1l wrote: post #25
watashiato wrote: post #19

Before anyone gets too excited about ntsync, the performance gains are (with few exceptions) mild, usually in the lower single percentage range. These extreme gains are the result of benching against vanilla wine without fsync, anyone playing demanding games on linux would have been doing so using fsync. This is mentioned in the article but treated like a side note. I've been running benchmarks between both and while…

>These extreme gains are the result of benching against vanilla without fsync, which is what anyone gaming on linux uses Not for anyone using a kernel without these patches. Which would be most people.

Most people? What mainstream Linux distros ship without fsync or esync support?

Re: Wine 11 rewrites how Linux runs Windows games at kernel with massive speed gains

#44

Post by zerr »

adelmotsjr wrote: post #5

Reading these posts always make me feel like an imposter. People are dealing with such low level things, while i'm outta here building simple CRUDs.

The grass is always greener on the other side - many low-level programmers feel like an imposter when it comes to high-level systems such as CRUD apps.

Re: Wine 11 rewrites how Linux runs Windows games at kernel with massive speed gains

#46

Post by irishcoffee »

zerr wrote: post #44
adelmotsjr wrote: post #5

Reading these posts always make me feel like an imposter. People are dealing with such low level things, while i'm outta here building simple CRUDs.

The grass is always greener on the other side - many low-level programmers feel like an imposter when it comes to high-level systems such as CRUD apps.

They don't. The "simplicity" of using a "high-level" framework for someone who bit-shifts for a living is almost comical.

Re: Wine 11 rewrites how Linux runs Windows games at kernel with massive speed gains

#47

Post by duskwuff »

porphyra wrote: post #39
TehCorwiz wrote: post #10

Earlier quoted context omitted.

I wouldn't be surprised if Wine eventually becomes more stable than Windows.

Wine actually does run some ancient Windows games better than Windows 11 itself.

It certainly runs 16-bit Windows games better than Windows 11, which can't run them at all. Not that there are a ton of those, but it's still pretty neat that they work.

Re: Wine 11 rewrites how Linux runs Windows games at kernel with massive speed gains

#48

Post by akdev1l »

foresto wrote: post #42
akdev1l wrote: post #25

Earlier quoted context omitted.

>These extreme gains are the result of benching against vanilla without fsync, which is what anyone gaming on linux uses Not for anyone using a kernel without these patches. Which would be most people.

Most people? What mainstream Linux distros ship without fsync or esync support?

Well I can tell you that if it didn’t make it upstream Fedora didn’t ship it.

It looks there was a copr for a custom kernel-fsync and projects like Bazzite or Nobara are adding patches.

From my understanding the fsync patches were never upstreamed.

Re: Wine 11 rewrites how Linux runs Windows games at kernel with massive speed gains

#49

Post by dgunay »

adelmotsjr wrote: post #5

Reading these posts always make me feel like an imposter. People are dealing with such low level things, while i'm outta here building simple CRUDs.

You can probably learn to do these things too with enough determination, but don't sell yourself short. Some CRUD apps can get deceptively complicated. Businesses have a way of coming up with just the right requirements to completely invalidate your architecture if you don't know what you're doing.

Re: Wine 11 rewrites how Linux runs Windows games at kernel with massive speed gains

#50

Post by keyringlight »

carlos_rpn wrote: post #26
TehCorwiz wrote: post #10

Earlier quoted context omitted.

I wouldn't be surprised if Wine eventually becomes more stable than Windows.

It feels like it won't be long before Microsoft starts helping with that (by making Windows less stable, not improving Wine).

What I wonder about is if MS wants to keep people on windows, what methods they can use to do that. For simple desktop stuff I don't think they have many options to lock in other developers (and their audiences) to windows unless they want do so themselves (putting aside web based or not PC-desktop).

Bleeding edge gaming and multiplayer anti-cheat is one area where I think having a big company owning the OS probably helps them stay ahead, as that structure probably lets them work with hardware designers to get the capabilities in use (i.e. in new versions of DirectX) and available to software developers first. There's generally a lag in adoption for new features within Vulkan and then usage downstream in wine/proton to get compatibility parity with windows, then the games themselves being able to run feature/performance parity. It'd be interesting to see what cooperation would be needed to have the linux gaming stack equal at the point new features are released, and with the least amount of manual hacks or command line tweaking required for the users. As discussed a few weeks back, tough anti-cheat for linux seems like a paradox with the current methods.

Post reply on HN