8½, оконная система Plan 9

Роб Пайк
rob@plan9.bell-labs.com
АБСТРАКТНО

8½ является оконной системой Plan 9, она обеспечивает текстовый ввод-вывод и сервисы растровой графики, как для локальных, так и для удаленных клиентских программ, обслуживая мультиплексируемый набор файлов этих клиентов. Доступ к мыши и экрану обеспечивают традиционные Unix файлы типа /dev/tty. Операции с растровой графикой в системе выполняются путем обращения к файлу /dev/bitblt, куда клиенты записывают кодированные сообщения для выполнения графических операций. 8½ необходимы те же файлы для ее собственного внедрения (она мультиплексирует свой интерфейс), поэтому она может работать рекурсивно, как клиент самой себя. Такая архитектура имеет много преимуществ и является легко осуществимой.

Введение

В 1989 году мною была создана модельная оконная система всего лишь из нескольких сотен строк кода на языке программирования по-умолчанию и необычная архитектура связывания параллельных процессов [1]. Так как система получилась элементарной, она продемонстрировала, что оконные системы в сущности не являются сложными. В этом же году оконная система была переписана на языке С для новой распределенной операционной системы Plan 9 [12] и получила название 8½. На дисплеях с разными цветовыми возможностями 8½ обеспечивает сервисы, необходимые современной оконной системе, включая программируемость и поддержку удаленной графики. Вся система, включая программу типа xterm [2] с функциями «вырезать и вставить» между окнами, находилась в пределах 90 KB исходного текста для процессора Motorola 68020. Это около половины размера ядра операционной системы, которое поддерживает ее, и десятой части размера X сервера [17] без xterm.

Так что же делает 8½ такой компактной? Большая часть сбережений происходит от общей простоты: 8½ содержит малое число графической фантастики, осмысленный интерфейс программирования, и небольшой, фиксированный пользовательский интерфейс. Часто решения в системе принимаются путем фиата — это трехкнопочная мышь, перекрывающиеся окна, встроенная терминальная программа и оконный менеджер, и т.п., а не путем удовлетворения вкусовых особенностей всех и каждого. Стоит отметить, что компактность 8½ не аскетична. Чтобы сделать использование удобным, она обеспечивает как основы, так и достаточное количество расширенных возможностей. Наиболее важным фактором, повлиявшим на ее небольшой размер, является разработка общей конструкции в виде файлового сервера. Структура такого типа может применятся в оконных системах традиционных Unix-подобных операционных систем.

Небольшой размер не оказывает влияния на функциональность оконной системы: она обеспечивает сервисы практически эквивалентные X Window. Хотя клиенты 8½ могут быть какой угодно сложности, тенденция имитирования конструкции 8½ и ее чистого интерфейса программирования приводят к тому, что они не такие раздутые как приложения Х.

Пользовательская модель

8½ может быть представлена в одном из двух вариантов: как единый экран, мышь и клавиатура терминала (в терминологии Plan 9) или же как массив независимых виртуальных терминалов рабочей станции (в коммерческой терминологии). Терминалы, в свою очередь, также делятся на две категории: текстовые (с поддержкой оболочки и обычного набора инструментальных средств) и графические (использующие всю мощь растрового экрана и мыши). Текст представлен в UTF — кодировке стандарта Unicode [12]. Механизм работы программного интерфейса основан на чтении и записи файлов из каталога /dev.

Исторически сложилось так, что общая модель и внешний вид 8½ подобны системе mux [9]. Как раз на них и остановимся не на долго. Правая кнопка мыши выводит меню управления окнами. Когда создается новое окно, в нем запускается оболочка по-умолчанию (в нашем случае это rc [1]). Стандартные ввод и вывод оболочки ориентированы окну и доступны через файл /dev/cons (console), аналогично /dev/tty в Unix. Смена названия этого файла говорит о разрыве с прошлым: Plan 9 не поддерживает телетайповую модель терминалов.

Графические приложения, как и обычные программы, запускаются путем ввода их имен в окне оболочки. Таким образом, приложение занимает окно, в котором было запущено; чтобы запустить приложение в новом окне, необходимо использовать внешнюю программу под название window, ее описание дается ниже. Для графических приложений модель виртуального терминала расширена отчасти. Она позволяет программам выполнять графические операции, доступ к мыши, и связанные функции путем чтения и записи файлов с именами типа /dev/mouse и /dev/window, мультиплексируемыми в окно подобно /dev/cons. Реализация и семантика этих файлов, как будет описано ниже, является центральной структурой 8½.

