Feuille de route de la console Windows et de l’écosystème terminal

Ce document est une feuille de route générale des produits de la console Windows et du terminal Windows. Il couvre :

• Comment la console Windows et le terminal Windows s’intègrent dans l’écosystème d’applications en ligne de commande entre Windows et d’autres systèmes d’exploitation.

• Historique et feuille de route future des produits, fonctionnalités et stratégies qui font partie de la création de la plateforme, ainsi que de la création pour cette plateforme.

L’objectif de l’ère actuelle de console/terminal chez Microsoft est d’apporter une expérience de terminal de première classe directement aux développeurs sur la plateforme Windows et de sortir progressivement les API de console Windows classiques, en les remplaçant par des séquences de terminal virtuel utilisant la pseudoconsole. Le terminal Windows présente cette transition vers une expérience de première classe, invitant la collaboration open source de la communauté des développeurs, prenant en charge un éventail complet de mélange et de correspondance des applications d’hébergement de ligne de commande et de terminal client, et unifiant l’écosystème Windows avec toutes les autres plateformes.

Définitions

Il est recommandé de vous familiariser avec les définitions de terminologie courante utilisée dans cet espace avant de continuer. La terminologie courante inclut les applications de ligne de commande (ou console),les handles standard (STDIN, , STDOUTSTDERR) , les appareils TTY et PTY, les clients et les serveurs, le sous-système de console, l’hôte de console, la pseudoconsole et le terminal.

Architecture

L’architecture générale du système se trouve en quatre parties : client, appareil, serveur et terminal.

Client

Le client est une application en ligne de commande qui utilise une interface basée sur du texte pour permettre à l’utilisateur d’entrer des commandes (plutôt qu’une interface utilisateur basée sur la souris), renvoyant une représentation textuelle du résultat. Sur Windows, l’API console fournit une couche de communication entre le client et l’appareil. (Il peut également s’agir d’un handle de console standard avec des API de contrôle d’appareil).

Appareil

L’appareil est une couche de communication intermédiaire de gestion des messages entre deux processus, le client et le serveur. Sur Windows, il s’agit du pilote de console. Sur d’autres plateformes, il s’agit de l’appareil TTY ou PTY. D’autres appareils tels que des fichiers, des canaux et des sockets peuvent être utilisés comme canal de communication si l’intégralité de la transaction est en texte brut ou contient des séquences de terminal virtuel, mais pas avec les API de console Windows.

Serveur

Le serveur interprète les appels ou messages d’API demandés à partir du client. Sur Windows en mode d’exploitation classique, le serveur crée également une interface utilisateur pour présenter la sortie à l’écran. Le serveur collecte également les entrées pour renvoyer des messages de réponse au client, par le biais du pilote, comme un terminal groupé dans le même module. En utilisant le mode pseudoconsole , il s’agit plutôt d’un traducteur pour présenter ces informations dans des séquences de terminal virtuel vers un terminal attaché.

Aérogare

Le terminal est la couche finale qui fournit des services graphiques d’affichage et d’interactivité à l’utilisateur. Il est chargé de capturer l’entrée et de l’encoder STDINen tant que séquences de terminal virtuel, qui atteignent finalement le client. Il recevra également et décodera les séquences de terminal virtuel qu’elle reçoit de la présentation du STDOUT client à l’écran.

Autres connexions

En tant qu’addenda, d’autres connexions peuvent être effectuées en chaînant des applications qui servent plusieurs rôles dans l’un des points de terminaison. Par exemple, une session SSH a deux rôles : il s’agit d’un terminal pour l’application en ligne de commande s’exécutant sur un appareil, mais elle transfère toutes les informations reçues sur un rôle client sur un autre appareil. Ce chaînage peut se produire indéfiniment entre les appareils et les contextes offrant une grande flexibilité de scénario.

Sur les plateformes non-Windows, les rôles serveur et terminal sont une unité unique, car il n’est pas nécessaire d’utiliser une couche de compatibilité de traduction entre un ensemble d’API et des séquences de terminal virtuel.

Produits Microsoft

Tous les produits de ligne de commande Microsoft Windows sont désormais disponibles sur GitHub dans un référentiel open source, microsoft/terminal.

Hôte de console Windows

Il s’agit de l’interface utilisateur Windows traditionnelle pour les applications en ligne de commande. Il gère toutes les maintenances de l’API de console appelées à partir de n’importe quelle application de ligne de commande attachée. La console Windows gère également la représentation de l’interface utilisateur graphique (GUI) au nom de toutes ces applications. Il se trouve dans le répertoire système en tant que conhost.exe, ou openconsole.exe dans son formulaire open source. Il est fourni avec le système d’exploitation Windows. Il se trouve également dans d’autres produits Microsoft créés à partir du référentiel open source pour une implémentation plus up-to-date de l’infrastructure pseudoconsole . Selon les définitions ci-dessus, il fonctionne dans un rôle serveur et terminal combiné traditionnellement ou un rôle serveur uniquement via l’infrastructure pseudoconsole préférée.

