termproc

---

---

WICHTIG

Dieser Code ist veraltet!

Das neue Prozessmodell von Windows Terminal Version 1.18 erfordert einen anderen Ansatz.
Die neue Implementierung finden Sie unter https://github.com/german-one/termwnd.

---

---

TermProc

Der Zweck des Codes in diesem Repository besteht sowohl darin, zwischen Conhost- und Windows-Terminalprozessen zu unterscheiden als auch zu bestimmen, welche Terminalinstanz mit dem aktuellen Konsolenprozess verbunden ist. Terminal-Apps von Drittanbietern werden nicht unterstützt.
Bei den Quelldateien handelt es sich um Transkriptionen nahezu desselben Kerncodes in verschiedenen Programmiersprachen.

Mindestanforderungen zum Kompilieren/Ausführen des Codes:

Quelldateien in Windows Batch , C , C++ , C#.Net , PowerShell und VB.Net werden im Ordner src veröffentlicht. Sie alle hängen davon ab, dass Windows das Zielbetriebssystem ist. Weitere spezifische Abhängigkeiten sind unten aufgeführt.

Datei	Erfordernis
*.bat	Windows PowerShell 2
*.c	C99
*.cpp	C++20
*.cs	.NET Framework 4.5
*.ps1	Windows PowerShell 2
*.vb	.NET Framework 4.5

Relevanter Code:

Die Quelldateien in diesem Repository enthalten voll funktionsfähigen Code, der die Verwendung des Suchverfahrens demonstriert. Wenn Sie es jedoch in Ihrem eigenen Code verwenden möchten, kann es hilfreich sein zu wissen, welche wesentlichen Codeteile Sie einschließen müssen.

Datei	Interessenkodex	Wert des Interesses
*.bat	TermPid Makro, definiert in der Routine :init_TermPid	Die vom TermPid Makro zurückgegebene Fehlerstufe ist die PID des Hosting-Terminals ( 0 , wenn ein Fehler aufgetreten ist).
*.c	GetTermPid Funktion, zusammen mit der Struktur SYSTEM_HANDLE und den Funktionen GetProcBaseName , GetPidOfNamedProcWithOpenProcHandle	Der von der GetTermPid -Funktion zurückgegebene Wert ist die PID des Hosting-Terminals ( 0 wenn ein Fehler aufgetreten ist).
*.cpp	alles im Namespace termpid , zusammen mit dem Namespace saferes und der Funktion GetProcBaseName	Der von der GetTermPid -Funktion zurückgegebene Wert ist die PID des Hosting-Terminals ( 0 oder Ausnahme, wenn ein Fehler aufgetreten ist).
*.cs	Klasse WinTerm	Der Wert der Eigenschaft WinTerm.TermProc bezieht sich auf den Hosting-Terminalprozess ( null oder Ausnahme, wenn ein Fehler aufgetreten ist).
*.ps1	Geben Sie die referenzierende Klasse WinTerm	Der Wert der Eigenschaft [WinTerm]::TermProc bezieht sich auf den Hosting-Terminalprozess ( $null oder Typ WinTerm nicht definiert, wenn ein Fehler aufgetreten ist)
*.vb	Modul WinTerm	Der Wert der Eigenschaft WinTerm.TermProc bezieht sich auf den Hosting-Terminalprozess ( Nothing oder Ausnahme, wenn ein Fehler aufgetreten ist).

Hintergrund:

Vor einigen Jahren begann Microsoft mit der Entwicklung einer neuen Terminalanwendung – Windows Terminal. Die Installation ist für Windows 10 verfügbar, Windows 11 wird bereits mitgeliefert. Durch ein Update im Oktober 2022 machte Microsoft es zur Standard-Terminal-App unter Windows 11.
Ab sofort existiert Windows Terminal neben dem guten alten Conhost. Benutzer können auswählen, welche Terminal-App als Standardanwendung verwendet werden soll.

In der Vergangenheit war es einfach herauszufinden, welcher Terminalprozess mit der Shell-/Konsolenanwendung verbunden ist. Hinter den Kulissen war es immer Conhost und daher hat Microsoft dafür gesorgt, dass die Windows-API den Prozess, der den Conhost-Prozess erzeugte, als Terminalprozess meldete und das Fenster der Shell-Anwendung als Konsolenfenster meldete. Obwohl das alles technisch falsch ist, ist es gleichzeitig recht komfortabel.
Für das Windows-Terminal ist jedoch keine solche Komfortfunktionalität implementiert. Und wenn Windows Terminal als Standardterminal festgelegt ist, können wir aus dem Prozessbaum nicht ableiten, welcher Terminalprozess mit unserem Shell-Prozess kommuniziert.

Beim Verwenden des Process Explorers habe ich festgestellt, dass der Windows-Terminalprozess über ein Handle für den geöffneten Shell-Prozess verfügt. Unter der Annahme, dass dies immer der Fall ist, habe ich versucht, einen Code zu schreiben, der alle offenen Handles auflistet und nach dem richtigen Prozesshandle sucht. Dies erfordert die Einbeziehung einer undokumentierten API. Ich habe im Code ein paar Kommentare hinterlassen, die grob erklären, wie das alles funktioniert.

In jeder Datei befindet sich auch ein unabhängiger Code, der das Fenster aus- und wieder einblendet. Für mich war es ein eindrucksvoller Beweis dafür, dass der richtige Prozess gefunden wurde.

Suchvorgang:

Dies ist eine kurze Erklärung, wie die Suche in den Quellcodes implementiert ist.

1. Bestimmen Sie das Handle für das Konsolenfenster.
2. Versuchen Sie, das Symbol zu erhalten.
   • Wenn wir ein gültiges Handle erhalten haben, läuft unsere Anwendung in einem Conhost-Fenster und wir geben die PID des Prozesses zurück, für den das Fenster erstellt wurde. (Die Windows-API hat eine spezielle Schreibweise, um den gehosteten Prozess als Eigentümer des Fensters und nicht den Conhost-Prozess selbst zu behandeln.)
   • Wenn das Handle ein Nullzeiger ist, gehen wir davon aus, dass das Conhost-Fenster ausgeblendet ist (ConPTY), und wir müssen mit der Suche unter der Annahme fortfahren, dass Windows Terminal unsere Anwendung hostet.
3. Die NtQuerySystemInformation -API-Funktion wird verwendet, um eine Momentaufnahme aller offenen Handles in allen laufenden Prozessen zu erhalten. (Dies ist nicht offiziell dokumentiert.)
   • Die Informationen werden als Array von Strukturen bereitgestellt, die den Typ des geöffneten Handles, die PID des Prozesses, der das Handle geöffnet hat, und ein Pseudo-Handle enthalten, das das geöffnete Handle identifiziert (zusammen mit weiteren Informationen, die wir nicht verwenden).
4. Durchlaufen Sie das Array in einer Schleife.
   • Fahren Sie mit der nächsten Struktur fort, wenn der Typ des offenen Griffs nicht dem von uns gesuchten Typ entspricht.
   • Duplizieren Sie das Pseudo-Handle. Fahren Sie mit der nächsten Struktur fort, wenn das duplizierte Handle und das Handle für die Anwendung, die das ausgeblendete Konsolenfenster besitzt, nicht auf dasselbe Kernelobjekt verweisen.
   • Rufen Sie den Namen des Prozesses ab, der das Handle geöffnet hat. Fahren Sie mit der nächsten Struktur fort, wenn der Name nicht „WindowsTerminal“ lautet.
   • Geben Sie entweder die PID des gefundenen „WindowsTerminal“-Prozesses oder 0 zurück, wenn wir ihn nicht gefunden haben.