Путеводитель по экосистеме консоли и терминала Windows
В этом документе изложен общий план развития консоли Windows и Терминала Windows. В нем рассматриваются следующие аспекты:
место консоли Windows и Терминала Windows в экосистеме приложений командной строки в Windows и других операционных системах;
прошлый и будущий план создания этой платформы и развития продуктов, функций и стратегий в рамках этого процесса.
Основное внимание на текущем этапе развития консоли и терминала в корпорации Майкрософт уделяется созданию первоклассных функциональных возможностей терминала для разработчиков на платформе Windows, а также поэтапному отказу от классических API-интерфейсов консоли Windows и их замене последовательностями виртуальных терминалов с помощью псевдоконсоли. Терминал Windows наглядно демонстрирует переход к таким первоклассным возможностям, привлекая разработчиков к сотрудничеству в проектах с открытым кодом, поддерживая всевозможные сочетания приложений для командной строки и размещения в терминале и объединение экосистемы Windows со всеми остальными платформами.
Прежде чем продолжить, рекомендуем ознакомиться с определениями общей терминологии, используемой в этой области, Распространенная терминология включает в себя: приложения командной строки (или консоли), стандартные дескрипторы (STDIN
, STDERR
STDOUT
), устройства TTY и PTY, клиенты и серверы, консольная подсистема, узел консоли, псевдоконсол и терминал.
Общая архитектура системы состоит из четырех частей: клиент, устройство, сервер и терминал.
Клиент — это приложение командной строки, использующее текстовый интерфейс для ввода команд пользователем (вместо пользовательского интерфейса с управлением мышью) и возвращающее текстовое представление результата. В Windows API-интерфейс консоли обеспечивает уровень взаимодействия между клиентом и устройством. (Это также может быть стандартный обработчик консоли с API-интерфейсами для управления устройствами.)
Устройство выполняет функцию промежуточного уровня взаимодействия для обработки сообщений между двумя процессами: клиентом и сервером. В Windows это драйвер консоли. На других платформах это устройство телетайпа или псевдотерминала. Если вся транзакция представляет собой обычный текст или содержит последовательности виртуальных терминалов, в качестве такого канала связи могут использоваться другие устройства, например файлы, каналы и сокеты. Однако с API-интерфейсами консоли Windows такой подход не работает.
Сервер интерпретирует запрошенные вызовы API или сообщения от клиента. В классическом режиме работы Windows сервер также создает пользовательский интерфейс для вывода выходных данных на экран. Сервер дополнительно собирает входные данные для отправки их в ответных сообщениях на клиент через драйвер, например терминал, присоединенный к тому же модулю. При использовании модуля псевдоконсоли он вместо этого выполняет только функцию ретранслятора, предоставляющего подключенному терминалу эту информацию из последовательности виртуальных терминалов.
Терминал — это конечный уровень, который обеспечивает графическое отображение и интерактивные службы для пользователя. Он отвечает за запись входных данных и их кодирование в виде последовательностей виртуальных терминалов, которые в итоге поступают на STDIN
клиента. Он также будет получать и декодировать последовательности виртуальных терминалов, поступающие от STDOUT
клиента, для вывода их на экран.
Далее можно также создать дополнительные подключения, присоединив цепочку приложений с различными ролями к одной из конечных точек. Например, сеанс SSH выполняет две роли. Он функционирует как терминал для приложения командной строки, выполняемого на одном устройстве, и как клиент, перенаправляющий все полученные сведения, на другом устройстве. Эту цепочку можно продлить на произвольное число устройств в любых контекстах, что обеспечивает гибкие возможности для реализации различных сценариев.
На платформах, отличных от Windows, роли сервера и терминала реализованы в одном блоке, так как нет необходимости в переходном уровне для обеспечения совместимости между набором API и последовательностями виртуальных терминалов.
Все продукты командной строки Microsoft Windows теперь доступны на сайте GitHub в репозитории с открытым кодом microsoft/terminal.
Это традиционный пользовательский интерфейс Windows для приложений командной строки. Он обрабатывает все операции обслуживания через API консоли, вызываемые из любого подключенного приложения командной строки. Консоль Windows также обрабатывает представление графического пользовательского интерфейса от имени всех этих приложений. Она находится в системном каталоге в виде conhost.exe
или openconsole.exe
в форме программы с открытым кодом. Она входит в состав операционной системы Windows. Она также включена в другие продукты Майкрософт, созданные на основе репозитория с открытым кодом, чтобы реализовать более актуальную инфраструктуру псевдоконсоли. В соответствии с приведенными выше определениями она может выполнять либо традиционную общую роль сервера и терминала, либо функционировать только в качестве сервера с использованием предпочтительной инфраструктуры псевдоконсоли.
Это новый интерфейс Windows для приложений командной строки. Терминал Windows может служить основным примером использования псевдоконсоли для разделения взаимодействия при обслуживании через API и работе с текстовым приложением по тому же принципу, что и на всех остальных платформах, отличных от Windows.
Терминал Windows — это основной текстовый пользовательский интерфейс для Windows. Он демонстрирует возможности экосистемы и способствует дальнейшему сближению Windows с другими платформами. Терминал Windows также может служить примером создания надежного и сложного современного приложения с учетом прежних наработок для всего спектра API-интерфейсов и платформ Windows. В соответствии с приведенными выше определениями этот продукт выполняет роль терминала.
Основные исторические вехи развития подсистемы консоли можно разделить на две части: реализация до 2014 года и вся работа, проделанная после 2014 года, когда было определено новое направление развития командной строки в эпохе Windows 10.
[1989–1990 гг.] Изначально система узла консоли была реализована в виде эмуляции среды DOS в операционной системе Windows. Ее код был тесно связан и объединен с командной строкойcmd.exe
, которая является представлением этой среды DOS. Функции и права кода системы узла консоли такие же, как у интерпретатора (оболочки) командной строки. Эта система также предоставляет базовый уровень служб для других служебных программ командной строки, которые работают аналогично CMD.
[1997–1999 гг.] В этот период была внедрена поддержка двухбайтовой кодировки (DBCS), которая обеспечила поддержку ККЯ (китайского, корейского и японского языков). Это привело к разделению методов записи и чтения в консоли на две ветви: одна использовалась для создания отдельных "западных" версий, обрабатывающих однобайтовые символы, а другая — для альтернативных "восточных" версий, в которых для представления огромного массива символов требуется два байта. Такое разделение на ветви предусматривало расширение представления ячейки в среде консоли, ширина которой теперь могла составлять 1 или 2 ячейки. Представление с 1 ячейкой узкое (больше в высоту, чем в ширину), а с 2 ячейками — широкое (полная ширина или квадрат, в который можно вписать обычные китайские, японские и корейские иероглифы).
[2005–2009 гг.] Так как подсистема консоли работает внутри критического системного процесса csrss.exe
, подключение разных клиентских приложений с разными уровнями доступа к одному суперкритическому и привилегированному процессу было определено как особенно опасное. На этом этапе подсистема консоли была разделена на клиент, драйвер и серверные приложения. Каждое приложение может работать в собственном контексте, что позволяет сузить круг его прав и задач. Такая изоляция повышает общую надежность системы, так как никакой сбой в подсистеме консоли больше не может повлиять на другие критически важные функции процесса.
[2014–2016 гг.] После длительного периода несистематического обновления подсистемы консоли всевозможными командами разработчиков была сформирована новая отдельная команда, отвечавшая за улучшения ее возможностей. В этот период были внесены следующие улучшения: выбор строки, плавное изменение размера окна, изменение размещения текста, копирование и вставка, поддержка высоких значений DPI и ориентация на Юникод, в том числе сведение отдельных алгоритмов управления хранением и потоками для "западных" и "восточных" языков в единый алгоритм.
[2015–2017 гг.] Наряду с выходом подсистемы Windows для Linux в качестве мер корпорации Майкрософт по улучшению работы Docker в Windows и внедрению OpenSSH в качестве основной технологии удаленного выполнения в командной строке в узле консоли были представлены исходные реализации последовательностей виртуальных терминалов. Это позволило имеющейся консоли выполнять функцию терминала, подключенного непосредственно к таким собственным приложениям Linux в соответствующих средах, преобразовывая графические и текстовые атрибуты для просмотра на экране и возвращая введенные пользователем данные на требуемом "диалекте".
[2018 г.] За последние двадцать лет сторонние производители создали альтернативы исходному узлу консоли, которые помогают разработчикам работать еще эффективнее, а также поддерживают настройку дополнительных возможностей и предлагают интерфейсы с вкладками. Однако этим приложениям по-прежнему требовалось запускать и скрывать окно узла консоли. Они присоединяются в качестве дополнительного "клиентского" приложения, извлекающего данные из буфера путем циклического опроса в процессе работы основного клиентского приложения командной строки. Их задача — выполнять функцию терминала так, как на других платформах, но уже в мире Windows, где замена терминалов не поддерживалась.
В этот период была внедрена инфраструктура псевдоконсоли. Псевдоконсоль позволяет любому приложению запускать узел консоли в неинтерактивном режиме и выполнять функцию конечного терминального интерфейса для пользователя. Основным ограничением развития в этом направлении было обещание обеспечить дальнейшую совместимость Windows в отношении обслуживания всех опубликованных API-интерфейсов консоли Windows в неопределенном будущем, предоставив при этом для замены интерфейс размещения на сервере, способный обеспечить такие же возможности, как на всех других платформах. Решением этой задачи стала последовательность виртуальных терминалов. По сути, это зеркальное отражение того, чтобы было сделано на этапе реализации клиента — проекты псевдоконсоли, которые будут отображаться на экране как последовательности виртуальных терминалов для делегированного узла и интерпретировать ответы, преобразовывая их в последовательности ввода в формате Windows для использования клиентским приложением.
[С 2019 г. по сегодняшний день] Это эпоха открытого кода для подсистемы консоли с ориентацией на новый Терминал Windows. В рамках конференции Microsoft Build в мае 2019 г. было объявлено о выходе Терминала Windows, полностью размещенного на GitHub в репозитории microsoft/terminal. Основным приоритетом этого периода будет создание приложения "Терминал Windows" на основе оптимизированной платформы для псевдоконсоли, которое обеспечит первоклассные функциональные возможности терминала для разработчиков на платформе Windows.
Терминал Windows не только демонстрирует возможности платформы, в том числе технологию интерфейса WinUI, модель упаковки MSIX и архитектуру компонентов C++/WinRT, но и позволяет выполнить ее проверку. С помощью Терминала Windows организация Windows сможет открывать и развивать платформу приложений по мере необходимости, что позволит разработчикам работать еще эффективнее. Реализация уникального набора требований для опытных пользователей и разработчиков в Терминале Windows обеспечит соответствие платформы Windows современным требованиям и ожиданиям.
Для операционной системы Windows это означает отказ от стандартного пользовательского интерфейса узла классической консоли и переход на Терминал Windows, ConPTY и последовательности виртуальных терминалов.
Наконец, на этом этапе предполагается поддержка всего спектра стандартных функциональных возможностей, как в Терминале Windows, так и во всех альтернативных терминалах.
[Будущее] Учитывая наличие поддержки последовательностей виртуальных терминалов и соответствующей документации на стороне клиента, мы настоятельно рекомендуем разработчикам служебных программ командной строки Windows отказаться от классических API Windows в пользу последовательностей виртуальных терминалов, чтобы воспользоваться преимуществами унифицированной экосистемы при работе со всеми платформами. Однако в этой картине недостает одной существенной детали. Другие платформы имеют широкий спектр вспомогательных библиотек на стороне клиента для обработки входных данных, например readline, и графического отображения, например ncurses. Чтобы добавить эту недостающую часть плана будущего развития, необходимо определить, какие возможности предлагает эта экосистема и как ускорить внедрение последовательностей виртуальных терминалов в приложения командной строки Windows вместо классических API-интерфейсов консоли.
[Будущее] Совместное использование реализаций клиента и сервера виртуальных терминалов обеспечивает поддержку всевозможных сочетаний приложений для командной строки и размещения в терминале. Эта комбинация может взаимодействовать как с классическими API-интерфейсами консоли Windows, так и с последовательностями виртуальных терминалов, однако преобразование в совместимый классический метод Windows и обратно в более универсальный метод виртуальных терминалов сопряжено с дополнительными временными затратами.
Когда применение последовательностей виртуальных терминалов и UTF-8 в Windows получит широкое распространение на рынке, задание преобразования и интерпретации для узла консоли можно будет при необходимости отключить. После этого узел консоли станет обычным средством обработки вызовов API и будет ретранслировать вызовы с устройств в основное приложение через псевдоконсоль. Это изменение повысит производительность и обеспечит максимальную поддержку "диалекта" последовательностей, используемого для обмена данными между клиентским приложением и терминалом. Благодаря этому изменению появится возможность реализовать дополнительные сценарии взаимодействия и (наконец) привести мир Windows в соответствие с семейством всех остальных платформ, на которых реализуются приложения командной строки.