Главная

Особенности программирования BeOS API для пришельцев - введение. Часть 1-я.

Невозможно рассказать об особенностях программирования в BeOS, не упомянув одну особенность архитектуры этой ОС — модульность. BeOS целиком построен на основе сервисов, или серверов (servers) — программных демонов (в юникс–терминологии). Таких как Сервер Приложений (Application Server), выполняющий отрисовку всего видимого слоя в BeOS и обеспечивающего общение программ с системой и между собой. Или Медиа–Сервер (MediaServer) — превращающий медиа–потоки в звук и видео. Все вызовы функций/методов BeOS API из пользовательской программы в подавляющем числе случаев выполняются одним из этих серверов. В иерархии слоев ОС эти сервера находятся на уровне обычной пользовательской программы. То есть имеют те же права и методы доступа к системным ресурсом (памяти, процессору, периферии), как и гипотетическая «любая обычная» программа. А это значит, что ошибка в пользовательской программе вызовет в худшем случае падение только этого сервера (во многих случаях его можно перезапустить, «не отходя от кассы», то есть не перегружая всю систему — как многие из вас делали с NetServer или MediaServer).
Кроме того, каждый из серверов запускает множество практически независимых потоков (threads, дословно — нить) для обслуживания обращений от других программ, поэтому, во многих случаях, умирает лишь «поврежденный» поток. Такие умирающие не своей смертью потоки вылавливаются постоянно действующей «ловушкой для клопов и соломкой для падений» — Debug Server. Для последующей экспертизы. Причем, это не совсем паталогоанатомия трупа — до закрытия окна Debug Server поток находится в состоянии всего лишь клинической смерти, ему могут быть сделаны анализы, а иногда он может быть даже реанимирован.

Наиболее важный из них для нашего дальнейшего разговора — это, естественно, Application Server, обеспечивающий наибольшую часть функциональности программ. Не то, что бы мы его намеревались упоминать направо и налево, но во всем дальнейшем разговоре он будет играть роль «серого кардинала».
В принципе, AppServer — хорошая иллюстрация быстрой и эффективной клиент–серверной архитектуры для графического интерфейса пользователя (GUI).
То, о чем десктопный юникс–народ с их X11 может пока только мечтать (о сетевой функциональности X11 здесь речь не идет, тем более, что в версии BeOS 5.1 по имеющимся сведениям, вся эта клиент–серверность с тем же успехом работала и через сеть).
Впрочем, есть и другой пример эффективной реализации этой идеи — Photon в операционной системе QNX.

Значительная заслуга во впечатляющей работе AppServer принадлежит многопоточности.
Наверное надо чуть пояснить про потоки. Начинающие программисты, даже программируя в многозадачной среде, редко в явном виде сталкиваются с этим зверем. В BeOS же без него ни шагу не ступить. Или, скорее невозможно на эти грабли не наступить. Образно говоря, это такой минимальный целостный кусок исполняемого кода, у которого может создаться впечатление, что он настолько самый главный, что все ресурсы машины принадлежат ему одному.
Концепция потоков является развитием концепции многозадачности. На всякий пожарный, поясню и это.
Вас никогда не удивляло, что процессор, как правило — один, видеокарта, скажем, тоже одна — а тем не менее вроде все программы выполняются одновременно и другу другу не мешают (хехе, вот тут и отличие грамотно сделанной ОС от…)? Делается это за счет очень быстрого переключения процессора с одного куска кода на другой. Для временно осиротевшего кода запоминается его состояние и частично состояние ОС в момент остановки, то есть всяческие данные, необходимые для последующей реанимации.
Вот такой исполняющийся код, вместе с этими самыми постоянно обновляемыми «реанимационными данными», и есть процесс, или задача. В былые времена весь код, относящейся к одной программе, обычно и представлял из себя единый и единственный процесс. Теперь же и единая программа может из себя представлять целый набор параллельно выполняющихся кусков, тем самых потоков–нитей (threads). В целом же потоки–нити одной программы образуют связку — team. При этом каждый из потоков программы может получить некоторый доступ к общим для team данным.

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

Теперь можно спуститься и поближе к земле, то есть к BeOS API. Единственно, что меня слегка гложет — это степень необходимости пояснения понятия Объектно Ориентированного Программирования (OOP) по ходу текста.
Хотя нынешняя молодежь должны была бы всосать это дело с первым глотком кока–колы, мой опыт показывает, что это не так. Хотя даже VisualBasic дает (тем кто интересуется) достаточный опыт, оказывается, что и активные пользователи таких объектных сред как Delphi и BorlandBuilder зачастую имеют о предмете весьма смутное представление. Так что заранее прошу OOP–гуру извинить меня за последующее занудство и некоторый примитивизм:)

