In order to make a native SSH server, Windows need pseudoconsoles (analogous to pseudoterminals in POSIXland). That is, it must be possible for a random program to create a handle that supports operations like SetConsoleCursorPosition without having to call AllocConsole. Calling AllocConsole is a problem because there's no way to monitor what programs are doing with that console except scraping it. (The accessibility hooks are insufficient because if you try to access the console from inside them, you deadlock, and if you queue an access request for later, you race.)

Since consoles are real kernel objects since Windows 8 and talk to conhost over IPC anyway, this feature is eminently doable. It's been my top feature requests for years. Nobody's gotten around to it.

Pseudoconsoles would be a bit more complicated than POSIX pseudoterminals because Windows consoles have more features, but the basic concept would transplant beautifully. It'd also make Cygwin a lot better.

I miss working on operating systems.

This!!!! One of the biggest things I really miss in Windows-land is SSH. Just today I had to create a SSH tunnel for SQL Server. While it's not a big issue with third party tools, it should just be built and ready for use as with every Linux distro, FreeBSD, Solaris and OSX.

While they are at it, they could create a posix compatible layer for Windows. That would really drive some conversion.

edit: after rereading my comment and seeing the downvotes, just to clarify, it was a serious, not negative suggestion. :)

There used to be Windows Services for UNIX (a.k.a. Subsystem for UNIX-based Applications):

http://en.wikipedia.org/wiki/Windows_Services_for_UNIX

https://technet.microsoft.com/en-us/library/cc771470.aspx

They ditched in Windows Server 2012.

Now recommend cygwin.

"The Subsystem for UNIX-based Applications (SUA) is deprecated. If you use the SUA POSIX subsystem with this release, use Hyper-V to virtualize the server. If you use the tools provided by SUA, switch to Cygwin's POSIX emulation, or use either mingw-w64 (available from Sourceforge.net) or MinGW (available from MinGW.org) for doing a native port. " https://technet.microsoft.com/en-us/library/hh831568.aspx

msys2 is a lot better than mingw+msys and cygwin, in my opinion. I switched months ago and its been a lot easier to deal with.

They've done that before and, as far as I know, it was not an extremely popular product.

It was not an extremely functional product. It was largely there to get government contracts where one of the requirements was POSIX conformance, even if they weren't using it.

Imagining they had first-class support for it (a major undertaking, I'd guess, but anyway) how many people would use it? I'd guess it'd be about the same people who use Cygwin now.

Why would you guess that? Because cygwin is nothing close to first class support. It has a lot of friction associated with its use. You're better off just running linux in a vm if you want posix on windows, and trust me plenty of people do that these days.

Anyone porting applications from Linux would be able to use it to reduce the effort.

Yes, but I think Microsoft's ultimate concern is how many people will want to use such applications. How many will? Think about how few people run, say, PHP applications under Windows. Even though it's possible. (Well, actually, often it won't work right because PHP developers don't bother to test with anything besides Linux)

I think with Azure, you can log into your Azure instance and then send commands. I recently tried to set up automated deployments for our non-Azure infrastructure and investigated bringing things to Azure.

It's not the same as SSH, but then again powershell is not the same as linux shells.