Введение в POSIX'ивизм

       

О режимах


Когда машины были большие, и когда к ним начали прикручивать дисплеи в качестве устройств вывода, дисплеи эти были разными - текстовыми или графическими.

Текстовые дисплеи в терминальных комплектах использовались чаще. Их особенность в том, что они в принципе были способны выводить символы только из некоего предопределенного набора, жестко прошитого в "железе" (в ПЗУ знакогенератора). Конечно, в такие наборы входили не только текстовые (то есть алфавитно-числовые) символы, но и, например, так называемая псевдографика (уголки, линейки и т.д.), с помощью которой можно было строить некие изображения (например, элементы меню). Но важно то, что выход за пределы предопределенного набора символов был невозможен (я помню времена, когда для обеспечения вывода символов кириллицы требовалось перепрограммирование знакогенератора, что и проделывалось нашими умельцами).

Графические дисплеи работали по другому принципу: на них изображение строилось, с помощью специальных алгоритмов, попиксельно. Что, соответственно, давало в принципе возможность вывода на экран совершенно произвольных вещей - любых наборов символов в различном шрифтовом оформлении, а также собственно изображений - векторных (то есть образованных линиями, описываемыми математическими уравнениями) или растровых (слагавшихся из наборов пикселей определенного цвета). Тем не менее, графические дисплеи по природе своей были устройствами растровыми - даже векторные кривые в конечном счете слагались из цепочек пикселей. Говорят, существовали и собственно векторные графические дисплеи, однако мне их видеть не приходилось, и что это такое - представляю весьма смутно.

