[Info-vax] RMS intro

[Dan Cross]

In article <un1n5c$2q36g$4 at dont-email.me>,
Lawrence D'Oliveiro  <ldo at nz.invalid> wrote:
>On Tue, 2 Jan 2024 12:46:14 +0000, Andy Burns wrote:
>> ... there is a certain technical elegance to the
>> WSL1 mechanism.
>
>When Windows NT was first created, it was supposed to support the idea of 
>"personalities" to allow different kinds of userland apps to run on top of 
>the same core kernel. For example, Win32 was just one kind of 
>"personality", while the POSIX layer was implemented as another kind.
>
>You would think the WSL1 would have been implemented as just another 
>"personality". But no. It appears the whole extensibility of the 
>"personality" architecture has kind of bitrotted away in the years since 
>the introduction of NT, so WSL1 was implemented in its own unique kind of 
>way (don't ask me how).

With the caveat that I have no first-hand experience with the
WSL implementation in the Windows kernel, the mechanism is
likely to be fairly straight-forward.  When the system goes to
invoke an executable program, it examines the image file; for
both PECOFF (e.g., Windows .EXE format) and Linux-styled ELF
binaries, the image formats are pretty well defined and the
kernel can easily distinguish between them.  Depending on which
it is attempting to run, it can select the appropriate loader
and it can install a per-process system call handler.  Traps
into the OS for system calls will then consult the local system
call table for that process and decide how to handle the call.

The interesting bit is inside the kernel, where the different
interfaces are handled using (presumably) a common set of
functionality.

>And, in spite of the fact that it was supposed to be implementing a well-
>documented API, with plenty of example source code to refer to, they still 
>couldn't get WSL1 to work right. So they had to chuck it away and bring in 
>a proper Linux kernel instead.

This is a well-understood problem in the Linux space; gVisor
suffers from a similar issue.

The problem is not that Linux's behavior is well-documented, it
is also what is not documented.  It's not enough to be
consistent with the documented interfaces, but one must also be
"bug-compatible" with the system.  Further, Linux has a
long-standing policy of preserving userspace behaviors, even
when doing so means that the implementation contradicts a
documented interface in some way or another.

Furthermore, the rate of change in Linux is high; following
along from outside is fraught.  And we haven't even gotten
to things like:
https://docs.kernel.org/process/stable-api-nonsense.html

	- Dan C.