имизировать избыточность и достичь максимальной пропускной
способности, когда устройство работает в <em>сыром</em> режиме. ‘ этой
целью используютсЯ следующие правила:

<ul><li> Ћбработчики прерываний помещают принЯтые данные непосредственно в
очереди в памЯти. ’олько при наличии ждущего запроса на чтение <em>и</em>
при условии, что этот запрос может быть удовлетворен, обработчик прерываниЯ
инициирует выполнение <tt>Dev</tt>. ‚о всех остальных случаЯх выполнЯетсЯ
просто возврат из прерываниЯ. Ѓолее того, если <tt>Dev</tt> уже выполнЯетсЯ,
то никакой диспетчеризации не производитсЯ.

</li><li> Љогда запрос на чтение удовлетворен, <tt>Dev</tt> копирует данные в
приложение <em>непосредственно</em> из буфера сырого ввода. Љак
результат, данные копируютсЯ только один раз.</li></ul>
<p>ќти правила - в сочетании с исключительно маленькими задержками
прерываниЯ и диспетчеризации в QNX - обеспечивают очень эффективную
модель ввода.


<!-- 6 -->

<!-- 7 -->


<h2><a name="p7">Њенеджер сети</a></h2>

<p>ќта глава охватывает следующие темы:
<ul><li><a href="#INTRO">введение;</a></li><li><a href="#RESPONSIBILITIES">обЯзанности Њенеджера сети;</a></li><li><a href="#KERNELINTERFACE">интерфейс ЊикроЯдро/Њенеджер сети;</a></li><li><a href="#DRIVERS">сетевые драйверы;</a></li><li><a href="#IDENTIFIERS">идентификаторы узла и сети;</a></li><li><a href="#CHOOSINGANET">выбор сети;</a></li><li><a href="#TCPIPNET">сеть TCP/IP.</a></li></ul>


<h3><a name="INTRO">‚ведение</a></h3>
<p>Њенеджер сети (<tt>Net</tt>) дает пользователЯм QNX прозрачное
расширение мощных возможностей механизма передачи сообщений.
‚заимодействуЯ непосредственно с ЊикроЯдром, Њенеджер сети усиливает
механизм IPC на основе обмена сообщениЯми, передаваЯ сообщениЯ на
удаленные компьютеры. Љроме того, Њенеджер сети обеспечивает:

<ul><li> повышенную пропускную способность за счет балансировки нагрузки;

</li><li> отказоустойчивость за счет резервированиЯ соединений;

</li><li> функции моста между QNX сетЯми.

 </li></ul>

<h3><a name="RESPONSIBILITIES">ЋбЯзанности Њенеджера сети</a></h3>
<p>Њенеджер сети отвечает за распространение примитивов передачи
сообщений QNX в пределах локальной сети. ‘тандартные примитивы передачи
сообщений используютсЯ <em>без изменениЯ</em> длЯ свЯзи с удаленным
компьютером. „ругими словами, не существует особых "сетевых" <i>Send(),</i>
<i>Receive()</i> или <i>Reply()</i>.


<p><b><a name="id4">Ќезависимый модуль</a></b>
<p>Њенеджер сети <em>не</em> должен быть обЯзательно встроен в образ
операционной системы.  Ћн может быть запущен и остановлен в любое
времЯ, чтобы обеспечить или удалить сетевые возможности передачи
сообщений.

<p>Џри запуске Њенеджер сети регистрируетсЯ у Њенеджера процессов и
џдра. ќто активизирует код внутри последних, который взаимодействует
с Њенеджером сети. ќто означает, что передача сообщений по сети и
создание удаленных процессов - это не просто добавлЯемый поверх
операционной системы слой.  ‘етевые возможности интегрированы в самую
сердцевину примитивов передачи сообщений и управлениЯ процессами.

<p>’акаЯ глубокаЯ интеграциЯ на самом нижнем уровне обеспечивает
QNX сетевую прозрачность и делает ее полностью распределенной
операционной системой.  Џоскольку приложениЯ запрашивают и получают доступ
ко всем обслуживающим программам посредством сообщений и Њенеджер сети
обеспечивает прозрачное прохождение сообщений по сети, то узлы QNX
функционируют вместе как единый логический компьютер.

<p>Џоскольку Њенеджер сети и ЊикроЯдро отделены друг от друга,
ЊикроЯдро может достичь независимости от сетевого оборудованиЯ, а
компьютеры, не подключенные к сети, могут выиграть за счет меньшего
объема кода.


<h3><a name="KERNELINTERFACE">€нтерфейс ЊикроЯдро/Њенеджер сети</a></h3>
<p>ЊикроЯдро и Њенеджер процессов взаимодействуют с Њенеджером сети
через специальную неблокирующую очередь в памЯти. ќта очередь представлЯет
собой список передач, которые должен выполнить Њенеджер сети. ќлементы
очереди содержат всю информацию о конкретной операции (например,
<i>Send()</i>, <i>Reply()</i>, создание виртуального канала (VC), передача
удаленного сигнала и т.д.).

<p>„ругим ресурсом операционной системы, используемым длЯ обеспечениЯ
прозрачной передачи сообщений, ЯвлЯетсЯ <em>буфер виртуального канала</em>.
‚ыделЯемый при создании VC процессом, буфер виртуального канала хранит
данные до завершениЯ операции передачи сообщениЯ на другой узел.

<p>Ќиже приведены диаграммы, иллюстрирующие процесс посылки и
приема удаленных сообщений.


<p><b><a name="id6">Џосылка сообщениЯ на удаленный узел</a></b>
<p><hr>
<p><img src="qnx4-sendrmot.gif" alt="fig: i/sendrmot.gif">
<hr>

<p><i>Џроцесс вызывает Send() или Reply() к удаленному узлу.</i><pre>

</pre>

<p>‚ случае вызова <i>Send()</i> или <i>Reply()</i> к удаленному узлу,
имеют место следующие событиЯ:


<ol>
<li>Џроцесс вызывает <i>Send()</i> или <i>Reply()</i>, и ЊикроЯдро
копирует данные из области данных процесса в буфер виртуального
канала.
</li><li>ЊикроЯдро добавлЯет в очередь Њенеджера сети элемент,
содержащий идентификаторы отправителЯ, удаленного получателЯ и
указатель на данные в буфере виртуального канала. …сли перед этим
очередь была пуста, то Њенеджер сети получает прокси, извещающее о
том, что поЯвилась новаЯ работа.
</li><li>Њенеджер сети извлекает элемент из очереди.
</li><li>Њенеджер сети посылает элемент соответствующему сетевому
драйверу.
</li><li>Њенеджер сети начинает передачу данных по сети и отвечает за
доставку.
</li></ol>

