Check out our Monthly Survey Page to see what our users are running.

A developer for Collabora, the open source consultancy firm that works with the likes of Valve has sent in a Linux Kernel patch aimed at helping Windows games run on Linux through Wine.

From what's noted in the patch titled "[PATCH RFC] seccomp: Implement syscall isolation based on memory areas", which was sent in for gathering comments (RFC = Request for comments), it seems more and more modern Windows applications / games are sidestepping the actual Windows API. The result? It breaks Wine compatibility as "it doesn't have a chance to intercept and emulate these syscalls before they are submitted to Linux".

What they're going for is an addition to the Linux Kernel, to enable them to filter and find out if the calls being done are from Wine itself or from the Windows application being run. They're proposing using the seccomp function, used usually for security purposes but this is in no way a security feature it's just how they're building the functionality for Wine while re-using what's available.

Their new way will avoid some harsh performance penalties too. An existing method would have added a 10% overhead but they say this averages around 1.5% which is a pretty dramatic difference, for something as performance critical as this. Reading over comments and how it's done, it's possible this can help anti-cheat systems too but as always, don't go getting hopes up over early work that's not complete or merged in yet.

You can see the patch here on the mailing list.

Article taken from GamingOnLinux.com.
Tags: Misc, Wine
31 Likes, Who?
We do often include affiliate links to earn us some pennies. We are currently affiliated with GOG, Humble Store and Paradox Interactive. See more here.
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly.
See more from me
31 comments
Page: «3/4»
  Go to:

razing32 1 Jun
Quoting: TheSHEEEPI read "the open source conspiracy firm"... :D

Join our global cabal on Github.
Merge our banking ploy into upstream.
Bug #34176 Free Speech will be patched in next release.
:D
tested a few games didn't notice any improvement now I'm downloading Detroit Become Human (again because I deleted it). 3DMark seems the same, also other games like F2019, Mafia II definitive edition.
F.Ultra 1 Jun
Quoting: CatKiller
Quoting: elmapul"sidestepping the actual Windows API. "
how is that even possible?

