On 8/30/19, Chris Angelico <ros...@gmail.com> wrote: > On Sat, Aug 31, 2019 at 7:42 AM Eryk Sun <eryk...@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. -- https://mail.python.org/mailman/listinfo/python-list