<p>‚ случае распространениЯ сигнала или созданиЯ VC, Њенеджер
процессов, а не ЊикроЯдро, добавлЯет управлЯющий пакет в очередь .
Љак и в предыдущем случае, Њенеджер сети передаст пакет по
назначению.

<p><b><a name="id7">Џолучение сообщениЯ с удаленного узла</a></b>
<p><hr>
<p><img src="qnx4-recvrmot.gif" alt="fig: i/recvrmot.gif">
<hr>

<p><i>Џроцесс получает удаленный Send() или Reply().</i><pre>

</pre>

<p>„опустим, что удаленный узел послал сообщение, как описано выше.
‚ этом случае на принимающем узле имеют место следующие событиЯ:


<ol>
<li>‘етевой драйвер помещает поступившие по сети данные в
соответствующий буфер виртуального канала.
</li><li>‘етевой драйвер информирует Њенеджер сети о том, что прием
завершен.
</li><li>Њенеджер сети использует частный вызов џдра, извещаЯ его о
том, что прием завершен.
</li><li>ЊикроЯдро копирует данные из буфера виртуального канала в
буфер процесса (при условии, что он RECEIVE- или REPLY-блокирован на
этом виртуальном канале).</li></ol>

<p>‹юбые управлЯющие пакеты, которые получает Њенеджер сети,
немедленно переправлЯютсЯ Њенеджеру процессов через стандартный
примитив <i>Send()</i>.  ќти управлЯющие пакеты используютсЯ длЯ
распространениЯ сигналов и созданиЯ виртуальных каналов.


<h3><a name="DRIVERS">‘етевые драйверы</a></h3>
<p>Џодобно Њенеджеру файловой системы и Њенеджеру устройств,
Њенеджер сети не содержит аппаратно-зависимого кода.  ќта
функциональность обеспечиваетсЯ драйверами сетевых плат.  Њенеджер
сети может поддерживать одновременно несколько сетевых драйверов.
Љаждый драйвер обычно обслуживает одну сетевую плату. ‚ы можете иметь
драйверы/платы одного и того же типа или различных типов - например,
два драйвера/платы Ethernet или, допустим, драйвер/плату Ethernet и
драйвер/плату Arcnet.

<p>€нтерфейс между Њенеджером сети и драйверами реализован через
очереди в разделЯемой памЯти.  ќтот интерфейс разработан таким
образом, чтобы достичь максимально возможной производительности.
„райвер определЯет протокол, подходЯщий длЯ данного сетевого
носителЯ.

<p>„райвер отвечает за формирование пакетов, организацию
последовательности и в случае, когда требуетсЯ гарантированнаЯ доставка
данных удаленному узлу, повторную передачу. ’акаЯ архитектура позволЯет QNX
легко поддерживать новое сетевое оборудование и протоколы за счет
написаниЯ или модификации только сетевого драйвера.


<h3><a name="IDENTIFIERS">€дентификаторы узла и сети</a></h3>
<p>Љаждый узел в локальной сети идентифицируетсЯ
двумЯ числами:
<ul><li>физическим идентификатором (ID) узла (или идентификаторами,
если узел имеет более одной сетевой платы);
</li><li>комбинацией логического ID узла и логического ID сети.
</li></ul>

<p><b><a name="id10">”изический ID узла</a></b>
<p>”изический ID узла определЯетсЯ оборудованием.  ‘етевые платы
обмениваютсЯ данными друг с другом, указываЯ физический ID удаленного
узла, с которым должна быть установлена свЯзь. ‚ случае сети Ethernet
или Token Ring - это большое число, которым неудобно оперировать
людЯм и утилитам.  Ќапример, каждаЯ плата Ethernet или Token Ring
имеет уникальный 48-битный физический ID узла в соответствии со
стандартом IEEE 802.  Џлаты Arcnet, напротив, имеют всего лишь
8-битный ID.

<p>€спользование физического ID узла имеет существенный недостаток:
при соединении некоторых сетей может возникнуть конфликт адресов
(особенно в случае Arcnet), или формат адресов может радикально
отличатьсЯ.


<p><b><a name="id11">‹огический ID узла</a></b>
<p>—тобы обойти названные выше проблемы, возникающие при
использовании физических ID узлов, каждому узлу QNX присваиваетсЯ
<em>логический ID узла</em>. ‚се процессы QNX оперируют логическими ID
узлов. ”изические ID узлов скрыты от процессов, выполнЯющихсЯ в QNX.

<p>€спользование логических ID узлов упрощает лицензирование.  ’акже
они позволЯют утилитам, которые опрашивают сеть, использовать простой
цикл, в котором логический ID узла изменЯетсЯ от 1 до количества
узлов.

<p>‘оответствие между логическими и физическими ID узлов
устанавливаетсЯ Њенеджером сети.  Њенеджер сети, когда поручает
драйверу передать данные на другой узел, передает ему физический ID
этого узла.

<p>‹огические ID узлов обычно присваиваютсЯ по порЯдку,
начинаЯ с 1.  Ќапример, узел, имеющий плату Ethernet, может получить
логический ID <tt>2</tt>, который будет соответствовать физическому ID
узла <tt>00:00:c0:46:93:30</tt>.

<p>‹огические ID узлов должны быть уникальны длЯ всех узлов во <em>всех</em>
соединенных QNX-сетЯх, чтобы сделать возможным функционирование мостов.


<p><b><a name="id12">‹огический ID сети</a></b>
<p>ID сети идентифицирует конкретную <em>логическую сеть</em>. ‹огическаЯ
сеть - это любое оборудование, которое позволЯет сетевому драйверу
непосредственно взаимодействовать с сетевым драйвером на другом узле.
ќто может быть как просто последовательный порт, так и сложнаЯ сеть
Ethernet с <em>аппаратными</em> мостами.

<p>Ќа следующей диаграмме узел 7 имеет две сетевые платы, которые
позволЯют ему иметь доступ к узлам в логических сетЯх 1 и 2. “злы 8 и
9 имеют по три платы, подключающие их к сетЯм 1, 2 и 3.

<p>‡аметьте, что все логические ID узлов уникальны длЯ всех трех
логических узлов.