So, again, just as I understand it from reading bug reports about a game I'm vaguely interested in rather than from any in-depth knowledge, most programs will use some kind of library when they need to make some system calls to make something happen - libc or ntdll.dll, say - but it's also possible to just make system calls directly: libc and ntdll.dll need to be able to make their own system calls, too, of course. Windows and Linux both use the same mechanism for this (I think it's a processor instruction and registers?) but they use different numbers in the registers: that is, they'll both have a system call number 12, but there's no reason for it to necessarily do the same thing. In fact, which thing gets done by each number changes between versions of Windows, so the developers doing this need to check the version of Windows and use a look-up table to generate their numbers.

Exactly this! on i386 you put the syscall number in the eax register and some other data in other registers depending on the syscall and then you raise the $80 interrupt. On x86_64 they implemented a pure syscall instruction on the CPU.

Here is an old "Hello World" example that calls the sys_write syscall (syscall 4) to write the "hello world" string to stdout and then it calls exit (syscall 1) to let the kernel terminate the "application" with a proper exit code.
 
.data
    s:
        .ascii "hello world\n"
        len = . - s
.text
    .global _start
    _start:

        movl $4, %eax   /* write system call number */
        movl $1, %ebx   /* stdout */
        movl $s, %ecx   /* the data to print */
        movl $len, %edx /* length of the buffer */
        int $0x80

        movl $1, %eax   /* exit system call number */
        movl $0, %ebx   /* exit status */
        int $0x80



Last edited by F.Ultra on 1 June 2020 at 11:53 pm UTC
I hear this may allow WSL in reverse, which would be quite funny running Windows in WSL under Linux and having access to DX12 without needing a virtual machine with pass-through, however that would be VERY far off and wishful thinking.. (surprised or not surprised MS haven't done it already)


Last edited by TheRiddick on 2 June 2020 at 3:47 am UTC
CatKiller 2 Jun
I'm not sure why this didn't occur to me before.

Using system calls directly seems like a very silly thing to do with a Windows game, but that's not necessarily as true for an Xbox game. I think the developers that have done this will still get bitten by the support costs caused by the fragility of their chewing-gum-and-string coding method, but it might not be as insane as it might first appear.

So perhaps Quantic Dream have an Xbox version that they haven't released yet, or they found it easier to go PlayStation -> Xbox -> Windows for some reason.
scaine 2 Jun
View PC info
  • Contributing Editor
  • Supporter Plus
Quoting: F.Ultra
Quoting: CatKiller
Quoting: elmapul"sidestepping the actual Windows API. "
how is that even possible?

So, again, just as I understand it from reading bug reports about a game I'm vaguely interested in rather than from any in-depth knowledge, most programs will use some kind of library when they need to make some system calls to make something happen - libc or ntdll.dll, say - but it's also possible to just make system calls directly: libc and ntdll.dll need to be able to make their own system calls, too, of course. Windows and Linux both use the same mechanism for this (I think it's a processor instruction and registers?) but they use different numbers in the registers: that is, they'll both have a system call number 12, but there's no reason for it to necessarily do the same thing. In fact, which thing gets done by each number changes between versions of Windows, so the developers doing this need to check the version of Windows and use a look-up table to generate their numbers.

Exactly this! on i386 you put the syscall number in the eax register and some other data in other registers depending on the syscall and then you raise the $80 interrupt. On x86_64 they implemented a pure syscall instruction on the CPU.

Here is an old "Hello World" example that calls the sys_write syscall (syscall 4) to write the "hello world" string to stdout and then it calls exit (syscall 1) to let the kernel terminate the "application" with a proper exit code.
 
.data
    s:
        .ascii "hello world\n"
        len = . - s
.text
    .global _start
    _start:

        movl $4, %eax   /* write system call number */
        movl $1, %ebx   /* stdout */
        movl $s, %ecx   /* the data to print */
        movl $len, %edx /* length of the buffer */
        int $0x80

        movl $1, %eax   /* exit system call number */
        movl $0, %ebx   /* exit status */
        int $0x80
Jesus, I'm getting wild, unwelcome flashbacks to the mid-80's and trying to learn 68020 assembler to get a simple text message scrolling smoothly across the screen! I got there, but I paid for that in blood and almost literal tears. Never again!
F.Ultra 2 Jun
Quoting: scaine
Quoting: F.Ultra
Quoting: CatKiller
Quoting: elmapul"sidestepping the actual Windows API. "
how is that even possible?

So, again, just as I understand it from reading bug reports about a game I'm vaguely interested in rather than from any in-depth knowledge, most programs will use some kind of library when they need to make some system calls to make something happen - libc or ntdll.dll, say - but it's also possible to just make system calls directly: libc and ntdll.dll need to be able to make their own system calls, too, of course. Windows and Linux both use the same mechanism for this (I think it's a processor instruction and registers?) but they use different numbers in the registers: that is, they'll both have a system call number 12, but there's no reason for it to necessarily do the same thing. In fact, which thing gets done by each number changes between versions of Windows, so the developers doing this need to check the version of Windows and use a look-up table to generate their numbers.

Exactly this! on i386 you put the syscall number in the eax register and some other data in other registers depending on the syscall and then you raise the $80 interrupt. On x86_64 they implemented a pure syscall instruction on the CPU.

Here is an old "Hello World" example that calls the sys_write syscall (syscall 4) to write the "hello world" string to stdout and then it calls exit (syscall 1) to let the kernel terminate the "application" with a proper exit code.
 
.data
    s:
        .ascii "hello world\n"
        len = . - s
.text
    .global _start
    _start:

        movl $4, %eax   /* write system call number */
        movl $1, %ebx   /* stdout */
        movl $s, %ecx   /* the data to print */
        movl $len, %edx /* length of the buffer */
        int $0x80

        movl $1, %eax   /* exit system call number */
        movl $0, %ebx   /* exit status */
        int $0x80
Jesus, I'm getting wild, unwelcome flashbacks to the mid-80's and trying to learn 68020 assembler to get a simple text message scrolling smoothly across the screen! I got there, but I paid for that in blood and almost literal tears. Never again!

68020 assembler is a league of beauty and non-complexiness above i386 so you should actually feel lucky ;). I have a few hundred floppys with 68000 assembler code in the basement, don't know if they still are readable though...
F.Ultra 2 Jun
Quoting: CatKillerI'm not sure why this didn't occur to me before.

Using system calls directly seems like a very silly thing to do with a Windows game, but that's not necessarily as true for an Xbox game. I think the developers that have done this will still get bitten by the support costs caused by the fragility of their chewing-gum-and-string coding method, but it might not be as insane as it might first appear.

So perhaps Quantic Dream have an Xbox version that they haven't released yet, or they found it easier to go PlayStation -> Xbox -> Windows for some reason.

Just guessing here since I'm #1 not a Windows dev and #2 not a Game dev, but this could be due to some high hopes optimizing since the library calls perform some sanity checks and massaging of the data that you send in so a direct syscall is some ns faster. And there exists lots of projects like this one: https://github.com/JustasMasiulis/inline_syscall that provides easy access to the direct syscalls under Windows.

I guess that based on how "crazy" some of the game devs can by sometimes when they read on some webpage that "do X for performance" then they just do it without thought. One such example was the guy that where porting some game to Stadia and complained about his spinlock behaviour on Linux: https://www.realworldtech.com/forum/?threadid=189711&curpostid=189723 when the real and obvious answer was "don't use spinlocks in userspace, ever", but the dev had used them "for performance" when in the end it turned out that using the proper locks the performance was actually much better :)
CatKiller 2 Jun
Quoting: F.UltraJust guessing here since I'm #1 not a Windows dev and #2 not a Game dev, but this could be due to some high hopes optimizing since the library calls perform some sanity checks and massaging of the data that you send in so a direct syscall is some ns faster.

Me either, but historically there have been some really elaborate things done with games because you really need the performance - timing your game output by where the CRT electron beam is, for example - and you're optimising for that rather than maintainability. On a console it's probably (relatively) legit (and probably took quite a lot of work), since you've got limited hardware configurations and a fixed software environment, any changes to your assumptions come with a whole other console, and if the performance isn't quite there you can't tell your customers to simply buy a better computer. It's not legit when you don't know the hardware, you don't know the software, and all your assumptions can be completely ruined by an OS update, or driver update, or any number of other things that can happen without warning and completely out of your control.
F.Ultra 3 Jun
Quoting: CatKiller
Quoting: F.UltraJust guessing here since I'm #1 not a Windows dev and #2 not a Game dev, but this could be due to some high hopes optimizing since the library calls perform some sanity checks and massaging of the data that you send in so a direct syscall is some ns faster.

Me either, but historically there have been some really elaborate things done with games because you really need the performance - timing your game output by where the CRT electron beam is, for example - and you're optimising for that rather than maintainability. On a console it's probably (relatively) legit (and probably took quite a lot of work), since you've got limited hardware configurations and a fixed software environment, any changes to your assumptions come with a whole other console, and if the performance isn't quite there you can't tell your customers to simply buy a better computer. It's not legit when you don't know the hardware, you don't know the software, and all your assumptions can be completely ruined by an OS update, or driver update, or any number of other things that can happen without warning and completely out of your control.

Oh yes, timing to CRT electron beam is something that I did extensively do in the 80:ies and 90:ies but I don't think that even is a thing with consoles released in the last decade. Regardless it does fit as an example anyway, I did write that they where "crazy" :-)
While you're here, please consider supporting GamingOnLinux on Patreon, Liberapay or Paypal. We have no adverts, no paywalls, no timed exclusive articles. Just good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!

You need to Register and Login to comment, submit articles and more.


Or login with...

Livestreams & Videos
Community Livestreams
Latest Forum Posts