Понимание того, как вещи выводятся на экран (cout, printf) и происхождение действительно сложных вещей, которые я не могу найти в учебниках

Ну, они проходят через кучу библиотечных функций и в конечном итоге вызывают системный вызов write (), который отправляет данные в соответствующий файловый дескриптор, который затем вызывает вызов read () в эмулятор терминала (или оболочка командного окна, если это Windows). Терминал / оболочка заставляет эти данные отображаться на экране, вероятно, с помощью множества системных вызовов для отправки их в графическую систему.

Терминология Windows и Unix / Linux сильно различается, особенно концепция оболочки в каждой из них не одно и то же. Но использование вызовов read () и write () в обоих случаях очень похоже.

Системные вызовы - это специальные функции, которые заставляют ядро ​​выполнять определенные действия; то, как они реализованы, довольно волшебно и очень зависит от того, какой у вас процессор, но обычно это вызывает некоторую исправляемую ошибку процессора, которую ядро ​​должно привести в порядок.

Взломайте, откройте исходный код на glibc и убедитесь сами.

Короткий ответ, много кода C, иногда присыпанного ассемблером.

Волшебство действительно происходит в драйвере устройства. ОС представляет собой интерфейс, к которому могут подключиться прикладные программисты. Это немного массируется (например, буферизуется), а затем отправляется на устройство. Затем устройство принимает общее представление и преобразует его в сигналы, которые может понять конкретное устройство. Таким образом, ASCII отображается в разумном формате на консоли, в файле PDF, на принтере или на диске в форме, подходящей для этого устройства. Попробуйте что-нибудь другое, кроме ASCII (или UTF8), которое драйвер не понимает, и вы поймете, о чем я говорю.

Для вещей, которые операционная система не может обрабатывать (например, специальных видеокарт), приложение записывает данные непосредственно в память устройства. Вот как работает что-то вроде DirectX (чтобы значительно упростить).

Каждый драйвер устройства индивидуален. Но все они одинаковы с точки зрения того, как они взаимодействуют с ОС, по крайней мере, для каждого класса устройств (диск, сетевой адаптер, клавиатура и т. Д.).

Итак, в основном, как создаются эти функции? .. это сборка ?, если да, то с чего это начинается ?. Это вызывает больше вопросов, например, как вообще они сделали функции openGl / directx.

Эти функции могут быть ассемблерными или C, они не сильно меняются (и, в любом случае, вы можете делать на C практически все, что вы можете делать на ассемблере.) В конечном итоге волшебство происходит в интерфейсе программного и аппаратного обеспечения - как добраться туда из printf и cout << может быть столь же тривиально, как несколько указателей. операций (см. пример 286 ниже или прочтите о cprintf ниже) или столь же сложными, как прохождение нескольких уровней различных системных вызовов, возможно, даже через сеть, прежде чем в конечном итоге затронуть ваше оборудование дисплея.

Представьте себе следующие сценарии :

1. Я выкапываю свой старый 286 из-под пыли и запускаю MS-DOS; Я компилирую и запускаю следующую программу в реальном режиме :

    void main (void) {
   far long * pTextBuf = (far long *) 0xb8000L; 
    / * Gotoxy бедняги + имитация cprintf - отображать "C:" (0x43,0x3a) 
   серебряными буквами на черном в верхнем левом углу экрана * / 
    * pTextBuf = 0x073a0743L ; 
   } 
    

2. Я подключаюсь с помощью Windows HyperTerminal моего ноутбука к своему последовательному порту, который подключен с помощью кабеля к задней части блока SUN, через который я могу получить доступ к моему SUN консоль коробки. С этой консоли я перехожу по ssh в другой ящик в сети, где запускаю свою программу, которая выполняет printf , передавая свой вывод через more . Информация printf прошла по каналу через more , затем через псевдотерминал SSH через сеть в мой блок SUN, оттуда через последовательный кабель на мой ноутбук, через Windows «Функции рисования текста GDI перед тем, как наконец появиться на моем экране.

Добавление дополнительных деталей к ответу Нормана , надеюсь, больше в направлении вашего исходного вопроса:

• printf и cout << обычно выполняет запись в stdout - обычно буферизированная запись, но так было не всегда
  • в свое время, различные поставщики компиляторов (Borland, Microsoft), особенно DOS предоставила вам такие функции, как cprintf , которые записывают непосредственно в видеопамять без каких-либо системных вызовов, стиль memcpy (см. Мой пример 286 выше) - - подробнее об этом ниже
• запись в stdout является системным вызовом, будь то запись под * nix, WriteFile или WriteConsole ] под Windows, INT 21, 9 под DOS и т. д.
• Преимущество использования абстракции stdout заключается в том, что она позволяет операционной системе выполнять некоторые внутренние сантехника и выполнить перенаправление (будь то tty дескриптор, в канал, в файл, в последовательный порт, на другую машину через сокет и т. д.)
  • он также косвенно позволяет иметь несколько приложений » stdout сосуществуют на одном экране, например в разных окнах - то, что было бы намного сложнее сделать, если бы каждое приложение пыталось записывать непосредственно в видеопамять самостоятельно (как cprintf сделал в DOS - не что было бы называется сегодня настоящей или пригодной для использования многозадачной операционной системой.)
• в настоящее время графическое приложение , такое как приложение окна консоли rxvt , клиент Telnet / ssh PuTTY, консоль Windows и т. Д., Будет: {{1 }}
  • прочтите stdout вашего приложения:
    • из дескриптора tty (или его эквивалента) в случае rxvt или консоль Windows
    • через последовательный порт, если вы используете что-то вроде Realterm для подключения к встроенной системе или к старой консоли SUN
    • из сокета, если вы используете PuTTY в качестве клиента telnet
  • , отобразите информация, отображаемая графически,пиксель за пикселем , в буфер окна графического приложения / контекст устройства и т. д.
    • это обычно делается через еще один уровень абстракции и систему вызовы (такие как GDI, OpenGL и т. д.)
    • , информация о пикселях в конечном итоге попадает в линейный буфер кадра , то есть в выделенный диапазон памяти (еще во времена 8-мегагерцовых процессоров, задолго до AGP , эта область может находиться в системной RAM, в настоящее время это могут быть мегабайты и мегабайты двухпортовой RAM на самой видеокарте)
    • видеокарта (то, что раньше называлось RAMDAC ), будет периодически читать диапазон памяти кадрового буфера (например, 60 раз в секунду, когда ваш адаптер VGA установлен на 60 Гц), строка за строкой развертки (возможно, выполняя поиск по палитре ) ), и передавать его на дисплей в виде аналоговых или цифровых электрических сигналов
• в свое время или даже сегодня, когда вы загружаете свой * nix box в однопользовательском режиме или продолжаете работать. l-screen в консоли Windows, ваш графический адаптер фактически находится в текстовом режиме
  • , а не в линейном буфере кадров, один (будь то реализация cprintf или ОС) записывает в ] гораздо меньший размер 80x25 или 80x50 и т. д. текстовый буфер массив, где (например,в случае VGA) только два байта необходимы для кодирования каждого значения символа, такого как A или ▒ или ♣ (1 байт), а также его цвет атрибуты (1 байт) - то есть его передний план (4 бита или 3 бита + бит яркости) и цвета фона (4 бита или 3 бита + бит мигания)
  • для каждого пикселя на каждой строке сканирования, RAMDAC:
    • будет отслеживать, какой текстовый столбец и какая текстовая строка принадлежит пикселю
    • , будет искать значение символа позиции столбца / строки, а атрибуты
    • будут искать символ значение против простого определения шрифта растрового изображения
    • будет видеть, должен ли отображаемый пиксель в определении растрового изображения глифа значения символа быть установлен на передний план или фон, и какой цвет будет основан на атрибуте символа в этом позиция
    • , возможно, перевернуть передний план и фон на четные секунды, если бит мигания был установлен или курсор отображается и находится в текущей позиции
    • . e pixel

Начните со страниц История видеокарт и GPU в Википедии, чтобы подробнее узнать, как мы достигли сегодняшнего положения.

Также посмотрите Как работают графические процессоры и Как работают графические карты .