Comment by PaulHoule
5 months ago
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.
https://www.winehq.org/ calls it a compatibility layer that translates calls on the fly.
so 'translation layer' is not that unfair.
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.
"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).
If it is forwarding to libc() as opposed to syscalls directly than maybe ‘translation’ is fair.
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.
1 reply →
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.
Does it implement sscanf() with accidental complexity of O(n^2) for compatibility?
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.
Proton/wine also implements many of those NT syscalls because windows programs do use them directly as well
There is also NanoX. Not fully Win32 replacement, but I think it is a good start.
Wine/Proton it's just another Win32 implementation for Unix. Win32 it's a subsystem on top of Windows NT too.
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).