<hr>
<table>
<td><img src="qnx4-pointing.gif" width=58 height=40 alt="Note:"></td>
<td>‹огические ID узлов сети назначаютсЯ системным администратором. Ѓолее
подробно см. в главе "“становка сети" в книге <cite>ђуководстве
пользователЯ</cite>.</td>
</table>
<hr>

<p><hr>
<p><img src="qnx4-multinet.gif" alt="fig: i/multinet.gif">
<hr>

<p><i>Ќесколько физических сетей сосуществуют посредством логических сетей.</i><pre>

</pre>


<h3><a name="CHOOSINGANET">‚ыбор сети</a></h3>
<p>‚ случае, когда узлы соединены более чем одной логической сетью,
Њенеджер сети может выбирать, какую из сетей использовать длЯ
передачи к удаленному узлу.  Ќапример, на приведенном выше рисунке
узел 7 может передавать данному узлу 8, используЯ либо сеть 1, либо
сеть 2.


<p><b><a name="id14">ђаспределение нагрузки</a></b>
<p>ЏропускнаЯ способность сети определЯетсЯ совокупностью скорости
компьютера и скорости сети.  …сли компьютер может выдавать данные
быстрее, чем сеть может их передавать, то сеть будет ограничивать
пропускную способность.

<p>Ќапример, два компьютера Pentium, соединенные сетью 10BASE-T
Ethernet, будут ограничены 1.1 миллионом байт в секунду, то есть
скоростью передачи данных, обеспечиваемой сетевым оборудованием.
Ћднако если поместить по две платы Ethernet в каждый из компьютеров
и соединить их отдельными кабелЯми, то Њенеджер сети сможет
передавать данные по обеим сетЯм одновременно.  Џри большой нагрузке
это обеспечит увеличение пропускной способности в два раза по
сравнению с одной сетью.

<p>Њенеджер сети будет пытатьсЯ сбалансировать нагрузку, выбираЯ
сетевой драйвер.  ‚ рассмотренном выше примере, если производитсЯ
передача с узла 7 на узел 8 по сети 1 и другаЯ передача на узел 8
инициируетсЯ на узле 7, то сеть 2 будет <em>автоматически</em> выбрана длЯ
передачи данных.

<p><b><a name="id15">Ћтказоустойчивость</a></b>
<p>Љогда узлы соединены двумЯ и более сетЯми, то существует больше
чем один возможный путь длЯ свЯзи. ‚ случае отказа платы в одной из
сетей, когда свЯзь по этой сети невозможна, Њенеджер сети
автоматически перенаправит все данные через другую сеть.  ќто
происходит <em>на лету</em> без какого-либо вмешательства со стороны
прикладных программ и обеспечивает прозрачную отказоустойчивость
сети. …сли кабели различных сетей проложены раздельно, то вы также
будете защищены от случайного обрыва кабелЯ.

<p>‚ы также можете проектировать системы-"тандемы", в которых две
машины соединены высокоскоростной сетью длЯ нормальной работы и
другой, более дешевой и медленной сетью (например, по
последовательному каналу), котораЯ служит резервом. ‚ случае отказа
первой сети соединение не оборветсЯ, хотЯ пропускнаЯ способность,
конечно же, снизитсЯ.


<p><b><a name="id16">Њосты между сетЯми QNX</a></b>
<p>Њенеджер сети позволЯет любому узлу играть роль моста между
двумЯ отдельными сетЯми QNX, базирующимисЯ на стандарте IEEE 802.


<hr>
<table>
<td><img src="qnx4-pointing.gif" width=58 height=40 alt="Note:"></td>
<td>’ак как QNX использует одинаковый формат пакетов и протокол на всех
IEEE 802 сетЯх, можно создавать мосты между сетЯми Ethernet, Token
Ring и FDDI.<p>„лЯ сетей Arcnet <em>нельзЯ</em> создавать мосты.</td>
</table>
<hr>

<p>ђассмотрим следующую диаграмму, где одной сети принадлежат узлы
17 и 18, а другой - узлы 18 и 19:


<p><hr>
<p><img src="qnx4-relay.gif" alt="fig: i/relay.gif">
<hr>

<p><i>Њост между двумЯ IEEE 802 QNX сетЯми.</i><pre>

</pre>

<p>“злы 17 и 18 находЯтсЯ в одной сети, поэтому они могут общатьсЯ
друг с другом напрЯмую.  ’о же справедливо длЯ узлов 18 и 19.  Ќо как
могут общатьсЯ узлы 17 и 19?

<p>’ак как <em>обе</em> локальные сети базируютсЯ на IEEE 802, узел 18
автоматически перенаправлЯет пакеты, позволЯЯ узлам 17 и 18 создать
виртуальный канал.  •отЯ они и не подключены к одной и той же
локальной сети, узлы 17 и 19, тем не менее, могут общатьсЯ друг с
другом.


<h3><a name="TCPIPNET">‘еть TCP/IP</a></h3>
<p>ЏрисущаЯ QNX поддержка сети реализует локальную сеть на основе
собственного <em>частного</em> протокола и оптимизирована длЯ организации
интерфейса между QNX компьютерами. Ќо длЯ свЯзи с не-QNX системами,
QNX использует ставший <em>промышленным стандартом</em> набор протоколов,
называемый TCP/IP.

<p>Џо мере того как €нтернет стал занимать все большее место в
нашей повсеместной жизни, протокол, на котором он основан - IP
(Internet Protocol) - приобретает все большее значение. „аже если вы
не подключаетесь непосредственно к €нтернет как к таковому, IP
протокол и свЯзанный с ним инструментарий поистине вездесущи, делаЯ
IP стандартом "де-факто" длЯ многих частных сетей.

<p>IP используетсЯ везде, начинаЯ от простых задач (например,
удаленный вход в систему (login)) и до более сложных (например,
отслеживание биржевых котировок в реальном времени). ‚се больше и
больше компаний используют World Wide Web ("всемирную паутину"),
основанную на IP, длЯ переписки с клиентами, рекламы и другой деловой
активности.


<p><b><a name="id18">Њенеджер TCP/IP</a></b>
<p>Њенеджер TCP/IP в QNX происходит из Berkley BSD 4.3, который
ЯвлЯетсЯ наиболее распространенным стеком TCP/IP в €нтернет и
использован как основа длЯ многих систем.


<p><b><a name="id19">‘окет API</a></b>
<p>Ѓиблиотека BSD сокета API была очевидным выбором длЯ QNX 4.
‘окет API ЯвлЯетсЯ стандартным API длЯ программированиЯ TCP/IP в
среде Unix.  ‚ среде Windows, Winsock API базируетсЯ на BSD сокете
API. ќто облегчает переход между ними.

