Klassische Konsolen-APIs im Vergleich zu virtuellen Terminalsequenzen

Wir empfehlen, die klassische Windows-Konsolen-API durch virtuelle Terminalsequenzen zu ersetzen. In diesem Artikel wird der Unterschied zwischen den beiden erläutert und die Gründe für unsere Empfehlung erläutert.

Definitionen

Die klassische Windows-Konsolen-API-Oberfläche wird als die Reihe von C-Sprachfunktionsschnittstellen kernel32.dll mit "Console" im Namen definiert.

Virtuelle Terminalsequenzen werden als Eine Sprache von Befehlen definiert, die in den Standardeingabe- und Standardausgabedatenströmen eingebettet sind. Virtuelle Terminalsequenzen verwenden nicht druckbare Escapezeichen für Signalbefehle, die mit normalem druckbarem Text kombiniert sind.

Geschichte

Die Windows-Konsole bietet eine breite API-Oberfläche für Client-Befehlszeilenanwendungen, um sowohl den Ausgabeanzeigepuffer als auch den Benutzereingabepuffer zu bearbeiten. Nicht-Windows-Plattformen haben diesen spezifischen, API-gesteuerten Ansatz für ihre Befehlszeilenumgebungen jedoch nie übernommen. Stattdessen verwenden sie virtuelle Terminalsequenzen, die in den Standardeingabe- und Standardausgabestreams eingebettet sind. (Microsoft hat dieses Verhalten für eine Zeit auch in frühen Editionen von DOS und Windows über einen Treiber unterstützt, der als ANSI.SYS bezeichnet wird.)

Im Gegensatz dazu steuern virtuelle Terminalsequenzen (in einer Vielzahl von Dialekten) die Befehlszeilenumgebungsvorgänge für alle anderen Plattformen. Diese Sequenzen sind in einem ECMA-Standard verwurzelt und stammen aus einer Reihe von Erweiterungen, die von vielen Anbietern entwickelt wurden, und zurück bis auf Terminals von Digital Equipment Corporation und Tektronix gehen, bis hin zu moderneren und gängigeren Softwareterminals wie xterm. Viele Erweiterungen sind in der Domäne der virtuellen Terminalsequenz vorhanden, und einige Sequenzen werden häufiger unterstützt als andere, aber es ist sicher zu sagen, dass die Welt dies als Befehlssprache für Befehlszeilenerfahrungen mit einer bekannten Teilmenge standardisiert hat, die von praktisch jeder Terminal- und Befehlszeilenclientanwendung unterstützt wird.

Plattformübergreifender Support

Virtuelle Terminalsequenzen werden auf allen Plattformen nativ unterstützt, wodurch Terminalanwendungen und Befehlszeilenprogramme problemlos zwischen Versionen und Variationen von Betriebssystemen portiert werden können, mit Ausnahme von Windows.

Im Gegensatz dazu werden Windows-Konsolen-APIs nur unter Windows unterstützt. Eine umfangreiche Adapter- oder Übersetzungsbibliothek muss zwischen Windows und virtuellem Terminal geschrieben werden, oder umgekehrt, wenn Sie versuchen, Befehlszeilenprogramme von einer Plattform oder einer anderen zu portieren.

Remotezugriff

Virtuelle Terminalsequenzen haben einen großen Vorteil für den Remotezugriff. Sie erfordern keinen zusätzlichen Aufwand für den Transport oder zum Ausführen von Remote-Prozeduraufrufen als das, was zum Einrichten einer standardmäßigen Remote-Befehlszeilenverbindung erforderlich ist. Durch einfaches Verbinden eines ausgehenden und eines eingehenden Transportkanals (oder eines einzelnen bidirektionalen Kanals) über ein Rohr, Socket, Datei, serieller Port oder ein anderes Gerät reicht es aus, alle Informationen vollständig zu übertragen, die für eine Anwendung erforderlich sind, die diese Sequenzen an einen Remotehost spricht.

