Live data from Hacker News

Introducing the Windows Pseudo Console (ConPty)

blogs.msdn.microsoft.com

71–80 of 196 posts

Re: Introducing the Windows Pseudo Console (ConPty)

#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, using Windows for development is against your own best interest. If you like to be treated as a dog that is not allowed inside the house, use Windows.

Re: Introducing the Windows Pseudo Console (ConPty)

#72
post #45

Earlier quoted context omitted.

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.

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.

Re: Introducing the Windows Pseudo Console (ConPty)

#73
post #60

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.

[deleted]

Re: Introducing the Windows Pseudo Console (ConPty)

#74

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…

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

The Windows Console was even more terminally dead. Terminals have their limitations, but honestly, I'll take a terminal, tty/pty, and terminfo, any day over the Windows Console.

Re: Introducing the Windows Pseudo Console (ConPty)

#75

Earlier quoted context omitted.

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…

Spawning a new thread to handle a signal is much better than preemption: you then have no concerns about async-signal-safety that aren't plain old thread-safety concerns. I'd much rather have thread-safety constraints than async-signal-safety constraints.

Sort of. At least you can mask signals. I agree that threads are probably better overall, but I don't think it's a huge difference.

Re: Introducing the Windows Pseudo Console (ConPty)

#76

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.

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

It's also the most absurdly verbose shell that exists, which means it sucks as a shell even if it's a half-decent scripting language.

Re: Introducing the Windows Pseudo Console (ConPty)

#77
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.

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!

Another exciting development in moving beyond UTF-16: Microsoft is experimenting with adding a native UTF-8 string in .NET next to the existing UTF-16 string:

https://github.com/dotnet/coreclr/commits/feature/utf8string

Re: Introducing the Windows Pseudo Console (ConPty)

#78
post #60

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.

UTF-16 has a bit of a funky design (using four byte/two code unit surrogate pairs to encode code points outside the basic multilingual plane) that ultimately restricts Unicode (if compatibility is to be maintained with UTF-16, at least) to 17 planes, or 2^20 code points (about 1 million).

UTF-8 uses a variable length encoding that allows for more characters-- if restricted to four bytes, it allows for 2^21 total code points; it's designed to eventually allow for 2^31 code points, which works out to about 2 billion code points that can be expressed.

(Granted, this is all hypothetical-- Unicode isn't even close to filling all of the space that UTF-16 allows; there aren't enough known writing systems yet to be encoded to fill all of the remaining Unicode planes (3-13 of 17 are all still unassigned). But UTF-16's still nonstandard (most of the world's standardized on UTF-8) and kind of ugly, so the sooner it goes away, the better.)

Re: Introducing the Windows Pseudo Console (ConPty)

#79
post #60

Earlier quoted context omitted.

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

No humor whatsoever. Thank you for the explanation! I'm an ops person who knows python/golang to a dangerous extent and have never gone out of my way to understand the UTF reasonings. Your post intrigued me and made me want to ask why you felt that way. This will make me sound horrendously ignorant to someone of the likes of someone such as yourself but I'm here to learn.

Re: Introducing the Windows Pseudo Console (ConPty)

#80
post #76

Earlier quoted context omitted.

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

It's also the most absurdly verbose shell that exists, which means it sucks as a shell even if it's a half-decent scripting language.

What is with all you people who used PowerShell for a grand total of 10 seconds, gave up because it wasn't bash, then go on to complain about completely false things?

PowerShell has aliases. It has shortened aliases for all the common commandlets. You can create your own aliases if you want.

PowerShell has tab completion on commandlets, arguments, flags, and variable names. FFS...

Every time I run into another one of you it gets increasingly harder to be polite about telling you how wrong you are.

Post reply on HN