Windows Terminal

Il s’agit de la nouvelle interface Windows pour les applications en ligne de commande. Le terminal Windows sert d’exemple de premier plan d’utilisation de la pseudoconsole pour séparer les problèmes entre la maintenance de l’API et l’interfacing d’application basée sur du texte, comme toutes les plateformes non-Windows.

Le terminal Windows est l’interface utilisateur en mode texte phare pour Windows. Il illustre les fonctionnalités de l’écosystème et dirige le développement Windows vers l’unification avec d’autres plateformes. Le terminal Windows est également un exemple de création d’une application moderne robuste et complexe qui couvre l’historique et la gamme des API et infrastructures Windows. Selon les définitions ci-dessus, ce produit fonctionne dans un rôle de terminal.

Jalons historiques majeurs

Les principaux jalons historiques du sous-système de console sont divisés en implémentation avant 2014, puis passent à une vue d’ensemble du travail effectué depuis 2014, lorsque le focus renouvelé sur la ligne de commande a été formé dans l’ère Windows 10.

Implémentation initiale

[1989-1990] Le système hôte de la console initiale a été implémenté comme émulation de l’environnement DOS au sein du système d’exploitation Windows. Son code est enchevêtré et coopératif avec l’invite de commandes, cmd.exequi est une représentation de cet environnement DOS. Le code du système hôte de la console partage les responsabilités et les privilèges avec l’interpréteur/interpréteur d’invite de commandes. Il fournit également un niveau de base de services pour d’autres utilitaires de ligne de commande afin d’effectuer des services de manière de type CMD.

DBCS pour CJK

[1997-1999] Autour de cette époque, la prise en charge de DBCS (« Jeu de caractères double octets ») est introduite pour prendre en charge les marchés CJK (chinois, japonais et coréen). Cet effort entraîne une bifurcation de la plupart des méthodes d’écriture et de lecture à l’intérieur de la console pour fournir à la fois des versions « occidentales » pour traiter les caractères d’un octet, ainsi qu’une représentation alternative pour les versions « orientales » où deux octets sont nécessaires pour représenter le vaste tableau de caractères. Cette bifurcation comprenait la représentation croissante d’une cellule dans l’environnement de console à 1 ou 2 cellules larges, où 1 cellule est étroite (plus grande qu’elle est large) et 2 cellules sont larges, pleine largeur ou autrement un carré dans lequel les idéogrammes typiques chinois, japonais et coréen peuvent être inscrits.

Sécurité/isolation

[2005-2009] Avec l’expérience du sous-système de console s’exécutant à l’intérieur du processus système critique, csrss.exela connexion d’applications clientes assorties, à différents niveaux d’accès, à un seul processus super critique et privilégié a été remarqué comme particulièrement dangereux. Dans cette époque, le sous-système de console a été divisé en applications client, pilote et serveur. Chaque application peut s’exécuter dans son propre contexte, ce qui réduit les responsabilités et les privilèges dans chacun d’eux. Cette isolation a augmenté la robustesse générale du système, car toute défaillance dans le sous-système de console n’a plus affecté d’autres fonctionnalités de processus critiques.

Améliorations apportées à l’expérience utilisateur

[2014-2016] Après une longue période de maintenance généralement dispersée du sous-système de la console par des équipes réparties au sein de l’organisation, une nouvelle équipe axée sur les développeurs a été formée pour posséder et améliorer la console. Les améliorations apportées au cours de cette période sont les suivantes : sélection de ligne, redimensionnement de fenêtre lisse, reflowage de texte, copie et collage, prise en charge élevée de ppp et focus sur Unicode, notamment la convergence du fractionnement entre les algorithmes de manipulation de flux et de stockage « occidentaux » et « est ».

Client de terminal virtuel

[2015-2017] Avec l’arrivée du sous-système Windows pour Linux, Microsoft s’efforce d’améliorer l’expérience de Docker sur Windows et l’adoption d’OpenSSH comme technologie d’exécution à distance de ligne de commande premier, les implémentations initiales des séquences de terminal virtuel ont été introduites dans l’hôte de console. Cela a permis à la console existante d’agir en tant que terminal, attachée directement à ces applications natives Linux dans leurs environnements respectifs, de restituer des attributs graphiques et de texte à l’affichage et de retourner l’entrée utilisateur dans le dialecte approprié.

Serveur terminal virtuel

