It's a subsystem for running Linux binaries, unaltered, on top of the Windows NT kernel. There has been no mention of additional Windows NT filesystem drivers, anywhere.
It seems weird to me that conhost.exe handles how console commands are displayed. I've read where some 3rd party attempts to improve the terminal experience on Windows have done so by essentially scraping what conhost outputs and then using the data to display output themselves.
Am I wrong about this? I have never worked on terminals so I very well could be, but my expectation would be that terminals call into shell APIs which return a result that the terminal can then display however it wishes. If so, then I think the next natural step would be for Windows to decouple conhost's responsibilities.
This isn't as necessary as it used to be: conhost.exe got a major overhaul in Windows 10 and it sucks a lot less now. There's wrapped selection, copy/paste, and transparency (if you're into that). There's plenty more to go but overall the experience is no longer pull-your-hair-out agony, and Microsoft did say (without providing any specifics) that more improvements were on the way and that they are still soliciting feedback and feature suggestions. You could propose changing the way commands are displayed if you wanted.
From what I understand, it used to run at way too low a level in the kernel for some reason, so third parties couldn't touch it. This was fixed in Win10 so alternative shells are now possible.
"while you’ll be able to run native Bash and many Linux command-line tools on Windows, it’s important to note that this is a developer toolset to help you write and build all your code for all your scenarios and platforms.
This is not a server platform upon which you will host websites, run server infrastructure, etc"
No, they demonstrated developing and testing a Ruby application on Windows via the Linux sub-system, then deploying it to Azure (using ssh, mina and git).
Important distinction - they're building support for developing Linux-based web applications into Windows, not hosting websites.
Unlikely msys can handle the DOS/POSIX EOL conversion. Which is something I totally take for granted and is gonna be really annoying to deal with in Windows once BASH support is added.
Where does it say this can't? I understood the opposite:
...we decided to grow our command line family by adding real, native Bash and with it support for Linux command-line tools which run directly on Windows in an environment that behaves like Linux!"
edit:
note that Bash and Linux tools cannot interact with Windows applications and tools, and vice-versa. So you won’t be able to run Notepad from Bash, or run Ruby in Bash from PowerShell.
I think it won't be able to run windows program, at least at first, and the reason is probably mainly technical: detecting fork/exec pairs of calls where it should be possible to spawn a PE is non-trivial, especially since you mainly aim at standard Linux syscall compat with unmodified pre-existing GNU/Ubuntu userspace (and Linux does not even uses fork() but clone() as a syscall -- which makes the issue even more difficult to handle).
Now as for what it could be useful for, I guess a lot of people will reclaim a solution to be able to run windows program from that environment, because one of the scenario is build-systems and leaving that to a separated environment would be too bad. At least I will. In the meantime, maybe we will be able to cope with ssh.
Now back to technical stuff, I think the best way to allow execution of windows program from that environment would be a small custom program that uses a special syscall and to spawn a windows process. The end result would not be transparent (you would have to launch let's say "windows cl" instead of "cl" from the Linux env, but this is an extremely small price to pay, since: build-system already often can prepend things to command lines, for example to use ccache, we can actually implement this solution without even needing syscall support but instead TCP/IP (and maybe ssh) and switch to an accelerated para-syscallized solution when it is available -- but then the classical problem of inheriting the environment will reappear (env var to translate with heuristics, etc...)
So maybe MS thought about all that and decided they will "never" do it (until they change their mind in 10 years), and we actually should just stick to MSYS for that kind of stuff? Would be a little sad, but it's not like we are without an existing working solution.
Well, MSYS/MSYS2 lets do that today. It would just be more elegant to use native unported Linux binaries from an existing repository (which probably has more tools available too), but even with the low level syscall thing being solved, the other stuff MSYS fixes will reappear (mainly problems about path and environment translation, which is crucially important in build-sys). So we can guess it is at least not for the first version...
Edit: reading your comment again, maybe you will be happy with building your windows exe with a MinGW cross compiler fully running under the Linux subsystem under Windows. That covers some needs, but not all. For example I really need to be able to e.g. launch cl from there with standard Makefiles and GNU Make.
There are probably still enough companies out there which are using Windows 7 as their standard installation. And as long as that's the case msys(git) would still be needed.
Posix on Windows! Yay! Together with the open sourcing of DotNet (that now enjoys an MIT license), this new Microsoft stance is looking more and more compelling. Comparing MS policies that to the rather hostile licensing/litigation policies of Java/Oracle makes me reevaluate.
I wonder if PG will update his "Microsoft is dead" prediction. Nadella seems to have resurrected Microsoft. I can't imagine them doing this under Ballmer or Gates.
He might modify it to be "Windows is dead." Microsoft has moved on the focusing on the cloud (unsurprising with Nadella). Windows is only ~10% of total revenue.
This is a nice move, but if you think this changes the "Microsoft is dead" statement (not prediction) then you don't appreciate what Microsoft was as compared to what Microsoft is today.
In the 1990s, Microsoft was in many tech markets the default winner, with such powerful monopoly influence that large classes of startup idea would not even make sense to consider because Microsoft was just so well set up to kill any threats to their dominance. And quite willing to do so.
This is a level of dominance and ferocity that has not been attained by other tech companies since. Companies like Apple, Google, and Facebook have pretty strong dominance powered by their lead in product quality, engineering talent, and brand/network effects, but it doesn't strike fear into people the way Microsoft once did. Plus, there is some balance of power among them.
Microsoft now is a participant in this power dynamic. They play in the normal way, by trying to make good products and attract developers and users to their platform. In the 1990s, this would have seemed a pathetic weakness. That Microsoft is still dead.
"Third, note that Bash and Linux tools cannot interact with Windows applications and tools, and vice-versa. So you won’t be able to run Notepad from Bash, or run Ruby in Bash from PowerShell."
It is not in the current Preview Build; they have said it's coming soon but did not give specifics. Preview builds are pretty fast-paced now (about once a week) so I suspect it won't be long.
48 comments
[ 2.8 ms ] story [ 103 ms ] threadOr Microsoft won't dare to hurt their FAT-LFN & exFAT cash cows and make that "uh-oh developers only" feature? ;)
Am I wrong about this? I have never worked on terminals so I very well could be, but my expectation would be that terminals call into shell APIs which return a result that the terminal can then display however it wishes. If so, then I think the next natural step would be for Windows to decouple conhost's responsibilities.
This is not a server platform upon which you will host websites, run server infrastructure, etc"
Yet they demo'd a website being hosted via the Linux sub-system -_- thanks microsoft!
Important distinction - they're building support for developing Linux-based web applications into Windows, not hosting websites.
Right now on Windows I use Git Shell which works great but is based on mintty. Will be nice to be something close to native.
It uses pacman from Arch Linux as its package manager and it contains many libs in addition to just the compilers (and the unixy tools)
...we decided to grow our command line family by adding real, native Bash and with it support for Linux command-line tools which run directly on Windows in an environment that behaves like Linux!"
edit:
note that Bash and Linux tools cannot interact with Windows applications and tools, and vice-versa. So you won’t be able to run Notepad from Bash, or run Ruby in Bash from PowerShell.
So, which is it?
Now as for what it could be useful for, I guess a lot of people will reclaim a solution to be able to run windows program from that environment, because one of the scenario is build-systems and leaving that to a separated environment would be too bad. At least I will. In the meantime, maybe we will be able to cope with ssh.
Now back to technical stuff, I think the best way to allow execution of windows program from that environment would be a small custom program that uses a special syscall and to spawn a windows process. The end result would not be transparent (you would have to launch let's say "windows cl" instead of "cl" from the Linux env, but this is an extremely small price to pay, since: build-system already often can prepend things to command lines, for example to use ccache, we can actually implement this solution without even needing syscall support but instead TCP/IP (and maybe ssh) and switch to an accelerated para-syscallized solution when it is available -- but then the classical problem of inheriting the environment will reappear (env var to translate with heuristics, etc...)
So maybe MS thought about all that and decided they will "never" do it (until they change their mind in 10 years), and we actually should just stick to MSYS for that kind of stuff? Would be a little sad, but it's not like we are without an existing working solution.
Edit: reading your comment again, maybe you will be happy with building your windows exe with a MinGW cross compiler fully running under the Linux subsystem under Windows. That covers some needs, but not all. For example I really need to be able to e.g. launch cl from there with standard Makefiles and GNU Make.
https://en.wikipedia.org/wiki/Microsoft_POSIX_subsystem
https://en.wikipedia.org/wiki/Windows_Services_for_UNIX
This story has deeper analysis: http://www.computerworld.com/article/3041378/microsoft-windo...
In the 1990s, Microsoft was in many tech markets the default winner, with such powerful monopoly influence that large classes of startup idea would not even make sense to consider because Microsoft was just so well set up to kill any threats to their dominance. And quite willing to do so.
This is a level of dominance and ferocity that has not been attained by other tech companies since. Companies like Apple, Google, and Facebook have pretty strong dominance powered by their lead in product quality, engineering talent, and brand/network effects, but it doesn't strike fear into people the way Microsoft once did. Plus, there is some balance of power among them.
Microsoft now is a participant in this power dynamic. They play in the normal way, by trying to make good products and attract developers and users to their platform. In the 1990s, this would have seemed a pathetic weakness. That Microsoft is still dead.
[1] http://www.hanselman.com/blog/DevelopersCanRunBashShellAndUs...