Freigeben über


Roadmap für Die Windows-Konsole und das Terminalökosystem

Dieses Dokument ist eine allgemeine Roadmap der Windows-Konsolen- und Windows Terminal-Produkte. Es umfasst:

  • Wie Windows-Konsole und Windows-Terminal in das Ökosystem von Befehlszeilenanwendungen in Windows und anderen Betriebssystemen passen.

  • Eine Geschichte und zukünftige Roadmap der Produkte, Features und Strategien, die Teil des Aufbaus der Plattform sind, sowie das Erstellen dieser Plattform.

Der Fokus der aktuellen Konsolen-/Terminalära bei Microsoft besteht darin, Entwicklern auf der Windows-Plattform eine erstklassige Terminalerfahrung zu bieten und klassische Windows-Konsolen-APIs auslaufen zu lassen und sie durch virtuelle Terminalsequenzen mithilfe von Pseudoconsole zu ersetzen. Windows Terminal zeigt diesen Übergang in eine erstklassige Erfahrung, lädt die Open Source-Zusammenarbeit aus der Entwicklercommunity ein, unterstützt ein umfassendes Spektrum an Mischen und Abgleich von Clientbefehls- und Terminalhostinganwendungen und die Vereinheitlichung des Windows-Ökosystems mit allen anderen Plattformen.

Definitionen

Es wird empfohlen, sich mit den Definitionen allgemeiner Terminologie vertraut zu machen, die in diesem Bereich verwendet werden, bevor Sie fortfahren. Allgemeine Terminologie umfasst: Befehlszeilenanwendungen (oder Konsolenanwendungen),Standardhandles (STDIN, STDOUT, STDERR), TTY- und PTY-Geräte, Clients und Server, Konsolensubsystem, Konsolenhost, Pseudoconsole und Terminal.

Architektur

Die allgemeine Architektur des Systems besteht aus vier Teilen: Client, Gerät, Server und Terminal.

Kommunikationsflussdiagramm von der Befehlszeile von der Quelle zum Ziel, das vom Client über das Gerät zum Server zum Terminal läuft

Kunde

Der Client ist eine Befehlszeilenanwendung, die eine textbasierte Schnittstelle verwendet, um dem Benutzer die Eingabe von Befehlen (anstelle einer mausbasierten Benutzeroberfläche) zu ermöglichen, um eine Textdarstellung des Ergebnisses zurückzugeben. Unter Windows stellt die Konsolen-API eine Kommunikationsschicht zwischen dem Client und dem Gerät bereit. (Dies kann auch ein Standard-Konsolen-Handle mit einer API für die Gerätesteuerung sein).

Gerät

Das Gerät ist eine zwischengeschaltete Kommunikationsschicht für die Nachrichtenverarbeitung zwischen zwei Prozessen, dem Client und dem Server. Unter Windows ist dies der Konsolentreiber. Auf anderen Plattformen ist es das TTY- oder PTY-Gerät. Andere Geräte wie Dateien, Rohre und Sockets können als dieser Kommunikationskanal verwendet werden, wenn sich die gesamte Transaktion in Nur-Text befindet oder virtuelle Terminalsequenzen enthält, jedoch nicht mit Windows-Konsolen-APIs.

Server

Der Server interpretiert die angeforderten API-Aufrufe oder -Nachrichten vom Client. Unter Windows im klassischen Betriebsmodus erstellt der Server auch eine Benutzeroberfläche, um die Ausgabe auf dem Bildschirm darzustellen. Der Server sammelt darüber hinaus Eingaben, um sie über den Treiber, wie z. B. ein Terminal, das im selben Modul gebündelt ist, in Antwortnachrichten an den Client zurückzusenden. Im Pseudoconsole-Modus ist es stattdessen nur ein Übersetzer, um diese Informationen in virtuellen Terminalsequenzen an einem angefügten Terminal darzustellen.

Endgerät

Das Terminal ist die letzte Ebene, die dem Benutzer grafische Anzeige- und Interaktivitätsdienste bereitstellt. Es ist verantwortlich für die Erfassung und Codierung von Eingaben als virtuelle Terminalsequenzen, die schließlich den Client erreichen STDIN. Sie wird auch die virtuellen Terminalsequenzen empfangen und decodieren, die sie vom Client STDOUT für die Präsentation auf dem Bildschirm erhält.

Weitere Verbindungen

