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 API Carbon был официально прекращен и удален, оставив 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 и программой с использованием различных структур данных, основанных на концепции вариантных записей Pascal .
Со временем на Mac появилось несколько объектных библиотек , в частности библиотека MacApp для Object Pascal и библиотека классов THINK C Think, а также более поздние версии MacApp и PowerPlant от CodeWarrior на языке C++ .
С покупкой NeXT в конце 1996 года Apple разработала новую стратегию операционной системы, основанную в основном на существующей платформе OPENSTEP for Mach . Новая стратегия Rhapsody OS была относительно простой; она сохранила большую часть существующих объектных библиотек 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 состоит из множества библиотек и функций, которые предлагают API, подобный Mac, но работающий поверх базовой 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 стал известен как «Carbonization». Официальная поддержка 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, необходимый для широко эквивалентного API Cocoa . [12]
Carbon совместим со всеми несколькими исполняемыми форматами, доступными для PowerPC Mac OS. Двоичная совместимость между Mac OS X и предыдущими версиями требует использования файла Preferred Executable Format , который Apple никогда не поддерживала в своей Xcode IDE .
Новые части Carbon, как правило, гораздо более объектно-ориентированы в своей концепции, большинство из них основаны на Core Foundation . Некоторые менеджеры, такие как HIView Manager (надмножество Control Manager), реализованы на C++ , но Carbon остается API на языке C.
Некоторые примеры углеродных менеджеров:
Первоначально диспетчер событий Mac Toolbox использовал модель опроса для проектирования приложений. Основной цикл событий приложения запрашивает диспетчер событий о событии с помощью GetNextEvent. Если в очереди есть событие, диспетчер событий возвращает его приложению, где оно обрабатывается, в противном случае он немедленно возвращается. Такое поведение называется « занятое ожидание », запуская цикл событий без необходимости. Занятое ожидание сокращает количество процессорного времени, доступного для других приложений, и снижает заряд батареи на ноутбуках. Классический диспетчер событий берет свое начало в оригинальной Mac OS 1984 года, когда любое запущенное приложение гарантировало, что оно будет единственным запущенным приложением, и где управление питанием не было проблемой.
С появлением MultiFinder и возможностью одновременного запуска нескольких приложений появился новый вызов Event Manager, WaitNextEvent , который позволяет приложению указывать интервал сна. Один простой трюк для устаревшего кода, позволяющий принять более эффективную модель без серьезных изменений в его исходном коде, — это просто установить параметр сна, переданный WaitNextEvent, на очень большое значение — в macOS это переводит поток в спящий режим, когда нечего делать, и возвращает событие только тогда, когда его нужно обработать. Таким образом, модель опроса быстро инвертируется, становясь эквивалентной модели обратного вызова, при этом приложение выполняет собственную диспетчеризацию событий исходным способом. Однако есть лазейки. Например, устаревший вызов панели инструментов ModalDialog вызывает старую функцию GetNextEvent внутренне, что приводит к опросу в тесном цикле без блокировки.
Carbon представляет заменяющую систему, называемую Carbon Event Manager. (Оригинальный Event Manager все еще существует для совместимости с устаревшими приложениями). Carbon Event Manager предоставляет цикл событий для разработчика (на основе Core Foundation CFRunLoopв текущей реализации); разработчик настраивает обработчики событий и вводит цикл событий в основную функцию, а затем ждет, пока Carbon Event Manager отправит события в приложение.
В классической Mac OS не было поддержки операционной системы для таймеров уровня приложения (более низкий уровень Time Manager был доступен, но он выполнял обратные вызовы таймера во время прерывания, во время которого вызовы не могли быть безопасно сделаны для большинства процедур Toolbox). Реализация таймеров обычно предоставлялась разработчикам приложений, и это обычно делалось путем подсчета прошедшего времени во время события простоя — то есть события, которое возвращалось WaitNextEvent , когда никакое другое событие не было доступно. Для того чтобы такие таймеры имели разумное разрешение, разработчики не могли позволить WaitNextEvent слишком долго задерживаться, и поэтому обычно устанавливались низкие параметры «сна». Это приводит к крайне неэффективному поведению планирования, поскольку поток не будет спать очень долго, вместо этого многократно просыпаясь, чтобы вернуть эти события простоя. Apple добавила поддержку таймера в Carbon, чтобы решить эту проблему — система может планировать таймеры с большой эффективностью.
GNUstep содержит реализацию API Carbon под названием Boron. Она нацелена на совместимость с не устаревшими частями ApplicationServices и CoreServices. Название происходит от того факта, что Boron стоит перед Carbon в периодической таблице элементов . [14] Darling также содержит реализацию Carbon. Обе реализации крайне неполны и состоят в основном из функций-заглушек.