<p>€меютсЯ все процедуры, которые могут понадобитьсЯ прикладным
программистам:

<p>
<i>accept()</i><br>
<i>bind()</i><br>
<i>bindresvport()</i><br>
<i>connect()</i><br>
<i>dn_comp()</i><br>
<i>dn_expand()</i><br>
<i>endprotoent()</i><br>
<i>endservent()</i><br>
<i>gethostbyaddr()</i><br>
<i>gethostbyname()</i><br>
<i>getpeername()</i><br>
<i>getprotobyname()</i><br>
<i>getprotobynumber()</i><br>
<i>getprotoent()</i><br>
<i>getservbyname()</i><br>
<i>getservent()</i><br>
<i>getsockname()</i><br>
<i>getsockopt()</i><br>
<i>herror()</i><br>
<i>hstrerror()</i><br>
<i>htonl()</i><br>
<i>htons()</i><br>
<i>h_errlist()</i><br>
<i>h_errno()</i><br>
<i>h_nerr()</i><br>
<i>inet_addr()</i><br>
<i>inet_aton()</i><br>
<i>inet_lnaof()</i><br>
<i>inet_makeaddr()</i><br>
<i>inet_netof()</i><br>
<i>inet_network()</i><br>
<i>inet_ntoa()</i><br>
<i>ioctl()</i><br>
<i>listen()</i><br>
<i>ntohl()</i><br>
<i>ntohs()</i><br>
<i>recv()</i><br>
<i>recvfrom()</i><br>
<i>res_init()</i><br>
<i>res_mkquery()</i><br>
<i>res_query()</i><br>
<i>res_querydomain()</i><br>
<i>res_search()</i><br>
<i>res_send()</i><br>
<i>select()</i><br>
<i>send()</i><br>
<i>sendto()</i><br>
<i>setprotoent()</i><br>
<i>setservent()</i><br>
<i>setsockopt()</i><br>
<i>shutdown()</i><br>
<i>socket()</i><br>
<p>ђаспространенные утилиты и демоны из €нтернет могут быть легко
перенесены или просто перекомпилированы в такой среде. ќто облегчает
использование имеющихсЯ готовых наработок.


<p><b><a name="id20">‚озможность взаимодействиЯ сетей</a></b>
<p>Џри разработке Њенеджера TCP/IP в QNX в первую очередь
принималась во внимание возможность взаимодействиЯ сетей.  “читывались
как требованиЯ RFC, так и реальные условиЯ.  Њенеджер TCP/IP
охватывает всю функциональность, предлагаемую RFC 1122.  ’акже
поддерживаютсЯ протоколы ARP, IP, ICMP, UDP и TCP.

<h3><a name="id21">NFS</a></h3>
<p>Network File System (NFS) ЯвлЯетсЯ приложением TCP/IP,
реализованным на большинстве DOS и Unix систем.  NFS позволЯет
отображать удаленные файловые системы - или их части - в локальное
пространстве имен. ”айлы на удаленной системе показываютсЯ как часть
локальной файловой системы QNX.
<p>

<hr>
<table>
<td><img src="qnx4-pointing.gif" width=58 height=40 alt="Note:"></td>
<td>‚ QNX 4 длЯ поддержки NFS требуетсЯ менеджер <tt>Socket</tt>.  “чтите,
что "облегченнаЯ" версиЯ менеджера, <tt>Socklet</tt>, может быть
использована, если нет необходимости в NFS.</td>
</table>
<hr>

<h3><a name="id22">SMB</a></h3>
<p>Server Message Block (SMB), который используетсЯ многими различными
серверами, такими как Windows NT, Windows 95, Windows for Workgroups,
LAN Manager и Samba. <tt>SMBfsys</tt> позволЯет клиенту QNX прозрачный
доступ к удаленным дискам на таких серверах.


<!-- 7 -->


<!-- 8 -->

<h2><a name="p8">ЋконнаЯ система Photon microGUI</a></h2>


<p>ќта глава охватывает следующие темы:
<ul><li><a href="#GRAPHMICROK">графическое микроЯдро;</a></li><li><a href="#EVENTSPACE">пространство событий;</a></li><li><a href="#GRAPHDRIVERS">графические драйверы;</a></li><li><a href="#SCALEFONTS">масштабируемые шрифты;</a></li><li><a href="#UNICODE">многоЯзычнаЯ поддержка Unicode;</a></li><li><a href="#ANIMATE">поддержка анимации;</a></li><li><a href="#PRINTING">поддержка печати;</a></li><li><a href="#PWM">менеджер окон Photon;</a></li><li><a href="#WIDGET">библиотека виджетов;</a></li><li><a href="#SUMMARY">резюме.</a></li></ul>

<h3><a name="GRAPHMICROK">ѓрафическое микроЯдро</a></h3>
<p>Њногие встроенные системы нуждаютсЯ в пользовательском
интерфейсе.  „лЯ сложных приложений или длЯ максимальной простоты
использованиЯ, естественным выбором ЯвлЯетсЯ графическаЯ оконнаЯ
система. Ћднако оконные системы настольных ЏЉ требуют слишком много
системных ресурсов длЯ практического применениЯ во встроенных
системах, где памЯть и стоимость ограничены.
<p>Џри создании оконной системы Photon microGUI была применена
архитектура микроЯдра, успешно воплощеннаЯ в QNX длЯ созданиЯ POSIX
Ћ‘ длЯ встроенных систем.


<p>„лЯ успешной реализации Ћ‘ на основе микроЯдра в первую очередь
было необходимо добитьсЯ максимальной эффективности IPC (так как от
IPC зависит производительность всей Ћ‘). ЃлагодарЯ воплощенному в QNX
механизму IPC с низкими издержками, стало возможным создание
структуры GUI как графического "микроЯдра", окруженного командой
взаимодействующих процессов, общающихсЯ через IPC.


<p>•отЯ на первый взглЯд это может показатьсЯ похожим на построение
графической системы по классической схеме клиент/сервер, используемой
в X Window System, архитектура Photon отличаетсЯ за счет ограничениЯ
функциональности, реализуемой внутри самого графического микроЯдра
(или сервера), и распределениЯ большей части функций GUI между
взаимодействующими процессами.


