[amiga386]

Cygwin is WINE in reverse. It provides POSIX APIs in a Windows DLL, and the implementation tries to map them immediately to Windows API calls. You should then be able to take source written for Unix and you should be able to compile it and have it run on Windows.

MinGW is a GNU toolchain for writing Windows-native software... that happens to be used quite often to compile Unixy non-Windows software, so they added MSYS which is derived from Cygwin and works like Cygwin (a DLL providing POSIX APIs implemented using Windows APIs), to make it easier to compile and run Unixy software unmodified.

WSL is a VM that runs your choice of Linux kernel and distro as a guest OS, and adds integrations with the host system that make it seem much more native than it really is.

[kevin_thibedeau]

WSL2 is a VM. WSL1 is Wine in reverse. They run ELF binaries compiled against the Linux ABI. Cygwin/Msys is a Posix compatability layer for PE binaries.

[ryao]

I thought WSL1 implemented Linux's ABI in the NT kernel and uses a Linux userland. Wine reimplements the a Windows userland and emulates NT kernel services in userland. The two do not seem the same, although the intention of running Linux software on Windows is the opposite of the intention of letting UNIX system run Windows applications.

[lproven]

> I thought WSL1 implemented Linux's ABI in the NT kernel

Yeah, I thought that too, and said so in an article. It would be the clean, logical, elegant way to do it and inline with the history of NT.

I got angry denials from several Microsofties on Twitter!

It isn't at all.

WSL1 is an offshoot of the now-cancelled Android runtime for Windows.

They wanted to run Android's JVM/Dalvik apps on Windows Mobile... but discovered more and more native OS calls. So, they ended up implementing 90% of a Linux kernel emulator in userland.

Later, they made it standalone and complete enough to run a real Linux userland on top, and marketed it as a Linux runtime.

It is tragic to me that senior MS execs are now proud of this approach and scolded me for thinking otherwise.

My conclusion is that MS no longer has:

• Any kernel engineers who really understand how NT works deep down;

• Anyone skilled enough to modernise the NT kernel's POSIX personality to be Linux personality;

• Anyone in authority who realises it ought to have these things;

• Nobody left who feels shame at this.

[jborean93]

They call them pico processes and have documented them quite well [1]. The pico processes has a userland and kernel component and is quite interesting from a technical perspective.

[1] https://learn.microsoft.com/en-au/archive/blogs/wsl/pico-pro...

[kevin_thibedeau]

That's a byproduct of NT being designed from the start to have subsystems for alternate execution environments and was the path of least resistance. Conversely, it wouldn't be logical to make Wine tightly integrated into the Linux kernel when it had broader portability goals.

[ryao]

Interestingly, they recently pushed ntsync into the Linux kernel specifically for use by wine.

[haolez]

This is WSL2, right? I had the impression that WSL1 provided a better experience, but it was too complex to maintain and Microsoft decided to take the easy road.

[mikepurvis]

Yes WSL2 is a mini-VM. Having used both, I don't think it's a slam dunk that 1 was better, really just different.

Particularly for the more complex cases of container APIs, GPU access, desktop integration, etc. Those are solved problems in the VM space and reinventing new solutions at a slightly different layer is not necessarily wise or realistic.

[apatheticonion]

but also WSL2 doesn't add anything of value to the development experience on Windows that wasn't already possible with a VM.

For my use cases, I just want to target unix-like APIs and use bash-isms so I can reuse my build scripts and tooling. I don't really care if the binary format I consume or compile to is different to Linux - as long as my development experience is identical across MacOS, Windows and Linux.

A thin layer on top of Windows that mimics Linux so I can run bash _properly_ is all I really need.

The closest I've come is using Msys2 with zsh and uutils and it is so close but there are still cases where it simply doesn't work. WSL1 was pretty close but it falls short by needing remote development tools and having isolated storage/poor performance interacting with host storage.

WSL2 is DOA for me, I just hand roll my own Linux VM and call it a day.

[amiga386]

The thinness is actually part of the problem. POSIX and Windows APIs don't work like each other.

For example, if you were a Unix archiver extracting a file, you'd call stat() open() write() close() chmod() utimes(). On Linux/BSD that's 1 file open/close, but on Windows, that's 4 file opens/closes because the Windows APIs need an open filehandle, while the POSIX APIs take a filepath. Linux/BSD have LRU caches of filepath->inode because they're designed around these APIs, Windows doesn't. Cygwin has to open/close a Windows filehandle each time because it can't make the calling code pass a filehandle instead.

So it may be more comfortable and familiar, but also Windows APIs are unsympathetic to code designed for Unix originally.

