181–190 of 512 posts
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…
Earlier quoted context omitted.
So, what's the relationship between Wine and Proton? Is Proton just the SteamOS/Valve name for it, or is it actually it's own project?
More or less Wine + some experimental patches not yet I twgrated in mainstream wine + a buch of DirectX translation libraries + close steam integration.
Earlier quoted context omitted.
> 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…
Sorry I am not sure if 2.12 is a a recent release or older, I made up this number up If the application is built against 2.12 it may link against symbols which are versioned 2.12 and may not work against 2.11 - the opposite (building against 2.11 and running on 2.12) will work >If true (I don't think it is), that is a hard showstopper for most companies that want to develop for Linux. Not really a show stopper, vendo…
that's not correct. libraries have versions for a reason. the only thing preventing the installation of multiple glibc versions is the package manager or the package versioning.
this makes building against an older version of glibc non-trivial, because there isn't a ready made package that you can just install. the workarounds take effort:
https://stackoverflow.com/questions/2856438/how-can-i-link-t...
the problem for companies developing on linux is that it is not trivial
I'll be very interested to see how this plays out with final 3rd-party benchmarks. Now if we can just get some decent Nvidia drivers......
What's wrong with the Nvidia drivers for Linux?
Earlier quoted context omitted.
> It is interesting that these are harder to get working than games. Games are mostly just doing their own thing, only interacting with the system for input & output. MS Office is using every single corner of Windows: every feature in the XML libraries, tons of .NET type stuff, all the OLE and COM and typelib and compound storage features, tons of Explorer integrations, auto-updating stuff via Windows patching mechan…
> Games are mostly just doing their own thing, only interacting with the system for input & output. They should be trivial to port then, no?
Earlier quoted context omitted.
Valve's Proton (so Wine + DXVK + some other additions) revolutionized gaming on Linux. I play games both for fun and work, and for a solid 3+ years now, gaming on Linux has been an "it just works" experience for me, and should be for most games that don't use kernel-level anticheat.
I really is impressive. I wish publishers like EA and anti-cheat developers weren't so reluctant to support it. I hope Steam devices and SteamOS gain enough traction to force their hands.
If you're interested in technical notes on how the WoW64 thing works, I dug into Wine and implemented a similar thing in my (far inferior) emulator and wrote about it here, including some links to some Wine resources: https://neugierig.org/software/blog/2023/08/x86-x64-aarch64....
Nice. Highly complex, I’d be interested in reading more posts on how your emulator works too! FYI the link to the Rosetta branch at the end 404s. Maybe change the point to the main repo?
Is the difference between the NT-style and POSIX-style semaphores essentially just that NT (and now this new API in Linux) supports setting a max value? Why don't POSIX semaphores support this?
WaitForMultipleObjects is fascinating behind the scenes. A single thread can wait on up to 64 independent events, which is done by plumbing the KTHREAD data structure with literally 64 slots for dispatcher header stuff, plus all the supporting Ke/dispatcher logic in the kernel. There’s never been a POSIX equivalent to this. It requires sophisticated kernel support and the exact same parity can’t be achieved in user s…
Earlier quoted context omitted.
You're onto something but that's not entirely true for all games. There's plenty of vintage games, made before DirectX standardized everything into the late 90s, that don't work well under wine because back in their day, they would try to bypass windows by "hacking" their way to the hardware via unsupported APIs and hooks, to squeeze every bit of performance from the hardware, and also because every hardware vendor b…
You mean dos games, just run them under a dos emulator then.
There are the more obvious ones like 3DFX/Glide, but there was also stuff like the Diamond Edge 3D, which used Sega Saturn style "quads".
> Dirt 3 went from 110.6 FPS to 860.7 FPS > Resident Evil 2 jumped from 26 FPS to 77 FPS > Call of Juarez went from 99.8 FPS to 224.1 FPS > Tiny Tina's Wonderlands saw gains from 130 FPS to 360 FPS Amazing. I don't understand the low level details on how such a massive speed gain was ripe for the picking but I welcome! I guess thanks Valve for pouring money into Proton.
Those benchmark numbers are slightly misleading, as they are a comparison of Wine+ntsync against Wine+nothing. There has been a somewhat fast "fsync" library built around Linux's futex and the gains over Wine+fsync are modest (just a few % in most cases). That said, Wine+ntsync is still a win, just not a 8x improvement like the Dirt 3 benchmark suggests. (And it case it's not clear, ntsync is https://docs.kernel.org/…