Hispanopedia Wiki
Articulo de referencia

Carbono (API)

Carbon era una interfaz de programación de aplicaciones (API) basada en C , ya descontinuada , desarrollada por Apple para Mac OS X. Introducida para facilitar la transición des...

Hispanopedia WikiContenido en espanolLectura gratuita

Carbon era una interfaz de programación de aplicaciones (API) basada en C , ya descontinuada , desarrollada por Apple para Mac OS X. Introducida para facilitar la transición desde Mac OS 8 y Mac OS 9 , permitía a los desarrolladores portar ("carbonizar") aplicaciones existentes a Mac OS X manteniendo la compatibilidad con el Mac OS clásico . Carbon complementaba a Cocoa , la API orientada a objetos heredada de NeXTSTEP , que se convirtió en el marco de desarrollo de aplicaciones principal de Apple.

A medida que los desarrolladores adoptaron Cocoa cada vez más, especialmente tras la introducción de iOS , el papel de Carbon disminuyó. Apple nunca lanzó una versión de 64 bits de la mayoría de las API de Carbon, descontinuó el framework en OS X 10.8 Mountain Lion en 2012 y lo eliminó por completo con macOS 10.15 Catalina en 2019, dejando a Cocoa como la principal API nativa para el desarrollo de aplicaciones para Mac.

Historia

Aplicación "carbonizada" Adobe ImageReady v7.0 ejecutándose directamente en Mac OS X 10.2

Programación clásica de Mac OS

El sistema operativo 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 , que intercambiaban información entre la API y el programa mediante diversas estructuras de datos basadas en el concepto de registro variante de Pascal .

Con el tiempo, se desarrollaron varias bibliotecas de objetos para Mac, en particular la biblioteca Object Pascal MacApp y la biblioteca de clases THINK C Think Class Library, y versiones posteriores de MacApp y PowerPlant de CodeWarrior en C++ .

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 para Mach . 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 (GUI) 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 tipo Unix de Rhapsody (en particular QuickTime y AppleSearch ) y añadía un emulador conocido como "Blue Box" que ejecutaba el software existente de Mac OS.

Cuando este plan se presentó en la Conferencia Mundial de Desarrolladores (WWDC) de 1997, hubo cierta resistencia por parte de los desarrolladores de Mac OS, quienes estaban molestos porque sus bases de código quedarían efectivamente bloqueadas en un emulador que probablemente nunca se actualizaría. Empezaron a llamar a la "caja azul" la "caja de castigo". Desarrolladores más grandes como Microsoft y Adobe se opusieron rotundamente y se negaron a considerar la posibilidad de migrar a OpenStep, que era tan diferente del Mac OS existente que la compatibilidad era mínima o nula.

Apple se tomó muy en serio estas preocupaciones. Cuando Steve Jobs anunció el cambio de rumbo 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 se la iba a proporcionar".

El concepto original de Rhapsody, que solo incluía la Caja Azul para ejecutar software existente de Mac OS, finalmente se lanzó en 1999 como Mac OS X Server 1.0 . Esta fue la única versión basada en el concepto original de Rhapsody.

Cacao y carbono

Para ofrecer una ruta de actualización real y bien respaldada para las bases de código existentes de Mac OS, Apple introdujo el sistema Carbon. Carbon consta de muchas bibliotecas y funciones que ofrecen una API similar a la de Mac, pero ejecutándose sobre el sistema operativo subyacente tipo Unix, en lugar de una copia de Mac OS ejecutándose en emulación. Las bibliotecas de Carbon se han limpiado, modernizado y "protegido" ampliamente. Mientras que Mac OS estaba lleno de API que compartían memoria para pasar datos, en Carbon todo ese acceso se reimplementó usando subrutinas de acceso en tipos de datos opacos . Esto permitió que Carbon admitiera la verdadera multitarea y la 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 manejadores de interrupciones o controladores de dispositivos .

Para dar soporte a Carbon, se modificó por completo el modelo de Rhapsody. Mientras que Rhapsody era, en esencia, OpenStep con un emulador, bajo el nuevo sistema, tanto la API de OpenStep como la de Carbon compartirían, en la medida de lo posible, código común. Para ello, gran parte del código útil de los niveles inferiores del sistema OpenStep, escrito en Objective-C y conocido como Foundation, se reimplementó en C puro. Este código se denominó Core Foundation , o CF. 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, ya que los métodos de los objetos llamaban a las bibliotecas C subyacentes, pero Apple utilizó una técnica que denominó puente gratuito para reducir este impacto. [ 1 ]

Como parte de esta conversión, Apple escribió desde cero un nuevo servidor de ventanas y un motor gráfico para reemplazar Display PostScript , que estaba sujeto a licencia: Quartz (que se ha llamado "Display PDF"). [ 2 ] Quartz proporcionaba llamadas a la API de C que podían usarse desde Carbon o Cocoa. El 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 el año 2000, como una biblioteca compartida retrocompatible con 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 portabilidad a Carbon 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 compañías de software, incluso por Apple. El Finder , por ejemplo, siguió siendo una aplicación de Carbon durante muchos años, y solo se portó a Cocoa con el lanzamiento de Mac OS X 10.6 en 2009. [ 3 ]