Программа по-умолчанию, запускаемая в окне, знакома пользователям терминалов Blit [6]. Она подобна таковой в mux [9], обеспечивающей мыше-основанное редактирование ввода и вывода, возможность прокрутки назад для просмотра недавнего вывода, и т.д. 8½ имеет уникальную особенность, вытекающую из ее строения. Реализуясь как файловый сервер, она обладает возможностью отложенного ответа на запросы чтения для конкретного окна. Эта опция переключается зарезервированной клавишей клавиатуры (ESC). Нажав ее один раз, вы приостановите чтение клиента из окна; повторное нажатие восстанавливает нормальное чтение, которое построчно поглощает любой текст. Таким образом, пользователь может редактировать многострочный входной
текст на экране до того, как приложение увидит его; устраняется необходимость включения отдельного редактора для подготовки текста, например, почтовых сообщений. С этим связана и возможность ответа на считывания непосредственно из структуры данных, определяющих текст на дисплее: текст можно редактировать до тех пор, пока его конечная новая строка делает подготовленную строку текста считываемой для клиента.

Plan 9 и 8½

Plan 9 — это распределенная система, обеспечивающая поддержку Unix-подобных приложений в среде, которая построена из различных CPU серверов, файловых серверов и терминалов, соединенных в различные сети [12]. Терминалы сравнимы со скромными рабочими станциями, которые подключены к файловому серверу через сеть среднего масштаба типа Ethernet. Они самодостаточные компьютеры, запускающие полную операционную систему. Тем не менее, в отличие от рабочих станций, их задача заключается в обеспечении доступного мультиплексного пользовательского интерфейса для остальной части системы: они запускают оконную систему и поддерживают простые интерактивные задачи, такие как текстовое редактирование. Таким образом, они лежат примерно между рабочими станциями и X терминалами по конструкции, цене, производительности и функциональности. (Терминалы могут использоваться и для общих вычислений, но на практике пользователи Plan 9 выполняют свои вычисления на CPU серверах.) Терминальное программное обеспечение Plan 9, включая 8½, было разработано на 68020-основаной машине под названием Gnot и портировано на NeXTstation, MIPS Magnum 3000, SGI Indigos и Sun SPARC — все малые рабочие станции, которые мы используем в качестве терминалов, также как и PC.

Ресурсоемкие задания типа компиляции, текстовой обработки и научных вычислений выполняются на CPU серверах, которые соединены с файловыми серверами высокоскоростными сетями. При интерактивной работе эти вычисления могут быть доступны терминалам. Терминал и CPU сервер могут использоваться конкретным пользователем, если они подключены к одному файловому серверу, даже через разные типы сетей; Plan 9 обеспечивает независимый от расположения сети вид файлового сервера.

Компоненты Plan 9 соединены посредством общего протокола, основанного на распределении ресурсов. Все ресурсы в сети реализованы как файловые серверы; если программам необходим доступ к ним, то осуществляется соединение через сеть и связь с использованием обычных файловых операций. Необычным аспектом в Plan 9 является пространство имен процесса, т.е. набор файлов, который может быть доступен по имени (например, посредством системного вызова open), он не глобален для всех процессов машины; разные процессы имеют разные пространства имен. Система обеспечивает методы, благодаря которым процессы могут менять свои пространства имен, т.е. способность подмонтировать сервис в существующий каталог, сделав файлы сервиса видимыми в каталоге. (Эта операция сильно отличается от ее Unix тезки.) Многочисленные сервисы могут монтироваться в один каталог, при этом допускается возможность доступа многочисленных сервисов. Опции системного вызова mount управляют порядком поиска файлов в таком союзном каталоге.

