консольные приложения для windows

Десятка быстрых. Выбираем консольный софт для повседневных нужд

Содержание статьи

Если ты перешел на Linux совсем недавно или же работаешь исключительно в графической среде и графических приложениях, то наверняка задаешься вопросом: а зачем столько людей используют консольный софт? Я говорю не о терминале и его мощной командной строке, а о консольных приложениях с псевдографическим интерфейсом, в которых вся визуальная составляющая — это символы (яркий пример из мира Windows — FAR и Norton Commander).

Скорее всего, ты думаешь, что пользователи таких приложений — старперы, которые уже не могут переучиться и привыкнуть к новому. Отчасти это правда, однако есть и другие причины: скорость, удобство и «чистота интерфейса». Консольный софт просто невероятно быстр, им можно управлять не используя мышь, а главное — создать захламленный псевдографический интерфейс просто невозможно, он всегда будет содержать только необходимую информацию, без лишних обвесок и декораций.

Далее я расскажу о десятке приложений для решения повседневных задач: управления файлами, чтения почты, прослушивания музыки и прочего. Сразу скажу, что в списке есть несколько графических приложений (просмотрщик изображений и PDF-ридер), но созданы они с оглядкой на консольный софт — минималистичный интерфейс и полное управление с клавиатуры. Так что все будет честно.

Файлы: Midnight Commander

Midnight Commander (или просто mc) — одно из самых известных консольных приложений. Это клон бессмертного Norton Commander, созданный специально для UNIX. Mc можно увидеть на экране ноутбука каждого второго админа, вот только почему-то все они используют его как есть, выжигая себе глаза синим фоном.

Также рекомендую изменить две другие опции для отключения бесполезных строки меню сверху и строки кнопок снизу:

Ну а те, кто не любит стандартный редактор mc и предпочитает юзать другой, должны добавить такую опцию:

Важная особенность mc — умение показывать и запускать многие типы файлов с помощью внешних приложений. Например, если ты выберешь файл с изображением и нажмешь F3, то увидишь на экране информацию об изображении: формат, размер, глубина цвета и другие данные. Эту информацию mc получает от утилиты identify из пакета ImageMagic. Нажатие Enter запустит просмотрщик изображений (по умолчанию с помощью gqview, see или zgv, какой найдется в системе).

Все привязки типов файлов к приложениям описаны в файле

Midnight Commander здорового человека

Файлы по-другому: Nnn

Двухпанельный файловый менеджер не всегда удобен, когда необходимо просто пройтись по каталогам и найти/открыть нужный файл. В этом случае гораздо лучше подойдет nnn — простой и быстрый как молния файловый менеджер без лишних обвесок и со всей необходимой функциональностью для навигации по файловой системе.

Лаконичный интерфейс nnn

Электронная почта: mutt

В среде пользователей UNIX почтовый клиент mutt занимает примерно то же место, что и Vim: его либо ненавидят, либо не могут без него жить. Как и у Vim, у mutt очень высокий порог вхождения, его нельзя просто запустить и начать использовать. Точнее, можно, но всей мощи клиента ты не увидишь. mutt необходимо конфигурировать, долго подстраивая его под себя. Зато в результате ты получишь приложение, с помощью которого можно обработать тонны писем намного быстрее, чем с помощью любого другого клиента.

Рассказывать здесь о том, как конфигурировать mutt, бессмысленно, это слишком обширная тема. Зато в Сети всегда можно найти множество преднастроенных конфигов, один из которых обязательно тебе подойдет (пример для любителей Vim). Существуют даже онлайн-генераторы конфига mutt.

Вот лишь базовый конфиг mutt для подключения к Gmail (имей в виду, тебе необходимо включить поддержку IMAP и создать пароль приложения специально для mutt, если ты используешь двухфакторную аутентификацию):

mutt: простота и эффективность

Продолжение доступно только участникам

Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее

Вариант 2. Открой один материал

Заинтересовала статья, но нет возможности стать членом клуба «Xakep.ru»? Тогда этот вариант для тебя! Обрати внимание: этот способ подходит только для статей, опубликованных более двух месяцев назад.

