[syn_rst]

WSL fails in a lot of use cases due to the NT kernel's poor performance when creating processes, slowness in the translation layer when accessing files, and the like.

It's essentially the reverse case of telling Windows users to "just use Wine" - the emulation isn't perfect and some programs won't work well or at all. In a sense, WSL is worse than Wine in this regard since there's usually a Linux-native alternative if something doesn't work in Wine. If something doesn't work in WSL, you don't have a lot of options.

[cwyers]

> WSL fails in a lot of use cases due to the NT kernel's poor performance when creating processes, slowness in the translation layer when accessing files, and the like.

But it's still the NT kernel either way, right? How does having binaries compiled with cygwin or MinGW improve upon what WSL offers here?

[saurik]

It isn't the "NT kernel either way", as you are going through the filesystem translation layer; AFAIK it is implemented as a subsystem, so you are accessing the kernel through an entirely disjoint mechanism.

So like, Microsoft may have fixed this recently, but WSL processes were essentially stuck inside of a filesystem sandbox that uses some inane mechanism to access files via mountpoints that fails to correctly translate the few flags that are supportable by the underlying Windows filesystem, so if you try to do basic things like use WSL's copy of git to manage a git repository stored outside of the WSL sandbox, it just doesn't work correctly.

On the flip side, you also can't run a native Windows process whose binary is sitting inside of the sandbox, as native Windows processes do not have direct access to WSL files. Checking, they seem to have finally added the ability to mount new paths, so that's helpful (if you have network shares or removable media like USB keys, these were previously not accessible via WSL).

The great thing about cygwin and MinGW is that, by and large, it _is_ "just the NT kernel", with nothing more than a userland library sitting between the process and the same kernel interface used by any other Windows application, so tons of stuff "just works" that WSL is having to slowly reimplement.

(FWIW, it could be that Microsoft has fixed some of these filesystem showstoppers since I last tried to seriously use WSL; if so, that's exciting, but it doesn't change the reality of why people are looking at these are very different ways of running programs.)

https://blogs.msdn.microsoft.com/wsl/2017/04/18/file-system-...

> In the latest Windows Insider build, the Windows Subsystem for Linux (WSL) now allows you to manually mount Windows drives using the DrvFs file system. Previously, WSL would automatically mount all fixed NTFS drives when you launch Bash, but there was no support for mounting additional storage like removable drives or network locations.

> Now, not only can you manually mount any drives on your system, we've also added support for other file systems such as FAT, as well as mounting network locations. This enables you to access any drive, including removable USB sticks or CDs, and any network location you can reach in Windows all from within WSL.