Hacker News new | past | comments | ask | show | jobs | submit login
Bash and Windows Subsystem for Linux Demo [video] (msdn.com)
285 points by nailer on Feb 21, 2017 | hide | past | favorite | 300 comments

This is coming to Windows stable in April:

- vt sequences fixed (so stuff like colored output, midnight commander, etc work and the terminal doesn't screw up)

- Elixir and Go work

- Also Postgres and MySQL

- You can launch Windows apps from bash.

- inotify works

- Visual Studio can compile with GNU/Linux C/C++ tools, gdb, linker etc

There's some recent fast ring info on: https://blogs.msdn.microsoft.com/commandline/2017/01/09/bash...

From reading that blog, and also: https://github.com/Microsoft/BashOnWindows/issues/111#issuec... it sounds as if the Windows console (separate from bash, openssh, powershell etc) is being entirely refactored for creators update. So those fixes should also help powershell, ConEmu and a bunch of other common windows command line stuff.

It isn't clear how much people can appreciate this sort of thing without context. Back in the mid 2000's I was at a very high level Microsoft Developer event and got to ask about waning support for command line tools.

People of a certain age remembered well the power and simplicity of using DOS and its "console" to effectively develop code and debug, even without typing 'win' to get into "GUI mode".

But at this event a very senior engineer/architect in the Windows group (no longer with Microsoft) responded to my question of command line support with a very snarky response which was something along the lines of "It is called Windows not relic from the 70's so no, we really don't care if you can't use it like a time sharing system any more." And that was the way it was, anything you could do on the command line you could do in a GUI window with radio buttons and various text boxes.

And what was why I switched to MacOS as my daily driver because my personal style had me so much more productive in "terminal" mode than in "gui" mode, I preferred it.

Now you have Microsoft investing real time and effort to create credible command line type tools in their system and it is a remarkably good thing. I use WLS every day and its getting better and better. I have suggested they implement a local network service equivalent of the USB over Ethernet service so that you can easily share USB devices between the Windows side and the Linux side, the up coming visual fixes will address many of the minor annoyances. That is a really huge shift for Microsoft.

It's funny you mention switching from Windows to MacOS for the command line tools. I booted up a pre-NeXT Mac (an iBook with OS9) the other day, and was blown away to learn that there is no terminal at all! How quickly things changed after that.

Absolutely. My background was that I was Sun for years and on a "workstation" the most common window open for a software developer was an xterm not some IDE. That said, for people who "grew up" knowing nothing but visual studio and delphi, telling them that everything they are trying to do is easily done in the command line doesn't resonate.

Even though I am a huge command-line fan, I am not sure that "everything they are trying to do [in an IDE] is easily done in the command line" is entirely true ;)

While one can do at least as much, if not more, via a variety of command-line tools, the integrated build & debug workflow of a good IDE is invaluable to many. Esp. for those for whom learning a multitude of command-line tools, and syntaxes to drive gdb, profilers, etc. as a little costly/cumbersome.

ISTR from my days when I was a primary school kid playing around with my grandmother's Mac running System 7 that there were some (fairly lame) third party tools that attempted to implement a DOS-style CLI.

> - Visual Studio can compile with GNU/Linux C/C++ tools, gdb, linker etc

First VS Core, now VS proper. Impressive!

(going back to my ddd window on Linux, crying a bit inside).

A properly configured and well-curated collection of packages will yield an exceptional experience using emacs - if you're into that kind of thing. Add in some custom elisp and you're well on your way to a fully customizable development environment.

Are you talking about proper, legit Intellisense in Emacs? If so, I'm sold. More details?

I've been playing with NetBeans and it seems like a fairly reasonable C++ environment.

CLion is pretty spiffy IMO, though it uses CMake as the underlying build tool which may or may-not be your thing (I prefer scons.. but nothing's perfect).

KDevelop is also a very good C++ IDE for Linux.

It is quite good, as it is the basis of Solaris IDE, just some features are missing.

Re: Elixir

The Erlang/OTP 19.x releases are still broken because of some missing system calls. They seem to have an incoming fix though: https://github.com/Microsoft/BashOnWindows/issues/613

It's great that they keep open conversations like this for issue tracking and hopefully April will be working 100% by then.

For this reason, whenever I try to develop anything on Windows, especially systems related stuff, I will do so in a VM. I may develop a test suite and try running it on Windows, but the Windows Linux Subsystem will never be reliable to me, until it aims to guarantee 100% compatibly.

Bash and Windows Subsystem for Linux is a band-aid solution for a fundamental problem for Microsoft: Linux tooling and kernel are IT industry standards.

People have been developing on OS X outside a VM for a while now, and OS X is most definitely not linux. If they can get WSL to be as linuxy as OS X (and arguably it's already close), Windows will be as good a dev platform for linux development as OS X.

But they really need to fix notepad so it supports unix style line endings. That part of the demo was a bit embarrassing.

WSL is more Linuxy than macOS, it implements the Linux syscall interface rather than Darwin's.

I agree with this. OS X is a flavor of BSD. I've learned that it's often more helpful to search for "<thing I want to do> bash BSD" than it is to search for "<thing I want to do> bash OS X".

Making "Winbuntu" a fully compatible Ubuntu sounds like a really lofty goal, especially when it comes to things that expect a Linux file system.

I guess for me, it's easier to reason about Linux in a VM (or maybe a container), with all the limitations of that approach, than it is to wonder what surprise might occur as a result of trying to run something on Winbuntu. At some point maybe that will shift. It's not like VMs are exactly like bare metal.

Keeping trying hard Microsoft! I like Winbuntu enough that I bought a Windows 10 laptop just to play with it! Emphasis on play, not seriously use.

I've been using WSL since it was released to the fast insider ring. It's pretty slick. There have been some warts and growing pains, but the team has been very responsive to bug reports. I've seen responses as quickly as 2 public build cycles (about a week) to get a fix for an issue reported on their github site.

I love watching people developing on OS X, targeting Linux, without proper tests forgetting that Linux's FS's are by default case-sensitive in regards to file names, and completely forgetting that OS-X is case-insensitive, by default (and recommended to remain so, because most OS-X software is not developed with case-sensitive file-system awareness.)

>OS-X is case-insensitive, by default (and recommended to remain so, because most OS-X software is not developed with case-sensitive file-system awareness.)

A few years back, following my previous laptop which had been a flimsy Acer running Ubuntu which became unusable following malfunction of the fan, I was looking for a more sturdy laptop and ended up buying a mid-2012 15" MacBook Pro which came with OS X Mountain Lion I think it was. Being used to case-sensitivity from various Linux distros and on my FreeBSD servers, I decided to enable case-sensitivity for the system drive. That turned out to be quite a mistake indeed. Several pieces of software were unable to find the files they needed, so I ended up reinstalling the whole system shortly after, this time without case-sensitivity.

Following that I had a hardware problem that the Apple authorized repairshops I went to were unable to fix three times in a row so I ended up demanding a refund (Norwegian customer protection laws are good in this regard), and while I still think OS X is an impressive system I lost a bit of my respect for Apple after that experience. (I enjoy my iPod touch though.) Anyway, the reason I mention this is just to say, I don't know if case-sensitivity remains problematic in macOS. I find it highly likely that it still is though.

Can't wait to run docker in this. Will save me countless development hours.

I was already a fan of colinux back then but this has te potential of being infinitely better.

You can actually manage/control Docker for Windows (upon which you can run Windows & Linux containers) from your Docker client running in Bash (or Windows) on the same box.

Inception ... noitpecnI ;)

They are for one part of the tech industry (which I count myself in) but it's pretty obvious that for many others, Microsoft-based tech (which now runs everywhere) is a standard. Why not persue both?

Why wouldn't getting as close to 100% compatibility as possible be the aim? WSL is currently beta. The installation documentation has a big warning at the top that functionality is currently incomplete.

All I can say is that the first two things I tried on the Windows Linux Subsystem didn't work, mainly running Elixir and Debootstrap. It's okay that they aren't (yet?) supported, but something that looks & smells like Ubuntu, yet isn't, doesn't inspire confidence that it can be trusted to act like Ubuntu.

An alternative approach would be to call it Winbuntu, Winux, or simply Ubuntu for <windows subsystem architecture>. Then aggressively maintain a list of known compatibility issues, and stay on top of fixing them. Maybe even open source it?! A close sourced, not-quite-what-I-wanted solution is simply less interesting to me.

I'm not sure a public-facing curated list of specific compatibility issues would be practical at this stage of the project's life; it's changing fairly rapidly. FWIW, the bug tracker is public, and the team seems to be fairly responsive; a UPX Compression bug I ran into was tagged fixinbound within a couple weeks. https://github.com/Microsoft/BashOnWindows

The speed at which they can push new builds to people who aren't on Windows Insider is a bit unfortunate, though.

> All I can say is that the first two things I tried on the Windows Linux Subsystem didn't work, mainly running Elixir and Debootstrap. It's okay that they aren't (yet?) supported, but something that looks & smells like Ubuntu, yet isn't, doesn't inspire confidence that it can be trusted to act like Ubuntu.

You need to handle this anyways, as it's unlikely that your target deploy platform will always be ubuntu. In any case, you can just use docker like most OSX folks do now.

I'm not familiar with Elixir or Debootstrap (I'm guessing web-oriented)? But, I've had great success with using WSL for C++ oriented projects, building with both g++ & clang. Only issue in that regard I've had is that the emulated syscalls cannot currently enumerate ethernet devices. The calls are implemented, but fail at runtime currently. I've not yet filed a bug report, because I don't know how it should perform.