Евгений Зобнин

Редактор рубрики X-Mobile. По совместительству сисадмин. Большой фанат Linux, Plan 9, гаджетов и древних видеоигр.

Источник

Магия консоли. Подбираем полезные утилиты для работы в терминале

Содержание статьи

Система

Pueue

Ути­лита Pueue — инте­рес­ная шту­ка для запус­ка дол­гих задач и для работы с соз­данной оче­редью задач в сис­теме, конеч­но. Нуж­на для тех, кому впол­не оче­вид­ных для таких слу­чаев jobs / fg / bg / screen / tmux по какой‑то при­чине ока­зыва­ется недос­таточ­но.

Де­мо из репози­тория

Crongo — еще одна попыт­ка соз­дать удоб­ный инс­тру­мент для работы с cron. Ути­лита дела­ет при­мер­но то же самое, что Pueue, так что может в некото­ром смыс­ле быть аль­тер­нативой.

Nq — еще одна прос­тая ути­лита, которая поз­воля­ет запус­кать оче­реди из заданий в сис­теме. Не то что­бы без нее было невоз­можно жить, но порой очень силь­но помога­ет. Выг­лядит куда менее прив­лекатель­но, чем Pueue, но и в работе про­ще.

Она нас­толь­ко прос­тая, что для ее исполь­зования дос­таточ­но прос­то уви­деть при­мер:

Vizex

Ес­ли ты работа­ешь в тер­минале доль­ше недели, ты, конеч­но, зна­ешь о df и его сухом выводе. Давай разук­расим его и сде­лаем бли­же к людям!

Как выг­лядит vizex

bashtop

Ра­бота­ет!

Bashtop уме­ет показы­вать не толь­ко общую информа­цию, но и детали по каж­дому про­цес­су. Поз­воля­ет эти про­цес­сы сор­тировать по раз­личным парамет­рам и лег­ко кон­фигури­рует­ся.

А еще есть реали­зация это­го кра­сав­ца на Python — bpytop. Выг­лядит не менее эффек­тно, да и по воз­можнос­тям не отста­ет.

За­нят­ная кон­соль­ная ути­лита для ана­лиза логов nginx. Встре­чай Rhit — это, конеч­но, не GoAccess, но выг­лядит тоже инте­рес­но.

Уме­ет рисовать гра­фики час­тоты зап­росов пря­мо в кон­соли.

Скри­ны сты­рены с сай­та прог­раммы

Есть ана­лиз трен­дов в зап­росах и удоб­ный гра­фичес­кий вывод это­го в кон­соль.

Ко­неч­но же, все мож­но филь­тро­вать, что­бы отсле­живать толь­ко необ­ходимое.

Lnav — это ана­лиза­тор логов, который уме­ет работать не толь­ко с nginx, в отли­чие от Rhit. Вот спи­сок его дос­тоинств:

Пря­мо на сай­те есть готовые бинар­ники под Linux и macOS: видимо, это на слу­чай, если твой сер­вер — ста­рый мак­бук.

Butterfly Backup

Butterfly Backup — это такая инте­рес­ная обер­тка вок­руг rsync, которая уме­ет соз­давать и вос­ста­нав­ливать бэкапы. Спи­сок уме­ний дей­стви­тель­но вну­шитель­ный:

Ус­тановить Butterfly Backup мож­но все­го в три коман­ды:

При­мер исполь­зования от авто­ра ути­литы:

Источник

Гарантированная локализация/русификация консоли Windows

Введение

Данный материал не предлагает строгий алгоритм действий, а направлен на описание узловых проблем, с которыми неизбежно сталкивается разработчик локализованного консольного приложения, а также некоторые возможные пути их разрешения. Предполагается, что это позволит разработчику сформировать стратегию работы с локализованной консолью и эффективно реализовать существующие технические возможности, большая часть которых хорошо описана и здесь опущена.

Виды консолей

В общем случае функции консоли таковы:

управление операционной системой и системным окружением приложений на основе применения стандартных системных устройств ввода-вывода (экран и клавиатура), использования команд операционной системы и/или собственно консоли;

запуск приложений и обеспечение их доступа к стандартным потокам ввода-вывода системы, также с помощью стандартных системных устройств ввода-вывода.

Отдельным видом консоли можно считать консоль отладки Visual Studio (CMD-D ).

Конфликт кодировок

Совет 1. Выполнять разработку текстовых файлов (программных кодов, текстовых данных и др.) исключительно в кодировке UTF-8. Мир любит Юникод, а кроссплатформенность без него вообще невозможна.

Совет 2. Периодически проверять кодировку, например в текстовом редакторе Notepad++. Visual Studio может сбивать кодировку, особенно при редактировании за пределами VS.

Поскольку в консоли постоянно происходит передача управления от приложений к собственно командному процессору и обратно, регулярно возникает «конфликт кодировок», наглядно иллюстрируемый таблица 1 и 2, сформированных следующим образом:

Команды и код приложения под катом

> Echo ffffff фффффф // в командной строке

PS> Echo ffffff фффффф // в PowerShell

код тестового приложения:

Командную часть задания все консоли локализовали практически без сбоев во всех кодировках, за исключением: в WPS неверно отображена русскоязычная часть команды во всех кодировках.

Табл. 1. Результат выполнения команды консоли Echo ffffff фффффф

Вывод тестового приложения локализован лишь в 50% испытаний, как показано в табл.2.

Табл. 2. Результат запуска приложения LoggingConsole.Test

Сoвет 3. Про PowerShell забываем раз и навсегда. Ну может не навсегда, а до следующей мажорной версии.

По умолчанию Windows устанавливает для консоли кодовые страницы DOS. Чаще всего CP437, иногда CP866. Актуальные версии командной строки cmd.exe способны локализовать приложения на основе русифицированной кодовой страницы 866, но не 437, отсюда и изначальный конфликт кодировок консоли и приложения. Поэтому

Проблемы консолей Visual Studio

Отдельной опцией Visual Studio является встроенная односеансная консоль отладки, которая перехватывает команду Visual Studio на запуск приложения, запускается сама, ожидает компиляцию приложения, запускает его и отдает ему управление. Таким образом, отладочная консоль в течение всего рабочего сеанса находится под управлением приложения и возможность использования команд Windows или самой консоли, включая команду CHCP, не предусмотрена. Более того, отладочная консоль не воспринимает кодовую страницу по умолчанию, определенную в реестре, и всегда запускается в кодировке 437 или 866.

Совет 6. Тестирование приложения целесообразно выполнять во внешних консолях, более дружелюбных к локализации.

Локализация отладочной консоли Visual Studio

Ниже приведен пример вывода тестового приложения в консоль, иллюстрирующий изложенное. Метод Write получает номера текущих страниц, устанавливает новые кодовые страницы вводного и выводного потоков, выполняет чтение с консоли и записывает выводную строку, содержащий русский текст, в том числе считанный с консоли, обратно в консоль. Операция повторяется несколько раз для всех основных кодовых страниц, упомянутых ранее.

приложение запущено в консоли с кодовыми страницами 1251 (строка 2);

приложение меняет кодовые страницы консоли (current, setted);

приложение остановлено в консоли с кодовыми страницами 1252 (строка 11, setted);

Приложение адекватно локализовано только в случае совпадения текущих кодовых страниц консоли (setted 1251:1251) с начальными кодовыми страницами (строки 8 и 10).

Код тестового приложения под катом

Совет 7. Обязательный и повторный! Функции SetConsoleCP должны размещаться в коде до первого оператора ввода-вывода в консоль.

Стратегия локализации приложения в консоли

Удалить приложение PowerShell (если установлено), сохранив Windows PowerShell;

Установить в качестве кодовую страницу консоли по умолчанию CP65001 (utf-8 Unicode) или CP1251 (Windows-1251-Cyr), см. совет 5;

