Ubuntu on Windows

A few random thoughts:

- Wow, hell is really freezing over!

- The hardest part of running bash and other posix things under windows is filesystem access. Windows uses drive letters and backslashes, unix has a root filesystem with forward slashes. It seems they are taking the same route as cygwin by "mounting" windows drives in /mnt/c (or /cygdrive/c).

- If you just wanted bash and some posix tools, the harder but nicer way would be to patch them to understand windows paths. It is not clear to me that it is even possible, for example many tools assume a path that does not start with a slash is a relative path - while "C:\" is absolute. You would also want to make more windows apps understand forward slashes like "C:/Windows". To make things even more complicated, there are NT native paths "\Device\HarddiskVolume4\Users\Bill", UNC paths "\\Server\share", and the crazy syntax "\\?\C:\MyReallyLongPath\File.txt".

- I am really surprised this works in an appx container. From my little dabbling with modern apps in Visual Studio, I've found that they are incredibly sandboxed - no filesystem access unless you go through a file picker, no network connections to localhost (!?), no control of top-level windows, no loading of external DLLs. You can get around most restrictions for sideloaded apps, but not for windows store apps. That they can now package such a complex application as a modern app (with maybe only the linux subsystem DLLs delivered externally) means that they are slowly moving the modern/universal apps and traditional Win32 apps together with regards to their powers.

- Running a Linux kernel in windows, and then ELF executables on top (without virtualization) is nothing new, see CoLinux or andLinux. If I understand correctly, this new work uses a new Linux NT subsystem. It remains to be seen if this is better (more performant) or worse (if the Linux kernel is just another process, and it crashes, it doesn't take down the system).

- If they actually wrote a NT subsystem for Linux, this opens a whole can of GPL licensing worms, as you'll need to include internal NT headers. However, they say it is closed source, so I wonder how they did it.

- This really stands and falls with how well it is integrated in the rest of the system. I want to install tools in "Ubuntu" via apt and use them from cmd.exe, and vice versa. And long term, a X11/Wayland bridge would be nice too.

I expect they implemented a subsystem for Linux at the syscall level - i.e. they implemented the Linux kernel's interface at the ABI level. No headers would need to intermingle with open source; compile on Linux, run on Windows.

From the screenshots, it seems there is a full kernel in there - e.g. you have /proc/cpuinfo, and it identifies as Linux 3.4.0.

If they just implemented all Linux syscalls on top of NT, that would replace a Linux kernel. There would be no Linux kernel running on top. But in that case they would also need to emulate stuff like /proc. (This is the "reverse Wine" scenario.)

So I personally think it is either: - There is no new subsystem, this is just a linux.exe running the Linux kernel as a process, like CoLinux does or - There is a new subsystem. One way to do this is to port Linux to a new "architecture", namely the NT HAL. You'd call into the NT native API from the linux kernel, which would mean you'd have to put the headers with the native APIs you use under the GPL.

Armchair kernel development is fun :-)