You should be able to enumerate network connections on recent Insider builds ... or on Creators Update when it arrives in ... well ... "Soon™" :)

I don't think they can open source WSL in any useful capacity because it's signed as part of the kernel itself - afaict this is also why an update to WSL is an update to the Windows build itself.

> - You can launch Windows apps from bash.

So I can basically do `code .` from inside bash and it will open VS Code in the linux sub-system folder? That's amazing!

Almost. `code.exe .` will do what you expect IF you are in a folder that's visible from the Windows side. If you're in a WSL folder, the Windows program will be run in C:\Windows\System32.

It has worked well for me to make a symlink under ~ to /mnt/c/Users/myaccount/, and that way anything under that symlinked folder is visible to WSL and Windows programs.

Hi - yes, we register the '.exe' extension with binfmt that then triggers WSL whenever a .exe is launched, allowing us to go find and spawn the requested Win32 process.

If you just want to type `code <filespec>` (without the .exe), then you can create an alias that resolves to code.exe.

Same for Notepad, etc. :)

(HN: bitcrazed is Rich, the person presenting in the video)

Hey Rich, can you (or colleagues) tell us any news on console? I get the vibe from Michael Niksa back in August [1] [2] there's a big changes happening that will fix readline-type stuff and I'd love to know more about this - I use ConEmu / Win32 SSH on Windows and it, was well as bash, seem to occasionally suffer from terminal-corrupting weirdnesses.

I'd love to know more about the causes, the fixes, whether the fixes will make it into Creators Update, etc.

[1] https://github.com/Microsoft/BashOnWindows/issues/111#issuec...

[2] https://github.com/Microsoft/BashOnWindows/issues/111#issuec...

Yes, we're essentially giving the Windows Console its biggest overhaul in > 30 years!

It's important to remember that the Console was one of the first things Cutler & team implemented when they started NT itself, and it's been updated, patched, partially-enhanced and modified quite a few times in the last 30+ years! ;)

We're in the process of modularizing much of the Console's internals, replacing particularly archaic parts with shiny new modern C++ collections, etc., removing unnecessary cruft, etc. ... while trying not to break anyone!

Much of the work we're doing right now will result in Maximus5 & the Console2 / ConsoleZ / etc. teams having to jump through far fewer hoops to implement decent terminals on Windows.

And while we're doing this, we're also enhancing the console to support *NIX VT sequences, adding 24-bit color, etc., working with several other teams around Microsoft who need Console changes to make their things work.

This week, we are planning & building features for the NEXT OS release!

As you can imagine, it takes considerable effort and care to do this and we've got a great team with Michael, Paul, Mike2 & Austin beavering away as I type.

Actually; small lie - Niksa is on vacation this week re-charging his fuel cells before I chain him to his desk again ;)

We'll be writing a series of blog posts in the coming weeks, summarizing what's new in Bash & Console in Creators Update, and will have some cool stuff to show off at Build 2017!

I'll also be speaking at OSCON 2017 in Austin (same week as Build!!), so stop-by if you're in TX and want to chat about Bash / Console :)


WSL is great, I use it every day and am very much looking forward to the next update.

Regarding future work, are there any plans to make the emulated Linux filesystem usable in the rest of Windows e.g. via a drive mapping?

Thanks and glad you like it so far ;)

We are keen to smooth out some of the filesystem interop challenges. There's a reason we've not yet removed the Beta label ;)

I'm a big fan of this new feature, enough that I wrote and released some open source code to launch applications before this was possible. Mine's a hack, pure and simple but it worked to fill in the gap but I'm glad to not need it anymore. Thanks! https://github.com/jaegerpicker/Rockhopper

Would I be able to setup Linux environment in VS? i.e. would I be able to include and write POSIX application with this update?

Did you watch the video? ;) Take a look at Visual C++ for Linux: https://blogs.msdn.microsoft.com/vcblog/2016/03/30/visual-c-...

Yes, I did, and it didn't answer my question, but the blog post does. Thanks.

In the video, my demo was to take a POSIX C++ application and deploy it to a local WSL instance, built it, run it and debug it ... from VS.

This is actually the (previously) missing feature that was preventing me from fully diving into Win10 + Bash.. very happy to see this

I was under the impression that only linux sub-system applications should be modifying files inside the linux sub-system.

For example, using windows explorer to edit linux sub-system files would be a big no-no.

Yes, that is the guidance we're giving right now. See my post on this subject for more background: https://blogs.msdn.microsoft.com/commandline/2016/11/17/do-n...

However, it's fine to modify files stored in your Windows filesystem from within Bash, so if you were in `/mnt/c/dev/project/` and launched `code.exe ./`, Code would open the current (Windows-accessible) folder.

First, I switched from OSX to Windows b/c WSL made it possible.

There is some weirdness with the recommended file system sharing. Git on WSL sees files as modified after they have been checked in from Windows. It means I either use Git from the IDE or from the terminal, but not both.

Excited to see how this continues to improve.

Great to hear - welcome to the party! :)

What you're seeing with git is likely to be caused by line ending differences. You've probably got "Convert line endings to Windows" configured in your Git on Windows, but "Checkout Linux line endings on Linux". Either way, both should match otherwise all your files will look different because ... well ... they will be ;)

Just for reference, I've been doing this for a few months now. I'm not sure what's changed, but you'll need ubuntu 16 (you can uninstall 14 and reinstall WSL to get it) in WSL to do it.

