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

171–180 of 196 posts

Re: Introducing the Windows Pseudo Console (ConPty)

#171

Post by zadjii »

badminton1 wrote: post #71

HRESULT WINAPI ResizePseudoConsole(_In_ HPCON hPC, _In_ COORD size); 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. 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. As a developer, us…

Honestly, learning Windows is just like learning another programming language. This API is designed to be the Windows equivalent of a unix API - of course it's not going to be the exact same thing, but functionally it does the same thing.

Re: Introducing the Windows Pseudo Console (ConPty)

#172

Post by zadjii »

cryptonector wrote: post #72
zadjii wrote: post #45

Earlier quoted context omitted.

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.

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

Re: Introducing the Windows Pseudo Console (ConPty)

#173

Post by acqq »

pjc50 wrote: post #127
acqq wrote: post #119

Earlier quoted context omitted.

I understand this as a "compatibility with * nix" existing software, not as an "amazing feature." Can anybody suggest why I should like it, except for the compatibility with the software written for * nix terminals? Even ssh being too interconnected with a terminal down to the many details was a shock for me... I expected the simple encryption mechanism, over which whatever communicates, even if that would implement…

> 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 the kitchen sink” (that is, exactly the kind of things mentioned in the OP or the comments, like terminal signals and whatnot) has to be there.

SSL is straightforward compared that, at least, once the keys are set. But ssh... as seen in the OP even the console or the terminal or however that part it called has to be very special, and they are obviously proud they implemented that too. In 2018. Probably decades after the last single hardware terminal was sold.

Re: Introducing the Windows Pseudo Console (ConPty)

#174

Post by zadjii »

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 client writes VT sequences, they still need to be interpreted by conhost. This is because technically, a console application could use both VT and the console API, and we need to make sure the buffer is consistent. So clients should still assume that they should write out `xterm-256color` compatible sequences.

Now on the other side of thngs, the "master"/terminal side of conpty, we're going to "render" the buffer changes to VT. Fortunately, we'd dont really need a deep VT vocabulary to make this possible, so the VT that's coming out of a conpty is actually pretty straightforward, probably even vt100 level (or I guess vt100-256colors, as insane a termcap that would be).

It's definitely a future feature that we'd like to add to make conpty support multiple different TERM settings, and change the sequences we emit based on what the terminal on the other side is going to expect.

We haven't really gotten into the nitty gritty of all of this quite yet, so if you find bugs or have feature requests, we're happy to take a look at them. You can file issues on [our github](https://github.com/microsoft/console) and we'll add them to our backlog

Re: Introducing the Windows Pseudo Console (ConPty)

#175

Post by JdeBP »

quotemstr wrote: post #167
JdeBP wrote: post #144

Earlier quoted context omitted.

The sad thing is that this was all already implemented and done in Microsoft's second POSIX subsystem for Windows NT. It provided signals and process groups support for job control shells. It had a full control sequence interpreter for output and control sequence generator for extended keys. There were termcap/terminfo database records that people had added to other operating systems. It had a line discipline with "c…

I wish people would stop pointing at the Linux subsystem and using it as an example of the stuff Windows in general could do. The Linux subsystem is a subsystem . In NT terminology, that makes it practically a container. It's disconnected from the rest of the system. It can interact with the win32 world in only a few constrained ways. You can't deliver SIGWINCH to a win32 process!

Actually, the second POSIX subsystem could deliver signals to Win32 processes. Who pointed at the Linux subsystem, by the way?

* https://news.ycombinator.com/item?id=11416392

Re: Introducing the Windows Pseudo Console (ConPty)

#176

Post by zadjii »

hoppelhase wrote: post #156
zadjii wrote: post #49

Earlier quoted context omitted.

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.

The existing Console API won't be extended with features of VT codes, or will it?

Oh we added support for VT sequences in commandline apps years ago - case in point, WSL.

see [this docs page](https://docs.microsoft.com/en-us/windows/console/console-vir...) for a (surprisingly incomplete) list of VT sequences we support, and how to use them.

Re: Introducing the Windows Pseudo Console (ConPty)

#177

Post by zadjii »

caf wrote: post #57
zadjii wrote: post #28

Earlier quoted context omitted.

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

*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're still very early in on this project. We still have lots of improvements to be made to the infrastructure and translation, and even as I type this up, I'm thinking there's probably a better way of handling alt buffers.

Re: Introducing the Windows Pseudo Console (ConPty)

#178

Post by OnlyRepliesToBS »

They're going to fuck up console like they fucked up the Registery, COM+, WPF, DirectDraw, Silverlight, WCF, etc...

It will be a clusterfuck of weird syntax that no doubt will embrace and extend what a console can do but then become proprietary as fuck.

Watch.

Cycle repeat.

Re: Introducing the Windows Pseudo Console (ConPty)

#179

Post by joeyaiello »

sime2009 wrote: post #146
joeyaiello wrote: post #16

Earlier quoted context omitted.

PM for PowerShell here! I haven't seen DomTerm before, but it looks pretty awesome. At a glance, it's basically a GUI-fied tmux hosted in Electron? It would be awesome to have in Windows, but wouldn't that just require that DomTerm add support for these ConPty APIs? In any case, I'm more interested in your proposed interactions. Did you have anything cool in mind? Given that we ship PowerShell on Linux, we could theo…

I'm not the person you were asking, but this should interest you. I've been working on a terminal emulator ( Extraterm http://extraterm.org/ ) with some novel features which would dovetail nicely with how PowerShell works. The first is the ability to send files to the terminal where they can be displayed as text, images, sound, etc or as an opaque download. Extraterm also adds a command `from` which lets you use prev…

Ooooh yeah, that sounds awesome! Going to share this with some people on our team (lots of folks love and use Hyper already, but we're always looking for new stuff to play with).

I would highly recommend you check out the excellent HistoryPx module[1]. Among (many) other things, it supports automatically saving the most recently emitted output to a magic `$__` variable. Theoretically, you could save a lot further back, but you may start to run into memory constraints (turns out .NET objects are a little heavier than text... ;) )

[1]: https://github.com/KirkMunro/HistoryPx

Post reply on HN