Carbon fue una de las dos principales interfaces de programación de aplicaciones (API) basadas en C desarrolladas por Apple para el sistema operativo macOS (anteriormente Mac OS X y OS X) . Carbon proporcionó un buen grado de compatibilidad con versiones anteriores para los programas que se ejecutaban en Mac OS 8 y 9. Los desarrolladores podían usar las API de Carbon para portar ("carbonizar") sus aplicaciones y software "clásicos" de Mac a la plataforma Mac OS X con poco esfuerzo, en comparación con portar la aplicación al sistema Cocoa completamente diferente , que se originó en OPENSTEP . Con el lanzamiento de macOS 10.15 Catalina , la API de Carbon se suspendió y eliminó oficialmente, dejando a Cocoa como la única API principal para desarrollar aplicaciones de macOS.
Carbon fue una parte importante de la estrategia de Apple para llevar Mac OS X al mercado, ofreciendo una vía para la rápida portabilidad de aplicaciones de software existentes, así como un medio para enviar aplicaciones que se ejecutarían tanto en Mac OS X como en el Mac OS clásico. A medida que el mercado se fue moviendo cada vez más hacia los marcos basados en Cocoa, especialmente después del lanzamiento de iOS , se redujo la necesidad de una biblioteca de portabilidad. Apple no creó una versión de 64 bits de Carbon mientras actualizaba sus otros marcos en el período de tiempo de 2007, y finalmente desaprobó toda la API en OS X 10.8 Mountain Lion , que se lanzó el 24 de julio de 2012.
El sistema operativo Mac OS original utilizaba Pascal como su plataforma de desarrollo principal y las API se basaban en gran medida en la semántica de llamadas de Pascal . Gran parte de la caja de herramientas de Macintosh consistía en llamadas a procedimientos , que pasaban información de ida y vuelta entre la API y el programa utilizando una variedad de estructuras de datos basadas en el concepto de registro de variantes de Pascal .
Con el tiempo, varias bibliotecas de objetos evolucionaron en Mac, en particular la biblioteca Object Pascal MacApp y la biblioteca de clases Think THINK C , y versiones posteriores de MacApp y PowerPlant de CodeWarrior en C++ .
Con la compra de NeXT a finales de 1996, Apple desarrolló una nueva estrategia de sistema operativo basada en gran medida en la plataforma OPENSTEP para Mach existente. La nueva estrategia de Rhapsody OS era relativamente simple: conservaba la mayoría de las bibliotecas de objetos existentes de OpenStep bajo el nombre de "Yellow Box", adaptaba la interfaz gráfica de usuario existente en OPENSTEP para Mach y la hacía más parecida a la de Mac, adaptaba varias API importantes de Mac OS al sistema subyacente de tipo Unix de Rhapsody (especialmente QuickTime y AppleSearch ) y añadía un emulador conocido como "Blue Box" que ejecutaba el software existente de Mac OS.
Cuando se reveló este plan en la Conferencia Mundial de Desarrolladores (WWDC) de 1997, hubo cierta resistencia por parte de los desarrolladores de Mac OS existentes, quienes estaban molestos porque sus bases de código quedarían bloqueadas en un emulador que probablemente nunca se actualizaría. Comenzaron a llamar a la Blue Box la "caja de penalización". [ cita requerida ] Los desarrolladores más grandes, como Microsoft y Adobe , se opusieron rotundamente y se negaron a considerar la posibilidad de portar a OpenStep, que era tan diferente del Mac OS existente que había poca o ninguna compatibilidad.
Apple se tomó muy en serio estas preocupaciones. Cuando Steve Jobs anunció el cambio de dirección de Apple en la siguiente WWDC en 1998, afirmó que "lo que los desarrolladores realmente querían era una versión moderna del Mac OS, y Apple [iba] a ofrecerla".
El concepto original de Rhapsody, que solo incluía la Blue Box para ejecutar el software existente de Mac OS, se lanzó finalmente en 1999 como Mac OS X Server 1.0 . Esta fue la única versión basada en el concepto original de Rhapsody.
Para ofrecer una ruta de actualización real y bien soportada para las bases de código de Mac OS existentes, Apple introdujo el sistema Carbon. Carbon consta de muchas bibliotecas y funciones que ofrecen una API similar a la de Mac, pero que se ejecuta sobre el sistema operativo subyacente similar a Unix, en lugar de una copia del sistema operativo Mac OS ejecutándose en emulación. Las bibliotecas Carbon se limpiaron, modernizaron y "protegieron" en gran medida. Mientras que Mac OS estaba lleno de API que compartían memoria para pasar datos, bajo Carbon todo ese acceso se volvió a implementar utilizando subrutinas de acceso en tipos de datos opacos . Esto permitió que Carbon admitiera una verdadera multitarea y protección de memoria , características que los desarrolladores de Mac habían estado solicitando durante una década. Otros cambios de la API preexistente eliminaron características que eran conceptualmente incompatibles con Mac OS X, o simplemente obsoletas. Por ejemplo, las aplicaciones ya no podían instalar controladores de interrupciones o controladores de dispositivos .
Para poder soportar Carbon, todo el modelo de Rhapsody cambió. Mientras que Rhapsody sería efectivamente OpenStep con un emulador, bajo el nuevo sistema, tanto la API de OpenStep como la de Carbon compartirían, siempre que fuera posible, código común. Para ello, muchos de los fragmentos útiles de código de los niveles inferiores del sistema OpenStep, escritos en Objective-C y conocidos como Foundation, se volvieron a implementar en C puro. Este código pasó a conocerse como Core Foundation , o CF para abreviar. Una versión de Yellow Box adaptada para llamar a CF se convirtió en la nueva API de Cocoa , y las llamadas de Carbon similares a las de Mac también llamaban a las mismas funciones. Bajo el nuevo sistema, Carbon y Cocoa eran iguales. Esta conversión normalmente habría ralentizado el rendimiento de Cocoa como los métodos de objeto llamados a las bibliotecas C subyacentes, pero Apple utilizó una técnica que llamaron toll-free bridging para reducir este impacto. [1]
Como parte de esta conversión, Apple también trasladó el motor gráfico del Display PostScript, que requería licencia , al Quartz, que no requería licencia (que se ha denominado "Display PDF"). [2] Quartz proporcionaba llamadas nativas que podían utilizarse tanto desde Carbon como desde Cocoa, además de ofrecer interfaces similares a las de Java 2D . El sistema operativo subyacente se aisló aún más y se publicó como Darwin .
Carbon se introdujo en forma incompleta en 2000, como una biblioteca compartida compatible con versiones anteriores de Mac OS 8.1 de 1997. Esta versión permitió a los desarrolladores portar su código a Carbon sin perder la capacidad de que esos programas se ejecutaran en máquinas Mac OS existentes. La migración a Carbon se conoció como "Carbonización". El soporte oficial de Mac OS X llegó en 2001 con el lanzamiento de Mac OS X v10.0 , la primera versión pública del nuevo sistema operativo. Carbon fue ampliamente utilizado en las primeras versiones de Mac OS X por casi todas las principales empresas de software, incluso por Apple. El Finder , por ejemplo, siguió siendo una aplicación de Carbon durante muchos años, y solo se trasladó a Cocoa con el lanzamiento de Mac OS X 10.6 en 2009. [3]
La transición a las aplicaciones Macintosh de 64 bits a partir de Mac OS X v10.5 , lanzado el 26 de octubre de 2007, trajo consigo las primeras limitaciones importantes a Carbon. Apple no proporciona compatibilidad entre la interfaz gráfica de usuario de Macintosh y el lenguaje de programación C en el entorno de 64 bits, y en su lugar requiere el uso del dialecto Objective-C con la API Cocoa. [4] Muchos comentarios tomaron esto como la primera señal de la eventual desaparición de Carbon, una posición que se reafirmó cuando Apple declaró que no se agregarían nuevas incorporaciones importantes al sistema Carbon, [5] [6] y se reforzó aún más con su desuso en 2012.
A pesar de las supuestas ventajas de Cocoa, la necesidad de reescribir grandes cantidades de código heredado ralentizó la transición de las aplicaciones basadas en Carbon, como sucedió con Adobe Photoshop [7] , que finalmente se actualizó a Cocoa en abril de 2010. Esto también se extendió a los paquetes de software estrella de Apple, ya que iTunes [8] y Final Cut Pro (así como las características del motor QuickTime que lo impulsa [9] ) permanecieron escritos en Carbon durante muchos años. Desde entonces, tanto iTunes como Final Cut Pro X se han lanzado en versiones Cocoa.
En 2012, con el lanzamiento de OS X 10.8 Mountain Lion, la mayoría de las API de Carbon se consideraron obsoletas. Las API seguían siendo accesibles para los desarrolladores y todas las aplicaciones de Carbon seguían ejecutándose, pero las API ya no se actualizarían. El 28 de junio de 2017, Apple anunció que el software de 32 bits para macOS, como todas las aplicaciones de Carbon, ya no recibiría soporte "sin concesiones" en las versiones de macOS posteriores a macOS 10.13 High Sierra . [10] macOS 10.15 Catalina eliminó oficialmente el soporte para aplicaciones de 32 bits, incluidas todas las aplicaciones de Carbon. [11]
Carbon desciende de Toolbox y, como tal, está compuesto de "Administradores". Cada Administrador es una API relacionada funcionalmente, que define conjuntos de estructuras de datos y funciones para manipularlas. Los administradores suelen ser interdependientes o estar estructurados en capas. Carbon consta de un amplio conjunto de funciones para administrar archivos, memoria, datos, la interfaz de usuario y otros servicios del sistema. Se implementa como cualquier otra API: en macOS, se distribuye en varios marcos (cada uno de ellos una estructura construida alrededor de una biblioteca compartida ), principalmente Carbon.framework, ApplicationServices.framework, y CoreServices.framework, y en Mac OS clásico, reside en una única biblioteca compartida denominada CarbonLib.
Como término general que abarca todos los procedimientos de API en lenguaje C que acceden a funciones específicas de Mac, Carbon no está diseñado como un sistema discreto. En cambio, abre casi toda la funcionalidad de macOS a los desarrolladores que no conocen el lenguaje Objective-C necesario para la API Cocoa, que es ampliamente equivalente . [12]
Carbon es compatible con todos los formatos ejecutables disponibles para PowerPC Mac OS. La compatibilidad binaria entre Mac OS X y versiones anteriores requiere el uso de un archivo de formato ejecutable preferido , que Apple nunca admitió en su IDE Xcode .
Las partes más nuevas de Carbon tienden a estar mucho más orientadas a objetos en su concepción, la mayoría de ellas basadas en Core Foundation . Algunos administradores, como el administrador HIView (un superconjunto del administrador de control), están implementados en C++ , pero Carbon sigue siendo una API de C.
Algunos ejemplos de Gestores de Carbono:
El Administrador de eventos de Mac Toolbox originalmente utilizaba un modelo de sondeo para el diseño de aplicaciones. El bucle de eventos principal de la aplicación solicita un evento al Administrador de eventos mediante GetNextEvent. Si hay un evento en la cola, el Administrador de eventos lo devuelve a la aplicación, donde se maneja; de lo contrario, regresa inmediatamente. Este comportamiento se denomina " espera activa ", que ejecuta el bucle de eventos innecesariamente. La espera activa reduce la cantidad de tiempo de CPU disponible para otras aplicaciones y disminuye la energía de la batería en las computadoras portátiles. El Administrador de eventos clásico data del Mac OS original en 1984, cuando se garantizaba que cualquier aplicación que se estuviera ejecutando sería la única aplicación en ejecución y donde la administración de energía no era una preocupación.
Con la llegada de MultiFinder y la capacidad de ejecutar más de una aplicación simultáneamente, llegó una nueva llamada al Administrador de eventos, WaitNextEvent , que permite a una aplicación especificar un intervalo de suspensión. Un truco fácil para que el código heredado adopte un modelo más eficiente sin cambios importantes en su código fuente es simplemente establecer el parámetro sleep pasado a WaitNextEvent en un valor muy grande; en macOS, esto pone el hilo en suspensión siempre que no hay nada que hacer y solo devuelve un evento cuando hay uno para procesar. De esta manera, el modelo de sondeo se invierte rápidamente para convertirse en equivalente al modelo de devolución de llamada, con la aplicación realizando su propio envío de eventos de la manera original. Sin embargo, existen lagunas. Por un lado, la llamada a la caja de herramientas heredada ModalDialog , por ejemplo, llama a la función GetNextEvent más antigua internamente, lo que da como resultado un sondeo en un bucle estrecho sin bloqueo.
Carbon presenta un sistema de reemplazo, llamado Carbon Event Manager. (El Event Manager original aún existe para compatibilidad con aplicaciones heredadas). Carbon Event Manager proporciona el bucle de eventos para el desarrollador (basado en Core Foundation CFRunLoopen la implementación actual); el desarrollador configura los controladores de eventos e ingresa el bucle de eventos en la función principal, y espera a que Carbon Event Manager envíe eventos a la aplicación.
En el Mac OS clásico, no había soporte del sistema operativo para temporizadores de nivel de aplicación (el Time Manager de nivel inferior estaba disponible, pero ejecutaba devoluciones de llamadas de temporizador en el tiempo de interrupción, durante el cual no se podían realizar llamadas de forma segura a la mayoría de las rutinas de Toolbox). Los temporizadores generalmente se dejaban en manos de los desarrolladores de aplicaciones para que los implementaran, y esto generalmente se hacía contando el tiempo transcurrido durante el evento inactivo , es decir, un evento que era devuelto por WaitNextEvent cuando ningún otro evento estaba disponible. Para que estos temporizadores tuvieran una resolución razonable, los desarrolladores no podían permitirse que WaitNextEvent se demorara demasiado, por lo que generalmente se establecían parámetros de "suspensión" bajos. Esto da como resultado un comportamiento de programación altamente ineficiente, ya que el hilo no se suspenderá durante mucho tiempo, sino que se activará repetidamente para devolver estos eventos inactivos. Apple agregó compatibilidad con temporizadores a Carbon para abordar este problema: el sistema puede programar temporizadores con gran eficiencia.
GNUstep contiene una implementación de la API Carbon llamada Boron. Su objetivo es ser compatible con las partes no obsoletas de ApplicationServices y CoreServices. El nombre deriva del hecho de que Boron aparece antes que Carbon en la tabla periódica de elementos . [14] Darling también contiene una implementación de Carbon. Ambas implementaciones son muy incompletas y consisten principalmente en funciones auxiliares.