You don't HAVE to nuke & reinstall your Linux environment to get up to 16.04 - we also support in-place upgrades too ... so long as you're running a Windows Insider build >= 14951


Are you running the fast ring build?

EDIT: Actually, since I am doing that as well, I just tested it. And yes, it all works!

Cygwin has its own ANSI/VT100 emulation which is translated to Console API calls.

In the Cygnal project (http://www.kylheku.com/cygnal) I made a few fixes to this code.

With Cygnal you can write a terminal-oriented application using termios and VT100 escape sequences (or a library like ncurses if you wish). You just package it with the cygnal DLL, and any other DLL's. It will run fine in the console window.

For a demo of this, download the Windows installer for the TXR language.


The txr.exe executable happily runs out of the cmd.exe console window with history, multi-line editing, etc. There is not a shred of Win32 code in TXR: it's just (a much enhanced fork of) the Linenoise library which uses termios and ANSI codes. Not a single #ifdef WIN32 in there.

Wow those are some pretty significant updates!

I've loved the idea of bash-on-windows but it was missing just enough that it wasn't worth it moving away from my current love affair with the "git bash" system I'm using.

With these changes, it looks like I'll be jumping ship when it comes to stable!

Great work to everyone involved!

Agreed... I tried it for about a day, then went back to git bash. Will probably give it a try again after it goes to release. For now, I've been sshing into a linux vm, and using samba/cifs to mount my linux ~/ so I can edit in windows, but better integration would be nice.

Is iterating over network interfaces possible? IIRC that was causing a lot of issues with local nodejs dev servers

Yeah it works.

I can finally ping, do ifconfig etc.

Even htop runs. I am amazed! http://imgur.com/7P2J64h

This alone made WSL way more useful for me. Only thing that's missing now is traceroute.

We're working on traceroute for a future release. In the meantime, you can run `tracert.exe <ip>` from within Bash which will invoke the Windows trace-route command-line tool to do the same thing ;)

This was added to the fast ring builds in December. Not sure of the timeline to get it out into stable, but it definitely was a big deal to get.

On their blog they state that raw sockets (ping), ip address / ip route will work.

Still some work there though. Traceroute errors with: setsockopt IP_MTU_DISCOVER: Protocol not available

Yeah, to be clear here: We worked with the networking team to enable Linux Ping to open a raw socket, but we've not enabled carte blanche raw-socket support for all Linux processes.

We are, however, continuing to work on solving these and several other networking issues to close the gap in our networking support.

As a work-around, you could always call Windows' tracert.exe via the interop feature ;)

An if you're just using standard sockets technologies (e.g. HTTP, TLS, FTP, SSH, etc.) all should be good.

Any chance we'll see a first-party X11 server at some point? XMing, VCXsrv, and Cygwin/X all have some warts when it comes to stuff like windows previewing, copy/paste, acceleration, and fonts. OS X has shipped with an optional X11 server forever, and it would be great to see that feature parity in Windows.

No plans at this time; we're focusing entirely on command-line tools & scenarios right now. Besides, there are plenty of X Servers out there, no?

On the fast ring Go 1.8 and Haskell are running okay as well as inotify working.

Sorry for being dense but how is this better than running seamless window Linux under vmware? With that I can also access shared files, etc.

It's less overhead and better integrated into the system as a whole. After all a VM is still a separate entity in its own environment. WSL is jumping over the fence and runs Linux stuff in a Windows environment.

Think of it the other way. Why would you use wine if you could just run Windows in a VM? :)

Why someone might use Wine is that it's free software. That's about it.

I think the point that parent commenter tried to make is actually that one might use Wine instead of VM because Wine has less overhead.

> less overhead

is it really? last time I read tests WSL was slower than VMs

I don't know if I would call it better or worse, it's more about preferred workflow. I'm typing this on a MBP and I have a fleet of VMs specifically because I'm tired of playing the platform game. I can configure a VM specific to an app's needs faster than hosing my host OS with a very specific configuration that may not match production environments. Even with version managers like rvm or nvm/n there is just a lot to get wrong. It may be faster or less resource intensive to not have to spin up a VM but I've been in .NET land with desktop apps and now various web platforms enough to prefer this workflow. For someone like me, this would be for personal usage versus job related activities but I do see the benefit of having the choice. I just hope I'm strong enough to resist the temptation because my personal win10 laptop is a graveyard of rails installer and a few other various barely-supported toys.

you don't pay for RAM that the VM doesn't use and don't have to deal with madness that is sharing files over sftp/smb/nfs/shared folders/etc.

A smart VM will have ballooning to not throw away unused VM memory.

Because it's a fraction of the resource cost, and shares resources better with the host system as well?

So VS can do C/C++ compilation now. I wonder if they will extend VS to work with other higher-level languages like Ruby and Python (et. al.) ?

It would be nice to work from Windows but build for Linux that way, for other languages too.

Uh.... VS has always been able to do C/C++ compilation. Like... for decades now? Just not with the standard Linux toolchain, but you've always been able to build C/C++ projects on Windows.

Not only that, but Visual Studio is based off Visual C++ in the first place.

Thanks for the downvote guys. I wasn't born under a rock.

The article was talking about Windows Subsystem for Linux, and my comment was that VS can do C/C++ for Linux. I thought that was implied by the context.

Anyways, I know VS has done C/C++ for forever. :)

Yes, in Insider build 14965, we added NETLINK_ROUTE's RTM_GETLINK and RTM_GETADDR support which enabled ifconfig and network connection enumeration support : https://msdn.microsoft.com/commandline/wsl/release_notes#bui...

VS not only could build C and C++ since I can remember, but was a pioneer in the recent C++ revival. Btw VS 2015 installer offers Python tooling install if I remember correctly. See also: https://github.com/Microsoft/PTVS

In case the context didn't make it obvious... I know that VS is based on, and can do compilation for C/C++. I was saying basically, "Oh cool. You can do VS compilation of C/C++ for Linux now. Do you plan in introducing it for other higher-level languages too? (Ruby, Python, et. al.)"

