QNX Windows: Взгляд изнутри

(С) И.Н. Коваленко

• Предпосылки
• Что такое QNX Windows
• Пользовательский интерфейс OPEN LOOK
• Архитектура и концепции QNX Windows
• Разработка приложений для QNX Windows
• Комплект поставки и требования к аппаратуре
• Заключение
• Изменения в версии 4.23

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

Так как в нашей стране эта ОС пока недостаточно широко распространена, читателям которым она неизвестна, имеет смысл сначала прочесть статью ‘QNX: Золушка в семье UNIX’, опубликованную во 2-ом номере журнала ‘Открытые Системы’ за 1995 год. Для того чтобы облегчить анализ возможностей, предоставляемых QNX Windows, она будет рассматриваться в сравнении с более известной широкому кругу специалистов графической оболочкой X Window System.

Предпосылки

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

Под внешней стороной понимаются визуальные элементы интерфейса и концепции взаимодействия пользователя с приложениями. Этот аспект интерфейса имеет очевидное значение, поскольку пользователи приложений реального времени как правило не отягощены глубоким знанием компьютерных технологий. В принципе, то же самое можно сказать о любом ‘конечном пользователе’, однако если ошибка допущенная при работе с текстовым процессором может быть безболезненно исправлена, то после неправильной команды в адрес ядерного реактора вам вряд-ли удастся сделать ‘Undo’. Тем более обидно, если это произошло из-за несовершенства пользовательского интерфейса. Отсюда следует вывод, что внешняя сторона интерфейса не должна провоцировать пользователя на ошибки. Заметим также, что операторы технологических процессов как правило все же проходят какой-либо курс обучения, а их работа обычно достаточно монотонна и однообразна, при этом времени на долгие раздумья в случае если произошло что-либо непредвиденное обычно нет. Следовательно, идеи о дружественном интерфейсе c фокусами вроде ‘гидов’, примененных в пакете Microsoft Bob, вряд-ли применимы в рассматриваемой области.

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

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

Резюмируя вышесказанное, можно сделать следующие выводы. Во-первых, поьзовательский интерфейс для приложений реального времени не должен содержать элементов, потенциально способных вызывать ошибки пользователей. Лучшие принципы проектирования такого интерфейса это простота и непротиворечивость. Кроме того, реализация интерфейса должна быть достсточно эффективной, для того чтобы обеспечить приемлемое время реакции и достаточно компактной, чтобы физически поместиться в ограниченном объеме оперативной памяти. И, наконец, желательно чтобы интефейс обеспечивал высокую степень изоляции приложений от проблем взаимодействия с пользователем (например, в то время как пользователь заполняет какую-нибудь форму на экране, приложение должно продолжать выполнение своей основной задачи).

Что такое QNX Windows

Если говорить коротко, QNX Windows это интеллектуальный графический сервер, однако чтобы понять смысл этого выражения необходимы довольно обильные пояснения, так как данная система имеет мало общего с общеизвестными системами вроде MS Windows или X Window System.

Как ни удивительно, ее разработчики (канадская фирма Basis Computer Systems Inc.) сумела предложить нечто непохожее ни на что другое. Разрабатывалась эта система специально для ОС QNX с расчетом на приложения работающие в реальном масштабе времени и с использованием всех преимуществ этой ОС. Права на систему принадлежат фирме QNX Software Systems Ltd. (разработчик OC QNX), поскольку разработка велась по ее заказу. Работа эта начиналась еще когда существовала только серия 2.x OC QNX, предназначенная для процессоров i8086-80286.

Первая версия системы была выпущена в 1990 году. Впоследствии QNX Windows была перенесена в 32-х разрядную версию QNX (серия 4.x), однако стоит отметить тот факт, что соответствующая версия данной системы способна работать даже на IBM PC/XT-86 (при этом обеспечивается многопользовательский доступ, вытесняющая многозадачность, прозрачные сетевые коммуникации и многое другое).

Теперь самое время рассмотреть систему QNX Windows с точки зрения внешнего интерфейса и архитектурных концепций. Внешний интерфейс этой системы совместим со спецификациями графического интерфейса пользователя OPEN LOOK, которые были разработаны экспертами фирмы Sun Microsystems, по заказу корпорации AT&T. Поскольку в нашей стране с ним знакомо лишь незначительное количество специалистов, которым довелось поработать с техникой и программным обеспечением фирмы Sun, имеет смысл остановиться на этогм вопросе подробнее.

Пользовательский интерфейс OPEN LOOK

