Then what's this Linux subsystem that Windows ships?
> Linux ABI is large and fast-evolving and underdocumented
You don't have to keep up with the latest ABI. You don't need to match tip-of-tree. You only need to match some version of Linux that programs still target, and that version can be pretty old, since enterprise customers scream bloody murder when you force them up upgrade kernels to run new programs.
Using a VM for WSL means that it'll never be possible to write a program that's simultaneously a good win32 GUI citizen and a Unix API user. WSL1 (AFAIK) didn't allow this use case, but there was a path to get there. There's no path from a VM to a native USER32 process.
The bright side is that at least Cygwin won't die. Cygwin allows for precisely this use case.
You might want to look up all of the reasons why they made this choice, including but not limited to the amazing impedance mismatch between Linuxy I/O operations and Windowsy I/O operations.
Running the Linux kernel in a VM and doing all sorts of integration tricks ends up being a better end-user experience, even if it's not as cool and clever as what WSL0 and WSL1 are.
Yeah, this right here is the most problematic. It's fairly easy to implement the proactor pattern of the Windows asynchronous IO APIs using reactor implementations common on Linux, the opposite is not so true. Seeing as this is a fundamental design choice of the NT kernel itself, and not just the Win32 subsystem it's rather difficult to properly emulate the Linux API's without a similar amount of indirection that a hypervisor layer adds.
Could you provide a link to this?
The point of WSL isn't to just run some Linux code on Windows. You've been able to do that for literally decades. The point is to create a tightly integrated environment that gives you Linux and Windows views onto the same workspace and that makes Linuxy and Windows processes peers.
Using a VM here feels like a "safe" and "sustainable" uninspired corporate choice that gives Windows a checkbox feature without expanding the bounds of what's possible. You can tell me all day that switching from innovation to crank-turning is right for the business, but I personally want nothing to do with crank-turners.
But again, the problem is that Microsoft wanted to have binary compatibility. That would mean containers w/ Linux ABI emulation, or a proper VM. Well, Linux ABI emulation has been tried by many people:
- Sun (twice)
- Joyent (once, based on earlier tech from Sun)
- FreeBSD
- Microsoft (WSL1)
- probably others
I'm not a Windows developer but I have a Windows laptop that I'd like to be able to run linux on and WSL2 scratches that itch, so your complaint doesn't register for me.
[1] National Novel Generation Month
[2] https://en.wikipedia.org/wiki/Racter
[3] https://github.com/spc476/NaNoGenMo-2015/blob/master/C/msdos...
But yes, I was referring precisely to WSL2 being VM-based.
It may be a less pure design, but it solves my needs better than anything else out there.
Yeah, and WSL1 did not.
It's now a full Linux kernel running in a hypervisor.