Does this mean that it will now be easy to port terminator to windows?
Introducing the Windows Pseudo Console (ConPty)
21–30 of 196 posts
Re: Introducing the Windows Pseudo Console (ConPty)
#22Hey 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 i…
Can conhost still do anything that users of the new API can't?
Re: Introducing the Windows Pseudo Console (ConPty)
#23Earlier quoted context omitted.
Zadji I love your work. Which build is this going to land in? Do you know if any of the third party console apps using the new API yet?
It's already available in current insider's builds, and will be landing officially in the next available Windows release some time later this year. We're still working with ConEmu, VsCode, and OpenSSH to get them all over to the new API, with varying levels of adoption in the next few months likely. Currently, WSL is also using the same functionality, if you open a WSL distro and run any Windows executables (eg `cmd.…
You might want to talk to the Cygwin people to get their pty layer to use the new virtual console.
Re: Introducing the Windows Pseudo Console (ConPty)
#24Earlier quoted context omitted.
While it is nice that MS is focusing on console and command line now, it seems to me that you are mostly working on improving compatibility with legacy UNIXy stuff. Do you have some vision or plans to go well beyond the classic UNIXy style of console and command line? I'm thinking in the lines of projects like DomTerm http://domterm.org/ which could have nice interactions with e.g. PowerShell.
The ConPTY is not just about compatibility with nix. It's about proper remoting of consoles. Unix got that right / Windows got that wrong, and now Windows will finally get it right too -- that it helps nix compat seems like a happy accident (though obviously they want that too, so not so accidental.
Right. For a long time, the MS remoting philosophy was that applications should be remoted, not text streams. The stance goes all the way back to DCOM. That's why PowerShell remoting looks more like a local PowerShell executing commands on a remote machine than it looks like you just connecting to a PowerShell running elsewhere.
The difference is important, since in the traditional MS model, each program that wants to do the remote thing needs to essentially implement its own client-server setup, albeit with a massive amount of help from various runtimes. Named pipes and central authentication made this approach not quite as horrible as it sounds.
This new API is a departure from this model. It will make it possible to just remote via text streams. Perhaps that's uglier --- everyone knows in-band signaling is fragile. But long experience shows they just remoting the damn text streams is easily the more pragmatic option.
Re: Introducing the Windows Pseudo Console (ConPty)
#25Earlier quoted context omitted.
Will this replace Command Prompt or Powershell? Or is this more the back-end for these apps? I believe that we are heading for console overload (in a good way?!) with Command Prompt and Powershell installed on every computer and Debian/Ubuntu available on the MS store.
First off: command prompt (cmd.exe) and powershell are commandline client applications. They are shells just the same as bash is. All commandline clients run attached to a console server, and that server is conhost.exe. Conhost is responsible not only for being the console server, but drawing the actual terminal window these apps run in. So when you alunch cmd or powershell, what you're seeing is conhost.exe "hosting…
Is there any chance cmd and powershell will improve from a user interface perspective? And perhaps become usable? Cmd has been garbage since it's inception.
Re: Introducing the Windows Pseudo Console (ConPty)
#26What 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/stedola…
The lack of signals in Windows is the very opposite of a flaw! - Windows has just never pretended you can get away without a message loop.
Re: Introducing the Windows Pseudo Console (ConPty)
#27Something looks very eerie in that Admiral Grace Hopper picture. Is it shopped?
Re: Introducing the Windows Pseudo Console (ConPty)
#28Hey 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 i…
Can conhost still do anything that users of the new API can't?
Excellent question! There are a few limitations that we have to place on the ConPty to make it work quite right. Primarily, client apps running attached to the conpty will not be able to have separate viewport and buffer sizes. On *nix, the entire "console buffer" is just the size of the window, but on Windows, technically, the buffer is much larger than the window. (as an example, when you open up a command prompt, there's a giant empty space at the bottom if you scroll down). Fortunately, we haven't came across any apps that _need_ the buffer to be a different size than the viewport, and it's a technically valid console configuration, so apps should have been able to support it before.
Input is also tricky - VT doesn't let you express input with as much fidelity as a console app might be expecting, though this we're working on a solution for :)
Re: Introducing the Windows Pseudo Console (ConPty)
#29Earlier quoted context omitted.
First off: command prompt (cmd.exe) and powershell are commandline client applications. They are shells just the same as bash is. All commandline clients run attached to a console server, and that server is conhost.exe. Conhost is responsible not only for being the console server, but drawing the actual terminal window these apps run in. So when you alunch cmd or powershell, what you're seeing is conhost.exe "hosting…
Is there any chance cmd and powershell will improve from a user interface perspective? And perhaps become usable? Cmd has been garbage since it's inception.
cmd is parked for pretty much everything except for major issues. It's a scary codebase that has a LOT of code that's dependent on it, and we can't really add any new features there without the possibility of breaking someone.
This feature is mostly focused on the other end of the communication, on being able to create new Terminal windows to run shells inside of them.
Re: Introducing the Windows Pseudo Console (ConPty)
#30Earlier quoted context omitted.
It's already available in current insider's builds, and will be landing officially in the next available Windows release some time later this year. We're still working with ConEmu, VsCode, and OpenSSH to get them all over to the new API, with varying levels of adoption in the next few months likely. Currently, WSL is also using the same functionality, if you open a WSL distro and run any Windows executables (eg `cmd.…
You might want to talk to the Cygwin people to get their pty layer to use the new virtual console.
That is an excellent suggestion, I'll get our PM to reach out :)