Прежде всего следует уточнить, что мы будем понимать под интерфейсом. Обратите внимание, что OPEN LOOK это именно спецификация, а не конкретная реализация интерфейса. Разработка велась без оглядки на какой-либо из существующих интерфейсов и без ориентации на какую-либо конкретную среду выполнения, правда в некоторой степени использовались результаты исследовательских работ, проводившихся компанией Rank Xerox. Спецификации включают три книги, определяющие внешний вид графических элементов интерфейса, рекомендации по стилю приложений и процедуру сертификации приложений на соответствие спецификациям. Все книги опубликованы издательством Addison-Wesley Inc., русских переводов (насколько известно автору) не существует. Официальная публикация спецификаций состоялась в 1990 году. Затем появилось несколько реализаций, в основном для среды X Window. Наиболее известны среди них системы Open Windows и X View, разработанные фирмой Sun, а также библиотека виджетов AT&T. Реализации классифицируются на 3 уровня, по полноте. В настоящее время интерфейс OPEN LOOK является основным конкурентом интерфейса OSF/Motif, широко используемого в системе X Window, который более знаком российским специалистам, ввиду того что основными источниками вдохновения для его создателей были MS Windows и Presentations Manager.

Споры о том, какой интерфейс лучше, видимо не закончатся никогда, поскольку в этом вопросе слишком многое зависит от личного вкуса и задач, которые нужно решать. На взгляд автора, OPEN LOOK отличается некоторой внешней аскетичностью, например рекомендуется избегать применения иконок в качестве органов управления (и я знаю людей которые не любят иконки), и не злоупотреблять визуальными эффектами (типа ‘взрывающихся окон’). Если задуматься, то для многих приложений это неплохие рекомендации, ведь пользователя интересует не внешняя красота программы, а задача которую он должен решить. С другой стороны, разработчики OPEN LOOK пишут о том, что этот интерфейс предназначен не для конкуренции, а для сосуществования с другими интерфейсами. Одним словом, выбирайте то, что больше по вкусу Вам (или Вашим пользователям).

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

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

Конечно, любой специалист по графическим интерфейсам скажет, что этим принципам должна (и обычно пытается) следовать любая приличная графическая система. Однако благими намерениями вымощена дорога в ад, и достаточно поэкспериментировать с некоторым количеством программ для MS Windows, чтобы заметить как далеко большинству из них до соответствия объявленным принципам. Проблема заключается в том, что эти принципы являются не более чем общим местом, если они не сопровождаются конкретными рекомендациями по принятию тех или иных решений.

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

Теперь рассмотрим коротко основные элементы интерфейса OPEN LOOK. Очевидно, что главным элементом любого графического интерфейса являются окна (windows). В данном интерфейсе определено четыре типа окон:

Самой необычной особенностью окон в интерфейсе OPEN LOOK является возможность определить для окна ‘крайние зоны’ (Window Bars), то есть промежутки между границей окна и его внутренней частью.

Пример такого промежутка - область заголовка окна, но здесь эти промежутки могут находиться с любой стороны окна и иметь любую ширину. Они имеют независимую систему координат и могут использоваться для вывода так же как и внутренняя область окна. Верхний (и иногда левый) промежутки используются как область управления (см. далее), а правый и нижний промежутки - для зон скроллинга. Нижний промежуток используется еще и для вывода сообщений (аналог Message Area в интерфейсе OSF/Motif).

Внутренняя область окна может быть поделена на ‘форточки’ (Panes), каждая из которых может использоваться независимо (и иметь свои собственные полосы прокрутки). Всего можно определить не более 4-х форточек (не более 2-х в одном направлении), причем их общий внешний контур должен совпадать с контуром окна.

При запуске ‘менеджера рабочего стола’, все окна снабжаются декорациями (трехмерная рамка, уголки для изменения размеров, заголовок, служебная кнопка (window button) или булавка (pushpin)), иконками (для базовых окон) и меню окна, зависящим от типа.

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

Самым характерным элементом всплывающего окна служит булавка, которая является едва ли не самым известным элементом интерфейса OPEN LOOK. При открытии окна она обычно ‘лежит на боку’ в верхнем левом углу. Когда пользователь выполняет действие, связанное с окном, оно обычно закрывается. Однако, если щелкнуть мышью по булавке, она ‘втыкается’ в экран и ‘прикалывает’ окно к нему. После этого окно не закрывается, пока пользователь еще раз не нажмет на булавку, что позволяет многократно выполнять часто используемые действия. Особенно это удобно при использовании всплывающего меню - его можно приколоть в любом месте экрана, которое удобно пользователю. Заметьте, что эта красивая идея была впоследствии использована, в несколько другой форме, в интерфейсе OSF/Motif версии 1.2, под названием Tear-Off Menu (там вместо булавки используется ‘линия перфорации’ и пользователь может ‘оторвать’ меню от ‘корешка’ как листок из блокнота).

