Una bifurcación de recursos es una bifurcación de un archivo en el sistema operativo Mac OS clásico de Apple que se utiliza para almacenar datos estructurados. Es una de las dos bifurcaciones de un archivo, junto con la bifurcación de datos , que almacena datos que el sistema operativo trata como no estructurados. La capacidad de bifurcación de recursos se ha trasladado al sistema operativo macOS moderno para lograr compatibilidad.
Una bifurcación de recursos almacena información en un formato específico, que contiene detalles como mapas de bits de iconos, formas de ventanas, definiciones de menús y sus contenidos, y código de aplicación ( código de máquina ). Por ejemplo, un archivo de procesamiento de texto puede almacenar su texto en la bifurcación de datos, mientras que almacena cualquier imagen incrustada en la bifurcación de recursos del mismo archivo. La bifurcación de recursos se utiliza principalmente en ejecutables , pero cualquier archivo puede tener una bifurcación de recursos.
En una nota técnica de 1986, Apple recomendó enfáticamente que los desarrolladores no incluyan datos generales en la bifurcación de recursos de un archivo. Según Apple, hay partes del software del sistema que dependen de que las bifurcaciones de recursos contengan únicamente información válida del Administrador de recursos. [1]
La bifurcación de recursos fue concebida e implementada por el programador de Apple Bruce Horn .
La bifurcación de recursos tiene tres propósitos en los sistemas de archivos clásicos de Macintosh:
La bifurcación de recursos se implementa en todos los sistemas de archivos utilizados para las unidades del sistema en el sistema operativo Mac OS clásico ( MFS , HFS y HFS Plus ) y en el APFS exclusivo de macOS . La presencia de una bifurcación de recursos facilita el almacenamiento de una variedad de información adicional, como un ícono que el escritorio debe mostrar para ese archivo. Si bien la bifurcación de datos permite el acceso aleatorio a cualquier desplazamiento dentro de ella, el acceso a la bifurcación de recursos funciona como la extracción de registros estructurados de una base de datos . ( Microsoft Windows también tiene un concepto de " recursos ", pero estos no están relacionados en absoluto con los recursos en Mac OS).
Los sistemas de archivos de Macintosh almacenan metadatos distintos de la bifurcación de datos o recursos, como las marcas de tiempo de creación y modificación, el tipo de archivo y los códigos de creador, y las longitudes de las bifurcaciones.
Algunos archivos solo tienen una bifurcación de recursos. Un ejemplo es un archivo de fuentes en el sistema operativo Mac OS clásico. Otro ejemplo es una aplicación Classic 68k , donde incluso el código ejecutable está contenido en recursos de tipo 'CODE'. Los binarios posteriores de PowerPC almacenaban el código ejecutable en la bifurcación de datos.
Dado que las bifurcaciones de recursos solo se admitían en los sistemas de archivos de Macintosh, incluidos MFS, HFS, HFS Plus y APFS, no se podían copiar a los sistemas de archivos de otros sistemas operativos . Los formatos Mac BinHex y MacBinary se inventaron para codificar las bifurcaciones de recursos y datos en un solo archivo, para su transferencia entre sistemas. A/UX admitía bifurcaciones de recursos en sistemas de archivos Unix a través de los formatos AppleSingle y AppleDouble . A partir de Mac OS X Tiger , AppleDouble se utilizó para almacenar bifurcaciones de recursos en sistemas de archivos como recursos compartidos SMB de Windows y volúmenes FAT32 ( tabla de asignación de archivos ).
En el sistema de archivos HFS Plus, se pueden realizar configuraciones para permitir otras bifurcaciones además de las bifurcaciones de datos y recursos, para crear una aplicación "multi-bifurcación". [2]
A partir del 7 de agosto de 2002, Apple recomendó que los desarrolladores no crearan recursos en bifurcaciones de recursos en binarios Mach-O en Mac OS X. [3]
Cada recurso tiene un identificador OSType (un valor de cuatro bytes), un ID (una palabra con signo de 16 bits ) y un nombre opcional. Existen tipos de recursos estandarizados para cuadros de diálogo ( ), imágenes ( ), sonidos ( ) y binarios ejecutables ( ) que, hasta la llegada del procesador PowerPC , se almacenaban sin excepción en la bifurcación de recursos. Las subrutinas para representar ventanas se almacenan en su propio tipo de recursos ( ), y las subrutinas para representar menús en el suyo ( ). Esta disposición permitió a los usuarios personalizar fácilmente no solo las aplicaciones individuales sino también el propio sistema operativo, utilizando herramientas como ResEdit para modificar los recursos de un archivo de aplicación o cualquiera de los archivos del sistema.DITLPICTsnd CODE WDEFMDEF
Dentro de una aplicación u otro código, los recursos se pueden cargar simplemente utilizando una combinación de su tipo, ID o nombre, sin importar cómo y dónde se almacenan en la bifurcación de recursos. El cliente recibe un identificador del recurso cargado al que se puede acceder como a cualquier otro dato basado en el montón. El componente del sistema operativo que facilita esto es el Administrador de recursos. Además de abstraer los detalles del almacenamiento de datos de los datos, el Administrador de recursos también organiza conjuntos de bifurcaciones de recursos abiertas en una pila, con el archivo abierto más recientemente en la parte superior. Al intentar cargar un recurso, buscará primero en la parte superior de la pila (quizás la bifurcación de recursos del documento actual), luego en la siguiente hacia abajo (la bifurcación de recursos de la aplicación) y luego en la siguiente (bifurcaciones de recursos del sistema). Esta disposición es muy poderosa: permite que los recursos locales anulen a los más globales que se encuentran más abajo, de modo que una aplicación puede proporcionar sus propios íconos o fuentes en lugar de los estándares del sistema, por ejemplo. También permite que una aplicación cargue recursos del sistema utilizando la misma API que cualquier otro recurso, sin importar dónde o cómo se almacena ese recurso: para la aplicación, todos los recursos están igualmente disponibles y son fáciles de usar. El sistema reserva los identificadores de recursos en un rango determinado para ayudar a evitar conflictos de recursos que surjan de esto. Las API del administrador de recursos permiten al programador manipular la pila y modificar el comportamiento de búsqueda.
Como la bifurcación de recursos se puede editar con un editor de recursos como ResEdit , se puede utilizar para localizar y personalizar software . Además, la mayoría de los editores de recursos permiten la edición visual de datos. En macOS , es posible utilizar recursos al desarrollar una aplicación. Sin embargo, si es posible que la aplicación deba usarse en UFS , también es posible configurarla para que toda la bifurcación de recursos se mueva a la bifurcación de datos, utilizando la configuración de Archivo de recursos sin procesar [ cita requerida ] . Los entornos de desarrollo integrados distribuidos de forma gratuita por Apple Inc. , que incluyen MPW y Apple Developer's Tools , incluyen un compilador llamado Rez. Este utiliza un lenguaje dedicado, también llamado Rez, que se puede utilizar para crear una bifurcación de recursos compilando el código fuente . También se incluye un descompilador, DeRez, que se puede utilizar para cambiar una bifurcación de recursos de nuevo al código Rez.
En la estructura de la bifurcación de recursos, hay un fragmento de datos llamado "mapa de recursos" que almacena las posiciones de los elementos de datos de recursos. Esto se puede utilizar para permitir el acceso aleatorio a los datos de recursos en función de los identificadores y nombres definidos. Se puede pensar que la bifurcación de recursos consta esencialmente de dos objetos, el mapa de recursos y los datos de recursos en sí, pero, de hecho, cada tipo de datos es una estructura jerárquica que almacena varios elementos de datos. El formato en el que se almacena la información de los datos de recursos se define en función de los tipos de información, que se conocen como "tipos de recursos". Los datos de recursos a menudo hacen referencia a otros tipos de datos.
En macOS, las bifurcaciones se denominan archivo /..namedfork/ forkname , p. ej ., la bifurcación de recursos del archivo IMG_0593.jpg es IMG_0593.jpg/..namedfork/rsrc. El lscomando admite una -l@opción que enumera las bifurcaciones de un archivo.
Las bifurcaciones de recursos aparecen como el atributo extendido com.apple.ResourceFork. [4]
Anteriormente, se accedía a las bifurcaciones de recursos a través de la API "Administrador de recursos" . Esta API ahora está obsoleta. [5]
Bajo la API obsoleta:
Las API del administrador de archivos también PBOpenRF()permiten el acceso a la bifurcación de recursos sin procesar; sin embargo, deben usarse solo para aplicaciones como copiar un archivo: Apple advierte enérgicamente contra el uso de la bifurcación de recursos como una "segunda bifurcación de datos".
Desde la interfaz POSIX , se podía acceder a la bifurcación de recursos como filename/..namedfork/rsrco como filename/rsrc; la forma más corta quedó obsoleta en Mac OS X v10.4 y se eliminó por completo en Mac OS X v10.7 . [6]
Los elementos más pequeños que componen una bifurcación de recursos se denominan tipos de datos. Existen varios tipos de datos. Después de acceder a una bifurcación de recursos, se puede encontrar su contenido leyéndolo según los tipos de datos definidos de antemano. Colocar definiciones dentro del programa que indiquen cómo se deben tratar los datos también permite almacenar recursos llamados recursos TMPL. El uso de este método aumenta la visibilidad de los datos cuando se visualizan con un programa como ResEdit, lo que hace que la edición posterior sea más sencilla. Como la plataforma Macintosh se originó con procesadores basados en Motorola (68k y PPC), los datos se serializan en el disco en formato big-endian .
La siguiente es una lista de los principales tipos de datos, en orden alfabético.
Los códigos de tipo a continuación, al igual que los tipos de datos anteriores, se utilizan como identificadores de tipo para más que las bifurcaciones de recursos en sí: se utilizan para identificar los archivos en sí, para describir datos en el portapapeles y mucho más.
Los tipos deben tener 4 bytes de longitud, por lo que tipos como snd y STR en realidad tienen un espacio (0x20) al final.
La complejidad de la programación con bifurcaciones de recursos ha llevado a problemas de compatibilidad al acceder a otros sistemas de archivos a través de protocolos de uso compartido de archivos como AFP , SMB , NFS y FTP , al almacenar en volúmenes que no sean HFS o al transmitir archivos a otros sistemas de otras formas (como por correo electrónico). El protocolo AFP admite de forma nativa las bifurcaciones de recursos, por lo que las bifurcaciones de recursos generalmente se transmiten a estos volúmenes tal como están y el servidor las almacena de forma transparente para los clientes. El protocolo SMB admite un sistema de metadatos de archivos similar a las bifurcaciones de Macintosh conocidas como secuencias de datos alternativas (ADSes en adelante). macOS no admitía el almacenamiento de bifurcaciones de recursos en ADSes en volúmenes SMB de forma predeterminada hasta Mac OS X v10.6 . En versiones anteriores del sistema operativo, incluidas las versiones actualizadas de 10.6, esta función se puede habilitar con un cambio de parámetro o creando un archivo especial. [9]
Los protocolos de intercambio de archivos en red, como NFSv3 y FTP, no tienen un concepto de metadatos de archivo, por lo que no hay forma de almacenar de forma nativa las bifurcaciones de recursos. Esto también es cierto cuando se escribe en ciertos tipos de sistemas de archivos locales, incluido UFS, y en volúmenes SMB donde no está habilitada la compatibilidad con flujo de datos alternativo. En esos casos, macOS almacena metadatos y bifurcaciones de recursos mediante una técnica llamada AppleDouble , en la que la bifurcación de datos se escribe como un solo archivo, y la bifurcación de recursos y los metadatos se escriben como un archivo completamente separado precedido por una convención de nombres "._". Por ejemplo: ExampleFile.psd contendría la bifurcación de datos y ._ExampleFile.psd contendría la bifurcación de recursos y los metadatos.
Pueden surgir problemas de compatibilidad porque macOS manejará el almacenamiento de las bifurcaciones de recursos de manera diferente, según la versión de macOS, la configuración y el tipo de sistema de archivos. Por ejemplo, en una red SMB con una combinación de clientes 10.5 y 10.6. Un cliente 10.6 recién instalado buscará y almacenará las bifurcaciones de recursos en un volumen SMB en ADS, pero el cliente 10.5 ignorará (de manera predeterminada) los ADS y usará el formato AppleDouble para manejar las bifurcaciones. Si un servidor de archivos admite AFP y NFS, los clientes que usen NFS almacenarán los archivos en formato AppleDouble , mientras que los usuarios de AFP almacenarán la bifurcación de recursos de forma nativa. En esos casos, a veces se puede mantener la compatibilidad al obligar a los clientes a usar, o no, el formato AppleDouble .
Muchos servidores de archivos que ofrecen compatibilidad con AFP no admiten de forma nativa bifurcaciones de recursos en sus sistemas de archivos locales. En esos casos, las bifurcaciones pueden almacenarse de formas especiales, como archivos con nombres especiales, directorios especiales o incluso secuencias de datos alternativas.
Otro desafío es preservar las bifurcaciones de recursos al transmitir archivos mediante aplicaciones que no las tienen en cuenta o con ciertos métodos de transferencia, incluidos el correo electrónico y el FTP. Se han creado varios formatos de archivo, como MacBinary y BinHexSplitForks , para manejar esto. Las herramientas del sistema de línea de comandos permiten FixupResourceForksla combinación y el aplanamiento manual de las bifurcaciones de recursos. Además, un servidor de archivos que busca presentar sistemas de archivos a clientes Macintosh debe acomodar la bifurcación de recursos así como la bifurcación de datos de los archivos; los servidores UNIX que brindan soporte AFP generalmente implementan esto con directorios ocultos.
Las aplicaciones antiguas escritas con la API Carbon tienen un problema potencial al ser trasladadas a las Mac Intel actuales . Si bien el Administrador de recursos y el sistema operativo saben cómo deserializar datos correctamente para recursos comunes como ' snd ' o ' moov', los recursos creados con recursos TMPL deben intercambiarse manualmente para garantizar la interoperabilidad de archivos entre PPC y las versiones basadas en Intel de una aplicación. (Si bien el mapa de recursos y otros detalles de implementación son big-endian , el Administrador de recursos por sí solo no tiene ningún conocimiento del contenido de un recurso genérico y, por lo tanto, no puede realizar el intercambio de bytes automáticamente).
Hasta la llegada de Mac OS X v10.4 , las utilidades de línea de comandos estándar de UNIX en macOS (como cpy mv) no respetaban las bifurcaciones de recursos. Para copiar archivos con bifurcaciones de recursos, había que usar dittoo CpMac y MvMac.
El concepto de un administrador de recursos para objetos gráficos, para ahorrar memoria, se originó en el paquete OOZE en Xerox Alto en Smalltalk-76. [10] El concepto es ahora en gran medida universal en todos los sistemas operativos modernos. Sin embargo, el concepto de la bifurcación de recursos sigue siendo peculiar de Macintosh. La mayoría de los sistemas operativos usaban un archivo binario que contenía recursos, que luego se "adjuntaba" al final de un archivo de programa existente. Esta solución se usa en Microsoft Windows , por ejemplo, y se usan soluciones similares con X Window System , aunque los recursos a menudo se dejan como un archivo separado.
El sistema NTFS de Windows NT puede admitir bifurcaciones (y, por lo tanto, puede ser un servidor de archivos para archivos de Mac); la característica nativa que proporciona esa compatibilidad se denomina flujo de datos alternativo . Las características del sistema operativo Windows (como la pestaña Resumen estándar en la página Propiedades para archivos que no son de Office) y las aplicaciones de Windows las utilizan, y Microsoft estaba desarrollando un sistema de archivos de próxima generación que tiene este tipo de característica como base.
Las primeras versiones de BeOS implementaron una base de datos dentro del sistema de archivos, que podía usarse de manera análoga a una bifurcación de recursos. Los problemas de rendimiento llevaron a un cambio en versiones posteriores a un sistema de atributos de sistema de archivos complejos. Bajo este sistema, los recursos se manejaban de una manera algo más análoga a Mac.
AmigaOS no utiliza archivos bifurcados. Sus archivos ejecutables están divididos internamente en una estructura modular de grandes piezas ( hunk ) capaces de almacenar código, datos e información adicional. De manera similar, los archivos de datos y de proyecto tienen una estructura de trozos codificada en el estándar IFF . Otros tipos de archivos se almacenan de manera similar a otros sistemas operativos. Aunque no es estrictamente una bifurcación de recursos, AmigaOS almacena metadatos en archivos conocidos como .infoarchivos. .infoLos archivos se pueden identificar por la .infoextensión; por ejemplo, si guarda un proyecto en un disco, se guardarán dos archivos, MyProjecty MyProject.info. MyProjectserían los datos reales del proyecto y MyProject.infocontendrían el ícono del proyecto, información sobre qué programa se necesita para abrir el proyecto (ya que no hay enlace de aplicaciones en AmigaOS), opciones especiales del proyecto y cualquier comentario del usuario. .infoLos archivos son invisibles en el escritorio de Amiga ( Workbench ). El ícono en el escritorio, tomado del .infopropio, es la metáfora de la interfaz a través de la cual el usuario interactúa tanto con el proyecto en sí como con su .infoarchivo asociado. Un cuadro de diálogo accesible haciendo clic derecho en el ícono permite al usuario ver y modificar los metadatos presentes en el .infoarchivo. .infoLos archivos se pueden ver como archivos individuales en la interfaz de línea de comandos o en un Administrador de archivos . Los clones modernos de AmigaOS ( AROS , MorphOS y AOS4 ) heredan la estructura (completa con metadatos) de los .infoarchivos de versiones anteriores de AmigaOS y también pueden aceptar archivos gráficos PNG.info estándar como mapas de bits de iconos en sus archivos.
Sistemas operativos NeXT NeXTSTEP y OPENSTEP , su sucesor, macOS , y otros sistemas como RISC OS implementaron otra solución. Bajo estos sistemas, los recursos se dejan en un formato original, por ejemplo, las imágenes se incluyen como archivos TIFF completos en lugar de estar codificadas en algún tipo de contenedor. Estos recursos luego se colocan en un directorio junto con el código ejecutable y los "datos sin procesar". El directorio (llamado " paquete " o " directorio de aplicación ") luego se presenta al usuario como la aplicación en sí. Esta solución proporciona la misma funcionalidad que la bifurcación de recursos, pero permite que los recursos sean manipulados fácilmente por cualquier aplicación: no se necesita un "editor de recursos" (como ResEdit ). Desde la interfaz de línea de comandos, el paquete parece ser un directorio normal. Este enfoque no era una opción en el Mac OS clásico , ya que el sistema de archivos ( MFS ) no admitía directorios de catálogo separados. Cuando se incluyó la compatibilidad con archivos de catálogo en Mac OS, con el sistema de archivos HFS, se mantuvo la bifurcación de recursos. macOS conserva la API clásica del Administrador de recursos como parte de sus bibliotecas Carbon para lograr compatibilidad con versiones anteriores. Sin embargo, los recursos en sí ahora se pueden almacenar en archivos de datos separados dentro del sistema de archivos; el Administrador de recursos ahora oculta este cambio de implementación del código del cliente.