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

101–110 of 512 posts

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

#101

Post by anthk »

nurettin wrote: post #62
irishcoffee wrote: post #46

Earlier quoted context omitted.

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

I met someone who bit shifts for life, uses opengl shaders for compute, but has no sql experience and is afraid of opening a tcp socket.

Trivial under plan9/9front. Under Win32/POSIX, run way.

On bit shifts, pick any Forth programmer and shaders will be almost like a toy for them. They are used to implement double numbers (and maybe floats) themselves by hand by just reusing the only integer numbers they have and writting custom commands to output these pairs of integer as double numbers. They can probably implement multithreading processing by hand in Forth and also know the IEEE standards for floats better than C programmers over 20 years.

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

#102

Post by kelnos »

akdev1l wrote: post #35
krastanov wrote: post #8

Earlier quoted context omitted.

Wine's APIs are more stable than Linux's APIs, so it seems more plausible to me that Wine will become the first class target itself.

People always say this to shit on glibc meanwhile those guys bend over backwards to provide strong API compatibilities. It rubs me off the wrong way. What glibc does not provide is forward compatibility. An application built with glibc 2.12 will not necessarily work with any older version. Such application could be rebuilt to work with an older glibc as the API is stable. The ABI is not which is why the application w…

> What glibc does not provide is forward compatibility. An application built with glibc 2.12 will not necessarily work with any older version.

Is this correct? I think you perhaps have it backward? If I compile something against the glibc on my system (Debian testing), it may fail to run on older Debian releases that have older glibc versions. But I don't see why an app built against glibc 2.12 wouldn't run on Debian testing. glibc actually does a good job of using symbol versioning, and IIRC they haven't removed any public functions, so I don't see why this wouldn't work.

More at issue would be the availability of other dependencies. If that old binary compiled against glibc 2.12 was also linked with, say, OpenSSL 0.9.7, I'd have to go out and build a copy of that myself, as Debian no longer provides it, and OpenSSL 3.x is not ABI-compatible.

> glibc does not provide ABI compatibility because from their perspective the software should be rebuilt for newer/older versions as needed.

If true (I don't think it is), that is a hard showstopper for most companies that want to develop for Linux. And I wouldn't blame them.

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

#103

Post by kelnos »

thescriptkiddie wrote: post #81
charcircuit wrote: post #61

Earlier quoted context omitted.

No other operating system works like this. Supporting older versions of an OS or runtime with a compiler toolchain a standard expectation of developers.

what about mac os?

macOS doesn't require developers to rebuild apps with each major OS release, as long as they link with system libraries and don't try to (for example) directly make syscalls.

Apple may require rebuilds at some point for their Mac Store (or whatever they call it), but it's not required from a technical perspective.

The one exception here is CPU architecture changes, and even then, Apple has provided seamless emulation/translation layers that they keep around for quite a few years before dropping support.

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

#104

Post by wishfish »

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.

Not only do the CRUDs have value but they're good for your sanity. I knew a guy back in the dot-com era. Very skilled coder. Backbone of the company. He pulled off miracles. Fulfilled impossible deadlines. Then one day, out of the blue, he quit. Took a job at a non-technical corp. They put him in a cubicle where he wrote Visual Basic CRUDs on an 8-5 schedule. No weird deadlines, no sleeping under the desk. He called it his paid vacation.

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

#105

Post by anthk »

bombcar wrote: post #63
chistev wrote: post #51

Earlier quoted context omitted.

Really?

I know literal kernel developers who can handle drivers and race conditions any day of the week who can't wrap their mind around Outlook, let alone GUI updates.

Myself. Forth it's easy, 9front C it's manageable but POSIX it's hell and managing both Unix descendants are a piece of cake.

GUI interfaces for the enterprise came from Dante's hell themselves. I hate them, they are like the Madhouse from that Asterix movie making satire of the European bureucracy of the day. The often are oddly designed and they are not documented at all, you must guess the meaning by chance of with a senior tutoring you.

The same with anything corporate from Microsoft with AD roles/group policies and the like. Or anything coming from IBM.

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

#106

Post by TheCycoONE »

LtWorf wrote: post #64
orbital-decay wrote: post #21

Earlier quoted context omitted.

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

People who keep parroting this clearly have no experience of gaming on linux.

Are you able to run any of the old Loki games on Linux these days?

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

#107

Post by MisterTea »

pdpi wrote: post #75
hxorr wrote: post #53

Earlier quoted context omitted.

ReactOS also deserves an honorary mention. A lot of knowledge from that project feeds into Wine.

And vice-versa. It's pretty interesting that the two projects haven't kind of merged despite all the collaboration.

Very different projects so I would not encourage a merge but sharing a code base? I can totally see that being a boon for both and other Windows emulation projects.

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

#108

Post by krastanov »

akdev1l wrote: post #35
krastanov wrote: post #8

Earlier quoted context omitted.

Wine's APIs are more stable than Linux's APIs, so it seems more plausible to me that Wine will become the first class target itself.

People always say this to shit on glibc meanwhile those guys bend over backwards to provide strong API compatibilities. It rubs me off the wrong way. What glibc does not provide is forward compatibility. An application built with glibc 2.12 will not necessarily work with any older version. Such application could be rebuilt to work with an older glibc as the API is stable. The ABI is not which is why the application w…

I am sorry, I did not mean to imply anyone else is doing something poorly. I believe glibc's (and the rest of the ecosystem of libraries that are probably more limiting) policies and principled stance are quite correct and overall "good for humanity". But as you mentioned, they are inconvenient for a gamer that just wants to run an executable from 10 years ago (for which the source was lost when the game studio was bought).

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

#109

Post by kelnos »

akdev1l wrote: post #66
charcircuit wrote: post #61

Earlier quoted context omitted.

No other operating system works like this. Supporting older versions of an OS or runtime with a compiler toolchain a standard expectation of developers.

Plenty of operating systems work like this. Just not highly commercial ones because proprietary software is the norm on those. From a bit of research it looks like FreeBSD for example only provides a stable ABI within minor versions and I imagine if you build something for FreeBSD 14 it won’t work on 13. Stable ABI literally only benefits software where the user doesn’t have the source. Any operating system which ass…

Yes, and this is a great reason why FreeBSD isn't a popular gaming platform, or for proprietary software in general. I'm not saying this is a bad thing, but... that's why.

> Stable ABI literally only benefits software where the user doesn’t have the source.

It also benefits people who don't want to have to do busywork every time the OS updates.

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

#110

Post by kelnos »

yjftsjthsd-h wrote: post #22
dinkblam wrote: post #3

it seems if you want the same on macOS, this is the place to contribute: https://github.com/Alien4042x/Wine-NTsync-Userspace-macOS-ba...

That's interesting. I thought the point was that it needed to be in-kernel for performance reasons; if it works in userspace why did linux not do that?

Ideally it does need to be in-kernel for performance reasons. But that's not possible on macOS, so it's better to have it in userspace than not at all.
Post reply on HN