Меню в интерфейсе OPEN LOOK определены 3-х типов: Drop-Down, Pull-Right и Pop-Up. Первый тип является основным и используется совмеcтно с кнопками - меню появляется при нажатии правой кнопки мыши на кнопке (обычно под кнопкой). Второй тип является разновидностью первого и служит для создания иерархических меню. Такое меню используется только совместно с одним из двух других типов и появляется при нажатии правой кнопки мыши на элементе меню старшего уровня, c которым оно связано (обычно справа от него - отсюда и название). Третий тип предназначен для обеспечения быстрого доступа к часто используемым функциям, доступным через основное меню и появляется при нажатии правой кнопки мыши на любом пустом участке окна. Каждое меню должно иметь один элемент, который выбирается по умолчанию. Для всех типов меню (в особенности приколотых) приложения должны обеспечивать визуальную обратную связь - если какой-либо элемент меню неприменим в данном контексте приложения - он должен быть деактивирован и наоборот.

Вместо традиционной области меню (Menu Bar), базовое окно в интерфейсе OPEN LOOK имеет область управления (Control Area), в качестве которой рекомендуется верхний промежуток окна (Top Bar). В этой области принято располагать кнопки, c могут быть ассоциированы Drop-Down меню.

Рекомендуется также состав и порядок расположения кнопок - File, View, Edit, Properties, причем для кнопок File и Edit, рекомендуется еще и стандартный состав ассоциированных меню. Состав остальных меню зависит от приложения. Специальной области для ввода команд (по типу Command Area в OSF/Motif) в базовом окне не предусматривается.

Кнопки (Buttons) в интерфейсе OPEN LOOK имеют овальную форму и всегда выводятся с 3D-эффектом, то есть они ‘выпирают’ над поверхностью, а при нажатии утапливаются. Одна из кнопок в окне назначается ‘кнопкой по умолчанию’ и будет выделяться ободком внутри контура кнопки. В некоторых реализациях эта кнопка будет нажиматься при нажатии клавиши Enter. Все кнопки классифицируются на 3 типа - кнопки меню (Menu Buttons), кнопки окон (Window Buttons) и кнопки команд (Command Buttons). Кнопки первого типа помечаются значком треугольника, направленного вниз. При нажатии левой кнопки мыши на такую кнопку автоматически выбирается элемент по умолчанию из ассоциированного меню (интерпретация AT&T) или этот элемент выводится на кнопку вместо названия, чтобы его можно было увидеть (интерпретация Sun Microsystems). При нажатии правой кнопки мыши, соответствующее меню появляется под кнопкой. Кнопки второго типа выделяются знаком (...). При нажатии на такую кнопку открывается какое-либо окно. Кнопки последнего типа никак не выделяются. При нажатии на них просто выполняется соответствующее действие. Точно такая-же классификация применяется по отношению к элементам меню. Это относится и к выделению, но вместо треугольника направленного вниз, применяется треугольник, направленный вправо.

Принципы взаимодействия с пользователем в интерфейсе ориентированы в основном на использование мыши, хотя можно обходиться и без нее. Позиционирование через клавиатуру не определено, хотя и поддерживается в той или иной степени большинством реализаций (в том числе QNX Windows). Понятие фокуса ввода по отношению к кнопкам также не определено, так как OPEN LOOK использует другой механизм для нажатия кнопки через клавиатуру - мнемонические комбинации. Для каждой кнопки можно определить букву, входящую в ее название, в качестве мнемонической (по умолчанию первая). Она будет выделяться (цветом или подчеркиванием) при отображении кнопки. Одновременное нажатие клавиши Alt и указанной буквы будет эквивалентно нажатию левой кнопки мыши на эту кнопку.

C другой стороны, OPEN LOOK очень систематично использует мышь, причем все 3 ее кнопки. Они даже имеют специальные названия - SELECT, ADJUST и MENU (слева направо). Кнопка SELECT (левая) служит для выборки элементов в окне, переключения фокуса ввода между окнами, нажатия на кнопки. Кнопка ADJUST (средняя) предназначена для изменения текущей выборки (например, когда пользователь должен выбрать 3 файла, он должен нажать SELECT на первом и ADJUST на остальных. Повторный SELECT сбрасывает предыдущую выборку, а повторный ADJUST исключает элемент из выборки). Если используется двухкнопочная мышь, нажатие комбинации Shift-SELECT обычно эмулирует ADJUST. Кнопка MENU (правая) служит для открытия меню всех типов. Те, кто знает интерфейс OSF/Motif заметят, что основное различие - в использовании средней кнопки - там она предназначена для операций в режиме Drag’n’Drop (версия 1.2). В интерфейсе OPEN LOOK для этой цели применяется кнопка SELECT, но следует заметить, что в целом концепция режима Drag and Drop здесь продумана слабее и недостаточно систематизирована, что объясняется тем, что Motif 1.2 появился на 2 года позже чем OPEN LOOK (в предыдущих версиях этот режим вообще отсутствовал).

