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 programas que se ejecutaban en Mac OS 8 y 9 . Los desarrolladores podrí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 Carbon se suspendió y eliminó oficialmente, dejando a Cocoa como la única API principal para desarrollar aplicaciones macOS.
Carbon fue una parte importante de la estrategia de Apple para llevar Mac OS X al mercado, ofreciendo un camino para la migración rápida de aplicaciones de software existentes, así como un medio para enviar aplicaciones que se ejecutarían en Mac OS X o en el Mac OS clásico. A medida que el mercado se ha movido cada vez más hacia los marcos basados en Cocoa, especialmente después del lanzamiento de iOS , la necesidad de una biblioteca de portabilidad se diluyó. Apple no creó una versión de 64 bits de Carbon mientras actualizaba sus otros marcos en el período de 2007 y, finalmente, dejó obsoleta toda la API en OS X 10.8 Mountain Lion , que se lanzó el 24 de julio de 2012.
El Mac OS original utilizaba Pascal como plataforma de desarrollo principal y las API se basaban en gran medida en la semántica de llamadas de Pascal . Gran parte de Macintosh Toolbox consistía en llamadas a procedimientos , pasando información de un lado a otro entre la API y el programa utilizando una variedad de estructuras de datos basadas en el concepto de registro variante de Pascal .
Con el tiempo, varias bibliotecas de objetos evolucionaron en Mac, en particular la biblioteca Object Pascal MacApp y la biblioteca THINK C Think Class, y versiones posteriores de MacApp y PowerPlant de CodeWarrior en C++ . A mediados de la década de 1990, la mayor parte del software de Mac se escribía en C++ utilizando CodeWarrior.
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 existente. La nueva Rhapsody era relativamente simple; retuvo la mayoría de las bibliotecas de objetos existentes de OpenStep bajo el nombre "Yellow Box", portó la GUI existente de OpenStep y la hizo parecer más parecida a Mac, portó varias API importantes desde Mac OS al sistema subyacente tipo Unix de Rhapsody (en particular, QuickTime y AppleSearch ) . y agregó un emulador conocido como "Blue Box" que ejecutaba el software Mac OS existente.
Cuando se reveló este plan en la Conferencia Mundial de Desarrolladores de 1997, hubo cierta oposición por parte de los desarrolladores existentes de Mac OS, quienes estaban molestos porque sus bases de código quedarían efectivamente encerradas en un emulador que era poco probable que alguna vez se actualizara. Empezaron a llamar al Cuadro Azul el "cuadro de penalti". [ cita necesaria ] Los desarrolladores más grandes como Microsoft y Adobe se opusieron rotundamente y se negaron a considerar la migración a OpenStep, que era tan diferente del Mac OS existente que había poca o ninguna compatibilidad.
Apple tomó en serio estas preocupaciones. Cuando Steve Jobs anunció este cambio de dirección en la WWDC de 1998, afirmó que "lo que los desarrolladores realmente querían era una versión moderna de Mac OS, y Apple [iba] a entregarla".
El concepto original de Rhapsody, con sólo la Blue Box para ejecutar el software Mac OS existente, finalmente se lanzó en 1999 como Mac OS X Server 1.0 . Este fue el único lanzamiento basado en el concepto original de Rhapsody.
Para ofrecer una ruta de actualización real y con buen soporte para las bases de código existentes de Mac OS, Apple presentó el sistema Carbon. Carbon consta de muchas bibliotecas y funciones que ofrecen una API similar a Mac, pero que se ejecuta sobre el sistema operativo subyacente tipo Unix, en lugar de una copia del sistema operativo Mac que se ejecuta en emulación. Las bibliotecas de Carbon se han limpiado, modernizado y "protegido" mejor. Mientras que Mac OS estaba lleno de API que compartían memoria para pasar datos, bajo Carbon todo ese acceso se reimplementó utilizando subrutinas de acceso en tipos de datos opacos . Esto permitió a Carbon admitir una verdadera multitarea y protección de la memoria , características que los desarrolladores de Mac habían estado solicitando durante una década. Otros cambios de la API preexistente eliminaron funciones que eran conceptualmente incompatibles con Mac OS X o simplemente estaban obsoletas. Por ejemplo, las aplicaciones ya no podían instalar controladores de interrupciones ni controladores de dispositivos .
Para admitir Carbon, todo el modelo Rhapsody cambió. Mientras que Rhapsody sería efectivamente OpenStep con un emulador, bajo el nuevo sistema tanto OpenStep como Carbon API compartirían, cuando sea posible, código común. Para hacer esto, muchos de los fragmentos de código útiles de los niveles inferiores del sistema OpenStep, escritos en Objective-C y conocidos como Foundation, se reimplementaron en C puro. Este código se conoció como Core Foundation , o CF para corto. Una versión de Yellow Box portada para llamar a CF se convirtió en la nueva API Cocoa , y las llamadas de Carbon similares a Mac también llamaron a las mismas funciones. Bajo el nuevo sistema, Carbon y Cocoa eran pares. Esta conversión normalmente habría ralentizado el rendimiento de Cocoa cuando los métodos de objeto llamaron a las bibliotecas C subyacentes, pero Apple utilizó una técnica que llamaron puente gratuito para reducir este impacto. [1]
Como parte de esta conversión, Apple también transfirió el motor de gráficos del Display PostScript con licencia al Quartz sin licencia (que se ha denominado "Display PDF"). [2] Quartz proporcionó llamadas nativas que podrían usarse desde Carbon o Cocoa, además de ofrecer interfaces similares a Java 2D . El sistema operativo subyacente fue aún más aislado y lanzado 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 ejecutar esos programas en máquinas Mac OS existentes. La migración al carbono se conoció como "carbonización". El soporte oficial para 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 muy utilizado en las primeras versiones de Mac OS X por casi todas las principales casas de software, incluso por Apple. El Finder , por ejemplo, siguió siendo una aplicación de Carbon durante muchos años y solo se transfirió a Cocoa con el lanzamiento de Mac OS X 10.6 en 2009. [3]
La transición a aplicaciones Macintosh de 64 bits a partir de Mac OS X v10.5 , lanzado el 26 de octubre de 2007, trajo 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, sino que 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 reforzó cuando Apple declaró que no se agregarían nuevas adiciones importantes al sistema Carbon, [5] [6] y se reforzó aún más con su depreciación 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, famosa por Adobe Photoshop , [7] que finalmente se actualizó a Cocoa en abril de 2010. Esto también se extendió al propio buque insignia de Apple. Los paquetes de software, como iTunes [8] y Final Cut Pro (así como las funciones 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. Los desarrolladores todavía podían acceder a las API y todas las aplicaciones de Carbon aún se ejecutaban, 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 Carbon, ya no sería compatible "sin concesiones" en las versiones de macOS posteriores a macOS 10.13 High Sierra . [10] macOS 10.15 Catalina eliminó oficialmente la compatibilidad con aplicaciones de 32 bits, incluidas todas las aplicaciones Carbon. [11]
Carbon desciende de la Caja de Herramientas y, como tal, está compuesto por "Administradores". Cada Manager es una API funcionalmente relacionada, que define conjuntos de estructuras de datos y funciones para manipularlas. Los gerentes suelen ser interdependientes o estratificados. 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.frameworky CoreServices.framework, y en Mac OS clásico, reside en una única biblioteca compartida llamada CarbonLib.
Como término general que abarca todos los procedimientos API en lenguaje C que acceden a funciones específicas de Mac, Carbon no está diseñado como un sistema discreto. Más bien, abre casi todas las funciones de macOS a los desarrolladores que no conocen el lenguaje Objective-C necesario para la API Cocoa, 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 HIView Manager (un superconjunto de Control Manager), 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 utilizó originalmente un modelo de sondeo para el diseño de aplicaciones. El bucle de eventos principal de la aplicación solicita al administrador de eventos un evento 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 ocupada ", y ejecuta el bucle de eventos innecesariamente. La espera ocupada 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 clásico Administrador de eventos data del Mac OS original de 1984, cuando se garantizaba que cualquier aplicación que se estuviera ejecutando sería la única 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, surgió una nueva llamada del Administrador de eventos, WaitNextEvent , que permite que una aplicación especifique 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 de suspensión pasado a WaitNextEvent en un valor muy grande; en macOS, esto pone el hilo en suspensión cuando 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 volverse equivalente al modelo de devolución de llamada, y la aplicación realiza su propio envío de eventos de la manera original. Sin embargo, existen lagunas. Por un lado, la llamada de la caja de herramientas heredada ModalDialog , por ejemplo, llama internamente a la función GetNextEvent más antigua , lo que da como resultado un sondeo en un bucle cerrado sin bloqueo.
Carbon presenta un sistema de reemplazo, llamado Carbon Event Manager. (El Administrador de eventos original todavía existe por 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 controladores de eventos e ingresa al 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 a nivel de aplicación (el Administrador de tiempo de nivel inferior estaba disponible, pero ejecutaba devoluciones de llamada del temporizador en el momento de la interrupción, durante el cual no se podían realizar llamadas de manera segura a la mayoría de las rutinas de Toolbox). Por lo general, los temporizadores 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 WaitNextEvent devolvía cuando ningún otro evento no estaba disponible. Para que dichos temporizadores tuvieran una resolución razonable, los desarrolladores no podían permitirse que WaitNextEvent se retrasara 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 subproceso no permanecerá inactivo por mucho tiempo, sino que se despertará repetidamente para devolver estos eventos inactivos. Apple agregó soporte de temporizador a Carbon para solucionar 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 partes no obsoletas de ApplicationServices y CoreServices. El nombre deriva del hecho de que el Boro aparece antes que el Carbono en la tabla periódica de elementos . [14] Darling también contiene una implementación de Carbon. Ambas implementaciones son muy incompletas y constan principalmente de funciones auxiliares.