Hacker News Reader

Comment by AndrewDavis | Hacker News Reader

> 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.

View on HN

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://github.com/NetBSD/src/commit/6ce3f21

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).

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

Microsoft had a POSIX personality on NT since its release in 1993.

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

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.

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

Even that’s not true. cygwin, mingw, and others have been around for decades.

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!!!".

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

I had to confirm this, but you are misremembering. https://www.sobyte.net/post/2021-11/cygwin-mingw-msys/ gives a good rundown.

Ahhh. It must just have been shell scripts, Perl and the likes that I ran under cygwin then.

Thanks for correction

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.

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%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.

Reply on news.ycombinator.com