<p>ЊикроЯдро Photon выполнЯетсЯ как маленький процесс (размер кода
45K), реализуЯ только несколько фундаментальных примитивов, которые
внешние опциональные процессы используют длЯ построениЯ более
высокого уровнЯ функциональности оконной системы.  Џо иронии, длЯ
самого микроЯдра Photon "окна" не существуют.  ЊикроЯдро Photon не
может также "рисовать" что-либо или управлЯть мышью либо клавиатурой.


<p>„лЯ управлениЯ средой GUI, Photon создает 3-мерное "пространство
событий" и ограничиваетсЯ только оперированием регионами и
выполнением отсечениЯ и направлениЯ различных событий по мере их
прохождениЯ сквозь регионы в этом пространстве событий.


<p>ќта абстракциЯ напоминает концепцию микроЯдра Ћ‘, которое не
поддерживает функции ввода/вывода длЯ устройств или файловой
системы, а полагаетсЯ на внешние процессы, предоставлЯющие эти
услуги высокого уровнЯ. ќто обеспечивает масштабируемость Ћ‘ и GUI,
построенных на основе микроЯдра, по размеру и функциональности .
<p>‚ основе "абстракции" микроЯдра Photon лежит воображаемое
графическое <i>пространство событий</i>, в которое другие процессы могут
помещать <i>регионы</i>.  €спользуЯ QNX IPC длЯ свЯзи с микроЯдром
Photon, эти процессы управлЯют своими регионами длЯ предоставлениЯ
графических сервисных функций высокого уровнЯ или длЯ выполнениЯ функций
пользовательских приложений. „лЯ систем с ограниченными ресурсами Photon
может масштабироватьсЯ "вниз" за счет <em>удалениЯ</em> процессов,
предоставлЯющих сервисные функции, а за счет <em>добавлениЯ</em>
процессов, предоставлЯющих сервисные функции, Photon может
масштабироватьсЯ "вверх" до полнофункциональной настольной системы.


<h3><a name="EVENTSPACE">Џространство событий Photon</a></h3>
<p>"Џространство событий" можно представить как пустое трехмерное
пространство с "корневым регионом" на заднем плане. Џользователи
как будто "смотрЯт внутрь" этого пространства событий. ЏриложениЯ
помещают регионы в трехмерное пространство между корневым регионом и
пользователем; они используют эти регионы длЯ генерации и приема
различных типов событий в этом пространстве.

<p>Џроцессы, которые выполнЯющие обслуживание драйверов устройств,
помещают регионы на передний план пространства событий. ‚ дополнение
к управлению пространством событий и корневым регионом, микроЯдро
Photon поддерживает экранный указатель (курсор), проецируемый
как <i>событиЯ рисованиЯ</i> по направлению к пользователю.
<hr>

<p><img src="qnx4-regions.gif" alt="fig: i/regions.gif">
<hr>

<p><i>Photon использует последовательность регионов, начинаЯ от
корневого региона на заднем плане пространства событий до
графического региона спереди. ‘обытиЯ рисованиЯ двигаютсЯ от регионов
приложений к графическому региону.  ‘обытиЯ ввода возникают в регионе
курсора/клавиатуры и двигаютсЯ по направлению к корневому региону.</i><pre>

</pre>

<p>„вигающиесЯ в пространстве событий событиЯ можно представить
себе как "фотоны" (что и дало название оконной системе). ‘ами
событиЯ состоЯт из набора прЯмоугольных областей и прикрепленных к
ним данных.  Џо мере движениЯ событий в пространстве событий их
прЯмоугольники пересекают регионы, принадлежащие различным процессам
(приложениЯм).
<p>Џро событиЯ, которые двигаютсЯ от корневого региона, говорЯт,
что они перемещаютсЯ наружу (по направлению к пользователю), в то
времЯ как про событиЯ от пользователЯ говорЯт, что они двигаютсЯ
внутрь, по направлению к корневому региону.
<p>‚заимодействие между событиЯми и регионами лежит в основе ввода
и вывода в Photon.  ‘обытиЯ мыши, клавиатуры и светового пера
двигаютсЯ от пользователЯ к корневому региону, с "прикрепленным" к
ним положением курсора.  ‘обытиЯ рисованиЯ возникают в регионах и
двигаютсЯ по направлению к региону устройства и пользователю.

<p><b><a name="id4">ђегионы</a></b>
<p>Љаждому региону соответствует прЯмоугольнаЯ область,
определЯющаЯ его положение в 3-мерном пространстве событий. ђегион
также имеет атрибуты, определЯющие, как он взаимодействует с
различными классами событий при пересечении ими региона.
‚заимодействие региона с событиЯми определЯетсЯ двумЯ битовыми
масками:


<ul><li>маска <i>чувствительности</i>;</li><li>маска <i>непрозрачности</i>.</li></ul><p>Њаска чувствительности определЯет, должен ли процесс-владелец
региона оповещатьсЯ о пересечении региона тем или иным событием.
Љаждый бит маски чувствительности определЯет, чувствителен ли регион
к определенному типу событий.  Љогда событие пересекает регион, длЯ
которого установлен бит (равен 1), копиЯ этого событиЯ помещаетсЯ в
очередь процесса-владельца региона, извещаЯ приложение о прохождении
событиЯ через регион. ’акое извещение никак не изменЯет само событие.
<p>Њаска непрозрачности определЯет прозрачность региона длЯ тех или
иных событий.  Љаждый бит этой маски определЯет, ЯвлЯетсЯ ли регион
прозрачным длЯ определенного типа событиЯ. Џри прохождении событиЯ
сквозь "непрозрачный" регион, оно модифицируетсЯ.
<p>ќти две битовые маски могут быть совместно использованы длЯ
достижениЯ различных результатов. ‚озможны следующие четыре сочетаниЯ
длЯ региона:
<table border>
<tr><th>‘очетание битовых масок:
        </th><th>Ћписание:
</th></tr><tr><td>Ќечувствительный, прозрачный.
        </td><td>Џри прохождении событиЯ через регион, оно не модифицируетсЯ, и
владелец региона не извещаетсЯ.  Џроцесс-владелец региона просто не
интересуетсЯ событием.
</td></tr><tr><td>Ќечувствительный, непрозрачный.
        </td><td>Џри прохождении событиЯ через регион, оно отсекаетсЯ; владелец
региона не извещаетсЯ.  Ѓольшинство приложений используют такую
комбинацию атрибутов длЯ отсечениЯ событий рисованиЯ, чтобы избежать
перерисовки окна событиЯми рисованиЯ, исходЯщими от лежащих под ним
окон.
</td></tr><tr><td>—увствительный, прозрачный.
        </td><td>ЉопиЯ событиЯ направлЯетсЯ владельцу региона; событие продолжит
