Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Why didn't Microsoft go with something like this for WSL, instead of using a VM for WSL2?


There's an interesting thread [1] on github.com regarding this.

Here is a copy of the comment I added there:

I was not surprised when Microsoft took the approach with WSL2, as I've gone a similar path when writing coLinux. I've considered extending an existing project named LINE, which is more similar in architecture to WSL1. Not having the full resource of a development team, I took the easier cooperative VM approach. Re-implementing stuff is a pain. Integrating is more fun.

However I think both WSL1 and WSL2 have their added value being active projects. WSL1, is good for being more 'in the Windows domain of things' compared to WSL2, and not requiring a hardware-accelerated hypervisor behind the scenes. For WSL2, back when writing coLinux, I've imagined the things that could have been gained if I had had access to the Windows internals, especially regarding memory management. I believe that the Windows dev team has a much better chance to make Linux more compatible and smoothly integrated in a performant way with this approach.

Perhaps it's too late, but I wish that the two approaches would have had different names so to not suggest that one is entirely newer or better than the other.

[1] https://github.com/microsoft/WSL/issues/4022


Cooperative multitasking is, in general, less than optimal in terms of stability. Both kernels run in the same address space, and must voluntarily cede control to the other, so any problem with either writing to the wrong place or failing to yield control to the other can cause a system failure. In addition to that, there is also the latency introduced when Linux has control and receives a hardware interrupt which it must then ferry to Windows for processing. In general, they can't both be running at the same time, which is not the case with all other virtualization methods.

The real strength of this approach I think lies in the total time and manpower required to get it working - the paper on their web site says that from the day he sat down to start the project, it took him roughly one month until he was able to run KDE programs, and the total modifications to the Linux kernel were only a few thousand lines of code. I find this pretty incredible in itself.


That's true. The effort was very concentrated.

Those days in late 2003 were crazy. Waking up at noon to work on it for until 9:00pm, and then off to a night shift writing boring tests script stuff until the morning. And also weekends. It was like a full time job with extra hours during that month. Was full head-on stamina at age 21, and I don't even drink tea or coffee.

Interestingly, if it wasn't for the boring night shift job I had back then, I would have never found all the time back at home during the day time to do all this. And once I figured out how I want to write it, nothing stopped me until it worked.


Security and OS stability comes to mind.

In an time where we are finally migrating to better isolated architectures on mainstream OSes, having a full OS running as a driver isn't that appealing.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: