| Linux On Windows - Microsoft On How It Works |
| Written by Mike James |
| Wednesday, 27 April 2016 |
|
The ability to use Ubuntu's user side interface under Windows is perhaps the biggest open source surprise this year. Now Microsoft is explaining how it works. It isn't well known, but Windows has been able to offer some support for Linux applications for a while in the form of a Posix subsystem that eventually became Subsystem for Unix Applications SUA. However, this mostly didn't work and hardly anyone made use of it. This isn't the case with the Windows Subsystem for Linux. Times have changed and even Microsoft understands that we all have to get involved with Linux at some point or other. In most cases it's just a server or having to set up an IDE to use a remote hosted compiler. Sometimes the ability to run Linux commands under Windows would make things a lot easier. This is what the Windows Subsystem for Linux WSL does. There has been some speculation on how WSL works and how far you could push it. Some users have even managed to get applications that use a GUI to work by installing an Xwindows server under Win32. Now we have some new information from Microsoft about how it all works that indicates just what the limits are.
Even with the system diagram it is difficult to work out what is going on and what is important. The key idea seems to be the Pico process - something invented as part of Microsoft Research's Drawbridge project. This is something like a container crossed with a virtual machine. The Bash shell runs as a Win32 process and communicates with the Linux subsystem via a broker, the LXSS manager. This is used to start other Linux binaries as pico processes. All Linux binaries started by one user go into a single Linux instance. The pico process emulates Linux system calls (syscall), usually by translating them into equivalent Windows calls, but occasionally by implementing them as a set of calls. The example given is the Linux fork() which has to be implemented as a copy operation and NtcreateProcess. The implementation of the syscalls is done by a clean room implemenation of lxcore.sys. i.e. without using any code from the Linux kernel. The Linux file system is also simulated using the NTFS file system. The VolFs system provides something that looks like a standard Linux files system including the usual directories /etc /bin and a home folder. This emulation supports Linux style permissions, symbolic links and file names. Windows applications have no access to the VolFs. They do, however, have access to DriveFs, which is interoperable. It uses Windows file names and security. All Windows drives are mounted in the usual /mnt directory. Notice that there is no possibility of installing or mounting any other Linux file systems as this is all a mirage created using standard NTFS files. If you want a video explanation see:
If you want to influence the development of the Linux system then visit User Voice, where there are already an amazing selection of suggestions for the future direction. My favourite is to standardize on / for all paths - can't see why not. It is interesting to speculate where all this will end. Will one day in the future we all work with LinWin and wonder why there ever was a split? No that is just too far fetched.
More InformationWindows Subsystem for Linux Overview Related ArticlesRun Linux Binaries On Windows 10 Microsoft Does U-Turn On Skype Universal App Astoria Cancellation Confirmed - Devs Advised To Try Xamarin Microsoft Buys Xamarin - About Time Too Microsoft's Astoria Android Emulation Might Not Happen Microsoft's Islandwood Now On GitHub - An iOS Bridge To Nowhere? Silverlight Bridge To UWP Apps Project Westminster - Another Web App Format
To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on, Twitter, Facebook, Google+ or Linkedin.
Comments
or email your comment to: comments@i-programmer.info |
| Last Updated ( Wednesday, 27 April 2016 ) |
