Carbon был одним из двух основных интерфейсов прикладного программирования (API) на основе C, разработанных Apple для операционной системы macOS (ранее Mac OS X и OS X) . Carbon обеспечил хорошую степень обратной совместимости для программ , работавших в Mac OS 8 и 9 . Разработчики могли использовать API-интерфейсы Carbon для переноса («карбонизации») своих «классических» приложений и программного обеспечения Mac на платформу Mac OS X без особых усилий по сравнению с портированием приложения на совершенно другую систему Cocoa , которая возникла в OPENSTEP . С выпуском macOS 10.15 Catalina поддержка Carbon API была официально прекращена и удалена, в результате чего Cocoa остался единственным основным API для разработки приложений macOS.
Carbon был важной частью стратегии Apple по выводу Mac OS X на рынок, предлагая путь для быстрого портирования существующих программных приложений, а также средство доставки приложений, которые будут работать как на Mac OS X, так и на классической Mac OS. Поскольку рынок все больше перешел на фреймворки на основе Cocoa, особенно после выпуска iOS , потребность в библиотеке портирования снизилась. Apple не создала 64-битную версию Carbon при обновлении других своих платформ в период 2007 года и в конечном итоге объявила устаревшим весь API в OS X 10.8 Mountain Lion , выпущенной 24 июля 2012 года.
Исходная Mac OS использовала Pascal в качестве основной платформы разработки, а API-интерфейсы в значительной степени основывались на семантике вызовов Pascal . Большая часть Macintosh Toolbox состояла из вызовов процедур , передающих информацию туда и обратно между API и программой с использованием различных структур данных, основанных на концепции вариантной записи Паскаля .
Со временем на Mac появился ряд объектных библиотек , в частности библиотека Object Pascal MacApp и библиотека классов THINK C Think, а также более поздние версии MacApp и PowerPlant от CodeWarrior на C++ .
С покупкой NeXT в конце 1996 года Apple разработала новую стратегию операционной системы, основанную в основном на существующей платформе OPENSTEP for Mach . Новая «Рапсодия» была относительно простой; он сохранил большую часть существующих объектных библиотек OpenStep под названием «Yellow Box», перенес существующий графический интерфейс в OPENSTEP для Mach и сделал его более похожим на Mac, перенес несколько основных API из Mac OS в базовую Unix-подобную систему Rhapsody (особенно QuickTime и AppleSearch ), а также добавил эмулятор, известный как «Blue Box», который запускал существующее программное обеспечение Mac OS.
Когда этот план был обнародован на Всемирной конференции разработчиков в 1997 году, это вызвало некоторое сопротивление со стороны существующих разработчиков Mac OS, которые были расстроены тем, что их кодовые базы фактически будут заблокированы в эмуляторе, который вряд ли когда-либо будет обновляться. Голубой ящик стали называть «штрафником». [ нужна цитата ] Крупные разработчики, такие как Microsoft и Adobe, категорически отказались рассматривать возможность переноса на OpenStep, который настолько отличался от существующей Mac OS, что совместимость была минимальной или отсутствовала вообще.
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 с эмулятором, в новой системе OpenStep и Carbon API будут, где это возможно, использовать общий код. Для этого многие полезные фрагменты кода нижних уровней системы OpenStep, написанные на Objective-C и известные как Foundation, были повторно реализованы на чистом C. Этот код стал известен как Core Foundation , или CF для короткий. Версия Yellow Box, портированная для вызова CF, стала новым Cocoa API, а вызовы Carbon в стиле Mac также вызывали те же функции. В рамках новой системы Carbon и Cocoa были равными. Обычно это преобразование замедляло бы производительность Cocoa, поскольку методы объекта вызывали базовые библиотеки C, но Apple использовала метод, который они назвали бесплатным мостом, чтобы уменьшить это влияние. [1]
В рамках этого преобразования Apple также перенесла графический движок с обремененного лицензией Display PostScript на безлицензионный Quartz (который получил название «Display PDF»). [2] Quartz предоставил собственные вызовы, которые можно было использовать как из Carbon, так и из Cocoa, а также предложил интерфейсы, подобные Java 2D . Сама базовая операционная система была дополнительно изолирована и выпущена как 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] и Final Cut Pro (а также функции движка QuickTime , лежащие в его основе [9] ), оставались написанными на Carbon в течение многих лет. И iTunes, и Final Cut Pro X с тех пор были выпущены в версиях 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.
В качестве общего термина , охватывающего все процедуры API на языке C, обеспечивающие доступ к специфичным для Mac функциям, Carbon не спроектирован как отдельная система. Скорее, он открывает почти все функциональные возможности macOS для разработчиков, которые не знают языка Objective-C, необходимого для широко эквивалентного Cocoa API . [12]
Carbon совместим со всеми несколькими исполняемыми форматами, доступными для PowerPC Mac OS. Двоичная совместимость между Mac OS X и предыдущими версиями требует использования файла предпочтительного исполняемого формата , который Apple никогда не поддерживала в своей среде разработки Xcode .
Новые части Carbon имеют тенденцию быть гораздо более объектно-ориентированными по своей концепции, большинство из них основаны на Core Foundation . Некоторые менеджеры, такие как HIView Manager (расширенный вариант Control Manager), реализованы на C++ , но Carbon остается API C.
Некоторые примеры менеджеров по выбросам углерода:
Менеджер событий Mac Toolbox изначально использовал модель опроса для разработки приложений. Основной цикл событий приложения запрашивает у диспетчера событий событие с помощью GetNextEvent. Если в очереди есть событие, диспетчер событий передает его обратно в приложение, где оно обрабатывается, в противном случае он возвращается немедленно. Такое поведение называется « ожиданием занятости », при котором цикл событий запускается без необходимости. Ожидание занятости уменьшает количество процессорного времени, доступного для других приложений, и снижает заряд батареи на ноутбуках. Классический диспетчер событий появился в оригинальной Mac OS в 1984 году, когда любое запущенное приложение гарантированно было единственным работающим приложением и когда управление питанием не было проблемой.
С появлением MultiFinder и возможностью одновременного запуска нескольких приложений появился новый вызов диспетчера событий WaitNextEvent , который позволяет приложению указывать интервал ожидания. Один простой способ использовать устаревший код для принятия более эффективной модели без серьезных изменений в его исходном коде — просто установить для параметра сна, передаваемого в WaitNextEvent , очень большое значение — в macOS это переводит поток в спящий режим всякий раз, когда нечего делать. и возвращает событие только в том случае, если есть событие, требующее обработки. Таким образом, модель опроса быстро инвертируется и становится эквивалентной модели обратного вызова, при этом приложение выполняет собственную диспетчеризацию событий оригинальным способом. Однако есть лазейки. Например, вызов ModalDialog из устаревшего набора инструментов внутренне вызывает более старую функцию GetNextEvent , что приводит к опросу в узком цикле без блокировки.
Carbon представляет систему замены, называемую Carbon Event Manager. (Исходный менеджер событий все еще существует для совместимости с устаревшими приложениями). Carbon Event Manager предоставляет разработчику цикл событий (на основе Core Foundation CFRunLoopв текущей реализации); разработчик настраивает обработчики событий, входит в цикл событий в основной функции и ждет, пока Carbon Event Manager отправит события в приложение.
В классической Mac OS не было поддержки операционной системой таймеров уровня приложения (диспетчер времени нижнего уровня был доступен, но он выполнял обратные вызовы таймера во время прерывания, во время которого нельзя было безопасно выполнять вызовы большинства подпрограмм Toolbox). Реализация таймеров обычно оставлялась на усмотрение разработчиков приложений, и обычно это делалось путем подсчета времени, прошедшего во время события простоя , то есть события, которое возвращалось функцией WaitNextEvent , когда какое-либо другое событие было недоступно. Чтобы такие таймеры имели разумное разрешение, разработчики не могли позволить WaitNextEvent слишком долго задерживать, поэтому обычно устанавливались низкие параметры «сна». Это приводит к крайне неэффективному планированию, поскольку поток не будет спать очень долго, а вместо этого неоднократно просыпается, чтобы вернуть эти события простоя. Чтобы решить эту проблему, Apple добавила в Carbon поддержку таймеров — система может планировать таймеры с большой эффективностью.
GNUstep содержит реализацию Carbon API под названием Boron. Он стремится быть совместимым с неустаревшими частями ApplicationServices и CoreServices. Название происходит от того факта, что бор стоит перед углеродом в периодической таблице элементов . [14] Darling также содержит реализацию Carbon. Обе реализации крайне неполны и состоят в основном из функций-заглушек.