Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introducing the Windows Pseudo Console (ConPty)

blogs.msdn.microsoft.com

Post reply on HN
Print view View original

41–50 of 196 posts

Re: Introducing the Windows Pseudo Console (ConPty)

#41

Post by quotemstr »

tom_ wrote: post #26
cryptonector wrote: post #13

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/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.

Windows does have signals! It just splits them into a few facilities. POSIX "synchronous" signals correspond to SEH exceptions and can be handled roughly the same way --- except that signals have process global handlers and Windows has thread-local ones, because the glibc people are sticks in the mud and are hostile to any attempt to make signals suck less.

For asynchronous signals, like SIGINT, Windows create a new thread out of thin air to deliver your app a notification. That's not really all that much better than a signal from a concurrency perspective.

Windows even has APCs, which are like regular signals that are delivered only at explicit system call boundaries.

Every operating system needs some mechanism to tell a process to do something. Windows has evolved an approach that isn't all that different from Unix signal handling.

Re: Introducing the Windows Pseudo Console (ConPty)

#42

Post by paulie_a »

zadjii wrote: post #29
paulie_a wrote: post #25

Earlier quoted context omitted.

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.

Is there a chance this will be connected to a functional shell interface. I get your point that cmd cannot be upgraded because of legacy issues and that is understandable and unfortunate, but windows needs a proper shell. This is obviously a great start for one side of the equation. But until there is a decent terminal app, windows will continue to be a nonstarter.

Re: Introducing the Windows Pseudo Console (ConPty)

#43

Post by zadjii »

tokyodude wrote: post #39
paulie_a wrote: post #25

Earlier quoted context omitted.

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.

some other HN thread recommended cmder. I haven't touched cmd since http://cmder.net/

Ah but see, now you're conflating two different things:

cmd.exe is a shell

conhost and cmder are terminals.

I believe cmder can come with git bash as well, which is also a shell.

The confusion comes from when you launch cmd, the window that appears by default is conhost, with cmd running attached to it. When you launch cmder, it's also running attached to cmd.

Re: Introducing the Windows Pseudo Console (ConPty)

#44

Post by zadjii »

paulie_a wrote: post #42
zadjii wrote: post #29

Earlier quoted context omitted.

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.

Is there a chance this will be connected to a functional shell interface. I get your point that cmd cannot be upgraded because of legacy issues and that is understandable and unfortunate, but windows needs a proper shell. This is obviously a great start for one side of the equation. But until there is a decent terminal app, windows will continue to be a nonstarter.

It sounds like you're asking for two different things here:

cmd.exe is a shell, and that's the guy that's parked.

conhost.exe is a terminal, and that's under active development, though it's slower than something like VsCode, because we can't just go adding features as we see fit, we have a LOT of back compat we still need to support.

Fortunately, conpty will allow for the creation of new terminal applications on Windows. If you're looking for a better shell experience on windows, I can point you to powershell or even [yori](http://www.malsmith.net/yori/), which looks pretty cool

Re: Introducing the Windows Pseudo Console (ConPty)

#45

Post by zadjii »

cryptonector wrote: post #15
zadjii wrote: post #9

Earlier 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.…

Out of curiosity, are you backporting onto Windows 10, or is Windows 10 the only release vehicle for everything in master? If the latter, how are you releasing piecemeal?

Pretty much any new features we release are only available on new Windows 10 releases. Unless there's a gigantic demand for a feature, or business impact, we're not really capable on our team of backporting anything.

Re: Introducing the Windows Pseudo Console (ConPty)

#46

Post by zadjii »

amluto wrote: post #36

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.

It is! But this is a very un-windows like feature, isn't it? We want this to work on other platforms with as little modification as necessary, and frankly, jumping through the wchar_tchar hoops is a _pain_. So we'll do it for you!

Re: Introducing the Windows Pseudo Console (ConPty)

#47

Post by zadjii »

theclaw wrote: post #38
zadjii wrote: post #2

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 i…

I'm unclear as to whether I'll be able to pipe binary data between a classic console application and a ConPTY application due to the VT translation and rendering components in ConHost. So, for example if I was to pipe into 7z.exe, a classic console app, using something like "type mybinaryfile.bin | 7z.exe a -si c:\temp\myarchive.7z" from a ConPTY console, would the VT translation affect the piped stream?

Nope! We're only rendering the effect of any attached processes to the VT on the conpty side of things. On the client side (where cmd, type, 7z.exe are all running), they're going to keep working just the same as they always have. They're all running on the "slave" side of conpty, while the emitted VT is coming from the "master" side of the conpty.

Re: Introducing the Windows Pseudo Console (ConPty)

#48

Post by zadjii »

berbec wrote: post #17
zadjii wrote: post #2

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 i…

Will there be the ability to disown, background, nohup processes and close the console, leaving the commands running?

Those sound like they'll be more like the responsibility of the terminal emulator, unfortunately.

Windows console applications aren't really able to live without being attached to a console. Now, a terminal might be able to implement those features...

actually now you've got me thinking. I'll play around with that idea. Definitely non-committal, but it might be possible in the future.

Re: Introducing the Windows Pseudo Console (ConPty)

#49

Post by zadjii »

hoppelhase wrote: post #33

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.

That'll work just the same as it always has :) Existing commandline applications won't be affected by this feature, but it will open the doors for an entirely new class of applications.

Re: Introducing the Windows Pseudo Console (ConPty)

#50

Post by [deleted] »

zadjii wrote: post #9
nailer wrote: post #6

Earlier 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.…

[deleted]
Post reply on HN