> - vt sequences fixed (so stuff like colored output, midnight commander, etc work and the terminal doesn't screw up)

Does this mean tmux will work?

The OP asked if TMux worked on WSL, which it does.

Now, there are many, MANY, improvements required of Windows' Console which is currently receiving its biggest overhaul in > 30 years! Bear with us while we give the Console some much needed TLC and start to re-shape it into a clean Console infrastructure that supports modern Console demands.

I currently have zero issues running tmux and bunch of other software in mintty/wsltty


tmux should have already worked quite well in Anniversary Update (14393). There are some specific feature enhancements, such as 256/24bit color support (although tmux doesn't support 24bit color by default) and mouse mode support that should make tmux much more usable.

I've been running windows (using WSL for most of my development) for a few months and overall I'm very happy with it. Every non-GUI linux program I want to run works just fine on WSL, with the sole exception of (beta software) Urbit.

I do miss Xmonad-like window management, but windows does have shortcut keys that do a good enough job. Emacs works perfectly well. And Anaconda (https://www.continuum.io/downloads ) is actually a good native windows distribution of Python and Julia.

Cortana + voice recognition is actually pretty cool, I'm looking forward to hacking on it when MS releases the dev kit.

So far, windows seems to be an acceptable Linux. I will probably stick with it for a while, assuming I don't run into any crazy new blockers.

(I've been on Linux exclusively since 2001 except for a brief attempt to use OS X around 2009. That experiment was less than successful: https://news.ycombinator.com/item?id=1786930#1787411 )

Emacs has one flaw for me under WSL: the janky Windows console doesn't pass C-SPC. Meaning I have to bind set-mark-command to something else (like M-SPC), or download and use wsltty (fork of mintty).

But other than that Emacs is fine, and a lot of Linux stuff (Node, mongo, etc.) works great.

Who cares if Urbit doesn't work? :)

For the record, we fixed C-Spc in emacs on the more recent builds :)

To be clear, I use one of the GUI versions of emacs for windows. C-spc works fine there.

I'd like to play with Urbit - Yarvin and his goals are interesting enough that I'm willing to spend a few hours playing around.

Would you mind elaborating on what emacs in particular you're using? I use and love emacs but unfortunately the times I've tried to use it on windows it's been extremely unresponsive.

Woah I tried it again and it seems like it's working perfectly! It seems like the initial release for windows wasn't compiled with optimizations, so perhaps that's the issue I was observing.


Have you tried this one?


It's worked for me fairly well.

Indeed that's the one that I used. For some reason, even just moving the cursor around the buffer was extremely unresponsive, it would take seconds for it to register a cursor movement. I'll have to figure out if it's some package I'm using.

What do you use for colors/theme in emacs in WSL? I ran emacs with the default settings the other day and there was a lot of unreadable blue on black.

Once the latest build filters out to Windows Update, I will probably only invoke the Windows build of emacsclientw, but it would be nice to have something habitable in WSL on occasion.

I set TERM=vt100 and run it in stunning mono.

Nice :-)

That's much easier on the eyes. org-mode folding doesn't seem to like it, but it should be no problem sticking to Windows Emacs for that.

Every non-GUI linux program I want to run works just fine on WSL

Most gui programs seem to work ok as well, though you do need an X-server running on Windows (e.g. the one in MobaXTerm does the job)

Yep. Pulseaudio works similarly with enough poking and prodding.

I was able to do stuff like watch cat videos on youtube with sound at full speed (though presumably not hardware accelerated).

I'm pretty happy with it too. For the things that are implemented, it works better than MacOS did as a casual Unix for me. Mostly because I prefer the Ubuntu tools. I'm still using a genuine Linux box for real work though.

The big feature I'm missing is network file systems.

> Emacs works perfectly well

Do you use spacemacs by any chance? I tried emacs with WSL when the Anniversary Update was released and ran into this issue:


I'll try it again when Creators Update is available and hope for the best.

Edit: NM, just saw below, after I posted this message that you're using the Windows emacs build.

The biggest problem I have with the WSL is that it is intrinsically tied to stable Windows releases; there is no way to get incremental updates for Bash on Windows unless you subscribe to the Windows Insider program, which is a way of running prerelease versions of Windows.

So in order to get Linux features like inotify working you have to sacrifice the stability of your operating system.

This looks like it'll be true till the end of time. Does your dev work depend on bug fixes or certain syscall implementations? Well, either run an OS that may or may not work at any given time or wait several months for the next release.

A couple weeks back I tried to give WSL a try but everything was broken. Inotify prevents hot reloading, which really makes my life just dandy, so I tried to transition to the insider program in order to get my fix. To my chagrin, this caused Node to up and break on me. Like, full stop doesn't work anymore.

I ended up going back to Linux. I really hope that developing on Windows becomes something other than 'awful' - for me at least - but I don't think it's quite there yet.

@OhSoHumble: We totally hear you. We'd love to ship WSL builds uncoupled from the rest of the OS, but at the moment, we're developing WSL at a breakneck pace alongside several other critical kernel feature changes which all have to ship in lock-step.

A good example of this is the work we've been doing with the networking team to add additional network socket mode support to the NT kernel's networking stack so that we can create the correct socket semantics that Linux apps expect. We're also working with the NTFS team, process & scheduling team, management infrastructure, etc.

That's good to know. Maybe I'll try to use Windows as a development platform when it has another major release. I'm really impressed that WSL exists at all. I didn't think Microsoft had it in them to allow such a project to flourish.

At the end of the day, however, I really hate writing code on Windows. I don't write much Java or C#, instead sticking to Elixir, Ruby, Python, Node, and Golang. Every time I try to use Windows I just get super frustrated. I remember showing up to a Code for San Francisco meeting with a Windows laptop and being the only person there without a Mac. I mean, go check out node-gyp's 500 comment 'windows users arent happy' issue to see how deep the rabbit hole goes.

WSL makes an impact on a lot of the issues that frustrate me. Knowing I have a tool chain that can actually compile C extensions matters. I'll never, ever bet my career on Windows but I might one day use it as hobbyist development platform.

While I have you here, will the Windows console ever 'get better?' Rendering console text on Windows is... pretty awful, I'm not going to lie. Going from Linux to Windows is fairly painful; when I `cat` a large file in Windows it then takes seven years for all the text to render. Day to day usage just feels sluggish and awkward in comparison to a Linux terminal. Even if WSL was a flawless piece of engineering, the 'terminal experience' on Windows could do with some TLC. Are there any internal plans to make improvements?

As far as the console "getting better" - it's getting better with every release. This last release we focused on enabling full 256color/24 bit color support, and enabling VT mouse mode, to better support terminal applications. Not only that, but we've also been working constantly on performance enhancements under the hood. IIRC, before AU, we would try to repaint the frame every character, now they're aggregated to 60 FPS. It's getting better, not terribly quickly, but we're getting there :)

> A good example of this is the work we've been doing with the networking team to add additional network socket mode support to the NT kernel's networking stack so that we can create the correct socket semantics that Linux apps expect.

Ooh! That's nice.

I was slightly disappointed I couldn't SSH tunnel or do too much with network tools when I gave it a try not long ago. I am definitely looking forward to that.

I think you are being too harsh -- this is an in-development feature. Once it gets stable things should "just work", and you'll get an update in a few months, like most pieces of software. At the moment you wouldn't want to rely on the beta version for anything important -- some betas are fairly broken (as you would expect with betas).

It is unfortunate that Microsoft couldn't figure out how to write this in a less kernel-attached way, but this is adding some powerful new functionality at many levels of the kernel, that will hopefully provide long-term benefits.

You could very well be right. I really don't want to take away from the fantastic work that the WSL team has done.

However, as a developer, I want a development environment that is stable and easy to setup. Windows has always been a huge mess to develop on and is the red headed step child as far as support for every open source project out there and the WSL implementation solves 90% of associated problems.

That being said... both MacOS and Linux are easier to code on. From compiling C extensions to file path parsing, UNIX-based operating systems have just turned out to be better development platforms. From my perspective, at least.

To emphasize, I have less of a problem with the work-in-progress nature of the project as I do with the release cycle. If the operating system stands in the way of getting work done, then the end user shouldn't have to face the dichotomy of whether or not to sacrifice core system stability in order to achieve his or her goals.

@OhSoHumble: Second Point:

"A couple weeks back I tried to give WSL a try but everything was broken"

Did you run an Insider build? 14986 completed a batch of inotify related syscall improvements since we first added inotify support in 14328 (Details here: https://msdn.microsoft.com/commandline/wsl/release_notes)

My main project is a Rails/Ember.js application to help people find affordable housing in the bay area.

My problem was that the CLI built to help glue the two together didn't work on Windows so I tried it out in the WSL. Because of missing inotify support, hot reloading was broken. I found that I really missed that functionality so I moved to the fast ring of insider builds. After an update, node was completely broken. I didn't know how to switch to the slow ring to get a build that may have worked so I switched to developing to the Arch install I have on another drive.

What OS build & Linux version are you running? Type `ver` at the Cmd prompt, and `lsb_release -a` at the Bash prompt.

What do you mean when you say your node is "broken"?

And I don't follow re. your Arch install on another drive?

Output from `bash --version` on macOS:

`GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin16) Copyright (C) 2007 Free Software Foundation, Inc.`

that's a 10yr old bash and there's barely any shell magic that you can do on Linux that won't work on macOS. And since by far most devs use macOS, most binaries support at least the macOS version of bash. All in all, no need to worry :p

> by far most devs use macOS

I'm not sure about this - that seems too extreme of a statement. If there is any winner, it's going to be Windows. IMO, Linux and macOS will be within 5 percentage points of each other. From what I've seen at university, it's something like 60% Windows, ~20% macOS, ~20% Linux (usually Ubuntu). Much more Linux/Mac in the "hackier" courses, usually with a slight majority to Macs.

Where can reliable statistics be found on this? HN isn't exactly indicative of developers in general.


That's all I need to say about that.

As for the reasons.. Devs want a POSIX (macOS, Linux or BSD) system because many of the utilities used are written for that, and much of the infrastructure you will be working with in the future will also be POSIX. Of all the POSIXes, macOS is by far the most capable and stable laptop OS. Macbooks are still unrivaled, with only the Dell XPS range coming somewhat close.

They are also the only company with both a solid phone and computer product, meaning you get lots of ecosystem goodies (verify iCloud logins with a push notification on your iPhone, Wi-Fi passwords entered on your MacBook instantly work on your phone, 'instant hotspot', AirPods intelligent multi-pairing, etc)

And that may seem like I'm drinking the Apple kool-aid, but I'm not. The audio quality on the AirPods is terrible. In fact, Apple has never produced anything but mediocre audio gear. The $200 price bump on the MBP 2016 is unjustified. Removing the headphone jack on the iPhone is utterly insane, even if they did use USB-C (maybe in 10 years when all audio-out ports on everything everywhere also uses USB-C it would have made sense). macOS stripping out all GPL tools because they don't want to use GPLv3 stuff, etc. etc. etc.

That's an anecdotal photo and an off-the-cuff rationale.

Here's data:


~50% Windows, 26% OSX, 22% Linux, for the average "developer-who-fills-a-survey-on-stackoverflow".

And I doubt anybody will argue that the masses of developers who don't frequent StackOverflow are less likely to run Windows.

Not sure a self selected group of college aged kids really counts as an effective sample to qualify that 'by far most devs use macOS'


That's apparently the school of journalism...

Wow that site really doesn't like adblockers

My impression is that most devs who write POSIX software these days use macOS (with possibly Linux running in a VM.) AFAIK, that's more to do with preferring Apple hardware, and then Linux not having 100% support for said hardware (e.g. touchpad multitouch / "force touch".)

Devs who write native apps for an OS (e.g. DirectX games for Windows) will of course use that OS.

See, that's not really what I see in my experience. About half of my friends that hack around use macOS, another half use Linux, and then a couple use Windows.

In general, I see Linux native used as often as Mac native, and Linux VMs used on Windows all the time. POSIX has little to do with it.

I've interviewed at a couple local companies with 50+ devs each (mostly web dev positions), and almost everyone uses a Mac. This is anecdote of course, but I very rarely see devs using Linux professionally (natively, not in a VM).

That said, it depends on the kind of work; obviously, .NET developers almost exclusively use Windows, and I've noticed that sysadmins and system engineers are a little more likely to use Linux.

its more about supported syscalls and buggy behaviour in their linux kernel emulation than specific versions of specific tools.

You can get a newer bash, so that comparison is particularly moot.

My point is you don't need to, even running a shell that's 10 years old :)

Output from macOS Sierra: GNU bash, version 4.4.0(1)-release (x86_64-apple-darwin16.0.0).

That's your Homebrew bash..

Does anyone know the roadmap for WSL? My guess is that WSL itself is still unstable right now and later on it won't really need a lot of updates.

On top of it, the Ubuntu userland should be freely upgradable - I think.

Yes, the Ubuntu userland is upgradable using exactly the tools you would expect. (The system even includes a Scheduled Task that does security updates every week.)

> My guess is that WSL itself is still unstable right now

Correct, it's currently a 'technology preview'.

Actually, it's currently a 'beta' feature while we continue to expand the breadth and depth of WSL's syscall implementation & supporting tools.

That said, WSL is now far, FAR more compatible with the majority of mainstream dev tools than it was in Anniversary Update or early Insider builds.

Don't take my word for it - I am biased ;) - but if you've not taken a look at WSL in 2017, you might be surprised by how much now works very well :)

IIRC WSL is still in beta.

Not since Windows 2000 have I been so interested in an upgrade to a new Windows release. Only at work do I have to suffer through Windows, but this would make things much nicer there.

I hope/pray that readline and/or editline work correctly on bash et al?

Do Windows CI services like Appveyor support WSL? If so I would hope that deploying to windows for lots of high level software is relatively painless.

Head scratcher from the video:

> What if I want to open this file in notepad?

> ... <demonstrates opening notepad from bash>

> audience applauds

Ugh, the only thing worth applause here would be if instead he had said "and we finally taught notepad how to work with different line-endings" or "and we finally deleted notepad". The demo clearly shows the shebang line mashed in with the rest of the file contents. "This was a very popular ask" -- from whom‽ To present things as a dichotomy between vim and notepad is not honest.

EDIT: comments below have clarified: the feature refers to launching Windows processes from linux ones, not notepad specifically.

The idea is that you can probably open the file from other windows programs (like Sublime text).

For a while, it was impossible for windows programs and WSL content to mix (and if you could somwehow do it, it was highly discouraged).

But that's no longer the case. Notepad is just an example to prove this point.

The Notepad line ending thing is kind of shameful but Notepad is ok for what it's supposed to do.

It truly is a Notepad. It launches quickly and has a non-nonsense interface.

It's not meant to be a programmer's editor. It never was, it never will be.

Agree 1000%! Was waiting for a comment like yours to help drive the case for some updates to Notepad to support NIX file endings, etc. ;)

