With the goal of making more developers use Windows, and to help them move their workflows over to Windows, Microsoft has taken the step to enable Bash scripting natively in Windows 10. This will be a new subsystem, and not an emulation layer, with full access to native Windows functions such as the file system and APIs.

Microsoft partnered with Canonical to provide an Ubuntu based subsystem into Windows. In the keynote, Microsoft spoke about how they have had lots of feedback regarding their Hosted Web App bridge which lets developers take web apps and provide them through the Windows Store as pseudo-native apps. The Web Apps can have access to the Universal Windows Platform (UWP) APIs for things like Live Tiles and Cortana integration, but without a lot of the overhead of re-writing into a native app. But the feedback was that a lot of the development tools they use require Bash scripting making it difficult to do the development on Windows, hindering Web App adoption.

Adding the Ubuntu subsystem into Windows is an interesting solution to this problem. Linux does a lot of things much differently than Windows, including having a case sensitive file system, among other things, so certainly some work would have been done on the back end to enable this in Windows.

This, like many of Microsoft’s announcements over the last year or more, have been about making it easier for devs to work on Windows, and expanding the install base of targeted applications with bridges and Xamarin.

I hope to have some more info on the Bash announcement in the next couple of days.

Comments Locked

41 Comments

View All Comments

  • doggface - Wednesday, March 30, 2016 - link

    Cool story bro.
  • Daniel Egger - Wednesday, March 30, 2016 - link

    As for the differences: cygwin has been around for ages and works pretty well despite feeling like an alien, however many of the differences you just mentioned also apply to OS X and yet it feels pretty Linuxish under the bonnet nowadays but obviously Apple wouldn't partner with Microsoft to give them the same edge...

    As for drawing more developers to Windows: good luck with that, enabling Linux/OS X/BSD/<you name it> "workflows" (basically only those relying on bash, which is a clear pointer to autoconf/automake) on Windows is only the smallest step of many. As long as the rest of the tools continue to suck this won't fly anywhere... And why use Windows natively if it is much simpler to crosscompile e.g. with MXE.
  • aryonoco - Wednesday, March 30, 2016 - link

    Cygwin does not work well.

    Cygwin uses the ancient POSIX compatibility layer that's been around in Windows since NT 4.0, and presents all its own weird problems. Everything has to be ported to Cygwin, which is no easy task. Also, Cygwin is dog slow. Writing to a modern SSD at 10 MB/s is not particularly novel in 2016.

    This is a very big deal, it allows running Linux binaries unmodified on Windows. No need to recompile anything, no need to port anything to another weird POSIX. All the Linux binaries that people know and use and are maintained well, on Windows.

    This is an impressive bit of engineering. Sure NT has always had the ability to run different userspaces, and it did have a POSIX environment and and OS/2 environment for a while, but those provided source compatibility. Translating every Linux API syscall to NT? And doing so at native speeds? This is hugely impressive.

    For the first time in a LONG time, I'm really excited about something in Windows. Heck for the first time in a long time, I might actually think about buying a Windows laptop next.
  • aIIergen - Wednesday, March 30, 2016 - link

    It looks like the same idea as linuxulator which has been working for > 20 years on BSDs.
  • aryonoco - Wednesday, March 30, 2016 - link

    Yes indeed, it is very similar to the Linux compat layer that the BSDs have long provided.

    From a computer science perspective, this is nothing new. Back in the late 90s and early 2000s, there was a product called Win4Lin from NeTraverse which did the opposite of this, it translated Win 95 syscalls to the Linux kernel and allowed Windows binaries to be run "natively" on Linux. Problem was it only supported the Win 9X branch, and once the Windows userland moved to NT, it became obsolete.

    It takes a fair amount of engineering to pull something like this off, but it is not novel from a programming point of view. It does mean that Microsoft now has to track the Linux kernel API to maintain compatibility, but that's fairly stable so it's a low-risk strategy. Still, in this age of virtualization and containerization, I did not expect to see something like this from Microsoft. Kudos to them.
  • Klimax - Thursday, March 31, 2016 - link

    Sorry, but wrong. Cygwin does not use POSIX Subsystem. (Windows 8 dropped it, it implemented only older specification and had some severe limitations)

    Cygwin always reimplemented POSIX on WinAPI.
  • aryonoco - Thursday, March 31, 2016 - link

    You are right, Cygwin is a Win32 implementation.

    It doesn't change the fact that it's dog slow.
  • Vatharian - Wednesday, March 30, 2016 - link

    Ummm... Cygwin? Been around for years?
  • lilkwarrior - Thursday, March 31, 2016 - link

    This isn't the same thing; this is much, much better
  • Klimax - Thursday, March 31, 2016 - link

    Hello POSIX Subsystem. Long time no see. Now we have fun....

Log in

Don't have an account? Sign up now