Mac OS X "Леопард" - 64-битная операционная система. Умеющая работать с 32-битными программами и технологиями, но - 64-битная на всех важнейших направлениях. Некоторые технологии остаются 32-битными, что, наверное, должно означать их не очень высокий статус. 32-битность отныне - своего рода "черная метка". Тонкий намек.

Среди получивших "черную метку" оказался... Carbon.

Что такое Carbon, насколько серьезна угроза, и... как это скажется на будущем Мака, разработчиков и пользователей? Попробуем разобраться - а для этого начнем свои рассуждения издалека.

"API, или "Легко ли опираться на два фундамента сразу?"

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

Такой "фундамент" называется API (программный интерфейс для разработчика). В подавляющем большинстве операционных систем такой фундамент только один. Качество "фундамента" исключительно важно, на его поддержку и развитие не жалеют ни времени, ни денег. Занимаются им "штучные" программисты, которых в мире - жесточайший дефицит. В Windows XP такой фундамент только один. В Windows Vista - тоже. И в классической Mac OS...

А вот в Mac OS X таких "фундаментов"... два. Уникально! Здорово! Впереди планеты всей! Целых два... Я бы с удовольствием порадовался этому факту, если бы было чему радоваться. Это - недостаток. Более того: есть в Mac OS X несколько групп API, в которых эти два фундамента фактически дублируют друг друга. Без какой-либо пользы.

Термином "Carbon" в Mac OS X несколько злоупотребляют. За без малого десять лет, в течении которых Cocoa (современный наследник NeXTstep/OPENSTEP) и Carbon существуют бок о бок, компания проделала огромную работу по превращению разнородных технологий в сплав, значительно превосходящий любой из входящих в него компонентов набором полезных свойств.

В Mac OS X существуют и другие API, например, Darwin OS (сертифицированная юникс-подобная операционная система с открытым исходным кодом), прозрачно доступный из любой программы (будь это Carbon-программа или Cocoa-программа), и ценный сам по себе. Например, как среда разработки. Как инструментарий для переноса программного обеспечения из различных юниксов и юникс-подобных операционных систем.

Сложилась своеобразная многоуровневая архитектура. Собственно, это уже не Cocoa+Carbon+Darwin+..., а нечто принципиально новое. Факты? Пожалуйста:

"Сплав в действии"

Графика... Проще всего (и быстрее) работать с графикой (рисовать, преобразовывать, анализировать, и т.п) с помощью подмножества графических API, адаптированных (и значительно упрощенных) в Cocoa. Имеющихся в Cocoa графических API вполне достаточно для большинства жизненных случаев. Даже для профессиональных графических программ.

Если требуется большее, используются библиотеки Core Graphics (Quartz), в которых определены все те же операции (плюс многие-многие еще), только более детально и подробно. Формально, Core Graphics относится к библиотекам Carbon. В любом Cocoa-проекте, при необходимости, можно запрограммировать все действия над графикой целиком с помощью Cocoa. По мере необходимости, можно "утончить" некоторые из них с помощью нескольких функций из Core Graphics, или полностью удовлетворить графические потребности программы исключительно средствами Core Graphics.

В некоторых "провинциях" Mac OS X задействованы все три этажа.

Например, Bonjour (бывш. Rendezvous). Это межплатформенная реализация ZeroConf, разработанная на Apple, Inc.

В Cocoa, с помощью классов NSNetService и NSNetServerBrowser, можно разрабатывать сложные и продвинутые "сервисы" Bonjour.

С помощью группы API "CFNetServices", формально входящей в Carbon, в любом, в Cocoa- или Carbon- проекте можно опуститься до деталей значительно меньшего масштаба.

Третий уровень вниз - юникс. На этом уровне в подробностях и деталях легко заблудиться, зато практически любой мыслимый и немыслимый поведенческий аспект разрабатываемой программы оказывается под контролем. На самом нижнем уровне услугами Bonjour можно воспользоваться с помощью DNSServiceDiscovery API, целого набора функций и структур данных, формально являющихся частью Darwin OS.

Автор когда-то (лет 5-6 назад), закончил одну из статей про Cocoa и Carbon мечтой о том времени, когда они сольются во что-то новое и мощное, и все это станет называться Diamond. Мечта фактически уже исполнилась,. Автор не угадал только название. Это не Diamond. Это Mac OS X.