Наиболее очевидным примером сетевого ресурса считается файловый сервер, основной задачей которого является постоянное хранение файлов. Также существует большое количество необычных сервисов, чья конструкция в различных средах может отличаться от файловоподобной. Множество таких сервисов описаны в другом документе [12]; некоторые из примеров представлены последовательностью процессов для отладки, они имеют много общего с файлами процессов Киллиана (Tom Killian) для 8-ой версии Unix [5], и реализация пар имя/значение среды Unix exec как файлов. Пользовательские процессы также должны реализовываться как файловые сервисы и быть доступными для клиентов через сеть, они очень похожи на «подмонтированные байт-ориентированные потоки» (mounted streams) в 9-ой версии Unix [15]. Типичный пример — программа, интерпретирующая внешне описанную файловую систему, такую как на CD-ROM дисках или стандартной Unix системе, и делает ее содержимое доступным для программ Plan 9. Такая конструкция использовалась во всех распределенных приложениях Plan 9, включая 8½.

8½ обслуживает набор файлов из стандартного каталога /dev с именами типа cons, mouse и screen. Клиенты 8½ общаются с оконной системой при помощи чтения и записи этих файлов. К примеру, клиентская программа, такая как оболочка, может выводить текст путем записи своего стандартного вывода, который автоматически соединяется с /dev/cons, или же путем явного чтения и записи этого файла. Тем не менее, в отличие от файлов, сохраняемых как традиционные файловые серверы, пример /dev/cons подается в каждом окне 8½ как некий четкий файл; пространства имен процессов Plan 9 позволяют 8½ обеспечивать уникальный /dev/cons каждому клиенту. Хорошей иллюстрацией этого механизма является создание нового клиента 8½.

Когда запускается 8½, она создает дуплексный канал, который представляет собой средство связи для сообщений, реализующих файловый сервис. Один конец распределяется между всеми клиентами, другой же, в свою очередь, организовывает поддержку 8½ для принятия запросов ввода-вывода. Когда пользователь, используя мышь, создает новое окно, 8½ распределяет оконные структуры данных и раздваивает порожденный процесс. Порожденное пространство имен, первоначально сохраняемое с порождающим, затем удваивается, таким образом изменения, проводимые в нем, не влияют на порождающее пространство имен. После этого порожденное пространство подключает свой конец соединительного канала, cfd, к каталогу /dev посредством системного вызова монтирования:

Этот вызов подключает сервис, ассоциированный с файловым дескриптором cfd (клиентский конец канала), к началу /dev, так что эти файлы в новом сервисе получают больший приоритет, чем существующие в этом каталоге файлы. Эта процедура делает новые файлы cons, mouse и т.п., доступными в /dev, выполняя скрытие файлов с одинаковыми именами. Аргумент buf — это символьная строка (нулевая в нашем случае), описываемая ниже.

Клиентский процесс затем закрывает файловые дескрипторы 0, 1 и 2 и многократно открывает /dev/cons для соединения стандартных файлов ввода, вывода и ошибок с оконным /dev/cons. Для начала выполнения оболочки в окне применяется системный вызов exec. Вся последовательность, вместе с обработкой ошибок, составляет 33 строки кода на С.

Вид этих событий из конца канала 8½ представляет собой последовательность сообщений файлового протокола от нового клиента. Последовательность генерируется операционной системы в ответ на системные вызовы mount и open, которые выполнил клиент. Сообщение, сгенерированное mount, информирует 8½ о том, что новый клиент подключился к файловому сервису, который она представляет; ответ 8½ — это уникальный идентификатор, который охраняется операционной системой и передается со всеми сообщениями, сгенерированными вводом-выводом происходящих от этого mount файлов. Этот идентификатор используется 8½ для различия клиентов, каждый из которых видит уникальный /dev/cons; большинству серверов не требуется делать эти различия.

Процесс, не имеющий отношения к 8½, для создания окон должен использовать именно этот вариант механизма. Когда запускается 8½, она использует сервис Plan 9 чтобы «отправить» клиентский конец соединительного канала в общественное место. Процесс должен открыть этот канал и подмонтировать его к подключению оконной системы, во время этого пути X клиент должен соединиться с Unix доменным сокетом сервера, связанного с файловой системой. Последний аргумент mount посылается операционной системой как не интерпретированный. Он делает возможным обмен информацией между клиентом и сервером во время монтирования. 8½ интерпретирует этот аргумент как размеры окна, которое будет создано для нового клиента. (В описанном выше случае, окно будет создано за время вызова mount, при этом buf не будет нести никакую информацию.) Когда происходит возврат mount, процесс может открывать файлы нового окна и начинать ввод-вывод для его использования.