La transición a las aplicaciones de Macintosh de 64 bits, que comenzó con 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 más con su descontinuació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, especialmente con Adobe Photoshop , [ 7 ] que finalmente se actualizó a Cocoa en abril de 2010. Esto también afectó a los paquetes de software insignia de Apple, ya que iTunes , [ 8 ] la aplicación Finder 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, iTunes, Finder y Final Cut Pro se han lanzado en versiones Cocoa.

Descontinuació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. Si bien los desarrolladores aún podían acceder a ellas y todas las aplicaciones de Carbon seguían funcionando, las API dejaron de actualizarse. El 28 de junio de 2017, Apple anunció que el software de 32 bits para macOS, incluidas todas las aplicaciones de Carbon, dejaría de ser compatible "sin restricciones" 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 de Carbon. [ 11 ]

Arquitectura

Carbon desciende de Toolbox y, como tal, está compuesto por "Administradores". Cada Administrador es una API funcionalmente relacionada, que define conjuntos de estructuras de datos y funciones para manipularlas. Los Administradores suelen ser interdependientes o estar organizados 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 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 llamada CarbonLib.

Carbon no es una caja de compatibilidad; es una API nativa para Mac OS X. En un diagrama de arquitectura, se sitúa prácticamente al mismo nivel que Cocoa. Las aplicaciones de Carbon pueden usar todas las funciones nativas de Mac OS X, y se pueden combinar ventanas de Carbon y Cocoa en el mismo proceso.

Carbon es compatible con todos los formatos ejecutables disponibles para Mac OS PowerPC. 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 recientes de Carbon tienden a ser mucho más orientadas a objetos en su concepción, la mayoría basadas en Core Foundation . Algunos administradores, como el HIView Manager (un superconjunto del Control Manager), están implementados en C++ , pero Carbon sigue siendo una API de C.

Algunos ejemplos de gestores de carbono:

  • Administrador de archivos : gestiona el acceso al sistema de archivos, permitiendo abrir, cerrar, leer y escribir archivos.
  • Administrador de recursos : gestiona el acceso a fragmentos de datos en la bifurcación de recursos de un archivo. Algunos ejemplos de recursos son iconos, sonidos, imágenes, plantillas para widgets, etc.
  • Administrador de fuentes : gestiona las fuentes . Obsoleto (como parte de QuickDraw ) desde Mac OS X v10.4 , en favor de Apple Type Services (ATS).
  • QuickDraw : primitivas gráficas 2D. Obsoleto desde Mac OS X v10.4 , en favor de Quartz 2D.
  • Carbon Event Manager : convierte la actividad del usuario y del sistema en eventos que el código puede reconocer y a los que puede responder.
  • HIObject es una API completamente nueva orientada a objetos que aporta a Carbon un modelo OO para la creación de interfaces gráficas de usuario (GUI). Está disponible en Mac OS X v10.2 o posterior y ofrece a los programadores de Carbon una API más potente. A partir de Mac OS X v10.2 , HIObject es la clase base para todos los elementos de la GUI en Carbon. HIView es compatible con Interface Builder , parte de las herramientas para desarrolladores de Apple. Tradicionalmente, las arquitecturas de GUI de este tipo se han dejado en manos de frameworks de aplicaciones de terceros. A partir de Mac OS X v10.4, los HIObjects son NSObjects y heredan la capacidad de serializarse en flujos de datos para su transporte o guardado en disco.
  • HITheme utiliza QuickDraw y Quartz para mostrar los 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 que se ejecuta sobre HITheme desde esa versión.
  • Administrador de HIView : gestiona la creación, el dibujo, la detección de colisiones y la manipulación de controles. Desde Mac OS X v10.2, todos los controles son HIViews. En Mac OS X v10.4, el Administrador de controles pasó a llamarse Administrador de HIView.
  • Administrador de ventanas : gestiona la creación, el posicionamiento, la actualización y la manipulación de ventanas. Desde Mac OS X v10.2, las ventanas tienen una vista raíz HIView.
  • Administrador de menús : gestiona la creación, selección y manipulación de menús. Desde Mac OS X v10.2, los menús son HIObjects. Desde Mac OS X v10.3, el contenido de los menús se puede dibujar usando HIViews, y todos los menús estándar usan HIViews para dibujar.

Gestión de eventos

El Administrador de eventos de Mac Toolbox originalmente utilizaba un modelo de sondeo para el diseño de aplicaciones. El bucle principal de eventos 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 procesa; de lo contrario, regresa inmediatamente. Este comportamiento se denomina " espera activa " y ejecuta el bucle de eventos innecesariamente. La espera activa reduce el tiempo de CPU disponible para otras aplicaciones y disminuye la duración de la batería en las computadoras portátiles. El Administrador de eventos clásico data del Mac OS original de 1984, cuando se garantizaba que cualquier aplicación en ejecución fuera la única en ejecutarse y 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 al Administrador de eventos, WaitNextEvent , que permite a una aplicación especificar un intervalo de espera. Un truco sencillo para que el código heredado adopte un modelo más eficiente sin grandes cambios 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 espera 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 ser 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, hay lagunas. Por ejemplo, la llamada a la caja de herramientas heredada ModalDialog llama internamente a la función GetNextEvent anterior , lo que resulta en un sondeo en un bucle cerrado sin bloqueo.

Carbon introduce un sistema de reemplazo llamado Carbon Event Manager. (El Event Manager original aún existe para garantizar la compatibilidad con aplicaciones antiguas). Carbon Event Manager proporciona el bucle de eventos para el desarrollador (basado en el de Core Foundation CFRunLoopen la implementación actual); el desarrollador configura los manejadores de eventos, ingresa al bucle de eventos en la función principal y espera a que Carbon Event Manager envíe los eventos a la aplicación.

Temporizadores

En el Mac OS clásico, el sistema operativo no ofrecía soporte para temporizadores a nivel de aplicación (aunque sí estaba disponible el Administrador de tiempo, de nivel inferior, que ejecutaba las 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). La implementación de los temporizadores solía quedar a cargo de los desarrolladores de aplicaciones, quienes generalmente contaban el tiempo transcurrido durante el evento de inactividad , es decir, un evento devuelto por WaitNextEvent cuando no había ningún otro evento disponible. Para que dichos temporizadores tuvieran una resolución razonable, los desarrolladores no podían permitirse que WaitNextEvent se demorara demasiado, por lo que normalmente se establecían parámetros de "suspensión" bajos. Esto resultaba en un comportamiento de planificación muy ineficiente, ya que el hilo no se suspendía durante mucho tiempo, sino que se despertaba repetidamente para devolver estos eventos de inactividad. Apple añadió soporte para temporizadores a Carbon para solucionar este problema: el sistema puede planificar temporizadores con gran eficiencia.

Implementaciones de código abierto

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 el boro precede al carbono en la tabla periódica de los elementos . [ 12 ] Darling también contiene una implementación de Carbon. Ambas implementaciones están muy incompletas y consisten principalmente en funciones auxiliares.

Véase también

Referencias

  1. ↑ "Conceptos en programación Objective-C: Conexión gratuita" . developer.apple.com . 2012. Consultado el 8 de mayo de 2017 .
  2. ^ Siracusa, John (2000). "Actualización de Mac OS X: Quartz y Aqua" . archive.arstechnica.com . Consultado el 8 de mayo de 2017 .
  3. ↑ Krazit, Tom (17 de octubre de 2008). "Apple traslada Finder a Cocoa" . CNET . Archivado del original el 11 de julio de 2015. Consultado el 21 de mayo de 2015 .
  4. ↑ Apple Inc. "Introducción a la guía de 64 bits para desarrolladores de Carbon" . Archivado del original el 11 de junio de 2009.
  5. ↑ Apple Inc. "Cómo elegir una ruta de desarrollo para la interfaz de usuario de Carbon" . Modificación de la aplicación para usar direccionamiento de 64 bits . Archivado del original el 4 de agosto de 2009.
  6. ↑ Siracusa, John (3 de abril de 2008). "Rapsodia y blues" . Ars Technica . Consultado el 5 de febrero de 2023 .
  7. ↑ John Nack. "Photoshop, Lightroom y la hoja de ruta de Adobe para 64 bits" . Archivado del original el 14 de abril de 2015.
  8. ↑ Chris Foresman (3 de septiembre de 2010). "Primeras impresiones de iTunes 10: rendimiento más ágil, opciones de interfaz de usuario cuestionables" . Archivado del original el 2 de abril de 2015.
  9. ↑ John Siracusa (septiembre de 2009). "Mac OS X 10.6 Snow Leopard: la reseña de Ars Technica" . Archivado del original el 13 de julio de 2014.
  10. ↑ Apple Inc. (28 de junio de 2017). "Requisito de 64 bits para aplicaciones de Mac" . Archivado del original el 30 de enero de 2018. Consultado el 18 de febrero de 2018 .
  11. ↑ MacRumors (4 de junio de 2019). "Las aplicaciones de 32 bits 'no optimizadas para tu Mac' dejarán de funcionar en macOS Catalina" . Consultado el 10 de agosto de 2019 .
  12. ↑ "gnustep/libs-boron: El boro es el átomo que precede al carbono" . GitHub . GNUstep. 23 de marzo de 2019.
  • Biblioteca de referencia de Carbon (Apple Developer Connection) en Wayback Machine (archivada el 20 de abril de 2009)