WSL2 operates in a Hyper-V environment, there's too many issues with trying to do syscall emulation that WSL1 attempted - while both will remain supported for a while the writing is already on the wall.
Ugh. I hadn't heard that. WSL2 being a VM is a huge disappointment. There's the technically-cowardly Microsoft from the Ballmer era. Just when I thought Microsoft had rediscovered how to do technically interesting things, they wave the white flag and run away.
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.
Microsoft knows full well how to do technically interesting things, that's why WSL1 worked as well as it did. The problem is that, being a company and not a grad student, "works 100% of the time" is more worthwhile to them than "works 99% of the time and sounds really cool."
> Just when I thought Microsoft had rediscovered how to do technically interesting things, they wave the white flag and run away
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.
> 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.
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.
> 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.
As far as I'm concerned, using a VM is a poor choice technical choice: a VM closes off lots of potential integration opportunities and creates all the system-resource-use coordination problems that all non-container system partitioning approaches have.
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.
A light-weight solution would have been nice. Something like containers.
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
and... it's just too difficult. It's ETOOHARD. So they all failed.
Could you give a specific example of what kind of integration you're looking for (that can only be addressed by WSL0/1)?
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.
It was cool how WSL1 allowed named pipes to be shared between Windows and Linux apps, giving the possibility to have a shared SSH agent, efficient X11 support, etc. Does WSL2 support that? I'm not sure but I don't think so.
for NaNoGenMo [1] 2015, I wanted to run Racter [2] against Eliza, but 1) I run Linux and 2) I had an MS-DOS executable for Racter. I thought I would use DosBox to run Racter and pipe input/output to Eliza running under Linux natively, but DosBox didn't allow that. I ended up having to write enough of an MS-DOS emulator [3] to run Racter under Linux so I could pipe input/output. It barely functioned.
As someone who is using WSL2 and had used Cygwin in the past, WSL2 is awesome and way better than the original WSL. I highly recommend you give it a shot.
It may be a less pure design, but it solves my needs better than anything else out there.