Так как интерфейс 8½ основан на файлах, для управления им могут использоваться стандартные системные утилиты. К примеру, способ создания окон внешне упакован в 16-строчный сценарий оболочки под названием window, основа которого — простая операция монтирования, которая приписывает каталог 8½ к /dev и запускает команду, введенную в строке аргументов:

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

Другие основные характеристики системы естественно выпадают из файловоподобной модели. Когда пользователь удаляет окно, 8½ отправляет эквивалент Unix сигнала группе процессов (клиентам в окне), удаляет окно с экрана и обрубает входящие соединения к файлу, который управлял им. Если клиент игнорирует сигнал и продолжает запись в окно, он начнет получать ошибки ввода-вывода. Если, с другой стороны, все процессы в окне спонтанно завершат свою работу, они автоматически закроют все соединения с окном. 8½ выполняет счет количества ссылок на файлы окна; когда ссылок нет, она закрывает окно и удаляет его с экрана. Другой пример, когда пользователь нажимает клавишу DEL для генерации прерывания, 8½ записывает сообщение в специальный файл, обеспечиваемый интерфейсом управления процессами Plan 9, который и прерывает выполнение всех процессов в окне. Все эти примеры работают совершенно аналогично через сеть.

Реализация оконной системы посредством мультиплексирования /dev/cons и других подобных файлов дает два ценных эффекта. Первый, автоматически решается проблема подачи значимой интерпретации файлу /dev/cons (/dev/tty) в каждом окне. Обеспечение /dev/cons — это основное задание оконной системы, а не тяжелое бремя; чтобы вести себя предсказуемо в окне другие системы должны часто делать специальные организации для /dev/tty. Второй, любая программа может получить доступ к серверу, включая процесс на удаленной машине, и к файлам, используя стандартные системные вызовы read и write для общения с оконной системой, и стандартные вызовы open и close для подключения к ним. Чтобы сделать возможным использование всех графических особенностей 8½, не требуется никаких специальных организаций для удаленных процессов.

Графический ввод

Безусловно, 8½ представляет клиентам нечто большее, чем просто ASCII ввод-вывод. Состояние мыши можно узнать, прочитав файл /dev/mouse, который возвращает десяти байтовое кодированное сообщение состояния кнопок и позиции курсора. Если с момента последнего чтения /dev/mouse мышь не передвигалась или же, если окно, ассоциированное с примером /dev/mouse, не находится в «фокусе ввода», то проводится чтение блоков.

Формат сообщения таков:

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

Для клавиатурного ввода, клиенты могут читать /dev/cons или же, если им нужен символ-за-один-раз ввода, /dev/rcons (raw console). Нет явного механизма помощи клиентам при чтении из многочисленных источников. Взамен, может использоваться небольшая (365 строк) внешняя библиотека поддержки. Она подключает процесс к различным блокирующим источникам ввода — к мыши, клавиатуре, и, возможно, третьему пользовательскому файловому дескриптору — и суммирует их ввод в один канал, из которого могут считываться разные типы событий в традиционном стиле. Этот пакет является побочным. Как обсуждалось в предыдущем документе [10], я предпочитаю освобождать приложения от программирования, основанного на событиях. К сожалению, я не вижу легче путь для достижения этого в одно-потоковых программах на C, и я не склонен требовать от всех программистов овладевать параллельным программированием. (Смотрите программу-пример в конце документа.)

Графический вывод

Файл /dev/screen может быть прочитан любым клиентом для получения изображения всего экрана, например для печати (см. Рис. 1). Аналогично, /dev/window хранит содержимое текущего окна. Эти файлы только для чтения.

Рис. 1. Здесь показан экран 8½, запущенной на NeXTstation в Plan 9 (без ПО NeXT). Справа вверху находится программа, анонсирующая поступающую почту. По середине и слева — броузер для астрономических баз данных и созданное им изображение галактики. Снизу слева находится экранный редактор sam [8], в котором выполняется редактирование японского текста в кодировке UTF, и наконец, снизу справа — запущенная рекурсивно 8½, внутри которой просмотрщик вывода troff. Под faces в маленьком окне запущена команда, которая сохраняет изображение экрана путем передачи /dev/screen утилите растрового вывода.