Спецификации OPEN LOOK определяют также операции с Clipboard и с файлами, то есть менеджер фалов является необходимым элементом для реализации 2-го уровня. Кроме того даются рекомендации по поводу выбора и оформления заголовков и меток, размещения элементов внутри окна, выбора названий для пунктов меню, формата сообщений об ошибках, выбора цветовой палитры и еще многи деталей, о которых начинающие проектировщики обычно даже не думают. Объем статьи не позволяет нам, к сожалению, даже кратко рассмотреть все элементы интерфейса OPEN LOOK, поэтому рассмотрим теперь более подробно систему QNX Windows как пример реализации описанных концепций (причем одну из первых).

Архитектура и концепции QNX Windows

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

Схема, показаная на рисунке 1, описывает ключевые элементы архитектуры QNX Windows с точки зрения их взаимодействия с прикладными программами. Для простоты на ней не показаны некоторые элементы, не относящиеся к делу.

Важнейшим элементом архитектуры является менеджер событий (Event Manager), который является для прикладной программы ‘окном в мир’ - все события, относящиеся к графическому интерфейсу, она получает от него.

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

Термины сообщение и событие здесь сознательно противопоставлены, так как они не только несут разную смысловую нагрузку, но и реализуются различными механизмами. Дело в том, что события по определению должны быть асинхронными, поскольку менеджер событий не должен блокироваться до получения события соответствующим процессом. В противном случае один зациклившийся процесс ‘подвесит’ все остальные. Механизм передачи сообщений в ОС QNX (Send/Receive/Reply) является синхронным, поэтому менеджер событий использует асинхронный механизм proxy, выполняющий передачу сообщений через виртуальные процессы-посредники. Механизм сигналов не подходит, поскольку вместе с событием почти всегда необходимо передавать связанные с ним данные.

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

Сообщения, которые не относятся ни к одному из активных приложений, обычно перехватываются ‘менеджером рабочего стола’ (OPEN LOOK Workplace Manager), роль которого похожа на роль менеджера окон в системе X Window (переключение и перемещение окон, изменение размеров, декорации и меню окон), но включает еще и многие другие функции, например конфигурирование системных меню, настройку цветовой палитры, поддержку функций печати, установку характеристик мыши, выбор ‘хранителя экрана’ и т.п.

Приложение обычно выполняет все графические операции через сервер экрана (Screen Server), роль которого заключается в поддержке стандартных операций над графическими элементами определенными для интерфейса OPEN LOOK. Обращение к серверу происходит путем вызова соответсвующих функций API, которые осуществляют обмен с сервером через системные вызовы Send/Receive/Reply, и возвращают приложению соответствующие данные и код результата. Такой подход позволяет маскировать детали архитектуры от приложений и использовать для их разработки традиционный прикладной интерфейс на языке C. С целью снижения расхода оперативной и дисковой памяти на приложения, QNX Windows использует разделяемую библиотеку. Причины, по которым сервер экрана был выделен в самоcтоятельный модуль (а не объединен с разделяемой библиотекой) будут рассмотрены далее. Заметим также, что приложения, нуждающиеся в сверхвысокой скорости вывода на экран (например для анимации), могут напрямую взаимодействовать с графическим драйвером через общую область памяти, используя специальный прикладной интерфейс (туннельный режим). Этот режим особенно эффективен при использовании высококачественных видеоплат, аппаратно поддерживающих операции типа BitBlt и т.п. (например ATI Ultra или Number Nine S3).

Полезной особенностью сервера экрана является возможность перевести его в режим ‘sleep’, при котором он освобождает консоль и переводит ее в текстовый режим. Пользователь при этом может работать с текстовыми приложениями, в то время как графические приложения (не ожидающие ввода) будут продолжать нормальное выполнение. Сервер может быть снова ‘разбужен’ в любой момент.

