Most active commenters

    ←back to thread

    Games run faster on SteamOS than Windows 11, Ars testing finds

    (arstechnica.com)
    402 points _JamesA_ | 14 comments | 25 Jun 25 19:40 UTC | HN request time: 0.461s | source | bottom
    1. PaulHoule ◴[25 Jun 25 19:52 UTC] No.44381245[source]▶
    Might be unfair to call Proton a "translation layer" because the Win32 API is not defined in terms of system calls but rather a set of functions exported from a DLL.

    Proton supplies a DLL that implements the Win32 API using Linux syscalls. Windows supplies a DLL that implements that Win32 API using Windows syscalls that you're not really supposed to use directly.

    replies(7): >>44381329 #>>44381882 #>>44382143 #>>44383220 #>>44385052 #>>44385780 #>>44386176 #
    2. homarp ◴[25 Jun 25 20:04 UTC] No.44381329[source]▶
    https://www.winehq.org/ calls it a compatibility layer that translates calls on the fly.

    so 'translation layer' is not that unfair.

    replies(2): >>44381688 #>>44385909 #
    3. PaulHoule ◴[25 Jun 25 20:50 UTC] No.44381688[source]▶
    If it is forwarding to libc() as opposed to syscalls directly than maybe ‘translation’ is fair.
    replies(1): >>44381890 #
    4. shmerl ◴[25 Jun 25 21:12 UTC] No.44381882[source]▶
    Wine is translating Windows ABIs (not APIs) into underlying Linux OS and userland. Translation simply means that normally Windows ABIs are meant to be used on Windows, they aren't native on Linux.
    5. delusional ◴[25 Jun 25 21:12 UTC] No.44381890{3}[source]▶
    I think that's how it started out, and also how a lot of developers still conceptualize it. Wine has had to massively expand that scope to reach the maturity it has now. I think it's kind of straddling the line between "Implementation" and "translation".

    Philosophically its still a translation layer though. It doesn't really care about correctness if the no apps depend on it. Success is in meaningfully running client software. The implementation of the Windows Libraries are just a way to get there.

    replies(1): >>44382285 #
    6. randomNumber7 ◴[25 Jun 25 21:52 UTC] No.44382143[source]▶
    Does it implement sscanf() with accidental complexity of O(n^2) for compatibility?
    7. Melatonic ◴[25 Jun 25 22:14 UTC] No.44382285{4}[source]▶
    I suppose you could say that Wine has "aged" well :-)
    8. Cloudef ◴[26 Jun 25 00:51 UTC] No.44383220[source]▶
    Proton/wine also implements many of those NT syscalls because windows programs do use them directly as well
    9. fithisux ◴[26 Jun 25 07:26 UTC] No.44385052[source]▶
    There is also NanoX. Not fully Win32 replacement, but I think it is a good start.
    10. anthk ◴[26 Jun 25 09:52 UTC] No.44385780[source]▶
    Wine/Proton it's just another Win32 implementation for Unix. Win32 it's a subsystem on top of Windows NT too.
    replies(1): >>44388737 #
    11. Sammi ◴[26 Jun 25 10:15 UTC] No.44385909[source]▶
    Clearly they don't want to come out and say that Wine is an "implementation of windows apis", because that would invite legal issues. But clearly this is what Wine really is for a large part. Some stuff are just shallow shims to Linux apis, while other stuff they need to make more of their own implementation of.
    replies(1): >>44388673 #
    12. Fluorescence ◴[26 Jun 25 11:07 UTC] No.44386176[source]▶
    I really have to respect Wine's persistence (with Proton's help).

    For so long it was one of those "and now you have two problems" technologies and now it looks like it's the slow blade that could actually kill Windows.

    13. WorldMaker ◴[26 Jun 25 16:01 UTC] No.44388673{3}[source]▶
    "WINE Is Not an Emulator" has always said something exactly like that. It hasn't exactly been a "secret" that Wine is an implementation of Windows APIs (and not an emulator/translator).
    14. WorldMaker ◴[26 Jun 25 16:09 UTC] No.44388737[source]▶
    Also, most games are still 32-bit EXEs, so on most PCs today they are running not just in the Win32 subsystem, but the WOW64 subsystem (Windows-on-Windows 64) the compatibility layer of running 32-bit Windows applications on top of 64-bit Windows and its Win32 subsystem (it's still called Win32 on 64-bit, an unfortunate naming bug from massive compatibility break differences between Win16 and Win32 that didn't exist in the 64-bit transition, 64-bit didn't get a new API subsystem, it just upgraded the existing one, mostly).