Anyone running Win10 who wants to see Notepad support NIX file endings, PLEASE submit feedback via the feedback app - that way Notepad's owners get to see your pleas ;)

Unfortunately the Feedback Hub application requires me to adjust my system wide privacy settings to allow sending who knows what to Microsoft.

I suppose I could temporarily change the setting just to give line ending feedback for notepad.

what feedback app?

I think it's available since the most recent stable Windows update - there's an app literally called "Feedback" you can use to report and upvote issues.

I think they mean launching Windows-side apps from the Bash CLI.

This had nothing specifically to do with Notepad, I would bet they just used it as a simple example.

I think this means that you can finally run EXEs in an easy way, directly from WSL. Without installing cbwin.

Basically this: http://stackoverflow.com/questions/38920710/how-can-a-run-wi...

> The demo clearly shows the shebang line mashed in with the rest of the file contents.

Demoer specifically comments that it's broken (obvously CR/LF differences) and they're fixing it.

Also VS Code for Windows might have been a better example than Notepad but you get how this could be useful.

I was so split as to whether to show Notepad or Code, but figured that more people were aware of Notepad and would grok what I was trying to demo so went that way.

Plus it nicely demonstrates one of Notepad's key weaknesses to help drive awareness with the Notepad team ;)

There's really a Notepad team?