Im Gegensatz dazu sind die Windows-Konsolen-APIs nur auf dem lokalen Computer zugänglich, und alle Bemühungen, sie remote zu nutzen, erfordern die Erstellung einer gesamten Remoteanruf- und Transportschnittstellenschicht jenseits eines einfachen Kanals.

Trennung von Zuständigkeiten

Einige Windows-Konsolen-APIs bieten zugriff auf die Eingabe- und Ausgabepuffer auf niedriger Ebene oder Komfortfunktionen für interaktive Befehlszeilen. Dies kann Aliase und Befehlsverlauf enthalten, die innerhalb des Konsolensubsystems und der Hostumgebung programmiert sind, anstatt innerhalb der Befehlszeilenclientanwendung selbst.

Im Gegensatz dazu legen andere Plattformen die Speicherung des aktuellen Anwendungszustands und der benutzerfreundlichen Funktionen in die Verantwortung des Befehlszeilenhilfsprogramms oder der Shell selbst.

Die Windows Console-Methode zur Behandlung dieser Verantwortung im Konsolenhost und der API erleichtert das Schreiben einer Befehlszeilenanwendung mit diesen Features, wodurch die Verantwortung für das Merken des Zeichnungszustands oder die Bearbeitung von Komfortfeatures entfernt wird. Dies macht es jedoch aufgrund von Variationen in Implementierungen und Verfügbarkeit nahezu unmöglich, diese Aktivitäten remote über Plattformen, Versionen oder Szenarien hinweg zu verbinden. Diese Art der Verantwortungsbehandlung macht auch die endgültige interaktive Erfahrung dieser Windows-Befehlszeilenanwendungen vollständig abhängig von der Implementierung, Prioritäten und Releasezyklus des Konsolenhosts.

Beispielsweise sind erweiterte Zeilenbearbeitungsfeatures wie Syntaxmarkierung und komplexe Auswahl nur möglich, wenn eine Befehlszeilenanwendung Bearbeitungsaspekte selbst behandelt. Die Konsole konnte niemals genügend Kontext haben, um diese Szenarien umfassend zu verstehen, wie die Clientanwendung kann.

Im Gegensatz dazu verwenden andere Plattformen virtuelle Terminalsequenzen , um diese Aktivitäten und die virtuelle Terminalkommunikation selbst über wiederverwendbare clientseitige Bibliotheken wie Readline und Ncurses zu verarbeiten. Das endgültige Terminal ist nur für das Anzeigen von Informationen und empfangen von Eingaben über diesen bidirektionalen Kommunikationskanal verantwortlich.

Gegenläufige Verben

Mit der Windows-Konsole können einige Aktionen in entgegengesetzter und natürlicher Richtung für die Eingabe- und Ausgabedatenströme ausgeführt werden. Auf diese Weise können Windows-Befehlszeilenanwendungen die Verwaltung ihrer eigenen Puffer vermeiden. Darüber hinaus können Windows-Befehlszeilen-Anwendungen fortgeschrittene Vorgänge durchführen, z. B. das Simulieren/Einfügen von Eingaben für einen Benutzer oder das Zurücklesen einiger Teile der Geschichte des Geschriebenen.

Dies bietet zwar zusätzliche Leistungsfähigkeit für Windows-Anwendungen, die in einem bestimmten Benutzerkontext auf einem einzelnen Computer ausgeführt werden, bietet aber auch einen Vektor, um Sicherheits- und Berechtigungsstufen oder Domänen zu überschreiten, wenn sie in bestimmten Szenarien verwendet werden. Solche Szenarien umfassen das Arbeiten zwischen Kontexten auf demselben Computer oder kontextübergreifend mit einem anderen Computer oder einer anderen Umgebung.

