APRIL 1, 2016 14:31 am

Announcement of GNU/NT

Since we announced the bash for linux on Windows 10 yesterday, we have a big announcement for you today as well. There's a lot of talking going on concerning Open Source and the Windows Subsystem for Linux (WSL).

Especially the Linux Bash on Windows 10 is a big change on how we have to see the software world. Things get closer together and that means we have to collaborate more and more with Open Source projects to create innovative and great products.

The Bash is a clear signal on how Microsoft changed its view on the software world and we want go move on to make an even bigger step into the future. We will re-build our whole kernel to run GNU/Linux applications and therefore be able to act as alternative Linux kernel.

Based off your feedback we’ve done a couple things: First we made investments that improve cmd, PowerShell, and many other command-line tools and developer scenarios. Second we decided to grow our command line family by adding real, native Bash and with it support for Linux command-line tools which run directly on Windows in an environment that behaves like Linux! And finally we'll put the whole user-mode of Linux onto the GNU/NT kernel.

”It's time to change our view on companies like Microsoft or Google. They finally realized the facts, that we're not competitors anymore but more and more partners.”

— Linux Torvalds, founder of Linux

When can we use it?

There's no release date ye, but at the end of the year, there'll bemore information about the technologie, first source codes available and the first beta version published.

Related Build 2016 Content

If you’d like to learn more, you can watch Kevin Gallo’s keynote announcement and demo of running Bash on Ubuntu on Windows at Build 2016. Unfortunately the developement of the GNU/NT kernel is not that far right now, to there's nothing to see yet.

Also, Rich Turner and Russ Alexander recorded a Build 2016 session introducing and demonstrating Bash running on Ubuntu on Windows.

We look forward to working with you to improve the Windows command-line tools and console: Please continue to suggest features etc. via our Windows Command-line UserVoice portal and stay tuned for lots more news on our new command-line blog. Also, visit our new command-line documentation portal for content and links to resources.

Updated APRIL 1, 2016 15:54 pm

