if STREAM.isatty():

[Eryk Sun]

On 8/30/19, Chris Angelico <rosuav at gmail.com> wrote:
> On Sat, Aug 31, 2019 at 7:42 AM Eryk Sun <eryksun at gmail.com> wrote:
>
>> In Windows 8+, a process attaches to a console by opening
>> "\Device\ConDrv\Connect" as a connection to an instance of the console
>> host process, conhost.exe. This handle is stored internally as
>> "ConsoleHandle" (in its PEB->ProcessParameters). The console API uses
>> this handle for functions that don't operate on a stream, such as
>> GetConsoleTitle.
>> [chomp more details]
>
> Huh. I kinda just assumed that, since cmd.exe was still running, the
> console would continue to be in use. I guess technically it's a lot
> more complicated than that, but still, to the average user, the
> difference won't be visible.

I was just clarifying the implementation details of what kind of
reference is used to keep a console alive in Windows 8+. To me the
details are useful to flesh out a picture of how things work, so that
I know what to look for when they fail to work. For the average user
and average use case, all that we need to know is that at least one
process has to be attached to the console to keep it alive.

> And that's why the pseudo-tty system is vital to making things make
> sense. On Unix-like platforms, a tool like ssh can connect a program
> to something that it perceives as a TTY, and then take the contents
> elsewhere. It's a consistent system that works with any program.

Windows 10 has pseudoconsole support. I think the new Windows terminal
that's available in preview builds is based on this, but I haven't
experimented with it yet. Note that the console host process
(conhost.exe) is still in the loop. It works in this case as a
headless subsystem server (i.e. it doesn't create a window) that sits
in between the application and the terminal. The application<->ConHost
interface is still mediated in the kernel via the ConDrv console
device. But ConDrv is kept relatively simple. Most of the console
subsystem is implemented in the user-mode ConHost server process (in
coordination with the session subsystem process, CSRSS). The terminal
communicates with ConHost using a pair of pipes for I/O that stream
UTF-8 text with inline virtual-terminal sequences.

> Oh, and, well, GNU Readline is just a smidge better than the default
> Windows line editing, too...

There's pyreadline in Windows, which uses ctypes to access the console
at a low level in order to emulate GNU Readline. PowerShell has a
similar PSRreadline library that's enabled by default. It can be
configured to use Emacs or Vi mode, but it defaults to Windows mode,
which emulates the console's builtin line editing.