Latest Comments by CatKiller
Total War Saga: TROY is now a 12 month Epic Games Store exclusive
2 June 2020 at 4:39 pm UTC Likes: 1
I think (hope) they're saying to wishlist it for Linux on Steam so that Feral don't get totally dumped, but I could be wrong.
2 June 2020 at 4:39 pm UTC Likes: 1
Quoting: GuestNot sure what you're driving at here, you want us to get it free on Epic Store?
I think (hope) they're saying to wishlist it for Linux on Steam so that Feral don't get totally dumped, but I could be wrong.
Total War Saga: TROY is now a 12 month Epic Games Store exclusive
2 June 2020 at 4:31 pm UTC Likes: 12
... because Epic gave us a big bag of money.
2 June 2020 at 4:31 pm UTC Likes: 12
QuoteWhile we know that some of you won’t like the Epic Games Store exclusivity, we feel like this is a great opportunity for us in a lot of ways
... because Epic gave us a big bag of money.
Total War Saga: TROY is now a 12 month Epic Games Store exclusive
2 June 2020 at 4:17 pm UTC Likes: 4
2 June 2020 at 4:17 pm UTC Likes: 4
That really sucks for Feral.
Linux Kernel patch being discussed to help Windows games run in Wine
2 June 2020 at 4:16 pm UTC
2 June 2020 at 4:16 pm UTC
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.
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.
Linux Kernel patch being discussed to help Windows games run in Wine
1 June 2020 at 2:52 pm UTC Likes: 16
They've already done that: that's how they have benchmarks on the relative performance of selectively trapping system calls. And while the Wine devs being able to play All The Games might be nice for them, I expect that they'd quite like other Wine users to be able to as well.
The issue is that Windows applications are using Windows system calls without going through Wine. Those system calls won't work, because Linux isn't Windows, and they can't be translated because they don't go through Wine.
They need a solution that will catch (self-modifying and obfuscated) code that doesn't go through Wine and somehow still make it work for all users, without breaking Wine for everything else. For that, it needs to go to the kernel - since that's where the system calls end up - and it needs some discussion to find the best approach, and it needs the kernel devs to agree that it's a good idea. Hence the Request For Comment.
I would say that the game developers have done something pretty manky, but this is the least-bad way of handling it if those games are to be made to be able to run.
1 June 2020 at 2:52 pm UTC Likes: 16
Quoting: scaineI'm a bit confused as to why they pushed this patch at all. If they only need to establish whether something is happening in Wine, or in Windows, can't they simply apply their patch to a locally-compiled kernel and test a few of the offending games/apps with that custom kernel loaded?
They've already done that: that's how they have benchmarks on the relative performance of selectively trapping system calls. And while the Wine devs being able to play All The Games might be nice for them, I expect that they'd quite like other Wine users to be able to as well.
The issue is that Windows applications are using Windows system calls without going through Wine. Those system calls won't work, because Linux isn't Windows, and they can't be translated because they don't go through Wine.
They need a solution that will catch (self-modifying and obfuscated) code that doesn't go through Wine and somehow still make it work for all users, without breaking Wine for everything else. For that, it needs to go to the kernel - since that's where the system calls end up - and it needs some discussion to find the best approach, and it needs the kernel devs to agree that it's a good idea. Hence the Request For Comment.
I would say that the game developers have done something pretty manky, but this is the least-bad way of handling it if those games are to be made to be able to run.
Linux Kernel patch being discussed to help Windows games run in Wine
1 June 2020 at 2:40 pm UTC Likes: 1
My reading of it was that they don't want to take an approach that will definitely break their anti-cheat work, rather than that this approach will specifically help.
1 June 2020 at 2:40 pm UTC Likes: 1
QuoteReading 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.
My reading of it was that they don't want to take an approach that will definitely break their anti-cheat work, rather than that this approach will specifically help.
Linux Kernel patch being discussed to help Windows games run in Wine
1 June 2020 at 8:09 am UTC Likes: 9
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.
1 June 2020 at 8:09 am UTC Likes: 9
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.
Linux Kernel patch being discussed to help Windows games run in Wine
1 June 2020 at 7:48 am UTC Likes: 8
The opposite. It's so that when a Windows application blindly uses Windows system calls on Linux they can be bounced back to Wine to be interpreted properly rather than naïvely followed or dropped. The seccomp framework already exists for trapping system calls, this is just to handle things more sensibly for this use case so that only Windows system calls need processing and Wine system calls can function unmolested. As I understand it.
1 June 2020 at 7:48 am UTC Likes: 8
Quoting: BeamboomIsn't this to punch holes in the os layer and open up for instabilities, hardware conflicts and massive security issues?
The opposite. It's so that when a Windows application blindly uses Windows system calls on Linux they can be bounced back to Wine to be interpreted properly rather than naïvely followed or dropped. The seccomp framework already exists for trapping system calls, this is just to handle things more sensibly for this use case so that only Windows system calls need processing and Wine system calls can function unmolested. As I understand it.
Linux Kernel patch being discussed to help Windows games run in Wine
1 June 2020 at 7:43 am UTC Likes: 1
The two I read about a little while ago here were Detroit: Become Human and Red Dead Redemption 2. I saw reference to some other culprits elsewhere, too, but I can't remember which they were right now.
1 June 2020 at 7:43 am UTC Likes: 1
Quoting: PatolaDoes anyone know of any current use cases for this patch? Which Windows applications/games skip WinAPI calls to do syscalls directly?
The two I read about a little while ago here were Detroit: Become Human and Red Dead Redemption 2. I saw reference to some other culprits elsewhere, too, but I can't remember which they were right now.
Valve continues to improve Linux Vulkan Shader Pre-Caching
30 May 2020 at 9:07 pm UTC Likes: 11
Shaders are programs that run on your graphics card. When GPUs first became programmable, rather than fixed-function hardware pipelines, the first programs they could handle were for light calculations, so they're called shaders, but every part is programmable now.
The programs are written in whatever language and compiled to a portable Intermediate Representation, which is compatible with whichever cards follow the relevant standards. Those IRs are generally what get distributed with games, but they still can't be run directly. They need to be compiled into a form that will run on the specific hardware.
Once you've compiled the programs it would be handy if you could save them somewhere so that you didn't need to compile them again; that's the shader cache.
30 May 2020 at 9:07 pm UTC Likes: 11
Quoting: BeamboomIf I have understood what a shader is, I can not fathom how this works?
Shaders are programs that run on your graphics card. When GPUs first became programmable, rather than fixed-function hardware pipelines, the first programs they could handle were for light calculations, so they're called shaders, but every part is programmable now.
The programs are written in whatever language and compiled to a portable Intermediate Representation, which is compatible with whichever cards follow the relevant standards. Those IRs are generally what get distributed with games, but they still can't be run directly. They need to be compiled into a form that will run on the specific hardware.
Once you've compiled the programs it would be handy if you could save them somewhere so that you didn't need to compile them again; that's the shader cache.
- Dungeon Clawler will grab hold of your free time now it's in Early Access, plus keys to give away
- Steam getting proper Season Pass support with clearer guidelines and refunds for cancellations
- itch.io store now requires AI generated content disclosures for assets
- Mesa 24.3.0 graphics drivers for Linux released with many new features and bug fixes
- Huge new Proton 9.0-4 update for Steam Deck / Linux now in need of testing
- > See more over 30 days here
-
New Steam Controller 2 and VR controller designs got le…
- chickenb00 -
PlaytronOS Alpha 2 brings expanded NVIDIA support, more…
- pleasereadthemanual -
PlaytronOS Alpha 2 brings expanded NVIDIA support, more…
- LoudTechie -
New Steam Controller 2 and VR controller designs got le…
- FutureSuture -
New Steam Controller 2 and VR controller designs got le…
- Highball - > See more comments
- New Desktop Screenshot Thread
- Hamish - Spare gog keys
- Pyrate - Nintendo-style gaming, without Nintendo!
- Talon1024 - What have you been listening to?
- Linux_Rocks - More updates - social media related
- Klaas - See more posts