Introducing the Windows Pseudo Console (ConPty)

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?

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.

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.

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?)

Anyways, this is fantastic. Finally, proper ssh functionality!

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.

[0] https://github.com/stedolan/jq (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.

This is so un-Windows-like.

I've been waiting for two decades to revise this particular Frequently Given Answer.

* http://jdebp.info./FGA/capture-console-win32.html

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.

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.

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.

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.

Finally! I've been waiting ten years or so for this API. It's about time that alternative terminal emulation becomes possible on Windows.

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?