Для выполнения графических операций в окнах, клиентские программы имеют доступ к /dev/bitblt. Он реализует протокол, кодирующий операции с растровой графикой. Большая часть сообщений в протоколе (всего их 23, половина из которых отвечает за управление многоуровневыми шрифтами для эффективной обработки символов Unicode) передается (посредством записи) от клиента к оконной системе для выполнения графической операции типа bitblt [14] или, скажем, прорисовки символа; несколько сообщений содержат информацию, возвращаемую клиенту (посредством чтения). Также как и в /dev/mouse, протокол /dev/bitblt имеет определенный порядок байт. Например, вот формат сообщения bitblt:

Сообщение, тривиально созданное из bitblt подпрограммы в библиотеке, выглядит так:

Поля «идентификатора» в сообщении указывают на другую особенность 8½: клиенты не хранят локально фактические данные для любых своих растров. Взамен, для распределения растра протокол обеспечивает сообщение, сохраняемое на сервере, и возвращает клиенту идентификатор целого типа (это схоже с файловыми дескрипторами Unix), который будет использоваться в операциях над этим растром. Число растра 0 обычно является клиентским окном, аналогично к стандартному вводу для файла ввода-вывода. Фактически, на клиентской машине не выполняется никаких операций с растровой графикой, все они выполняются на стороне сервера. Опять же, использование стандартных операций над удаленным файлом в Plan 9 позволяет работать без графических возможностей на машинах, таких как CPU сервер. Аналогичные характеристики в оконной системы Andrew [3] и X [17] требуют более сложных механизмов.

8½ не может сама работать непосредственно на растрах. Взамен, чтобы выполнить графические операции, она вызывает другой сервер, используя идентичный протокол. Операционная система для терминалов содержит внутренний сервер, реализующий схожий с 8½ протокол, но лишь для одного клиента. Этот сервер сохраняет фактические байты для растров и реализует основные операции с растровой графикой. Таким образом, среда, в которой запускается 8½, имеет структуру, идентичную обеспечиваемой ею клиентам; 8½ воспроизводит среду для своих клиентов, мультиплексируя интерфейс для поддержки раздельности клиентов.

Безусловно, этот способ мультиплексирования путем имитации может применяться не только в оконных системах, он также имеет некоторые сторонние эффекты. Поскольку 8½ имитирует свою собственную среду для клиентов, она может быть запущена в одном из своих окон (см. Рис. 1). Полезное и общее приложение, построенное по этой технологии, — соединение окна с удаленной машиной, такой как CPU сервер, а затем запуск оконной системы там, чтобы каждое подокно автоматически появлялось на удаленной машине. Это также удобный способ для отладки новой версии оконной системы или создания среды, например, с другим шрифтом по-умолчанию.

Реализация

Для представления графики клиентам 8½, по большей части, лишь мультиплексирует и передает через свой собственный сервер запросы клиентов. Она редко перестраивает сообщения для поддержки вымысла, что у клиентов уникальные экраны (окна). Для управления перекрывающимися окнами она использует модель слоев, которая обрабатывается отдельной библиотекой [7]. Таким образом, 8½ остается совсем мало работы и она достаточно простая программа; ею командуют несколько операторов переключения для интерпретации растра и протоколов файлового сервера. Встроенная оконная программа вместе с ассоциированными с ней меню и поддержкой текстового управления отвечают за большую часть кода.

Сервер операционной системы также компактен: версия для процессора 68020 без реализации полдюжины операций над растровой графикой — 2295 строк кода на С (опять, половина из которых отвечает за работу со шрифтами); графические операции — еще 2214 строк.

8½ структурирована как множество связанных сопрограмм, большинство из которых описано в документе 1989 года [10]. Одна сопрограмма управляет мышью, другая — клавиатурой, еще одна отвечает за управление состоянием каждого окна и ассоциированного с ним клиента. Когда не требуется запуск сопрограммы, 8½ читает следующий файловый запрос ввода-вывода, который приходит периодически по полнодуплексному соединительному каналу. Таким образом, 8½ полностью синхронна.

