[HN Gopher] Wine 11 rewrites how Linux runs Windows games at ker...
___________________________________________________________________
Wine 11 rewrites how Linux runs Windows games at kernel with
massive speed gains
Author : felineflock
Score : 1208 points
Date : 2026-03-24 18:34 UTC (1 days ago)
(HTM) web link (www.xda-developers.com)
(TXT) w3m dump (www.xda-developers.com)
| kapija wrote:
| awesome, finally wine is getting proper ntsync support... and i
| reckon wow64 will let me run so many old games...
| dinkblam wrote:
| it seems if you want the same on macOS, this is the place to
| contribute:
|
| https://github.com/Alien4042x/Wine-NTsync-Userspace-macOS-ba...
| yjftsjthsd-h wrote:
| 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?
| kelnos wrote:
| 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.
| hungryhobbit wrote:
| But does anyone _care_ about MacOS? ;)
|
| I mean, I know Mac has had some great games (eg. I spent so
| much time on school Macs playing that Bolo tank game) ... but
| they have probably <1% of the number of games Windows has. I'd
| expect a simiilar percentage of devs to be interested in Mace
| (or whatever you call Mac Wine).
| kelnos wrote:
| Not sure what you mean. The number of Mac games isn't
| relevant to a subthread about a project to increase
| performance when Windows games on Mac.
| ticulatedspline wrote:
| 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.
| jfaulken wrote:
| This is the very definition of "a good problem to have."
| p_ing wrote:
| OS/2 part deux
| ssl-3 wrote:
| Sorta, kinda, but not really.
|
| OS/2 may have been a better Windows than Windows during the
| Warp days 30-ish years ago. It was also a very competent
| operating system in its own right.
|
| We all know the story:
|
| It never had a broad base of native applications. It could
| have happened, but it did not happen. Like, back then when
| Usenet was the primary way of conducting written online
| discourse, the best newsreader I had on OS/2 was a Windows
| program; the ones that ran natively on OS/2 weren't even
| _close_.
|
| And OS/2 never had support from a popular company. There were
| times at OS/2's peak (such as it was) when it was essentially
| impossible to buy a new computer with OS/2 pre-installed and
| working correctly _even from IBM_.
|
| Linux, though? Over those same 30-ish years, a huge amount of
| native applications have been written. Tons of day-to-day
| stuff can be done very well in Linux without even a hint of
| Wine and that's been reality for quite a long time now.
|
| The missing piece, if there is one, is gaming. It'd be great
| to have more native games and fewer abstraction layers. But
| systems like Valve's popular Steam Deck and upcoming Steam
| Machine are positive aspects that OS/2 never had an
| equivalent to. And since Steam is very nearly ubiquitous,
| companies that sell computer game software _do_ pay attention
| to what Valve is doing in this space.
|
| (And frankly, when a game runs great in some
| Steam/Wine/Proton/Vulkan shapeshifting slime mold abstraction
| stack, I really do not care that it isn't running natively. I
| push the button and receive candy.)
| krastanov wrote:
| 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.
| TehCorwiz wrote:
| I wouldn't be surprised if Wine eventually becomes more
| stable than Windows.
| carlos_rpn wrote:
| It feels like it won't be long before Microsoft starts
| helping with that (by making Windows less stable, not
| improving Wine).
| keyringlight wrote:
| 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.
| mschuster91 wrote:
| > What I wonder about is if MS wants to keep people on
| windows, what methods they can use to do that
|
| Microsoft doesn't give a fuck about private customers any
| more. They don't have money.
|
| What has money though is enterprise/government sales, and
| MS got these customers tightly locked in. Compliance
| audits and tooling for insurances or legal stuff (SOX,
| GDPR, ...) are _built_ against a full Microsoft stack of
| MS Server, Active Directory, Azure, Teams, Office 365 and
| Windows desktops.
|
| You might be able to get away with replacing AD and GPO
| with Samba servers but even that is already a pain when
| the auditors come knocking. Everything else? There is
| _no_ single FOSS based "standard offering" (i.e. a
| combination of everything needed to run an on-prem
| enterprise site, Office replacement, remote collaboration
| tooling), so every audit for such setups must be custom
| made and involves a lot of extra work.
|
| A second leg is industrial control machines, medical
| devices and the likes. That's all stuff built by third
| party vendors and integrators. They need to continue on
| Windows because switching to an alternative OS would
| require redoing _everything_ from scratch on the software
| and certification side. These customers buy the LTSC IoT
| stuff.
|
| And that is why you see Microsoft pushing
| enshittification so hard on private customers... extract
| the last few cents you can from them. But the real money
| comes from the large customers.
| porphyra wrote:
| Wine actually does run some ancient Windows games better
| than Windows 11 itself.
| duskwuff wrote:
| 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.
| senfiaj wrote:
| 16-bit software won't run natively in 64-bit mode. It
| requires some programmatic emulator, like DosBox. Or am I
| missing something?
| simoncion wrote:
| The thing that you're missing is that Microsoft used to
| ship that emulator with Windows. Then they stopped doing
| that.
|
| AFAICT, Wine can run WIN16 programs. I don't know if it
| can run DOS programs. There's a WineHQ wiki page that
| says it can _load_ DOS programs, but various internet
| fora seem to believe that Wine 's DOS support is pretty
| broken. I've never tried it, and have no DOS programs
| handy, so I can't verify those claims.
| duskwuff wrote:
| "DOS support" is tricky inasmuch as a lot software from
| that era - especially larger and more complex packages -
| interacted with hardware directly. In a sense, they
| weren't really DOS applications so much as they were
| bare-metal PC applications which were booted from DOS.
| It'd be difficult for WINE to support those, and other
| projects like DOSbox / 86box / etc do a better job of it.
| consp wrote:
| Time to dust off my cd copy of Stars! (From the disk
| backup, the cd had terminal illnesses and has died). The
| only win16 game I've ever seen distributed on CDROM. Wine
| already ran it ok (iirc there were some issues but
| nothing gamebraking), but now it can do so without i386
| libs.
| anthk wrote:
| Anything Direct Draw related will be mapped into OpenGL
| under Unix giving you decent speeds. On Windows it will
| be a crawling slideshow because from Windows 8 and up it
| will use a really dog slow software mode with no
| acceleration at all, worse than plain VESA. Yes, you can
| reuse WineD3D DLL's on Windows and run these game in a
| fast way, but not by default, it's a Win32 port of some
| Wine libraries.
| rescbr wrote:
| Once I had to use a Mesa3D build for Windows and use the
| zink driver to render OpenGL to Vulkan, otherwise it
| would use Windows' software renderer.
| anthk wrote:
| I had to use WineD3D's ddraw.dll among another one to run
| these touch based arcade machine games with card games,
| Trivial Pursuit, hangman and the like. If not the game
| made for w98/2k would really lag even under an i3.
|
| The same with some multimedia CD's from its day. Scummvm
| it's partially implementing Macromedia Director support
| but the mentioned game had a custom engine. The Scummvm
| devs would RE in few weeks (it's a simple 2D game bundle,
| nothing difficult, with virtually no animations, almost
| everything it's still images) but no one began yet.
| zadikian wrote:
| Wine is also the reason why Windows software has more
| longevity on Mac than Mac software. Like, 32-bit didn't
| get deprecated in Wine.
| beAbU wrote:
| Not just ancient games!
|
| https://arstechnica.com/gaming/2025/06/games-run-faster-
| on-s...
| wing-_-nuts wrote:
| MS got such a black eye for that that they're developing
| a build of windows specifically for handhelds, optimized,
| without the bloat and power hungry extras. Would be nice
| if it ran on laptops
| Aerroon wrote:
| Windows 14 will just be a linux distro with wine acting as
| backwards compatibility.
| voodooEntity wrote:
| Inb4 Windows 40k and to run the "kernel" you need to
| sacrifice 1000 a day
| beAbU wrote:
| By the time we get to version 40k the kernel will just be
| AI hallucinating a UI for you at 60fps.
|
| Secondly, I do acknowlege your 40k reference.
| pjmlp wrote:
| Why would Microsoft ever do that?
|
| WSL is already there for the folks that want to play with
| Linux.
| alexrp wrote:
| I've experienced multiple instances where (so I heard; I
| don't use Windows) a Windows Update completely broke a game
| on Windows for everyone, but Wine/Proton kept running it
| just fine. So we're already there in some sense.
| wing-_-nuts wrote:
| I remember when the shader caching done for a popular
| game in linux made that game run better than the windows
| version
| _flux wrote:
| What I'd like to see would be some useful extra APIs in Wine,
| that would allow it to perform even better in some
| situations, and that such APIs would be then embraced by the
| game developers.
|
| Finally some embrace, extend, and extinguish love right back
| at Microsoft!
| zerocrates wrote:
| Building against the Steam runtime containers seems like the
| other route, which also gets you more stability.
| akdev1l wrote:
| 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 would need to be rebuilt.
|
| glibc does not provide ABI compatibility because from their
| perspective the software should be rebuilt for newer/older
| versions as needed. Maintaining a stable ABI mostly helps
| proprietary software where the source is not available for
| recompilation. Naturally the gnu guys building glibc don't
| care about that use case much.
|
| I guess you didn't mention glibc in your comment but I
| already typed this out
| charcircuit wrote:
| No other operating system works like this. Supporting older
| versions of an OS or runtime with a compiler toolchain a
| standard expectation of developers.
| akdev1l wrote:
| 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
| assumes you have the source will not prioritize it.
|
| (Edit: actually thinking harder MacOS/iOS is actually
| much worse on binary compatibility, as for example Intel
| binaries will stop working entirely due to M-cpu
| transition - Apple just hits developers with a stick to
| rebuild their apps)
| kelnos wrote:
| 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.
| toast0 wrote:
| FreeBSD isn't _too_ bad, you can build /install compat
| packages back to FreeBSD 4.x, and I'd expect things to
| largely work. At previous jobs we would mostly build our
| software for the oldest FreeBSD version we ran and
| distribute it to hosts running newer FreeBSD releases and
| outside some exceptional cases, it would work. But you'd
| have to either only use base libraries, or be careful
| about distribution of the libraries you depend on. You
| can't really use anything from ports, unless you do the
| same build on oldest and distribute plan.
|
| At Yahoo, we'd build on 4.3-4.8, and run on 4.x - 8.x. At
| WhatsApp, I think I remember mostly building on 8.x and
| 9.x, for 8.x - 11.x. The only thing that I remember
| causing major problems was extending the bitmask for CPU
| pinning; there were a couple updates where old software +
| old kernel CPU pinning would work, and old software + new
| kernel CPU pinning failed; eventually upstream made that
| better as long as you don't run old software on a system
| with more cores than fit in the bitmask. I'm sure there
| were a few other issues, but I don't remember them ...
| charcircuit wrote:
| You can still run x86 binaries on new macbooks. They
| don't stop working entirely. Using wine I can even run
| x86 windows binaries.
| akdev1l wrote:
| They announced Rosetta 2 will be deprecated and
| eventually removed (MacOS 28?)
|
| By that point they already hit the developers enough to
| get them to port to aarch64
|
| (arguably though this could be a special case because it
| is due to architectural transition)
| littlecranky67 wrote:
| Apple said they will keep Rosetta 2 for select usecases,
| such as gaming. They do have a user base that uses Steam
| and bought mac games - without rosetta that would mean
| the users could no longer play their game. And no one
| ports 5-10year old games.
| wing-_-nuts wrote:
| Can one run a windows version of a game well over on say,
| a MBP?
|
| I ask because my current laptop is getting long in the
| tooth, and if I were just buying it for productivity
| stuff, the current MBPs are _beasts_ , but last time I
| checked years ago, gaming on os x was in a sad state,
| even compared to linux.
| throwaway2046 wrote:
| > Stable ABI literally only benefits software where the
| user doesn't have the source
|
| Stable ABI benefits everyone. If I need to recompile a
| hundred packages with every OS update instead of doing
| real work then there's something seriously wrong with my
| OS.
| thescriptkiddie wrote:
| what about mac os?
| kelnos wrote:
| 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.
| charcircuit wrote:
| The latest Xcode supports targeting back to macOS 11.
| This covers >99% of macs which is acceptable for most
| developers.
|
| https://developer.apple.com/support/xcode/
| kelnos wrote:
| > _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.
| akdev1l wrote:
| 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, vendors just do what vendors
| do and bundle all their dependencies in. Similar to
| windows when you use anything outside of the win32 API.
|
| The only problem with this approach is that glibc cannot
| have multiple versions running at once. We have "fixed"
| this with process namespaces and hence containers/flatpak
| where you can bundle everything including your own glibc.
|
| Naturally the downside is that each app bundles their own
| libraries.
| em-bee wrote:
| _The only problem with this approach is that glibc cannot
| have multiple versions running at once_
|
| 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
| seba_dos1 wrote:
| You compile in a container/chroot with the userspace you
| target. Done.
|
| In the context of games, that will likely be Steam
| Runtime.
| em-bee wrote:
| it's not that simple. you want to be able to use a modern
| toolchain (compilers that support the latest standards)
| but build a binary that runs on older systems.
|
| the only way to achieve that is to get the older
| libraries installed on a newer system, or you could try
| backporting the new toolchain to the older system. but
| that's a lot harder.
| seba_dos1 wrote:
| It may be hard-ish, sometimes. Sometimes it's a breeze.
| And sometimes you can just use host's toolchain with
| container's sysroot and proceed as if you were cross-
| compiling. Most of the time it's not a big deal.
| akdev1l wrote:
| glibc must match the linker so you would need a separate
| linker and the binaries usually have a hardcoded path to
| the system linker (and you need to binary patch the stuff
| - https://stackoverflow.com/questions/847179/multiple-
| glibc-li...)
|
| So in practice you can only have 1 linker, 1 glibc
| (unless you do chroot or containers and at that point
| just build your stuff in Ubuntu 12.04 or whatever
| environment)
| jdpage wrote:
| 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.
| SAI_Peregrinus wrote:
| MUSL is a better libc for companies making proprietary
| binaries. They can either statically link it, or provide
| a .so with the musl version they want their programs to
| use & dynamically link that.
| krastanov wrote:
| 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).
| em-bee wrote:
| that 10 year old binary should run, unless it links
| against a library that no longer exists.
|
| for example here is a 20 year old binary of the game
| mirrormagic that runs just fine on my modern fedora
| machine: ~/Downloads/mirrormagic-2.0.2>
| ldd mirrormagic linux-gate.so.1 (0xf7f38000)
| libX11.so.6 => /lib/libX11.so.6 (0xf7db5000)
| libm.so.6 => /lib/libm.so.6 (0xf7cd0000)
| libc.so.6 => /lib/libc.so.6 (0xf7ad5000)
| libxcb.so.1 => /lib/libxcb.so.1 (0xf7aa9000)
| /lib/ld-linux.so.2 (0xf7f3b000) libXau.so.6
| => /lib/libXau.so.6 (0xf7aa4000)
| ~/Downloads/mirrormagic-2.0.2> ls -la mirrormagic
| -rwxr-xr-x. 1 em-bee em-bee 203633 Jun 7 2003
| mirrormagic
|
| ok, there are some issues: the sound is not working, and
| the resolution does not scale. but there are no issues
| with linked libraries.
| Levitating wrote:
| I personally believe we should just compile games
| statically. Problem solved, right?
| cylemons wrote:
| This a toolchain issue rather than OS issue. This wounldn't
| have been a problem if gcc/clang just took a --stdlib-
| version option and built the executables linking to that
| version of glibc or equivalent.
| HerbManic wrote:
| Ever since Proton came along, it has been a quiet agreement
| that Win32 APIs are the best target for Linux support.
| beAbU wrote:
| I agree with this take. Wine/Proton might become something
| akin to a runtime for games, running on many platforms and
| consoles. This means devs might stop targeting windows
| directly, but rather they target wine and you'll need that
| for your games on Windows.
| bsimpson wrote:
| Valve nudges developers to ship/support their "one best
| version" of a game, and trust compatibility layers to make it
| work for everyone else.
|
| For x86, that's Windows. For mobile/VR, it's Android.
| Normal_gaussian wrote:
| A solution to itself
| tombert wrote:
| I actually think it'll be the opposite. Even for games that
| have native ports I pretty much always run the Windows version
| with Proton, since that just tends to be more stable. People
| develop against the Windows API because it's familiar and
| somewhat unchanging, and that's fine since Proton does such a
| good job running it.
| Jblx2 wrote:
| If you game/app runs on Wine, doesn't that reduce the pressure
| to develop a Linux port?
| ticulatedspline wrote:
| short term yeah, probably hurts native ports since "why
| bother". Long term though if the market share for Linux is
| particularly high I could see more native development.
|
| Either way my comment is intended as more humorous than truly
| insightful or prophetic.
| BadBadJellyBean wrote:
| Possibly but does it realistically matter? I don't care why
| my games run on linux I just care that they do. I encountered
| a few cases where the native version was inferior to the wine
| version (Cronos is one example). With wine improving there is
| very little downside to just using it.
| Jblx2 wrote:
| Could there ever be a killer app for Linux? One that would
| cause a not-insignificant number of people to decide that
| Linux was worth switching to, even if there was some pain
| of moving away from Windows?
| orbital-decay wrote:
| Unlikely. Games need a stable ABI and Win32 is the only stable
| ABI on Linux.
| akdev1l wrote:
| 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
| fluffybucktsnek wrote:
| Even if all games were FOSS, without - at least - a stable
| API, most games will remain a hassle to run. DOOM doesn't
| deal as much with this due to the high amount of
| volunteers, but relying on community support for all games
| is just outsourcing labor to some unlucky fellows. At best,
| it's yet another pain for Linux users. At worse, it's the
| death of unpopular games. Either case, a hurdle for Linux
| adoption.
| badsectoracula wrote:
| > Proprietary software needs a stable ABI.
|
| Open source software also needs a stable ABI because:
|
| a) i don't want to bother building it over and over (not
| everything is in my distro's repository, a ton of software
| has a stupid building process and not every new version is
| always better than the old versions)
|
| b) a stable ABI implies a stable API and even if you have
| the source, it is a massive PITA to have to fix whatever
| stuff the program's dependencies broke to get it running,
| especially if you're not the developer who made it in the
| first place
|
| c) as an extension to "b", a stable API also means more
| widely spread information/knowledge about it (people wont
| have to waste time learning how to do the same tasks in a
| slightly different way using a different API), thus much
| easier for people to contribute to software that use that
| API
| Pannoniae wrote:
| Not really. I actually tried building an "old" game (read:
| not updated since 2014 or so) on Linux when I used it. It
| didn't work because autotools changed, some weird errors
| with make, and the library APIs have changed too.
|
| In the end I gave up and just used proton on the windows
| .exe. Unbelievable. :(
| akdev1l wrote:
| I should clarify my original comment about stability only
| applies to glibc itself. Once we go out of glibc there
| will be varying degrees of API/ABI stability simply
| because at that point it's just different groups of
| people doing the work
|
| In some cases such libraries are also cross-platform so
| the same issues would be found on Windows (eg: try to
| build application which depends on openssl3 with openssl4
| and it will not work on either Linux or windows)
|
| For future reference if you ever need to do that again,
| it would be way easier to spin up a container with the
| build environment the software expects. Track down the
| last release date of the software and do podman run ---rm
| -it ubuntu:$from_that_time and just build the software as
| usual.
|
| You can typically link the dependencies statically during
| build time to create system independent binaries. So the
| binary produced inside the container would work on your
| host as well.
| LtWorf wrote:
| People who keep parroting this clearly have no experience of
| gaming on linux.
| fluffybucktsnek wrote:
| Please elaborate.
| LtWorf wrote:
| Wine has constant regressions. What works fine today will
| completely fail next year. Which is why steam lets you
| pick which proton version you want to use.
|
| Which means that a .exe without the exact version of wine
| won't run.
|
| Plus of course there's the whole vulkan stuff. Older
| cards aren't well supported but it will rather crash than
| just run openGL normally where it would work fine.
| orbital-decay wrote:
| In practice, Wine is constantly improving. It's in active
| development and not that stable, but regressions are
| mostly local. Treat its releases like bleeding edge.
|
| _> What works fine today will completely fail next
| year._
|
| Usually not on the timescale of a year. I have many new
| games that worked a year ago and none of these stopped
| working now. The worst breakage I had recently was some
| physics glitches in an old RPG (released in 2001) on Wine
| 11.0, and it was fixed in the next release.
| fluffybucktsnek wrote:
| Those issues seem othorgonal to stable ABI issue from OP,
| specially the OpenGL one (that is more like a hardware
| incompatibility issue). When apps fail to run due to Wine
| updates, they are considered bugs to be fixed. On the
| native side, apps may break becuase: 1) required library
| is unavailable, normally because it is too old and
| unsupported; 2) required library's path is different in
| distro A from B. None of these are considered bugs and,
| as such, are rarely addressed. I believe Steam Linux
| Runtime is an attempt at fixing this,but I'm not sure
| about its effectiveness. Also, you are exaggerating on
| the "exact Wine version". It helps to know which versions
| don't have a regression by knowing which specific version
| an app used to run on.
| seba_dos1 wrote:
| > I believe Steam Linux Runtime is an attempt at fixing
| this,but I'm not sure about its effectiveness.
|
| It's effective enough for it to be practically a solved
| problem now.
| orbital-decay wrote:
| I am playing both modern and old games on Linux. Games
| outside a super narrow enthusiast realm are always closed-
| source (even indie ones) and it's going to stay like that
| in the foreseeable future, that's just a fact of life and
| gamedev incentives and specifics.
| TheCycoONE wrote:
| Are you able to run any of the old Loki games on Linux
| these days?
| anthk wrote:
| With compat libraries and OSSPD it will run even under
| Pulseaudio.
| DeathArrow wrote:
| Quiet the other way around. Wine being good will reduce
| incentives for game studio to produce native Linux ports.
| cadamsdotcom wrote:
| Gotta get there somehow.
| 2OEH8eoCRo0 wrote:
| It's interesting when old Windows games run better in Wine than
| in actual Windows 10/11.
| inetknght wrote:
| It's even more interesting when the latest Windows games run
| better in Wine than in actual Windows 10/11.
| marssaxman wrote:
| It seems more likely to me that the Windows API will become the
| de-facto Linux gaming SDK, and the idea of porting a game to
| Linux will become meaningless.
| FpUser wrote:
| If I had a guarantee that every windows application that is
| important to me runs on Wine I would switch next day. Now I use
| Windows to develop both - Windows and Linux applications even
| when primary running mode for application is business backend
| on Linux
| kelnos wrote:
| I don't think this is a big concern. There will still be plenty
| of demand for Wine even with a decent catalog of Linux-native
| games. People use Wine for things other than games, and even if
| tomorrow every single new game had a native Linux port, people
| would still be playing older Windows-only games for at least
| another 20 years, probably more.
|
| Also the Windows ABI is still more stable than the Linux ABI.
| Even if Linux (non-SteamDeck) gaming share went up to like 50%
| or more, it still would probably be less of a hassle to build
| for Windows only, the performance difference on Linux+Wine
| isn't enough to matter.
| nialv7 wrote:
| There always will be old games that will never be ported to
| Linux.
| nutrientharvest wrote:
| In many cases for game devs/publishers "supporting Linux" now
| means making sure the Windows build runs well under Proton.
| hrmtst93837 wrote:
| Maybe, but the incentive runs the other way. If Windows
| compatibility gets good enough, game devs have even less reason
| to pay for Linux QA and support, and Valve plus GPU vendors can
| live with that because the cost gets pushed onto Wine and
| Proton chasing Windows' quirks forever with hacks and syscall
| glue.
| Grimblewald wrote:
| Wine has always beem a bandage not a final thing. Something to
| drive exactly this transition to better. Through wine ive been
| able to transition many colleagues accross because software
| they need will work as they expect it to in linux and
| everything elese is an arcane mystery to them anyway. This
| means one less network effect contributing win user. Most also
| experience a massive jump in tech literacy as a result of the
| move, since a system that doesn't wall you out at every step
| lets you passively learn more.
| adelmotsjr wrote:
| 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.
| brailsafe wrote:
| Start working through the layers! It's incredibly rewarding to
| go from just typical day job stuff to understanding bits and
| pieces of esoteric low level implementation. One level at a
| time, it's not that bad, although it is hard and takes effort.
| I know next to nothing either, but having felt the same way a
| few years ago, these kind of posts now at least excite me
| instead of just intimidate.
| eurg wrote:
| All good. I tell people how to add another mailbox to their
| Outlook, "click here, now there". Not glorious. Necessary
| anyways.
| DeathArrow wrote:
| >People are dealing with such low level things, while i'm outta
| here building simple CRUDs.
|
| CRUDs do pay the bills.
| zerr wrote:
| 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.
| irishcoffee wrote:
| They don't. The "simplicity" of using a "high-level"
| framework for someone who bit-shifts for a living is almost
| comical.
| chistev wrote:
| Really?
| bombcar wrote:
| 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.
| anthk wrote:
| 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.
| timacles wrote:
| 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
| bombcar wrote:
| Kernel developers know that, eventually, they'll figure
| out how the system works and is supposed to work.
|
| CRUD developers know that they never, ever will, because
| business logic is insane.
| JollySharp0 wrote:
| > 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.
|
| It isn't "random", a as business process develop over
| time to various business/customer/regulatory needs. The
| business process _evolves_ over time typically.
|
| When you take a business process, you are often
| formalising it. The fact that you have no appreciation of
| this, tells me you don't really understand what you are
| talking about.
|
| > Understanding low level code puts you on entirely
| different level because you can reason about a problem
| using logic and how systems operate.
|
| You have to do this in high level languages as well. It
| isn't something that only low level devs do. In fact to
| be able to write any good code you need to understand the
| problem domain.
|
| > 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
|
| You are literally disrespecting them by saying this. It
| is also false, what you are describing is developers
| having deal with incomplete/poor specifications and poor
| documentation. BTW this is rampant through the industry.
| I wanted to do some stuff yesterday with Docker and Go,
| the documentation is non-existant.
| bombcar wrote:
| Everything is shit, it's just different _kinds_ of shit.
| :)
| JollySharp0 wrote:
| No not really. I've worked with good teams and you would
| be amazed at how easy it is, even with iffy tech stacks.
| Stuff even get documented properly.
| phist_mcgee wrote:
| Sure mate. And the guy who can do binary sums in his head
| would think of assembly as mere childsplay.
|
| Jog on.
| irishcoffee wrote:
| It was an example. Pedantry is alive and well on hn. :)
| nurettin wrote:
| 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.
| anthk wrote:
| 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.
| whateveracct wrote:
| bit shifting isn't impressive lol
| zerr wrote:
| Thruth to be told, Dunning-Kruger effect is common among
| those who "shift bits" :)
| -drews wrote:
| I felt this way moving from embedded into backend for the
| first time and having no idea where to start. Was incredibly
| daunting, but both domains become trivial over time.
| Rick76 wrote:
| Can confirm, my buddy who is someone I respect immensely, is
| an embedded programmer.
|
| He will talk about OS events, or any low level concept and it
| makes me feel like I don't know anything, but he acts like
| I'm a genius if I talk about JavaScript Runtimes, browser
| engines, anything frontend.
|
| It's cool he teaches me new things, I teach him some
| __natty__ wrote:
| Some people are exceptional at solving difficult but hard
| to explain problems while other are great solving direct
| business problems. No need to feel ashamed for both it's
| just different work
| throwawaytea wrote:
| I think your friend is just being kind.
|
| Most people know that there is a big difference between
| experience in something pretty easy vs mastery of something
| very difficult.
|
| A rocket scientist acknowledges a concrete guy knows way
| more than he does about concrete, but also knows that
| doesn't make him a genius because it's easy enough to learn
| just being around it. Plus, the rocket scientist also knows
| that since he knows so little about concrete, he wouldn't
| even be able to judge if the guy is really a concrete
| genius or just saying things a real pro would label wrong.
|
| Your example isn't that crazy, but still, you should
| realize your friend is just being nice.
| surajrmal wrote:
| I work on OS/embedded and my wife in server backend. I
| definitely feel like a simpleton when trying to
| understand all of the high level stuff she works on. It
| doesn't invalidate my own expertise. There is nothing
| wrong with acknowledging someone has skills that you
| don't have and likely would take a long time to pick up.
| Pannoniae wrote:
| Yeah exactly. High-level people think the low-level stuff is
| magic, and us from the other side think the high-level stuff
| is magic (how can you handle all that complexity?...)
| guzfip wrote:
| > how can you handle all that complexity?...
|
| You don't. Someone else smarter than you handled it already
| and you just need to integrate their solution.
| zerr wrote:
| "Someone else smarter than you manufactured microchips
| and you just need to integrate their solutions."
| zerr wrote:
| Yup. AbstractSingletonProxyFactoryBean and
| SimpleBeanFactoryAwareAspectInstanceFactory agree as well
| :)
| dgunay wrote:
| 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.
| dmitrygr wrote:
| Play with low level things. It'll help you in your daily job in
| ways you do not yet imagine. Start here: nandgame.com
| Teknoman117 wrote:
| As someone who works on systems at this level, believe me, it's
| a learnable skill. And at least an intellectually valuable one
| I think too. Even if you never really need the knowledge for
| the things you do, there's a nice feeling that comes from
| seeing something done at a high level and understanding how
| that makes its way down into the system and why those design
| choices were made.
|
| If I were more money motivated I'd probably be building CRUD
| apps too. I just like weird puzzles XD.
| zem wrote:
| I work on compilers, and have bounced several times off trying
| to write my own full stack crud app for a personal project
| (tried doing it in rails, phoenix and django at various times).
| I'm finally getting somewhere with claude's help, but it really
| is its own set of skills - easy to get started with but hard to
| do well.
| amoss wrote:
| You may be surprised by how much easier it is to dump the
| framework/stack and just write it from scratch. I say this
| because I too work on compilers and have a crud app as a
| personal project. The first versions were a nightmare in
| various frameworks and since I switched to a C++ backend /
| vanilla .js frontend it has been incredibly easy to write.
| zem wrote:
| interesting, how did you manage the db interactions in c++?
| and did you have a single executable for the app and the
| web server combined?
| amoss wrote:
| no database for this project - the data model has a
| simple text representation so it gets serialized out to a
| folder/file layout on disk that goes into version
| control. single self-contained binary: contains the
| web/websockets server, backend logic,
| parser/serialization. there is a separate component in
| python that sits behind an internal network connection to
| handle an execution sandbox.
| johnnyanmac wrote:
| Meanwhile, I can't really do either because the job market
| sucks and I don't have time to contribute the way I want to to
| project like this.
| pier25 wrote:
| Same. I feel like a plumber compared to real engineers.
| dole wrote:
| You're still an engineer. Knowing the right places to click
| in an esoteric app is like knowing where to hit the boiler
| with a hammer to get it working again.
| kalinkochnev wrote:
| Engineers feel like plumbers compared to the plumbers
| IIsi50MHz wrote:
| Engineers & architects leave a lot of detail out of their
| designs, relying on the plumbers and other trades to figure
| out the Right Thing. (-:
| wishfish wrote:
| 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.
| genodethrowaway wrote:
| ai slop
| rationalist wrote:
| Looking at the user's other comments, I disagree.
|
| Looking at your comments however, while probably not AI,
| they're still not helpful.
| crustaceansoup wrote:
| Never seen an LLM write so many short, halting sentences in
| a row. Very human.
| wishfish wrote:
| You can tell from my comment that I'm not AI. I've had a
| lifelong habit of using commas instead of dashes in
| situations where the dashes would have been more
| appropriate. AI would always go for the dash.
|
| First time I've been accused of AI.
| komali2 wrote:
| > He called it his paid vacation.
|
| As a fellow CRUD writer you're kinda seconding the OP's point
| here...
|
| Personally I say oh well, some people are smarter and/or
| harder working than me. Now watch this drive -
| wishfish wrote:
| I was seconding his point. I personally ended up in
| educational software which is CRUD-adjacent in terms of
| stress and sanity. Never regretted it.
| guzfip wrote:
| > 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.
|
| That was all nice and good for a while, but the times are
| ending.
|
| I suspect there will still be a human involved in the
| production of software, but it will be domain experts, not
| CRUd monkeys who picked up just enough domain knowledge to be
| dangerous.
| samus wrote:
| The really valuable CRUD monkeys are already domain experts
| as well. The threatened ones are junior developers whose
| output is barely better than AI slop.
| guzfip wrote:
| > The really valuable CRUD monkeys are already domain
| experts as well
|
| Sure but that's a minority I'd argue. There wouldn't be
| such a volume of shitty business software otherwise.
|
| I will be interested to see if there are any economic
| effects of ending one of the last well paid, low barrier
| to entry careers in which some level of meritocracy was
| permitted.
| crtified wrote:
| Don't feel too bad - I had to Google what CRUD means. :D
| torginus wrote:
| Why do people belittle CRUDs? Or even call them that? I have
| written quite a few applications, where there was a frotend
| which displayed things stored in a SQL db, with certain
| operations allowing you to modify said db, which I guess would
| fall into the CRUD variety, but the least of the complexity,
| and usefullness lay in that fact.
| Deebster wrote:
| CRUD = Create, Read, Update, Delete
|
| Plenty of business apps don't really ask for much more than
| that, and those are the CRUD apps. They're not particularly
| challenging to write, nor is it very interesting to do so.
| JollySharp0 wrote:
| I am a normal web dev / CRUD app coder. All of this isn't
| beyond your ability.
|
| Every so often I hit a problem that requires me to go all the
| way down to the OS level and find out what is going wrong or
| into the core framework and you find out that most of the code
| is actually less complex, better documented and clearer than a
| lot of the garbage bespoke applications you have to deal with
| at the higher levels.
| Tade0 wrote:
| If it's any consolation I can out-imposter you: lately I've
| been mostly reviewing LLM-generated code.
| hu3 wrote:
| > 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.
| bmenrigh wrote:
| 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/userspace-api/ntsync.html, which is a
| driver for Linux that offers syncronization primitives (mutex,
| semaphore, events) that more closely match the semantics of the
| Windows primitives. It's easier to do a direct implementation
| in Wine to support code compiled for Windows that expects to be
| talking to an NT kernel.)
| creesch wrote:
| > There has been a somewhat fast "fsync" library built around
| Linux's futex
|
| The article actually goes into that in quite a bit of detail
| about that.
| bmenrigh wrote:
| Yeah but to the commenter I was replying to, I don't think
| it was clear that detail was relevant to the benchmark
| numbers they were quoting.
| torginus wrote:
| Do they have any other usecase behind Wine? My guess would be
| MS SQL server, but is that correct?
| ElectricalUnion wrote:
| Starting with SQL Server 2017, native Linux support exists.
| Probably because of Azure.
| qalmakka wrote:
| Ironically, SQL Server AFAIK in order to run on Linux
| uses what basically amounts to a Microsoft
| reimplementation of Wine. Which always makes me wonder if
| they'll ever get rid of Windows altogether someday in
| favour of using Linux + a Win32 shim. I think there are
| still somewhat strong incentives nowadays to keep NT
| around, but I wouldn't be that surprised it this happened
| sometime down the line.
| sirjaz wrote:
| It's a Windows container. It runs the NT kernel and a few
| minimal other things. The closest would be the Nano
| Server container
| qalmakka wrote:
| AFAIK it's more like a reimplementation of NT APIs in
| userspace - aka basically Wine with extra steps, or Linux
| UM. There was a slide deck going around about Project
| Drawbridge, here:
| https://threedots.ovh/slides/Drawbridge.pdf
| Levitating wrote:
| Though like the article mentions, fsync doesn't work out of
| the box (requiring kernel patches).
| iknowstuff wrote:
| * when not using esync nor fsync
| ToucanLoucan wrote:
| 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?
| jeppester wrote:
| It's a distribution of Wine with some extra stuff added,
| importantly DXVK (directx => vulkan layer) and a lot of game
| specific workarounds.
| gpderetta wrote:
| More or less Wine + some experimental patches not yet I
| twgrated in mainstream wine + a buch of DirectX translation
| libraries + close steam integration.
| ToucanLoucan wrote:
| That makes sense. I thought they were entirely separate tbh
| but it makes sense that they'd share a lot of DNA.
|
| I absolutely love my Ally running SteamOS. Incredible work
| by... everyone involved, really.
| rounce wrote:
| Though currently Proton has not yet shipped a release which
| uses Wine 11.
| Dystakruul wrote:
| There's also Proton-GE [1], which is even more experimental
| and adds some bleeding edge fixes and features.
|
| I've heard it's pretty good for fixing video
| playback/rendering (e.g. cutscene) issues if both the
| stable and the experimental branch of Proton can't make it
| work.
|
| [1] https://github.com/GloriousEggroll/proton-ge-custom
| psyonity wrote:
| A lot of what Proton-GE brings from my understanding is a
| larger support for Media Foundation, which can't be added
| to Proton itself because of license issues (Proton is
| from a commercial company, where Proton-GE is from an
| individual).
|
| So aside from the stuff that has been implemented
| differently, running Proton instead of Proton GE is like
| trying to game on Windows N editions.
| badsectoracula wrote:
| There is also UMU Launcher[0] which is basically all that
| without the Steam integration/dependencies so you can run
| games from GOG and other stores (it is a command-line tool
| but launchers like Heroic can use it behind the scenes). I
| used to install dxvk, etc manually but in recent months i
| switched to it as it tends to work much more seamlessly for
| games (i did disable its autoupdates though).
|
| [0] https://github.com/Open-Wine-Components/umu-launcher
| diath wrote:
| Read the last sentence in that paragraph, those numbers are a
| bit disingenuous:
|
| > Those benchmarks compare Wine NTSYNC against upstream vanilla
| Wine, which means there's no fsync or esync either. Gamers who
| use fsync are not going to see such a leap in performance in
| most games.
| hu3 wrote:
| That makes Wine on Linux even more amazing.
|
| It means these games were already running well in Linux and
| even better now.
| sumtechguy wrote:
| Having done a multi targeted project in the 2005 range. I can
| tell you. The APIs that both systems provide are quite
| expansive and do quite a bit. However there is a mismatch on
| details and gaps. In this case the NT mutex system is 'there'
| in linux however the way it works is subtly different. You have
| to basically emulate waitforxxxxxxobject set of windows calls.
| Getting that right and performant can be quite a challenge.
|
| My particular challenge was similar in around how threads were
| created destroyed and signals between them (such as mutex). We
| ended up making our own wrappers to insure the different
| platforms acted the same. Even something simple as just moving
| between two supposedly 'same' linux distros could be different
| depending on what the ODM did to their packages and supported
| libs. Having a dedicated linux object that acts exactly like
| the windows one would have made that code much simpler to do.
|
| Another place where there is a huge impedance mismatch is in
| the permission system. In many ways the VMS/NT way is wildly
| detailed. Linux can do that but you have to emulate it or use
| it directly and hope you get it right on both sides. There are
| several places where windows/linux have the same functionality
| but the APIs are different enough that multi platform support
| is kinda awful to do.
| tombert wrote:
| 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 a lot of games better than Windows now
| (especially older games) shows a very strong attention to detail
| and a high tolerance for pain. I commend them for it.
| hxorr wrote:
| ReactOS also deserves an honorary mention. A lot of knowledge
| from that project feeds into Wine.
| pdpi wrote:
| And vice-versa. It's pretty interesting that the two projects
| haven't kind of merged despite all the collaboration.
| MisterTea wrote:
| 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.
| Induane wrote:
| ReactOS periodically rebases some of it's libraries from
| Wine.
| badsectoracula wrote:
| Wine devs do not want to work with people who have looked
| at ReactOS[0] (see at the end) so any collaboration is one-
| way (or by ignoring the guidelines) and the likelihood of
| the two projects merging is zero.
|
| [0] https://gitlab.winehq.org/wine/wine/-/wikis/Clean-Room-
| Guide...
| DaSHacka wrote:
| Surprised no one responded to the 7th comment in that
| linked email thread, the author brought up a good point
| about making progress without using any disassembled
| windows binaries.
| rhdunn wrote:
| 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.
| dingdingdang wrote:
| 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.
| RunningDroid wrote:
| > 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.
|
| I believe that's what Winelib is for:
| https://gitlab.winehq.org/wine/wine/-/wikis/Winelib-
| User's-G...
| dingdingdang wrote:
| Yep. that's the route I tried before, no good, maybe it's
| just that the documentation is past it's sell by date,
| maybe it's lack of community use.. I'm just not seeing
| it. Even the article itself describes how to make an exe
| file... that will then work in Linux? Or is it simply a
| program that's easier to run on Wine? Loads of text with
| unclear details throughout it.
| tosti wrote:
| To make an elf, you use gcc. To make an exe, you use
| mingw.
|
| The rest should be a matter of include and linker paths,
| but that's all I can recall right now.
| refulgentis wrote:
| I simply wouldn't have the patience to do what Elizabeth did,
| for a month, much less years. Really really impressive
| anal_reactor wrote:
| Yes, Wine is truly a miracle. Once full support for Office is
| achieved, we should expect huge uptick in Linux adoption.
| jhoechtl wrote:
| Ny that time office will be cloud only.
| m463 wrote:
| > full support for office
|
| does microsoft still sell office?
| ThrowawayB7 wrote:
| Yes, Microsoft does still sell MS Office 2024 as a one time
| purchase:
|
| - https://www.microsoft.com/en-us/microsoft-365/p/office-
| home-...
|
| - https://www.microsoft.com/en-us/microsoft-365/p/office-
| home-...
| tom_alexander wrote:
| Outlook is a business exclusive these days?! Outlook used
| to be included in the most basic version of office back
| when I still used microsoft office.
| dhosek wrote:
| I've only ever used Outlook when forced to by an employer
| and I find it a dreadful application to use. I would
| guess that most people prefer something else. I would
| imagine that most people tend to stick with the default
| email app on their computer (no idea what that is on
| Windows as I've managed to avoid having to use Windows
| for 7 years now).
| 1bpp wrote:
| The default mail app on Windows is now called Outlook for
| Windows, no relation to the Outlook in Office (sorry,
| Microsoft 365 Copilot), and it's a significantly worse
| barely functional webview. It also replaced the entire
| Calendar app, which was decent.
| Asmod4n wrote:
| Will be removed from the next release. Then you can't
| connect to your own exchange server anymore and are
| forced into 365 when you want a desktop app.
| tracker1 wrote:
| They've really shifted how Outlook works... as well as
| how the backend is more tuned to the way M365 mail works
| far more than how it used to work with Exchange, or
| independently. It's been a slow downslide imo since
| around 2007 or so.
|
| I know the why, but it's really worse as an experience
| for most people than the older integrations... but the
| use of horizontally scalable backends makes for a saner
| platform at the expense of better UX.
| pkaye wrote:
| Yes the do have an one time purchase option. You get 5
| years of updates but no new features. I have it on my home
| computers. But new features are not a big deal since the
| differences are not big anymore (just like mobile phones.)
| novos wrote:
| I wouldn't put it past Microsoft to suddenly add "features"
| that break said support.
| mrec wrote:
| "Office ain't done 'til Wine won't run"?
| RachelF wrote:
| It is a superb project, and a hard thing to do.
|
| It is a pity that the apps most business people use everyday,
| like Word and Excel and Outlook don't work in it (Excel 2010 is
| the last version that has Platinum status). It is interesting
| that these are harder to get working than games.
| coldpie wrote:
| > 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 mechanisms...
| there's almost no corner of the Windows OS that MS Office
| _doesn 't_ use.
| joe_mamba wrote:
| 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 back then from graphics to sound shipped
| their own APIs.
| Asmod4n wrote:
| You mean dos games, just run them under a dos emulator
| then.
| joe_mamba wrote:
| NO, I meant Windows games.
| ndriscoll wrote:
| 90s Windows ran inside of DOS, and you can run e.g.
| Windows 98 games (through Windows itself) in DOSBox. Look
| up exowin9x where they're trying to compile all of the
| necessary configs for one-click launchers.
| tombert wrote:
| I didn't think that regular DOSBox had support for stuff
| like 3dFX does it? Or other weird APIs?
|
| I had to use PCem to get support for that stuff.
| sersi wrote:
| I've had some success with installing windows in dosbox-x
| which has glide support. Faster and more lightweight than
| pcem/86box
| tryauuum wrote:
| I tried running the elder scrolls Redguard, on wine,
| which launches windows version of dosbox with glide
| support. Redguard is a weird beast which is installed
| only with windows installer, but the actual game runs in
| dos mode
|
| Everything works but the frame rate isn't great
|
| If anyone knows a good Redguard setup for Linux please
| mail me, you can guess my mail easily. Now I just run the
| gog version
| Asmod4n wrote:
| Then you can use dosbox-x which can run any non nt
| windows version and has support for 3d acceleration
| joe_mamba wrote:
| Again, I meant windows games, not DOS games.
| Asmod4n wrote:
| Windows before NT is just a dos app, and dosbox(-x) can
| play all windows games up to those which require ME.
| tombert wrote:
| Oh, no, before everything kind of converged to OpenGL and
| DirectX, there were oodles of different things trying to
| be the next graphics API.
|
| 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".
| vbezhenar wrote:
| > Games are mostly just doing their own thing, only
| interacting with the system for input & output.
|
| They should be trivial to port then, no?
| Rohansi wrote:
| 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 builds. It's Vulkan renderer has had a
| memory leak for a while now. Input has randomly decided
| to double keypresses on some distros.
| MindSpunk wrote:
| 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.
| simonask wrote:
| 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.
| p1necone wrote:
| Yeah but Windows is a more stable api to develop against
| than Linux (at least when it comes to stuff that games
| need to do) - it doesn't feel "pure", but pragmatically
| it's much better as a game developer to just make sure
| the Windows version works with proton than it is to
| develop a native Linux version that's liable to break the
| second you stop maintaining it.
| greiskul wrote:
| As someone once said it best, Win32 is the only stable
| ABI on Linux: https://blog.hiler.eu/win32-the-only-
| stable-abi/
| tosti wrote:
| Because free software doesn't need such a thing as a
| stable ABI.
|
| There does exist flatpak, everything that would benefit
| from a stable ABI could use that.
| codebje wrote:
| The killer for games tends to be the anti-cheat or anti-
| piracy layers.
|
| I have a Windows game I can't run under CrossOver (aka
| Wine 11) or a VM, only because its anti-piracy layer
| doesn't accept those circumstances.
| alpaca128 wrote:
| Meanwhile I had to pirate Dark Souls 1 because
| Microsoft's own DRM prevented the legitimately purchased
| game from saving on Windows, and download official no-cd
| patches for two other games because their DRM stopped
| working.
|
| The problem with DRM is the DRM.
| RajT88 wrote:
| Parts of the OS were designed for Office. (Windows
| installer service, for example)
| nicoburns wrote:
| Office used to work well on WINE. It was the switch to a
| rolling release model that killed it.
| usrusr wrote:
| So that's what's keeping Microsoft from just running WINE
| on an MS-flavored Linux or perhaps a clean slate kernel as
| their next OS. I've been wondering for a while, this is by
| far the best explanation.
| bombcar wrote:
| The Windows Kernel (and arguably the Windows APIs) are
| the only good part of Windows; they should dump
| everything else and run Linux above it; wait they did do
| that and then changed it to a boring VM.
| fock wrote:
| if you rip out linux from your linux distribution you
| usually end up with GNU.
| rowyourboat wrote:
| So, that would make this GNU/Windows
| dkersten wrote:
| They could brand it as "New Windows"
| 9wzYQbTYsAIc wrote:
| Out with the old, in with the GNU.
| JPLeRouzic wrote:
| > _" running WINE on an MS-flavored Linux"_
|
| Like obsolete Longene project?
|
| https://en.wikipedia.org/wiki/Longene
| da_chicken wrote:
| Yeah, people forget that MS Office, and Excel and Outlook
| in particular, are the real foundation of Microsoft's
| vendor lock-in on the desktop.
| Discordian93 wrote:
| Outlook is now basically an Electron app, they've
| deprecated the old desktop Outlook in favor of a port of
| the web app to desktop, so it's basically just Excel
| remaining.
| johnebgd wrote:
| Electron apps also basically don't work in Wine. I miss
| having Evernote on Linux.
| Grisu_FTP wrote:
| Wouldnt it be possible to extract the files you need and
| sort of "repackage" it for linux?
|
| I have no idea how electron apps look "internally" but it
| doesnt sound too bad.
|
| Sort of like you can unzip .deb files and use them
| somewhere else, if what i heard was correct (never tried
| it myself)
| ifwinterco wrote:
| Not my area of expertise so I could be wrong but Electron
| apps just use Chromium underneath (which already works on
| linux), so in theory it should be easier to get them
| running on linux than a native Windows app
| jitl wrote:
| If the Electron app is pure JS with no native extensions
| it can be doable. However, many Electron apps contain
| platform-specific js code, since features for stuff like
| Dock on Mac and Taskbar icons on Windows differ. Electron
| apps like Notion also contain native extensions -
| compiled C/C++/Objective-C code that are platform
| specific. For example in Notion, we use sqlite via
| better-sqlite3 (potentially replaceable since it's open
| source, but will need more work than "just" repackaging
| js), but we also write our own native support libraries
| to use OS-specific APIs for microphone recording in
| meeting notes feature.
| exceptione wrote:
| How is that even possible? I expect you have to go out of
| your way to make it platform dependent, are you sure?
| tsimionescu wrote:
| Electron is basically just a GUI framework. The
| application itself can be arbitrarily complicated,
| nothing stops you from building a Java + .NET + C++&COM
| app that includes three Windows Services that interfaces
| with the Electron runtime just for UI.
| lp0_on_fire wrote:
| > Outlook is now basically an Electron app
|
| And it's horrible.
| Quothling wrote:
| Having worked in non-swe enterprise for two decades I
| would argue that this is less true today than it was 10
| years ago. It used to be that new hires would come with a
| basic knowledge of windows and office, but that's no
| longer the case. At the same time, you have things like
| Smartsheets and so on, which are more popular, at least
| with our employees, than Excel and everyone seems to hate
| Outlook these days. I don't think it was ever really the
| case though. What Microsoft sells to enterprise is
| governance, and they really don't have any competition in
| this area.
|
| Being in the European energy sector we're naturally
| looking into how we can replace every US tech product
| with an EU/FOSS one. It's actually relatively easy to buy
| the 365 experience through consultants which will setup a
| NextCloud, Libre/Only Office, Proton and a teams
| replacement I can't for the life of me remember the name
| of. Beneath it there is a mix of Identity Management
| systems, often based around Keycloak, at least for now.
| It works, from what we've seen in Germany (specificlaly
| with their military) it's also possible to roll it out
| relatively quickly. It's all the "other" stuff that gets
| murky. There isn't a real alternative to AD/Entra, yet,
| from a governance perspective. There are great tech
| solutions which does the same thing, but they require a
| lot of IT man hours. Something the public sector is
| always going to be more willing to deal with than the
| private sector. If we collectively decided that trains in
| Denmark should be free for passengers, then that would
| happen. You can't do that in a private business, though
| security obviously does factor into it.
|
| This is the general story really. Microsoft's copilot
| studio is relatively new, and it's probably been flying
| under the radar in a lot of tech circles because it's
| basically what power automate always wished it could be.
| Having used it to build a HR flow, where an AI model will
| receive the applications, read them, auto-reply to
| irrelevant ones, create a teams site with files and the
| relevant people for the relevant applications, and invite
| the applicant to their first appointment. Well... I gotta
| say that I'm not sure what we have that's an alternative
| to that. It took me a couple of hours to build it, and it
| frankly works better than I thought it would. Granted, I
| did know the tool because I had previously done a PoC
| where I build a teams agent which "took over" my teams
| interactions. Everyone noticed because it spelled
| correctly and wasn't capable of posting Warhammer 40k ORK
| meme's in any form of quality, but it was frightenly
| easy. What Microsoft sells in this area is again the
| governance of it all. You can do these things because of
| how EntraID lets you connect services seamlessly with a
| few clicks. While behind the scenes all of those clicks
| are only available to you because your IT department
| control them... Again... without hundreds of manhours.
|
| I'm sure we'll eventually get there, but it'll likely
| come down to change management. Because even if you're
| willing to retrain your IT operations crew, it's not
| likely that they will want to leave the Microsoft world
| where they are well paid and job-secure. Well, maybe I'm
| in a cheese bell, but I've never met an Azure/Microsoft
| IT person who would want to work with something else, and
| having been forced to work a little bit with it behind
| the scenes, I sort of get it... well not really.
|
| Which boils down to why Microsoft has always been good
| with enterprise customers. The decision makers in your
| organisation will listen to everything, but their own IT
| departments will often sort of automatically recommend
| Microsoft products and at the end of the day, it'll all
| boil down to risk. Which is what Microsoft really
| sells... risk-mitigation. Sure their licenses are
| expensive, but is it really more expensive than losing
| your entire IT staff? (this isn't an actual question I'm
| asking, it's what goes through the considerations.)
| mietek wrote:
| > _...an AI model will receive the applications, read
| them, auto-reply to irrelevant ones..._
|
| You're probably breaking EU law by building this
| nightmare.
|
| https://artificialintelligenceact.eu/article/86/
| danudey wrote:
| All that law says is that the applicant 'shall have the
| right to obtain from the deployer clear and meaningful
| explanations of the role of the AI system in the
| decision-making procedure and the main elements of the
| decision taken.'
|
| And even then, only if a job application rejection
| 'produces legal effects or similarly significantly
| affects that person in a way that they consider to have
| an adverse impact on their health, safety or fundamental
| rights'.
|
| So as long as the company is recording the decisions
| taken and the reasons for those decisions, and providing
| those to candidates on request, they're in the clear.
|
| I doubt that they are, but maybe!
| bigfudge wrote:
| This probably reflects my own prejudices, but it always
| struck me that MS based IT people wouldn't work with
| anything else, basically because they couldn't.
|
| That stack optimises for not really having to understand
| what you're doing, but also avoiding any major foot guns
| (and having the general arse covering that buying IBM
| used to provide, but which MS now does). The price you
| pay is that everything is horrible to work with. But if
| the alternative is not really being able to get anything
| done at all then so be it?
| danudey wrote:
| The Windows ecosystem does a lot of things that, to me,
| as a Linux/MacOS user, seem like a weird bunch of crazy
| decisions that are different just because.
|
| Whether that's true or not, it does mean that a lot of
| people who came up on Windows IT don't have a mental
| framework for how to run or manage Linux systems.
| Likewise, when I'm trying to diagnose something on
| Windows it just seems like the entire thing is a
| disaster; where are event logs? In the event viewer! How
| do I filter them? It's a mess! Can I search them? Kind
| of! Do they have information to help me diagnose the
| problem? Almost never!
|
| On Linux, I know all the tools I need to solve all the
| problems that come up; on Windows, I have only minimal
| concept of how things work, and very little way to
| diagnose or debug them when they go wrong, which is
| often.
|
| For example, when my Windows gaming machine comes out of
| hibernation my ethernet controller insists that there's
| no connection. I can't convince it otherwise except by
| disabling the device and re-enabling it. I can't figure
| out where I might find information that tells me why this
| is happening, so I just wrote a powershell script to turn
| it off and then on again. I bet some Windows IT dork
| could figure it out in 30 seconds, but I'm a Linux IT
| dork and I have no clue.
| badpun wrote:
| For games, part of that mere ,,output" is 3d graphics, so
| replicating the internals of Direct 3D exactly right and
| getting the Linux GPU drivers to cooperate. That's a
| hardcore task.
| coldpie wrote:
| Fun fact: MS Office _also_ uses Direct3D :) See
| "Graphics" requirement here:
| https://support.microsoft.com/en-us/office/system-
| requiremen... We put a ton of effort into D3D11
| specifically to get MS Office running.
| philipwhiuk wrote:
| I don't know that they are. It's just there's more incentive
| to port stuff that has no direct alternative.
| codebje wrote:
| Steam and CodeWeavers contribute a lot of code to the Wine
| project, because it underpins their business models of
| supporting Windows games on non-Windows platforms.
|
| Between them they make up the vast bulk of what actually gets
| attention and improvement in Wine, and neither one has any
| interest in supporting non-game applications.
| YokoZar wrote:
| > neither one has any interest in supporting non-game
| applications.
|
| I don't know how much of their business it is today, but
| CodeWeavers spent their first decade or so supporting only
| non-game applications. Their product Crossover was
| originally Crossover Office because it was optimized around
| productivity applications.
| Grisu_FTP wrote:
| Also a big part of the marketing for the
| SteamMachine/SteamDeck/SteamFrame is that it has a
| desktop mode and can be used like a pc, so i think they
| also have an interest in that
| jitl wrote:
| i didn't buy a steam deck since so i can run Microsoft
| Office. i like that there's freedom to open up desktop
| mode to tinker / install 3rd party software, but not to
| use it as a business machine.
| josh_p wrote:
| I find it difficult to believe that someone with enough
| technical knowledge to run a Linux desktop for business
| purposes in 2026 would be reliant on the MS Office suite.
| Other people have given plenty of technical reasons for the
| difficulty. I don't think it's a useful goal to get them
| running when practical alternatives like libreoffice exist.
| saidnooneever wrote:
| these apps are all like web browsers, and likely needlessly
| complicated due to patching the same codebase for so long.
| its MS afterall. there will be code in there that they
| themselves hardly understand.
| computomatic wrote:
| I avoided using Wine (and Linux for gaming generally) for years
| on the sole basis that I assumed what they were trying to do
| was impossible to do well. Occasionally I'd try wine for some
| simple game and be impressed it worked at all, but refused to
| admit to myself that it was something I could rely on. (This
| was many years ago and I freely admit today that I was wrong.)
| ACS_Solver wrote:
| 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.
| owaislone wrote:
| 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.
| amatecha wrote:
| https://www.gamingonlinux.com/2026/03/ea-javelin-
| anticheat-j...
| sdenton4 wrote:
| Idk, kernel anti cheat is a pretty clear sign to me that
| I should pick a different game to play anyway...
| HWR_14 wrote:
| Does windows make it easy to tell the installer wants to
| install kernel anti cheat? It used to pop up the generic
| binary "This application wants to change files on your
| computer" which could be installing in the protected
| "Program Files" or could be modifying anything.
| worthless-trash wrote:
| I dont think you can even load the "windows" kernel
| module in wine. Last time i tried with the capcom
| rootkit, it didnt work at all.
| colejohnson66 wrote:
| Wine doesn't emulate the NT kernel; Just the NT and Win32
| userspace APIs. For example, Wine provides a
| `kernel32.dll` that maps API calls into the appropriate
| Linux ones. Anything kernel level is operating "below"
| Wine.
| HWR_14 wrote:
| I read the person I was responding to saying they avoided
| games with root kits for moral, not technical, reasons.
| So I assumed they were on Windows, and AFAIK, windows
| just offers binary "changes" permissions which covers
| anything from installing in the slightly protected
| Program Files directory to installing a rootkit. In other
| words, can they even detect they are about to install a
| root kit?
| Melatonic wrote:
| Good question and one I am now looking into
| ZiiS wrote:
| Ironically the only way I would ever consider robust
| anti-cheet is if the game installed a seperate bootable
| Linux witch didn't have the encryption keys for my main
| partition.
| cultofmetatron wrote:
| Paying for a game that inserts rootkits into your kernel
| feels like paying money to get molested. no thanks.
| Arwill wrote:
| Hate to be the one saying this, but that rootkit is there
| to prevent you from molesting/cheating other players. So
| its not an one-sided issue. It is unfortunate that the
| developers found no other way of fighting cheats, sure.
|
| And by all means, if a game community is so toxic that it
| has to be policed by extreme measures, it is perhaps
| indeed better to avoid playing such a game altogether.
| cultofmetatron wrote:
| agreed. if a condition of attending an event was that I
| had to wear a chastity belt that prevented guests from
| raping each other, I'd think twice about attending
| alltogether.
| johanvts wrote:
| I don't care if my shooter game "community" is toxic. I
| don't have any interaction with the "community" other
| than to try and virtually kill its members. I wish my
| chess app had anti-cheat, there are just some people who
| will cheat and any game is more fun if they can be
| prevented from playing.
| Hikikomori wrote:
| Because anti cheat on linux is completely useless.
| anakaine wrote:
| By and large Im happy to not participate in games that use
| kernel level anti-cheat.
| BatteryMountain wrote:
| Now if only Steam would add a checkbox on their checkout
| page to add 10% donation/tip that goes directly to their
| upstream opensource dependencies (like the Wine team), that
| would be amazing! I would add extra money on every purchase
| to support these people!
| hochmartinez wrote:
| https://www.winehq.org/donate
| moring wrote:
| Requires PayPal or credit card. The suggestion was to pay
| with your Steam Wallet or whatever payment method already
| used when you buy a Proton-based game on Steam.
| red-iron-pine wrote:
| for 99% of people it will also probably be paypal or
| credit card
| colejohnson66 wrote:
| > Donate to the Wine Development Fund by cash, cheque, or
| international money order in US dollars.
| moring wrote:
| IMHO this supports the original point that payment via
| Steam would be an upgrade:
|
| Sending cash to a postal address isn't low-effort nor
| low-risk.
|
| Payment by cheque is something I have never done, nor
| would I know how to do it. I'd have to ask at my bank --
| not low effort. I don't know if I'm an outlier here but I
| have never heard from any of my peers who ever did such a
| thing.
|
| The same or even worse is true for international money
| orders. The whole concept of making a money transfer to a
| postal address is something I have never heard of.
| Where's the IBAN?
|
| The Wine team is right to put even PayPal before all of
| these.
| greenavocado wrote:
| The best low overhead way to support them for Americans
| is to set up bill pay with their bank and auto send
| checks to their mailbox
| moralestapia wrote:
| Can you have a Steam Wallet without having a credit card?
| moring wrote:
| Yes, I do. It just means that you have to manually
| "recharge" your Steam wallet when it runs low. That's
| some effort, but it limits the possible damage if
| something goes wrong.
| moralestapia wrote:
| How do you "recharge" you Steam Wallet? Gift cards, I
| assume?
| danudey wrote:
| Yep, depending on where you live you can probably find
| them wherever you find other major brand gift cards.
| lebed2045 wrote:
| i pay for crossover license (wine on mac), if i
| understand correctly, they spend this money on
| development wine core as well.
| OccamsMirror wrote:
| This is a fantastic idea. I completely endorse it. I hope
| a Valve employee sees this.
| exitb wrote:
| You always give 30% to Valve and their interests so far
| are aligned. Everything that's possible within the Steam
| ecosystem is available outside of it. Maybe things will
| change in the future, but I doubt we could be getting a
| better deal.
| rickdeckard wrote:
| Great idea!
|
| Such donations might even be tax-deductible revenue for
| Valve, so even the finance bros should love it.
|
| Although I would prefer if Valve simply commits to a
| fixed percentage of its Steam fee to be donated...
| colejohnson66 wrote:
| Forwarded donations are not tax-deductible (in the US);
| That's a lie that's been spread around the internet. If
| you give a company money with the express purpose of them
| forwarding it to someone else (the company acts as a
| "collection agent"), it's not their income or donation.
|
| https://taxpolicycenter.org/taxvox/who-gets-tax-benefit-
| thos...
| BobaFloutist wrote:
| And even if it was, all "tax deductible" would mean is
| that they wouldn't have to pay taxes on that money.
| Which, you know, they don't get to spend. So it's kind of
| defacto tax deductible in the same sense that my friend's
| income is "tax deductible" for me, I guess.
| colejohnson66 wrote:
| A lot of people online have convinced themselves that
| "tax deductible" means that the government would refund
| you that dollar amount. That's a "tax _credit_ "... If
| forwarded donations were a tax credit, then yes, rounding
| up _is_ giving the company "free" money! But you're not.
| rickdeckard wrote:
| Interesting, thanks for the details.
|
| So it would be actually financially _better_ for Valve to
| donate a portion of their revenue and state "we will
| donate x% of the price to yy", as THEN it would be tax-
| deductible for them
| tstenner wrote:
| Buy a steam deck. It sends a strong signal to Valve to
| continue supporting Wine _and_ you get a Steam Deck
| BatteryMountain wrote:
| I'm in Africa, when I go to the steam deck page, it says
| it is not available in my country. Not interested in
| buying from a third party importer. So until then..
| GreenVulpine wrote:
| Unfortunately Steam decks have been out of stock for a
| while. The AI slop Apocalypse ruined the consumer
| computing market with chip shortages.
| stavros wrote:
| I wanted to buy the entire new lineup (Machine, VR, and
| controller), but alas, AI RAM shortage. I hope it can get
| released soon.
| lo_zamoyski wrote:
| > if only Steam would add a checkbox on their checkout
| page to add 10% donation/tip that goes directly to their
| upstream opensource dependencies
|
| Or how about instead of passing the cost off to users,
| Steam actually supports them from their own profits?
| After all, they _are_ profiting from free work.
|
| We can't be pushovers about this.
| InitialLastName wrote:
| As far as I can tell, Valve makes significant
| contributions back to Wine via Proton development. Isn't
| that essentially them supporting their upstream
| dependencies with their own profits, by using some of
| those profits to pay people to contribute work to their
| open source dependencies?
| mietek wrote:
| No.
| danudey wrote:
| Valve pays over a hundred open source developers to work
| on the various open source projects that they rely on so
| heavily, so yeah Valve's 30% of your Steam purchases is
| already contributing to these open-source projects (like
| Mesa, the Linux kernel, Wayland, etc.)
|
| https://www.pcgamer.com/valve-is-paying-a-whole-lot-of-
| devel...
| patmorgan23 wrote:
| Value does pay for development on open source projects
| already.
|
| https://news.ycombinator.com/item?id=34061110
| ErroneousBosh wrote:
| > and should be for most games that don't use kernel-level
| anticheat.
|
| It actually gives a far better user experience for games
| like Battlefield 6, because on Linux they just don't work
| at all. Try it for yourself - it won't even start!
|
| By contrast if you run Battlefield 6 on Windows, eventually
| you'll end up playing it, and you'll wish you hadn't. It's
| a shitty buggy mess and you'll hate it.
|
| So, notch up another score for Linux!
| duttish wrote:
| It's reached the level where a game not working is a
| suprise.
|
| Space Marine 2 was the latest one for me, but Steam is
| great at refunds if you do it quickly enough.
| aranelsurion wrote:
| I remember managing to play Crysis under Linux with Wine and
| I was SO impressed. Never would've imagined one day almost
| every game would be playable.
| spoiler wrote:
| To be fair, early wine (when I first tried it) wasn't very
| usable, and for gaming specifically. So if you were an early
| enthusiast adopter, you might've just experienced their
| growing pains.
|
| Also, I assume some Windows version jumps didn't make things
| easy for Wine either lol
| xattt wrote:
| The hype/performance mismatch was significant in the 2000s
| for Wine. I'm not sure if there was any actual use case
| aside from running obscure business software.
|
| Yes, there was "the list" but there was no context and it
| was hard to replicate settings.
|
| I think everyone tried running a contemporary version of
| Office and Photoshop, saw the installer spit out cryptic
| messages and just gave up. Enough time has passed with
| enough work done, and Wine now supports/getting to support
| the software we wanted all along.
|
| Also, does anyone remember the rumours that OS X was going
| to run Windows applications?
| Fnoord wrote:
| I ran Wine end of 90s to run CS (Half-Life), and I had
| not only more FPS than Windows. It was more stable as
| well.
| aaronbrethorst wrote:
| Red Box: https://lowendmac.com/1997/red-box-blue-box-
| yellow-box/
| zadikian wrote:
| I remember it being surprisingly decent for games back
| then. Then a lot of games moved to Steam, which made it
| way harder to run them in Wine. Of course there was later
| Proton for that, but not on Mac.
| pxc wrote:
| I used WINE a lot in the 2000s, mostly for gaming. It was
| often pretty usable, but you often needed some hacky
| patches not suitable for inclusion in mainline. I played
| back then with Cedega and later CrossOver Games, but the
| games I played the most also had Mac ports so they had
| working OpenGL renderers.
|
| My first memorable foray into Linux packaging was
| creating proper Ubuntu packages for builds of WINE that
| carried compatibility and performance patches for running
| Warcraft III and World of Warcraft.
|
| Nowadays Proton is the distribution that includes such
| hacks where necessary, and there are lots of good options
| for managing per-game WINEPREFIXes including Wine itself.
| A lot of the UX around it has improved, and DirectX
| support has gotten really, really good.
|
| But for me at least, WINE was genuinely useful as well as
| technically impressive even back then.
| ryukoposting wrote:
| It took some futzing. The crusty PlayOnLinux UI is
| permanently etched into my brain.
| brnt wrote:
| Transgaming! It worked for ons or two games for me, bit
| it was glorious.
| ecshafer wrote:
| With Proton especially, which is WINE really optimized with
| all of the right options and a few other things, I play
| literally any game on linux and never worry about support. It
| hasn't steered me wrong yet in the last 3 or 4 years I think.
| figmert wrote:
| Meanwhile I've been impressed with Wine since I discovered
| it. One of the few things that was keeping me from moving to
| Linux was MS Office suite. I struggled to get used to
| OpenOffice. And wine was able to run it. Sure I had to faff
| around with it, but I was just so impressed. I was telling
| all my family, but they just didn't get it.
|
| Anyway, I later stopped using it because Google Docs and then
| later libreoffice was good enough. I still followed it, and I
| continued to be impressed by all the announcements.
| donatj wrote:
| I have been using Wine on Mac for fifteen years now since I
| moved to Mac for work. There's always been a couple Windows
| programs I just can't seem to replace fully, namely
| RegexBuddy, and I continue to run them in Wine to this day.
| Everything has gotten so much better as the years have gone
| on, that this is a perfectly acceptable solution.
| whalesalad wrote:
| The first time I seriously used wine it was to run Forscan
| (https://forscan.org/home.html) to interface with my car via
| OBD2 port. It quite literally just worked. Installed via the
| executable MSI installer, finished install, booted right up,
| and worked with the USB device.
| samus wrote:
| It's an unfair fear since architecturally Wine sits at the
| same position as the Win32 API on Windows, which also in the
| end merely uses the underlying native system calls. The only
| difference is that Linux aims to keep its system call
| interface stable.
| tracker1 wrote:
| You're saying that Windows' system interfaces aren't
| stable? In comparison to Linux?
| ConceptJunkie wrote:
| win32 dates back to 1993. OP doesn't know Windows
| history. Maintaining backwards compatibility was always a
| huge priority for Microsoft, even if it couldn't be
| perfect.
|
| If a program didn't work on a newer version of Windows,
| there's a good chance it was doing something unsupported.
| samus wrote:
| The API _underneath_ the Win32 API, the Windows Native
| API, is not necessarily stable and therefore not intended
| for direct consumption by applications.
| Perepiska wrote:
| I've tried to use Wine in order to play Steam Windows games on
| Mac. Wine silently exposes all my macos drives as D:/F:/etc
| that was open to any game I started. Immediately removed Wine.
| Awful experience.
| dwroberts wrote:
| Wine configuration -> Drives -> Remove
|
| It's like the most trivial thing to change
| dhosek wrote:
| Way back in the 90s when I used OS/2 and running Windows
| applications required running a fully copy of Windows inside
| OS/2,1 I had dreamed of writing something akin to Wine for
| OS/2, but I lacked the knowledge to do it back then (and still
| do). I've never used it since I never use Linux in a context
| that it would make sense (for me, as is the case for most Linux
| users I suspect, Linux is strictly a headless server OS).
| Apparently Wine is also available for the Mac, but these days I
| don't know of a single Windows app2 that I would want to run.
|
| [?]
|
| 1. A frequent debate about the time was whether this was a wise
| thing to do as it reduced the motivation for developers to
| create OS/2-native versions of applications. The slow death of
| OS/2 can be interpreted as both support for those who felt that
| Windows-under-OS/2 was a bad idea and those who felt that OS/2
| was doomed from the start in the face of the Windows monopoly.
|
| 2. Largely because I'm not a gamer--when I've looked at what it
| takes, both in terms of hardware and in learning how to do
| stuff in games, I've decided that I'm happy staying that way.
| alilikestech wrote:
| With AI, you can automate all the grunt work.
| orbital-decay wrote:
| AI unreliability aside, Microsoft suing the hell out of them
| was always a concern. They do clean room reimplementation to
| insulate themselves from legal risks as much as possible,
| another incentive is not what anyone wants.
| stevefan1999 wrote:
| Well about clean room, you almost got a haircut due to
| Google v. Oracle in the Android-Java API dispute
| Kuraj wrote:
| I guess the silver lining is that the Windows ABI is extremely
| stable
| sneak wrote:
| 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
| Windows is no longer a critical component. This is incompetence
| on an unthinkable scale.
|
| I wonder when and how Excel's stranglehold will eventually be
| cracked, and if I will live to see it. Perhaps the new agentic
| universe will cause someone to finally make the Pixelmator of
| Excel.
| jsLavaGoat wrote:
| 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.
| sneak wrote:
| Those aren't the ones I am talking about. The global
| economy runs on Excel.
| MSFT_Edging wrote:
| The EU seems to rapidly be adopting ODF, at least in
| official guidelines.
| stevefan1999 wrote:
| That's not boring at all. A lot of the works done in Wine can
| be fed back to ReactOS
| pyuser583 wrote:
| There was a time when WINE was iffy. At best.
|
| It's gotten good and reliable.
|
| Commendations to contributors!
| JKCalhoun wrote:
| I was rewriting an old game of mine using SDL2 for release on
| Steam--had struggled with getting a build target for
| Linux/Steam Deck.
|
| Man, Wine just worked and I confess I copped out and just
| delivered MacOS and Windows targets.
| brightball wrote:
| If any Wine devs are reading this, I'd love to see a talk on this
| topic at the 2026 Carolina Code Conference. Call for Speakers is
| open until March 31st.
| watashiato wrote:
| 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 the performance
| increase is real, please temper your expectations. A few titles
| might also run slightly worse.
| akdev1l wrote:
| >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.
| foresto wrote:
| Most people? What mainstream Linux distros ship without fsync
| or esync support?
| akdev1l wrote:
| 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.
| foresto wrote:
| The common gaming-focused Wine/Proton builds can also use
| esync (eventfd-based synchronization). IIRC, it doesn't
| need a patched kernel.
|
| The point being that these massive speed gains will
| probably not be seen by most people as you suggest,
| because most Linux gamers already have access to either
| esync or fsync.
| akdev1l wrote:
| Maybe you are right about esync but anyway I would also
| gather a lot of people don't have that either. At least
| personally I don't bother with custom proton builds or
| whatever so if Valve didn't enable that on their build
| then I don't have it.
| foresto wrote:
| > if Valve didn't enable that on their build then I don't
| have it.
|
| The Proton build _is_ Valve 's build. It supports both
| fsync and esync, the latter of which does not require a
| kernel patch. If you're gaming on Linux with Steam,
| you're probably already using it.
|
| https://github.com/ValveSoftware/Proton/?tab=readme-ov-
| file#...
| akdev1l wrote:
| I thought you meant Proton-GE or such other patched
| builds of proton.
| kelnos wrote:
| I would assume most of them? I'd be surprised if distros
| like Debian, Ubuntu, Fedora, etc. would ship non-mainline
| kernel features like that.
|
| Sure, gaming-focused distros, or distros like Arch or
| Gentoo might (optionally or otherwise), but _mainstream_?
| Probably not.
|
| Of course, esync doesn't require kernel patches, so I
| imagine that was more broadly out there. But it sounds like
| fsync got you performance pretty close to what ntsync can
| do, but esync was quite a bit behind both? With vanilla
| being quite a bit behind esync?
|
| (Also, jeez, fsync, what a terrible name. fsync is a
| syscall that has to do with filesystem data. So confusing.)
| nialv7 wrote:
| esync and fsync both use mainline kernel features.
| genthree wrote:
| Last I checked, every distro of note had its own patchset
| that included stuff outside the vanilla kernel tree. Did
| that change? I admit I haven't looked at any of that
| in... oh, 15 years or so.
| akdev1l wrote:
| Depends on the distro.
|
| Fedora looks like it carries a whooping 2 patches on top
| of upstream
| foresto wrote:
| > I would assume most of them? I'd be surprised if
| distros like Debian, Ubuntu, Fedora, etc. would ship non-
| mainline kernel features like that.
|
| It's best not to assume with these things. With my stock
| Debian Stable kernel, Proton says this:
|
| fsync: up and running.
|
| And when I disable fsync, it says this:
|
| esync: up and running.
|
| > But it sounds like fsync got you performance pretty
| close to what ntsync can do, but esync was quite a bit
| behind both?
|
| No, esync and fsync trade blows in performance. Here are
| some measurements taken by Kron4ek, who maintains
| somewhat widely used Wine/Proton builds:
|
| https://web.archive.org/web/20250315200334/https://flight
| les...
|
| https://web.archive.org/web/20250315200424/https://flight
| les...
|
| https://web.archive.org/web/20250315200419/https://flight
| les...
|
| > With vanilla being quite a bit behind esync?
|
| Yes, vanilla Wine has historically fallen behind all of
| them, of course.
|
| > Also, jeez, fsync, what a terrible name. fsync is a
| syscall that has to do with filesystem data. So
| confusing.
|
| We can agree on this. :)
| IshKebab wrote:
| The article says fsync uses futexes which are a completely
| standard kernel feature.
| jabl wrote:
| If you read more carefully it says fsync needs some
| enhancements to the futex API, called futex2. The original
| patch that fsync needed called the syscall
| futex_wait_multiple. Eventually futex2 made it into the
| mainline kernel, but the syscall is called futex_waitv. Not
| sure if the wine fsync implementation was updated to
| support the mainline kernel futex2 implementation.
| damentz wrote:
| Unless you are running an ancient LTS distribution, you at
| least have fsync. But then also recognize, with the ancient
| LTS distribution not carrying any enhancements for the last
| few years, your drivers are also out of date and games will
| play terribly for unrelated reasons.
| tremon wrote:
| "Have fsync" is not a sufficient requirement. You need a
| kernel with windows-compatible fsync patches, and many
| distributions do not ship those.
| kvemkon wrote:
| > usually in the lower single percentage range
|
| Is it worth to compare Wayland vs X11?
| Night_Thastus wrote:
| 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......
| k33n wrote:
| What's wrong with the Nvidia drivers for Linux?
| Duralias wrote:
| In practically every benchmark the Linux Nvidia drivers
| notably underperform compared to the windows driver.
| Night_Thastus wrote:
| 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.
| rounce wrote:
| 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.
| braiamp wrote:
| The only problem with Nvidia in the last... 5 years was
| their wayland support and their worse than expected
| performance for DX12 games. Both of which were being
| actively worked on, where wayland support has been
| improving since 2 years ago and DX12 performance needs
| patches on all the stack, the driver is there, mesa and
| vkd3d patch are pending.
| drnick1 wrote:
| This is not true at all. I game on Linux (Arch, btw) on my
| 3090 and every game not using some kind of kernel-level
| anticheat just works. I have never made formal comparisons,
| but my experience is that I can't notice a difference in
| performance relative to Windows most of the time. One
| exception was Helldivers 2, but the performance gap has
| more or less closed recently with recent Proton versions.
| DeathArrow wrote:
| While I am not a big gamer anymore, I am curious whether this new
| Wine release make it possible to run Windows software such as
| Photoshop or Visual Studio on Linux with decent speed and decent
| resource usage.
| hungryhobbit wrote:
| Linux runs VS Code just fine. If you mean the larger Visual
| Studio suite ... why on earth would anyone want to run that
| garbage pile on Linux?
| dmitrygr wrote:
| At least for the last decade Visual Studio and Photoshop ran
| just fine on wine.
| xuhu wrote:
| I hope Photoshop runs in the Linux VM introduced with Android
| 16, so I can stop carrying a laptop to edit photos and bring
| just a 0.5kg monitor instead.
| SeriousM wrote:
| Does it finally support visual studio?
| metalliqaz wrote:
| the NTSYNC change is for video games, doesn't help VS
| SeriousM wrote:
| Yes, true. And the 64bit support may help visual studio,
| right?
| LetsGetTechnicl wrote:
| 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.
| jordand wrote:
| 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.
| bombcar wrote:
| The WoW64 including 16 bit support is actually pretty big.
| Microsoft dropped it years ago.
| senfiaj wrote:
| If I'm not mistaken, 16-bit x86 software cannot naively run
| in 64-bit mode anyways. It requires an emulator, like DosBox.
| Wine uses WineVDM. CPU-heavy 16-bit programs, or programs
| that are sensitive to timing, can be noticeably slower.
| lifis wrote:
| 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 neither esync or fsync do this though - why?
|
| Claude thinks that "nobody was motivated enough to write and
| debug the complex shared-memory waiter-list logic when simpler
| (if less correct) approaches worked for 95% of games, and when
| correctness finally mattered enough, the kernel was the more
| natural place to put it". Is that true?
| evmar wrote:
| I don't know the technical details, but the kernel docs say "It
| exists because implementation in user-space, using existing
| tools, cannot match Windows performance while offering accurate
| semantics." https://docs.kernel.org/userspace-api/ntsync.html
| topspin wrote:
| > 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
| semantics. To do this, Linux kernel synchronization primitives
| and scheduler API must be used. You can read the code[1] and
| observe that this is a compatibility adapter that relies
| heavily on Linux kernel primitives and their coordination with
| the kernel scheduler. No approach using purely user space
| synchronization primitives can do this both efficiently and
| accurately.
|
| [1]
| https://github.com/torvalds/linux/blob/master/drivers/misc/n...
| lifis wrote:
| 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 futex-based parking/unparking system like
| parking_lot does
|
| Obviously this breaks if the shared memory is corrupted or if
| you SIGKILL any process while it's touching it, but for Wine
| getting that seems acceptable. A kernel driver is clearly
| better though for this reason.
| topspin wrote:
| 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
| garaetjjte wrote:
| > 3. WHY IT CAN'T BE DONE WITH EXISTING TOOLS
|
| https://lore.kernel.org/lkml/f4cc1a38-1441-62f8-47e4-0c67f5a...
| dangoodmanUT wrote:
| I had to close 3 ads before even half my screen was the article
|
| And then it never was more than half...
| sph wrote:
| I am glad that a portion of the thousands of dollars I've given
| to Valve Corporation over the years has been gone to improve Wine
| for everybody. I wonder how many developers and contractors on
| the project are paid by Valve.
| philipwhiuk wrote:
| 2/3 of the developers on Wine work for CodeWeavers who have a
| substantial contract with Valve for Proton (a Wine fork/spin).
|
| So most of it.
| ptx wrote:
| 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?
| trentnelson wrote:
| 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 space alone.
| modeless wrote:
| Yeah I was wondering if some native Linux apps might want to
| use it, since it is clearly useful and hard to emulate.
| braiamp wrote:
| Linux native semaphores are enough. Linux has been able to
| be very performant without it. That feature seems like way
| too over engineered for little gains.
| gpderetta wrote:
| This comes up often, but what can it do that poll can't?
| dwattttt wrote:
| Reading the link provided by
| https://news.ycombinator.com/item?id=47511778, I believe
| "atomically acquire multiple objects". The link states they
| try to emulate it by performing a poll then a read, but the
| gap between those results in a race, which is a terrible
| thing to have in a synchronisation primitive.
|
| There was also something about needing to back out if any
| of the reads fails to acquire, which also sounds nasty.
| gpderetta wrote:
| Great post.
|
| Ah, interesting, so wfm does both the wait and the
| acquire!
|
| When using eventfd it is indeed annoying having to both
| poll and later read to disarm the object (there are epoll
| tricks that can be used but are not generalizable).
|
| The signal+wait is also a primitive that it is hard to
| implement atomically on posix.
| evmar wrote:
| 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....
| vintagedave wrote:
| 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?
| evmar wrote:
| Hey thanks! I don't mean to hijack this great wine news with
| my own project, but since you asked, the top of the post has
| links to more. I will fix the link.
| mschuster91 wrote:
| > This might sound like a small quality-of-life improvement, but
| it's a massive piece of engineering work. The WoW64 mode now
| handles OpenGL memory mappings, SCSI pass-through, and even
| 16-bit application support. Yes, 16-bit! If you've got ancient
| Windows software from the '90s that you need to run for whatever
| reason, Wine 11 has you covered.
|
| Does that also apply to macOS? Even on Intel machines, Apple
| dropped 32-bit support many many years ago and IIRC it took ugly
| workarounds that weren't ever part of upstream WINE but of
| Crossover.
| hatmanstack wrote:
| Anybody know if NTSYNC support is why the Chrome OS team moved
| away from native Steam support?
| Blackthorn wrote:
| I've heard in the past that ntsync is a big deal for audio
| plugins via yabridge as well. Not sure how much that's going to
| reduce the existing CPU penalty there.
| oompydoompy74 wrote:
| Not that it really matters, but does this article read as LLM
| authored to anyone else?
| Twisol wrote:
| I saw signs of both human and LLM authorship, so it's probably
| at least not _slop_. It did take me out of it a bit though,
| yes.
| mft_ wrote:
| This is great.
|
| Not to sound snarky, but now please get it to run Microsoft
| Office. I'd argue that this is the last barrier to many, many
| people being able to use Linux full-time for business purposes.
| SV_BubbleTime wrote:
| Entirely.
|
| If you _really / actually_ want Linux and Linux Gaming to
| really take off, contribute with whatever helps to get Office
| 365 running in Linux without a VM.
|
| Like it or not, the business world runs on Office.
|
| I have quite a few machines under my direction, and I would
| drop Windows on every single one of them for employees that
| have never used Linux in their lives if I could be assured that
| they had Office and Teams.
| Levitating wrote:
| > Like it or not, the business world runs on Office.
|
| Maybe if EU requires local governments to use LibreOffice (or
| other OSS alternatives like MijnBureau) companies will
| follow.
|
| https://www.libreoffice.org/discover/who-uses-libreoffice/
|
| https://minbzk.github.io/mijn-bureau/
| IshKebab wrote:
| I don't know if it is. Most businesses seem to use the web-
| based Office365 interface now, rather than native Office.
|
| I expect the biggest reasons businesses use Windows these days
| are momentum, and lower support costs (Linux is still less
| reliably than Windows on real laptop hardware).
| mft_ wrote:
| I work in an area where large heavy collaborative Word
| documents are very commonplace.
|
| I've tried very much to make this work on Linux with the web
| apps, but they're just not good enough - not feature
| complete, and quite slow and clunky compared to the native
| equivalent.
| scott01 wrote:
| I don't think so. Windows is very easy to administer compared
| to both, Linux and Mac. There is also a compliance part that MS
| makes easier, though it's a bit beyond what I really know.
| basemi wrote:
| I'm not an heavy o365 user but i'm almost happy on Debian KDE
| with thunderbird 148[0] (email only), teams-for-linux[1]
| (chat/calendar/whatever), Onedrive[2] and webdav
| (sharepoint)[3]. Libreoffice/Onlyoffice for documents.
|
| [0] https://blog.thunderbird.net/2025/11/thunderbird-adds-
| native...
|
| [1] https://github.com/IsmaelMartinez/teams-for-linux
|
| [2] https://github.com/abraunegg/onedrive +
| https://github.com/bpozdena/OneDriveGUI
|
| [3] Store the SP cookie via konqueror visiting the SP site,
| then open it in dolphin via
| "webdavs://CORP.sharepoint.com/sites/SITE/Shared Documents/"
| (sometimes the cookie is very short-lived)
| mft_ wrote:
| I tried very hard to make something similar work for a couple
| of months - Mint, teams-for-linux (which is great,
| actually!), web-apps for everything else.
|
| The main problem is Word - for the documents I regularly work
| with professionally (large, complex, collaboratively-edited)
| the web-app is just not feature complete and sometimes
| struggles to cope.
|
| Also, FWIW, the web Powerpoint is an awful experience.
|
| After a brief flirtation with a virtual machine for Windows
| and Office (nah) I had to take a step back from Linux and use
| a Mac again.
| childintime wrote:
| I'd consider using it as Windows replacement. Exclusively
| Windows, as I don't care for the Linux applications, or
| anything Linux, at all. I don't enjoy being an admin, and the
| system is more stable without package management. Linux is a
| fossil from the age of the admin, best used today to emulate
| Windows, just like it runs under Android, as a HAL. If so, 2026
| could be the year of the Linux desktop!
|
| ReactOS is always almost there.. except it doesn't quite get
| there; same goes for Wine, as they have a lot in common?
| mifydev wrote:
| Hm, speculating a bit, but it feels like NTSYNC is essentially a
| beginning of NT Subsystem for Linux, or maybe ntoskrnl as a
| kernel module. Feels like the most clean and fast way to port
| Windows, since the rest of the interfaces are in the user space
| in real Windows. Essentially should be almost without overhead:
| user: [gdi32.dll,user32.dll,kernel32.dll -> ntdll.dll] -> kernel:
| [ntoskrnl.ko]
| gigel82 wrote:
| Support for Xbox Game Pass games (typically deployed as UWP /
| containerized) would be absolutely amazing and likely the final
| nail in the coffin for Windows for gaming for many people.
| sourcegrift wrote:
| I'd rather they focus on productivity apps than games. Linux has
| enough toxic users as it is. I'll praise wine when I can install
| 12yo office 2014
| igravious wrote:
| "And because Proton, SteamOS, and every downstream project builds
| on top of Wine, those gains trickle down to everyone."
|
| the gains would trickle up, no?
| igravious wrote:
| Here's a link to try it
|
| https://www.codeweavers.com/crossover/download
| SeriousM wrote:
| Flagged as advertisement
| SXX wrote:
| What advertisement?
|
| Codeweavers is literally the company behind Wine. Without
| them project would never reach point where it is now.
|
| Codeweavers developers historically been authors of 2/3 (and
| likely even more in past) commits in Wine.
| igravious wrote:
| Uh?
|
| CodeWeavers : Wine :: IBM/RedHat : Fedora
| tuananh wrote:
| I know that Wine devs are doing most of the hard works but also
| Valve team for doing the last mile: pushing for better UX, faster
| patches, pushing adoption (with their Deck device), etc...
| pojzon wrote:
| For someone gaming on linux, is proton or wine currently ahead on
| the virtualization side?
|
| Can we finally ditch windows ?
| Nican wrote:
| I am trying to read this article on my phone without an ad
| blocker, and it is an impossible challenge.
|
| Ads keeps loading and unloading, causing the page to jump around,
| and lose track of what I was reading.
|
| The article is really interesting, but I am actively getting
| frustrated with my phone.
| BatteryMountain wrote:
| Steam devs if you are reading this: add a checkbox on your
| checkout screen that will allow me to donate 10% or a flat amount
| with each purchase, that will go directly to your upstream
| opensource dependencies like Wine & friends. I would add money to
| each purchase without blinking to support these people and I
| think the correct place for this is at the steam checkout screen,
| in the case for gamers.
| hnarn wrote:
| This is a nice idea, but how do you follow through in practice?
| Who decides what counts as an "upstream dependency", where do
| you draw the line? Is the Linux kernel included? Are desktop
| environments included? How do you decide how much of the pot
| goes to each project, does curl get an equal amount to Wine?
| Why/why not?
|
| As I said, it's a nice idea but I have a feeling the complexity
| behind making this work well is what might have kept them from
| doing it.
| BatteryMountain wrote:
| So the steam devs can most likely produce a finite list of
| all their dependencies. They can then take a day or two to
| score each one with a weight. Then they use the weights to
| determine how to split the funds. Or they can have an open
| source champion person internally that takes care of
| relationships with opensource projects and can release funds
| to them as needed. Point is, lets say they accumulate
| $1M/year this way, it is that person's responsibility to
| distribute it fully back out to the community. Obviously try
| to keep it super simple & transparent. They can even ask game
| developers each quarter who they should think need money or
| which problems were solved well for them this round, as an
| extra layer of input.
| SomeUserName432 wrote:
| And how would you determine that the buyer intends to play
| on linux, and not windows like 9x% of the buyers?
| BatteryMountain wrote:
| This extends past linux. Open source projects get used
| broadly regardless of runtime environment. Steam is just
| one open nerve ending where this could be used for good
| and they have the power to do so (and from what we've
| seen, steam seems to be a low friction company, less
| corpo red tape - would you trust say Ubisoft with
| handling this or steam?). If a game gets deployed to
| windows, it doesn't matter, as each game/application
| probably use five or ten or more open source projects
| regardless of where they run. It can help open source
| devs keep pacing with steam and game developer needs.
| Remember a ton of these project have upstream effects
| outside of gaming - its just the most obvious open nerve
| we can use to help open source.
| jojomodding wrote:
| You can only show the checkbox on Linux. You can add OS
| detection to the checkbox and have it say "support our
| $OS dependencies" and put that into different pots of
| money. You can make the checkbox say "support our Linux
| dependencies" and then rely on Windows people not
| selecting it.
| asimovDev wrote:
| might as well just buy Crossover to support Wine
| samus wrote:
| Steam and most other nontrivial applications use other open
| source components internally. Those need funding as well.
| thn-gap wrote:
| They can take it from the current 30% cut
| cpx86 wrote:
| When it comes to Wine, aren't they already doing this? Steam
| develops Proton in cooperation with CodeWeavers, who are the
| main sponsors of Wine, and parts of that work is upstreamed to
| the Wine project. The NTSYNC patch from what I can tell was
| also submitted by a CodeWeavers employee, so it doesn't seem
| far-fetched to say that Steam probably contributed to making
| this happen in Wine.
| BatteryMountain wrote:
| There are many other open source projects that gets used that
| never sees the spotlight like Wine does, but they are crucial
| too. Think audio codecs & processing, compression libs,
| networking libs, even sqlite. Our society depends on these
| projects too but there are too much friction for normal
| people to contribute to them (if they are even aware). Steam
| checkout is a low friction surface where normal people spend
| time. A small optional checkbox at the bottom with a two
| sentence explanation or link to a blog post to explain where
| the money goes, will add minimal new friction while giving
| people the opportunity to contribute to something meaningful.
| I think many gamers (esp adult ones) knows what open source
| means and they will actually contribute now & then. Fund
| allocations must be transparent (crucial!) so people can see
| where the money went.
| cpx86 wrote:
| Oh absolutely, I would welcome some way of sponsoring such
| projects in general. I just meant to highlight that for
| this particular feature and project, there is already a
| form of sponsorship happening.
| Prunkton wrote:
| so apparently it is Proton GE 10.9 from July'25 adding ntsync
| support [0].
|
| I'm playing on wine now for several years now, my deepest respect
| for the developers involved. Thank you!
|
| [0]: https://www.linuxcompatible.org/story/geproton109-released/
| dmos62 wrote:
| I wish competitive shooters (or rather their anti-cheats) would
| run on Linux. Only reason left to use Windows.
| angelfangs wrote:
| Running most of my VSTs with wine + yabridge. Amazing that
| transcription layer/emulation software end up having less issues
| than running shit native.
| alfanick wrote:
| I would happily pay even a _subscription_ to Wine, if they manage
| to get Lightroom running smoothly. So far I need to run VM or use
| a Mac just to do that.
| eb0la wrote:
| I would pay if I can use Clip Studio Paint without lag. In
| fact, I will try another time this easter. If works, I will
| need to donate.
| beAbU wrote:
| Codeweavers.com
|
| They'll take your money, and you'll be contributing to wine.
|
| It looks like they do commercial wine projects. Might cost more
| than a coffee a day tho!
| alfanick wrote:
| CrossOver support of Lightroom is just as bad a wine...
| Realistically it will take $20-50k of dev work to make it
| work (and some other apps as a side effect).
| neonstatic wrote:
| > Wine 11 is different. This isn't just another yearly release
| with a few hundred bug fixes and some compatibility tweaks. It
| represents a huge number of changes and bug fixes.
|
| What's the point of being a "journalist", when your job is to
| write words and instead a machine has written them? What is the
| point of such a "journalist"?
|
| P.S. I am assuming "Lead Technical Editor" falls under the
| umbrella of "journalist" in some sense
| AdamConwayIE wrote:
| Hey, article author here!
|
| I've been writing for nearly a decade, and I can assure you,
| all of this is human written. I've long been writing about the
| Linux kernel where it's been relevant to my coverage, and there
| are articles under my name talking about low-level technical
| aspects in drivers and kernels from as far back as 2017.
|
| I get that it's hard to know what to trust out there given that
| Dead Internet Theory is beginning to feel like a reality, but
| comments like this can be quite upsetting after spending days
| researching and writing an article like this. I totally get
| criticism of the article itself, and I'm fine with that, but it
| feels as if people are too quick to jump on the "must be
| written by AI" bandwagon. I receive it, my colleagues receive
| it, and for the people who I know put in so much effort into
| their work, it can be upsetting to them as well.
|
| As was mentioned in another thread, there were actually a
| couple of typos in this article when it went live. I cleaned
| those up once they were pointed out, but AI doesn't make typos.
| I get it to an extent; hostility and accusations of all kinds
| have been levied at writers for the years and years I've been
| in this industry writing long-form content and analysis. But
| with the proliferation of AI, that hostility has really ramped
| up over the last couple of years.
| neonstatic wrote:
| Apologies if my post hurt your feelings and I appreciate you
| taking the time to respond. The writing style in the piece I
| quoted looked very AI driven to me, that's why I said what I
| said.
| razkaplan wrote:
| The story was picked and featured autonomously by the rabbit hole
| agentic show - https://www.youtube.com/watch?v=rWQRmasdSu0
| noisy_boy wrote:
| If someone is interested in hearing the author Elizabeth Figura's
| views on Wine and Proton:
| https://www.youtube.com/watch?v=ZNBKTolL5oQ
| jackhalford wrote:
| I wonder if having a /dev/ntsync device could make it easier for
| game devs to compile their games for linux in the first place,
| instead of having to use wine. There may be other windows
| specific dependencies though, but this is one less right?
___________________________________________________________________
(page generated 2026-03-25 23:01 UTC)