Thanks to WSL and this, I'm very hopeful that my next development laptop can be a windows device
Introducing the Windows Pseudo Console (ConPty)
161–170 of 196 posts
Re: Introducing the Windows Pseudo Console (ConPty)
#162Earlier quoted context omitted.
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.
Linux can do that as well, see SIGEV_THREAD.
Only for AIO, which few use.
Re: Introducing the Windows Pseudo Console (ConPty)
#163Earlier quoted context omitted.
I don't see anything wrong with what you're saying, but I still don't get how it explains the original comment I replied to [1]: > I'm not at all convinced that 2^21 codepoints will be enough, so someday it'd be nice to be able to get past UTF-16 and move to UTF-8 UTF-16 currently uses up to 2 16-bit code units per code point, whereas UTF-8 uses up to 4 8-bit code units per code point, and the latter wastes more bits…
If I had intended to explain that, I wouldn't be replying to your comment about your not working out the bits with an explanation that works out the bits for you, and shows that it really is capable of encoding all 17 planes even though surrogate pairs have only 20 bits. And as you can see, if you do work out the bits, you find that cryptonector is wrong, since UTF-8 (as it has been standardized from almost the start…
No, UTF-8 could, and used to, encode much more than 21 bits of codepoint space. It has been artificially limited to better match UTF-16 -- UTF-16's limits are not artificial but fundamental. If some day we need more bits, we'll simply obsolete UTF-16 and drop those limits on UTF-8. MSFT seems to be taking steps to put UTF-8 on a level or even higher playing field than UTF-16. We should welcome this.
Re: Introducing the Windows Pseudo Console (ConPty)
#164Earlier quoted context omitted.
UTF-16 is a variable-length encoding using up to two code units which each are 16-bits wide. UTF-8 is a variable-length encoding using up to 4 code units (though it used to be up to 6, and could again be up to 6) each of which are 8-bits wide. Both, UTF-16 and UTF-8 are variable-length encodings! UTF-32 is not variable-length, but even so, the way Unicode works a character like ´ (á) can be written in two diffe…
For completeness sake: the confusing part is that there is (used to be) a constant-length encoding that uses the exact same codepoints as UTF-16, but doesn't allow the variable-length extensions. That encoding is called UCS-2 and although deprecated, is the reason why many people think UTF-16 is constant-length.
Not the same codepoints as UTF-16, but a subset. But yes, UCS-2 is the source of all this evil.
Re: Introducing the Windows Pseudo Console (ConPty)
#165Earlier quoted context omitted.
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 unatte…
That's a really good point.
Re: Introducing the Windows Pseudo Console (ConPty)
#166Earlier 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…
It's a difference between making mv/move, cp/copy client-server aware and making the shell running these simple utilities client-server aware.
The Windows way would be to mount the remote filesystem and use local mv and cp. Which works fine, since Windows has excellent remote filesystem support. The Unix world only partially began to catch up to CIFS with the advent of NFSv4 and its lease infrastructure and it still isn't as seamless as the Windows stuff.
Re: Introducing the Windows Pseudo Console (ConPty)
#167Earlier quoted context omitted.
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.
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!
Re: Introducing the Windows Pseudo Console (ConPty)
#168Earlier quoted context omitted.
Unicode code point space: Was 16-bit (0000 to FFFF), then 32-bit (00000000 to FFFFFFFF), and is now 21-bit (00000000 to 0010FFFF) UTF-16: Encodes the entire 21-bit range, encoding most of the first 0000 to FFFF range as-is, and using surrogate pairs in that range to encode 00010000 to 0010FFFF. The latter range is shifted to 00000000 to 000FFFFF before encoding, which can be encoded in the 20 bits that surrogate pair…
> a lot of UTF-8 codecs in the real world actually no longer contain the code for handling the longer sequences. Not exactly. A conforming decoder MUST reject them. MySQL’s problem is that, by default, it can’t even handle all valid code points.
They reject them by not having a code path that successfully decodes them.
Re: Introducing the Windows Pseudo Console (ConPty)
#169Wow, there might be able to be a proper ncurses port now!
Functionally, we support all of the VT sequences you'd need to make ncurses work resonably well on windows for a few releases now (ever since WSL was introduced). If you could build an ncurses that assumed TERM=xterm-256color, then you might be able to get it to work on windows.
Re: Introducing the Windows Pseudo Console (ConPty)
#170Earlier quoted context omitted.
You can suspend and resume threads, so if you model your jobs with processes that could be used for that, I guess.
*with threads
Processes. A quick skim of the documentation linked by the person I answered suggests that processes can be associated with a job object, but threads cannot. But a process cannot really be suspended directly, except by suspending all its threads.