5 ms·

> WSL 1 was relatively innovative, integrating Linux application compatibility into the Windows operating system itself Both FreeBSD and Illumos were running L

> WSL 1 was relatively innovative, integrating Linux application compatibility into the Windows operating system itself Both FreeBSD and Illumos were running Linux applications (at various levels of compatibility) many years prior to wsl v1. Joyent even went as far as re-implementing the Docker api to allow running OCI images natively in LX zones. Hence, it wasn't even that novel of an idea.

p_ing 1y ago
NT running POSIX applications pre-dates the existence of FreeBSD by a handful of months. The interesting thing about WSLv1 is the pico process concept, not the syscall compatibility.
wizzwizz4 1y ago
Achieving it on Windows was fairly novel, though: we hadn't had something like that since the XP days.
- hnlmorg 1y ago
  Even that’s not true. cygwin, mingw, and others have been around for decades.
  - wizzwizz4 1y ago
    Those are runtime environments provided by DLLs (requiring recompilation), not Wine-like translation layers. WSL 1 was something special, and it says something that Microsoft ditched it in favour of "we've invented virtual machines for the very first time!!!".
    - hnlmorg 1y ago
      It’s been a while since I’ve played with Cygwin and I do recall there were a lot of stuff compiled for Windows, but couldn’t it also run Linux software run natively too? Admittedly back then I was working for a place that mainly developed in Perl, so I didn’t port a whole lot of ELFs across. So maybe I’m misremembering
      - wizzwizz4 1y ago
        I had to confirm this, but you are misremembering. https://www.sobyte.net/post/2021-11/cygwin-mingw-msys/ https://www.sobyte.net/post/2021-11/cygwin-mingw-msys/ gives a good rundown.
        hnlmorg 1y ago
        Ahhh. It must just have been shell scripts, Perl and the likes that I ran under cygwin then. Thanks for correction
      - deleted 1y ago
        [deleted]
      - bithead 1y ago
        When I was on the team migrating datacenters, we got ahold of tcpdump.exe which didn't need winpcap presumably because it was staticly compiled under cygwin - I'm fairly certain someone didn't write the entire thing including winpcap from scratch. It was nice because getting anything approved by the windows sysadmin group was like changing the tire on a moving truck. It was more than a godsend, because when a windows server was plugging into "the wrong vlan" we could just give them the tcpdump command to capture a CDP/LLDP packet and tell us which switch and port the box was physically connected to.
        hnlmorg 1y ago
        A lot of software from the Linux/UNIX world will have macros to support Windows even without cygwin. For example with tcpdump: https://github.com/search?q=repo%3Athe-tcpdump-group%2Ftcpdump%20win32&type=code https://github.com/search?q=repo%3Athe-tcpdump-group%2Ftcpdu... So it’s not quite the same thing as what we were discussing further up the thread. Though it’s still an interesting anecdote in its own right.
brynet 1y ago
What's interesting is that the syscall-compatibility layers in the BSDs began with SunOS binary compat on NetBSD m68k/32-bit sparc-- which was created by Theo de Raadt. https://marc.info/?l=openbsd-tech&m=161435521906992&w=2 https://marc.info/?l=openbsd-tech&m=161435521906992&w=2 https://github.com/NetBSD/src/commit/6ce3f21 https://github.com/NetBSD/src/commit/6ce3f21 https://github.com/NetBSD/src/commit/1a68594 https://github.com/NetBSD/src/commit/1a68594 He also came to the same conclusion compat layers were a dead end (OpenBSD removed all compat_*(8) support, including Linux).
hnlmorg 1y ago
That’s arguably an easy task though because there is more commonality due to POSIX. But there are plenty of examples of compatibility layers like this throughout computing history. WINE, cygwin, Linux compat, etc. Microsoft even went down this road already in the 80s with Xenix before abandoning the idea of Unix. The only novel part of WSL was the marketing folks
- AndrewDavis 1y ago
  Microsoft had a POSIX personality on NT since its release in 1993. https://en.wikipedia.org/wiki/Microsoft_POSIX_subsystem https://en.wikipedia.org/wiki/Microsoft_POSIX_subsystem Then with the release of XP it was replaced with: https://en.wikipedia.org/wiki/Windows_Services_for_UNIX https://en.wikipedia.org/wiki/Windows_Services_for_UNIX