движение в пространстве событий, не изменЯЯсь.  Џроцесс, желающий
регистрировать прохождение всех событий, может использовать такую
комбинацию.
</td></tr><tr><td>—увствительный, непрозрачный.
        </td><td>ЉопиЯ событиЯ направлЯетсЯ владельцу региона; событие отсекаетсЯ
регионом. “становив такую комбинацию масок, событие может играть
роль фильтра или преобразователЯ. Џриложение может обработать любое
полученное событие, регенерировать его и при необходимости
преобразовать его каким-либо образом при этом, возможно, изменив
направление движениЯ или координаты. Ќапример, регион может поглощать
событиЯ светового пера, выполнЯть распознавание почерка, а затем
генерировать эквивалентные событиЯ нажатиЯ клавиш.
</td></tr></table>

<p><b><a name="id5">‘обытиЯ</a></b>
<p>Џодобно регионам, событиЯ могут относитьсЯ к различным классам и
иметь различные атрибуты, как, например:
<ul><li>регион происхождениЯ;</li><li>тип;</li><li>направление;</li><li>прикрепленный список прЯмоугольников;</li><li>специфические длЯ данного событиЯ данные.</li></ul><p>‚ отличие от большинства оконных систем, Photon
классифицирует <em>не только</em> ввод (перо, мышь, клавиатура т.д.),
но и вывод (запросы рисованиЯ) как событиЯ.  ‘обытиЯ могут
генерироватьсЯ как регионами, которые процессы поместили в
пространство событий, так и самим микроЯдром Photon.  Ћпределены
следующие типы событий:


<ul><li>нажатиЯ клавиш;</li><li>нажатиЯ пера и кнопок мыши;</li><li>перемещениЯ пера и мыши;</li><li>пересечение границ региона;</li><li>событиЯ экспозиции и перекрытиЯ;</li><li>событиЯ рисованиЯ;</li><li>событиЯ перетаскиваниЯ (drag).</li></ul><p>ЏриложениЯ могут либо ждать наступлениЯ событий, и при этом
блокироватьсЯ, либо получать асинхронные извещениЯ о приходе событиЯ.
<p>‘писок прЯмоугольников, прикрепленный к событию, может
определЯть одну или более прЯмоугольных областей, либо "исходную
точку" - единственный прЯмоугольник, у которого координаты верхнего
левого и нижнего правого углов совпадают.


<p>Џри пересечении событием непрозрачного региона, прЯмоугольник
региона "вырезаетсЯ" из списка прЯмоугольников событиЯ так, что
список описывает теперь только видимую часть событиЯ.

<p>‹учше всего иллюстрирует такое отсечение то, как изменЯетсЯ
список прЯмоугольников событиЯ рисованиЯ по мере его прохождениЯ
сквозь различные регионы.  Љогда событие рисованиЯ генерируетсЯ,
список прЯмоугольников содержит единственный прЯмоугольник,
описывающий породивший событие регион.
<p>…сли событие проходит через регион, который отсекает, например,
верхний левый угол событиЯ рисованиЯ, то список прЯмоугольников
модифицируетсЯ и будет содержать уже два прЯмоугольника, которые
определЯют область, подлежащую отрисовке.  ќти результирующие
прЯмоугольники называютсЯ "плитки" (tiles).
<p>Џодобным образом, каждый раз при пересечении событием рисованиЯ
непрозрачного региона, список прЯмоугольников будет модифицироватьсЯ
таким образом, чтобы описывать область, оставшуюсЯ видимой после
"вырезаниЯ" непрозрачного региона.  Љогда, наконец, событие рисованиЯ
достигнет графического драйвера, то список прЯмоугольников будет
точно описывать только его видимую часть.
<hr>
<p><img src="qnx4-clipping.gif" alt="fig: i/clipping.gif">
<hr>

<p><i>Ќепрозрачные длЯ событиЯ рисованиЯ регионы вырезаютсЯ, в
результате чего получаетсЯ область, состоЯщаЯ из прЯмоугольных
"плиток".</i><pre>

</pre>

<p>‚ том случае, если событие рисованиЯ целиком отсекаетсЯ при
пересечении с регионом, оно прекращает существование.  ќтот механизм
"непрозрачных" окон, изменЯющих список прЯмоугольников событиЯ
рисованиЯ, обеспечивает правильное отсечение событий рисованиЯ по
мере их продвижениЯ от исходного региона (и свЯзанного с ним
процесса) к пользователю.


<h3><a name="GRAPHDRIVERS">ѓрафические драйверы</a></h3>
<p>ѓрафические драйверы реализованы как процессы, которые помещают
регион на переднем плане пространства событий. ђегион графического
драйвера <em>чувствителен</em> к событиЯм рисованиЯ, исходЯщим из
пространства событий. ѓрафический драйвер получает событиЯ рисованиЯ,
когда они пересекают его регион. Њожно представить себе, что регион
покрыт "фосфором", который светитсЯ при попадании "фотонов".


<p>’ак как API рисованиЯ Photon накапливает запросы рисованиЯ в
пакеты, посылаемые как одно событие рисованиЯ, то каждое событие
рисованиЯ, получаемое драйвером, содержит список графических
примитивов, подлежащих отрисовке.  Љ моменту пересечениЯ событием
рисованиЯ региона драйвера, список прЯмоугольников будет содержать
также "список отсечений", описывающий, какие именно части списка
рисованиЯ должны отображатьсЯ на дисплее. ђабота драйвера заключаетсЯ
в том, чтобы преобразовать результирующий список в визуальное
отображение на контролируемом графическом оборудовании.
<p>Ћдно из преимуществ использованиЯ списка прЯмоугольников внутри
событиЯ состоит в том, что каждое передаваемое драйверу событие
представлЯет собой фактически "пакет" запросов.  Џо мере
совершенствованиЯ графического оборудованиЯ, все больше и больше
такой "пакетной" работы может передаватьсЯ непосредственно
оборудованию.  Њногие видеоадаптеры уже поддерживают аппаратно одну
область отсечениЯ, а некоторые поддерживают и несколько областей.
<p>•отЯ использование механизма QNX IPC длЯ передачи запросов
рисованиЯ от приложений к графическому драйверу и может показатьсЯ
неприемлемой избыточностью, тесты производительности показывают, что
производительность в данном варианте не хуже, чем в случае, когда
приложениЯ выполнЯют прЯмые вызовы драйвера. Ћдной из причин ЯвлЯетсЯ
то, что при использовании событий многочисленные запросы рисованиЯ
группируютсЯ, что уменьшает количество посылаемых сообщений по
сравнению с количеством прЯмых вызовов драйвера.

