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

181–190 of 196 posts

Re: Introducing the Windows Pseudo Console (ConPty)

#181

Post by kpil »

oblio wrote: post #122
kpil wrote: post #111

-- Those who don't understand Unix are condemned to reinvent it, poorly. Henry Spencer

This is such a cliché. Do you think that the people who implemented the Windows Console, especially the people working on Windows NT, did not know about Unix? People try different approaches, sometimes they don't work out. And it's not like Unix is the Word of God, anyway, it has plenty of flaws. (Yeah, after a long time on internet forums I get kind of touchy after someone copy-pastes the same old and tired line.)

Since it took them 20 years to make a half-decent shell and 30 years how to figure out how stdout should work: no they had no clue.

Maybe they knew how a kernel should work though, but weren't the NT guys old VMS guys? That's a totally un-unixy OS actually.

Re: Introducing the Windows Pseudo Console (ConPty)

#182

Post by cryptonector »

zadjii wrote: post #172
cryptonector wrote: post #72

Earlier quoted context omitted.

What I meant is: are you building a Windows 11, or is Windows 10 the only release vehicle? I'm trying to imagine you pushing to a master branch to integrate into what becomes the insider builds, and then... either those become a future release of Windows 10, or you backport onto a Windows 10 branch. Neither option would be very appealing to me if it was up to me.

Windows 10 is the "last Windows ever". There's a pretty wide tree of branches under "winmain" that teams contribute to, and at each layer more branches are merged together, until they finally hit winmain, and then weekly they tag (more or less) a build from winmain as the Insider's build for the week. It's actually a lot more elegant than you'd expect it to be for a project with as many developers as Windows has

Thanks. Got it. Having worked on Solaris, this sort of thing is very interesting to me.

Re: Introducing the Windows Pseudo Console (ConPty)

#183

Post by c487bd62 »

kpil wrote: post #181
oblio wrote: post #122

Earlier quoted context omitted.

This is such a cliché. Do you think that the people who implemented the Windows Console, especially the people working on Windows NT, did not know about Unix? People try different approaches, sometimes they don't work out. And it's not like Unix is the Word of God, anyway, it has plenty of flaws. (Yeah, after a long time on internet forums I get kind of touchy after someone copy-pastes the same old and tired line.)

Since it took them 20 years to make a half-decent shell and 30 years how to figure out how stdout should work: no they had no clue. Maybe they knew how a kernel should work though, but weren't the NT guys old VMS guys? That's a totally un-unixy OS actually.

It's all about pushing Azure and dedicating resources to said goals

Re: Introducing the Windows Pseudo Console (ConPty)

#184

Post by caf »

zadjii wrote: post #174
caf wrote: post #59

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

So this is a confusing situation on Windows. Commandline applications on linux rely on a TERM setting (with termcaps) to be able to know what VT sequences the terminal is able to support. On Windows, we only really have one terminal, conhost.exe, and our goal there is to be compatible with TERM=`xterm-256color`. That's why you'll see that WSL has that set as the default term setting. Now even with ConPTY, when a clie…

Thanks. It makes sense to pick an existing terminal like xterm-256color to target - that way you don't have to worry about a new terminfo database entry getting distributed out.

The nitty-gritty can get quite nitty - things like bracketed paste and set window title.

Re: Introducing the Windows Pseudo Console (ConPty)

#185

Post by ThJ »

acqq wrote: post #173
pjc50 wrote: post #127

Earlier quoted context omitted.

> I expected the simple encryption mechanism, over which whatever communicates In the UNIX world, that's what it gives you - a stream of bytes. Hence things like rsync-over-ssh or git-over-ssh. It also has a port forwarding mode which has special support for X11, which gives you remote windowing over a stream of bytes too. The main, huge, benefit is that the abstraction is pretty simple, it's discoverable, and you ca…

As I’ve tried to implement my minimal ssh client (just to connect, execute some command and get the result) I’ve had exactly opposite impression of the “just a stream of bytes” that you mention -- exactly the lack the abstraction. Can you point to any source that does ssh without having to care about a lot of weird terminal and console ancient stuff? I’d be really glad to see it! To me it looked as “everything and th…