Разработку приложений выполнять в кодировке utf-8 Unicode;

Контролировать кодировку файлов исходных кодов, текстовых файлов данных, например с помощью Notepad++;

Реализовать программное управление локализацией приложения в консоли, пример ниже под катом:

Пример программной установки кодовой страницы и локализации приложения в консоли

Источник

Встречайте псевдоконсоль Windows (ConPTY)

Статья опубликована 2 августа 2018 года

Это вторая статья про командную строку Windows, где мы обсудим новую инфраструктуру и программные интерфейсы псевдоконсоли Windows, то есть Windows Pseudo Console (ConPTY): зачем мы её разработали, для чего она нужна, как работает, как её использовать и многое другое.

В прошлой статье «Тяжкое наследие прошлого. Проблемы командной строки Windows» мы рассказали о предпосылках появления терминала и эволюции командной строки в Windows, а также начали изучать внутреннее устройство Windows Console и инфраструктуры Windows Command-Line. Мы также обсудили многие преимущества и главные недостатки консоли Windows.

Один из недостатков заключается в том, что Windows пытается быть «полезной», но мешает разработчикам альтернативных и сторонних консолей, разработчикам служб и т.д. При создании консоли или службы разработчикам нужно иметь доступ к каналам связи, по которым их терминал/служба обменивается данными с приложениями командной строки, или предоставлять доступ к ним. В мире *NIX это не проблема, потому что *NIX предоставляет инфраструктуру «псевдотерминала» (PTY), которая позволяет легко создавать коммуникационные каналы для консоли или службы. Но в Windows такого не было…

От TTY к PTY

Прежде чем подробно рассказать о нашей разработке, давайте кратко вернёмся к развитию терминалов.

Вначале был TTY

Как обсуждалось в прошлой статье, в первые дни вычислений пользователи управляли компьютерами с помощью электромеханических телетайпов (TTY), подключённых к компьютеру через какой-то последовательный канал связи (обычно через токовую петлю 20 мА).

Кен Томпсон и Деннис Ричи (стоя) работают на DEC PDP-11 по телетайпу (сообщения без электронного дисплея)

Распространение терминалов

На смену телетайпам пришли компьютеризированные терминалы с электронными дисплеями (обычно ЭЛТ-экранами). Как правило, терминалы — очень простые устройства (отсюда термин «тупой терминал»), содержащие только электронику и вычислительную мощность, необходимую для следующих задач:

Адмирал Грейс Хоппер в своём офисе с терминалом DEC VT220 на столе

Распространение программных терминалов

Начиная с середины 1980-х годов вместо специализированных терминалов постепенно начали применяться компьютеры общего назначения, которые становились более доступными, популярными и мощными. Во многих ранних ПК и других компьютерах 80-х годов имелись терминальные приложения, которые открывали соединение по порту RS-232 на ПК и обменивались данными с кем угодно на другом конце соединения.

По мере того как компьютеры общего назначения становились всё более изощрёнными, появился графический пользовательский интерфейс (GUI) и целый новый мир одновременно работающих приложений, включая терминальные приложения.

Но возникла проблема: как терминальному приложению взаимодействовать с другим приложением командной строки, запущенным на той же машине? И как физически подключить последовательный кабель между двумя приложениями, работающими на одном компьютере?

Появление псевдотерминала (PTY)

В мире *NIX проблему решили введением псевдотерминала (PTY).

PTY эмулирует серийное телекоммуникационное оборудование в компьютере, выставляя ведущее и ведомое псевдоустройства (“master” и “slave”): терминальные приложения подключаются к ведущему псевдоустройству, а приложения командной строки (например, оболочки вроде cmd, PowerShell и bash) — к ведомому псевдоустройству. Когда терминальный клиент передаёт текст и/или команды управления (закодированные как текст) ведущему псевдоустройству, текст транслируется на связанное с ним ведомое. Текст от приложения направляется на ведомое псевдоустройство, затем обратно на ведущее и, таким образом, на терминал. Данные всегда отправляются/принимаются асинхронно.

Приложение/оболочка псевдотерминала

Важно отметить, что «ведомое» псевдоустройство эмулирует поведение физического терминала и преобразует командные символы в сигналы POSIX. Например, если пользователь вводит в терминал CTRL+C, то значение ASCII для CTRL+C (0x03) отправляется через ведущее устройство. При получении на ведомом псевдоустройстве значение 0x03 удаляется из входного потока и генерируется сигнал SIGINT.

Этот механизм позволяет терминальным приложениям «разговаривать» непосредственно с приложениями командной строки, запущенными локально, как терминал разговаривал бы с удалённым компьютером через последовательное/сетевое соединение.

Что, нет псевдоконсоли Windows?

Как мы обсуждали в предыдущей статье, в то время как консоль Windows концептуально похожа на традиционный терминал *NIX, она отличается несколькими ключевыми способами, особенно на самых низких уровнях, которые могут вызвать проблемы у разработчиков приложений командной строки Windows, сторонних терминалов/консолей и серверных приложений:

Что делать?

Многие, многие разработчики часто просили PTY-подобный механизм под Windows, особенно те, кто работает с инструментами ConEmu/Cmder, Console2/ConsoleZ, Hyper, VSCode, Visual Studio, WSL, Docker и OpenSSH.

Даже Питер Брайт — технологический редактор Ars Technica — попросил внедрить механизм PTY через несколько дней, как я начал работать в команде Console:

Что ж, мы наконец-то сделали это: мы создали псевдоконсоль для Windows:

Добро пожаловать в псевдоконсоль Windows (ConPTY)

С момента образования Console Team около четырёх лет назад группа занималась капитальным ремонтом консоли Windows и внутренних механизмов работы командной строки. При этом мы регулярно и тщательно рассматривали описанные выше вопросы и многие другие связанные вопросы и проблемы. Но инфраструктура и код были не готовы, чтобы сделать возможным выпуск псевдоконсоли… до настоящего момента!

Новая инфраструктура псевдоконсоли Windows (ConPTY), API и некоторые другие соответствующие изменения устранят/облегчат целый класс проблем… не ломая обратную совместимость с существующими приложениями командной строки!

Новые Win32 ConPTY API (официальная документация будет скоро опубликована) теперь доступны в последних инсайдерских сборках Windows 10 и соответствующих Windows 10 Insider Preview SDK. Они появятся в следующем крупном релизе Windows 10 (где-то осенью/зимой 2018).

Архитектура консоли/ConHost

Чтобы понять ConPTY, нужно изучить архитектуру консоли Windows, а точнее… ConHost!

Важно понимать, что хотя ConHost реализует всё, что вы видите и знаете как приложение Windows Console, но ConHost также содержит и реализует большую часть инфраструктуры командной строки Windows! Отныне же ConHost становится настоящим «консольным узлом», поддерживая все приложения командной строки и/или GUI-приложения, которые взаимодействуют с приложениями командной строки!

Как? Почему? Что? Давайте разберёмся подробнее.

Вот высокоуровневое представление внутренней архитектуры консоли/ConHost:

В сравнении с архитектурой из предыдущей статьи, ConHost теперь содержит несколько дополнительных модулей для обработки VT и новый модуль ConPTY, реализующий открытые API:

Как работают приложения командной строки Windows?

Чтобы лучше понять влияние новой инфраструктуры ConPTY, давайте рассмотрим, как до сих пор работали консольные приложения Windows и приложения командной строки.

Всякий раз, когда пользователь запускает приложение командной строки, такое как Cmd, PowerShell или ssh, Windows создаёт новый процесс Win32, в который загружает исполняемый двоичный файл приложения и любые зависимости (ресурсы или библиотеки).

Вновь созданный процесс обычно наследует дескрипторы stdin и stdout от своего родителя. Если родительский процесс был процессом Windows GUI, то дескрипторы stdin и stdout отсутствуют, поэтому Windows развернёт и присоединит новое приложение к новому экземпляру консоли. Связь между приложениями командной строки и их консолью передается через ConDrv.

Например, при запуске из экземпляра PowerShell без повышенных прав новый процесс приложения унаследует родительские дескрипторы stdin/stdout и, следовательно, получит входные данные и выдаст выходные данные в ту же консоль, что и родитель.

Здесь нужно немного оговориться, потому что в некоторых случаях приложения командной строки запускаются прикреплёнными к новому экземпляру консоли, особенно по соображениям безопасности, но обычно верно описание выше.

В конечном счёте, когда запускается приложение командной строки/оболочка, Windows подключает его к экземпляру консоли (ConHost.exe) через ConDrv:

Как работает ConHost?

Всякий раз, когда выполняется приложение командной строки, Windows подключает приложение к новому или существующему экземпляру ConHost. Приложение и его экземпляр консоли подключаются через драйвер консоли режима ядра (ConDrv), который отправляет/получает сообщения IOCTL, содержащие сериализованные запросы вызовов API и/или текстовые данные.

Исторически, как указано в предыдущей статье, работа ConHost сегодня относительно проста:

ConHost: вклад в прошлое ради будущего

Microsoft старается по возможности поддерживать обратную совместимость с существующими приложениями и инструментами. Особенно для командной строки. На самом деле 32-битные версии Windows 10 ещё могут запускать многие/большинство 16-битных приложений и исполняемых файлов Win16!

Как упоминалось выше, одна из ключевых ролей ConHost заключается в предоставлении сервисов своим приложениям командной строки, особенно устаревшим приложениям, которые вызывают и полагаются на консольный API Win32. Теперь ConHost предлагает и новые сервисы:

В этой новой модели:

В конечном счёте, даже традиционные приложения командной строки снаружи «говорят» текстом/VT без каких-либо изменений!

Используя новую инфраструктуру ConPTY, сторонние консоли теперь могут напрямую взаимодействовать с современными и традиционными приложениями командной строки и обмениваться со всеми ними данными в тексте/VT.

Удалённое взаимодействие с приложениями командной строки Windows

Описанный выше механизм отлично работает на одном компьютере, но также помогает при взаимодействии, например, с инстансом PowerShell на удалённом компьютере Windows или в контейнере.

При удалённом запуске приложения командной строки (т.е. на удалённых компьютерах, серверах или в контейнерах) имеется проблема. Дело в том, что приложения командной строки на удалённых машинах общаются с локальным инстансом ConHost, потому что сообщения IOCTL не предназначены для передачи по сети. Как же передать ввод из локальной консоли на удалённую машину и как получить выдачу из приложения, запущенного там? Более того, что делать с машинами Mac и Linux, где есть терминалы, но нет Windows-совместимых консолей?

Таким образом, чтобы удалённо управлять машиной Windows, нам нужен какой-то брокер связи, который сможет прозрачно сериализовать данные по сети, управлять временем жизни экземпляра приложения и т.д.

Возможно, что-то вроде ssh?

К счастью, OpenSSH недавно портировали на Windows и добавили как дополнительную опцию Windows 10. PowerShell Core также использует ssh в качестве одного из поддерживаемых протоколов удалённого взаимодействия PowerShell Core Remoting. А для тех, кто работал в Windows PowerShell, удалённое взаимодействие Windows PowerShell Remoting по-прежнему остаётся приемлемым вариантом.

Давайте посмотрим, как сейчас OpenSSH для Windows позволяет удалённо управлять оболочками и приложениями командной строки Windows:

В данный момент OpenSSH включает некоторые нежелательные усложнения:

Удалённая работа с использованием современных ConHost и ConPTY

Наверняка мы можем улучшить ситуацию? Да, конечно, можем — давайте сделаем несколько архитектурных изменений и применим наш новый ConPTY:

Из диаграммы видно, что схема изменилась следующим образом:

Согласитесь, что этот новый механизм удалённого взаимодействия ConPTY приводит к элегантной, последовательной и простой архитектуре. В сочетании с мощными функциями, встроенными в ConHost, поддержкой старых приложений и отображением изменений от приложений, вызывающих консольные Console API, в виде текста/VT, новая инфраструктура ConHost и ConPTY помогает нам перенести прошлое в будущее.

ConPTY API и как его использовать

К настоящему времени я уверен, что вам не терпится увидеть какой-то код 😉

Взглянем на декларации API:

Вышеприведённый ConPTY по API по сути выставляет для использования три новых функции:

Использование ConPTY API

Ниже приведён небольшой пример кода вызова ConPTY API для создания псевдоконсоли и присоединения приложения командной строки к созданному ConPTY.

Запись в псевдоконсоль

Запись входных данных в ConPTY осуществляется просто:

Изменение размера псевдоконсоли

Следующий сценарий показывает, как изменить размер ConPTY:

Закрытие псевдоконсоли

Нет ничего проще закрытия ConPTY:

Примечание: закрытие ConPTY завершит связанный ConHost и любые присоединённые клиенты.

Призыв к действию!

Внедрение ConPTY API — пожалуй, одно из самых фундаментальных и раскрепощающих изменений, произошедших с командной строкой Windows за последние годы… если не десятилетия!

Мы уже портировали на ConPTY API некоторые инструменты Microsoft, а сейчас сотрудничаем с несколькими командами внутри Microsoft (подсистема Windows для Linux (WSL), команды Windows Containers, VSCode, Visual Studio и др.), а также с некоторыми независимыми разработчиками, включая @ConEmuMaximus5 — создателя потрясающей консоли ConEmu для Windows.

Но нам нужна ваша помощь, чтобы распространить информацию и начать использовать новые ConPTY API.

Разработчики приложений командной строки

Если у вас традиционное приложение командной строки, то вы свободны и можете ничего не делать: ConHost сделает всю работу за вас. Программа может продолжать работать как раньше и полагаться на вызовы Console API. Приложение продолжит работать как обычно, в то же время получив дополнительный бонус в виде улучшенного, более качественного удалённого взаимодействия.

Но если хотите, можно постепенно ввести новую поддержку VT, например, для новых функций — решать вам.

С другой стороны, если вы сейчас планируете новые приложения командной строки Windows, то мы настоятельно рекомендуем транслировать текст/VT в кодировке UTF-8 вместо обращения к Console API: такой «разговор на VT» даст доступ ко многим функциям, которые не будут доступны через Console API (например, поддержка 16M RGB True Color).

Разработчики сторонних консолей/сервисов

Если вы работаете над автономным приложением консоли/терминала или интегрируете консоль в приложение, то мы настоятельно призываем вас как можно скорее изучить и принять новые ConPTY API: использование новых программных интерфейсов вместо старого механизма внеэкранной консоли, скорее всего, ликвидирует несколько классов ошибок, одновременно повысив стабильность, надёжность и производительность.

В качестве примера команда VSCode в настоящее время решает вопрос (GitHub #45693) с несколькими проблемами, вызванными нынешним отсутствием псевдоконсоли Windows.

Обнаружение ConPTY API

Новые ConPTY API станут доступны в релизе Windows 10 осенью/зимой 2018 года.

Если текущая версия Windows поддерживает ConPTY, ваше приложение сможет найти и вызвать новые API ConPTY. Если нет, придётся вернуться к запутанным механизмам, используемым до сих пор.

Итак, на чём мы остановились?

Ещё одна длинная статья… это становится привычкой! Ещё раз, если вы смогли дочитать до этого места, СПАСИБО! 😀

Из приведённой информации можно сделать многие выводы, но важно подчеркнуть, почему мы вносим такие улучшения, а также суть реализованных изменений. Наша цель — устранить целый класс проблем и ограничений для разработчиков консольных и серверных приложений, а также сделать разработку кода для инфраструктуры командной строки Windows более мощной, последовательной и увлекательной.

Будем рады отзывам через хаб обратной связи. О более сложных проблемах сообщайте в репозитории Windows Console на GitHub. А если есть вопросы, стучитесь ко мне в твиттер.

Источник