termproc
1.0.0
IMPORTANTE
El nuevo modelo de proceso de Windows Terminal versión 1.18 requiere un enfoque diferente.
Consulte https://github.com/german-one/termwnd para conocer la nueva implementación.
El propósito del código en este repositorio es distinguir entre los procesos de Conhost y Windows Terminal y determinar qué instancia de terminal está conectada al proceso de consola actual. No se admiten aplicaciones de terminal de terceros.
Los archivos fuente son transcripciones de prácticamente el mismo código central en diferentes lenguajes de programación.
Los archivos fuente en Windows Batch , C , C++ , C#.Net , PowerShell y VB.Net se publican en la carpeta src. Todos dependen de que Windows sea el sistema operativo de destino. Otras dependencias específicas se enumeran a continuación.
| Archivo | Requisito |
|---|---|
*.bat | WindowsPowerShell 2 |
*.c | C99 |
*.cpp | C++20 |
*.cs | Marco .NET 4.5 |
*.ps1 | WindowsPowerShell 2 |
*.vb | Marco .NET 4.5 |
Los archivos fuente de este repositorio contienen código completamente funcional que demuestra cómo utilizar el procedimiento de búsqueda. Sin embargo, si tiene la intención de utilizarlo en su propio código, puede resultar útil saber qué partes esenciales del código debe incluir.
| Archivo | Código de interés | Valor de interés |
|---|---|---|
*.bat | Macro TermPid definida en la rutina :init_TermPid | el nivel de error devuelto por la macro TermPid es el PID del terminal de alojamiento ( 0 si ocurrió un error) |
*.c | Función GetTermPid , junto con la estructura SYSTEM_HANDLE y las funciones GetProcBaseName , GetPidOfNamedProcWithOpenProcHandle | el valor devuelto por la función GetTermPid es el PID del terminal de alojamiento ( 0 si ocurrió un error) |
*.cpp | todo en el espacio de nombres termpid , junto con los espacios de nombres saferes y la función GetProcBaseName | el valor devuelto por la función GetTermPid es el PID del terminal de alojamiento ( 0 o excepción si ocurrió un error) |
*.cs | clase WinTerm | el valor de la propiedad WinTerm.TermProc se refiere al proceso del terminal de hosting ( null o excepción si ocurrió un error) |
*.ps1 | Clase de referencia de tipo WinTerm | el valor de la propiedad [WinTerm]::TermProc se refiere al proceso del terminal de hospedaje ( $null o tipo WinTerm no definido si ocurrió un error) |
*.vb | Módulo WinTerm | el valor de la propiedad WinTerm.TermProc se refiere al proceso del terminal de hosting ( Nothing o excepción si ocurrió un error) |
Hace unos años, Microsoft comenzó a desarrollar una nueva aplicación de terminal: Windows Terminal. La instalación está disponible para Windows 10 y Windows 11 ya viene con ella. Mediante una actualización del 22 de octubre, Microsoft la convirtió en la aplicación de terminal predeterminada en Windows 11.
A partir de ahora, Windows Terminal coexiste con el viejo Conhost. Los usuarios pueden elegir cuál se toma como su aplicación de terminal predeterminada.
En el pasado, era fácil determinar qué proceso de terminal está conectado a la aplicación de shell/consola. Detrás de escena siempre fue Conhost y, por lo tanto, Microsoft hizo que la API de Windows informara el proceso que generó el proceso conhost como el proceso de terminal y reportara la ventana de la aplicación Shell como la ventana de la consola. Si bien todo esto es técnicamente incorrecto, al mismo tiempo resulta bastante cómodo.
Sin embargo, no se implementa dicha funcionalidad conveniente para la Terminal de Windows. Y si Windows Terminal está configurado como terminal predeterminado, no podemos inferir del árbol de procesos qué proceso de terminal se está comunicando con nuestro proceso de shell.
Al utilizar Process Explorer, observé que el proceso de Terminal de Windows tiene un identificador para el proceso de shell abierto. Suponiendo que este es siempre el caso, intenté escribir un fragmento de código que enumere todos los identificadores abiertos en busca del identificador de proceso correcto. Esto requiere involucrar alguna API no documentada. Dejé un par de comentarios en el código que explican aproximadamente cómo funciona todo esto.
En cada archivo también hay un fragmento de código no relacionado que hace desaparecer y volver a aparecer la ventana. Me pareció una forma impresionante de demostrar que se había encontrado el proceso correcto. 
Esta es una breve explicación de cómo se implementa la búsqueda en los códigos fuente.
NtQuerySystemInformation se utiliza para obtener una instantánea de todos los identificadores abiertos en todos los procesos en ejecución. (Esto no está documentado oficialmente).