Join the conversation

  1. And I was all excited, but this is a problem…

    “Third, note that Bash and Linux tools cannot interact with Windows applications and tools, and vice-versa.”

    I hope that this is a temporary restriction. I’d like to be able to use bash to create scripts to automate tasks for me. In the past using Cygwin, I’ve done similar things, running commands in SQLCMD to make the same updates to several different databases.

    Without this ability, then this is just a fun plaything, probably not something I can use to benefit my daily work very often.

    • Great feedback Chris.

      You state that you want to invoke Windows tools within your Bash scripts and workflow. What kind of tools, specifically, would you find useful? Could you give us an example workflow that would employ tools on both the Bash and Windows sides?

      Not sure if it came across during the keynote, but you can access your Windows filesyste, from within Bash so could use Windows tools and Bash tools to work on the same set of files if you need to.

      • In bash I have the following in my Cygwin bash history which cross the Windows/Bash divide.
        explorer
        vagrant
        mvn
        java
        javac
        notepad++.

        • Thanks for sharing. So, if you were in Bash and typed “java …”, what would you expect to run? Java in the Bash environment or in Windows?

          • Hi Rich,

            I am a Java developer, using so far Ubuntu/OS X exclusively for my developing needs. In OS X/Ubuntu I installed JDK of my choice and use it every where. With this “on Ubuntu In Windows”thing do I need to install JDK on both platforms(which is a crazy idea, if that’s the case), same with .Net core and like these there are so many. So without interoperability its just a performance improvement over people already doing this through a VM, including those mounting windows drives inside Linux filesystem. We are all doing this from a long time.
            When I saw this news “Bash is coming to Windows” I was ecstatic. I thought the integration is on par with OS X. I wonder how Windows became a POSIX compliant over night.
            Hmmm, looks like atleast as of now, this is like a reverse of Wine on Linux. This is not I want. As a developer, I want Windows with Bash power. Just like how Bash is in OS X. Bash must be a first class citizen in Windows eco system, not as a guest who once come in while.

            Thanks

      • Hi Rich,

        I just signed up for answering this. What I need is (please, please!):
        – Ansible to be able to automate my Windows machine set-up.
        – Vagrant to work from this bash shell.

        I work a lot with Linux VMs but also write windows software. I do not want to have to change OSs for every customer. One of my customers works on Debian machines, uses Vagrant to launch his VMs. Other customers have Windows hosts. I do not want to have to change OSs.

        This is really exciting!!
        Thanks

        • If you’re looking for a tool to setup your local Windows box or Windows VM’s, you might be interested in http://www.boxstarter.org/

          I can certainly imagine running the vagrant client from Bash. When the you get the bits (next Windows 10 Insiders fast-ring), please give it a try and let us know.

      • Well, as I mentioned, I’ve used SQLCMD. I’ve also used some 3rd party tools, most notably the SQL tools from SQL Accessories. I’ve used XCOPY because the Cygwin cp is far too slow. I’ve used the various Visual Studio command line tools, msbuild, compilers. Finally, I’ve used a couple graphical tools, the one that immediately comes to mind is notepad++.

      • BTW, Rich, don’t get me wrong.

        I am extremely impressed with the concept. These seems similar to CoLinux, which I always thought had great potential. I think you’ll likely have some stumbling blocks along the way. Cygwin constantly has issues bringing in new tools from *nix. They’ve written their own fork(), but it’s very slow. I assume you’ll be able to do better. They also have issues with case-sensitive file names. I am curious as to how you’re handling that. Anyway, I’m sure you can throw more resources at this than are being thrown at Cygwin, so perhaps you can catch up pretty quickly. Good luck, and I can’t wait to see what comes of this.

        • Thanks Chris. Cygwin is essentially the GNU tools ported to run as Win32 tools. This gives you the ability to use their Bash to directly access Windows command-line tools, apps, etc.

          Bash on Ubuntu on Windows, on the other hand, provides an authentic Bash/Linux environment running directly on Windows. Right now, it has no ability to invoke/execute Win32 apps – it’s a relatively pure Linux environment, including enforcing Linux filesystem behaviors when working within the local Linux FS.

          But we also mount your C: drive into /mnt/c/ and maintain NTFS’ case-agnostic behaviors.

          • Personally, I think that is a great approach. Cygwin I always found problematic as you get the confusing mix between the two, In particular things like did you pick up the windows binary instead of the cywin one. This gets tricky in someone else build scripts and tools, especially if they are existing cross platform handling.

            I’d suggest that launching processes between the environments with a explicit launcher binaries would work fine. Those who want to run windows processes can use all the power of bash aliases and scripts to launch exactly what they want when they need it, without getting into potential confusing mess.

      • I have this problem with the Evince EPS viewer. There is a Windows binary which uses the windows display manager and the “gnome binary compiled for cygwin”. I specify which I want to open using an alias in my .bash_rc file and/or symbolic links to /usr/local.

        This scenario happens a lot. I think the best way to interact with Windows programs is to use the equivalent of cygstart which would open a file using what ever Windows defaults to for that file type.

    • To add on to what Rich said, bi-directional interop with Windows & Linux processes is something we are very interested in enabling. However, we want to know the specific scenarios you have in mind so we make sure to design the feature appropriately.

      • Mike and Rich,

        All of my software products Heimdal, OpenAFS, AuriStor File System, etc. are complex cross-platform products that share the majority of its source code with the builds for Linux, OSX, Solaris, AIX, etc. Our build processes make use of Git, Gerrit for code review, Buildbot for continuous integration builds, C-Tap and Docker for automated testing, Coverity scans, etc. All of the builds rely on command line tooling. For Windows builds a combination of nmake and msbuild as well as many Unix tools. A partial list includes:

        awk or gawk
        yacc or bison
        lex or flex
        python
        perl
        cmp
        makeinfo
        sed
        sh or bash
        git
        docbook
        xsltproc
        xmllint
        dblatex

        Today we use Cygwin or msysGit tools to provide the required functionality. As opposed to working with Canonical to bring yet another bash shell to Windows, what I would prefer to see is Microsoft work with Red Hat and the Cygwin community to better integrate Cygwin with Windows.

        To be clear, the functionality that I require is to have the same suite of command line development tools on Windows for building Windows applications that are used on the *nix platforms for building native binaries on those platforms.

      • Hi Mike,

        Some features that I think would make this useful compared to VMs or the new Docker for Windows:
        – Being able to launch linux processes from Windows (I guess it’s already possible with a bash command_name, under cmd?)
        – Similarly being able to launch Windows executables from within bash. Having to leave bash, retrieve the file in the right folder to edit it with VS Code was a bit pathetic unfortunately. We should be able to do something like: vscode file_name, under bash, or at least have a “win” command that can be used to launch windows processes with something like: win vscode file_name.
        – Some kind of basic inter-process communication protocol between windows and linux processes (piping, shared memory, or even a simple/hacky file system based approach since Bash already has access to the Windows file system).
        – Full integration with Visual Studio 2015. Being able to build ELF binaries with GCC and debug them natively inside Windows (without using the remote debugging feature).
        – Offer the open source community clear best practice Guidelines on how to integrate Windows and Linux dev workflows with bash scripts (How to handle long folder paths, ssh scripts involving folder names with spaces, etc…).
        – As a Scala developer for instance, I’d prefer to use bash scripts to build complex Scala projects in the Ubuntu environment while using the Windows installed JVM for testing etc. This sort of thing is already possible and is part of the Scala distribution, which uses Git’s MSYS bash. Doing it with the new Bash for Windows needs to be even easier.
        AFAIK Most hipster devs are using overpriced Macbook Airs because of the fully integrated Unix environment it offers. Bash on Windows is a great step to win them over, but better integration with existing Windows infrastructure is crucial.

        Great news and certainly the right direction.
        Thank you

        • My #1 wish list item in terms of Windows integration is the the is 2nd bullet Omar Reddam mentions above:
          – Similarly being able to launch Windows executables from within bash. Having to leave bash, retrieve the file in the right folder to edit it with VS Code was a bit pathetic unfortunately. We should be able to do something like: vscode file_name, under bash, or at least have a “win” command that can be used to launch windows processes with something like: win vscode file_name.

          I see my myself using bash/ubuntu commands for all the CLI stuff (as that’s how I use cygwin today) and Windows apps for all the GUI stuff, but the former needs to able to launch the latter, from the command line. That includes the need for path translation.

          Somewhat related, I’d love to eventually see Microsoft add conventions so Windows GUI apps (primarily programmer focused utilities) can say they support forward slash delimited paths & users (developer types) can set a Windows preference setting to use those by default with apps that support them. That can (eventually) make / vs \ path annoyances a thing of the past for Windows devs. But for now / to \ path translation is needed when bash launches Windows programs and passes path arguments as command line args.

    • I would agree with you Chris, If it becomes a sort of sandboxed vm within windows than my response would be thanks but no thanks, if i happen to be on windows and i need to ssh with my credentials or something, then i would not have to configure putty but that’s the only thing i can think of that i would do different.
      I am certainly not going to change my workflow for that.
      but for sysadmin stuff or development without a “real” marriage between the systems this is nothing more then a gimmick. I hope you do find a way to make this happen because i see this as an interesting development that puts some heat on canonical as well as benefiting quite a few users.

  2. Echoing Chris here. Until there is interplay with Windows apps and file systems completely, this is not that different from VM running Ubuntu really (other than some speed-up perhaps).

    It will be interesting to see how MS enables command/IPC equivalents between the two. Looking forward to exploring more.

    • Hey Suman.
      Note that you can access your local machine’s drives from within Linux – they’re mounted under /mnt. For example, your C: drive will be under /mnt/c/.

      This means that you could use VSCode to edit your Ruby source code sitting on your Windows PC and then switch to Bash to build and run using Rake/Ruby. This is particularly useful if any of your Ruby Gems contain Linux dependencies; they should run within the Bash environment, whereas they’d fail when run in Windows.

      As I mention above to Chris, we’re interested in what kind of process interop you’d like to see in the future. What Windows apps would you like to call from Linux, and vice versa?

      Rich.

      • Hey there Rich, great work!
        Continuing on this topic about interop, one thing that comes to mind is integrating git in some tools (like VS Code running on windows). If we don’t have that interop, we’d have to install both git from apt and git-scm.com in order to be able to use it from bash and from VS Code – if that’s the case, then it’s better to use MSYS2 or Cygwin, as those work from the terminal and from windows itself.
        Also, if that interop was working, I would be able to use bash vim to work on my win32 projects, by running cl from vim and compiling from there. Without that, again, I’d have to install both ubuntu’s vim and a win32 compiled vim in order to work on win32 projects.

        Nevertheless, I think this is a big step in a great direction, looking forward to testing this. Do you know more or less when this feature will be available to Windows Insiders?

      • Hello and congratulations for the new feature!
        In cygwin I actually can run a command like this:

        cat somefile.txt | /c/users/andrea/myprogram.exe | sed ‘someregexp’ > $result && “notepad++.exe” $(cygpath -w $result)’

        Where myprogram.exe is a win32 command line application. Lack of this kind of interaction (launch and pipe a win32 app) could upset some people, but I can understand the actual tech limits.

        Thank you!

    • Thanks Liam – I’ll forward your comment to the team :)

      Note that some of our content locations etc., are still waking up and should be live before long.

      Rich.

  3. Hi,

    Really excited by this news and I have one question:

    Will bash ne compatible with lumia 950 XL with a display dock connected si I can clone git repo and édit locally with emacs/vim? Lumia 950 XL with display dock lack Visual Studio Code compatible and this would ve a good alternative :)

    Thank you

  4. Which Windows Insider ring would be the most secure that would still get Bash on Ubuntu on Windows most soon?

  5. Pretty exciting stuff. Continuing on the point about interop, it would be nice if Windows GUI applications are able to run Linux command line tools with arguments determined at runtime and then capture the resultant output. The use case that I would like to see supported is the ide-haskell plugin for the Atom editor being able to run ghc-mod (a linux command line tool) with a path to a file as an argument (this is a temporary file generated by the plugin from the current state of the editor, the source code file, cursor location for type inference & etc.) and then read the output. In this use case I think being able to read the buffered output on the termination of the process is adequate (instead of having access to the output as a stream) as the process is short-lived.

  6. POSIX subsystem (Psxss), Interix, Services For Unix (SFU) and Subsystem for UNIX-based Applications (SUA) redux?

  7. Are mechanisms of calling POSIX functions going to be exposed to userspace developers? It’s interesting if other Windows developers can also come with other implementations of this kind of shell, scripting system. Or is it just “closed API”, hands off, don’t touch?

  8. This is very exciting news. Now I can play games and have a proper command line without rebooting. 😀
    One question, What is the possibility of running a GUI application from the unix shell? For example, I would like to run an instance of eclipse pydev which uses the unix libraries. In other words, I want an IDE to use the unix toolchains, and do normal debugging work on it. Would it be a possibility in the near future?

  9. Cygwin? Anyone? Why is Microsoft trying to reinvent the wheel with Ubuntu and not working on further integration with Cygwin?

    • I was thinking the same thing, but it became clearer that Windows is now capable of running the actual binaries from Ubuntu. This means you won’t have to recompile from source code, or reply on a separate user supported repository.

  10. “Third, note that Bash and Linux tools cannot interact with Windows applications and tools, and vice-versa. So you won’t be able to run Notepad from Bash, or run Ruby in Bash from PowerShell.”

    this is rather disappointing.
    im not sure of the point of having a bash prompt that cant interact with native windows command line apps, cygwins been doing it for years. and if you load enough 3rd party software ( mostly from sourceforge) you can get a pretty close approximation of a linux command line.

    all of the “server workloads” (git/ruby/perl/apache/mysql….) that this is not for running with already have good windows ports. or if im testing/developing for a system that will be required to run on a azure/hyper-v ubuntu box why wouldnt i develop in the same environment not some quazi functional emulation. that way im testing permissions, SELinux and iptables rules and actually developing in an environment that will properly simulate production.

    heck i cant even pipe grep/sed/awk output into osql with this.

    rather how about just spending a weekend and knocking out a native ssh/scp/sftp commands/powershell modules and add some of the more common commands natively such as less, sed, awk, tar, wget, vi…

    • Exactly, without interoperation of win and linux shell it’s not really much better than having virtual machine installed / in VM it’s also simple to share folders to win.

      I would like to write bash (.sh) scripts for improving workspace. Eg. do something in bash and then open win application like IDE, notepad++, or other. Also still there will be need to install and configure GIT in windows and also in linux to be able to use it in both platforms.

  11. This will be awesome and intelligent for me. I love both the OS: Windows and Linux. Now I can use them simultaneously, it a great thought for me.

    Thank you Windows for this……

  12. I’d also like to voice my support for the request to be able to run native Windows applications from bash. I work at Mozilla and support our build system, which currently requires an msys install along with a number of other tools. We were quite excited to hear about this work because we’d love to have a well-supported POSIX shell environment to use for building Firefox, but we need to (at the very least) be able to invoke Visual C++ from our build scripts.

    This looks great, though! One of the biggest complaints from myself and other developers has historically been the lack of a standard POSIX shell on Windows, and this looks better than I could have imagined!

  13. Can you add the option to open the bash in the extended right click menu below the option
    “Open command window here”
    ?
    I’d like to use it to quickly open a bash command when I’m on a directory and I want to execute a linux command line command or just open an UIless linux application.

  14. Me too fails to identify the functional benefit here:
    There is nothing new with “Applications running on one operating system instance accessing file systems available to multiple different operating system instances”.

    The key feature missing here is:
    “Run a Windows application from within a Linux application, with synchronized access to the same file system(s) and with stdio redirected”, as it is possible with SfU/SUA and Cygwin, as well as with Wine inside Linux – even if each solution does have its own limitations:
    SfU/SUA: end of live (we do use it for production!)
    Wine inside Linux: does not support Visual Studio (and others)
    Cygwin: fork() breaks when updating running Cygwin binaries (brand new patch available)

    We do have a *nix-based build- and packaging-system (bash, GNU make, autotools, libtool, …) running on many *nix as well as SUA, which knows how to execute the native Windows toolchain (cl.exe, link.exe, lib.exe, …) as well.

    While the application source code (C/C++) itself is ported to the native Windows compiler (minor difference, it is C/C++ after all), the build system is not (major difference, and we don’t want to maintain two distinct build- and packaging-systems).

    We have tried some kind of “Remote EXecution” already (https://github.com/haubi/rex), which we got to work for demo mode, but (let alone performance) failed for production use due to filesystem synchronization issues.

    The idea is:
    Within Linux, register a binfmt_misc handler for Windows executables, and when some Linux application (gmake, bash) is about to execute a Windows application (cl.exe, link.exe, cmd.exe, …), the binfmt handler does (remotely) execute the Windows binary, and redirect stdin/stdout/stderr (at least) in both directions – much like Wine already does.

    The key issue here is with file system synchronisation:
    Any file system content written by Windows applications has to be visible to Linux applications as soon as it would be visible to other Windows applications – and vice versa of course.

    Example:
    When (the Linux application) gmake does (run some code to) create the source.c file, and executes (the Windows Application) cl.exe to create source.obj, then source.c needs to be available to cl.exe as soon as it would be available to (the Linux application) gcc.
    Consequently, when cl.exe successfully returns, source.obj needs to be available to gmake as soon as it would be available to (the Windows application) nmake.exe.

    Looking forward to see remote-compiling (to some degree like cross-compiling),
    /haubi/

  15. Will the Linux ABI be ported to x86 (i.e. 32-bit Windows 10)? I have a 7″ tablet with 32-bit Windows 10. Otherwise I will have to use Cygwin there and Ubuntu on Windows in my 64-bit laptop. Right now I’m using Cygwin in Windows 10, but would like to switch to Ubuntu for Windows since it has more packages, and I’m also using Raspberry Pi:s with Raspbian and Ubuntu MATE which are more like Ubuntu than Cygwin.

    • Have you checked Cygwin Ports? It is a second repository maintained by most of the same RedHat developers that has a hugely increased software repository.

      • Thanks, I didn’t know about it. It works and give more programs, but the network there is slow from here, and it uses only ftp which is sometimes blocked in places where I work.

  16. I think it is great this initiative is coming from Microsoft themselves, but because it is, it is somehow disappointing in my opinion.
    First off, this kind of applications already exist, its not really integrated but something ran inside the classic windows command line. More interesting would be it being an alternative for the classic command line and not a kind of virtual environment inside of it. Take an example of bash, z shell, … all “living side by side”. I know this is a much bigger afford to get the wanted result but it is the only way to make windows attractive for developers and users that abandoned ship for Linux. Because that way there would be an possibility to get the flexibility between command line and windows applications that already exists in (lin/u)nix environments.
    Second, but somewhat unrelated I think, it would be great if Microsoft gave the possibility to chose what window manager to use, and not with slow 3th party software that already exist. It would be really nice to have awesome wm, gnome, … or windows 2000 style (including start menu) working natively on windows 10.

  17. Is it possible to run X Server on Windows Subsystem for Linux?
    It would be great to port all our applications that run in X Server directly to Windows, without any change in our code.

  18. Normally in Windows you cannot remove a file that somebody else have opened. On Linux you can remove an open file. Will the Linux subsystem match the Windows or the Linux semantics?

  19. Glad to see NT’s subsystem support has made such a prominent comeback! Always felt it was an awesome but sorely underused piece of engineering since the days of OS/2.

    Not sure if this can be covered in just one reply but I’m really curious as to how exactly can you access processes running on the Linux subsystem from within the win32 subsystem.
    You’ve stated that, say, calling explorer from bash is impossible, so, I presume this means that there is no communications layer between subsystems yet somehow you have to display bash within a win32 window and route all the relevant user / system events from the current win32 session to that bash process running on the linux subsystem.

    How is this done? Is data being routed through SMSS (which might explain, I suppose, why you can’t just call explorer.exe from bash for instance)? Also, (this is more of an idea for a “why the hell not?” project than anything practical in particular) would it be possible to change the default subsystem being loaded at startup or are there too many hardcoded win32 dependencies to make that possible?

  20. This is a really interesting development. If the workflow on Windows to work with open-source projects is as easy as it is on Linux, I’ll definitely give it a try. I’ll be trying to run Apache ZooKeeper and Kafka on my Windows PC, rather than in a Linux VM, just as a local test environment while I write my code. Eventually, it will be deployed on to real Linux but, for my dev environment, I’d really like to use Visual Studio for editing and bash to build and execute.

  21. Hi Rich,

    I’ve installed Windows 10 downloading from insider. I haven’t seen this any where. When can I see this? Appreciate some links/paths.

    Thanks

  22. Will bash scripts executable (by double click) in Windows Explorer? And can you drop files on the script and have the file names passed as arguments (like batch files)? It would be extremely useful to have hashbang support in Windows. Then a person could write scripts in an language they are comfortable. https://en.wikipedia.org/wiki/Shebang_(Unix)

  23. It seems that a major goal of this project is to make certain Windows remains a viable development platform without forcing Microsoft to dedicate developers to port every new project to Windows (like they have with redis, node, and many others). That’s fantastic. This benefits everyone. But I really think you should focus attention on supporting interaction between the Windows utilities and the Linux ones.

    Compared to running Linux in a VM, this solution certainly make networking and access files between environment much easier. But the user still has to worry about two separate environments with their own PATH and their own installations of git, awk, du, python, java, etc. And there’s a downside. VMs can more accurately mirror the production environment and can be easily backed up, cloned, or sent to another developer.

    Please don’t stop short of making the environment developer truly need to be productive. Many developers and admins currently use GNU tools to fill in the gaps of the Windows utilities and PowerShell. This wont help them. Think of amount of effort developers put into automating repetitive tasks, but the best environment for a productive developer.

  24. Dear MORONS at Microsoft, if you are not running a KERNEL then you just ported GNU Tools from the GNU project and a bunch of other projects.

    Thats the problem with Microsoft, they may be smart but you still morons, GNU != Linux. Jesus learn the difference.

    • They are not porting a Kernel or something, they redirect syscalls to win api, nothing else, this is not “linux” is GNU with GNU Tools and some open source software, not even a single thing from Canonical. There is no Canonical software there, just open source created before that crappy company existed.