You are conflating what SSH does with what the terminal you're running it in does. SSH barely knows what terminal emulation is. You can literally pipe binary data into it at one end and receive that data into a program at the other end. That's what programs like scp and rsync do. They launch ssh and use it as a data channel.

Re: Introducing the Windows Pseudo Console (ConPty)

#186

Post by pasabagi »

acqq wrote: post #173
pjc50 wrote: post #127

Earlier quoted context omitted.

> I expected the simple encryption mechanism, over which whatever communicates In the UNIX world, that's what it gives you - a stream of bytes. Hence things like rsync-over-ssh or git-over-ssh. It also has a port forwarding mode which has special support for X11, which gives you remote windowing over a stream of bytes too. The main, huge, benefit is that the abstraction is pretty simple, it's discoverable, and you ca…

As I’ve tried to implement my minimal ssh client (just to connect, execute some command and get the result) I’ve had exactly opposite impression of the “just a stream of bytes” that you mention -- exactly the lack the abstraction. Can you point to any source that does ssh without having to care about a lot of weird terminal and console ancient stuff? I’d be really glad to see it! To me it looked as “everything and th…

I see your point - but don't you find it kinda charming? It's a bit like drinking tea in a china cup, or eating a scone with clotted cream.

I think there is probably a lot of room for improvement in the terminal world, and I agree that a lot of the really old stuff makes things a bit counter-intuitive, but for whatever reason, it seems that people who make really good software also tend to be the people who are pretty fanatical about backwards compatibility. Consider vim, for instance.

In the end, I think the basic model of interoperable, small programs that manipulate streams of text is really good - so people will put up with any number of weird rituals to live in that model. It's also very humble, and very unexciting, so it's the kind of thing that's hard to get people hyped about. So it probably filters by the people that like old things.

Re: Introducing the Windows Pseudo Console (ConPty)

#188

Post by quotemstr »

andreyv wrote: post #180
quotemstr wrote: post #162

Earlier quoted context omitted.

Only for AIO, which few use.

You can spawn a thread manually and use the POSIX sigwait() function.

That won't stop the process-wide registered signal handler working and it won't do anything about being able to reliably handle synchronous signals.

Re: Introducing the Windows Pseudo Console (ConPty)

#189

Post by caf »

zadjii wrote: post #177
caf wrote: post #57

Earlier quoted context omitted.

*nix consoles typically have two buffers - many full-screen temrinal applications switch to the "alternate screen" on start and back to the principal screen on exit. That's why when you exit vim(1), you see the terminal state back as it was before you started it. Will ConPty support this?

Yep! It'll probably act a little different than you'd expect - the pseudoconsole itself will switch between the primary and alt buffers, leaving the terminal in the main buffer always. We'll "render" the contents of the alt buffer to the terminal, then when the client app switches back to the main buffer, conpty will re-render the contents of the main buffer to the terminal. It's not the most elegant solution, but we…

That's pretty much how it works if you have a screen/tmux type program in your path as well, so that makes sense.

Re: Introducing the Windows Pseudo Console (ConPty)

#190

Post by acqq »

ThJ wrote: post #185
acqq wrote: post #173

Earlier quoted context omitted.

As I’ve tried to implement my minimal ssh client (just to connect, execute some command and get the result) I’ve had exactly opposite impression of the “just a stream of bytes” that you mention -- exactly the lack the abstraction. Can you point to any source that does ssh without having to care about a lot of weird terminal and console ancient stuff? I’d be really glad to see it! To me it looked as “everything and th…

You are conflating what SSH does with what the terminal you're running it in does. SSH barely knows what terminal emulation is. You can literally pipe binary data into it at one end and receive that data into a program at the other end. That's what programs like scp and rsync do. They launch ssh and use it as a data channel.

> You can literally pipe binary data into it at one end and receive that data into a program at the other end

That is the user perspective, not what has to be in a ssh program to work.

Post reply on HN