This is pretty huge. For as long as I can remember the response to command line applications talking to command line applications was "Why would you want to do that? Use (RPC | shared memory | some other IPC mechanism)." And nobody at Microsoft seemed to understand how much simpler it was to use ptys. They seem to have completely capitulated to the notion ptys and are dropping them into the next release of W10. I wish this had happened 10 years ago but hey, I'll take it.
Will there be a terminfo database entry for ConPty? What TERM string should we expect to see?<p>To elaborate: although an ordinary POSIX pty doesn't inherently have a terminal type - that's entirely down to whatever emulator is connected to the master side - the way the ConPty system translates Console API calls into terminal control codes means that it necessarily needs to pick a terminal emulation, which all actors in the ConPty system are expected to use.<p>A terminfo database entry would be useful both for applications running on *NIX hosts but displaying on a remote ConPty master somewhere, as well as for porting existing terminal applications to Windows where they will run on a ConPty slave.<p>As a follow-up question, presumably this means that the SSHD running on Windows as a ConPty master needs to translate between whatever terminal emulation the ssh client is connected to and the one expected by ConPty / ConPty apps (in the same way it must translate between the native ConPty UTF-8 and the remote charset)?
What next? Job control signals?? :) (EDIT: How about tmux?)<p>Anyways, this is fantastic. Finally, proper ssh functionality!<p>This will encourage development of console (text-oriented) apps for Windows, which I hope will be much simpler. Interfacing with the console can be really difficult if you're coming from *nix. Ideally all the WIN32-specific code in, e.g., jq[0], could be ripped out.<p>[0] <a href="https://github.com/stedolan/jq" rel="nofollow">https://github.com/stedolan/jq</a> (look in src/main.c)
For me, the most surprising thing is that the new PTY devices use UTF-8. Not UTF-16 or UCS-2 or weird little endian variants thereof, and not even wchar_t.<p>This is so un-Windows-like.
I've been waiting for two decades to revise this particular Frequently Given Answer.<p>* <a href="http://jdebp.info./FGA/capture-console-win32.html" rel="nofollow">http://jdebp.info./FGA/capture-console-win32.html</a>
Hey I'm one of the Console devs who's been working on this feature for a while now. I'll be hanging around in the comments for a little while to try and answer any questions that people might have.<p>TL;DR of this announcement: We've added a new pseudoconsole feature to the Windows Console that will the people create "Terminal" applications on Windows very similarly to how they work on *nix. Terminals will be able to interact with the conpty using only a stream of characters, while commandline applications will be able to keep using the entire console API surface as they always have.
While we're talking Unixisms, Windows needs a dup2(2). That is, given a HANDLE, you should be able to swap out its backing kernel data structure with that of another HANDLE.<p>Without this, I/O redirection is slightly broken. Last I checked you can't change where stderr goes after the process starts, for example. [SetStdHandle doesn't do it at the right layer.]
I always liked the Console API where you can set the color of the text without actually changing the text that is written to Stdout. No issues when piping the output somewhere else. No need to check whether the output is getting piped.
If I use the System.Process API in .NET and redirect the Stdin/Stdout to a stream inside my application, does the framework spawn an invisible console and scrape the output? Or does this work differently? I always did it that way and thought the 3rd party terminal emulators also do that. Why do these emulators have to do it differently?
Wow. I remember the photo miniksa posted to GitHub when this was in process:<p><a href="https://github.com/Microsoft/WSL/issues/111#issuecomment-238592841" rel="nofollow">https://github.com/Microsoft/WSL/issues/111#issuecomment-238...</a><p><i>Awesome</i> to see it's finally up and running! \o/
I currently use ConEmu + zsh via MSYS2 as my preferred shell on Windows. I need to run many interactive programs like `python`, `node` etc. via winpty, e.g.:<p>```
alias node='winpty node.cmd'
```<p>With the new ConPTY, will I be able to run native Windows programs directly? If so, that would be huge, winpty (while I'm really thankful it exists) is a PITA in practice, see e.g. <a href="https://github.com/Microsoft/vscode/issues/45693" rel="nofollow">https://github.com/Microsoft/vscode/issues/45693</a>.
Is there any way to get this backported to Windows 7 - or run a W7 userland on top of a W10 kernel? I'm actually serious about this one, I can't stand this semi-"mobile-first", flat UI of newer Windows generations, and the privacy invasions and ads are other hard blockers for me - but that WSL layer or the new console subsystem seem to be pretty nice features.
<p><pre><code> HRESULT WINAPI ResizePseudoConsole(_In_ HPCON hPC, _In_ COORD size);
</code></pre>
If Microsoft is in the mood to fix old problems, right ^there you've got another old problem: its bizarre API that is different to everything else. Designed that way to lock everyone into their OS.<p>In 2018 nobody has the time to learn this. Just use a cross-platform API and if it doesn't run on Windows then just don't run Windows.<p>As a developer, using Windows for development is against your own best interest. If you like to be treated as a dog that is not allowed inside the house, use Windows.