Als Zusatz können weitere Verbindungen durch Verketten von Anwendungen ausgeführt werden, die mehrere Rollen in einem der Endpunkte bereitstellen. Beispielsweise verfügt eine SSH-Sitzung über zwei Rollen: Es handelt sich um ein Terminal für die Befehlszeilenanwendung, die auf einem Gerät ausgeführt wird, aber sie leitet alle empfangenen Informationen an eine Clientrolle auf einem anderen Gerät weiter. Diese Verkettung kann unbegrenzt auf allen Geräten und Kontexten auftreten, die eine breite Szenarioflexibilität bieten.

Auf Nicht-Windows-Plattformen sind die Server - und Terminalrollen eine einzige Einheit, da keine Übersetzungskompatibilitätsschicht zwischen api-Sätze und virtuellen Terminalsequenzen erforderlich ist.

Microsoft-Produkte

Alle Microsoft Windows-Befehlszeilenprodukte sind jetzt auf GitHub in einem Open Source-Repository, Microsoft/Terminal, verfügbar.

Windows-Konsolenhost

Dies ist die herkömmliche Windows-Benutzeroberfläche für Befehlszeilenanwendungen. Er behandelt alle Konsolen-API-Wartungen, die von einer angefügten Befehlszeilenanwendung aufgerufen werden. Die Windows-Konsole behandelt auch die grafische Darstellung der Benutzeroberfläche (GUI) im Auftrag aller dieser Anwendungen. Es befindet sich im Systemverzeichnis als conhost.exe, oder openconsole.exe in seiner Open Source-Form. Es ist im Lieferumfang des Windows-Betriebssystems vorhanden. Sie finden sie auch in anderen Microsoft-Produkten, die aus dem Open Source-Repository für eine mehr up-to-Date-Implementierung der Pseudoconsole-Infrastruktur erstellt wurden. Gemäß den oben genannten Definitionen wird sie entweder in einer kombinierten Server- und Terminalrolle traditionell oder in einer servergeschützten Rolle über die bevorzugte Pseudoconsole-Infrastruktur ausgeführt.

Windows-Terminal

Dies ist die neue Windows-Schnittstelle für Befehlszeilenanwendungen. Windows Terminal dient als Erstanbieterbeispiel für die Verwendung der Pseudoconsole, um die Verantwortungsbereiche zwischen der API-Wartung und der textbasierten Anwendungsschnittstelle zu trennen, ähnlich wie bei nicht-Windows-Plattformen.

Windows Terminal ist die Flaggschiff-Textmodus-Benutzeroberfläche für Windows. Es veranschaulicht die Fähigkeiten des Ökosystems und steuert die Windows-Entwicklung zur Vereinheitlichung mit anderen Plattformen. Windows Terminal ist auch ein Beispiel für das Erstellen einer robusten und komplexen modernen Anwendung, die den Verlauf und die Gamut von Windows-APIs und -Frameworks umfasst. Gemäß den oben genannten Definitionen arbeitet dieses Produkt in einer Terminalrolle.

Wichtige historische Meilensteine

Die wichtigsten historischen Meilensteine für das Konsolensubsystem werden in die Implementierung vor 2014 und dann in einen Überblick über die seit 2014 ausgeführten Arbeiten aufgeteilt, als der erneuerte Fokus auf die Befehlszeile in der Windows 10-Ära gelegt wurde.

Erstimplementierung

[1989-1990s] Das erste Konsolenhostsystem wurde als Emulation der DOS-Umgebung innerhalb des Windows-Betriebssystems implementiert. Der Code ist mit der Eingabeaufforderung verflochten und kooperiert, cmd.exe was eine Repräsentation dieser DOS-Umgebung ist. Der Konsolenhost-Systemcode teilt die Verantwortlichkeiten und Berechtigungen mit dem Kommandozeileninterpreter und der Shell. Sie stellt auch eine Basisebene von Diensten für andere Befehlszeilenhilfsprogramme bereit, um Dienste auf CMD-ähnliche Weise auszuführen.

DBCS für CJK

