Windows Subsystem for Linux out of Beta!

We're excited to announce that in Windows 10 Fall Creators Update (FCU) due to ship in fall 2017, Windows Subsystem for Linux (WSL) will no longer be a beta feature and will become a fully supported Windows feature. Early adopters on the Windows Insider program will notice that WSL is no longer marked as a beta feature as of Insider build 16251.

This will be great news for those who've held-back from employing WSL as a mainline toolset: You'll now be able to leverage WSL as a day-to-day developer toolset, and become ever more productive when building, testing, deploying, and managing your apps and systems on Windows 10.

So, what changes?

Very little! In fact, the only change most will notice, is that the "Windows Features" will no longer indicate that WSL is a beta feature!

What will change is that you will gain the added advantage of being able to file issues on WSL and its Windows tooling via our normal support mechanisms if you want/need to follow a more formal issue resolution process. You can also provide feedback via Windows 10 Feedback Hub app, which delivers feedback directly to the team.

We'll still do our best to remain as responsive as ever to the bugs and issues you post to the WSL issues GitHub repo and we'll remain just as engaged, seeking and responding to your questions, etc., on Twitter and will continue monitor and contribute to discussions and answer questions on forums and sites like Stack Overflow, Ask Ubuntu, Reddit and others.

So, do continue to let us know if you run into issues, and/or have questions, and we'll continue to improve WSL to support our key scenarios.

Caveat Emptor

Of course, we'd be remiss if we didn't take a moment to remind ourselves of our key WSL scenarios:

Run Linux Command-line tools for development and (basic) administration

Linux distro's running atop WSL are for interactive user scenarios, NOT for running production workloads on Apache/nginx/MySQL/MongoDB/etc.

