Carbon — один из двух основных C-ориентированных интерфейсов программирования приложений (API), разработанных Apple для операционной системы Mac OS X. Carbon обеспечивал хорошую степень обратной совместимости для программ, написанных для Mac OS 8 и 9. Разработчики могли использовать Carbon API для портирования («карбонизации») своих «классических» Mac-приложений на платформу Mac OS X с небольшими затратами, по сравнению с переписыванием приложения на совершенно иной API Cocoa, который возник в OpenStep. С выпуском обновления 10.15 (Catalina) для Macintosh, Carbon API был официально удален, оставив Cocoa единственным основным API для разработки современных Mac-приложений.

Carbon был важной частью стратегии Apple по выводу Mac OS X на рынок, предлагая путь для быстрого портирования существующих программ, которые могли бы работать как на Mac OS X, так и на классической Mac OS. По мере перевода кода на фреймворки на основе Cocoa, особенно после выпуска iOS, потребность в Carbon уменьшилась. Apple не стала делать 64-битную версию Carbon при обновлении своих других фреймворков в 2007 году и в конечном итоге весь API к OS X 10.8 Mountain Lion, который был выпущен 24 июля 2012 года, устарел.

Оригинальная Mac OS использовала Pascal в качестве основной платформы разработки, и API были сильно основаны на семантике вызова Pascal. Большая часть Macintosh Toolbox^[англ.] состояла из вызовов процедур, передающих информацию между API и программой с использованием различных структур данных, основанных на концепции вариантной записи Pascal.

Со временем на Mac развился ряд библиотек объектов, в частности библиотека Object Pascal MacApp и Think Class Library THINK C, а затем версии MacApp и PowerPlant CodeWarrior на C++.

С покупкой NeXT в конце 1996 года Apple разработала новую стратегию операционной системы, основанную в значительной степени на существующей платформе OPENSTEP for Mach. Новая стратегия ОС Rhapsody была относительно простой; она сохранила большинство существующих библиотек объектов OpenStep под названием «Yellow Box», портировала существующий GUI в OPENSTEP for Mach и сделала его более похожим на Mac, портировала несколько основных API из Mac OS в базовую Unix-подобную систему Rhapsody (в частности, QuickTime и AppleSearch) и добавила эмулятор, известный как «Blue Box», который запускал существующее программное обеспечение Mac OS.

Когда этот план был раскрыт на Всемирной конференции разработчиков (WWDC) в 1997 году, возникло некоторое сопротивление со стороны существующих разработчиков Mac OS, которые были расстроены тем, что их кодовые базы будут фактически заблокированы в эмуляторе, который вряд ли когда-либо будет обновлен. Они стали называть Blue Box «тюремной коробкой». Более крупные разработчики, такие как Microsoft и Adobe, категорически отказались рассматривать портирование на OpenStep, который настолько отличался от существующей Mac OS, что совместимость была минимальной или отсутствовала вовсе.

Apple приняла эти опасения близко к сердцу. Когда Стив Джобс объявил об изменении направления Apple на следующей WWDC в 1998 году, он заявил, что «то, что действительно хотели разработчики, это современная версия Mac OS, и Apple собиралась ее предоставить».

Первоначальная концепция Rhapsody, с только Blue Box для запуска существующего программного обеспечения Mac OS, в конечном итоге была выпущена в 1999 году как Mac OS X Server 1.0. Это был единственный выпуск, основанный на первоначальной концепции Rhapsody.

Чтобы предложить реальный и хорошо поддерживаемый путь обновления для существующих кодовых баз Mac OS, Apple представила систему Carbon. Carbon состоит из множества библиотек и функций, которые предлагают Mac-подобный API, но работают поверх базовой Unix-подобной ОС, а не копии Mac OS, работающей в эмуляции. Библиотеки Carbon были тщательно очищены, модернизированы и лучше «защищены». В то время как Mac OS была наполнена API, которые использовали общую память для передачи данных, в Carbon весь такой доступ был переработан с использованием методов доступа подпрограмм для непрозрачных типов данных. Это позволило Carbon поддерживать настоящую многозадачность и защиту памяти, функции, которые разработчики Mac запрашивали в течение десятилетия. Другие изменения в существующем API удалили функции, которые были концептуально несовместимы с Mac OS X или просто устарели. Например, приложения больше не могли устанавливать обработчики прерываний или драйверы устройств.

Для поддержки Carbon вся модель Rhapsody изменилась. В то время как Rhapsody фактически была бы OpenStep с эмулятором, в новой системе API OpenStep и Carbon, где это возможно, использовали бы общий код. Для этого многие полезные части кода из нижних уровней системы OpenStep, написанные на Objective-C и известные как Foundation, были переработаны на чистом C. Этот код стал известен как Core Foundation, или CF. Версия Yellow Box, портированная для вызова CF, стала новым API Cocoa, и Mac-подобные вызовы Carbon также вызывали те же функции. В новой системе Carbon и Cocoa были равными. Это преобразование обычно замедляло бы производительность Cocoa, поскольку объектные методы вызывали базовые библиотеки C, но Apple использовала технику, которую они назвали «бесплатным мостом», чтобы уменьшить это влияние.^[1]