[1997-1999] Derzeit wird die DBCS-Unterstützung ("Double-byte character set") eingeführt, um die CJK-Märkte (Chinesisch, Japanisch und Koreanisch) zu unterstützen. Dieser Aufwand führt zu einer Bifurcation vieler der Schreib- und Lesemethoden innerhalb der Konsole, um sowohl westliche Versionen für die Behandlung von Einzelbytezeichen als auch eine alternative Darstellung für "östliche" Versionen bereitzustellen, bei denen zwei Byte erforderlich sind, um das große Array von Zeichen darzustellen. Diese Verzweigung umfasste die erweiterte Darstellung einer Zelle in der Konsolumgebung, sodass sie entweder 1 oder 2 Zellen breit sein konnte, wobei 1 Zelle schmal ist (höher als breit) und 2 Zellen breit, vollbreit oder ein Quadrat sind, in dem typische chinesische, japanische und koreanische Ideographen eingeschrieben werden können.

Sicherheit/Isolation

[2005-2009] Mit der Konsolensubsystemerfahrung, die innerhalb des kritischen Systemprozesses ausgeführt wird, csrss.exewurde die Verbindung von sortierten Clientanwendungen auf unterschiedlichen Zugriffsebenen mit einem einzigen superkritischen und privilegierten Prozess als besonders gefährlich erkannt. In diesem Zeitalter wurde das Konsolensubsystem in Client-, Treiber- und Serveranwendungen aufgeteilt. Jede Anwendung kann in ihrem eigenen Kontext ausgeführt werden, wodurch die Verantwortlichkeiten und Berechtigungen in den einzelnen Anwendungen reduziert werden. Diese Isolation erhöhte die allgemeine Stabilität des Systems, da alle Fehler im Konsolensubsystem andere kritische Prozessfunktionen nicht mehr beeinträchtigten.

Verbesserungen bei der Benutzererfahrung

[2014-2016] Nach einer langen Zeit der generell verteilten Wartung des Konsolensubsystems durch sortierte Teams in der gesamten Organisation wurde ein neues entwicklerorientiertes Team gebildet, um Verbesserungen in der Konsole zu besitzen und zu fördern. Zu diesem Zeitpunkt wurden Verbesserungen vorgenommen: Linienauswahl, reibungsloses Ändern der Fenstergröße, Textumfluss, Kopieren und Einfügen, Unterstützung für hochauflösende DPI und ein Fokus auf Unicode, einschließlich der Konvergenz der Aufteilung zwischen "westlicher" und "östlicher" Speicher- und Datenstrommanipulationsalgorithmen.

Virtueller Terminal-Client

[2015-2017] Mit der Einführung des Windows-Subsystems für Linux, den Bemühungen von Microsoft, die Nutzung von Docker auf Windows zu verbessern, und der Übernahme von OpenSSH als führender Befehlszeilen-Remoteausführungstechnologie wurden die ersten Implementierungen von virtuellen Terminalsequenzen in den Konsolenhost integriert. Dadurch kann die vorhandene Konsole als Terminal fungieren, direkt an die Linux-nativen Anwendungen in ihren jeweiligen Umgebungen angefügt, grafische und Textattribute an die Anzeige gerendert und Benutzereingaben im entsprechenden Dialekt zurückgegeben werden.

Virtueller Terminalserver

[2018] In den letzten zwanzig Jahren wurden von Drittanbietern Alternativen für den Posteingangs-Konsolenhost entwickelt, um zusätzliche Produktivität für Entwickler zu bieten, mit starkem Fokus auf reiche Anpassungen und Registerkartenschnittstellen. Diese Anwendungen müssen weiterhin ausgeführt werden und das Konsolenhostfenster muss versteckt sein. Sie werden als sekundäre Clientanwendung verwendet, um Pufferinformationen in Abrufschleifen auszulesen, während die primäre Befehlszeilen-Clientanwendung läuft. Ihr Ziel war es, ein Terminal zu sein, wie auf anderen Plattformen, aber in der Windows-Welt, in der Terminals nicht austauschbar waren.

In diesem Zeitraum wurde die Pseudoconsole-Infrastruktur eingeführt. Pseudoconsole ermöglicht es jeder Anwendung, den Konsolenhost in einem nicht interaktiven Modus zu starten und die endgültige Terminalschnittstelle für den Benutzer zu werden. Die Haupteinschränkung in diesem Aufwand war die fortgesetzte Kompatibilitätszusage von Windows bei der Wartung aller veröffentlichten Windows-Konsolen-APIs für die unbestimmte Zeit, während eine Ersatz-Serverhosting-Schnittstelle bereitgestellt wurde, die den Erwartungen auf allen anderen Plattformen entspricht: virtuelle Terminalsequenzen. In diesem Sinne hat dieser Vorgang das Spiegelbild der Clientphase ausgeführt: Die Pseudoconsole projiziert auf den Bildschirm, was als virtuelle Terminalsequenzen für einen delegierten Host angezeigt wird, und interpretiert Antworten in Windows-Format-Eingabesequenzen für die Nutzung durch Clientanwendungen.