Исходный код программы не велик и компилируется за 10 секунд в нашей среде Plan 9. Все десять исходных файлов и один makefile составляют 5100 строк. Включается исходный код процесса оконного управления, терминальная программа вырезать-и-вставить, сам сервер окно/файл, и небольшая библиотека сопрограмм (proc.c). В программу не входит ни библиотека слоев (еще 1031 строка), ни библиотека управления вырезкой и вставкой текста, отображаемого в окне (960 строк), ни общая библиотека поддержки графики, которая управляет всеми не рисованными аспектами графики — арифметика с точками и прямоугольниками, управление памятью/ошибками, клиппинг, — плюс шрифты, события, и операции не примитивного рисования, такие как окружности и эллипсы (финальные 3051 строка). Сама 8½ не использует все части этих библиотек; в частности, большая часть графической библиотеки используется клиентами. Таким образом, несколько некорректно суммировать все эти числа, включая 4509 строк поддержки в ядре, и прийти к общему размеру реализации 8½ в 14651 строку. Это исходный код для разработки всей оконной системы 8½, от самых нижних уровней — до самых высоких.

Также важна реализация. Производительность 8½ конкурентоспособна системе X Window. По сравнению с использованием закладок gbench Dunwoody и Linton на 68020, распространяемых с «X Test Suite», скорость прорисовки окружностей и арок примерно одинакова с 8½, также как и с 4-й версией X11, скомпилированной при помощи gcc на эквивалентном оборудовании (возможно, потому что они реализованы вызовами примитивов point в пользовательской библиотеке). Скорость прорисовки линий примерно одинакова между двумя системами. Скорость прорисовки текста в кодировке Unicode в 8½ одинакова с текстом ASCII в Х, а тест bitblt в четыре раза быстрее для 8½. Эти результаты показывают, что архитектура 8½ является удачной и ни о каком уменьшении производительности не может быть и речи. И напоследок, загрузка 8½ выполняется за секунду, а создание нового окна почти мгновенное.

Пример

Здесь приведен пример полной программы, запускаемой в 8½. Она выводит строку «hello world» в место нажатия левой кнопки мыши, и завершает свою работу, если нажата правая кнопка мыши. Она также выводит строку в центре окна и управляет ею при изменении размера окна.

Полностью загруженный двоичный файл занимает 26 KB памяти на 68020. Эта программа может быть объединена с ей подобными в великолепном документе Роузенталя (David Rosenthal) [16]. (Текущая программа делает больше: в ней также применяется мышь.) Неуклюжей частью кода является функция ereshaped, которая вызывается из библиотеки событий, если окно изменяет форму или перемещается. (Простые, так называемые, незащищенные события не являются событиями в 8½; за них отвечает библиотека слоев.) Урок этой программы, со ссылкой на Роузенталя, в том, что если оконная система хорошо спроектирована, toolkit необязателен для простых задач.

Статус

1992 год, 8½ ежедневно используется почти всеми 60 членами нашего исследовательского центра. Одни используют ее для доступа к Plan 9, другие как вход для удаленных Unix систем.

Скоро в 8½ произойдут изменения. Неплохой является идея расширения возможностей работы оконной системы с оболочкой. Аналогичный этому документу [11] предлагает один метод решения, но в нем приходится забыть о графической функциональности. Возможно, текстовая версия файла /dev/bitblt могла бы увеличить характеристики системы, к примеру, это дало бы возможность awk программам непосредственно рисовать графы.

Может ли этот стиль оконной системы быть создан на другой операционной системе? Основная часть конструкции 8½ зависит от ее структуры как файлового сервера. В принципе, это можно сделать для любой системы, поддерживающей пользовательские процессы, которые хранятся в файлах. Это могут быть системы, запускающие файловые системы NFS или AFS [18, 4]. Тем не менее, есть одно требование, 8½ нужно отвечать на клиентские запросы по порядку: если один клиент читает /dev/cons в окне без считываемых символов, другие клиенты должны иметь возможность выполнять ввод-вывод в их окнах, или даже в одном окне. Другое ограничение в том, что файлы 8½ схожи с устройствами и должны кешироваться клиентом. NFS не может выполнить эти требования; то же самое с AFS. Конечно, есть и другие механизмы межпроцессовой связи, например, сокеты, они могут использоваться как основа для оконной системы.

Выводы