"Зона конфликта"

Начиная новый проект, Мак-разработчик (в зависимости от симпатий, особенностей стоящей перед ним задачи, воли руководства - и т.п.) имеет возможность выбрать между Cocoa-проектом и Carbon-проектом. В результате этого выбора, результатом разработки проекта становится либо Cocoa-, либо Carbon-приложение.

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

Межплатформенные программы почти все - Carbon-программы. Все программы и утилиты, входящие в MS Office, все звездные программы Adobe, собственная iTunes самой Apple...

И не только межплатформенные: вплоть до "Тигра" интерфейсная компонента самой операционной системы, многострадальный Finder - тоже Carbon-программа. Только в Леопарде будет новый Finder, на этот раз написанный в Cocoa (используя библиотеки Carbon).

О том, что такое Carbon "по сути", как он возник и развивался, мы еще поговорим. Пока достаточно отметить только то, что Carbon - результат глубокой модернизации и массированной доработки классической Mac OS. Наследник классической Mac OS. Поскольку "классика" была одной из наиболее продвинутых ОС в мире по части графического пользовательского интерфейса (ГПИ), значительную часть ее API составляли средства организации этих самых интерфейсов и управления ими.

На первых порах существования Carbon организация интерфейсов и управления выполнялась с помощью практически того же самого набора рутин и структур данных, что и в Mac OS 8 и 9. Благодаря этому, переносить программы из классики в бурный и непредсказуемый мир "современной ОС" было немного проще. Но на Carbon были "посажены" слишком талантливые инженеры ("штучные"), с неуемной фантазией и невероятной продуктивностью.

Они разработали совершенно новую (и очень обширную) область API для Carbon, основанную на HIObject и HIView, написали неплохие учебники и выложили в сети сотни примеров использования разработанной ими системы интерфейсных элементов. Эти элементы, и их комплексы, практически несовместимы с такими же элементами и комплексами Cocoa. Они развиваются параллельно. Это два огромных массива кода, каждый из которых надо поддерживать.

Не в последнюю очередь благодаря этим API, популярность Carbon в качестве среды для разработки Carbon-приложений остается высокой, а "священные войны" между сторонниками Carbon и Cocoa все еще продолжаются. Логичная многоуровневая архитектура, в которой легко узнается если не Стив Джобс сам по себе, то как минимум его увлеченное влияние - в этом месте дает сбой...

Это и есть "зона конфликта".

"Предназначение Carbon"

В разные исторические эпохи оно было различно. В 1998-2003 Carbon играл роль своеобразного мостика между старой и новой системами. Если бы не этот мостик, успех Mac OS X был бы почти нереален.

Переселение из "классики" в Mac OS X было массовым и болезненным. Году к 2003 (Mac OS 10.2) оно практичсеки завершилось - и Carbon стал примерно тем, чем он является сейчас. Многочисленные библиотеки, исторически относящиеся к Carbon (едва ли не большая их часть никогда не была в составе "классики"), стали очень ценным и важным компонентом операционной системы. Кроме того, Carbon превратился в один из двух "фундаментов" для создания прикладных программ с совершенно разной инфраструктурой.

Как известно из химии, Carbon (=углерод) существует в природе в одной из двух форм. Либо это уголь (графит), либо - алмаз. Carbon в Mac OS X тоже существует в двух формах: как в форме "алмаза" (API применимые в программах любого типа), так и в форме "угля" - в форме дублирующих и конкурирующих наборов API.

Все время, пока на свете существует Mac OS X, Apple не перестает убеждать разработчиков работать и жить именно в Cocoa. В воображении рисуется пирамидка - в основании которой юникс, чуть выше - библиотеки на С и С++ (алмазный фонд "Большого Карбона"), на вершине - Cocoa. Вот он, замысел. Физический отец Стива Джобса - египтянин (или сириец - источники расходятся по этому вопросу, большинство отстаивает "египетскую" версию), и возведение пирамид у них в крови.

Часть разработчиков (примерно треть, в том числе и на самой Apple) упорно предпочитает использовать Carbon в качестве "фундамента" для своих программ. Доводы приводятся самые разные. Мы уже упоминали "межплатформенные программы". На самом деле, на этот довод есть контрдовод, о котором мы поговорим в одной из следующих частей этой статьи.

Продолжение следует...