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

В мы остановились на обещании рассказать про main() и be_app.

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

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

Невозможно рассказать об особенностях программирования в 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.

В интернете -

или, если вы уже поставили комплект разработчика BeOS - BeOS Development Tools - на вашем диске:

file:///boot/beos/documentation/Be%20Book/index.html

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

В принципе, 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.

В интернете -

или, если вы уже поставили комплект разработчика BeOS - BeOS Development Tools - на вашем диске:

file:///boot/beos/documentation/Be%20Book/index.html

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

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