Microsoft had enough resources to painstakingly go through massive amounts of existing code, catalogue the differences and eventually deliver WSL. A small enthusiast group behind CoLinux would never commit to anything like this, since it's hard to imagine a less rewarding and intellectually stimulating job.
And I suspect it was not even too hard anyway: identify from which universe comes a type, then identify where you need compat, and use an explicit size to setup the typedef, and it's ok. Windows typically uses uppercase defined types like LONG, and Linux does not do that, so it's hard to mix up unintentionally.
As reasons for WSL to happen anyway? It's hard to know, despite my earlier glib comment that it would. It's plausible that a 64-bit coLinux might have found enough adoption to provide the same support for Microsoft's Windows strategy that WSL does, although coLinux's FOSS licensing model would certainly complicate that a lot - but, on the third hand, how much does it cost to convince a dev team it's time for an acquihire and a community fork? And how much is WSL or something like it worth to Microsoft, anyway? I know a fair number of devs who are glad to have it, but the next I meet who actually switched (or switched back) to Windows for it will be the first.
https://en.wikipedia.org/wiki/Architecture_of_Windows_NT
Had Microsoft taken care of it like other OS vendors did with their POSIX compatibility layers, instead of using it for DoD contracts and Win32 migrations, and FOSS UNIX clones would never had mattered.
The only reason I started tinkering with Linux, was that Xenix and DG/UX were a little hard to come by for work assignments at home, and stuff like Coherent wasn't really a solution.
I am not sure about that. NT licenses weren't cheap back in the day, and Linux was $0. (And didn't come with baggage like a more expensive SKU to support more CPUs)
Seems cute but the WSL has the full support of the Windows scheduler which is gonna make the practical choice of tool obvious for folks with Linux workload requirements.
Edit: I guess development on it started in 2004, it was only a few years later that hardware-assisted virtualization started becoming relatively mainstream.
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.
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.
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.
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.
Recalling this, it makes me feel quite a old hack, when I started this back in December 2003, without Git, through mailing lists, and on sourceforge - oh boy. Would have definitely been easier maintaining this project with all the tech, the reach, and the amount of potential contributors that we have today.
Nothing (almost!) against Windows, but with experience steeped in Xenix, Solaris and Interactive... let's say that coLinux was also pretty effective as an anti depressant :D
Fast forward to earlier today, after using Linux (proper) for the past 12 years, I came across another comment on HN that mentioned it and realized that even today I didn't really understand how the promises of coLinux were possible - how can you run Linux and Windows at the same time? Was it some kind of userland virtualization, like Wine, or was it just a fancy virtual machine, or what? After reading about it I realized it was in fact a very real project that actually did work, and that it used a very novel method of running two operating systems together without "virtualization" as people typically know it, where there is a "host" and a "guest" separated by hardware isolation mechanisms.
Instead, it works by literally just running the Linux kernel inside of a Windows driver, with some bootstrapping code to allocate memory to it, some glue for Windows/Linux context switching (with control yielding from Linux to Windows after a time slice, and control passing from Windows to Linux via a userland daemon in Windows calling into the coLinux driver on a timer), and a mechanism for ferrying interrupts between the two kernels. This basically amounts to "cooperative multitasking", which hadn't really been a thing since segmentation and paging were introduced at least as far back as the early 90's, and as far as I'm aware hasn't been used as a technique for serious virtualization since (for probably the obvious reasons).
It was pretty fascinating learning that this thing I'd tried so many years ago (and hadn't managed to get working, sadly) had such a novel approach to virtualization, so I thought it was interesting enough to share here.
https://en.wikipedia.org/wiki/MkLinux - linux on top of the mach microkernel, I think it was sponsored by Apple (especially its book was great)
I wanted the transition to be as painless as possible, and I also wanted to be able to use both system at the same time for a while while getting used to Linux & its applications.
First step was starting to use multiplatform & open applications. So I left IE, Outlook and Office for the windows verdions of Firefox, Thunderbird and Open Office.
Once I got accustomed to that, I installed Debian in dual boot and moved all my files to ReiserFS. This was before the unfortunate events involving its creator: eventually I moved to ext4 and years later I made a super cool in-place conversion to btrfs, but that's another story).
Now I was accustomed to open applications, and my data was on Linux, but I still found myself frequently needing to start windows for a lot of reasons. But then all my emails and documents were locked in the Linux partition.
Here colinix came to the rescue: while on windows, I started a colinux instance (it was super fast, no way a VM could have served that purpose), mounted the physical partition in it, and shared to the windows machine via Samba.
It was a long journey, but taught my younger self a lot, and above all grew me fond of how powerful and flexible an open software ecosystem can be. Nothing of that would have been possible on proprietary technologies.
Many years later, I have never looked back, and I grateful to all the wonderful passionate people that made this possible.
People talk a lot about WSL2 as if it's "already here", but WSL2 still requires the latest update of Windows 10 from two months ago, or a slightly older build along with an "insider preview" activated copy of Windows, and you have to enable Hyper-V. Not all devices/users will be able to support all of this and it will break compatibility with some apps.
Given that, your other option is WSL1, which is not really a replacement. If you want to run Docker on it, you either have to install Docker for Windows (which may also have conflicts with Hyper-V apps) or use the oldest stable version of Docker on Linux along with some annoying hacks to be able to run a container. All of this, and you finally run some apps, and it feels like half your system's performance is gone, and the apps run at about 1/5th their normal speed.
Maybe in a year most people will be on the right build of Windows for WSL2, and maybe we'll have patched all the Hyper-V conflicting apps, and maybe there'll be a way to use it without a long HOWTO and researching buggy commands. Until then, a VM is way easier, more functional, faster, and more reliable.
Unlike in other Linux virtualization solutions such as User Mode Linux (or the forementioned VMware), special driver software on the host operating system is used to execute the coLinux kernel in a privileged mode (known as ring 0 or supervisor mode).
By constantly switching the machine's state between the host OS state and and the coLinux kernel state, coLinux is given full control of the physical machine's MMU (i.e, paging and protection) in its own specially allocated address space, and is able to act just like a native kernel, achieving almost the same performance and functionality that can be expected from a regular Linux which could have ran on the same machine standalone."
This sounds great and is a noteworthy achievement!
Favorited.
Although (and this is just me geeking out here, and doing some imaginary future engineering in my mind!), wouldn't it be great if someone modified both Linux and Windows -- to use a common, neutral, small-as-possible microkernel?
You know, take out the common stuff that both of them do, and put all of that into a microkernel, then change them so they can happily run alongside one another, supported by that microkernel at the center?
Note to future self (when I have the time): Look into doing this... what would be learned about microkernels and microkernel design -- if someone went down this path?
(Yes, I know about Mach and other microkernels... maybe the job would be fitting Linux and other OS's to an existing microkernel... that would certainly be easier than generating the microkernel from scratch -- but not as educational...<g>)
Colinux worked very well. Thanks to the authors.
Used this a lot for cross platform development, like C#/.NET and Mono. Used this with an xserver on windows (xming?) and ran monodevelop or gvim.