There's not a "notepad team", but there is a "notepad team ;)".

There's probably a team that's responsible for Notepad. I doubt they exclusively focus on Notepad :)

Yea, fedora user at home, stuck on Windows 7 at work. I've actually started to pick up some Powershell for some light scripting. Have had a request in to the Vogons in IT to install python for windows for about 3 weeks now and I'm still waiting...

>and we finally deleted notepad

I think visual studio code is what you're looking for.

what works right now is exporting DISPLAY to e.g. mobaxterm and running Linux X apps.

i'll admit i'm super duper happy about this, can't wait for $WORK OS upgrade.

> Not since Windows 2000 have I been so interested in an upgrade to a new Windows release.

Well, yeah, Windows has been in the dollar milking phase for quite some time now (at least a decade).

It's no longer about delighting the user (yes, even Microsoft used to do that!). Or even just keeping them happy. It's just about keeping them not unhappy enough to switch to the alternatives.

I don't know about you but Windows 7 and now 10 have been quite solid for me, at least.

Windows 7 was a clear and undeniable update over XP and Vista while 10 refines a lot of Windows' weak spots (such as lack of virtual desktops).

I Still wish they did the opposite. I want to seamlessly run an occasional windows app in linux, and I would pay for it. There is literally zero chance of me switching back to windows for day to day usage.


idobai, I can't reply because your account is banned, but last I tried Wine and Crossover do not work for the apps I am trying to use.

Edit 2: cyloneyes, you're banned too. But "They" would be Microsoft. They are the only ones who could really do it.

> I want to seamlessly run an occasional windows app in linux, and I would pay for it.

Please define "seamless" in this context.

If you mean that you want to have the running Windows apps appear as window in your Linux environment, VirtualBox has a Seamless mode that will do that. I haven't tried it, but what I find with Google seems to say it works as expected. VMware Fusion (on the Mac) has a similar mode called Unity. The VMware one seems to work well enough, but I haven't tried it extensively.

If you want to be able to open files in Windows applications from your Linux environment, I'm not sure if this is possible. VMware Fusion (on the Mac) has this - I can right-click on files in the Mac and see various Windows programs on the "Open With" list. I don't know if this feature exists on VMware for Linux, but it would be worth investigating. I'm not aware of an equivalent with VirtualBox.

Combined, these two features would probably give you the closest thing to a seamless environment that you can get.

If you just want to run Windows on Linux and are willing to put up with the friction of using a VM, VirtualBox does a decent job and makes it fairly painless.

I've used virtualbox, but it doesn't work with everything, especially when it comes to hardware. By "Seamless" I meant Binary compatibility, with all the libraries, fonts, etc necessary to have %100 compatibility. I know it's a pipe dream, I'm just saying it would be nice.

I think the same. (Actually the title sounds like running Windows on Linux ;)) I'll be curious what happens - somehow I'm thinking they would be pretty stupid to do that. There is so much high end engineering and design software running on Windows only, they'd loose them all. On the other hand...does anyone need Windows except in the grey and boring high end/office section?

As a matter of fact, people are moving away since some time, either to Linux, macOS ooooor iOS/Android (haha). I guess even by economical means removing that lock-in may make sense.

Just a note to anyone looking to go down this road: IO performance is still pretty awful last I checked. If your workflow is IO intensive (non trivial Rails app, let's say), proceed w/ caution.

https://www.reddit.com/r/bashonubuntuonwindows/comments/5ece... - My last check.

(Addendum) I did a Fast Ring update on a separate machine and did not see substantial performance improvements, but the comparison is not valid between the machine linked and the machine I tested on, so I'd be hesitant to say that the performance hasn't improved at all, just that IO performance is definitely a weak point to WSL.

Yes - IO perf is not yet where we want it to be.

We have some improvements coming in Creator's Update and more substantial improvements planned in future releases, once we've completed some work with the NT kernel filesystem team.

Is this why Visual Studio is scp'ing source files around, instead of just copying the files to that /mnt/d directory and invoking the compiler there? That seemed like a big hack to me and it wasn't exactly clear why they were doing it that way (near the end, last five minutes).

With Visual Studio Code, Microsoft is making Windows 10 really appealing to developers. I personally won't jump any time soon, I am really satisfied with my work environment on macOS (and Linux inside VM) (unless I got locked down into Microsoft stack for work, in that case I will gladly switch, but it's not like I will have any other option). But anyway, I recognize and appreciate the change at Microsoft's direction of thinking, it's awesome! I wouldn't believe if somebody told me this 10 years ago...

VCpkg (and ofcourse CMake support, without it I don't use VS honestly) made me to make that switch ! it is awesome, it is one thing as C++ dev I always dreamed of

VCpkg is so much better in my opinion than installing library devel packages on linux. Makes it a pain to keep track of them. Also the code completion and refactoring capabilities are itself worth it.

You can now also compile using the gcc toolchain if you have WSL installed.

I agree, it is much better option than traditional /usr/lib

those are some cool changes. For those who can't/don'w want to watch the video:

- 24 bit color support added.

- lots of work to support more programs

- launch windows programs from bash (notepad.exe for instance)

- file change notification support (to allow for automatically rebuilding a website on file change for instance)

- can build a C++ project in Visual Studio and deploy it to your local WSL env, so you can run it directly from the local bash. (Visual Studio generates real linux binaries : ELF 64 bit lsb executable)

- Remote GDB Debugger: Can use visual studio debug engine to debug linux executables (It looks like this was possible before for remote machines [1], but now it can be done locally on a program running in WSL.)

[1] https://blogs.msdn.microsoft.com/vcblog/2015/11/18/announcin...

I'm still afraid to fully depend on this, and i'm sure i will be for years to come, but this is by far the most i've been interested in windows.

Who knows, in 3 years i might be able to ditch OSX for Windows, because some of the Surface devices actually look decent (no idea how true it is tho).

I ditched OSX for a Surface Book and am really happy with it. I use WSL everyday and primarily develop in Ruby.

Dumb question: Why did they name this "Subsystem for Linux"? (Old name was Interix, subsystem for UNIX-based applications, or "SUA".) Does marketing/users believe there is a distinction between Linux as a kernel and GNU as a source for a userland? Irrelevant? Curious what others think.

The big difference is that it isn't just POSIX compatible, it is a full out "bug-for-bug" emulation of the Linux kernel specifically with an eye towards binary compatibility. Out of the box, the userland here isn't just GNU, it is entirely the same binaries as shipped by Canonical in Ubuntu.

Old Interix required retargeting and recompiling binaries, similar to how you would need to recompile to target the differences between Linux and BSD. WSL runs Linux binaries without the need to retarget or recompile specifically for Windows.

This also means that the long tail ecosystem of Ubuntu PPAs and custom binary download sites all mostly work, too.

>the userland here isn't just GNU

Ah okay. Shame that calling this "GNU/NT 10.0" would not be proper then.

It’s “GNU\NT 10.0”.

GNU\Linux\NT 10.0

There's still enough GNU there that you could call it that if that amuses you to do so. (Though I bet RMS will happily throw a fit in your direction if you do. ;)

The old stuff provided source-level compatibility with UNIX via posix compliance.

The Subsystem for Linux is essentially an implementation of the Linux ABI, which is distinct from UNIX and provides true binary compatibility.

The ironic thing is that WSL itself is deliberately not Linux; the only similarity is the user-space ABI.

Unfortunately, I've met very few developers (admittedly interacting mostly with students) who have any understanding of what is Linux vs. GNU utilities vs. UNIX, vs. Ubuntu. "macOS is basically Linux right? Its because of the Terminal". screams

Agreed. The name is backasswards; it should be "Linux Subsystem for Windows".

Can't lead with someone else's trademarked product name.

You'd be amazed how complex and difficult product naming can be ;)

Just be glad we didn't call it WSRPGLCB - Windows Subsystem for Running POSIX, GNU and Linux Compatible Binaries ;)

Yeah, the name is pretty misleading. I first thought it's about MS making something to run on Linux. It's not.

How is the file system performance going with this? The latest release version runs Rails worse than shared folders on VMWare which is slow in bad way. Running MySQL on top of it might "work" but is it fast?

IO perf isn't where we want it to be yet, but we've some improvements coming in Creators Update and more planned for future releases.

Is it possible to access network drives yet? If not, is this something that's being worked on? Thanks!

Access network drives?

Via SSH? Sure.

Via Samba? Yep: https://www.samba.org/~garming/

If you mean MOUNT network drives, then, not yet, alas. But yes we're keen to build that support when we can.

I think they mean network drives mounted or accessed in Windows. For example, from WSL I can't access files on my network share (in windows it's \\pc-name\\shared, where pc-name is running Samba under Linux). Mapping a drive letter to it doesn't work either - the only thing that shows up in /mnt is c. This is quite a pain.

