←back to thread

402 points _JamesA_ | 3 comments | | HN request time: 0.001s | source
Show context
PaulHoule ◴[] 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 #
homarp ◴[] 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 #
1. PaulHoule ◴[] No.44381688{3}[source]
If it is forwarding to libc() as opposed to syscalls directly than maybe ‘translation’ is fair.
replies(1): >>44381890 #
2. delusional ◴[] No.44381890[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 #
3. Melatonic ◴[] No.44382285[source]
I suppose you could say that Wine has "aged" well :-)