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

61–70 of 196 posts

Re: Introducing the Windows Pseudo Console (ConPty)

#61

Post by cryptonector »

zadjii wrote: post #32
rogerbinns wrote: post #12

Earlier quoted context omitted.

Have you given thought on how to solve the "unwanted console" problem? For example if you run a .py file (Python) under Windows then you get a console. That is fine for command line stuff, but beyond annoying if the file displays as a gui. So there are now two Python binaries - python.exe and pythonw.exe. The only difference is the latter ensures no console appears. Also good luck if the script printed a help message…

Technically, any executable that's compiled as a commandline application is going to get a console allocated for it, no matter what on Windows. I don't believe that's something we can fix retroactively unfortunately, that's just a part of how things have to be. Now, I believe that python could have python.exe compiled as a win32 application, then call AllocateConsole as soon as the script called print() or something.…

Why... can't you have I/O redirection to the null device and have it understand (and throw away) Console API messages? You might as well also add some pseudo-device to convert Console API messages into Unix-style text streams (with or without metadata converted to terminal control sequences), so that one could redirect console programs' output to files / pipes.

When the user's (programmer's) intent is to run a program with no console window, then that's what they should get: no console window.

Re: Introducing the Windows Pseudo Console (ConPty)

#62

Post by cryptonector »

caf wrote: post #54
cryptonector wrote: post #51

Earlier quoted context omitted.

I mean, it could be a packet stream where some packets are control packets, and then the Console API could be used and remoted, but you'd need clients that understand it. The fragility of in-band signaling in the TTY world is not *nix's fault or anything. VMS had that too, since VMS too had to deal with TTYs. The fact is that a) the system evolved from real, hardware TTYs of the 1970s, b) using a text stream with som…

You also have to sanitise untrusted data that you want to output.

And remember to use less -R or else pipe to col(1) or whatever.

Re: Introducing the Windows Pseudo Console (ConPty)

#63

Post by cryptonector »

zadjii wrote: post #44
paulie_a wrote: post #42

Earlier quoted context omitted.

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

I think u/paulie_a is just asking for a better shell. If cmd can't be made better, then make a new one.

Re: Introducing the Windows Pseudo Console (ConPty)

#64

Post by cryptonector »

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?

I hate the alternate screen with a passion.

Re: Introducing the Windows Pseudo Console (ConPty)

#65

Post by cryptonector »

zadjii wrote: post #48
berbec wrote: post #17

Earlier quoted context omitted.

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.

I mean, the same is true on Unix. If an app is in the background and wants to write to (or read from) the terminal, it gets SIGTTOU (SIGTTIN) sent to it immediately. It might have to be impossible on Windows to ignore SIGTTOU/SIGTTIN/SIGTSTOP, but I think that's just fine.

Mind you, ptys + tmux/similar is certainly very good, and if that's all we'll get that's still way way better than the current state of affairs, but if that's all that will be possible it should at least be possible to pause the console's output (and flow-control the console application).

Re: Introducing the Windows Pseudo Console (ConPty)

#66

Post by cryptonector »

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…

I second this question. Perhaps there will only be support for vt100/vt220?

Re: Introducing the Windows Pseudo Console (ConPty)

#67

Post by AnIdiotOnTheNet »

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.

Windows has a proper shell, it's called PowerShell and it is by far the most discoverable and consistent shell that exists.

Re: Introducing the Windows Pseudo Console (ConPty)

#68

Post by quotemstr »

cryptonector wrote: post #51
quotemstr wrote: post #24

Earlier quoted context omitted.

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

I mean, it could be a packet stream where some packets are control packets, and then the Console API could be used and remoted, but you'd need clients that understand it. The fragility of in-band signaling in the TTY world is not *nix's fault or anything. VMS had that too, since VMS too had to deal with TTYs. The fact is that a) the system evolved from real, hardware TTYs of the 1970s, b) using a text stream with som…

https://m.facebook.com/notes/daniel-colascione/term-is-termi...

Re: Introducing the Windows Pseudo Console (ConPty)

#69

Post by cryptonector »

swozey wrote: post #60
cryptonector wrote: post #56

Earlier quoted context omitted.

UTF-16 is garbage. Windows is stuck with it because it was too early an adopter of Unicode. Oh the irony. This may set Windows on a path to deprecating UTF-16 -- godspeed!

Could you elaborate? I've been under the guise for most of my career that doubling a digit leads to huge benefits that I'm too comp-sci ignorant to understand.

Can I assume that's just subtle humor on your part?

If not:

UTF-16 is born of UCS-2 being a very poor codeset, as it was limited to the Unicode BMP, which means 2^16 codepoints, but Unicode has many more codepoints, so users couldn't have the pile-of-poo emoticon. Something had to be done, and that something was to create a variable-length (in terms of 16-bit code units) encoding using a few then-unassigned codepoints in the BMP. The result yields only a sad, pathetic, measly 2^21 codepoints, and that's just not that much. Moreover, while many codesets play well with ASCII, UTF-16 doesn't. Also, decomposed forms of Unicode glyphs necessarily involve multiple codepoints, thus multiple code units... Many programmers hate variable length text encoding because they can't do simple array indexing operations to find the nth character in a string, but with UTF-8, UTF-16, and just plain decomposition, that's a fact of life anyways. If you're going to have a variable-length codeset encoding, you might as well use UTF-8 and get all its plays-nice-with-ASCII benefits. For Latin-mostly text UTF-8 also is more efficient than UTF-16, so there is a slight benefit there.

Much of the rest of the non-Windows, non-ECMAScript world has settled on UTF-8, and that's a very very good thing.

Re: Introducing the Windows Pseudo Console (ConPty)

#70

Post by evanrelf »

swozey wrote: post #60
cryptonector wrote: post #56

Earlier quoted context omitted.

UTF-16 is garbage. Windows is stuck with it because it was too early an adopter of Unicode. Oh the irony. This may set Windows on a path to deprecating UTF-16 -- godspeed!

Could you elaborate? I've been under the guise for most of my career that doubling a digit leads to huge benefits that I'm too comp-sci ignorant to understand.

Wikipedia says: "UTF-8 requires 8, 16, 24 or 32 bits (one to four octets) to encode a Unicode character, UTF-16 requires either 16 or 32 bits to encode a character"

https://en.wikipedia.org/wiki/Comparison_of_Unicode_encoding...

Post reply on HN