Менеджер диалогов (Dialog Manager) обеспечивает поддержку стандартных диалогов нескольких типов (File, Menu, Prompt, Notice, Help) и, кроме того, позволяет создавать диалоги определенные программистом. В принципе диалог - это обычное окно, но наличие отдельного менеджера позволяет разделить нити управления основной программы и обработки диалогов, так как QNX Windows проектировалась еще когда ОС QNX не поддерживала множественные нити управления в одной программе (threads). Данное обстоятельство значительно упрощает программирование приложений реального времени, поскольку позволяет программе получать соответсвующие события лишь после того, как диалог уже завершен. Более того, даже инициализация диалога может быть выполнена автоматически, благодаря тому факту, что диалог можно ‘ассоциировать’ с произвольным элементом интерфейса (обычно с кнопкой), так что приложение даже не узнает об открытии диалогового окна, пока оно не закроется Еше один плюс такого подхода состоит в том, что он облегчает выполнение рекомендации OPEN LOOK о том, что диалоги, как правило, должны быть немодальными (то есть неблокирующими родительское окно).

Для обеспечения работы QNX Windows на достаточно широком спектре оборудования, разработчики применили концепцию универсальных графических драйверов, использующих для управления видеоплатами спецификации SVPMI (Super VGA Protected Mode Interface), предложенные ассоциацией VESA. Для запуска такого драйвера на новом типе видеоплаты достаточно получить (или написать) его описание в формате SVPMI. Производители оборудования обычно поставляют такое описание на прилагаемой к плате дискете в файле под названием vesa.pmi. Иногда такой файл может быть сгенерирован одной из прилагаемых утилит. QNX Windows поставляется с набором таких описаний для видеоплат типа Trident, Paradise, ET4000, Video-7, Amazing, ATI и S3. Кроме того в поставку входит и описание стандарта SVPMI, так что квалифицированный специалист может самостоятельно написать соответствующее описание для нужной видеоплаты. Для видеоплат с ускорителями на базе наборов микросхем Mach и 8514 (ATI, Number Nine S3, Diamond S3 Stealth) поставляются также специальные драйверы, позволяющие в полной мере использовать их возможности. Поддерживаются видеорежимы от VGA 640x480x16 до 1280x1024x256. Благодаря наличию в ОС QNX эмулятора прерывания int10, практически на любой видеоплате поддерживается разрешение 800х600х16, что обычно достаточно для приложений работающих на 14" мониторах.

Драйвер мыши тоже универсальный, поддерживает протоколы Mouse Systems, Microsoft и Logitech. Возможно использование как Serial так и Bus Mouse.

Поскольку в ОС QNX нет разницы между передачей сообщений в пределах одного узла и между узлами, рассмотренная архитектура позволяет (как и в системе X Window) создавать распределенные приложения, то есть пользователь может запустить программу-клиент QNX Windows на одном узле сети QNX, а ввод/вывод она может осуществлять на сервер, расположенный на другом (таким образом можно использовать чужую оперативную память и процессор).

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

Разобравшись немного с архитектурой мы можем перейти к рассмотрению концепций работы с графикой, использованных при создании QNX Windows. Лучше всего это сделать анализируя принципы разработки прикладных программ.

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

Разработка приложений для QNX Windows

Несмотря на классический прикладной интерфейс с языком С, QNX Windows изнутри представляет собой объектно-ориентированную систему, как и в случае с X Window. Здесь также используется понятие ресурса, но в другом смысле. Ресурсы - это картинки (pictures), элементы (picture elements), экраны (screens), окна (windows), форточки (panes) и диалоги (dialogs). Каждый ресурс имеет владельца (процесс) и имя (символьная строка). Поддержка ресурсов осуществляется соответствующими менеджерами. Некоторые из ресурсов имеют иерархические взаимоотношения:

• сервер может управлять несколькими экранами;
• экран может содержать несколько окон;
• окна могут содержать несколько форточек (и связанных с ними картинок);
• картинки могут содержать несколько элементов;

Приложения взаимодействуют с QNX Windows создавая ресурсы и манипулируя ими. Например, окна могут быть открыты и закрыты, картинки - созданы, скопированы и удалены, элементы - нарисованы, скопированы, перемещены, удалены и т.д. Любой ресурс может находиться на любом узле сети QNX, поскольку все манипуляции осуществляются через прозрачный для сети механизм передачи сообщений.

Базовой основой работы QNX Windows с графикой служит уникальная концепция ‘картинки’ (picture). Картинку можно представить себе как лист бумаги с координатной сеткой, независимой от устройства отображения (идея, вызывающая ассоциации с языком PostScript). Координаты измеряются в типсах (tips) - десятых долях пункта - типографской единицы, равной 1/72 дюйма. Начало координат находится в левом верхнем углу, размеры картинки ограничены координатами 65535. Весь графический вывод, если специально не указано иное, происходит не в окна, а в картинки (окно может и не существовать). С любой из ‘форточек’ окна можно динамически связать любую существующую картинку, можно также cменить картинку в любой момент.

