• KubeRoot@discuss.tchncs.de
    link
    fedilink
    English
    arrow-up
    2
    ·
    1 month ago

    I might be wrong, but I don’t think proton is either? It’s running x86 instructions either way, wine just provides a way to load it from the windows executable and library formats, and together with proton they provide implementations of windows libraries for those executables to use.

    • bufalo1973@piefed.social
      link
      fedilink
      English
      arrow-up
      3
      ·
      1 month ago

      I guess most of the process is just using a wrapper to translate the call to a Windows library to the equivalent call to a Linux library.

      • KubeRoot@discuss.tchncs.de
        link
        fedilink
        English
        arrow-up
        2
        ·
        1 month ago

        I think most of the work is in the fact that there often isn’t an “equivalent call”, and it can be quite a lot of code to make it work. One funny thing is the whole esync-fsync-ntsync issue, where synchronization is done differently on Linux and on windows, and translating it was a big performance hit, and difficult to do accurately. If I understood correctly, esync, fsync and ntsync were a series of kernel patches implementing additional synchronization code in the kernel, with ntsync actually replicating the windows style.

    • thelittleblackbird@lemmy.world
      link
      fedilink
      English
      arrow-up
      2
      ·
      1 month ago

      As far as I know for the new Vulkans layers and dx12 implementation there is a “translation layer” from the old dx implementation to the most updated one. This is the main reason why old games runs faster on Proton than in w7 for the same hw. Even if they were designed for w7 specifically.

      Last time I checked this was done during the booting of the game, but i have to admit this was time ago and it could have been changed.