Yep - that was the mount thing I mentioned in my prev' reply: We've not yet got around to mount support, but it is on our backlog and we're keen to get to it when priorities allow ;)

Even if they optimize to the point of native Windows speed it will still be slower than native Linux. Its a well known fact some heavy IO programs run faster under Wine than native.

With something called Cygnal, you can make native Windows applications, while taking avantage of all the POSIX interfaces in Cygwin. No special subsystem required, just some DLL's.


With all the drawbacks that Cygwin entails. Plus the requirement to rebuild the code instead of just using the Linux-native ELF binary.

Those are two things with very different goals.

Which drawbacks are those? (One is performance, unfortunately).

Rebuilding the code is the norm in the GNU/Linux landscape.

Is Ubuntu x86_64 built from Fedora x86_64 packages? Etc.

The requirement "I want to run Linux stuff on Windows without rebuilding" is basically stupid, because you normally don't even run stuff from Linux distro A on Linux distro B without rebuilding.

It sort of works for programs that have minimal, reasonably old dependencies.

People like to use package managers to install thing in a Linux distro. Supporting binary compatibility means that they can just use apt instead of building something new, and rely on Canonical for creating packages.

If you're using Ubuntu and relying on Ubuntu packages, that's not "binary compatibility". That's using Ubuntu binaries on Ubuntu. Ok, it's the trivial base case of binary compatibility: A is compatible with A.

Ubuntu users do not pull down Fedora packages, right?

I'm talking about Windows supporting binary compatibility with Ubuntu, so the Ubuntu userland can be run on Windows.

Newb question, does this "Winbash" run Linux/posix/unixy binaries that wouldn't otherwise run or does it assume the actual Windows dists/builds for (Elixir / Go / PostgreSQL / MySQL / GHC / etcpp)?

* Yes, these are native, ELF binaries. Yes, you can compile it on your linux server, cp it across to windows, and run it.

* No, it is not an emulation. The win10 kernel + compatibility layer just happens to be able to also run ELF binaries. Yes, these show up as standard processes, and can be interacted with using normal windows tools (eg taskmgr).

I see, thanks, this curiously "mildy" (or perhaps, increasingly/incrementally) incentivizes most of these linux/posix/unix-"native" FOSS projects to no longer provide separate "Windows builds": simplifies code-bases, deployment, documentation, support, everything. But if they still continue to do, they have just another "support/bug dimension" to deal with in addition to "OS" --- the old "Windows build" plus also now "X-ish build under Winbash".

In another twist to this, this dynamic then might 'incentivize' users of those packages to upgrade to 10 when they wouldn't have otherwise (or switch to Linux for good ;)

Windows also needs to simulate the Linux kernel ABI -- not just "run ELF binaries". It's like "kernel personalities" in BSD.

Erm ... that's exactly what WSL does. Not quite sure how we'd be able to run ELF64 Linux binaries without building a comprehensive Linux ABI compatible layer.

You might be interested in some of these videos and posts: https://blogs.msdn.microsoft.com/commandline/learn-about-bas...

I think "bash on Windows" is not a valid way of describing what it is.

Cygwin, which allows you to run bash among many things, has been available for TWENTY TWO YEARS now. However it required such software to be ported and recompiled specifically for its use with Cygwin.

The difference this time is being able to run unmodified Linux software on Windows, through an application binary interface called Windows Subsystem for Linux or WSL.

"Bash on Windows" is the least tech-savvy way to describe what is going on.

> Bash on Windows or Bash/WSL got the most votes in early polling while we were choosing a descriptive name for this unusual feature, especially compared to WSRPGLB (Windows Subsystem for Running POSIX, GNU, Linux Binaries) which felt a little cumbersome


That should not have been a poll option in the first place because it oversimplifies what it is.

Can anyone please tell if Windows SubSystem for Linux coexists well with Cygwin64 and/or msys? I have Cygwin64 installed. I don't use it a lot but it helps to run some deployment bash scripts which otherwise won't run on Windows. So it will be good to know if Windows SubSystem for Linux messes up with it or not.

Both run fine next to each other. The only conflict I can think of is if you don't call "bash" via a complete path, but rather rely on PATH environment variable.

Btw. any reason you are not running those bash scripts in WSL now?

Thanks for the info. Didn't try the WSL yet. Was afraid to break the workflows which are already working.

Planning to give WSL a shot soon.

You can actually install mingw for Linux in WSL and cross-compile win32 binaries, which is pretty funny.

I just ran my local go project in WSL. And I can confirm it works just like it does in Linux. This is huge for everyone!

Along those lines, a great trick for Go on Windows is to set your $GOPATH outside of the WSL filesystem, so you're developing in, e.g. /mnt/c/. This gives you full access in both Windows and Linux to your Go project, so if you need to open a file in Photoshop, etc. it's painless.

I seem to miss the point why this is huge. Why can't the project compiled for Windows in first place? Are there System specific calls?

I like to do my Go development in a Linux environment. So if I wanted to use Windows as my main OS, I'd have to either dual boot or use a VM. Now I can just develop directly in WSL.

A lot of people like to also develop in an environment they are going to deploy in. In my case I have some linux specific path in my code.

I am also running now Gogland Linux version through WSL.

Any news about 256-color support? I understand the desire for the extreme backwards compatibility, but it requires some manual magic done to display things properly in fish (which, thankfully, works really well with Bash on Windows after the aforementioned magic), and even then it will only support 16 colors.

Yes, we support every color sequence there is now, for full 256color/24bit color support.

At this point, I believe the terminal emulation is pretty close to complete, so if you notice any other shortcomings, make sure to take a look at or GH page for issue reporting:


Awesome, thank you guys!

The way I solved the terminal emulator shortcommings is this: Install a gtk-based terminal emulator with gtk/gnome dependencies on you ubuntu subsystem and run it with `DISPLAY=localhost:0.0` environment variable. This works if you run XServer Client on your Windows side. I use XcSrv and pantheon-terminal.

Konsole or yaquake are far better options

Those are pulling KDE dependencies? I didn't consider them as I already used GTK dependencies for rendering other software, so I wanted to stay on GTK stack.

