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

121–130 of 196 posts

Re: Introducing the Windows Pseudo Console (ConPty)

#121

Post by skrebbel »

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…

First, tmux works fine in WSL. Secondly, if you like both tmux and Windows, there's a fair chance you'll like ConEmu's split panel facility even better. It's basically tmux, but more "windowsy". ConEmu is spectacular.

Re: Introducing the Windows Pseudo Console (ConPty)

#122

Post by oblio »

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

Re: Introducing the Windows Pseudo Console (ConPty)

#123

Post by lokedhs »

cryptonector wrote: post #66
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?

That would be sad, as there is already far too much software out there that hard-codes escape sequences, completely ignoring the TERM environment variable.

Even worse, sometimes they won't even disable escape codes when they should not be displayed.

I've posted bug reports for very popular software packages whose commandline always output vt102, even when TERM is set to dumb or when run through pipes. That makes grepping for error messages somewhat annoying. In at least some cases these reports were ignored.

Re: Introducing the Windows Pseudo Console (ConPty)

#124

Post by oblio »

elFarto wrote: post #118
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.

Any chance that you could just fork it? Create cmd2.exe, hell you could even open-source it.

Is the pay-off big enough? Who knows what garbage code they might want to hide in there, for both technical reasons (including security) or even legal ones.

Re: Introducing the Windows Pseudo Console (ConPty)

#125

Post by SideburnsOfDoom »

cryptonector wrote: post #55
ChuckMcM wrote: post #40

This is pretty huge. For as long as I can remember the response to command line applications talking to command line applications was "Why would you want to do that? Use (RPC | shared memory | some other IPC mechanism)." And nobody at Microsoft seemed to understand how much simpler it was to use ptys. They seem to have completely capitulated to the notion ptys and are dropping them into the next release of W10. I wis…

It's the reality of the market, which is why Windows is adding Linux compatibility (as is every *BSD, Illumos, ...). But also it's the fact that three decades of not even life support has left the Windows console in pretty sad shape -- the folks tasked with getting it into better shape were bound to see the value of ptys. Lastly, don't forget that Windows NT was meant to be a console OS, like VMS. There must still be…

> Lastly, don't forget that Windows NT was meant to be a console OS, like VMS. There must still be people, even if very few, at MSFT who appreciate text-oriented apps.

I expect that, like Linux compatibility, most of it is not about "apps" but about being better at running in the cloud, where a (virtual) machine or container needs to be as light as possible, and to be configured and a service launched in it as unattended/automated manner as possible. Stripping out the GUI and making command lines work better works towards these goals.

Re: Introducing the Windows Pseudo Console (ConPty)

#126

Post by nailer »

hoppelhase wrote: post #34
quotemstr wrote: post #23

Earlier quoted context omitted.

You might want to talk to the Cygwin people to get their pty layer to use the new virtual console.

Maybe the guys at alacritty are interested in this as well. https://github.com/jwilm/alacritty

They are: https://github.com/jwilm/alacritty/issues/28

Re: Introducing the Windows Pseudo Console (ConPty)

#127

Post by pjc50 »

acqq wrote: post #119
ChuckMcM wrote: post #40

This is pretty huge. For as long as I can remember the response to command line applications talking to command line applications was "Why would you want to do that? Use (RPC | shared memory | some other IPC mechanism)." And nobody at Microsoft seemed to understand how much simpler it was to use ptys. They seem to have completely capitulated to the notion ptys and are dropping them into the next release of W10. I wis…

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 can use the same interface as a human. You can also plug any stream-of-bytes into any other stream-of-bytes, whereas API or RPC based systems have to be designed to interoperate.

Re: Introducing the Windows Pseudo Console (ConPty)

#129

Post by pjc50 »

zvrba wrote: post #108
ChuckMcM wrote: post #40

This is pretty huge. For as long as I can remember the response to command line applications talking to command line applications was "Why would you want to do that? Use (RPC | shared memory | some other IPC mechanism)." And nobody at Microsoft seemed to understand how much simpler it was to use ptys. They seem to have completely capitulated to the notion ptys and are dropping them into the next release of W10. I wis…

> Why would you want to do that? Use (RPC | shared memory | some other IPC mechanism). Yes, structured data exchange is the correct answer. When I have the opportunity to code something from scratch, this is the route I take.

> When I have the opportunity to code something from scratch

But how often does that happen, outside of toy systems and support utilities?

Re: Introducing the Windows Pseudo Console (ConPty)

#130

Post by jwilk »

mehrdadn wrote: post #105
yuubi wrote: post #103

Earlier quoted context omitted.

UTF-16 has a limit on the size of a code point because a code point is either a single normal code unit or a pair of surrogate code units, each encoding 10 bits of the code point (I think I used the right terminology). UTF-8 has a natural extension path to up to 7-byte encodings with all the usual UTF-8 properties (first code unit indicates how many remain, other code units are recognizable as not the first).

Where are you getting this information though? I haven't worked out the bits myself yet but Wikipedia's first sentence itself says UTF-16 can encode all 1,112,064 valid code points of Unicode, which is already more than 2^(10+10) = 1,048,576.

Yes, UTF-16 can encode all currently valid Unicode codepoints, which is more than 2²⁰ but less than 2²¹. But cryptonector doesn't believe it will be enough in the future.

OTOH, UTF-8, as originally defined, can encode 2³¹ codepoints.

Post reply on HN