С появлением персоналок собственно текстовые дисплеи (MDA и ранние Hercules'ы) быстро вышли из употребления. Видеосистемы IBM-совместимых машин, объединяющие в себе видеоадаптер (или, как часто говорят, видеокарту) и собственно монитор, стали графическими. Однако текстовый режим как таковой в них сохранился. Только теперь предопределенные наборы символов не прошивались в "железе", а загружались в видеокарту.
Именно программирование видеокарт и обусловило возможность создания простых способов работы с нелатинскими наборами символов (в том числе и кириллицей).

Постепенно текстовый режим вытеснялся различными графическими режимами (а были системы, изначально ориентированные на использование графики, такие, как MacOS или Amiga). И лишь в Unix-подобных операционках текстовый режим до недавнего времени прочно удерживал свои позиции - и в значительной мере именно благодаря поддержке виртуальных терминалов.

Часто неявным образом ставится знак равенства между текстовым режимом и режимом консольным (или режимом терминального доступа). В общем случае это неверно. Конечно, виртуальные консоли часто функционируют именно в текстовом режиме (в большинстве BSD-систем - почти исключительно в нем). Однако существует и понятие так называемой графической консоли, которое не следует смешивать с понятиями графических рабочих сред. Ибо это - самая обычная консоль, но изображения на ней (в том числе и текстовые символы) выводятся графическими средствами - то есть попиксельной прорисовкой, а не вытягиванием из предопределенного набора. Это возможно потому, что все современные (именуемые обычно VESA-совместимыми) видеокарты поддерживают так называемый линейный кадровый буфер (или Frame Buffer), допускающий прямое воспроизведение графики без использования специальных программных средств.

В принципе, с распространением жидкокристаллических мониторов, можно ожидать полного отмирания чисто текстовой консоли - уж больно неэстатично выглядит стандартный текстовый режим (80 колонок на 25 строк) на LCD-матрицах с физическим разрешением 1280x1024; не говоря уже о неэффективном использовании экранного пространства. Однако не думаю, что важность консоли от этого уменьшится. Как раз наоборот, именно режим фрейм-буфера позволяет заиграть ей дополнительными красками.

Таким образом, графическая консоль (или фрейм-консоль) знаменует собой плавный переход от чисто текстового режима к режиму графическому. Каковой в POSIX-системах может быть реализован различными способами.



Первый способ - только что упомянутая графическая консоль. Правда, до недавнего времени доступен этот способ был практически только в Linux, где требует лишь включения опции в конфигурации ядра (поддержка Frame Buffer для абстрактной VESA-совместимой видеокарты, или для одной из модельного ряда - ATI, Matrox и т.д.) и задания определенного параметра при загрузке (в большинстве современных user-ориентированных дистрибутивов это делается по умолчанию). После чего становится возможным изменение экранного разрешения в широких пределах - вплоть до 1280x1024, глубины цвета, просмотр изображений и даже видео.

Ядра NetBSD и OpenBSD, насколько мне известно, режима Frame Buffer не поддерживают. А во FreeBSD такая возможность теоретически могла быть включена, но только для фиксированного разрешения (800x600), да и на всех видеокартах, с которыми мне довелось иметь дело, выглядит это дело весьма убого.



Однако ныне в DragonFlyBSD режим графической консоли реализован ничуть не хуже, чем в Linux-консоли, позволяя выставлять произвольные (из числа поддерживаемых видеоадаптером) разрешения. И уже появились сведения о включении соответствующих патчей в ядро FreeBSD.

Однако не только ограничения операционок не позволяют считать фрейм-консоль полноценной графической системой. Главное - крайне малое количество собственно графических приложений, способных использовать возможности Frame Buffer. В их числе, фактически, - вьювер графических файлов, средство для создания скриншотов, изначально текстовый браузер links - и все. Да, еще Mplayer, собранный должным образом, может прокручивать видео во фрейм-консоли. Впрочем, эта великая программа способна проигрывать видео и в чисто текстовой консоли - передавая его ASCII-символами (весьма занятное зрелище, доложу я вам - правда, к кину как таковому отношения не имеющее).

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



Второй способ реализации графического режима в свободных POSIX-совместимых операционках - с помощью специализированной библиотеки SVGAlib. Сама по себе она разработана для ОС Linux, однако скомпилированные с ее использованием бинарные приложения можно запустить на любой BSD-платформе в так называемом режиме Linux-совместимости (своего рода эмуляции, основанной на подмене системных вызовов).

Хотя запускать-то особенно и нечего: на SVGAlib основано едва ли с полдюжины приложений (в числе которых, правда, знаменитый Doom). А поскольку проект этот практически прекратил свое развитие, ожидать существенного роста программ не приходится. Так что роль SVGAlib оказывается еще более ограниченной, чем графической консоли.

Таким образом, практически единственным универсальным способом реализации графического режима в POSIX-совместимых ОС оказывается оконная система X (X Window System), или, в просторечии, просто Иксы. Ибо X - это ее имя собственное (возникшее потому, что исторически ей предшестоввала другая графическая система, именовавшаяся W), а Window в ее названии - прилагательное, призванное подчеркнуть ее оконную природу - в противоположность полноэкранным графическим системам. Ведь в прежние времена таких существовало немало (примером чему - та же SVGAlib).

Начинающими пользователями Linux Иксы воспринимаются как неотъемлемая часть этой операционной системы. Однако это не так: оконная система X создавалась совершенно независимо не только от Linux, но и от Unix вообще. И назначением ее было - обеспечивать графический режим работы на любых машинах, как-то способных вообще поддерживать графику, и поверх любых операционок.

Свободные реализации оконной системы X (а есть еще и сугубо коммерческие ее варианты, используемые в проприетарных Unix'ах) - "правильная" Xorg и "неправильная" Xfree86, - абсолютно идентичны в Linux'е, Free-, Net- и прочих BSD. И все приложения, написанные в расчете на запуск в абстрактных Иксах, будут с равным успехом работать в любой из этих операционок.



Главной составной частью Иксов вообще (и XFree86 или Xorg в частности) является программа, именуемая X-сервером (собственно, устройством X-сервера и его функциональностью и различаются разные варианты реализации оконной системы X). Она запускается непосредственно на данной машине, и взаимодействует с ее "железом" - устройствами ввода, то есть мышью и клавиатурой, и вывода - видеоподсистемой. А уже поверх X-сервера могут быть запущены разнообразные клиентские приложения. Причем, вопреки обычному пониманию терминов "клиент" и "сервер", именно они могут иметь своим местопребыванием не локальную машину, а любую другую, доступную по сети (опять же любой - локальной или глобальной).

Один из важнейших X-клиентов - программа терминального доступа, позволяющая эмулировать обычную текстовую консоль для ввода команд (и запуска любых программ вообще), почему ее и именуют еще эмулятором терминала. Таких эмуляторов существует великое множество, но минимум один - xterm, - всегда будет в распоряжении пользователя, так как входит в штатный комплект любой реализации Иксов.

Не менее важен и другой класс X-клиентов - программы управления элементами графического интерфейса, так называемые оконные менеджеры (Window Managers).Коих тоже преизрядное количество, но в состав Иксов стандартно входит лишь один - весьма архаичный twm.

Кое-что об Иксах уже говорилось во вводной части, подробностям же ее устройства будет посвящена , глава. А нам тем временем пора переходить к рассмотрению вопроса


Содержание раздела