The Wine project emulates the Windows API in user space. One particular part of that API, namely the NT synchronization primitives, have historically been implemented via RPC to a dedicated “kernel” process. However, more recent applications use these APIs more strenuously, and the overhead of RPC has become a bottleneck.
The NT synchronization APIs are too complex to implement on top of existing primitives without sacrificing correctness. Certain operations, such as NtPulseEvent() or the “wait-for-all” mode of NtWaitForMultipleObjects(), require direct control over the underlying wait queue, and implementing a wait queue sufficiently robust for Wine in user space is not possible. This proposed driver, therefore, implements the problematic interfaces directly in the Linux kernel.
↫ Elizabeth Figura on the lkml
This proposed driver would yield some serious performance results.
Wine performance is impressive already; sometimes neck and neck with Windows, and occasionally, even beating it.
I just wish more obscure bugs would be fixed, like this one. https://www.protondb.com/app/22120
It goes to show that just because a game starts and runs correctly, does not mean the player will not experience strange behavior while progressing through it. This game is open source, so you would think identifying the problem in Wine would be pretty easy for a skilled programmer.
But again, it demonstrates why people can’t just go giving games a platinum rating because they play through the first ten minutes of it without any issues. (Usually, in my experience, games either work, or they don’t.)
kbd,
They were beating Windows on “micro stutters”.
https://steamcommunity.com/app/221410/discussions/0/3185738591082981557/
Basically when there is a new “shader” (combination of hardware graphics effects), it has to be compiled first to be available. On Windows, with DirectX 12, the application is in charge of proper scheduling of these. And when the shader is not ready for a frame, it has to wait before rendering. Hence “micro stutters” as you walk around. (They are cached on the disk, though, so second time loading the same level will not have the effect).
Anyway, what Proton did with the famous “Elden Ring” game was brilliant. They just do background compilation, and skip the effect for a frame. The game no longer stutters, but could have slightly reduced quality for a few milliseconds.
Mapping synchronization primitives between operating systems can be a nuisance. In the case of linux, the polling APIs require everything to be a file descriptor. This turns out to be very awkward to use in implementing APIs where everything is not a file. And I can see how emulating windows primitive semantics in linux userspace could be quite costly. Even so several hundred percent difference as stated by the link seems excessive. I’d have to watch the full video to find out why there’s that much overhead in emulating NT primitives on linux.
There are more than a few people that do not like “everything is a file” in all cases. Could these APIs end up getting used by Linux native software as well?
Perhaps Linux will implement the Win32 API before ReactOS does.
tanishaj,
Obviously everything is a file is an old unix idea that’s become very prominent. But there are exceptions everywhere and I wonder if we’re using the wrong abstraction. It’s nice to have standardized/enumerable interfaces ala sysfs/procfs/etc, I like that, but it can be very inefficient to program interfaces via file systems. For example monitoring temperatures and controlling fan speeds requires tons of syscalls and file operations. Furthermore linux drivers can resort to very dirty file system abstractions, like video4linux webcams under /dev/video0 that have side channel interfaces that completely break from a neat and tidy file system abstraction.
I understand the justification in breaking with FS semantics, but since we’re breaking the abstraction anyway, I think we might be able to do a better job at doing so in a much cleaner object oriented way than linux manages to do. I’d really like to see an OOP OS and this IMHO is what operating systems should be striving for. Everything is not a file, but rather an object.
This seems to imply it doesn’t implement win32 API. It already does, it’s just that reactos is in perpetual alpha.
I guess I should have said “full Win32 API”. It was a bad joke about not only how long ReactOS is taking but even more about their desire to fully implement Windows Server 2003 before allowing the OS to use more recent APIs. ReactOS is still 32 bit but would be incompatible with most modern software even it was not. For example, Firefox does not support Windows XP anymore because the Unicode libraries stopped supporting it. ICU requires at last Windows 7. Do not plan on using a modern browser on ReactOS.
My frustration is probably less about their progress though and more about the policy of not sharing it with anybody. ReactOS 0.4.15 should have released over a year ago. They have newer NT6+ APIs but they are not enabled. They have a 64 bit version but I have never seen even a test release of it or instructions how to build it.
Linux runs more Windows software than ReactOS does. It is via WINE of course but then again, ReactOS borrows fairly heavily from WINE as well. So, the joke was that, if it starts to add Win32 APIs to the kernel, that Linux may implement Win32 before WINE does.
I should not be so harsh towards ReactOS though. It is a great project. At least not everything is a file. 🙂