Very interesting. So it's very similar to WSL on Windows (not WSL2), where it translates Linux syscalls into the appropriate Zircon ones.
From the proposal:
> An important cautionary lesson we should draw from WSL1 is that the performance of starnix will hinge on the performance of the underlying system services that starnix exposes to the client program. For example, we will need to provide a file system implementation with comparable performance to ext4 if we want Linux software to perform well on Fuchsia.
Windows NT was also originally implemented with translation layers for OS/2 and POSIX.
The WSL is a revival of the POSIX layer.
"Broad software compatibility was initially achieved with support for several API "personalities", including Windows API, POSIX, and OS/2 APIs – the latter two were phased out starting with Windows XP."
Even WSL1 is technically very different from the old POSIX layer. The old POSIX layer used classic NT processes and POSIX APIs were routed in user space to NT syscalls via ntdll. WSL1 uses lightweight picoprocesses and implements the Linux syscall API in-kernel, rather than doing POSIX API to NT syscall mapping in user-space. Windows NT POSIX (and Interix/SFU/SUA) are conceptually much closer to Cygwin than to WSL1.
> So it's very similar to WSL on Windows (not WSL2), where it translates Linux syscalls
I wonder whether they will end up with the result of falling back to a real Linux kernel running in a VM eventually if they go with this route, as WSL -> WSL2 ended up with.
These userspace runners seem pretty revolutionary, especially their ability to catch syscalls. As I understand it, this is what WINE is trying to add to Linux (so that they can correctly emulate Windows calls for some DRM/anti-cheat).
This is very, very, cool stuff. It positions Fuschia as approximate to a lingua franca OS.
At the end of the day, x86 is x86. Different operating systems use different loaders/dynamic linkers, different filesystem layouts, different APIs, but still the same machine code and still the same calling conventions. WINE, in a nutshell, merely presents the Windows environment (by wrapping Linux calls in Windows calls) to an executable that is running otherwise natively, there isn't a virtual machine or an emulator involved. There is no sandbox or security (as that is a non-goal).
The problem is that various DRM and anti-cheat products use undocumented Windows syscalls to do their job, and syscalls are something that you can't just wrap with a function. This extension will allow WINE to ask Linux to send it unhandled syscalls (via SIGSYS), so that it can emulate them (making it a misnomer for the first time).
Unfortunately you can no longer create syscalls in NT subsystems (XP was the last time that was possible). I assume you have to be Microsoft, or a specially privileged partner with source access, in order to do that.
