Invoke Win32 applications with Bash on Windows | Hacker News Reader

Invoke Win32 applications with Bash on Windows

msdn.microsoft.com

146 pointsjackhammons50 comments

This finally makes bash on windows functional. It was one of its limitations that made it feel disconnected from the rest of Windows.

It also introduces potentially significant new attack surface.

Does it expose any network service by default?

Any more so than, say, using bash and friends via cygwin or similar?

Maybe. Cygwin is old code and sometimes that's better than new code from a security point of view.

No more so than any of the shells that's already available on Windows (batch scripts, WSH, Powershell). If one was to exploit scripting on Windows, it would make more sense to target the existing shells rather than Bash as they're more widespread on Windows.

Plus Bash on Windows isn't a new thing: we already have Cygwin, MinGW and I believe there was also some native Windows PE ports too. This is just a better implementation than the aforementioned three.

Yes, insofar as anything that allows you to do anything with your computer expands the attack surface.

Like nearly everything, it's a context-dependent cost-benefit consideration.

Yes, that's really the missing piece and sounds great. Before that it really felt isolated, like working in a VM. My use-case was to have a full featured bash for invoking some build scripts built still to be able to utilize some windows executables (most imporantly currently docker for windows) in it. Seems like this should do it.

This does sound like it will make it a reasonable choice once it's stable. I currently use Git Bash and it integrates pretty nicely.

I typically install it along with git and Git Extensions. It's great when you already know the bash way of doing something, hashing files for example.

Yes, I also use git bash / msys currently and I'm pretty happy with it. But there were a few cases were it caused problems, e.g. the automatic translation of file names caused some headaches for me (in most cases you want it, but e.g. in docker statements you don't want it). Wanted to try whether WSL can even improve that. The old version was unfortunately too limited, but this update sounds very promising and I will test it again.

Wow, this is really impressive. Last time I worked with bash on Windows it felt like isolated island. But with this. I think it is a viable option right now. The only down side to it is slow file system operations. Compiling a single toy kernel (xv6) would take much longer than Linux.

This is amazing, now I can have emacs server in Linux running through bash with windows service manager.

This is fucking awesome. I hope they improve thing further and further.

The only and biggest problem : Windows ridiculous conemu. I am not going use a console which I can't resize without any problem. For the sake of God they don't have unlimited buffer option and hide scrollbar (permanently) or resize window without messing up text.

> Parameters are passed to the Windows binary unmodified. As an example, the following commands will open C:\temp\foo.txt in notepad.exe:

This might rain on your parade a bit. Each island still has to know about the file sytem of the other island.

Cutting them some slack I think is not bad idea. They are literally integrating two big operating system together. Do you see what I am saying?

As we all know Microsoft messed up with mobile and web, but when it comes to software development they are ruler without even competition. Windows kernel is wonderful peace of software, and with this wsl they are literally showing industry how is software developed.

I will, they've been clear about it being a work in progress.

There are a lot of other people saying how amazing it is though, when functionality wise it's only just coming up to par with cygwin.

Edit - functionality wise as a usable bash shell, it's an acceptable linux virtual machine already.

It is not a virtual machine and doesn't involve Linux in any way. It is an implementation of the Linux syscalls for the Windows kernel.

Why does this trigger so many people?

Why is “trigger” used jokingly now? Unless you think the people responding have PTSD or a similar condition.

Because self diagnosed PTSD sufferers on Tumblr made a mockery of it.

The word has uses outside of the PTSD context though, like gun or database triggers.

> Because self diagnosed PTSD sufferers on Tumblr made a mockery of it.

Why would them being self-diagnosed matter? Why would you react to it having been “made a mockery of” by reinforcing this supposed mockery? It only makes it worse for people who have to deal with it.

> Why would them being self-diagnosed matter?

Because the self diagnosis is largely made up by people who don't understand what PTSD even is. It's like someone declaring they have cancer without going to a doctor.

> Why would you react to it having been “made a mockery of” by reinforcing this supposed mockery?

Because it's become part of the lexicon now. I don't think there's any going back. My usage was the "new" usage, no relation to PTSD was intended.

https://www.xkcd.com/386/

I have to agree... I'm still using the bash that comes with git for windows. It actually works (mostly) as one would expect it to work.

Also, not being able to edit the WSL filesystem from inside a windows editor is a huge loss in terms of usage. It's worse than using Samba/CIFS to share a directory and edit across to a full VM. I happen to like my gui editor, but prefer to run in Linux.

If you had to you can touch things in the WSL VolFS by browsing the appropriate %AppData% subfolder. I'm presuming Microsoft isn't encouraging that right now with this Interop tooling for several reasons.

At a guess one of them might be that apparently the Unix things like permissions and Unix-style metadata are stored in NTFS alternate streams (~"resource forks") that they may be worried some Windows programs might not handle quite right (ie, accidentally mangle/remove/destroy).