Linux files are NOT accessible from Windows (we're working to improve this scenario over time)

NO current plans to support X/GUI apps, desktops, servers, etc. at this time

Support & Issues

With the removal of the beta tag, it's also important to note who is responsible for supporting & fixing what part of the system:

Microsoft supports the WSL infrastructure and tooling

Distro-publishers are responsible for their distro internals

Microsoft and our awesome distro publisher partners maintain an open channel and partner-up to diagnose issues to their root cause, wherever that may be, and to schedule & deliver fixes when feasible.

If you do find something that doesn't work as you'd expect it to, or you have identified a reproducible issue, please continue to file feedback on our GitHub Issues repo, following the contribution guidelines and completing the new issue template as fully as possible. This process has proven to be a highly effective way for the WSL team, our distro partners, and our fanstastic community to directly engage & drive issues to resolution quickly and efficiently.

Key Takeaway

The removal of the beta tag will result in a continued improvement in product quality over time, and demonstrates our continued commitment to making Windows a great platform upon which to run your Linux tools. We look forward to hearing & learning more from you about what works, what doesn't, what features you'd like to see, and how WSL helps you achieve more.

We’re excited to announce that in Windows 10 Fall Creators Update (FCU) due to ship in fall 2017, Windows Subsystem for Linux (WSL) will no longer be a beta feature and will become a fully supported Windows feature. Early adopters on the Windows Insider program will notice that WSL is no longer marked as a beta feature as of Insider build 16251.

WSL prevents the need to port packages since it’s enables one to directly run unmodified Linux binaries. Cygwin/MSYS, on the other hand, ports a subset of the GNU toolset to Win32 for direct use within Windows environments. Each has their pro’s and con’s.

It’s sad that you’re avoiding the use of the name GNU. It’s clear that you want to provide users with a GNU environment, but that Microsoft is uncomfortable with the philosophy of the GNU project and thus avoids mentioning it by its proper name.

I fully agree with the name of the subsystem. But there are many references to the environment running inside of it as well. This is consistently a GNU environment. (I haven’t seen anything about supporting non-GNU environments.)

Above it is even referred to as ‘Linux’, when there is no Linux code running at all, and I have seen references to it as just running “Bash”, which is apparently a more convenient name for Microsoft to reiterate than GNU.

Containers/Dockers/VM’s all have a part to play, but tend to offer a more “isolated runtime environment” than WSL … and this is specifically by-design: WSL is about providing Linux tooling alongside Windows tooling, sharing access to the same network and filesystem, to increase developers’ productivity & efficiency.

If you want to run tools & share access to files on the host machine, WSL is a great fit. If you want to deploy systems to a server/farm/cloud, containers and/or VM’s are a better bet.

Great news. Thanks for the documentation too – it would be very difficult to keep up with news about changes done by WSL upstream (since I can not check regularly, so I have to check sporadically at best; the blog series provide an entry point for me to keep updated, even tough I do sometimes read github issue trackers – useful information can be found in some of them as well).

Where does it “end”? Good question. Not sure it’ll ever end since Linux tooling & the community of those building apps and tools that primarily target *NIX continue to evolve and improve over time.

Our goal, however, as often stated, is to allow developers, IT Pros, devops engineers, etc. to run *NIX tooling alongside Windows apps and tools. We do not intend to replace/extinguish/eradicate/harm Linux. In fact, we expect to increase access & exposure to *NIX tools to millions of Windows developers who currently can’t employ *NIX tools in their current workflows.

So now with Microsoft taking all that open-source Linux-Code – don’t you think it is time for MS to release the Win32-Systsystem + Userspace components? The Wine guys would be more than happy I guess 😉

WSL contains no Linux kernel source code – it’s a clean-room implementation of the Linux SCI, utilizing pre-existing features of the Windows kernel, with a little additional new infrastructure to allow WSL to mimic Linux-kernel-specific behaviors.

Note: Linux itself was an open-source re-implementation of the UNIX/POSIX SCI.

“Linux files are NOT accessible from Windows (we’re working to improve this scenario over time)”

So I am going to assume that this is a driver setup that you are working with? To at least read(and with some hope, write to) Linux partitions and/or the file system?

That would be very, very useful for me. The current driver that I am using… is sub par and the development of it has stalled. Ext2fsd, if I remember. I would honestly welcome a Microsoft based solution at this point, assuming that it doesn’t do much to harm the partition and the data in the file system. I know that the licensing of the Ext file system is going to be rather annoying (it is GPL, if I remember), but please… I need something that is more sane.

If you can talk to anything that it going on with that? I would greatly appreciate it.

I’ve been using Bash on Windows for quite some time. Its really helpful to use bash and GNU compilers on windows. I appreciate introduction of SUSE and OpenSUSE flavor. Will they be available in FCU release?

The problem with offline installation is that if you copy the distro APPX locally, you’ll end up missing out on updates etc. so you could well end up spending more time in apt update/upgrade than downloading and installing the latest 200MB APPX when you need it.

Rich is there a way to call Linux .so functions from either a Win10 app or Win10 DLL ? If a traditional function call mechanism is not available, is there another way to communicate between DLLs and .so’s ? Sockets or other IPC method ? Thanks.

No, there’s no direct way for Win32 code to invoke .so’s. However, you could host an command/app/daemon in Linux which listens for a socket/pipe/HTTP request, call the necessary .so, and return results.

Does WSL provide means to read ext partitions?
Is the tool dd supported?
Is it possible to catastrophically run “$ sudo rm -rf /” from WSL?
If you can write GUI based programs for GNU/Linux from within Visual Studio 2017, how can you even debug it without having to switch between machines/OS instances?

Not at this time. WSL relies on the NT filesystem stack which doesn’t support EXT by default. There are some EXT filesystem drivers in existence and you may have luck with them, but we’ve not tested any and you do so at your own risk 😉

Your Linux processes run with the permissions of the logged-in user, even when sudoed. Thus, you can cause the same amount of damage by running `rm -rf /` as you could by running `del c:\ /s` from Cmd or `rm -recurse -force c:\` in PowerShell. If you run the same from elevated command prompts, you can do even more damage. I’d generally recommend against doing this.

To test GUI apps, we recommend deploying into a Linux desktop VM running in Hyper-V etc. While you CAN get some X apps to run in WSL, you may experience more issues than using a VM because we only support command-line apps in WSL.

Think of it this way: To exploit the ‘bashware’ vulnerability, you first have to gain admin rights to the target machine. At this point it’s game-over anyhow. With admin rights, the attacker can access all your data, all your files, all your network connections, etc.

Worrying about someone enabling WSL, rebooting your box, re-establishing another admin session after the reboot, installing a distro, installing WINE, and then installing some malware is a highly contrived and highly unlikely attack vector. Various malware vendors are already in the process of enhancing their products to protect against these and other potential vectors.

Sorry, no – WSL is not a stand-alone module – it’s deeply integrated into the internals of the NT kernel, and depends on many of the features of other areas, inc. the filesystem, networking, IO, memory management, process scheduling, etc.

WSL files are accessible from windows, but on very long directory paths (in the non-beta) version.
It is unwise to access them from outside WSL because only WSL is aware of things like Linux permissions.
Instead, copy any files to or from a subdirectory of /mnt/c by using commands within the WSL shell.

And please read the comments posted throughout by WSL Team members updating y’all on progress, culminating with my post this morning pointing out that the fix is on its way to Insiders and is being back-ported to Fall Creators Update.