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

221–230 of 512 posts

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

#221

Post by jdpage »

kelnos wrote: post #102
akdev1l wrote: post #35

Earlier quoted context omitted.

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…

I don't know what the official policy is, but glibc uses versioned symbols and certainly provides enough ABI backward-compatibility that the Python package ecosystem is able to define a "manylinux" target for prebuilt binaries (against an older version of glibc, natch) that continues to work even as glibc is updated.

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

#222

Post by dingdingdang »

rhdunn wrote: post #56
tombert wrote: post #16

Wine is a project that I've grown a near-infinite level of respect for. I don't know for sure, but I suspect that a lot of the work for Wine is boring and thankless. Digging through and trying to get exact parity with both the documented and undocumented behavior of Windows for the past 30 years doesn't sound fun, but it's finding every little weird edge case that makes Wine a viable product. The fact that Wine runs…

Wine has a lot of tests that are run across platforms to check conformance -- https://test.winehq.org/data/ . These are a large part of why it has good compatibility.

With this exact point in mind: I've recently written a pretty straight forward win32 c implementation of a utility with some context dependent window interactions and a tray icon to help monitor and facility reload of config file.

Is there any way I can use the Wine project to facilitate this compiling and running straight under x11/linux environment as a integrated project that doesn't require the end user to fiddle with Wine? I don't mind bundling shared code as needed. Help appreciated, I tried hard and failed at this endeavour priorly.

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

#223

Post by Levitating »

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 personally believe we should just compile games statically. Problem solved, right?

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

#224

Post by rounce »

Night_Thastus wrote: post #184
k33n wrote: post #45

Earlier quoted context omitted.

What's wrong with the Nvidia drivers for Linux?

They're garbage. They're bad enough that If you have an Nvidia GPU, it's borderline impractical to game on Linux. You can, but you'll be cutting framerates in half or more in many cases.

That’s a wild exaggeration. Yes they underperform relative to the Windows drivers but my experience is far from “cutting framerates in half” nor “borderline impractical”. I’ve had the last four generations of Nvidia card (currently on 5070Ti) on Linux and played demanding games just fine.

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

#225

Post by bombcar »

jordand wrote: post #54
LetsGetTechnicl wrote: post #43

This is such an amazing accomplishment! Absolutely wild to see Linux basically re-implement Windows and doing it better, while MS is dead set on making everything about their software worse.

The full 16bit support here is a big thing especially given 64bit Windows (now everywhere) dropped it. With old games, there's thousands that are 16bit, and even odd cases where the game is 32bit but the installer for it is 16bit.

The WoW64 including 16 bit support is actually pretty big. Microsoft dropped it years ago.

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

#226

Post by timacles »

anthk wrote: post #105
bombcar wrote: post #63

Earlier quoted context omitted.

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 wit…

lol you guys are being too nice. Building CRUD apps is just implementing business logic by gluing APIs together, there is nothing to understand except the business domain, which is only done through exposure, because business logic is random. And then the APIs which are all essentially a kludge because of the shifting business logic.

Understanding low level code puts you on entirely different level because you can reason about a problem using logic and how systems operate.

No disrespect to any crud devs here but from my personal experience they just know a particular implementation of their domain and rarely even consider how the code base even operates as a whole

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

#227

Post by jsLavaGoat »

sneak wrote: post #219
tombert wrote: post #16

Wine is a project that I've grown a near-infinite level of respect for. I don't know for sure, but I suspect that a lot of the work for Wine is boring and thankless. Digging through and trying to get exact parity with both the documented and undocumented behavior of Windows for the past 30 years doesn't sound fun, but it's finding every little weird edge case that makes Wine a viable product. The fact that Wine runs…

It’s astounding how badly Microsoft had to fumble their complete and unassailable monopoly on the standard video game runtime (ie Windows) for an upstart like Valve to be able to get WINE/Proton into a place where this is now possible. The mind reels. They had the biggest moat in tech, and now small shops are easily tossing homemade ladders across the gap. AAA gaming is an industry larger than all of Hollywood, and W…

There are huge swaths of workplaces that run on Google Docs. If you're using features of Excel and PowerPoint that doesn't work on Docs (except maybe fonts), it might be fair to say you're the one with the incompatible doc these days. K-12 education would be one such world.

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

#228

Post by topspin »

lifis wrote: post #175
topspin wrote: post #145

Earlier quoted context omitted.

> It seems like it would be possible to implement this in userspace using shared memory It is not. Perhaps this should be possible, but Linux doesn't provide userspace facilities that would be necessary to do this entirely in userspace. This is not merely an API shim that allows Windows binary object to dynamically link and run. It’s an effort to recreate the behavior of NT kernel synchronization and waiting semantic…

The code doesn't really seem to use any kernel functionality other than spinlocks/mutexes and waiting and waking up tasks. That same code should be portable to userspace by: - Allocating everything into shared memory, where the shared memory fd replaces the ntsync device fd - Using an index into a global table of object pointers instead of object fds - Using futex-based mutexes instead of kernel spinlocks - Using a f…

People such as Figura and Bertazi have been attempting to do what you propose for most of a decade now[1]. They've ended up with this, after two previous implementations running in Wine for many years. Thier reasons are explained in their documentation[2]. Perhaps you know better. We all look forward to your work.

[1] https://lkml.org/lkml/2019/7/30/1399 [2] https://docs.kernel.org/userspace-api/ntsync.html

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

#229

Post by simonask »

MindSpunk wrote: post #205
Rohansi wrote: post #177

Earlier quoted context omitted.

Yes, they are easy to port a lot of the time. Especially now because you can use DXVK to translate DirectX calls into Vulkan, so you don't need to write a Vulkan renderer. Input is sometimes a trickier one to deal with but a lot of the time games are using cross-platform libraries for that already! Despite all this the Unity engine has spotty Linux support. Some games run better under Wine vs. Unity's native Linux bu…

The hard part of Linux ports isn't the first 90% (Using the Linux APIs). It's the second 90%. Platform bugs, build issues, distro differences, implicitly relying on behavior of Windows. It's not just "use Linux API", there's a lot of effort to ship properly. Lots of effort for a tiny user base. There's more users now, but proton is probably a better target than native Linux for games.

It’s not really about OS differences - as the GP said, games don’t typically use a lot of OS features.

What they do tend to really put a strain on is GPU drivers. Many games and engines have workarounds and optimizations for specific vendors, and even driver versions.

If the GPU driver on Linux differs in behavior from the Windows version (and it is very, very difficult to port a driver in a way that doesn’t), those workarounds can become sources of bugs.

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

#230

Post by garaetjjte »

lifis wrote: post #77

It seems like it would be possible to implement this in userspace using shared memory to store the data structures and using just one eventfd per thread to park/unpark (or a futex if not waiting for anything else), which should be fully correct and have similar or faster performance, at the cost of not being secure or robust against process crashes (which isn't a big problem for more Wine usage). It seems that neithe…

> 3. WHY IT CAN'T BE DONE WITH EXISTING TOOLS

https://lore.kernel.org/lkml/f4cc1a38-1441-62f8-47e4-0c67f5a...

Post reply on HN