В оконной системе 8½ используется необычная архитектура вместе с файловоподобной межпроцессовой связью Plan 9 для обеспечения сетеоснованной интерактивной графики клиентским программам. Она продемонстрировала, что даже коммерческие оконные системы, в сущности, не являются большими и сложными и могут легко использоваться и программироваться.

Благодарности

Полезными комментариями ранних черновиков этого документа обеспечили: Дуг Блиуэтт (Doug Blewett), Стью Филдман (Stu Feldman), Брайан Керниган (Brian Kernighan), Деннис Ритчи (Dennis Ritchie) и Фил Уинтерботтом (Phil Winterbottom). Поддержка цвета в 8½ была добавлена Говардом Трики (Howard Trickey). Много идей, пришедших в 8½, были сначала проверены в ранних, иногда менее удачных, разработках. Я хочу поблагодарить тех пользователей, которые выстрадали в каких-нибудь моих предыдущих 7½ оконных системах.

Литература

[1] Tom Duff, Rc - A Shell for Plan 9 and UNIX systems, Proc. of the Summer 1990 UKUUG Conf., London, July, 1990, pp. 21-33, reprinted, in a different form, in this volume.
[2] Far too many people, XTERM(1), Massachusetts Institute of Technology, 1989.
[3] James Gosling and David Rosenthal, A window manager for bitmapped displays and UNIX, in Methodology of Window Management, edited by F.R.A. Hopgood et al., Springer, 1986.
[4] Mike Kazar, Synchronization and Caching issues in the Andrew File System, Tech. Rept. CMU-ITC-058, Information Technology Center, Carnegie Mellon University, June, 1987.
[5] Tom Killian, Processes as Files, USENIX Summer Conf. Proc., Salt Lake City June, 1984.
[6] Rob Pike, The Blit: A Multiplexed Graphics Terminal, Bell Labs Tech. J., V63, #8, part 2, pp. 1607-1631.
[7] Rob Pike, Graphics in Overlapping Bitmap Layers, Trans. on Graph., Vol 2, #2, 135-160, reprinted in Proc. SIGGRAPH '83, pp. 331-356.
[8] Rob Pike, The Text Editor sam, Softw. - Prac. and Exp., Nov 1987, Vol 17 #11, pp. 813-845, reprinted in this volume.
[9] Rob Pike, Window Systems Should Be Transparent, Comp. Sys., Summer 1988, Vol 1 #3, pp. 279-296.
[10] Rob Pike, A Concurrent Window System, Comp. Sys., Spring 1989, Vol 2 #2, pp. 133-153.
[11] Rob Pike, A Minimalist Global User Interface, USENIX Summer Conf. Proc., Nashville, June, 1991.
[12] Rob Pike, Dave Presotto, Ken Thompson, Howard Trickey, and Phil Winterbottom, Operating Systems Review Vol 27, #2, Apr 1993, pp. 72-76 (reprinted from Proceedings of the 5th ACM SIGOPS European Workshop, Mont Saint-Michel, 1992, Paper n? 34, and reprinted in this volume).
[13] Rob Pike and Ken Thompson, Hello World or ?ALPHA??MU??ALPHA ???MUEPSILON or ????? ??, USENIX Winter Conf. Proc., San Diego, Jan, 1993, reprinted in this volume.
[14] Rob Pike, Bart Locanthi and John Reiser, Hardware/Software Tradeoffs for Bitmap Graphics on the Blit, Softw. - Prac. and Exp., Feb 1985, Vol 15 #2, pp. 131-152.
[15] David L. Presotto and Dennis M. Ritchie, Interprocess Communication in the Ninth Edition Unix System, Softw. - Prac. and Exp., June 1990, Vol 20 #S1, pp. S1/3-S1/17.
[16] David Rosenthal, A Simple X11 Client Program -or- How hard can it really be to write Hello, World?, USENIX Winter Conf. Proc., Dallas, Jan, 1988, pp. 229-242.
[17] Robert W. Scheifler and Jim Gettys, The X Window System, ACM Trans. on Graph., Vol 5 #2, pp. 79-109.
[18] Sun Microsystems, NFS: Network file system protocol specification, RFC 1094, Network Information Center, SRI International, March, 1989.

Copyright © 2000 Lucent Technologies Inc. All rights reserved.
Copyright © 2003 Перевод Андрей С. Кухар.