Другая фундаментальная концепция заключается в определении понятия графического элемента (picture element), иначе говоря объекта имеющего тип. Типы в основном соответствуют стандартным элементам, определенным в интерфейсе OPEN LOOK, и, самое главное, эти типы известны менеджеру экрана. Вывод в картинку осуществляется сервером, по запросу приложения, сообщающего серверу тип элемента, который необходимо создать, и его атрибуты. Все, что появляется на экране есть экземпляры элементов того или иного типа. Картинка же есть не что иное, как упорядоченный список элементов. Это относится не только к картинкам, созданным программой, но и к окнам, меню, иконкам и т.п.

QNX Windows использует следующие типы элементов:

С любым элементом может быть ассоциирована метка (label), диалог или произвольные данные, определенные программистом. В зависимости от типа, элементы имеют характерный набор атрибутов (координаты, цвет, цвет фона, толщина линий, шрифт и т.п.). Элементы всех типов могут иметь также опции (options) и состояния (states), которые определяют поведение элемента и способ его вывода. По поведению при нажатии на него мышью, элемент может быть ‘выбираемым’ (selectable), редактируемым, ‘уведомляющим’ (notify), блокированным, инвертирующим состояние или запоминающим состояние. Выводиться элемент может стандартно, непосредственно в окно (минуя картинку), с затемнением, с рамкой, с 3D-эффектом, с тенью.

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

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

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

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

Рассмотренные выше концепции позволили разработчикам QNX Windows применить несколько очень красивых и эффективных решений, некоторые из которых не имеют аналогов.

Во-первых, все ресурсы, создаваемые приложениями (окна, картинки, диалоги) создаются менеджером экрана и хранятся в его адресном пространстве. Это радикально уменьшает требования программ к оперативной памяти и повышает скорость выполнения графических операций. Именно в этом главное отличие графичесих элементов QNX Windows от виджетов X Window, которые хотя и маскируют от приложения детали своей работы, но хранятся в адресном пространстве приложения. При этом сервер в X Window всего лишь исполняет X Protocol, который имеет достаточно низкий уровень. Следствием этого является не только высокий внутренний трафик но и тот менее заметный факт, что нить управления при модификации содержимого экрана очень часто передается приложению, что весьма нежелательно для приложений реального времени. В QNX Windows все совсем иначе, так как приложение должно только заказать высокоуровневую операцию серверу, а выполняет он ее без дальнейшего вмешательства. При этом расходы памяти на сервере тоже невелики, поскольку понятие типа элемента позволяет отказаться от хранения растров, применяя вместо них картинки (сервер знает как рисовать элементы известного ему типа). Это слегка напоминает ОС NextStep, где изображения хранятся в формате Display PostScript, но картинки QNX Windows требуют на порядок меньше памяти (помните, что для цветной NextStep нужно 64Mb памяти?) так как PostScript описывает абстрактные команды рисования, а не объекты предопределенных типов.

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

В-третьих, имея в своем распоряжении все картинки и окна, сервер может сам отслеживать перекрытия окон, вычислять отсечения и выполнять перерисовку содержимого окон! Это означает, что программа в QNX Windows не обязана обрабатывать сообщения типа EXPOSE или WM_PAINT, как это приходится делать в системах X Window или MS Windows. Режим Backing Store, появившийся в X Window System release 11, не идет ни в какое сравнение, поскольку там хранятся растры, и в случае нехватки памяти (что весьма вероятно) сервер этот режим выключает (то есть программа не может и не должна на него полагаться). Конечно, любая промежуточная ступень вносит задержки, поэтому для программ, критически зависимых от скорости вывода на экран, предусмотрен режим прямого вывода элементов в окно.

В-четвертых, менеджер экрана может автоматически обеспечивать желаемое поведение окон и форточек, задаваемое набором опций, как и в случае с элементами. Например, можно специфицировать какие события следует посылать владельцу ресурсов, а какие нет.

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

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

Те, кто имеет опыт программирования в X Window, знают, что программы для этой системы чрезвычайно многословны. Огромное количество функций API делает его труднообозримым и осложняет жизнь программистам, ввиду чего для X Window было написано самое большое количество генераторов кода. Минимальная программа, выводящая в окно надпись hello world! имеет длину около 30 строк, что еще очень неплохо по сравнению с MS Windows. Размер исполняемого модуля получается около 800 Kb, в зависимости от конкретной реализации. В QNX Windows такая программа получается всего на две строчки длиннее, чем классический вариант Керингана и Ритчи, если использовать стандартный диалог, и еще на две сточки длиннее, если использовать обычное окно. Размер исполняемого модуля 7500 байт, при запуске программа занимает 92 Kb (32-х разрядная версия, flat-модель).

#include <windows/Qwindows.h>

void main ( void )

