Войти
| Разработчик (и) | Apple Inc. |
|---|---|
| Операционная система | Классическая Mac OS, macOS |
| Лицензия | Собственная |
| Веб-сайт | http://developer.apple.com/referencelibrary/Carbon/ на Wayback Machine (архивировано 20 апреля 2009 г.) |
Carbon является одним из интерфейсов прикладного программирования Apple на основе C . (API) для macOS (ранее Mac OS X), операционной системы, на которой работают компьютеры Macintosh. Carbon обеспечил хорошую степень обратной совместимости для программ, работающих на Mac OS 8 и 9. Разработчики могли использовать API-интерфейсы Carbon для переноса своего «классического» программного обеспечения Mac на платформу Mac OS X с небольшими усилиями по сравнению с переносом приложения на совершенно другой Cocoa, которая возникла в OPENSTEP.
Carbon, была важной частью стратегии Apple по выводу Mac OS X на рынок, предлагая путь для быстрого переноса существующих программных приложений, а также средства доставки приложений, которые будет работать либо на Mac OS X, либо на классической Mac OS. По мере того как рынок все больше переходит на платформы на основе Какао, особенно после выпуска iOS, потребность в библиотеке для переноса уменьшилась. Apple не создавала 64-битную версию Carbon при обновлении других своих фреймворков в период 2007 года, и в конечном итоге исключила весь API в OS X 10.8 Mountain Lion., который был выпущен 24 июля 2012 года. Carbon был официально прекращен и полностью удален с выпуском macOS 10.15 Catalina.
«Карбонизированное» приложение Adobe Systems ImageReady v.7.0, работающее непосредственно на Mac OS X версия 10.2 В исходной Mac OS использовалась Pascal в качестве основной платформы разработки, а также API в значительной степени основывались на семантике вызова Паскаля. Большая часть Macintosh Toolbox состояла из вызовов процедур, передавая информацию туда и обратно между API и программой с использованием различных структур данных на основе Паскаля. вариант записи понятие.
Со временем на Mac появился ряд библиотек объектов, в частности, Object Pascal library MacApp и Think Class. Библиотека (TCL) в Pascal и более поздних версиях MacApp и CodeWarrior PowerPlant в C ++. К середине 1990-х годов большая часть программного обеспечения Mac была написана на C ++ с использованием CodeWarrior.
С приобретением NeXT в конце 1996 года Apple разработала новую стратегию операционной системы, основанную в основном на существующей платформе OpenStep. Новая Rhapsody была относительно простой; он сохранил большую часть существующих библиотек объектов OpenStep под названием «Yellow Box», перенес существующий GUI OpenStep и сделал его более похожим на 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 состоит из множества библиотек и функций, которые предлагают API-интерфейс, подобный Mac, но работающий поверх базовой Unix-подобной ОС, а не копии Mac OS, работающей в режиме эмуляции. Библиотеки Carbon тщательно очищены, модернизированы и лучше "защищены". В то время как Mac OS была наполнена API-интерфейсами, разделяющими память для передачи данных, в Carbon весь такой доступ был повторно реализован с использованием подпрограмм accessor для непрозрачных типов данных. Это позволило Carbon поддерживать настоящую многозадачность и защиту памяти, функции, которые разработчики Mac запрашивали уже десять лет. Другие изменения из ранее существовавшего API удалили функции, которые были концептуально несовместимы с Mac OS X или просто устарели. Например, приложения больше не могли устанавливать обработчики прерываний или драйверы устройств.
. Для поддержки Carbon вся модель Rhapsody изменилась. В то время как Rhapsody будет фактически OpenStep с эмулятором, в новой системе и OpenStep, и Carbon API будут по возможности совместно использовать общий код. Для этого многие полезные фрагменты кода нижних уровней системы OpenStep, написанные на Objective-C и известные как Foundation, были повторно реализованы на чистом C. Этот код стал известен как Core Foundation, или сокращенно CF. Версия Yellow Box, перенесенная для вызова CF, стала новым API Cocoa, а вызовы Carbon, подобные Mac, также вызывали те же функции. В рамках новой системы Carbon и Cocoa были равными. Это преобразование обычно замедляло бы производительность Какао как методов объекта, вызываемых в базовые библиотеки C, но Apple использовала метод, который они назвали бесплатным мостом, чтобы уменьшить это влияние.
Как В рамках этого преобразования Apple также перенесла графический движок с обремененного лицензией Display PostScript на безлицензионный Quartz (который получил название «Display PDF "). Quartz предоставлял собственные вызовы, которые можно было использовать как из Carbon, так и из Какао, а также предлагал Java 2D -подобные интерфейсы. Сама базовая операционная система была дополнительно изолирована и выпущена как Darwin.
Carbon была представлена в неполной форме в 2000 году как разделяемая библиотека, обратно совместимая с Mac OS 8.1 1997 года. Эта версия позволяла разработчикам переносить свой код на Carbon, не теряя возможности запуска этих программ на существующих компьютерах Mac OS. Переход на углерод стал известен как «карбонизация». Официальная поддержка Mac OS X появилась в 2001 году с выпуском Mac OS X v10.0, первой общедоступной версии новой ОС. Углерод очень широко использовался в ранних версиях Mac OS X почти всеми основными разработчиками программного обеспечения, даже Apple. Finder, например, оставался приложением Carbon в течение многих лет, и был перенесен на Cocoa только с выпуском Mac OS X 10.6 в 2009 году.
Переход на 64- bit Приложения Macintosh, начиная с Mac OS X v10.5, выпущенной 26 октября 2007 г., принесли первые серьезные ограничения для Carbon. Apple не обеспечивает совместимость между графическим пользовательским интерфейсом Macintosh и языком программирования C в 64-битной среде, вместо этого требуя использования диалекта Objective-C с Cocoa API. Многие комментаторы считали это первым признаком возможного исчезновения Carbon, позиция, которая была усилена, когда Apple заявила, что никаких новых крупных дополнений не будет добавлено в систему Carbon, и еще больше усилилась с ее прекращением поддержки в 2012 году.
Несмотря на предполагаемые преимущества Какао, необходимость переписать большие объемы устаревшего кода замедлила переход приложений на основе углерода, в частности, с Adobe Photoshop, который в конечном итоге был обновлен в Cocoa в апреле 2010 года. Это также распространилось на собственные флагманские программные пакеты Apple, такие как iTunes и Final Cut Pro (а также функции механизма QuickTime которая его поддерживает) оставалась написанной на углероде в течение многих лет. И 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. macOS 10.15 Catalina официально удалила поддержку 32-битных приложений, включая все приложения Carbon.
Carbon происходит от Toolbox и как таковой является в составе «менеджеров». Каждый менеджер представляет собой функционально связанный API, определяющий наборы структур данных и функций для управления ими. Менеджеры часто взаимозависимы или многоуровневые. Углерод состоит из широкого набора функций для управления файлами, памятью, данными, пользовательским интерфейсом и другими системными службами. Он реализован, как и любой другой API: в macOS он распределен по нескольким фреймворкам (каждая представляет собой структуру, построенную вокруг общей библиотеки ), в основном Carbon.framework, ApplicationServices. frameworkи CoreServices.framework, а в классической Mac OS он находится в единой разделяемой библиотеке с именем CarbonLib.
в качестве зонтичного термина Углерод, охватывающий все процедуры API-интерфейса на языке C, обеспечивающие доступ к специфическим для Mac функциям, не задумывался как отдельная система. Скорее, он открывает почти все функциональные возможности macOS для разработчиков, которые не знают языка Objective-C, необходимого для широко эквивалентного Cocoa API.
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 и возможностью одновременного запуска нескольких приложений появился новый вызов диспетчера событий, WaitNextEvent, который позволяет приложению указывать интервал ожидания. Один из простых приемов для устаревшего кода, позволяющего адаптировать более эффективную модель без серьезных изменений в исходном коде, - это просто установить для параметра сна, передаваемого в WaitNextEvent, очень большое значение - в macOS это переводит поток в режим сна, когда нечего делать., и возвращает событие только тогда, когда есть событие для обработки. Таким образом, модель опроса быстро инвертируется, чтобы стать эквивалентной модели обратного вызова, при этом приложение выполняет свою собственную диспетчеризацию событий оригинальным способом. Но есть лазейки. Во-первых, вызов устаревшей панели инструментов ModalDialog, например, вызывает старую функцию GetNextEvent изнутри, что приводит к замкнутому циклу опроса без блокировки.
Carbon представляет заменяющую систему, которая называется Carbon Event Manager. (Исходный диспетчер событий все еще существует для совместимости с устаревшими приложениями). Carbon Event Manager предоставляет разработчику цикл событий (на основе CFRunLoopCore Foundation в текущей реализации); разработчик настраивает обработчики событий и входит в цикл событий в основной функции и ожидает, пока Carbon Event Manager отправит события в приложение.
В классической Mac OS не было поддержки операционной системой для таймеров уровня приложений (был доступен диспетчер времени нижнего уровня, но он выполнял обратные вызовы таймера во время прерывания, во время которого выполнялись вызовы невозможно безопасно сделать для большинства подпрограмм Toolbox). Таймеры обычно оставлялись разработчикам приложений для реализации, и это обычно делалось путем подсчета прошедшего времени во время события простоя, то есть события, которое было возвращено WaitNextEvent, когда какое-либо другое событие было недоступно. Чтобы такие таймеры имели разумное разрешение, разработчики не могли позволить WaitNextEvent задерживать слишком долго, поэтому обычно устанавливались такие низкие параметры «сна». Это приводит к крайне неэффективному планированию, так как поток не будет спать очень долго, а вместо этого многократно просыпается, чтобы вернуть эти простаивающие события. Apple добавила в Carbon поддержку таймеров, чтобы решить эту проблему - система может планировать таймеры с большой эффективностью.
GNUstep содержит реализацию Carbon API под названием Boron. Он нацелен на совместимость с устаревшими частями ApplicationServices и CoreServices. Название происходит от того факта, что Бор стоит перед углеродом в периодической таблице элементов. Дарлинг также содержит реализацию углерода. Обе реализации очень неполны и состоят в основном из функций-заглушек.