Andere Plattformen, die virtuelle Terminalsequenzen verwenden, lassen diese Aktivität nicht zu. Die Absicht unserer Empfehlung, von der klassischen Windows-Konsole zu virtuellen Terminalsequenzen zu wechseln, ist es, mit dieser Strategie sowohl Interoperabilität als auch Sicherheitserwägungen zu verbinden.

Direkter Fensterzugriff

Die Windows Console API-Oberfläche liefert das genaue Fensterhandle für das Host-Fenster. Auf diese Weise kann ein Befehlszeilenprogramm erweiterte Fenstervorgänge ausführen, indem er in die breite Breite von Win32-APIs gelangt, die für ein Fensterhandle zulässig sind. Diese Win32-APIs können den Fensterzustand, den Frame, das Symbol oder andere Eigenschaften des Fensters bearbeiten.

Im Gegensatz dazu gibt es auf anderen Plattformen mit virtuellen Terminalsequenzen einen schmalen Satz von Befehlen, die für das Fenster ausgeführt werden können. Diese Befehle können z. B. das Ändern der Fenstergröße oder des angezeigten Titels ausführen, aber sie müssen in demselben Band und unter demselben Steuerelement wie der Rest des Datenstroms ausgeführt werden.

Während sich Windows weiterentwickelt hat, wurden die Sicherheitskontrollen und Einschränkungen für Fenstergriffelemente verschärft. Darüber hinaus haben sich die Art und das Vorhandensein eines anwendungsadressierbaren Fenster-Handles bei bestimmten Elementen der Benutzeroberfläche weiterentwickelt, insbesondere durch die erhöhte Unterstützung von Geräteformfaktoren und -plattformen. Dadurch wird der direkte Fensterzugriff auf Befehlszeilenanwendungen zerbrechlich, da sich die Plattform und die Erfahrungen weiterentwickeln.

Unicode

UTF-8 ist die akzeptierte Codierung für Unicode-Daten auf fast allen modernen Plattformen, da es das richtige Gleichgewicht zwischen Portabilität, Speichergröße und Verarbeitungszeit darstellt. Windows hat jedoch in der Vergangenheit UTF-16 als primäre Codierung für Unicode-Daten ausgewählt. Die Unterstützung für UTF-8 nimmt in Windows zu und die Verwendung dieser Unicode-Formate schließt die Verwendung anderer Codierungen nicht aus.

Die Windows-Konsolenplattform wird unterstützt und unterstützt weiterhin alle vorhandenen Codeseiten und Codierungen. Verwenden Sie UTF-16 für maximale Kompatibilität in Windows-Versionen und führen Sie ggf. eine algorithmische Übersetzung mit UTF-8 durch. Die Unterstützung von UTF-8 wird für das Konsolensystem gerade verbessert.

UTF-16-Unterstützung in der Konsole kann ohne zusätzliche Konfiguration über die W-Variante aller Konsolen-APIs verwendet werden und ist eine wahrscheinlichere Wahl für Anwendungen, die bereits in UTF-16 über die Kommunikation mit den wchar_t und W-Varianten anderer Funktionen und Produkte der Microsoft- und Windows-Plattform vertraut sind.

Die UTF-8-Unterstützung in der Konsole kann über die A-Variante von Konsolen-APIs für Konsolenhandles verwendet werden, nachdem die Codepage je nachdem mit der Methode 65001 oder CP_UTF8 auf oder festgelegt wurde. Das Festlegen der Codepages im Voraus ist nur erforderlich, wenn der Computer in den Einstellungen für Nicht-Unicode-Anwendungen im Abschnitt „Region“ der Systemsteuerung nicht die Option „Unicode UTF-8 für weltweite Sprachunterstützung verwenden“ ausgewählt hat.

Empfehlungen

Für alle neuen und fortlaufenden Entwicklungen unter Windows werden virtuelle Terminalsequenzen als Interaktionsweise mit dem Terminal empfohlen. Dadurch werden Windows-Befehlszeilenclientanwendungen mit dem Stil der Anwendungsprogrammierung auf allen anderen Plattformen zusammengeführt.