{

	GraphicsOpen( NULL );	// соединение с сервером	

	Tell( "Hello Program", "Hello, World!" );	

	GraphicsClose( 0 );

}

Однако, как справедливо замечено в книге X Toolkit Programmer’s Manual, программа hello world! является вырожденным примером для X Window. Если нарастить приведенную программу до тех возможностей настройки которые предоставляет версия для X Window, мы получим сопоставимый размер исходного кода (однако размер исполяемого модуля изменится очень незначительно!!!).

Тем не менее, рассмотрим еще один пример. В комплект поставки OSF/Motif 1.2 входит демонстрационная программа DNDDemo, дающая пример использования протокола Drag and Drop, появившегося в этой версии интерфейса Motif. Размер исходного кода этой программы около 3000 строк на языке С, размер исполняемого модуля (в версии X Window для QNX) - около 900 Kb. Для сравнения автор данной статьи написал программу для QNX Windows обеспечивающую эквивалентную функциональность. Программа создает окно с двумя форточками, в нижней форточке размещены 16 цветных прямоугольников. Пользователь может рисовать прямоугольники в верхней форточке, используя обычный механизм ‘резиновой нити’. Нарисованные прямоугольники можно копировать или перемещать мышью как в пределах форточки, так и в верхнюю форточку другого окна, открытого другой копией программы. Цвет любого прямоугольника можно изменить, ‘перетащив’ желаемый цвет с палитры в нижней форточке.

При этом поддерживаются визуальные эффекты Drag Over (изменение курсора), Drag Under (взятие прямоугольника в рамку) и контекстно-зависимая функция Help. Размер исходного кода - 300 (триста) строк на языке C. Размер исполняемого модуля (32-х разрядная версия, компилятор Watcom C 9.51) - 15 (пятнадцать) Kb. Объем статьи не позволяет привести здесь исходный текст программы, но автор готов предоставить его по запросу всем желающим.

Комплект поставки и требования к аппаратуре

QNX Windows поставляется в виде трех отдельных частей: Runtime, SDK и Extended Toolkit. Исполняющая система занимает 2 (две) дискеты формата 1.44 Mb и устанавливается без лишних вопросов в течении нескольких минут.

В комплекте с ней поставляются стандартные сервисные программы: OPEN LOOK Workplace Manager, OPEN LOOK File Manager, Symbol Editor, Clock, Clipboard Viewer, Load Monitor, Wterm (эмулятор терминала), игры (Solitaire, Poker), программы для импорта изображений из формата GIF, несколько демонстрационных программ с исходными текстами. В поставку также входит комплект шрифтов, включающий гарнитуры Charter, Courier, Helvetica, New Century, Old English, System, Terminal и Times Roman, с размерами от 8 до 80 пунктов и стилями Regular, Bold, Italic и Bold Italic (всего более 200 шрифтов).

В системе используются только растровые шрифты своего собственного формата, однако этот формат позволяет более точно описывать шрифты, чем формат растровых шрифтов MS Windows (особенно для шрифтов с наклоном), поэтому качество их выше, а богатый набор гарнитур и стилей фактически компенсирует отсутствие контурных шрифтов. Разумеется, возникает еще вопрос о русификации этих шрифтов, но эта проблема уже решена (этим автор статьи занимался сам). Разработанный для среды QNX Windows редактор шрифтов позволяет импортировать растровые шрифты MS Windows и X Window (в формате BDF). Желающие могут также создавать свои собственные шрифты вручную и экспортировать их в X Window и в формат Interface Editor’а (см. далее). Документация на Runtime состоит из одной книги - QNX Windows User’s Guide, которая дает общее представление об интерфейсе OPEN LOOK с точки зрения конечного пользователя и подробно описывает технику работы в среде QNX Windows.

Система разработки занимает одну дискету формата 1.44 Mb и содержит набор заголовочных файлов и библиотек для компилятора Watcom C (стандартного для QNX). Поддерживается создание как 16-и так и 32-х разрядных приложений (модель памяти только flat). В комплект документации входит QNX Windows Programmer’s Reference. Книга представляет собой в основном справочник по функциям API, с довольно лаконичной первой частью, где дается очень беглое описание концепций постоения системы и принципов построения приложений. Последняя часть содержит также очень короткий учебник с примерами (for Dummies).

Extended Toolkit поставляется также на одной дискете и содержит программу Interface Editor, предназначенную для диалогового проектирования интерфейса приложений. С ее помощью можно формировать как окна, так и их содержимое (статическое), задавать для них режимы работы и сохранять полученные шаблоны в виде файлов. Соответствующие функции API позволяют использовать эти шаблоны при открытии окон. Кроме того, данная программа имеет свою собственную библиотеку шрифтов, хранящихся в формате PICT (см выше), и предназначенных для оформления создаваемых шаблонов.

