termproc
1.0.0
IMPORTANT
Le nouveau modèle de processus de Windows Terminal version 1.18 nécessite une approche différente.
Reportez-vous à https://github.com/german-one/termwnd pour la nouvelle implémentation.
Le but du code de ce référentiel est à la fois de faire la distinction entre les processus Conhost et Windows Terminal et de déterminer quelle instance de terminal est connectée au processus de console actuel. Les applications de terminal tiers ne sont pas prises en charge.
Les fichiers sources sont des transcriptions à peu près du même code de base dans différents langages de programmation.
Les fichiers sources dans Windows Batch , C , C++ , C#.Net , PowerShell et VB.Net sont publiés dans le dossier src. Ils dépendent tous du fait que Windows soit le système d’exploitation cible. D'autres dépendances spécifiques sont répertoriées ci-dessous.
| Déposer | Exigence |
|---|---|
*.bat | Windows PowerShell 2 |
*.c | C99 |
*.cpp | C++20 |
*.cs | .NET Framework 4.5 |
*.ps1 | Windows PowerShell 2 |
*.vb | .NET Framework 4.5 |
Les fichiers sources de ce référentiel contiennent du code entièrement fonctionnel qui montre comment utiliser la procédure de recherche. Cependant, si vous avez l'intention de l'utiliser dans votre propre code, il peut être utile de savoir quels éléments de code essentiels vous devez inclure.
| Déposer | Code d'intérêt | Valeur de l'intérêt |
|---|---|---|
*.bat | Macro TermPid définie dans la routine :init_TermPid | le niveau d'erreur renvoyé par la macro TermPid est le PID du terminal d'hébergement ( 0 si une erreur s'est produite) |
*.c | Fonction GetTermPid , avec la structure SYSTEM_HANDLE et les fonctions GetProcBaseName , GetPidOfNamedProcWithOpenProcHandle | la valeur renvoyée par la fonction GetTermPid est le PID du terminal d'hébergement ( 0 si une erreur est survenue) |
*.cpp | tout ce qui se trouve dans l'espace de noms termpid , ainsi que saferes de l'espace de noms et la fonction GetProcBaseName | la valeur renvoyée par la fonction GetTermPid est le PID du terminal d'hébergement ( 0 ou exception si une erreur est survenue) |
*.cs | classe WinTerm | la valeur de la propriété WinTerm.TermProc fait référence au processus du terminal d'hébergement ( null ou exception si une erreur s'est produite) |
*.ps1 | Classe de référencement de type WinTerm | la valeur de la propriété [WinTerm]::TermProc fait référence au processus du terminal d'hébergement ( $null ou tapez WinTerm non défini si une erreur s'est produite) |
*.vb | Module WinTerm | la valeur de la propriété WinTerm.TermProc fait référence au processus du terminal d'hébergement ( Nothing ou exception si une erreur s'est produite) |
Il y a quelques années, Microsoft a commencé à développer une nouvelle application de terminal : Windows Terminal. L'installation est disponible pour Windows 10 et Windows 11 est déjà livré avec. Par une mise à jour d'octobre 22, Microsoft en a fait l'application de terminal par défaut sur Windows 11.
Désormais, Windows Terminal cohabite avec le bon vieux Conhost. Les utilisateurs peuvent choisir laquelle est utilisée comme application de terminal par défaut.
Dans le passé, il était facile de déterminer quel processus de terminal était connecté à l'application shell/console. Dans les coulisses, il s'agissait toujours de Conhost et donc, Microsoft a fait en sorte que l'API Windows signale le processus qui a engendré le processus conhost en tant que processus de terminal et signale la fenêtre de l'application shell en tant que fenêtre de console. Bien que tout cela soit techniquement incorrect, c’est en même temps assez confortable.
Cependant, aucune fonctionnalité pratique de ce type n’est implémentée pour le terminal Windows. Et si le terminal Windows est défini comme terminal par défaut, nous ne pouvons pas déduire de l'arborescence des processus quel processus de terminal communique avec notre processus shell.
À l’aide de Process Explorer, j’ai observé que le processus du terminal Windows dispose d’un handle vers le processus shell ouvert. En supposant que c'est toujours le cas, j'ai essayé d'écrire un morceau de code qui énumère tous les descripteurs ouverts à la recherche du bon descripteur de processus. Cela nécessite d'impliquer une API non documentée. J'ai laissé quelques commentaires dans le code qui expliquent grossièrement comment tout cela fonctionne.
Dans chaque fichier se trouve également un morceau de code sans rapport qui fait apparaître et disparaître la fenêtre. J’ai trouvé que c’était une manière impressionnante de prouver que le bon processus avait été trouvé. 
Ceci est une brève explication de la manière dont la recherche est implémentée dans les codes sources.
NtQuerySystemInformation est utilisée pour obtenir un instantané de tous les handles ouverts dans tous les processus en cours d'exécution. (Ceci n'est pas officiellement documenté.)
