protonscr

Why don't convert the Windows binaries executable to Linux binaries instead do this at runtime?

protonclosed
ValveSoftware/Proton#5690 · opened 2022-03-17 by ebellumat · updated 2022-03-19 · 9 comments · github
Eebellumat 2022-03-17 github

Hello guys, first, thank you for the project. Proton is one of the most ambitious and successful projects that are already seen on the open source community in my opinion.

I'm not a c++ expert, but, this idea comes to my mind these days.

Why don't convert the Windows binaries executable to Linux instead do all of the work at runtime everytime?

I mean, if we can achieve this translating every instruction and syscalls from a windows binary to Linux Kernel at the runtime and we do the same with the graphic API calls, it's not a good idea we translate the entire binary to a Linux compatible and this way we can have basically a "port of the game"?

Apple does something like that on Rosetta 2, they translate everything from an X86 application to ARM and cache this after the process runs once.

I don't know if my suggestion makes sense or it's a thing to post on the Wine project.

But, thank you for everyone that read this.

Eebellumat 2022-03-17 github

This idea comes to my mind after i seen Valve caching the shadders from Elden Ring on the disk to fix the performance issues from this game specially for Steam Deck.

00x14307 2022-03-19 github

Proton already does that, it converts DirectX calls made by the game to Vulkan so that it can render stuff as it should.

Eebellumat 2022-03-19 github

My idea is not need to use proton on a second time, you know? Export the new binary rewrited for Linux.

00x14307 2022-03-19 github

Doing that would be extremely hard to do. Rosetta is a translation layer that converts instruction calls from X86 to ARM64. What you're suggesting is just Wine but recompiling the application for Linux instead of Windows which isn't needed cause Wine already exists.

Iipr 2022-03-19 github

Problem is if program has runtime checks against modifications (checking that it wasn't modified): those would not work if game was "translated" somehow into a native binary. And that would just mean the game would not work without much more work.

00x14307 2022-03-19 github

This also.

Iipr 2022-03-19 github

Then there's things like self-modifying/generating code. Regardless of what your thoughts are on that (allowable or not) it is a thing some use in reality. And something that is generated on the fly is harder to translate until it is generated (you have to run the program to generate the code).
There are reasons why self-modifying code should not be allowed in various programs but since it happens the compatibility layer just has to support them existing..

Iipr 2022-03-19 github

Google's Android Runtime (ART) generates native code from bytecode when program is installed but those programs are not distributed as final binaries and don't expect to run as such in any case..
Looks like Google has some tools to help porting to Stadia, but these need to be used on the publisher side I think. So this doesn't help Valve which has to run with what publisher decides to push with a massive catalog of older titles as well.

Eebellumat 2022-03-19 github

Thank you @ichbluu and @ipr for explanations. Theres also some problems with software licencing too, i guess. But i still thinking in some Proton tool for developers to generate Linux binaries of the final game. The first vesion of DLSS worked this way, the game have to sent to Nvidia to generate the model on the server side.

Make ports from scratch implyes a lot of work to the developers, even with we use Unity or Unreal sometimes.

But, things is getting better, over and over. Steam Deck is here!

Nothing extracted yet.