It actually doesn't work right, and MS just closed the issue. I'd be fine with cifs automounts in the linux subsystem for windows file directories... I mean it may take a little work, but in the end, I want to edit files with a windows gui editor, and run them via the LSW applications. Until I can do that, it's an also ran on the desktop... and until it can be used for docker with linux containers on the server, it doesn't do much use there either.

Why can't you keep the shared files that you want to GUI edit somewhere under /mnt/?/* in a normal NTFS folder? That works fine already today.

I'm using Bash on Ubuntu on Windows for Jekyll (because installing and keeping up to date Ruby on Windows is a terrible experience and this is a much nicer alternative). My files are in D:\Repos\..., I'll have VSCode open and Jekyll running in Bash in the equivalent /mnt/d/Repos/...

Actually,what does an emacs server running in wsl get you rather than just running the standard win32 build?

Emacs on win32 dosnt support daemon mode.

You should upgrade. Emacs 25.1 supports daemon mode in Windows.

So cool. I should really really think you. Wasn't aware of that.

> "Windows ridiculous conemu. I am not going use a console which I can't resize without any problem."

Sorry I don't follow. What resizing problems are you having with ConEmu? Works fine when I've tried it. We are talking about the same ConEmu, right?

http://conemu.github.io/en/

http://conemu.github.io/en/ResizeAndMove.html

The way they phrased it suggests they were referring to the default Windows NT terminal emulator, rather than Conemu.

I would agree with you, but that'd be the first time I've ever heard that called ConEmu. It's much more likely to be called the Windows command shell, Windows command prompt or cmd. As you're clearly already aware, ConEmu is a specific product that provides an enhanced command line experience on Windows.

FWIW, `cmd.exe` is both, the shell and the console. It is not a terminal (not designed to be operated remotely) nor is it emulating a terminal of any kind.

As for the parent poster, they must be abusing the term `ConEmu`, a completely separate console program that can run win32 programs (including `cmd.exe`).

If it helps futher square some of the linguistics digressions the parts of cmd.exe that are the console emulator are typically referred to as the ConHost. The ConHost's console emulation is indeed not quite as great a lot of people would like, which is why many Windows users use a different console emulator named ConEmu. Obviously abbreviating the ability of ConHost's console emulation to conemu rather than spell out "console emulation" causes confusion with the ConEmu tool for Windows.

Cmd.exe is just the shell. The console window is handled by conhost, as are any terminal emulation things.

So sorry about late answer. I meant Windows default console emulator. I forgot what they call it exactly.

Ah, fair enough.

I've actually been running an instance of VcXsrv and then running something similar to `bash -c "DISPLAY=:0.0 terminator` to run that under the X session. Way better than the CMD emulator

There's a lot more technical information in this post (scroll below the video for diagrams and writeup): https://blogs.msdn.microsoft.com/wsl/2016/10/19/windows-and-...

Now they just need a better terminal emulator. Windows 10 made some minor but much needed adjustment, but I still end up using Cmdr (a nicely preconfigured ConEmu), and it's decent enough, but it pales over a nicely configured iTerm2 or what most popular Linux distros come with out of the box.

I second this. Someone porting iTerm2 to Windows would make my day.

We're not on Windows 10 yet at my workplace, and I don't use Windows at home, so I've only been following loosely in a "this will be nice once I'm finally able to use it" way. But this bit took me by surprise:

> 1 Use the same working directory as the CMD or PowerShell prompt > 2 Are run under as the WSL default user > 3 Have the same Windows administrative rights as the calling process and terminal

1 and 3 are not surprising. But 2? There's a WSL default user? Windows users aren't automatically mapped to unique Linux users? That seems problematic in theory. How does it work out in practice?

Every Windows user get a separate Linux.

When they run bash for the first time, system asks them to create a default linux user. Typically, this is also the only user.

Mapping Linux users to Windows users would be quite problematic, e. g. with user such as nobody or apache that are typical to Linux.

Solved problem, see Samba

It seems to work pretty well in practice. The entire Ubuntu "system" is essentially installed into a Windows User's home space, which means that all of the Linux users are unique to a Windows user. This is useful in that you can install things that need Linux accounts for services (like say postgresql that uses a postgres user as a service account) and interact with it with sudo -u just as you would on an ordinary Ubuntu machine. With the interesting bit that the postgres user under my Windows user login would be different from the one under a different Windows user on the same machine, but that also has some advantages.

Thanks. That is a helpful explanation.

If there's ever been a great opportunity to open source something in the Windows client, it's WSL. A number of popular User Voice feature requests were closed recently as not in scope, which is reasonable on the part of the WSL team but shows that the demand for Linux-on-Windows is much greater than the team's current objectives. If the project was open source and the team accepted patches who knows where this thing could go. People want to run X, they want device emulation, they want to run all kinds of apps that aren't necessarily dev tools.

Oh, that's nice. That's what I was looking for in the first place.

As I'm reading the comments I keep seeing things that other people want to do that I never thought of...that's awesome.

I'm guessing this solves:

https://news.ycombinator.com/item?id=12715945

Embrace, extend and invoke? ;)

Reply on news.ycombinator.com