Windows работа с консолью: Что такое консоль, команды и прочее такое разное — CMD
Содержание
Выполнить в командной строке | internet-lab.ru
- 22 ноября 2021
Сегодня небольшой ликбез для начинающих пользователей компьютера. Меня часто спрашивают пользователи как сделать ту или иную вещь в Windows. И я нередко отвечаю: «Выполните в командной строке вот эту команду…», и присылаю команду, которую следует выполнить. В половине случаев следуют традиционные вопросы:
- А что такое командная строка?
- А выполнить в командной строке это как?
- А как и куда команды вписывать?
- Командная что?
- Какая-какая строка?
- Не понял, что нужно сделать?
Командная строка (консоль, терминал, командная оболочка) — это программа, которая позволяет управлять компьютером путем ввода текстовых команд с клавиатуры.
Как запустить командную строку
Командная строка есть во всех операционных системах.
В операционной системе Microsoft Windows тоже есть командная строка. Найти её легко.
В Windows 7: Пуск → Все программы → Стандартные → Командная строка.
В Windows 10: Пуск → Служебные — Windows → Командная строка.
Если лень искать, то можно запустить командную строку из диалогового окна «Выполнить»:
- Нажимаем на клавиатуре ⊞ Win + R.
- Откроется диалоговое окно «Выполнить».
- Пишем команду cmd и нажимаем «ОК».
Если командная строка требуется часто, то можно создать на рабочем столе ярлык. Правой кнопкой Создать → Ярлык.
В поле «Укажите расположение объекта» пишем cmd и нажимаем «Далее».
Указываем название ярлыка или оставляем предложенное по умолчанию.
Готово.
Ярлык на командную строку создан.
Запуск командной строки
Теперь, когда мы тем или иным способом нашли командную строку, запускаем её как любую другую программу.
Следует знать, что многие команды требуют прав администратора, в этом случае нужно запустить командную строку под администратором. Для этого нажимаем по иконке правой кнопкой и выбираем «Запуск от имени администратора».
Открывается оболочка командной строки.
Мы запустили командную строку.
Выполнение команд в командной строке
В командной строке можно выполнить любую команду Windows. Можно сделать всё то же самое, что обычно делается с помощью мышки, и даже больше. За это и любят работу в командной строке разработчики и системные администраторы. Вместо десяти минут поиска нужных окошек достаточно ввести несколько команд и получить нужный результат за десять секунд.
Команду вводим с помощью клавиатуры и нажимаем «Ввод», после этого команда отправляется на выполнение. К примеру, команда date покажет текущую дату и предложит установить новую. Если не хотим менять дату, то просто нажимаем «Ввод».
Команду можно где-нибудь скопировать и вставить в командную строку с помощью правой кнопки.
Команда вставится, осталось нажать «Ввод».
Мы научились выполнять команды в командной строке.
Полезные команды командной строки
Помощь по командам командной строки:
help
Узнать свой локальный IP адрес:
ipconfig
Проверить, есть ли доступ в интернет:
ping yandex.ru
Информация о системе:
systeminfo
Проверка целостности системных файлов Windows:
sfc /scannow
Открыть окно конфигурации системы:
msconfig
Запустить калькулятор:
calc
Открыть диспетчер задач:
taskmgr
Главное, вовремя остановиться. Прервёмся, команд много.
Ещё может быть полезно знание о том как прервать выполнение долгой или зависшей команды, для этого нужно нажать Ctrl + C.
Теги
- cmd
- beginner
Работа в командной строке Windows
Наиболее часто встречающиеся рекомендации по запуску звучат так: Пуск, выполнить, cmd
.
В меню пуск присутствует пункт Выполнить
. Он запускает программу, которая позволяет передавать единичные команды системе Windows. В данном случае команда cmd запускает исполняемый файл cmd.exe, находящийся в папке system32.
C:\WINDOWS\system32\cmd.exe
На некоторых версиях Windows пункт меню выполнить
по умолчанию убран. В этом случае жмёте + R, вводите cmd, далее Enter. Также можно запустить командную строку непосредственно из папки system32, сделав ярлык для запуска на рабочем столе (кликаем на cmd.exe правой клавишей мыши и в меню выбираем пункт Отправить/Рабочий стол
) или же через диспетчер задач (кнопка новая задача
— cmd).
По умолчанию в командной строке нельзя работать мышью (перемещать курсор или выделять текст). Это неудобно вообще и новичкам в особенности. К тому же чёрный экран выглядит как-то слишком мрачно и уныло. Поэтому после запуска командной строки
нужно будет изменить её настройки. Жмём правой клавишей на окне cmd и выбираем умолчания
.
Стоит сразу отметить, что настройки умолчаний относятся к cmd.exe в целом, а свойства
— к конкретному открытому окну.
В появившемся окне свойств командной строки видим четыре вкладки:
На вкладке Параметры
стоит отметить пункты отбрасывать повторения
(чтобы снизить заполнение буфера команд) и выделение мышью
(чтобы можно было использовать мышь в работе).
На вкладках Шрифты
и Цвета
всё просто: выбираете размер, тип и цвет шрифта, а также фоновый цвет окна. Отмечу только, что размер шрифта влияет на размеры окна командной строки, поэтому его надо выставлять до размеров окна, а не после.
Во вкладке Расположение
задаются размеры окна и его начальное расположение при запуске. Я так до конца и не понял в каких единицах представлены величины, поэтому размер советую выставлять, руководствуясь окном предпросмотра слева.
Стоит отметить, что размер буфера влияет на вместимость окна, т.е. на количество информации, которое без проблем можно будет просмотреть после вывода на экран результатов выполнения команды (горизонтальная и вертикальная полосы прокрутки).
Если задать равные размеры для окна и буфера, то в окне будет отображаться только хвост
выводимой информации, который туда вместится.
Также если строка не впишется в ширину окна это приведёт к её переносу. Воспринимать представленную таким образом информацию менее удобно. Поэтому буфер я ставлю всегда намного больше размеров окна. Это позволяет просмотреть большие объёмы информации, воспользовавшись полосами прокрутки справа и снизу. Картинка ниже кликабельна. На превью показано начало вывода команды dir для папки system32, а нажав на превью можно увидеть хвост
вывода (обратите внимание на полосу прокрутки справа — данных очень много).
Команды командной строки
Консоль настроена, теперь осталось ознакомить вас с командами командной строки. Для вывода их полного списка достаточно набрать команду help.
help - вывод справки по командам help CD или CD /? - вывод справки по одной команде (для команды CD) cd - переход в корневой каталог cd .. - переход в родительский каталог D: - переход на диск D. dir - вывод всего содержимого папки dir *.exe - вывод списка exe-файлов папки cls - очистить экран командной строки
. - переход в родительский каталог
D: - переход на диск D.
dir - вывод всего содержимого папки
dir *.exe - вывод списка exe-файлов папки
cls - очистить экран командной строкиКомандная строка запоминает команды, которые вы вводите. Листать их можно клавишами ⇑ и ⇓. Можно просматривать содержимое папки при помощи клавиши Tab (Shift+Tab листает в обратном порядке). Можно пролистать файлы на конкретную букву или буквы. Например, напечатав букву s и нажимая Tab, можно пролистать только файлы и папки, начинающиеся на эту букву (system, system32, system.ini и т.д.) . Как это можно использовать:
Например, вам надо перейти из корня диска C в папку system32, найти и запустить в ней контрольную панель. Можно просто напечатать:
C:\windows\system32\control.exe
Но это не всегда быстро и удобно, к тому же не всегда знаешь – что конкретно надо набирать. Поэтому можно набрать команду cd, затем после пробела набрать wi, пролистать клавишей Tab до папки Windows, поставить после неё слэш, набрать буквы sy, пролистать клавишей Tab до папки system32, затем опять слэш и то же самое с control.
exe.
C: cd windows\system32\control.exe
Этот способ с табом куда быстрее в большинстве случаев, чем простой набор, так как названия файлов и папок могут быть длинными.
При включении поддержки мыши копировать информацию из командной строки можно выделив участок текста мышью и нажав Enter. Правая клавиша мыши, напротив, вставляет информацию из буфера обмена в командную строку.
В заключение статьи скажу, что cmd.exe — это просто программа ввода-вывода, такая же, как и блокнот. Разумеется, есть более продвинутые аналоги, которыми тоже можно пользоваться. Одна из таких программ — Console Portable
Кстати, в операционной системе GNU Linux командную строку можно вызывать прямо из папки. При этом строка откроется сразу с адресом папки и его не надо будет набивать вручную. В Windows для того, чтобы открыть командную строку непосредственно в папке, необходимо, зажав Shift, нажать правую клавишу мыши и выбрать в меню пункт «Открыть окно команд».
Также можно добавить эту возможность (и целый ряд других) с помощью программы расширения контекстного меню FileMenu Tools:
Если материалы сайта оказались для вас полезными, можете поддержать дальнейшее развитие ресурса, оказав ему (и мне ) моральную и материальную поддержку.
Функции консоли
— Консоль Windows
Редактировать
Твиттер
Фейсбук
Эл. адрес
- Статья
- 4 минуты на чтение
Для доступа к консоли используются следующие функции.
| Функция | Описание |
|---|---|
| Аддконсолеалиас | Определяет псевдоним консоли для указанного исполняемого файла. |
| AllocConsole | Выделяет новую консоль для вызывающего процесса. |
| Аттачконсоль | Присоединяет вызывающий процесс к консоли указанного процесса. |
| ЗакрытьПсевдоКонсоль | Закрывает псевдоконсоль от данного дескриптора. |
| CreatePseudoConsole | Выделяет новую псевдоконсоль для вызывающего процесса. |
| креатеконсолескринбуффер | Создает экранный буфер консоли. |
| Филконсолеаутпутаттрибуте | Задает атрибуты цвета текста и фона для указанного количества символьных ячеек. |
| FillConsoleOutputCharacter | Записывает символ в экранный буфер консоли указанное количество раз. |
| FlushConsoleInputBuffer | Сбрасывает буфер ввода консоли. |
| FreeConsole | Отсоединяет вызывающий процесс от его консоли. |
| ГенератеконсолеCtrlEvent | Отправляет указанный сигнал группе процессов консоли, которая совместно использует консоль, связанную с вызывающим процессом. |
| Жетконсолеалиас | Извлекает указанный псевдоним для указанного исполняемого файла. |
| GetConsoleAliases | Извлекает все определенные псевдонимы консоли для указанного исполняемого файла. |
| GetConsoleAliasesLength | Возвращает размер в байтах буфера, необходимого для хранения всех псевдонимов консоли для указанного исполняемого файла. |
| GetConsoleAliasExes | Получает имена всех исполняемых файлов с заданными псевдонимами консоли. |
| GetConsoleAliasExesLength | Возвращает размер в байтах буфера, необходимого для хранения имен всех исполняемых файлов, для которых определены псевдонимы консоли. |
| GetConsoleCP | Получает входную кодовую страницу, используемую консолью, связанной с вызывающим процессом. |
| Жетконсолекурсоринфо | Получает информацию о размере и видимости курсора для указанного экранного буфера консоли. |
| GetConsoleDisplayMode | Получает режим отображения текущей консоли. |
| GetConsoleFontSize | Получает размер шрифта, используемого указанным экранным буфером консоли. |
| GetConsoleHistoryInfo | Извлекает настройки журнала для консоли вызывающего процесса. |
| GetConsoleMode | Получает текущий режим ввода буфера ввода консоли или текущий режим вывода буфера экрана консоли. |
| GetConsoleOriginalTitle | Извлекает исходный заголовок для текущего окна консоли. |
| GetConsoleOutputCP | Извлекает кодовую страницу вывода, используемую консолью, связанной с вызывающим процессом. |
| Жетконсолепроцесслист | Получает список процессов, подключенных к текущей консоли. |
| GetConsoleScreenBufferInfo | Извлекает информацию об указанном экранном буфере консоли. |
| Жетконсолескринбуфферинфоекс | Извлекает расширенную информацию об указанном экранном буфере консоли. |
| GetConsoleSelectionInfo | Получает информацию о выбранной консоли. |
| Жетконсолетитле | Извлекает заголовок текущего окна консоли. |
| GetConsoleWindow | Извлекает дескриптор окна, используемый консолью, связанной с вызывающим процессом. |
| GetCurrentConsoleFont | Получает информацию о текущем шрифте консоли. |
| GetCurrentConsoleFontEx | Извлекает расширенную информацию о текущем шрифте консоли. |
| GetLargestConsoleWindowSize | Получает размер максимально возможного окна консоли. |
| GetNumberOfConsoleInputEvents | Извлекает количество непрочитанных входных записей в буфере ввода консоли. |
| GetNumberOfConsoleMouseButtons | Получает количество кнопок мыши, используемых текущей консолью. |
| Жетстдхандле | Извлекает дескриптор устройства стандартного ввода, стандартного вывода или стандартной ошибки. |
| HandlerRoutine | Функция, определяемая приложением, используемая с функцией SetConsoleCtrlHandler . |
| PeekConsoleInput | Считывает данные из указанного буфера ввода консоли, не удаляя их из буфера. |
| РидКонсоле | Считывает введенные символы из буфера ввода консоли и удаляет их из буфера. |
| Риадконсолеинпут | Считывает данные из буфера ввода консоли и удаляет их из буфера. |
| Риадконсолеинпутекс | Считывает данные из входного буфера консоли и удаляет их из буфера с настраиваемым поведением. |
| Риадконсолеаутпут | Считывает данные атрибутов символов и цветов из прямоугольного блока символьных ячеек в экранном буфере консоли. |
| ReadConsoleOutputAttribute | Копирует указанное количество атрибутов цвета переднего плана и фона из последовательных ячеек экранного буфера консоли. |
| ReadConsoleOutputCharacter | Копирует ряд символов из последовательных ячеек экранного буфера консоли. |
| Изменить размер псевдоконсоли | Изменяет размер внутренних буферов псевдоконсоли до заданного размера. |
| ScrollConsoleScreenBuffer | Перемещает блок данных в экранный буфер. |
| Сетконсолеактивескринбуффер | Устанавливает указанный экранный буфер в качестве отображаемого в данный момент экранного буфера консоли. |
| СетконсолеКП | Задает кодовую страницу ввода, используемую консолью, связанной с вызывающим процессом. |
| СетКонсолеCtrlHandler | Добавляет или удаляет определенный приложением HandlerRoutine из списка функций-обработчиков для вызывающего процесса. |
| Сетконсолекурсоринфо | Задает размер и видимость курсора для указанного экранного буфера консоли. |
| Сетконсолекурсорпозитион | Устанавливает позицию курсора в указанном буфере экрана консоли. |
| Сетконсоледисплаймоде | Задает режим отображения указанного экранного буфера консоли. |
| Сетконсолехисториинфо | Задает настройки истории для консоли вызывающего процесса. |
| Сетконсолемоде | Устанавливает режим ввода буфера ввода консоли или режим вывода буфера экрана консоли. |
| СетконсолеаутпутКП | Задает кодовую страницу вывода, используемую консолью, связанной с вызывающим процессом. |
| Сетконсолескринбуфферинфоекс | Задает расширенную информацию об указанном экранном буфере консоли. |
| Сетконсолескринбуфферсизе | Изменяет размер указанного экранного буфера консоли. |
| Сетконсолетекстаттрибуте | Задает атрибуты цвета переднего плана (текста) и фона для символов, записываемых в экранный буфер консоли. |
| Сетконсолетитле | Задает заголовок для текущего окна консоли. |
| Сетконсолевиндовинфо | Устанавливает текущий размер и положение окна экранного буфера консоли. |
| Сеткуррентконсолефонтекс | Задает расширенную информацию о текущем шрифте консоли. |
| Сетстдхандле | Устанавливает дескриптор стандартного ввода, стандартного вывода или стандартного ошибочного устройства. |
| WriteConsole | Записывает строку символов в экранный буфер консоли, начиная с текущего положения курсора. |
| WriteConsoleInput | Записывает данные непосредственно в буфер ввода консоли. |
| WriteConsoleOutput | Записывает данные атрибутов символов и цветов в указанный прямоугольный блок ячеек символов в экранном буфере консоли. |
| WriteConsoleOutputAttribute | Копирует ряд атрибутов цвета переднего плана и фона в последовательные ячейки экранного буфера консоли. |
| WriteConsoleOutputCharacter | Копирует ряд символов в последовательные ячейки экранного буфера консоли. |
Командная строка Windows: Внутри консоли Windows
Рич Тернер
20 июля 2018 г. 0 0
Добро пожаловать в третий пост из серии статей о командной строке Windows. В этом посте мы начнем копаться во внутренностях консоли Windows и командной строки, что это такое, что оно делает… и чего оно не делает.
Сообщения из серии «Командная строка Windows»
Примечание. Этот список глав будет обновляться по мере публикации новых сообщений:
- Подложка
- Эволюция командной строки Windows
- Внутри консоли Windows [Это сообщение]
- Представляем псевдоконсоль Windows (ConPTY)
- Буфер вывода текста Unicode и UTF-8
[Обновлено 20 июля 2018 г.
для улучшения удобочитаемости и уточнения некоторых деталей Unicode/UTF-x]
Во время первоначальной разработки Windows NT, примерно в 1989 году, не было графического интерфейса, не было рабочего стола, была ТОЛЬКО полноэкранная командная строка, которая визуально больше напоминала MS-DOS, чем будущее. Когда начала появляться реализация графического интерфейса Windows, команде потребовалось консольное приложение с графическим интерфейсом, и, таким образом, родилась консоль Windows. Консоль Windows — одно из первых приложений Windows NT с графическим интерфейсом и, безусловно, одно из старейших приложений Windows, которые до сих пор широко используются.
Кодовой базе консоли Windows в настоящее время (июль 2018 г.) почти 30 лет… фактически она старше, чем разработчики, которые сейчас над ней работают! 😄
Как мы узнали из наших предыдущих постов, работа терминала относительно проста:
- Обработка пользовательского ввода
- Принимать ввод с устройств, включая клавиатуру, мышь, сенсорный ввод, перо и т. д.
- Преобразование ввода в соответствующие символы и/или последовательности ANSI/VT
- Отправить символы в подключенное приложение/инструмент/оболочку
- Принимать ввод с устройств, включая клавиатуру, мышь, сенсорный ввод, перо и т.
- Обработка выходных данных приложения:
- Принять вывод текста из подключенного приложения/инструмента командной строки
- При необходимости обновите отображение на основе полученных выходных данных приложения (например, вывод текста, перемещение курсора, установка цвета текста и т. д.)
- Обработка системных взаимодействий:
- Запуск по запросу
- Управление ресурсами
- Изменить размер/развернуть/свернуть и т. д.
- Завершить, когда требуется, или когда канал связи закрывается/завершается
д.Однако консоль Windows работает немного по-другому:
Консоль Windows представляет собой традиционный исполняемый файл Win32, и, хотя изначально он был написан на «C», большая часть кода переносится на современный C++ по мере модернизации и модуляризации.
Кодовая база консоли.
Для тех, кто заботится о таких вещах: Многие спрашивают, написана ли Windows на C или C++. Ответ заключается в том, что, несмотря на объектно-ориентированный дизайн NT, Windows, как и большинство ОС, почти полностью написана на языке C. Почему? C++ вводит затраты с точки зрения занимаемой памяти и накладных расходов на выполнение кода. Даже сегодня скрытые затраты на код, написанный на C++, могут удивить, но в конце 1990-х годов, когда память стоила ~60 долларов за МБ (да… 60 долларов за МЕГАБАЙТ !), скрытая стоимость памяти для виртуальных таблиц и т. д. был значительным. Кроме того, стоимость косвенного вызова виртуального метода и разыменования объекта могла привести к очень значительным потерям производительности и масштабируемости для кода C++ в то время. Хотя все еще нужно быть осторожным, накладные расходы на производительность современного C++ на современных компьютерах гораздо меньше беспокоят и часто являются приемлемым компромиссом, учитывая его преимущества в безопасности, удобочитаемости и ремонтопригодности … поэтому мы постоянно обновляем код консоли на современный C++.
Итак, что находится внутри консоли Windows?
До Windows 7 экземпляры консоли Windows размещались в критически важной подсистеме времени выполнения клиент-сервер (CSRSS). Однако в Windows 7 консоль была извлечена из CSRSS по соображениям безопасности и надежности и получила новый дом в следующих двоичных файлах:
- conhost.exe — пользовательский интерфейс консоли Windows в пользовательском режиме и подключение командной строки
- condrv.sys — драйвер ядра Windows, обеспечивающий коммуникационную инфраструктуру между conhost и одной или несколькими оболочками/инструментами/приложениями командной строки
Общее представление текущей внутренней архитектуры консоли выглядит следующим образом:
]4 Архитектура консоли в Win10 1803
Основные компоненты консоли состоят из следующих компонентов (снизу вверх):
- ConDrv.sys — Драйвер режима ядра
- Обеспечивает высокопроизводительный канал связи между консолью и любыми подключенными приложениями командной строки
- Сообщения Ferries IO Control (IOCTL) между приложениями командной строки и консолью, к которой они «привязаны»
- Консольные сообщения IOCTL содержат
- Данные, представляющие запросы на выполнение вызовов API для экземпляра консоли
- Текст, отправленный из консоли в приложение командной строки
- ConHost. exe — приложение с графическим интерфейсом Win32:
- ConHost Core — внутренности консоли и сантехника
- Сервер API : Преобразует сообщения IOCTL, полученные от приложений командной строки, в вызовы API и отправляет текстовые записи из консоли в приложение командной строки
- API : реализует API и логику консоли Win32, лежащие в основе всех операций, которые консоль может выполнять
- Буфер ввода : Хранит записи событий клавиатуры и мыши, сгенерированные пользовательским вводом
- VT Parser : если включено, анализирует последовательности VT из текста, извлекает все найденные из текста и вместо этого генерирует эквивалентные вызовы API
- Буфер вывода : Сохраняет текст, отображаемый на дисплее консоли. По сути, это двумерный массив структур CHAR_INFO, которые содержат символьные данные и атрибуты каждой ячейки (подробнее о буфере ниже)
- Другое : Не включено в приведенную выше диаграмму, включая инфраструктуру настроек, хранение/извлечение значений из реестра и/или файлов ярлыков и т. д.
.
- Консольные службы приложений UX — уровень UX и пользовательского интерфейса консоли
- Управляет компоновкой, размером, положением и т. д. окна консоли на экране
- Отображает и обрабатывает настройки пользовательского интерфейса и т. д.
- Выполняет загрузку очереди сообщений Windows, обрабатывает сообщения Windows и преобразовывает вводимые пользователем данные в записи событий клавиш и мыши, сохраняя их в буфере ввода
- ConHost Core — внутренности консоли и сантехника
exe — приложение с графическим интерфейсом Win32:
д. Как видно из приведенной выше архитектуры консоли, в отличие от терминалов NIX, консоль отправляет/принимает вызовы API и/или данные, сериализованные в сообщения управления вводом-выводом (IOCTL), а не сериализованный текст. Даже последовательности ANSI/VT, встроенные в текст, полученный из приложений командной строки (в основном Linux), извлекаются, анализируются и преобразуются в вызовы API. Это различие раскрывает ключевое фундаментальное философское различие между *NIX и Windows: в *NIX «все является файлом», тогда как в Windows «все является объектом».
У обоих подходов есть свои плюсы и минусы, которые мы опишем, но не будем здесь подробно обсуждать. Просто помните, что это ключевое различие в философии лежит в основе многих многих различий между Windows и *NIX!
В *NIX все является файлом
Когда Unix была впервые реализована в конце 1960-х и начале 1970-х годов, одним из основных принципов было то, что (там, где это возможно) все должно быть абстрагировано как файловый поток. Одной из ключевых целей было упростить код, необходимый для доступа к устройствам и периферийным устройствам: если бы все устройства представлялись ОС как файловые системы, то существующий код мог бы получить доступ к этим устройствам более легко. Эта философия имеет глубокие корни: можно даже перемещаться и запрашивать большую часть конфигурации ОС и машины на основе *NIX, перемещаясь по псевдо/виртуальным файловым системам, которые выдают то, что кажется «файлами» и папками, но на самом деле представляют конфигурацию машины.
и оборудование. Например, в Linux можно исследовать свойства процессоров машины, изучив содержимое /proc/cpuinfo Псевдофайл:
Однако за простоту и согласованность этой модели можно платить: извлечение/запрос конкретной информации из текста в псевдофайлах и возврат из выполнения команд часто требуют инструментов, например sed, awk, perl, python и т. д. Эти инструменты используются для написания команд и сценариев для анализа текстового содержимого в поисках определенных шаблонов, полей и значений. Некоторые из этих скриптов могут стать довольно сложными, часто их трудно поддерживать и они могут быть ненадежными — если структура, макет и/или формат текста изменяются, многие скрипты, вероятно, потребуется обновить.
В Windows все является объектом
Когда Windows NT проектировалась и создавалась, «объекты» рассматривались как будущее разработки программного обеспечения: «объектно-ориентированные» языки появлялись быстрее, чем кролики из норы — Simula и Smalltalk были уже утвердился, а C++ становился популярным.
Другие объектно-ориентированные языки, такие как Python, Eiffel, Objective-C, ObjectPascal/Delphi, Java, C# и многие другие, быстро последовали за ними.
Неизбежно, будучи выкованным в те бурные, объектно-ориентированные дни (около 1989), Windows NT была разработана с философией, согласно которой «все является объектом». На самом деле, одной из самых важных частей ядра NT является «Диспетчер объектов»!
Разработчики используют Windows Win32 API для доступа и управления объектами и структурами, которые обеспечивают доступ к аналогичной информации, предоставляемой псевдофайлами и инструментами *NIX. А поскольку синтаксические анализаторы, компиляторы и анализаторы понимают структуру объектов, многие ошибки кодирования часто можно обнаружить раньше, помогая убедиться, что намерения программиста синтаксически и логически правильны. Это также может привести к меньшему количеству поломок, волатильности и «оттока» с течением времени.
Итак, возвращаясь к нашему основному обсуждению консоли Windows: команда NT решила создать «консоль», которая отличалась бы от традиционного терминала *NIX в нескольких ключевых областях:
- API консоли : вместо полагаясь на способность программистов генерировать «сложные для проверки» последовательности ANSI/VT, консолью Windows можно манипулировать и управлять ею с помощью богатого консольного API
- Общие службы : чтобы каждая оболочка командной строки не повторно реализовывала одни и те же службы снова и снова (например, история команд, псевдонимы команд), сама консоль предоставляет некоторые из этих служб, доступных через консольный API
.
Хотя консольный API оказался очень популярным в мире инструментов и служб командной строки Windows, модель, ориентированная на API, создает некоторые проблемы для сценариев командной строки:
Командная строка Windows и межплатформенное взаимодействие
Многие инструменты и приложения командной строки Windows широко используют API консоли.
Проблема? Эти API работают только в Windows. Таким образом, в сочетании с другими отличительными факторами (например, различиями в жизненном цикле процессов и т. д.), приложения командной строки Windows не всегда легко переносятся на *NIX и наоборот.
По этой причине экосистема Windows разработала собственные, часто похожие, но обычно разные инструменты и приложения командной строки.
Это означает, что пользователям необходимо изучить один набор приложений и инструментов командной строки, оболочек, языков сценариев и т. д. при использовании Windows, а другой — при использовании *NIX.
Для этой проблемы не существует простого быстрого решения: консоль Windows и командная строка не могут быть просто выброшены и заменены bash и iTerm2, поскольку их сотни миллионов приложений, сценариев и инструментов, зависящих от консоли Windows и оболочек Cmd/PowerShell, многие из которых запускаются миллиарды раз в день на ПК и серверах Windows по всему миру.
Итак, какое здесь решение? Как разработчики запускают инструменты командной строки, компиляторы, платформы и т. д., изначально созданные в основном для платформ на основе *NIX?
Сторонние инструменты, такие как MinGW/MSYS и Cygwin, отлично справляются с портированием многих основных инструментов GNU и библиотек совместимости в Windows, но они не могут запускать неперенесенные, немодифицированные бинарные файлы Linux.
Это оказывается важным требованием, поскольку многие пакеты и модули Ruby, Python, Node и т. д. зависят от поведения Linux и/или «обертывают» бинарные файлы Linux.
Эти причины побудили Microsoft сделать так, чтобы подлинные, немодифицированные бинарные файлы и инструменты Linux запускались изначально в подсистеме Windows для Linux (WSL).
Используя WSL, пользователи теперь могут загружать и устанавливать один или несколько подлинных дистрибутивов Linux параллельно на одном компьютере и использовать диспетчер пакетов каждого дистрибутива или инструмента (например, apt, zypper, npm, gem и т. д.) устанавливать и запускать подавляющее большинство инструментов, пакетов и модулей командной строки Linux вместе с их любимыми приложениями и инструментами Windows. Чтобы узнать больше о WSL, посетите страницу обучения WSL или официальную документацию WSL.
Кроме того, есть еще некоторые возможности консоли, которые не были приняты терминалами других производителей: в частности, консоль Windows предоставляет службы истории команд и псевдонимов команд, цель которых — устранить необходимость в каждой оболочки (в частности) для повторной повторной реализации одной и той же функциональности.
Мы вернемся к этой теме в будущем.
Удаленное взаимодействие с командной строкой Windows затруднено
Как мы обсуждали в посте «Информация о командной строке», терминалы изначально были отделены от компьютера, к которому они были подключены. Перенесемся в сегодняшний день, этот дизайн остается: большинство современных терминалов и приложений / оболочек командной строки / и т. д. разделены процессами и/или машинными границами.
На платформах на основе *NIX представление о том, что терминалы и приложения командной строки являются отдельными и просто обмениваются символами, привело к тому, что к командным строкам *NIX легко получить доступ и управлять ими с удаленного компьютера/устройства: терминал и приложение командной строки могут обмениваться потоками символов через некоторый тип упорядоченной инфраструктуры последовательной связи (TTY/PTY/и т. д.), довольно просто удаленно управлять командной строкой компьютера *NIX.
Однако в Windows многие приложения командной строки зависят от вызова API консоли и предполагают, что они работают на том же компьютере, что и сама консоль.
Это затрудняет удаленное управление оболочками/инструментами/и т. д. командной строки Windows: как приложение командной строки, работающее на удаленном компьютере, вызывает API на консоли локального компьютера пользователя? И что еще хуже, как удаленное приложение командной строки вызывает консольный API, если доступ к нему осуществляется через терминал на компьютере Mac или Linux?!
Извините, что дразню, но мы вернемся к этой теме более подробно в следующем посте!
Запуск консоли… или нет!
Как правило, в системах на базе *NIX, когда пользователь хочет запустить инструмент командной строки, он сначала запускает терминал. Затем Терминал запускает оболочку по умолчанию или может быть настроен для запуска определенного приложения/инструмента. Терминал и приложение командной строки взаимодействуют, обмениваясь потоками символов через псевдотелетайп (PTY) до тех пор, пока один или оба не будут завершены.
Путаница с консолью
Однако в Windows все работает иначе: пользователи Windows никогда не запускают саму консоль (conhost.
exe): пользователи запускают оболочки и приложения командной строки, а не саму консоль!
СКАЗАТЬ ЧТО СЕЙЧАС?
Да, в Windows пользователи запускают приложение командной строки, а НЕ саму консоль . Если пользователь запускает приложение командной строки из существующей оболочки командной строки, Windows (обычно) прикрепляет только что запущенный .exe командной строки к текущей консоли. В противном случае Windows запустит новый экземпляр консоли и присоединит его к только что запущенному приложению.
Поскольку пользователи запускают Cmd.exe или PowerShell.exe и видят окно консоли, они работают в условиях распространенного заблуждения, что Cmd и PowerShell сами по себе являются «консолями»… они не ! Cmd.exe и PowerShell.exe — это «безголовые» приложения командной строки, которые необходимо подключить к экземпляру консоли ( conhost.exe ), из которого они получают пользовательский ввод и в который они выводят текстовый вывод для отображения пользователю.
.
Кроме того, многие люди говорят, что «приложения командной строки работают в Консоли». Это вводит в заблуждение и вносит дополнительную путаницу в то, как на самом деле работают консоли и приложения командной строки!
Пожалуйста, помогите исправить это заблуждение , если вы слышите его, указав, что «Инструменты/приложения командной строки запускают , подключенный к консоли» (или аналогичной). Спасибо! 😃
Итак, приложения командной строки Windows запускаются в своих собственных процессах, подключенных к экземпляру консоли, работающему в отдельном процессе. Это похоже на *NIX, где приложения командной строки запускаются подключенными к терминальным приложениям. Звучит хорошо, правда? Ну нет; здесь есть некоторые проблемы, потому что консоль работает немного по-другому:
- Консоль и приложение командной строки обмениваются данными через сообщения IOCTL через драйвер, а не через текстовые потоки (как в *NIX)
- Windows указывает, что ConHost. exe является консольным приложением, которое подключено к приложениям командной строки
- Windows управляет созданием коммуникационных «каналов», через которые консоль и приложение командной строки обмениваются данными
exe является консольным приложением, которое подключено к приложениям командной строкиЭто существенные ограничения, особенно последний пункт. Почему? Что, если вы хотите создать альтернативное консольное приложение для Windows? Как бы вы отправили клавиатуру/мышь/ручку/и т.д. действия пользователя в приложении командной строки, если вы не можете получить доступ к каналам связи, соединяющим вашу новую консоль с приложением командной строки?
Увы, история здесь не очень хорошая: ЕСТЬ несколько замечательных сторонних консолей (и серверных приложений) для Windows (например, ConEmu/Cmder, Console2/ConsoleZ, Hyper, Visual Studio Code, OpenSSH и т. д.), но им приходится прыгать через необычные обручи, чтобы вести себя как обычная консоль.
Например, сторонние консоли должны запускать приложение командной строки вне экрана, например, (-32000,-32000).
Затем они должны отправлять нажатия клавиш на закадровую консоль, очищать экран текстового содержимого закадровой консоли и перерисовывать его в своем собственном пользовательском интерфейсе! Я знаю, сумасшедший, да?! Это свидетельство изобретательности и решимости создателей этих приложений, что они вообще работают.
Совершенно очевидно, что мы хотим исправить эту ситуацию. Оставайтесь с нами, чтобы узнать больше об этой части истории — скоро будут хорошие новости.
Консоль Windows и VT
Как обсуждалось выше, Консоль Windows предоставляет богатый API. Используя Console API, приложения и инструменты командной строки записывают текст, изменяют цвета текста, перемещают курсор и т. д. А из-за наличия Console API в консоли Windows не было особой необходимости поддерживать последовательности ANSI/VT, обеспечивающие очень похожие функциональные возможности на других платформах. платформы. Фактически, до Windows 10 консоль Windows реализовывала только минимальную поддержку последовательностей ANSI/VT:
[
Все начало меняться в 2014 году, когда Microsoft сформировала новую команду консоли Windows, занимающуюся распутыванием и улучшением инфраструктуры консоли и командной строки Windows.
Одним из главных приоритетов новой команды консоли была реализация комплексной поддержки последовательностей ANSI/VT для обработки вывода приложений *NIX, работающих в подсистеме Windows для Linux (WSL) и на удаленных компьютерах *NIX. Вы можете прочитать немного больше об этой истории в предыдущем посте этой серии.
Команда консоли добавила всестороннюю поддержку последовательностей ANSI/VT в консоль Windows 10, что позволяет пользователям использовать и наслаждаться огромным набором инструментов и приложений командной строки Windows и Linux. Команда продолжает улучшать и совершенствовать поддержку VT в консоли с каждым выпуском ОС и благодарна за любые проблемы, о которых вы сообщаете в нашем трекере GitHub. определение каждого символа/глифа, используемого почти во всех системах письма на Земле, плюс многие неписьменные символы и изображения размером с символ (например, эмодзи), используемые сегодня. В настоящее время (июль 2018 г.
) Unicode 11 определяет 137 439 символов в 146 современных и исторических алфавитах! Unicode также определяет несколько кодировок символов, в том числе UTF-8, UTF-16 и UTF-32:
- UTF-8 : 1 байт для первых 127 кодовых точек (с сохранением совместимости с ASCII) и необязательный дополнительный 1-3 байта (всего 4 байта) для других символов
- UTF-16/UCS-2 : 2 байта на каждый символ. UCS-2 (внутренне используемый Windows) поддерживает кодирование первых 65536 кодовых точек (известных как базовая многоязычная плоскость — BMP). UTF-16 расширяет UCS-2, включая 4-байтовую кодировку для 17 дополнительных плоскостей символов
- UTF-32 : 4 байта на символ
.
Самая популярная кодировка сегодня, благодаря требованиям к эффективному хранению и широкому использованию на HTML-страницах, — это UTF-8. Оба UTF-16/UCS-2 распространены, хотя и реже в хранимых документах (например, веб-страницах, коде и т. д.
). UTF-32 редко используется из-за его неэффективности и больших требований к памяти. Отлично, теперь у нас есть эффективные и действенные способы представления и хранения символов Unicode!
Итак?
Увы, консоль Windows и ее API были созданы до того, как был создан Unicode. Консоль Windows сохраняет текст (который впоследствии отображается на экране) в виде символов UCS-2, требующих 2 байта на ячейку. Приложения командной строки записывают текст в консоль с помощью API консоли. Многие консольные API бывают двух видов: функции с суффиксом A обрабатывают однобайтовые/символьные строки, а функции с суффиксом W обрабатывают двухбайтовые (wchar)/символьные строки: например, функция WriteConsoleOutputCharacter() компилируется до WriteConsoleOutputCharacterA() для проектов ASCII или WriteConsoleOutputCharacterW() для проектов Unicode. Код может напрямую вызывать функции с суффиксом ...A или ...W , если требуется особая обработка.
Однако, хотя все API-интерфейсы W поддерживают UCS-2, а некоторые из них были обновлены для поддержки UTF-16, не все API-интерфейсы W полностью поддерживают UTF-16.
Кроме того, консоль не поддерживает некоторые новые функции Unicode, в том числе соединители нулевой ширины (ZWJ), которые используются для объединения отдельных символов, например, в арабском и индийском алфавитах, и даже используются для объединения нескольких символов эмодзи в один визуальный элемент. глиф, например смайлики «люди» и ниндзякоты.
Что еще хуже, текущий текстовый рендерер консоли не может даже отрисовывать эти сложные глифы, даже если буфер может хранить их: в настоящее время консоль использует GDI для рендеринга текста, но GDI не поддерживает должным образом возврат шрифта — механизм для динамического поиска и загрузки альтернативного шрифта, содержащего глиф, отсутствующий в текущем шрифте. Font-fallback хорошо поддерживается более современными механизмами рендеринга текста, такими как DirectWrite
Так что же произойдет, если вы захотите написать сложные и соединенные глифы на консоли? К сожалению, нельзя … пока, но это тоже пост в другой раз.
Еще раз, дорогой читатель, если вы прочитали все вышеизложенное, спасибо и поздравляем — теперь вы знаете о консоли Windows больше, чем большинство ваших друзей, и, вероятно, даже больше, чем вы хотели! Вам повезло 😛
В этом посте мы рассмотрели много вопросов:
- Основные строительные блоки консоли Windows:
- Condrv.sys — драйвер связи консоли
- ConHost.exe — интерфейс консоли, внутреннее устройство и сантехника:
- Сервер API — сериализует вызовы API и текстовые данные с помощью сообщений IOCTL, отправляемых в/из драйвера
- API — функционал Консоли
- Буферы — входной буфер для хранения пользовательского ввода, выходной буфер для хранения вывода/отображаемого текста
- VT Parser — преобразует последовательности ANSI/VT, встроенные в текстовый поток, в вызовы API
- Console UX — состояние пользовательского интерфейса консоли, настройки, функции
- Прочее — Разное срок службы, безопасность и т. д.
- Что делает консоль
- Отправляет пользовательский ввод в подключенное приложение командной строки
- Получает и отображает выходные данные подключенного приложения командной строки
- Отличие консоли от терминалов *NIX
- NIX: «Все является файлом/текстовым потоком»
- Windows: «Все является объектом, доступным через API»
- Проблемы с консолью
- Консольные приложения и приложения командной строки обмениваются данными через запросы вызовов API и текст, сериализованный в сообщения IOCTL
- Только приложения командной строки Windows вызывают API консоли
- Дополнительная работа по переносу приложений командной строки в/из Windows
- Приложения вызывают Windows API для взаимодействия с консолью
- Затрудняет удаленное взаимодействие с приложениями/инструментами командной строки Windows
- Зависимость от IOCTL нарушает конструкцию терминала «обмена символами».
д.