See this talk on how the developers of rustup massively improved their performance on Windows by restructuring their code: https://www.youtube.com/watch?v=qbKGw8MQ0i8

[adgjlsfhk1]

I do think that talk is way too kind to the windows design. they're trying to make the argument that windows filesystem isn't slow, but the talk is how fixing the problem took 3 months of optimization and direct help from Microsoft. all of this could be avoided if Microsoft made their filesystem not ridiculously slow

[p_ing]

NTFS/ReFS are not slow. But there is an extensible file system filter layer above them that can slow things down.

[mikepurvis]

I find the filesystem and network integration to be a lot nicer than I what I get from a Virtualbox VM. Having the WSL system able to see the host as /mnt/c and also have the WSL filesystems appear in Windows Explorer is pretty darn convenient.

I know conventional VMs do this kind of thing too, but I've always found it more awkward to set it up, you have to install special tools or kernel modules, etc. With WSL it just works out of the box.

[trallnag]

WSL2 supports all the good stuff like systemd. With WSL1 I'd have to rely on Windows utilities or handroll a lot more things

[bornfreddy]

> WSL2 supports all the good stuff like systemd.

That has to be sarcasm, right?

Then again, I see WSL as a poor man's Linux ("poor man" being a developer in some enterprise who can't pick their tools freely due to some IT policy).

[trallnag]

I like systemd. But I only know and use it superficially, mainly for fairly simple units that are sometimes running on a schedule.

And while WSL is worse than Linux without Windows, I still prefer it over MacOS with Linux running in a VM.

[freedomben]

I felt the same way. WSL1 was game changing, while WSL2 isn't much better than just running my own VM, and in some ways is worse.

The one exception: my God filesystem performance on WSL1 was ass, and not an easy problem to fix

[teo_zero]

> A thin layer on top of Windows that mimics Linux so I can run bash _properly_ is all I really need.

Something like skeeto's w64devkit? https://github.com/skeeto/w64devkit

[red_admiral]

For a subset of "run shell scripts", I'm a fan of the one-executable-file busybox for windows.

[EasyMark]

pulling up terminal running WSL instead of running a VM is a superior experience to me when all I need is terminal coding and python/bash scripting without having to block off a chunk of RAM for a virtual machine

[pjc50]

WSL1 mapped Linux file API calls directly to NTFS file API calls.

Unfortunately this was cripplingly slow for use in e.g. Git, so they moved to a model which is more of a VM.

[moomin]

Yeah, WSL1 was a great idea but there were so many edge cases. e.g. allocating a gig of memory you’re not actually using is fast in Linux, not so on Windows.

[jandrese]

Is this why Cygwin is such a dog at disk access? It seems like anytime a Cygwin binary needs to open a file it suffers from 100ms of stall.

[heftig]

Pretty much. AFAIK you're waiting for Windows Defender and other hooks to run.

[wvenable]

> but it was too complex to maintain and Microsoft decided to take the easy road.

The insurmountable problem was file system semantics. In Linux, files are dumb and fast. On Windows, files are smarter and therefore also slower. Linux applications expect dumb fast files and they produce a lot of them. Mapping Linux file system calls to Windows file system calls is doable but you can't overcome that difference.

At that point, simply virtualizing the Linux kernel itself is an obvious better solution long term.

[emulio]

> it was too complex to maintain and Microsoft decided to take the easy road.

This is a common confusion. WSL1 is not deprecated, and both WSL1 and WSL2 continue to be developed and supported in parallel by Microsoft.

This is example of bad Microsoft marketing. Maybe they should have added a postfixes instead of numbers: "WSL-native" "WSL-VM" or something like that

[lproven]

> both WSL1 and WSL2 continue to be developed

I have had a 'Softie deny, in person to my face at the Ubuntu Summit, that any further development would occur on WSL1, in 2022.

So I have to call [[citation needed]] on that.

[lproven]

> it was too complex to maintain

Nah. It was fine.

Filesystem access was slow. That meant that Git was slow. And every Linux techie thinks they're the next Torvalds and hacks on code and uses Git, so Git needed to work well.

[nialv7]

Cygwin is not wine. Wine lets you run existing windows executables unmodified on Linux. Cygwin does not let you run ELFs on windows.

[amiga386]

Good point, using wine as the interpreter for PE executables is another cool part of the WINE project.

But it is the case that you can build a Windows application from source on Linux and link it with libwine, in the same way you can build a Unix program from source on Windows and link it with cygwin.dll -- I seem to remember some time ago CorelDRAW (or at least Corel Photo-Paint) was made available for Linux that way, officially supported by Corel.