p_ing 1y ago

NT running POSIX applications pre-dates the existence of FreeBSD by a handful of months. The interesting thing about WSLv1 is the pico process concept, not the syscall compatibility.

wizzwizz4 1y ago

Achieving it on Windows was fairly novel, though: we hadn't had something like that since the XP days.

hnlmorg 1y ago
Even that’s not true. cygwin, mingw, and others have been around for decades.
- wizzwizz4 1y ago
  Those are runtime environments provided by DLLs (requiring recompilation), not Wine-like translation layers. WSL 1 was something special, and it says something that Microsoft ditched it in favour of "we've invented virtual machines for the very first time!!!".
  - hnlmorg 1y ago
    It’s been a while since I’ve played with Cygwin and I do recall there were a lot of stuff compiled for Windows, but couldn’t it also run Linux software run natively too? Admittedly back then I was working for a place that mainly developed in Perl, so I didn’t port a whole lot of ELFs across. So maybe I’m misremembering
    - wizzwizz4 1y ago
      I had to confirm this, but you are misremembering. https://www.sobyte.net/post/2021-11/cygwin-mingw-msys/ https://www.sobyte.net/post/2021-11/cygwin-mingw-msys/ gives a good rundown.
      - hnlmorg 1y ago
        Ahhh. It must just have been shell scripts, Perl and the likes that I ran under cygwin then. Thanks for correction
    - deleted 1y ago
      [deleted]
    - bithead 1y ago
      When I was on the team migrating datacenters, we got ahold of tcpdump.exe which didn't need winpcap presumably because it was staticly compiled under cygwin - I'm fairly certain someone didn't write the entire thing including winpcap from scratch. It was nice because getting anything approved by the windows sysadmin group was like changing the tire on a moving truck. It was more than a godsend, because when a windows server was plugging into "the wrong vlan" we could just give them the tcpdump command to capture a CDP/LLDP packet and tell us which switch and port the box was physically connected to.
      - hnlmorg 1y ago
        A lot of software from the Linux/UNIX world will have macros to support Windows even without cygwin. For example with tcpdump: https://github.com/search?q=repo%3Athe-tcpdump-group%2Ftcpdump%20win32&type=code https://github.com/search?q=repo%3Athe-tcpdump-group%2Ftcpdu... So it’s not quite the same thing as what we were discussing further up the thread. Though it’s still an interesting anecdote in its own right.

brynet 1y ago

What's interesting is that the syscall-compatibility layers in the BSDs began with SunOS binary compat on NetBSD m68k/32-bit sparc-- which was created by Theo de Raadt. https://marc.info/?l=openbsd-tech&m=161435521906992&w=2 https://marc.info/?l=openbsd-tech&m=161435521906992&w=2 https://github.com/NetBSD/src/commit/6ce3f21 https://github.com/NetBSD/src/commit/6ce3f21 https://github.com/NetBSD/src/commit/1a68594 https://github.com/NetBSD/src/commit/1a68594 He also came to the same conclusion compat layers were a dead end (OpenBSD removed all compat_*(8) support, including Linux).

hnlmorg 1y ago

That’s arguably an easy task though because there is more commonality due to POSIX. But there are plenty of examples of compatibility layers like this throughout computing history. WINE, cygwin, Linux compat, etc. Microsoft even went down this road already in the 80s with Xenix before abandoning the idea of Unix. The only novel part of WSL was the marketing folks

AndrewDavis 1y ago
Microsoft had a POSIX personality on NT since its release in 1993. https://en.wikipedia.org/wiki/Microsoft_POSIX_subsystem https://en.wikipedia.org/wiki/Microsoft_POSIX_subsystem Then with the release of XP it was replaced with: https://en.wikipedia.org/wiki/Windows_Services_for_UNIX https://en.wikipedia.org/wiki/Windows_Services_for_UNIX