Interface Editor позволяет выводить эти шрифты под углами в 0/90/180/270 градусов, с тенями, с 3D-эффектами, с различными цветами и т.д. Программа также снабжена довольно подробным руководством (Interface Editor User’s Guide). Кроме того, в комплект входит 2-я часть официальной публикации спецификаций OPEN LOOK, о которых говорилось выше - OPEN LOOK Graphical User Interface Application Style Guidelines. Эта книга представляет значительный самомтоятельный интерес для тех, кто хочет разобраться с теорией графических интерфейсо.

В качестве примера приводится полнофункциональная программа Calculator, разработанная с помощью Interface Editor’а и снабженная исходными текстами.

Благодаря своей сравнительно простой но гибкой и эффективной архитектуре QNX Windows довольно компактна. Общий объем оперативной памяти, занимаемый 32-х разрядной версией исполняющей системы составляет всего около 1.5 Mb, что весьма скромно по сравнению с запросами X Window. Таким образом на компьютере типа PC/AT-386DX/33 c 4 Mb памяти (типичная рабочая лошадка на текущий момент) останется свободным около 1.5 Mb.

Это вполне достаточно для выполнения нескольких 32-х разрядных приложений (и скорость будет очень приличная). Своппинг на диск в ОС QNX не используется, так как он плохо совместим требованиями приложений реального времени, поэтому для среды разработки желательно увеличить объем памяти до 8 Mb. Требования к дисковой памяти также очень скромные, что легко понять зная размер дистрибутива (4 дискеты). Видеоплаты, как уже отмечалось выше, можно использовать практически любые, однако если качество графики имеет принципиальное значение, лучше остановить свой выбор на платах типа Mach 32/64 (ATI Ultra Pro) или 8514 (Number Nine S3/928).

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

Заключение

ОС QNX и система QNX Windows с успехом применялась при реализации многих крупных проектов, некоторые из которых сами по себе достаточно интересны, чтобы написать о них отдельную статью. В качестве примеров можно привести применение QNX для систем сортировки входящего транспорта и продажи билетов на терминалах железнодорожной магистрали между Францией и Великобританией, проложенной в туннеле под проливом Ла-Манш. Проектная пропускная способность этой магистрали в часы пик - один состав каждые 2.5 минуты, скорость следования поездов - 100 миль в час, что предъявляет повышенные требования к квалификации машинистов. Для решения этой проблемы был создан специальный тренажерный центр, использующий технологию виртуальной реальности для 100% имитации реальной обстановки в кабине локомотива. QNX Windows была использована для создания визуальной подсистемы, обеспечивающей возпроизведение оцифрованных изображений окружающего пейзажа с частотой 25 кадров/сек. Система имитирует также звуковые и гравитационные эффекты.

Другой недавний пример - централизованая система управления морскими нефтяными платформами, созданная в Новой Зеландии, позволяющая осуществлять контроль над процессом перекачки нефти на всех установках в режиме on-line через дистанционные датчики.

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

Изменения в версии 4.23

В связи с интенсивным развитием системы Photon, фирма QSSL сократила развитие и поддержку QNX Windows до минимума. Единственное серьезное изменение, внесенное в систему - обеспечение работы QNX Windows в окне системы Photon и псевдо-драйвер gr.phi, благодаря которому QNX Windows может работать через видеодрайверы системы Photon.

Тем не менее, разработчики QNX Windows (Basis Computer) продолжают выпуск новых версий и разработку новых программ под нее. В частности, была выпущена 32-битная версия 4.23, в которою внесены некоторые существенные улучшения:

• Средства и документация для разработки и включения в сервер экрана новых графических элементов, что позволяет расширять систему в соответсвии с потребностями разработчиков.
• Фронт-процессор клавиатуры для проддержи азатских языков.
• Новый менеджер рабочего стола BWM, приближающий систему в внешнему виду Windows95.
• Система InterDesk, перенесенная из NextStep, сочетающая менеджер рабочего стола и мощный менеджер файлов.
• Программа просмотра документации в формате HTML.
• Универсальный графический редактор.

Кроме того, в стадии разработки находятся средства доступа к Internet. Хотя, учитывая сложившуюся с выходом Photon ситуацию, вряд-ли можно рекомендовать QNX Windows для новых пользователей, тем кто ее уже имеет и разработал для нее сложные приложения, вряд ли стоит бросать все и переходить на Photon. QNX Widnows по прежнему имеет некоторые существенные архитектурные преимущества перед системой Photon и, в виду улучшения пользовательского интерфейса и средств разработки, она вполне может сохранить свои позиции в будущем.