Ausnahmen für die Verwendung von Windows-Konsolen-APIs

Es ist weiterhin eine begrenzte Teilmenge der Windows-Konsolen-APIs erforderlich , um die anfängliche Umgebung einzurichten. Die Windows-Plattform unterscheidet sich immer noch von anderen im Prozess- und Signal-, Geräte- und Codierungshandling:

• Die Standardhandles für einen Prozess werden weiterhin mit GetStdHandle und SetStdHandle gesteuert.

• Die Konfiguration der Konsolenmodi für ein Handle, um sich für die Unterstützung von Virtual Terminal Sequence zu entscheiden, wird mit GetConsoleMode und SetConsoleMode behandelt.

• Die Deklaration der Codepage- oder UTF-8-Unterstützung wird mit setConsoleOutputCP - und SetConsoleCP-Methoden durchgeführt.

• Einige Ebenen der allgemeinen Prozessverwaltung sind möglicherweise mit allocConsole, AttachConsole und FreeConsole erforderlich, um einer Konsolengerätesitzung beizutreten oder zu verlassen.

• Signale und Signalbehandlung werden weiterhin mit SetConsoleCtrlHandler, HandlerRoutine und GenerateConsoleCtrlEvent durchgeführt.

• Die Kommunikation mit den Konsolengerätehandles kann mit WriteConsole und ReadConsole durchgeführt werden. Dies kann auch über Programmiersprachenlaufzeiten in form von: - C Runtime (CRT) genutzt werden: Stream-E/A wie Printf, Scanf, Putc, Getc oder andere Ebenen von E/A-Funktionen. - C++-Standardbibliothek (STL): iostream wie cout und cin. - .NET Runtime: System.Console wie Console.WriteLine.

• Anwendungen, die über Änderungen der Fenstergröße informiert sein müssen, müssen weiterhin ReadConsoleInput verwenden, um sie kombiniert mit Schlüsselereignissen zu empfangen, da ReadConsole alleine sie verwirft.

• Das Herausfinden der Fenstergröße muss weiterhin mit GetConsoleScreenBufferInfo für Anwendungen erfolgen, die versuchen, Spalten oder Raster zu zeichnen oder die Anzeige zu füllen. Die Fenster- und Puffergröße stimmen in einer Pseudoconsole-Sitzung überein.

Zukünftige Planung und Pseudoconsole

Es gibt keine Pläne, die Windows-Konsolen-APIs von der Plattform zu entfernen.

Im Gegenteil, der Windows-Konsolenhost hat die Pseudoconsole-Technologie bereitgestellt, um vorhandene Windows-Befehlszeilenanwendungsaufrufe in virtuelle Terminalsequenzen zu übersetzen und sie remote oder plattformübergreifend an eine andere Hostingumgebung weiterzuleiten.

Diese Übersetzung ist nicht perfekt. Sie erfordert, dass das Konsolenhostfenster eine simulierte Umgebung dessen aufrechterhält, was Windows dem Benutzer angezeigt hätte. Anschließend wird ein Replikat dieser simulierten Umgebung auf den Pseudoconsole-Host projiziert. Alle Aufrufe der Windows-Konsolen-API werden innerhalb der simulierten Umgebung ausgeführt, um die Anforderungen der älteren Befehlszeilenclientanwendung zu erfüllen. Nur die Effekte werden auf den endgültigen Host verteilt.

Eine Befehlszeilenanwendung, die volle Kompatibilität zwischen Plattformen und umfassende Unterstützung aller neuen Features und Szenarien sowohl unter Windows als auch auf anderen Plattformen wünscht, sollte daher zu virtuellen Terminalsequenzen wechseln und die Architektur von Befehlszeilenanwendungen so anpassen, dass sie mit allen Plattformen kompatibel ist.

Weitere Informationen zu diesem Windows-Übergang für Befehlszeilenanwendungen finden Sie in unserer Ökosystem-Roadmap.