Roadmap für die Zukunft

Terminalanwendungen

[2019-Now] Dies ist die Open Source-Ära für das Konsolensubsystem, das sich auf das neue Windows Terminal konzentriert. Während der Microsoft Build-Konferenz im Mai 2019 angekündigt, befindet sich Windows Terminal vollständig auf GitHub bei Microsoft/Terminal. Das Erstellen der Windows-Terminal-Anwendung auf der optimierten Plattform für Pseudoconsole ist der Schwerpunkt dieser Ära und bietet Entwicklern auf der Windows-Plattform eine erstklassige Terminalerfahrung.

Windows Terminal beabsichtigt nicht nur, die Plattform – einschließlich der WinUI-Schnittstellentechnologie , des MSIX-Verpackungsmodells und der C++/WinRT-Komponentenarchitektur – zu präsentieren, sondern auch als Validierung der Plattform selbst. Windows Terminal treibt die Windows-Organisation dazu, die App-Plattform nach Bedarf zu öffnen und zu entwickeln, um die Produktivität von Entwicklern weiter zu steigern. Die einzigartigen Windows-Terminal-Anforderungen für Power User und Entwickler fördern die modernen Windows-Plattformanforderungen für das, was diese Märkte wirklich von Windows benötigen.

Innerhalb des Windows-Betriebssystems schließt dies die Einstellung der klassischen Konsolenhost-Benutzeroberfläche von ihrer Standardposition zugunsten von Windows Terminal, ConPTY und virtuellen Terminalsequenzen ein.

Schließlich beabsichtigt diese Ära, die vollständige Auswahl über die Standarderfahrung zu bieten, unabhängig davon, ob es sich um das Windows Terminal-Produkt oder um alternative Terminals handelt.

Client-Support-Bibliothek

[Zukunft] Mit der Unterstützung und Dokumentation virtueller Terminalsequenzen auf clientseitiger Seite empfehlen wir Windows-Befehlszeilenprogrammentwicklern dringend, virtuelle Terminalsequenzen zuerst über die klassischen Windows-APIs zu verwenden, um den Vorteil eines einheitlichen Ökosystems mit allen Plattformen zu erzielen. Ein signifikanter fehlender Bestandteil ist jedoch, dass andere Plattformen über eine breite Palette von clientseitigen Hilfsbibliotheken für die Behandlung von Eingaben wie Readline und grafische Anzeige wie Ncurses verfügen. Dieses spezielle zukünftige Road map-Element stellt die Erforschung des Angebots des Ökosystems dar und wie wir die Einführung virtueller Terminalsequenzen in Windows-Befehlszeilenanwendungen über die klassische Konsolen-API beschleunigen können.

Sequenzpassthrough

[Zukunft] Die Kombination aus virtuellen Terminalclient- und Serverimplementierungen ermöglicht das vollständige Mischen und Abgleichen von Client-Befehlszeilen- und Terminalhostinganwendungen. Diese Kombination kann entweder mit den klassischen Windows-Konsolen-APIs oder virtuellen Terminalsequenzen sprechen, es gibt jedoch einen Aufwand, um dies in die klassische kompatible Windows-Methode und dann wieder in die universellere virtuelle Terminalmethode zu übersetzen.

Sobald der Markt ausreichend virtuelle Terminalsequenzen und UTF-8 unter Windows verwendet, kann der Konvertierungs-/Interpretationsauftrag des Konsolenhosts optional deaktiviert werden. Der Konsolenhost würde dann zu einem einfachen API-Aufrufdienst werden, der die Aufrufe von Geräten über die Pseudoconsole an die Hostinganwendung weiterleitet. Diese Änderung erhöht die Leistung und maximiert den Dialekt der Sequenzen, die zwischen der Clientanwendung und dem Terminal gesprochen werden können. Durch diese Änderung würden zusätzliche Interaktivitätsszenarien aktiviert und (schließlich) die Windows-Welt an die Familie aller anderen Plattformen im Befehlszeilenanwendungsbereich angepasst.