Углерод (API)

Углерод является одним из Apple , «s 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 [ править ]

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

Со временем на Mac появился ряд объектных библиотек , в частности, библиотека Object Pascal MacApp и Think Class Library (TCL) в Pascal, а также более поздние версии MacApp и CodeWarrior PowerPlant на C ++ . К середине 1990-х годов большая часть программного обеспечения Mac была написана на C ++ с использованием CodeWarrior.

Рапсодия [ править ]

После покупки NeXT в конце 1996 года Apple разработала новую стратегию операционной системы, основанную в основном на существующей платформе OpenStep . Новая рапсодия была относительно простой; он сохранил большую часть существующих объектных библиотек OpenStep под названием «Yellow Box», перенес существующий графический интерфейс 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 состоит из множества библиотек и функций, которые предлагают Mac-подобный API, но работают поверх базовой Unix-подобной ОС, а не копии Mac OS, работающей в режиме эмуляции. Библиотеки углерода тщательно очищены, модернизированы и лучше "защищены". В то время как 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 и Mac-подобные вызовы Carbon также вызывали одни и те же функции. В рамках новой системы Carbon и Cocoa были равными. Это преобразование обычно замедляло бы производительность Какао как объектных методов, вызываемых в базовые библиотеки C, но Apple использовала технику, которую они назвали бесплатным мостом, чтобы уменьшить это влияние. ^[1]

В рамках этого преобразования Apple также перенесла графический движок с обремененного лицензией Display PostScript на безлицензионный Quartz (который получил название «Display PDF»). ^[2] 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 , например, осталась применением углерода в течение многих лет, только будучи перенесена на какао с выпуском Mac OS X 10.6 в 2009 году ^[3]

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

Переход на Какао [ править ]

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

Прекращение поддержки и прекращения поддержки [ править ]

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

Архитектура [ править ]

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

Как общий термин, охватывающий все процедуры API на языке C, обеспечивающие доступ к специфическим для Mac функциям, Carbon не задуман как отдельная система. Скорее, он открывает почти все функциональные возможности macOS для разработчиков, которые не знают язык Objective-C, необходимый для широко эквивалентного API Cocoa . ^[11]

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

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

Некоторые примеры углеродных менеджеров:

• Файловый менеджер - управляет доступом к файловой системе, открытием, закрытием, чтением и записью файлов.
• Диспетчер ресурсов - управляет доступом к ресурсам, которые представляют собой заранее определенные блоки данных, которые могут потребоваться программе. Вызывает диспетчер файлов для чтения и записи ресурсов из файлов на диске. Примеры ресурсов включают значки, звуки, изображения, шаблоны для виджетов и т. Д.
• 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 , который приводит к углероду в ОО модель построения графического интерфейса. HIToolbox в Mac OS Classic и Copland ^[12] полагался на заброшенную системную объектную модель IBM , поэтому Carbon пришлось предоставить быструю и грязную замену, позволяющую переносить унаследованный код. Это доступно в Mac OS X v10.2 или новее и дает программистам Carbon некоторые инструменты, с которыми разработчики Cocoa уже давно знакомы. Начиная с Mac OS X v10.2 , HIObject является базовым классом для всех элементов графического интерфейса в Carbon. HIView поддерживается Interface Builder., часть инструментов разработчика Apple. Традиционно архитектуры GUI такого типа предоставлялись сторонним программным средам. Начиная с Mac OS X v10.4, объекты HIObject являются объектами NSObject и наследуют возможность сериализации в потоки данных для транспортировки или сохранения на диск.
• HITheme - использует QuickDraw и Quartz для визуализации элементов графического интерфейса пользователя (GUI) на экране. HITheme была представлена ​​в Mac OS X v10.3 , а с этой версии диспетчер внешнего вида является уровнем совместимости поверх HITheme.
• HIView Manager - управляет созданием, рисованием, проверкой попадания и манипулированием элементами управления. Начиная с Mac OS X v10.2, все элементы управления являются HIViews. В Mac OS X v10.4 Control Manager был переименован в HIView Manager.
• Диспетчер окон - управляет созданием, размещением, обновлением и управлением окнами. Начиная с Mac OS X v10.2, окна имеют корневой файл HIView.
• Диспетчер меню - управляет созданием, выбором и изменением меню. Начиная с Mac OS X v10.2, меню являются объектами HIO. Начиная с Mac OS X v10.3, содержимое меню можно рисовать с помощью HIViews, а все стандартные меню используют HIViews для рисования.

Обработка событий [ править ]

Диспетчер событий 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 операционная система не поддерживала таймеры уровня приложения (был доступен Time Manager более низкого уровня, но он выполнял обратные вызовы таймера во время прерывания, в течение которого нельзя было безопасно выполнять вызовы большинства подпрограмм Toolbox). Таймеры обычно оставлялись разработчикам приложений для реализации, и это обычно делалось путем подсчета прошедшего времени во время события простоя, то есть события, которое было возвращено WaitNextEvent, когда какое-либо другое событие было недоступно. Чтобы такие таймеры имели разумное разрешение, разработчики не могли позволить себе WaitNextEvent.задерживать слишком долго, поэтому обычно устанавливались такие низкие параметры «сна». Это приводит к крайне неэффективному планированию, так как поток не будет спать очень долго, а вместо этого многократно просыпается, чтобы вернуть эти события бездействия. Apple добавила в Carbon поддержку таймеров, чтобы решить эту проблему - система может планировать таймеры с большой эффективностью.

Реализации с открытым исходным кодом [ править ]

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

См. Также [ править ]

• Какао
• Разработчик интерфейса
• Цель-C
• Xcode

Ссылки [ править ]