<p><b><a name="id7">Ќесколько графических драйверов</a></b>
<p>€з того, что графический драйвер просто помещает регион в
пространство событий Photon, естественно следует, что одновременно
могут быть запущены несколько графических драйверов длЯ нескольких
видеоадаптеров, при этом каждый драйвер будет иметь свой,
чувствительный к событиЯм рисованиЯ, регион.


<p>ќти регионы могут быть расположены рЯдом, либо перекрывать друг
друга произвольным образом.  ’ак как Photon наследует от QNX сетевую
прозрачность, то приложениЯ или драйверы Photon могут выполнЯтьсЯ на
любом узле сети, позволЯЯ, таким образом, дополнительным графическим
драйверам расширЯть графическое пространство Photon за счет
физических дисплеев других компьютеров в сети. ‡а счет перекрытиЯ
регионов графических драйверов, событиЯ рисованиЯ могут дублироватьсЯ
на нескольких экранах.
<p>Њногие интересные приложениЯ стали возможны благодарЯ этим
свойствам Photon.  Ќапример, на заводе оператор с портативным
компьютером, имеющим беспроводное подключение к сети, может подойти к
рабочей станции и "перетащить" панель управлениЯ с ее монитора на
экран портативного компьютера, а затем перейти в цех и осуществлЯть
управление.
<p>‚ других приложениЯх встроеннаЯ система без пользовательского
интерфейса может проецировать дисплей на любой из узлов сети.  Љроме
того, становитсЯ возможным коллективный режим работы - несколько
человек, находЯсь за своими компьютерами, могут одновременно видеть
одни и те же окна и работать с одним и тем же приложением.
<p>‘ точки зрениЯ приложениЯ, это выглЯдит как одно единое
графическое пространство.  ‘ точки зрениЯ пользователЯ, это выглЯдит
как группа соединенных компьютеров, где можно перетаскивать окна с
одного физического экрана на другой.


<p><b><a name="id8">–ветоваЯ модель</a></b>
<p>„лЯ представлениЯ цветов используетсЯ 24-битнаЯ RGB модель (по 8
бит длЯ красного, зеленого и синего), что обеспечивает 16,777,216
цветов.  ‚ зависимости от используемого типа оборудованиЯ, драйвер
либо непосредственно отображает 24-битный цвет, либо использует
различные варианты смешиваниЯ цветов, чтобы отобразить требуемый цвет
на оборудовании, поддерживающем меньшее число цветов.

<p>’ак как графические драйверы используют аппаратно-независимое
представление цветов, то приложениЯ могут работать без изменениЯ на
различном оборудовании, независимо от того, какую цветовую модель оно
поддерживает.  ќто позволЯет "перетаскивать" приложениЯ с одного
монитора на другой, не задумываЯсь о том, какаЯ цветоваЯ модель
аппаратно реализована в каждом конкретном случае.


<h3><a name="SCALEFONTS">Њасштабируемые шрифты</a></h3>
<p>‚ дополнение к поддержке растровых шрифтов, Photon также
предлагает масштабируемые шрифты. ќти шрифты могут масштабироватьсЯ
практически с любым размером точки и использовать технологию
сглаживаниЯ (16 оттенков) длЯ четкого и Ясного отображениЯ на экране
с любым разрешением.
<p>Њасштабируемые шрифты в Photon поддерживаютсЯ быстродействующим
сервером шрифтов, который загружает описаниЯ шрифтов, хранЯщиесЯ в
сжатом виде в файлах <tt>*.pfr</tt> (Portable Font Resource, ресурсы
переносимых шрифтов), и затем приводит вид символов в соответствие с
любым размером точки и разрешением. ‘тоит отметить, что формат PFR
обеспечивает более чем в два раза лучшее сжатие по сравнению с
PostScript шрифтами.


<p><b><a name="id10">Ќаборы шрифтов</a></b>

<h3><a name="id11">Ћсновной латинский набор</a></h3>
<p><em>Ћсновной латинский (Core Latin)</em> набор шрифтов
Photon (<tt>latin1.pfr</tt>), который охватывает два набора
символов стандарта Unicode, <em>Basic Latin</em> (U+0000 - U+007F)
и <em>Latin-1 Supplement</em> (U+0080 - U+00FF), включает следующие
масштабируемые шрифты:
<ul><li>Dutch;</li><li>Dutch Bold;</li><li>Dutch Italic;</li><li>Dutch Bold Italic;</li><li>Swiss;</li><li>Swiss Bold;</li><li>Swiss Italic;</li><li>Swiss Bold Italic;</li><li>Courier;</li><li>Courier Bold;</li><li>Courier Italic;</li><li>Courier Bold Italic.</li></ul>
<h3><a name="id12">ђасширенный латинский набор</a></h3>
<p><em>ђасширенный латинский</em> (Extended Latin) набор
(<tt>latinx.pfr</tt>) охватывает наборы символов Unicode <em>Latin
Extended-A</em> (U+0100 - U+017F) и <em>Latin Extended-B</em> (U+0180 -
U+0217) и включает следующие шрифты:
<ul><li>Dutch;</li><li>Dutch Bold;</li><li>Dutch Italic (генерируетсЯ алгоритмически);</li><li>Dutch Bold Italic (генерируетсЯ алгоритмически);</li><li>Swiss;</li><li>Swiss Bold;</li><li>Swiss Italic (генерируетсЯ алгоритмически);</li><li>Swiss Bold Italic (генерируетсЯ алгоритмически).</li></ul>
<p><b><a name="id13">Џоддерживаемые Языки</a></b>
<p>€меЯ в своем распорЯжении Ћсновной латинский набор (<tt>latin1.pfr</tt>),
разработчик может поддерживать множество Языков, включаЯ:

<p><p>„атский;<br>
ѓолландский;<br>
Ђнглийский;<br>
”инский;<br>
”ламандский;<br>
”ранцузский;<br>
Ќемецкий;<br>
ѓавайский;<br>
€сландский;<br>
€ндонезийский;<br>
€рландский;<br>
€тальЯнский;<br>
Ќорвежский;<br>
Џортугальский;<br>
€спанский;<br>
‘уахили;<br>
ведский.<br>
<p>ђасширенный набор (<tt>latinx.pfr</tt>) позволЯет дополнительно поддерживать:
<p>
<p>Ђфриканский;<br>
Ѓаскский;<br>
Љаталонский;<br>
•орватский;<br>
—ешский;<br>
ќсперанто;<br>
ќстонский;<br>
ѓренландский;<br>
‚енгерский;<br>
‹атышский;<br>
‹итовский;<br>
Њальтийский;<br>
Џольский;<br>
ђумынский;<br>
‘ловацкий;<br>
’урецкий;<br>
‚аллийский.<br>
<p><b><a name="id14">„ополнительные Языковые пакеты</a></b>
<p>„лЯ Photon предлагаютсЯ несколько дополнительных
пакетов длЯ поддержки национальных Языков:

<ul><li><em>џпонский</em>;
</li><li><em>Љитайский</em>;
</li><li><em>Љорейский</em>;
</li><li><em>Љириллица</em>.

</li></ul>

<h3><a name="UNICODE">ЊногоЯзычнаЯ поддержка Unicode</a></h3>
<p>Photon разработан с учетом поддержки национальных символов.
‘ледуЯ стандарту Unicode (ISO/IEC 10646), Photon предоставлЯет
разработчикам возможность создавать приложениЯ, поддерживающие
основные мировые Языки.

<p>Unicode основываетсЯ на наборе символов ASCII, но использует
16-битную кодировку длЯ полной поддержки многоЯзычного текста. Ќет
никакой необходимости прибегать к escape-последовательностЯм или
управлЯющим кодам длЯ заданиЯ любого символа любого Языка. ‡аметьте,
что кодировка Unicode обрабатывает все символы - алфавитные,
идеограммы, специальные символы - абсолютно одинаковым образом.

<p><b><a name="id16">UTF-8 кодировка</a></b>
<p>€звестнаЯ раньше как UTF-2, UTF-8 (от "8-битнаЯ форма")
кодировка определЯет использование символов Unicode в 8-битной среде
UNIX.

<p>‚от некоторые основные характеристики UTF-8:
<ul><li>Unicode-символы от U+0000 до U+007E (набор ASCII) отображаютсЯ
в UTF-8-байты от 00 до 7E (ASCII-значениЯ);
</li><li>ASCII-значениЯ не встречаютсЯ иным образом в UTF-8,
обеспечиваЯ полную совместимость с файловыми системами, которые
анализируют ASCII-байты;
</li><li>UTF-8 упрощает преобразование в Unicode-текст и из него;
</li><li>Џервый байт указывает количество байт в многобайтной
последовательности, обеспечиваЯ эффективный разбор;
</li><li>Њожно легко найти начало символа из любого места в потоке
байт, так как длЯ этого необходимо перебрать не более четырех байт, а
начальный байт легко определить. Ќапример:<pre>
isInitialByte = ((byte &amp; 0xC0) != 0x80);
</pre>


</li><li>UTF-8 достаточно компактен, имеЯ в виду количество
байт, используемых длЯ кодировки.
</li></ul><p CHANGED="CHANGED">‘истемнаЯ библиотека включает рЯд функций
преобразованиЯ:
<table border>
<tr><th>”ункциЯ:</th><th>Ћписание:</th></tr>
<tr><td><i>mblen()</i></td><td>„лина многобайтной строки в символах</td></tr>
<tr><td><i>mbtowc()</i></td><td>Џреобразовать многобайтный символ в двухбайтный символ</td></tr>
<tr><td><i>mbstowcs()</i></td><td>Џреобразовать многобайтную строку в двухбайтную строку</td></tr>
<tr><td><i>wctomb()</i></td><td>Џреобразовать двухбайтный символ в его многобайтное представление</td></tr>
<tr><td><i>wcstombs()</i></td><td>Џреобразовать строку двухбайтных символов в многобайтную строку</td></tr></table>

<p>‚ дополнение к перечисленным выше функциЯм, разработчики могут также
воспользоватьсЯ собственной библиотекой Photon, функциЯми
<i NB="NB">PxTranslate</i>, которые выполнЯт различные преобразованиЯ
наборов символов в/из UTF-8.


<h3><a name="ANIMATE">Џоддержка анимации</a></h3>
<p>Photon обеспечивает немерцающую анимацию через специальный
виджет-контейнер с "двойным буфером" (<tt>PtDBContainer</tt>), который
создает специальный контекст в памЯти длЯ отрисовки изображений.
<p>‚иджет <tt>PtDBContainer</tt> использует блок разделЯемой памЯти,
достаточный длЯ хранениЯ изображениЯ соответствующего размера.


<h3><a name="PRINTING">Џоддержка печати</a></h3>
<p>Photon предусматрив
‘очетание битовых масок:	Ћписание:
Ќечувствительный, прозрачный.	Џри прохождении событиЯ через регион, оно не модифицируетсЯ, и владелец региона не извещаетсЯ. Џроцесс-владелец региона просто не интересуетсЯ событием.
Ќечувствительный, непрозрачный.	Џри прохождении событиЯ через регион, оно отсекаетсЯ; владелец региона не извещаетсЯ. Ѓольшинство приложений используют такую комбинацию атрибутов длЯ отсечениЯ событий рисованиЯ, чтобы избежать перерисовки окна событиЯми рисованиЯ, исходЯщими от лежащих под ним окон.
—увствительный, прозрачный.	ЉопиЯ событиЯ направлЯетсЯ владельцу региона; событие продолжит движение в пространстве событий, не изменЯЯсь. Џроцесс, желающий регистрировать прохождение всех событий, может использовать такую комбинацию.
—увствительный, непрозрачный.	ЉопиЯ событиЯ направлЯетсЯ владельцу региона; событие отсекаетсЯ регионом. “становив такую комбинацию масок, событие может играть роль фильтра или преобразователЯ. Џриложение может обработать любое полученное событие, регенерировать его и при необходимости преобразовать его каким-либо образом при этом, возможно, изменив направление движениЯ или координаты. Ќапример, регион может поглощать событиЯ светового пера, выполнЯть распознавание почерка, а затем генерировать эквивалентные событиЯ нажатиЯ клавиш.
”ункциЯ:	Ћписание:
mblen()	„лина многобайтной строки в символах
mbtowc()	Џреобразовать многобайтный символ в двухбайтный символ
mbstowcs()	Џреобразовать многобайтную строку в двухбайтную строку
wctomb()	Џреобразовать двухбайтный символ в его многобайтное представление
wcstombs()	Џреобразовать строку двухбайтных символов в многобайтную строку