[2018] Au cours des vingt dernières années, des alternatives tierces pour l’hôte de console de boîte de réception ont été créées pour offrir une productivité supplémentaire aux développeurs, centrée principalement sur les personnalisations enrichies et les interfaces à onglets. Ces applications sont toujours nécessaires pour exécuter et masquer la fenêtre hôte de la console. Ils s’attachent en tant qu’application « cliente » secondaire pour extraire les informations de mémoire tampon dans les boucles d’interrogation en tant qu’application cliente de ligne de commande principale exploitée. Leur objectif était d’être un terminal, comme sur d’autres plateformes, mais dans le monde Windows où les terminaux n’étaient pas remplaçables.

Pendant cette période, l’infrastructure pseudoconsole a été introduite. Pseudoconsole permet à toute application de lancer l’hôte de console en mode non interactif et de devenir l’interface finale du terminal pour l’utilisateur. La principale limitation de cet effort était la promesse de compatibilité continue de Windows dans la maintenance de toutes les API de console Windows publiées pour l’avenir indéfini, tout en fournissant une interface d’hébergement de serveur de remplacement qui correspond à ce qui est attendu sur toutes les autres plateformes : séquences de terminal virtuel. Par conséquent, cet effort a effectué l’image miroir de la phase cliente : le pseudoconsole projette ce qui serait affiché sur l’écran en tant que séquences de terminal virtuel pour un hôte délégué et interprète les réponses en séquences d’entrée au format Windows pour la consommation de l’application cliente.

Feuille de route pour l’avenir

Applications terminales

[2019-Now] Il s’agit de l’ère open source pour le sous-système de console, en mettant l’accent sur le nouveau terminal Windows. Annoncé lors de la conférence Microsoft Build en mai 2019, le terminal Windows est entièrement sur GitHub sur microsoft/terminal. La création de l’application Terminal Windows sur la plateforme affinée pour pseudoconsole sera l’objectif de cette ère, apportant une expérience de terminal de première classe directement aux développeurs sur la plateforme Windows.

Le terminal Windows a l’intention non seulement de présenter la plateforme, notamment la technologie d’interface WinUI , le modèle d’empaquetage MSIX et l’architecture des composants C++/WinRT , mais également comme validation de la plateforme elle-même. Le terminal Windows permet à l’organisation Windows d’ouvrir et d’évoluer la plateforme d’applications si nécessaire pour continuer à augmenter la productivité des développeurs. L’ensemble unique du terminal Windows pour les utilisateurs et les développeurs alimente les exigences de plateforme Windows modernes pour ce que ces marchés ont vraiment besoin de Windows.

Dans le système d’exploitation Windows, cela inclut la mise hors service de l’interface utilisateur de l’hôte de console classique de sa position par défaut en faveur des séquences de terminal Windows, ConPTY et de terminal virtuel.

Enfin, cette ère a l’intention d’offrir un choix complet sur l’expérience par défaut, qu’il s’agisse du produit terminal Windows ou de tout autre terminal.

Bibliothèque de support client

[Futur] Grâce à la prise en charge et à la documentation des séquences de terminal virtuel côté client, nous encourageons vivement les développeurs d’utilitaires de ligne de commande Windows à utiliser d’abord des séquences de terminal virtuel sur les API Windows classiques pour bénéficier d’un écosystème unifié avec toutes les plateformes. Toutefois, un élément manquant important est que d’autres plateformes disposent d’un large éventail de bibliothèques d’assistance côté client pour gérer les entrées telles que la lecture et l’affichage graphique comme les ncurses. Cet élément de feuille de route futur particulier représente l’exploration de ce que l’écosystème offre et la façon dont nous pouvons accélérer l’adoption des séquences de terminal virtuel dans les applications de ligne de commande Windows sur l’API console classique.

Passthrough de séquence

[Futur] La combinaison des implémentations client et serveur de terminal virtuel permet de combiner et de mettre en correspondance complètes les applications d’hébergement de ligne de commande et de terminal client. Cette combinaison peut parler aux API de console Windows classiques ou aux séquences de terminal virtuel, mais il existe un coût de surcharge pour la traduire dans la méthode Windows compatible classique, puis en revenir à la méthode de terminal virtuel plus universelle.

Une fois que le marché adopte suffisamment les séquences de terminal virtuel et UTF-8 sur Windows, le travail de conversion/interprétation de l’hôte de console peut éventuellement être désactivé. L’hôte de console devient ensuite un service d’appel d’API simple et relaye à partir d’appels d’appareil vers l’application d’hébergement via la pseudoconsole. Cette modification augmente les performances et optimise le dialecte des séquences qui peuvent être parlées entre l’application cliente et le terminal. Grâce à ce changement, des scénarios d’interactivité supplémentaires seraient activés et (enfin) mettre le monde Windows en alignement avec la famille de toutes les autres plateformes de l’espace d’application de ligne de commande.