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.)

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.

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.

Way back in the 90s when I used OS/2 and running Windows applications required running a fully copy of Windows inside OS/2,¹ 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 app² 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.

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

I simply wouldn’t have the patience to do what Elizabeth did, for a month, much less years. Really really impressive

Yes, Wine is truly a miracle. Once full support for Office is achieved, we should expect huge uptick in Linux adoption.

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.

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.)

* when not using esync nor fsync

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?

>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.

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.

All good. I tell people how to add another mailbox to their Outlook, "click here, now there". Not glorious. Necessary anyways.

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.

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.

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.

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.

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.

Don't feel too bad - I had to Google what CRUD means. :D

Same. I feel like a plumber compared to real engineers.

Play with low level things. It'll help you in your daily job in ways you do not yet imagine. Start here: nandgame.com

>People are dealing with such low level things, while i'm outta here building simple CRUDs.

CRUDs do pay the bills.

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.

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.

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.

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.

This is the very definition of "a good problem to have."

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.

There always will be old games that will never be ported to Linux.

Quiet the other way around. Wine being good will reduce incentives for game studio to produce native Linux ports.

If you game/app runs on Wine, doesn't that reduce the pressure to develop a Linux port?

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

A solution to itself

Gotta get there somehow.

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

OS/2 part deux

It's interesting when old Windows games run better in Wine than in actual Windows 10/11.

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.

> 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...

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

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?

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).

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?

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.

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.

What's wrong with the Nvidia drivers for Linux?

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?

At least for the last decade Visual Studio and Photoshop ran just fine on wine.

Why?

No, the gains here aren't very dramatic when compared properly (against fsync), and have nothing to do with AI help. The gains come down to Linux kernel support for certain synchronization primitives like the Mutex on Windows, such that there is a more direct mapping of what a Windows binary expects to what the Linux kernel provides. See https://docs.kernel.org/userspace-api/ntsync.html for the kernel support that makes this possible.