Для удобства программиста (который тоже человек:), весь набор фунций/методов для BeOS разбит на инструментальные комплекты — Kits. Например Networking Kit, Media Kit, Storage Kit. Сейчас нас будут интересовать два из них Инструментарий Приложений — Application Kit и Инструментарий Интерфейса — Interface Kit.

На все это дело можно взглянуть в библии BeOS–програмирования, BeBook.
В интернете — http://www.beclan.org/BeBook/
или, если вы уже поставили комплект разработчика BeOS — BeOS Development Tools — на вашем диске:
file:///boot/beos/documentation/Be%20Book/index.html

Начнем с головы, точнее с двух — main() и be_app. И если первое слово знакомо каждому С–шнику, то второе — уже чистый BeOS.
------------------------------------------------------–
Продолжение следует…

(С) Сергей Долгов, 2004

Очень неплохо! Жаль, что я не програмист:(

Я, как было сказано в предыдущей статье, «творческий» элемент, попросту любопытствующий, и моего любопытства хватило, что бы понять две вещи: 1 — в ВеОсе заложены коллосальные возможности, 2 — пипец придет этой оси, если её ближайшее время не распостронят в исходниках, количество программеров не увеличится и не станут писать BeOS ориентированные приложения(а не портировать монструозные LinuxApps)…

Программирование - вопросы и ответы

тут меня уже начали спрашивать те вещи, про которые я собирался рассказать в следующей статье или даже дальше. Чтоб оно не пропало — помещаю в комментарии:

Vladimir: только вопрос — правильно ли я понял из орейливской книги что любое окно в бе — отдельный поток?

fyysik: ага, даже два
fyysik: каждое окно имеет поток–"брата" в AppServer — такие Джекил и Хайд
Vladimir: эээ…что за Джекил и Хайд? и зачем братья–потоки?
fyysik: это знаменитый роман английский про мистера Джекила и мистера Хайда (Hide — спрятанный). МистерДжекил захотел вечной молодости, и у него завелся двойник в зеркале — мистер Хайд
Vladimir: ясненько
fyysik: почему братья потоки — об этом позже. Грубо говоря — программа сама ничего не рисует, рисует апп–сервер, но для тебя как программиста — это прозрачно–невидимо.

Просто пишешь, скажем, DrawString — и беосное окно перебрасывает этот вызов невидимо для тебя близнецу в AppServer, а тот уж занимается делом — а поток программы при этом уже свободен для других действий

Vladimir: грубо говоря один поток ловит события юзера а второй уже выполняет что ему программа скажет?

fyysik: это вторая сторона процесса взаимодействия программы и AppServer. АппСервер ловит клавиши и мышу и другие «внешние события» и кидает их программе, та кидает их окну (BWindow), а окно — виду (BView)
Кстати поэтому ты не можешь взять пиксели из одного вида (BView) и скопировать в другой — не принадлежат эти пиксели BView, а принадежат AppServer.
Зато ты модешь запомнить последовательность инструкций рисования в объекте BPicture — а потом вылить этот объект в другой bView

Хорошее начало.

По поводу ООП, я рекомендовал бы поискать книгу Г.Буч «Объектно–ориентированный анализ и проектирование» отличная книга, класика, сам по ней учился. ценность ее в том что она учит объектно–ориентированно мыслить, и не привязывает к конкретной платформе, в ней вообще нет кода как такового, взят для удобства только синтаксис С++. Думаю будет полезна даже для тех, кто считает себя гуру в вопросах ООП. Если б не БиОся и не эта книга, наверно до сих пор сидел бы в досе, и занимался бы структурным программированием.

есть еще одна достойная книга, но по мне она немного скучновата: Гама Хелм Джонсон Влиссидес «Приемы объектно–ориентированного
проектирования — паттерны проектирования»,

Отправить комментарий

Содержание этого поля является приватным и не предназначено к показу.
  • Адреса страниц и электронной почты автоматически преобразуются в ссылки.
  • Allowed HTML tags: <a> <em> <i> <img> <strong> <b> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Строки и параграфы переносятся автоматически.

Подробнее о форматировании

CAPTCHA
Введите перечисленные символы, чтобы мы убедились, что вы не робот. Не требуется для зарегистрированных пользователей.
c
f
y
5
s
v
Enter the code without spaces and pay attention to upper/lower case.