This is one (windows) kernel instance running apps built for linux. VMWare just starts a new OS instance on the same PC - but it has a separate memory/FS/scheduler/drivers/etc. a lot of overhead, duplication and sync work.
Say there's a tool that doesn't have a Windows version, like Facebook Flow didn't have - you can just install the necessary packages and run the linux app on your project folder - plenty of dev tools are built on top of *nix and Windows is a second class citizen in OSS - this solves that problem nicely. Or you can use linux GCC/clang to build the linux binaries on Windows and not muck around with cross compiling.
It's a different approach. WSL is more like CoLinux back in the day, in that Windows and Linux kernels run alongside each other. Even a bit better integrated because processes across both worlds can run each other, and see and talk to each other.
WSL doesn't run a Linux kernel – a Windows Subsystem just provides a different API to the underlying Windows kernel, in this case the API Linux applications expect. So arguably, it's even further from a VM than CoLinux.
Well, CoLinux ran Linux as a kernel-mode driver under Windows. WSL is a Windows kernel subsystem providing the Linux kernel API. That's why I made that comparison. I do know that they're very different things technically.
I haven't followed this, but last I've seen a while ago was that you could run an X-server for Windows and then have Linux applications talk to that (and the normal environment didn't have dbus and things like that)
Nice, because right now altough I use a linux VM for dev work, I am still bummed by the latency and stuff. For tty based work it is there but any X.org workload is still laggy as fuck, which kinda bothers me a little while coding (I'm using Xubuntu with all the VirtualBox additions on).
