De carbono es uno de los de Apple ‘s basados en C interfaces de programación de aplicaciones (API) para macOS (anteriormente Mac OS X), el sistema operativo que alimenta Macintosh computadoras. 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") su software Mac "clásico" 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..
Desarrollador (es) | Apple Inc. |
---|---|
Sistema operativo | Mac OS clásico , macOS |
Licencia | Propiedad |
Sitio web | http://developer.apple.com/referencelibrary/Carbon/ en Wayback Machine (archivado el 20 de abril de 2009) |
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 de envío de 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 migración se diluyó. Apple no crear un 64-bit versión de carbono, mientras que la actualización de sus otros marcos en el marco de tiempo de 2007, y, finalmente obsoleto todo el API de OS X 10.8 Mountain Lion , que fue lanzado el 24 de julio de 2012. carbono se suspendió oficialmente y eliminado por completo con el lanzamiento de macOS 10.15 Catalina .
Historia
Programación clásica de Mac OS
El Mac OS original usaba 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 Macintosh Toolbox consistía en llamadas a procedimientos , pasando información 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 Think Class Library (TCL) en Pascal, y versiones posteriores de MacApp y PowerPlant de CodeWarrior en C ++ . A mediados de la década de 1990, la mayoría del software de Mac estaba escrito en C ++ usando CodeWarrior.
Rapsodia
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", transfirió la GUI existente de OpenStep y la hizo parecer más similar a Mac, transfirió varias API importantes de Mac OS al sistema subyacente similar a Unix de Rhapsody (especialmente QuickTime y AppleSearch ) y agregó un emulador conocido como "Blue Box" que ejecutaba el software Mac OS existente.
Cuando este plan fue revelado en la Conferencia Mundial de Desarrolladores en 1997, hubo cierto rechazo por parte de los desarrolladores de Mac OS existentes, quienes estaban molestos porque sus bases de código estarían efectivamente bloqueadas en un emulador que era poco probable que alguna vez se actualizara. Empezaron a llamar a la Caja Azul 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 migración a OpenStep, que era tan diferente del Mac OS existente que había poca o ninguna compatibilidad.
Apple tomó estas preocupaciones en serio. Cuando Steve Jobs anunció este cambio de dirección en la WWDC de 1998, declaró que "lo que los desarrolladores realmente querían era una versión moderna de Mac OS, y Apple [iba] a ofrecerla". La declaración fue recibida con un aplauso atronador.
El concepto original de Rhapsody, con solo la caja azul 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.
Cacao y Carbono
Con el fin de 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 Mac, pero que se ejecutan sobre el sistema operativo similar a Unix subyacente, en lugar de una copia del sistema operativo Mac que se ejecuta en emulación. Las bibliotecas de Carbon se limpian en profundidad, se modernizan y se "protegen" mejor. Mientras que Mac OS estaba lleno de API que compartían memoria para pasar datos, en Carbon todo ese acceso se volvió a implementar utilizando subrutinas de acceso en tipos de datos opacos . Esto permitió a Carbon admitir una verdadera protección de memoria y multitarea , 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 dispositivos o controladores de interrupciones .
Para ser compatible con Carbon, todo el modelo de Rhapsody cambió. Mientras que Rhapsody sería efectivamente OpenStep con un emulador, bajo el nuevo sistema tanto OpenStep como Carbon API compartirían, cuando fuera posible, un código común. Para hacer esto, muchos de los bits ú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. Este código se conoció como Core Foundation , o CF para corto. 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 Mac también llamaron las mismas funciones. Bajo el nuevo sistema, Carbon y Cocoa eran pares. Esta conversión normalmente habría ralentizado el rendimiento de Cocoa a medida que los métodos de objeto llamaban 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 gráfico de Display PostScript con licencia al Quartz sin licencia (que se ha llamado "Display PDF"). [2] Quartz proporcionó llamadas nativas que se podían usar desde Carbon o Cocoa, además de ofrecer interfaces similares a Java 2D . El propio sistema operativo subyacente se aisló aún más y se lanzó como Darwin .
Lanzamiento y evolución
Carbon se introdujo de 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 migrar su código a Carbon sin perder la capacidad de esos programas para ejecutarse 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. El carbono fue muy 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 , lanzada 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 esta 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 de Carbon, [5] y se reforzó aún más con su depreciación en 2012. .
Transición al cacao
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, sobre todo con Adobe Photoshop , [6] 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 [7] y Final Cut Pro (así como las funciones del motor QuickTime que lo impulsa [8] ) permanecieron escritos en Carbon durante muchos años. Tanto iTunes como Final Cut Pro X se han lanzado desde entonces en versiones Cocoa.
Desaprobación y descontinuación
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 aún eran accesibles para los desarrolladores 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 compromiso" en las versiones de macOS posteriores a macOS 10.13 High Sierra . [9] macOS 10.15 Catalina eliminó oficialmente la compatibilidad con aplicaciones de 32 bits, incluidas todas las aplicaciones Carbon. [10]
Arquitectura
Carbon desciende de Toolbox y, como tal, está compuesto por "Gerentes". Cada administrador es una API funcionalmente relacionada, que define conjuntos de estructuras de datos y funciones para manipularlos. Los gerentes suelen ser interdependientes o 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, que se extiende sobre varios marcos (cada uno una estructura construida en torno a una biblioteca compartida ), principalmente Carbon.framework
, ApplicationServices.framework
y CoreServices.framework
, como en Mac OS clásico, que reside en una sola biblioteca compartida llamada 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. Más bien, abre casi toda la funcionalidad de macOS a los desarrolladores que no conocen el lenguaje Objective-C requerido para la API Cocoa ampliamente equivalente . [11]
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 de 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), se implementan en C ++ , pero Carbon sigue siendo una API de C.
Algunos ejemplos de gestores de carbono:
- Administrador de archivos: administra el acceso al sistema de archivos, abriendo, cerrando, leyendo y escribiendo archivos.
- Administrador de recursos: administra el acceso a los recursos, que son fragmentos de datos predefinidos que un programa puede requerir. Llama al Administrador de archivos para leer y escribir recursos desde archivos de disco. Los ejemplos de recursos incluyen iconos, sonidos, imágenes, plantillas para widgets, etc.
- Administrador de fuentes: administra las fuentes . En desuso (como parte de QuickDraw ) desde Mac OS X v10.4 , a favor de Apple Type Services (ATS).
- QuickDraw : primitivas de gráficos 2D. En desuso desde Mac OS X v10.4 , a favor de Quartz 2D.
- Carbon Event Manager: convierte la actividad del usuario y del sistema en eventos que el código puede reconocer y responder.
- HIObject: una API orientada a objetos completamente nueva que trae a Carbon un modelo OO para construir GUI. HIToolbox en Mac OS Classic y Copland [12] se basó en IBM System Object Model abandonado , por lo que Carbon tuvo que proporcionar un reemplazo rápido y sucio para permitir la migración del código heredado. Esto está disponible en Mac OS X v10.2 o posterior, y brinda a los programadores de Carbon algunas de las herramientas con las que los desarrolladores de Cocoa están familiarizados desde hace mucho tiempo. A partir de Mac OS X v10.2 , HIObject es la clase base para todos los elementos GUI en Carbon. HIView es compatible con Interface Builder , que forma parte de las herramientas de desarrollo de Apple. Tradicionalmente, las arquitecturas GUI de este tipo se dejaban en manos de marcos de aplicaciones de terceros. A partir de Mac OS X v10.4, los HIObjects son NSObjects y heredan la capacidad de ser serializados en flujos de datos para transportarlos o guardarlos en el disco.
- HITheme: utiliza QuickDraw y Quartz para representar elementos de la interfaz gráfica de usuario (GUI) en la pantalla. HITheme se introdujo en Mac OS X v10.3 , y Appearance Manager es una capa de compatibilidad además de HITheme desde esa versión.
- HIView Manager: gestiona la creación, el dibujo, las pruebas de posicionamiento y la manipulación de los controles. Desde Mac OS X v10.2, todos los controles son HIViews. En Mac OS X v10.4, Control Manager pasó a llamarse HIView Manager.
- Administrador de ventanas: administra la creación, el posicionamiento, la actualización y la manipulación de ventanas. Desde Mac OS X v10.2, Windows tiene una raíz HIView.
- Administrador de menús: administra la creación, selección y manipulación de menús. Desde Mac OS X v10.2, los menús son objetos HIO. Desde Mac OS X v10.3, el contenido del menú se puede dibujar usando HIViews, y todos los menús estándar usan HIViews para dibujar.
Manejo de eventos
El Event Manager 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 " ocupado en espera " 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 Event Manager data del Mac OS original en 1984, cuando se garantizaba que cualquier aplicación que se estuviera ejecutando fuera 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 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 convertirse en 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 caja de herramientas heredada llamada ModalDialog , por ejemplo, llama a la función anterior GetNextEvent internamente, lo que resulta en 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 CFRunLoop
en 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.
Temporizadores
En el Mac OS clásico, el sistema operativo no era compatible con los temporizadores de 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 forma segura a la mayoría de las rutinas de Toolbox). Los temporizadores generalmente se dejaban a 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 tales 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 bajos de "suspensión". Esto da como resultado un comportamiento de programación altamente ineficiente, ya que el hilo no dormirá por mucho tiempo, sino que se despertará 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.
Implementaciones de código abierto
GNUstep contiene una implementación de la API de carbono llamada Boron. Su objetivo es ser compatible con partes no obsoletas de ApplicationServices y CoreServices. El nombre deriva del hecho de que el boro viene antes que el carbono en la tabla periódica de elementos . [13] Darling también contiene una implementación de Carbon. Ambas implementaciones están muy incompletas y consisten principalmente en funciones stub.
Ver también
- Cacao
- Constructor de interfaces
- C objetivo
- Xcode
Referencias
- ^ "Conceptos en programación de Objective-C: puenteo gratuito" . developer.apple.com . 2012 . Consultado el 8 de mayo de 2017 .
- ^ Siracusa, John (2000). "Actualización de Mac OS X: Quartz & Aqua" . archive.arstechnica.com . Consultado el 8 de mayo de 2017 .
- ^ Krazit, Tom (17 de octubre de 2008). "Apple moviendo Finder a Cocoa" . CNET . Archivado desde el original el 11 de julio de 2015 . Consultado el 21 de mayo de 2015 .
- ^ Apple Inc. "Introducción a la guía de 64 bits para desarrolladores de carbono" . Archivado desde el original el 11 de junio de 2009.
- ^ Apple Inc. "Elegir una ruta de desarrollo para su interfaz de usuario de Carbon" . Modificación de su aplicación para utilizar direccionamiento de 64 bits . Archivado desde el original el 4 de agosto de 2009.
- ^ John Nack. "Photoshop, Lightroom y la hoja de ruta de 64 bits de Adobe" . Archivado desde el original el 14 de abril de 2015.
- ^ Chris Foresman. "Práctica de iTunes 10: rendimiento más ágil, opciones de interfaz de usuario cuestionables" . Archivado desde el original el 2 de abril de 2015.
- ^ John Siracusa. "Mac OS X 10.6 Snow Leopard: la revisión de Ars Technica" . Archivado desde el original el 13 de julio de 2014.
- ^ Apple Inc. (28 de junio de 2017). "Requisito de 64 bits para aplicaciones Mac" . Archivado desde el original el 30 de enero de 2018 . Consultado el 18 de febrero de 2018 .
- ^ MacRumors (4 de junio de 2019). "Aplicaciones de 32 bits 'no optimizadas para su Mac' para dejar de funcionar en macOS Catalina" . Consultado el 10 de agosto de 2019 .
- ^ Apple Inc. "Página de inicio de Apple Carbon" . Archivado desde el original el 12 de octubre de 2012.
- ^ Descripción de la clase HIEditText SOM de Mac OS 8.0 (Copland) DDK [ enlace muerto permanente ]
- ^ "gnustep / libs-boron: El boro es el átomo que precede al carbono" . GitHub . GNUstep. 23 de marzo de 2019.