Una bifurcación de recursos es una bifurcación de un archivo en el sistema operativo macOS 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.
Una bifurcación de recursos almacena información en una forma específica, que contiene detalles como mapas de bits de iconos, las formas de las ventanas, definiciones de menús y su contenido, y código de aplicación (código de máquina ). Por ejemplo, un archivo de procesamiento de textos puede almacenar su texto en la bifurcación de datos, mientras almacena las imágenes incrustadas en la bifurcación de recursos del mismo archivo. La bifurcación de recursos la utilizan principalmente los ejecutables , pero cualquier archivo puede tener una bifurcación de recursos.
En una nota técnica de 1986, Apple recomendó encarecidamente que los desarrolladores no colocaran datos generales en la bifurcación de recursos de un archivo. Según Apple, hay partes del software del sistema que dependen de bifurcaciones de recursos que solo contienen 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 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 debería mostrar el escritorio para ese archivo. Si bien la bifurcación de datos permite el acceso aleatorio a cualquier compensación dentro de ella, el acceso a la bifurcación de recursos funciona como extraer registros estructurados de una base de datos . ( Microsoft Windows también tiene un concepto de " recursos ", pero estos no tienen ninguna relación con los recursos de Mac OS).
Los sistemas de archivos de Macintosh almacenan metadatos distintos de la bifurcación de datos o de 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 la bifurcación.
Algunos archivos sólo tienen una bifurcación de recursos. Un ejemplo es un archivo de fuente en el 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 almacenaron el código ejecutable en la bifurcación de datos.
Dado que las bifurcaciones de recursos solo eran compatibles con 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 bifurcaciones de recursos y datos en un solo archivo, para su transferencia entre sistemas. A/UX admitió 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 que otras bifurcaciones, además de las bifurcaciones de datos y recursos, creen una aplicación "multibifurcación". [2]
El 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 de 16 bits con signo ) 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 renderizar ventanas se almacenan en su propio tipo de recursos ( ), y las subrutinas para renderizar menús en los suyos ( ). Esta disposición permitió a los usuarios personalizar fácilmente no solo 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 usando una combinación de su tipo, ID o nombre, sin tener en cuenta cómo y dónde se almacenan en la bifurcación de recursos. Al cliente se le devuelve un identificador para el recurso cargado al que luego se puede acceder como 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 abiertos 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 el siguiente hacia abajo (la bifurcación de recursos de la aplicación) y luego el siguiente (bifurcaciones de recursos del sistema). Esta disposición es muy poderosa: permite que los recursos locales anulen los más globales en el nivel inferior, por lo que una aplicación puede proporcionar sus propios íconos o fuentes en lugar de los estándar del sistema, por ejemplo. También permite que una aplicación cargue recursos desde el sistema usando la misma API que cualquier otro recurso, sin importar dónde o cómo se almacene ese recurso; para la aplicación, todos los recursos están igualmente disponibles y son fáciles de usar. El sistema reserva ID de recursos en un rango determinado para ayudar a evitar conflictos de recursos que surjan de esto. Las API de Resource Manager 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 sea necesario utilizar la aplicación 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 Archivo de recursos sin formato [ cita requerida ] . Los entornos de desarrollo integrados distribuidos gratuitamente por Apple Inc. , que incluyen MPW y Apple Developer's Tools , incluyen un compilador llamado Rez. Esto utiliza un lenguaje dedicado, también llamado Rez, que se puede usar para crear una bifurcación de recursos mediante la compilación del código fuente . También se incluye un descompilador, DeRez, que se puede utilizar para volver a convertir una bifurcación de recursos en código Rez.
En la estructura de la bifurcación de recursos, hay un dato 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 ID y nombres definidos. Se puede considerar que la bifurcación de recursos consta esencialmente de dos objetos, el mapa de recursos y los datos del recurso en sí, pero en realidad cada tipo de datos es una estructura jerárquica que almacena múltiples 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 referencias a otros tipos de datos.
En macOS, las bifurcaciones se denominan archivo /..namedfork/ forkname , por ejemplo , 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á en desuso. [5]
Bajo la API obsoleta:
Las API del administrador de archivos, como las que PBOpenRF()también permitían el acceso a la bifurcación de recursos sin formato; sin embargo, deben usarse sólo para aplicaciones como copiar un archivo; Apple advierte enfáticamente contra el uso de la bifurcación de recursos como una "segunda bifurcación de datos".
Desde la interfaz POSIX , se puede 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. Hay varios tipos de datos. Después de acceder a una bifurcación de recursos, su contenido se puede encontrar leyéndolo según corresponda para 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 ven con un programa como ResEdit, simplificando la edición posterior. 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 siguientes, al igual que los tipos de datos anteriores, se utilizan como identificadores de tipo para algo 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 generado problemas de compatibilidad al acceder a otros sistemas de archivos a través de protocolos de intercambio de archivos como AFP , SMB , NFS y FTP , al almacenar en volúmenes que no son HFS o al transmitir archivos a otros sistemas de otras maneras ( 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 Flujos de datos alternativos (ADS en adelante). macOS no admitía el almacenamiento de bifurcaciones de recursos en ADS 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 archivos y, por lo tanto, no hay forma de almacenar bifurcaciones de recursos de forma nativa. Esto también se aplica al escribir en ciertos tipos de sistemas de archivos locales, incluido UFS, y en volúmenes SMB donde la compatibilidad con flujo de datos alternativo no está habilitada. 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 archivo, y la bifurcación de recursos y los metadatos se escriben como un archivo completamente separado precedido por una convención de nomenclatura "._". Por ejemplo: EjemploFile.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 bifurcaciones de recursos de manera diferente, según la versión, la configuración y el tipo de sistema de archivos de macOS. Por ejemplo, en una red SMB con una combinación de 10,5 y 10,6 clientes. Un cliente 10.6 recién instalado buscará y almacenará bifurcaciones de recursos en un volumen SMB en ADS, pero el cliente 10.5 (de forma predeterminada) ignorará los ADS y utilizará el formato AppleDouble para manejar las bifurcaciones. Si un servidor de archivos admite tanto AFP como NFS, los clientes que utilicen 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, la compatibilidad a veces se puede mantener obligando a los clientes a usar o no el formato AppleDouble .
Muchos servidores de archivos que brindan soporte 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 flujos de datos alternativos.
Otro desafío es preservar las bifurcaciones de recursos al transmitir archivos utilizando aplicaciones que no admiten bifurcaciones de recursos o con ciertos métodos de transferencia, incluidos el correo electrónico y FTP. Se han creado varios formatos de archivo, como MacBinary y BinHex , para manejar esto. Herramientas del sistema de línea de comandos SplitForksy FixupResourceForkspermiten el aplanamiento y la fusión manual de 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 más antiguas escritas con Carbon API tienen un problema potencial al migrarse 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 usando recursos TMPL deben intercambiarse manualmente para garantizar la interoperabilidad de archivos entre PPC y las versiones de una aplicación basadas en Intel. (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 dittoCpMac y MvMac.
El concepto de 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 bifurcación de recursos sigue siendo peculiar de Macintosh. La mayoría de los sistemas operativos utilizan un archivo binario que contiene recursos, que luego se "pega" al final de un archivo de programa existente. Esta solución se usa en Microsoft Windows, por ejemplo, y se usan soluciones similares con el sistema X Window , aunque los recursos a menudo se dejan como un archivo separado.
El NTFS de Windows NT puede admitir bifurcaciones (y por lo tanto puede ser un servidor de archivos para archivos Mac); la característica nativa que proporciona ese soporte se llama 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 usan 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 podrí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 la 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 proyectos tienen una estructura fragmentada 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 aplicación en AmigaOS), opciones especiales del proyecto y cualquier comentario del usuario. .infoLos archivos son invisibles en el escritorio de Amiga ( Workbench ). El icono del escritorio, extraído del .infopropio, es la metáfora de la interfaz.info a través de la cual el usuario interactúa tanto con el propio proyecto como con su archivo asociado . Un cuadro de diálogo al que se puede acceder haciendo clic derecho en el icono 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 estándar como mapas de bits de iconos en sus .infoarchivos.
Los sistemas operativos NeXT NeXTSTEP y OPENSTEP , su sucesor, macOS , y otros sistemas como RISC OS implementaron otra solución. En estos sistemas, los recursos se dejan en un formato original; por ejemplo, las imágenes se incluyen como archivos TIFF completos en lugar de codificarse en algún tipo de contenedor. Luego, estos recursos 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 ") se presenta al usuario como la aplicación misma. Esta solución proporciona la misma funcionalidad que la bifurcación de recursos, pero permite que cualquier aplicación manipule fácilmente los recursos; 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 de Resource Manager como parte de sus bibliotecas Carbon para compatibilidad con versiones anteriores. Sin embargo, los recursos mismos 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.