В рамках этого преобразования Apple с нуля написала новый оконный сервер и графический движок для замены лицензионно обремененного Display PostScript: Quartz (который был назван «Display PDF»).^[2] Quartz предоставлял вызовы C API, которые могли использоваться как из Carbon, так и из Cocoa. Сама базовая операционная система была дополнительно изолирована и выпущена как Darwin.

Carbon был представлен в неполной форме в 2000 году как общая библиотека, обратно совместимая с Mac OS 8.1 1997 года. Эта версия позволила разработчикам портировать свой код на Carbon, не теряя возможности запускать эти программы на существующих машинах Mac OS. Портирование на Carbon стало известно как «карбонизация». Официальная поддержка Mac OS X появилась в 2001 году с выпуском Mac OS X v10.0, первой публичной версии новой ОС. Carbon очень широко использовался в ранних версиях Mac OS X почти всеми крупными компаниями-разработчиками программного обеспечения, даже Apple. Например, Finder оставался приложением Carbon в течение многих лет, будучи портированным на Cocoa только с выпуском Mac OS X 10.6 в 2009 году.^[3]

Переход на 64-битные приложения Macintosh, начавшийся с Mac OS X v10.5, выпущенной 26 октября 2007 года, принес первые серьезные ограничения для Carbon. Apple не обеспечивает совместимость между графическим пользовательским интерфейсом Macintosh и языком программирования C в 64-битной среде, вместо этого требуя использования диалекта Objective-C с API Cocoa.^[4] Многие комментаторы восприняли это как первый признак возможного исчезновения Carbon, позиция, которая была усилена, когда Apple заявила, что никаких новых крупных дополнений к системе Carbon не будет добавлено,^[5][6] и далее подкреплена ее устареванием в 2012 году.

Несмотря на предполагаемые преимущества Cocoa, необходимость переписывать большие объемы устаревшего кода замедлила переход приложений на базе Carbon, что особенно заметно на примере Adobe Photoshop,^[7] который в конечном итоге был обновлен до Cocoa в апреле 2010 года. Это также распространилось на собственные флагманские программные пакеты Apple, поскольку iTunes,^[8] приложение Finder и Final Cut Pro (а также функции движка QuickTime, который его поддерживает^[9]) оставались написанными на Carbon в течение многих лет. iTunes, Finder и Final Cut Pro с тех пор были выпущены в версиях Cocoa.

В 2012 году, с выпуском OS X 10.8 Mountain Lion, большинство API Carbon были признаны устаревшими. API по-прежнему были доступны разработчикам, и все приложения Carbon по-прежнему работали, но API больше не будут обновляться. 28 июня 2017 года Apple объявила, что 32-битное программное обеспечение для macOS, такое как все приложения Carbon, больше не будет поддерживаться «без компромиссов» в версиях macOS после macOS 10.13 High Sierra.^[10] macOS 10.15 Catalina официально прекратила поддержку 32-битных приложений, включая все приложения Carbon.^[11]

Carbon происходит от Toolbox и, как таковой, состоит из «Менеджеров». Каждый Менеджер — это функционально связанный API, определяющий наборы структур данных и функций для их манипулирования. Менеджеры часто взаимозависимы или многослойны. Carbon состоит из широкого набора функций для управления файлами, памятью, данными, пользовательским интерфейсом и другими системными службами. Он реализован как любой другой API: в macOS он распределен по нескольким фреймворкам (каждый из которых представляет собой структуру, построенную вокруг общей библиотеки), в основном Carbon.framework, ApplicationServices.framework и CoreServices.framework, а в классической Mac OS он находится в одной общей библиотеке под названием CarbonLib.

Carbon — это не коробка совместимости; это нативный API для Mac OS X. Он находится примерно рядом с Cocoa на архитектурной диаграмме. Приложения Carbon могут использовать всю нативную функциональность Mac OS X, и вы можете смешивать окна Carbon и Cocoa в одном процессе.

Carbon совместим со всеми несколькими исполняемыми форматами, доступными для PowerPC Mac OS. Двоичная совместимость между Mac OS X и предыдущими версиями требует использования файла Preferred Executable Format, который Apple никогда не поддерживала в своей Xcode IDE.

Новые части Carbon, как правило, гораздо более объектно-ориентированы в своей концепции, большинство из них основаны на Core Foundation. Некоторые Менеджеры, такие как HIView Manager (надмножество Control Manager), реализованы на C++, но Carbon остается C API.

Некоторые примеры Менеджеров Carbon:

• File Manager — управляет доступом к файловой системе, открытием, закрытием, чтением и записью файлов.
• Resource Manager — управляет доступом к фрагментам данных в ресурсной ветви файла. Примеры ресурсов включают значки, звуки, изображения, шаблоны для виджетов и т. д.
• Font Manager — управляет шрифтами. Устарел (как часть QuickDraw) с Mac OS X v10.4, заменён Apple Type Services (ATS).
• QuickDraw — примитивы 2D-графики. Устарел с Mac OS X v10.4, заменён Quartz 2D.
• Carbon Event Manager  — преобразует действия пользователя и системы в события, на которые код может реагировать.
• HIObject — совершенно новый объектно-ориентированный API, который привносит в Carbon ОО модель для построения графических интерфейсов. Он доступен в Mac OS X v10.2 или более поздних версиях и предоставляет программистам Carbon более мощный API для работы. Начиная с Mac OS X v10.2, HIObject является базовым классом для всех элементов графического интерфейса в Carbon. HIView поддерживается Interface Builder, частью инструментов разработчика Apple. Традиционно архитектуры графического интерфейса такого рода предоставлялись сторонними фреймворками приложений. Начиная с Mac OS X v10.4, HIObjects являются NSObject и наследуют возможность сериализации в потоки данных для передачи или сохранения на диск.
• HITheme — использует QuickDraw и Quartz для рендеринга элементов графического пользовательского интерфейса (GUI) на экране. HITheme был представлен в Mac OS X v10.3, а Appearance Manager является уровнем совместимости поверх HITheme с этой версии.
• HIView Manager — управляет созданием, отрисовкой, проверкой попадания и манипулированием элементами управления. С Mac OS X v10.2 все элементы управления являются HIViews. В Mac OS X v10.4 Control Manager был переименован в HIView Manager.
• Window Manager — управляет созданием, позиционированием, обновлением и манипулированием окнами. С Mac OS X v10.2 окна имеют корневой HIView.
• Menu Manager — управляет созданием, выбором и манипулированием меню. С Mac OS X v10.2 меню являются HIObjects. С Mac OS X v10.3 содержимое меню может быть отрисовано с использованием HIViews, и все стандартные меню используют HIViews для отрисовки.

Менеджер событий Mac Toolbox изначально использовал модель опроса для проектирования приложений. Главный цикл событий приложения запрашивает у Менеджера событий событие с помощью GetNextEvent. Если в очереди есть событие, Менеджер событий передает его обратно приложению, где оно обрабатывается, в противном случае он немедленно возвращается. Такое поведение называется «активным ожиданием», когда цикл событий выполняется без необходимости. Активное ожидание сокращает количество процессорного времени, доступного для других приложений, и уменьшает заряд батареи на ноутбуках. Классический Менеджер событий датируется оригинальной Mac OS 1984 года, когда любое запущенное приложение гарантированно было единственным запущенным приложением, и когда управление питанием не было проблемой.

С появлением MultiFinder и возможностью запускать более одного приложения одновременно появился новый вызов Менеджера событий, WaitNextEvent, который позволяет приложению указывать интервал сна. Один простой трюк для устаревшего кода, чтобы принять более эффективную модель без серьезных изменений в его исходном коде, состоит в том, чтобы просто установить параметр сна, передаваемый WaitNextEvent, на очень большое значение — в macOS это переводит поток в спящий режим всякий раз, когда нечего делать, и возвращает событие только тогда, когда есть что обрабатывать. Таким образом, модель опроса быстро инвертируется, чтобы стать эквивалентной модели обратного вызова, при этом приложение выполняет собственную диспетчеризацию событий обычным способом. Однако есть лазейки. Например, устаревший вызов Toolbox ModalDialog внутренне вызывает старую функцию GetNextEvent, что приводит к опросу в жестком цикле без блокировки.

Carbon представляет заменяющую систему, называемую Carbon Event Manager. (Оригинальный Event Manager все еще существует для совместимости с устаревшими приложениями). Carbon Event Manager предоставляет цикл событий для разработчика (на основе CFRunLoop Core Foundation в текущей реализации); разработчик настраивает обработчики событий и входит в цикл событий в основной функции, и ждет, пока Carbon Event Manager отправит события приложению.

В классической Mac OS не было поддержки таймеров операционной системой на уровне приложений (менеджер времени более низкого уровня был доступен, но он выполнял обратные вызовы таймера во время прерывания, во время которого вызовы не могли быть безопасно сделаны для большинства процедур Toolbox). Таймеры обычно оставлялись разработчикам приложений для реализации, и это обычно делалось путем подсчета прошедшего времени во время события idle — то есть события, которое возвращалось WaitNextEvent, когда любое другое событие было недоступно. Чтобы такие таймеры имели разумное разрешение, разработчики не могли позволить WaitNextEvent задерживаться слишком долго, и поэтому обычно устанавливался короткий «сон». Это приводит к крайне неэффективному планированию, поскольку поток не спал долго, постоянно просыпаясь. Apple добавила поддержку таймеров в Carbon для решения этой проблемы — система может планировать таймеры с большой эффективностью.

GNUstep содержит реализацию Carbon API под названием Boron. Название происходит от бора, который предшествует углероду в периодической таблице элементов.^[12] Darling также содержит реализацию Carbon. Обе реализации крайне неполны и состоят в основном из заглушек функций.

• Cocoa
• Interface Builder
• Objective-C
• Xcode

• Архивировано 20 апреля 2009 года.