[Info-vax] RMS intro

[Dan Cross]

In article <un75ou$3pjg7$2 at dont-email.me>,
Arne Vajhøj  <arne at vajhoej.dk> wrote:
>On 1/3/2024 8:31 AM, Dan Cross wrote:
>> In article <un293n$2tfib$1 at dont-email.me>,
>> Arne Vajhøj  <arne at vajhoej.dk> wrote:
>>> On 1/2/2024 2:25 PM, Andy Burns wrote:
>>>> Lawrence D'Oliveiro wrote:
>>>>> 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.
>>>>
>>>> I didn't do anything other than "play" with WSL1, but I thought
>>>> performance was the issue.
>>>>
>>>> I think I did more with MKS Toolkit and Cygwin than WSL.
>>>
>>> Note that Cygwin and WSL does completely different things.
>>>
>>> Cygwin:
>>>
>>> *nix and/or Windows source--Cygwin toolchain-->Windows executable
>>>
>>> WSL:
>>>
>>> *nix source--Linux toolchain-->Linux executable
>> 
>> More like:
>
>Less like that.

Nope.

>>            "cygwin executes Windows executables that are built
>> from Unix-y sources using compatibility libraries,
>
>Cygwin does not execute executables. Cygwin produces regular
>Windows executables that are executed by Windows line any other
>Windows executable.

Nope.  Cygwin is an _environment_ that exists under Windows,
along with a user interface, that supports executing Unix-style
programs.  Yes, there's a toolchain, but Cygwin itself is not
only a toolchain.  The more important thing, in many ways, is
the Cygwin DLL that supports cygwin execution.

You may quibble with the terminology here; it is true that
technically _windows_ loads and starts those executables running
and the hardware actually does the execution, but it is saying
that "cygwin produced regular Windows executables" is so vague
as to be outright incorrect.

>And as I described above then Cygwin can build both *nix source and
>Windows source (and hybrids of those) not just *nix sources.

You seem to be referring to the cygwin toolchain, which is only
part of cygwin.  See https://cygwin.com/ for more.

>>                                                   while WSL1
>> executes Linux-branded ELF binaries using a compatibility layer
>> in the Windows kernel."
>
>WSL execute standard Linux binaries - not something just Linux branded.
>And being ELF binaries is not sufficient - it has to be Linux binaries.

These two statements are contradictory.  Colloquially, we call
ELF binaries that are specific to a given ABI "branded" for that
ABI.  From e.g. the FreeBSD manual:

---
BRANDELF(1)             FreeBSD General Commands Manual            BRANDELF(1)

NAME
     brandelf --- mark an ELF binary for a specific ABI

SYNOPSIS
     brandelf [-lv] [-f ELF_ABI_number] [-t string] file ...

DESCRIPTION
     The brandelf utility marks an ELF binary to be run under a certain ABI
     for FreeBSD.
---

(So, for example, `brandelf -t Linux file`.)

So a, "Linux-branded ELF binary" is an "ELF binary" and a "Linux
binary."  People who are familiar with systems programming
understand this terminology readily, but if you have no
experience at this low of a level, it doesn't surprise me that
you would be confused.

>>                                 Toolchains are only tangentially
>> relevant.
>
>Toolschains are really the only thing that matters.

Nope.

>WSL exist to allow developers to run Linux toolchains.

No, WSL exists to allow Windows users to run a "Linux
environment", full-stop, running unmodified Linux-branded
ELF binaries.  Users can, of course, run a toolchain if they
wish, but they are not limited to that; believing so is a
failure of imagination.

	- Dan C.