It might work in ConEmu. As for the native Windows console, I wouldn't hold my breath, considering that that'd be rather incompatible with the current framebuffer and would probably require a lot of new Windows APIs.

I am using ConEmu, so that works. Thanks!

They just said they support 16 million colors.

When I was playing around with WSL a few months ago, I came across this emphatic caution from the devs to not modify any files in the Linux subsystem using Windows applications (aka anything with a GUI)[1]. Apparently it destroys file metadata and breaks things.

I know it's not that hard to keep your stuff in /mnt/c or wherever, but I wonder if there is any plan (or if it's even possible) to eliminate this last bit of incompatibility.

Is it possible to run a GUI version of the Linux version of VSCode on WSL?

1. https://blogs.msdn.microsoft.com/commandline/2016/11/17/do-n...

If Apple gives up on the Mac Pro and Mac mini for good, the Bash Windows Subsystem may be my new home.

I've been sing the Linux subsystem in my new Windows install for the last couple weeks, after buying my first new PC and first Windows machine in ten years. It's actually very impressive, and I like it.

My PC has a super loud fan system that requires software support to control to get it quiet. Under my Linux install this was turning into a configuration nightmare, trying to find the right incantations -- under Windows it is working nicely. As are the video drivers.

So I am doing my development in the Windows version of CLion, but doing the actual compiles and git usage etc. in the Linux subsystem. It's working really nicely. And for the few GUI I need, apps I run Xming and set my DISPLAY and it works perfectly.

Same here. I could not get VS code running. However, I could get Gogland and Pycharm running. So I will just use that I guess.

A basic thing, but glad they updated console to support more colors and basic vt sequences. Currently I just have X11 server on startup and through some scripting have a shortcut to launch an xfce4-terminal instead of the native console.

I use ConEmu (and Windows openssh) and have to deal with sporadic console breakage. Apparently this should be fixed with the console rewrite.

this is my setup as well, my vim theme looked horrible without the extra colors.

My computer usage tends to be as a dumb terminal for SSH, and in that regard, I'm not having any trouble with WSL

I couldn't spend more time with that. But my overall experience with WSL is positive at least I don't need to install cygwin just to get basic tools. Windows fs is mounted on /mnt/c which is easy to type. I assume most of important syscalls are already implemented to translate. Even though sometimes bash.exe stops responding and maybe more enter key works. But bash is working like a jailed process, WSL does not report Windows processes that run to it. Which is a deal breaker. Frustrating maybe even more than running without dbus.

That's because bash.exe isn't /usr/bin/bash. It's a confusingly-named frontend for WSL, and can essentially launch and proxy any Linux app.

It is good to hear that both Ruby and Elixir work now. I had issues with both when I first tried Bash on Windows.

The Windows Subsystem for Linux felt incomplete to me the last time I tried it. I guess that is one of the advantages that macOS has in running Bash. macOS IS Unix, so Bash just fits, rather than being a bolted on service, the way it is in Windows. Hopefully things are much smoother now. It is certainly nice to see Windows finally get a good, cross-platform shell.

EDIT: Oops! It looks like Erlang 19 still isn't quite there...

Looks great!

I won't switch from Mac anytime soon, but competition is always good. Can't wait to see how Apple will respond to latest Microsoft actions (WSL, Surface Book and Surface Studio).

if it responds. apple looks more and more like a luxury goods company and the things you mention aren't that. (not saying it won't, but i'm pretty sure 'how' isn't a certainty.)

What I really want is for the symlinks created on Linux to work on Windows. Right now, Windows can't read them at all.

It's impressive how fast the WSL team is iterating. Being able to create and debug Linux exe's through Visual Studio is pretty damn slick.

I'm pretty happy that Windows Subsystem for linux mostly works. I was able to get Don Melton's video scripts for video conversion to work on my Windows machine quite nicely. I do wish they'd update the base version of Ubuntu used to the 16.04 release. I had to update a bunch of the software needed as the releases for 14.04 were out of date. (ruby being the main one)

Looks like Creator's Update will have 16.04: https://blogs.msdn.microsoft.com/commandline/2016/10/19/wsl-...

Yep, I'm running 16.04 on my machine. Works great.

Now all we need is a first-party X server...

Any particular issues you've got with the existing third-party ones? I don't honestly use them often (I just work on the Windows side for 99%+ of the GUI stuff I need to do), but I've not had any issues with Xming, even on a HiDPI display.

It's been a few months since I tried, but I couldn't get OpenGL stuff to work with an X server. I needed it to run OpenAI's gym platform.

Xming works, but it does have some warts (at least, on my machine YMMV). The three things that bug me most about it:

1. Copy/Paste between Windows and XMing is pretty dicey. Sometimes I have to do 2-3 copy or paste attempts before one will go through. I got into the habit of hitting SHIFT+CTRL+C (or CTRL+INSERT) 3-4 times in every XMing window under the hope that one would take.

2. XMing's window previewing is kind of messed up. if you have multiple overlapping XMing application windows, the ALT+TAB and taskbar previews show the overlapped union of both windows, which makes it really hard to tell which one is wich if you have multiple terminals open or something.

3. On some applications, the DPI detection seems kind of wonky.

I even bought the paid version thinking it would fix this stuff, but it didn't :(

What we need (last time I checked) is cron jobs and persistent services (sshd pls).

sshd works I guess. I can start sshd on WSL and connect to it using ssh from Visual Studio to build my C/C++ code on Linux using gcc.

Maybe there are some others features of sshd you are talking about that I may not know about.

It currently dies when you close the bash instance:


There are ways to hack around that but they're not pretty:


mobaxterm works fine IME

Can it run apps inside Wine? Windows emulating Linux syscalls so that Wine can emulate Windows syscalls.

WINE does not (iirc!) emulate syscalls, it rather provides its own user32.dll and a host of other libraries which then call Linux userland (e.g. DirectX->OpenGL) or syscalls (files, I guess).

I don't have the post on hand, but I know someone around here posted showing that it's possible. We have to go deeper...

This should be really useful for people who are forced to use Windows (e.g. at work). Other than that, I don't think many Linux/Unix enthusiasts are looking forward to running a spyware-ridden closed-source non-Unix operating system.

Reposting a dead comment on this parent, because it's entirely reasonable.

No, I believe they're not really after the enthusiasts. I think they're after the fence sitters. Implementing these tools on Windows removes motivation for casual dissenters from building intertia and leaving their platform. This is of course not the first time Microsoft has done something like this. Historically, step two is where they extend the functionality for Windows only. Let's keep them honest and make sure they don't do that again!

Why is this dead? It even has a name.


The poster has negative karma. They got downvoted on their very first post, so the account is effectively dead unless a mod manually fixes it.

In the future, please vouch for comments you think should be visible to revive it. (link where the "flag" link would be on a non-dead comment)

Vouching privileges shadow revoked :^)

I am a Linux enthusiast. I'd love to run linux as my main OS, however:

1) I also like games

2) I hate dual booting

3) PCI passthrough of GPU to VM was a bit annoying

So WSL is kind of a nice middle of the two worlds. I don't need to run a Linux VM now for development, for example.

No, I believe they're not really after the enthusiasts. I think they're after the fence sitters. Implementing these tools on Windows removes motivation for casual dissenters from building intertia and leaving their platform.

This is of course not the first time Microsoft has done something like this. Historically, step two is where they extend the functionality for Windows only. Let's keep them honest and make sure they don't do that again!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact