En el sistema operativo Mac OS clásico (el sistema operativo original de Apple Macintosh ), las extensiones eran pequeños fragmentos de código que ampliaban la funcionalidad del sistema. Se ejecutaban inicialmente en el momento del arranque y se operaban mediante una variedad de mecanismos, incluidos los parches de trampa y otras técnicas de modificación de código. Inicialmente, las extensiones eran un truco de los desarrolladores de Apple, pero se convirtieron en la forma estándar de proporcionar un sistema operativo modular. Una gran cantidad de servicios importantes del sistema, como las pilas de red TCP/IP (MacTCP y Open Transport) y la compatibilidad con USB y FireWire, eran componentes opcionales implementados como extensiones. La frase "extensión del sistema" más tarde llegó a abarcar también las aplicaciones en segundo plano sin rostro.
Las extensiones generalmente cumplían la misma función que los programas residentes de DOS o los daemons de Unix , aunque al parchar el código del SO subyacente, tenían la capacidad de modificar el comportamiento del SO existente, los otros dos no. [ dudoso – discutir ]
El concepto de extensiones no estaba presente en el software del sistema Macintosh original, pero el sistema tenía un mecanismo de parcheo privado que los desarrolladores pronto aprendieron a aprovechar: el cargador INIT. Este código buscaría recursos del sistema de tipo 'INIT' y los cargaría y ejecutaría en el momento del arranque. Los recursos del código tenían que almacenarse directamente en la bifurcación de recursos de la maleta del sistema Mac , lo que significa que solo estaba realmente disponible para "usuarios avanzados" que se sintieran cómodos usando ResEdit u otro editor de recursos.
Como aprovechar este mecanismo era un truco sin soporte, y solo se podían cargar 32 INIT de esta manera, Apple respondió proporcionando una solución más administrada. Inicialmente, esto mismo tenía la forma de un recurso 'INIT' con ID 31 colocado en el archivo del sistema que buscaría más archivos de tipo 'INIT' en la carpeta del sistema , y cargaría y ejecutaría recursos INIT dentro de ellos. (Esta es la razón por la que algunos programadores veteranos de Mac todavía se refieren al mecanismo de carga de extensiones como el "truco INIT 31"). [1] Los INIT ahora se podían instalar simplemente colocando un archivo en la carpeta del sistema, dentro de las capacidades del usuario promedio. A partir del sistema 7, las extensiones se reubicaron en la carpeta Extensiones dentro de la carpeta del sistema para mayor comodidad, y se implementó un mecanismo de enrutamiento automático para que colocar una extensión en la carpeta del sistema mediante arrastrar y soltar realmente colocara el archivo en la subcarpeta apropiada.
Las extensiones conservaron el tipo de recurso 'INIT' durante toda su vida útil, y el cargador se mejoró gradualmente para buscar estos recursos en numerosos lugares, incluso en las bifurcaciones de recursos de los paneles de control en una variedad de formatos y el Selector .
Los INIT evolucionaron hasta convertirse en extensiones del sistema, y fueron adquiriendo protocolos ad hoc adicionales a lo largo del camino, como el suministro de un icono para que se mostrara en el momento del arranque (el origen de esto fue "ShowINIT"). El "desfile de piezas de rompecabezas e iconos" en la pantalla a medida que se cargaba cada extensión se volvió familiar para todos los usuarios de Mac. La propia Apple finalmente lanzó piezas importantes (pero opcionales) del sistema operativo como extensiones, como QuickTime , QuickDraw 3D y muchas otras. Una cantidad sustancial de servicios y controladores en Mac OS, tanto oficiales como de terceros, se proporcionaron como extensiones, lo que permitió que el sistema operativo se redujera al deshabilitarlos.
Las extensiones del sistema eran una fuente común de inestabilidad en Macintosh, ya que el código de terceros era de calidad variable y a menudo aplicaba parches al sistema de maneras que no siempre funcionaban correctamente. Algunas extensiones no funcionaban correctamente juntas o solo funcionaban cuando se cargaban en un orden particular. Además, diferentes extensiones podían intentar aplicar parches a la misma parte del sistema, lo que podía provocar conflictos entre extensiones y otros tipos de inestabilidad. Rastrear estas fuentes de problemas era otra tarea con la que se encontraban la mayoría de los usuarios de Mac en algún momento. La solución de problemas con las extensiones de Mac OS podía ser un proceso que consumía mucho tiempo, que consistía en dividirlas en dos partes y realizar pruebas y errores .
La forma más sencilla de iniciar el sistema operativo desde cero era mantener presionada la tecla Shift: así se evitaba la carga de extensiones. El sistema 7.5 agregó el Administrador de extensiones , que permitía al usuario habilitar o deshabilitar rápidamente extensiones específicas y también definir conjuntos de ellas que funcionaran correctamente juntas. El Administrador de extensiones venía con dos conjuntos básicos de solo lectura: uno que contenía el subconjunto de extensiones necesarias para el funcionamiento básico del sistema operativo y otro que habilitaba todas las extensiones oficiales que venían con el sistema operativo pero deshabilitaba todas las extensiones de terceros.
El orden de carga de las extensiones era un efecto secundario de la función GetFInfo que utilizaba el cargador para enumerar los archivos en la carpeta Extension. Aunque Apple siempre ha dicho que el orden que resulta de la enumeración de archivos mediante esta función no está definido, en los volúmenes HFS esta función enumeraba los archivos en el orden en que estaban almacenados en el catálogo HFS. La gente se dio cuenta de que cambiar el primer carácter del nombre del archivo podía cambiar el orden de carga de las extensiones, lo que causó problemas cuando Mac OS 8.1 pasó a HFS+. Apple terminó teniendo que cambiar el cargador para ordenar los nombres de archivo devueltos por esta función en una tabla, y proporcionó una interfaz para permitir que el software cambiara la tabla. [2]
Las extensiones del sistema no tenían interfaz de usuario: no existía un mecanismo estándar mediante el cual el usuario pudiera configurar los servicios que proporcionaba una extensión. Las extensiones podían alterar la interfaz gráfica (como agregar nuevos menús a la barra de menús) y, por lo tanto, aceptar la configuración del usuario, o podían estar acompañadas por una aplicación para proporcionar la interfaz de configuración.
Con System 7 , los paneles de control se convirtieron en complementos independientes del Finder en el disco que el usuario podía iniciar. Al insertar el código INIT en un panel de control, se hizo posible crear híbridos de extensión/panel de control que modificaban el sistema operativo en el momento del arranque y contenían su propia interfaz de configuración incorporada en la misma forma que cualquier otro panel de control del sistema operativo.
MultiFinder y System 7 y posteriores admitían aplicaciones en segundo plano sin rostro similares a los daemons de UNIX o Windows Services , aunque utilizando multitarea cooperativa . Los ejemplos incluían Time Synchronizer ( ajuste del horario de verano y sincronización horaria remota), Software Update Scheduler y Folder Actions (manejo de eventos de carpeta). Las aplicaciones en segundo plano sin rostro eran aplicaciones normales con la restricción de que no aparecían en el menú de aplicaciones. Las únicas diferencias técnicas entre una aplicación en segundo plano sin rostro y una aplicación normal eran que la bandera "Solo en segundo plano" estaba establecida en el SIZErecurso ' '. Se les prohibía abrir una ventana normal a nivel de aplicación: si lo hacían, el sistema se congelaba.
Sin embargo, tenían libertad para abrir ventanas flotantes globales, ya que estas no podían ganar ni perder el foco. La barra de control de Mac OS 8 y 9 era un ejemplo de una aplicación de fondo sin rostro que mostraba una ventana flotante global para proporcionar interacción al usuario. El selector de aplicaciones era otro. Sin embargo, el usuario no era consciente en ningún momento de que la barra de control era un proceso en ejecución; simplemente se presentaba como una función de interfaz adicional. El sistema simplemente describía las aplicaciones de fondo sin rostro como "aplicaciones del sistema". [ cita requerida ]
Las características del lenguaje en la arquitectura Open Scripting Architecture (y por lo tanto AppleScript ) se implementaron inicialmente como complementos cargables dinámicamente, conocidos como "adiciones de scripting" u OSAXes. En Mac OS 8 y 9, se complementaron con aplicaciones en segundo plano sin interfaz gráfica que se cargaban en segundo plano a pedido. Al igual que con las aplicaciones normales, se accedía a estas aplicaciones mediante tellcláusulas: el espacio de nombres global no se actualizaba como sucedía con los OSAXes. El sistema operativo no indicaba el lanzamiento de dichos procesos ni indicaba si se estaban ejecutando o no.
Las extensiones de tipo INIT se cargaban en el momento del arranque para actualizar el sistema operativo. Resulta confuso que también se pudieran colocar otros archivos en la carpeta Extensiones, muchos de los cuales no se cargaban en el momento del arranque. Los más notables de estos archivos eran las bibliotecas compartidas , que normalmente se colocaban en la carpeta Extensiones para facilitar su ubicación. Las bibliotecas compartidas no se cargaban en el momento del arranque.
Los archivos de tipo INIT no eran el único tipo de extensión del sistema. Otro tipo era scri , o extensión WorldScript. El cargador de arranque BootX para Linux se implementó como scri simplemente porque dichos archivos se cargaban muy temprano en el proceso de arranque, antes que todas las demás extensiones. BootX podía entonces mostrar un cuadro de diálogo que ofreciera al usuario la opción de terminar de arrancar Mac OS o cargar Linux en su lugar.