Ресурсная вилка — это вилка файла в классической операционной системе Mac OS от Apple , которая используется для хранения структурированных данных. Это одна из двух вилок файла, наряду с вилкой данных , которая хранит данные, которые операционная система рассматривает как неструктурированные. Возможность ресурсной вилки была перенесена в современную macOS для совместимости.
Ресурсная ветка хранит информацию в определенной форме, содержащую такие детали, как битовые карты значков, формы окон, определения меню и их содержимого, а также код приложения ( машинный код ). Например, файл текстового процессора может хранить свой текст в ветке данных, в то время как любые встроенные изображения хранятся в ресурсной ветке того же файла. Ресурсная ветка используется в основном исполняемыми файлами , но любой файл может иметь ресурсную ветку.
В технической заметке 1986 года Apple настоятельно рекомендовала разработчикам не помещать общие данные в ресурсную ветку файла. По словам Apple, существуют части системного программного обеспечения, которые полагаются на ресурсные ветки, имеющие в себе только действительную информацию Resource Manager. [1]
Форк ресурсов был задуман и реализован программистом Apple Брюсом Хорном .
В классических файловых системах Macintosh вилка ресурсов имеет три цели:
Вилка ресурсов реализована во всех файловых системах, используемых для системных дисков в классической Mac OS ( MFS , HFS и HFS Plus ), а также в APFS только для macOS . Наличие вилки ресурсов упрощает хранение различной дополнительной информации, такой как значок , который должен отображаться на рабочем столе для этого файла. В то время как вилка данных обеспечивает произвольный доступ к любому смещению внутри нее, доступ к вилке ресурсов работает как извлечение структурированных записей из базы данных . ( Microsoft Windows также имеет концепцию « ресурсов », но они совершенно не связаны с ресурсами в Mac OS.)
Файловые системы Macintosh хранят метаданные, отличные от данных или ветви ресурсов, такие как метки времени создания и изменения, тип файла и коды создателя, а также длины ветвей.
Некоторые файлы имеют только ресурсную вилку. Одним из примеров является файл шрифта в классической Mac OS. Другим примером является приложение Classic 68k , где даже исполняемый код содержится в ресурсах типа «CODE». Более поздние двоичные файлы PowerPC сохраняли исполняемый код в вилке данных.
Поскольку вилки ресурсов поддерживались только в файловых системах Macintosh, включая MFS, HFS, HFS Plus и APFS, их нельзя было скопировать в файловые системы других операционных систем . Форматы Mac BinHex и MacBinary были изобретены для кодирования вилок ресурсов и данных в один файл для передачи между системами. A/UX поддерживал вилки ресурсов в файловых системах Unix через форматы AppleSingle и AppleDouble . Начиная с Mac OS X Tiger , AppleDouble использовался для хранения вилок ресурсов в файловых системах, таких как общие папки Windows SMB и тома FAT32 ( таблица размещения файлов ).
В файловой системе HFS Plus можно настроить параметры, позволяющие использовать другие форки в дополнение к форкам данных и ресурсов, чтобы создать приложение «мультифорк». [2]
По состоянию на 7 августа 2002 года Apple рекомендовала разработчикам не встраивать ресурсы в форки ресурсов в двоичных файлах Mach-O на Mac OS X. [3]
Каждый ресурс имеет идентификатор OSType (четырехбайтовое значение), идентификатор ( знаковое 16-битное слово ) и необязательное имя. Существуют стандартизированные типы ресурсов для диалоговых окон ( DITL), изображений ( PICT), звуков ( snd ) и исполняемых двоичных файлов ( CODE), которые до появления процессора PowerPC без исключения хранились в ветви ресурсов. Подпрограммы для рендеринга окон хранятся в своем собственном типе ресурсов ( ), а подпрограммы для рендеринга меню — в своем ( ). Такое расположение позволило пользователям легко настраивать не только отдельные приложения, но и саму операционную систему, используя такие инструменты, как ResEdit, для изменения ресурсов файла приложения или любого из системных файлов.WDEFMDEF
В приложении или другом коде ресурсы можно загружать просто с помощью комбинации их типа, идентификатора или имени, независимо от того, как и где они хранятся в ветви ресурсов. Клиенту возвращается дескриптор загруженного ресурса, к которому затем можно получить доступ, как к любым другим данным на основе кучи. Компонент ОС, который облегчает это, — это диспетчер ресурсов. Помимо абстрагирования деталей хранилища данных от данных, диспетчер ресурсов также упорядочивает наборы открытых ветвей ресурсов в стек, с последним открытым файлом наверху. При попытке загрузить ресурс он сначала будет искать в верхней части стека (возможно, ветви ресурсов текущего документа), затем в следующей ниже (ветви ресурсов приложения), затем в следующей (ветви ресурсов системы). Такая организация очень мощная — она позволяет локальным ресурсам переопределять более глобальные ниже — поэтому приложение может предоставлять свои собственные значки или шрифты вместо стандартных системных, например. Он также позволяет приложению загружать ресурсы из системы, используя тот же API, что и любой другой ресурс, независимо от того, где или как этот ресурс хранится — для приложения все ресурсы одинаково доступны и просты в использовании. Система резервирует идентификаторы ресурсов в определенном диапазоне, чтобы помочь избежать конфликтов ресурсов, возникающих из-за этого. API-интерфейсы диспетчера ресурсов позволяют программисту манипулировать стеком и изменять поведение поиска.
Поскольку вилку ресурсов можно редактировать с помощью редактора ресурсов, такого как ResEdit , ее можно использовать для локализации и настройки программного обеспечения . Кроме того, большинство редакторов ресурсов позволяют визуально редактировать данные. В macOS можно использовать ресурсы при разработке приложения. Однако, если приложение может потребоваться использовать в UFS , его также можно настроить так, чтобы вся вилка ресурсов была перемещена в вилку данных, используя настройку Raw Resource File [ необходима цитата ] . Интегрированные среды разработки, распространяемые бесплатно Apple Inc. , включающие MPW и Apple Developer's Tools , включают компилятор Rez. Он использует специальный язык, также называемый Rez, который можно использовать для создания вилки ресурсов путем компиляции исходного кода . Также включен декомпилятор DeRez, который можно использовать для изменения вилки ресурсов обратно в код Rez.
В структуре вилки ресурсов есть фрагмент данных, называемый «картой ресурсов», который хранит позиции элементов данных ресурсов. Это может быть использовано для обеспечения произвольного доступа к данным ресурсов на основе определенных идентификаторов и имен. Вилку ресурсов можно рассматривать как состоящую из двух объектов, карты ресурсов и самих данных ресурсов, но на самом деле каждый тип данных представляет собой иерархическую структуру, которая хранит несколько элементов данных. Формат, в котором хранится информация в данных ресурсов, определяется на основе типов информации, которые известны как «типы ресурсов». Данные ресурсов часто ссылаются на другие типы данных.
В macOS форки называются file /..namedfork/ forkname , например , ресурсная форка файла IMG_0593.jpg — IMG_0593.jpg/..namedfork/rsrc. lsКоманда поддерживает -l@опцию, которая выводит список форков файла.
Ветви ресурсов отображаются как расширенный атрибут com.apple.ResourceFork. [4]
Ранее доступ к веткам ресурсов осуществлялся через API «Resource Manager» . Этот API теперь устарел. [5]
В устаревшем API:
API-интерфейсы файловых менеджеров, такие как , PBOpenRF()также разрешают доступ к необработанной ветви ресурсов; однако их следует использовать только для таких приложений, как копирование файлов — Apple настоятельно предостерегает от использования ветви ресурсов в качестве «второй ветви данных».
Из интерфейса POSIX доступ к ресурсной ветке можно было получить как filename/..namedfork/rsrcили как filename/rsrc; более короткая форма была объявлена устаревшей в Mac OS X v10.4 и полностью удалена в Mac OS X v10.7 . [6]
Наименьшие элементы, составляющие ресурсную вилку, называются типами данных. Существует несколько типов данных. После доступа к ресурсной вилке ее содержимое можно найти, прочитав ее в соответствии с типами данных, определенными заранее. Размещение определений внутри программы, указывающих, как следует обрабатывать данные, позволяет также хранить ресурсы, называемые ресурсами TMPL. Использование этого метода повышает видимость данных при просмотре с помощью такой программы, как ResEdit, что упрощает последующее редактирование. Поскольку платформа Macintosh возникла с процессорами на базе Motorola (68k и PPC), данные сериализуются на диск в формате big-endian .
Ниже приведен список основных типов данных в алфавитном порядке.
Приведенные ниже коды типов, как и указанные выше типы данных, используются в качестве идентификаторов типов не только для самих ветвей ресурсов: они используются для идентификации самих файлов, для описания данных в буфере обмена и многого другого.
Типы должны иметь длину 4 байта, поэтому такие типы, как snd и STR, на самом деле имеют пробел (0x20) в конце.
Сложность программирования с использованием вилок ресурсов привела к проблемам совместимости при доступе к другим файловым системам через протоколы обмена файлами, такие как AFP , SMB , NFS и FTP , при сохранении на томах, отличных от HFS, или при передаче файлов в другие системы другими способами (например, по электронной почте). Протокол AFP изначально поддерживает вилки ресурсов, поэтому вилки ресурсов обычно передаются на эти тома как есть и сохраняются сервером прозрачно для клиентов. Протокол SMB поддерживает систему метаданных файлов, похожую на вилки Macintosh, известную как альтернативные потоки данных (далее ADS). macOS не поддерживала хранение вилок ресурсов в ADS на томах SMB по умолчанию до Mac OS X v10.6 . В предыдущих версиях ОС, включая обновленные версии 10.6, эту функцию можно было включить с помощью изменения параметра или создания специального файла. [9]
Сетевые протоколы обмена файлами, такие как NFSv3 и FTP, не имеют концепции метаданных файлов, и поэтому нет возможности изначально хранить вилки ресурсов. Это также верно при записи в определенные типы локальных файловых систем, включая UFS, и на томах SMB, где поддержка Alternate Data Stream не включена. В этих случаях macOS хранит метаданные и вилки ресурсов, используя технику AppleDouble , в которой вилка данных записывается как один файл, а вилка ресурсов и метаданные записываются как совершенно отдельный файл, которому предшествует соглашение об именовании "._". Например: ExampleFile.psd будет содержать вилку данных, а ._ExampleFile.psd будет содержать вилку ресурсов и метаданные.
Проблемы совместимости могут возникнуть из-за того, что macOS будет по-разному обрабатывать хранение вилок ресурсов в зависимости от версии macOS, настроек и типа файловой системы. Например, в сети SMB со смесью клиентов 10.5 и 10.6. Недавно установленный клиент 10.6 будет искать и хранить вилки ресурсов на томе SMB в ADSes, но клиент 10.5 будет (по умолчанию) игнорировать ADSes и использовать формат AppleDouble для обработки вилок. Если файловый сервер поддерживает как AFP, так и NFS, то клиенты, использующие NFS, будут хранить файлы в формате AppleDouble , тогда как пользователи AFP будут хранить вилку ресурсов изначально. В таких случаях совместимость иногда можно поддерживать, заставляя клиентов использовать или не использовать формат AppleDouble .
Многие файловые серверы, предоставляющие поддержку AFP, изначально не поддерживают вилки ресурсов в своих локальных файловых системах. В таких случаях вилки могут храниться особым образом, например, в виде специально именованных файлов, специальных каталогов или даже альтернативных потоков данных.
Другая проблема заключается в сохранении вилок ресурсов при передаче файлов с использованием приложений, не поддерживающих вилки ресурсов, или с помощью определенных методов передачи, включая электронную почту и FTP. Для решения этой проблемы был создан ряд форматов файлов, таких как MacBinary и BinHexSplitForks . Системные инструменты командной строки и FixupResourceForksпозволяют вручную сглаживать и объединять вилки ресурсов. Кроме того, файловый сервер, стремящийся представить файловые системы клиентам Macintosh, должен размещать вилку ресурсов, а также вилку данных файлов; серверы UNIX , обеспечивающие поддержку AFP, обычно реализуют это с помощью скрытых каталогов.
Старые приложения, написанные с использованием API Carbon, имеют потенциальную проблему при переносе на современные компьютеры Intel Mac. Хотя диспетчер ресурсов и операционная система знают, как правильно десериализовать данные для общих ресурсов, таких как ' snd ' или ' moov', ресурсы, созданные с использованием ресурсов TMPL, должны быть вручную переставлены байтами, чтобы обеспечить совместимость файлов между версиями приложения на базе PPC и Intel. (Хотя карта ресурсов и другие детали реализации являются big-endian , сам диспетчер ресурсов не имеет никаких знаний о содержимом универсального ресурса и поэтому не может автоматически выполнить перестановку байтов.)
До появления Mac OS X v10.4 стандартные утилиты командной строки UNIX в macOS (такие как cpи mv) не учитывали вилки ресурсов. Чтобы скопировать файлы с вилками ресурсов, приходилось использовать dittoили CpMac и MvMac.
Концепция менеджера ресурсов для графических объектов, для экономии памяти, возникла в пакете OOZE на Xerox Alto в Smalltalk-76. [10] Эта концепция в настоящее время в значительной степени универсальна во всех современных операционных системах. Однако концепция ветвления ресурсов остается свойственной Macintosh. Большинство операционных систем использовали двоичный файл, содержащий ресурсы, который затем «прикреплялся» к концу существующего программного файла. Это решение используется, например, в Microsoft Windows , и аналогичные решения используются в X Window System , хотя ресурсы часто остаются в виде отдельного файла.
Windows NT NTFS может поддерживать форки (и, таким образом, может быть файловым сервером для файлов Mac), собственная функция, обеспечивающая эту поддержку, называется альтернативным потоком данных . Функции операционной системы Windows (например, стандартная вкладка «Сводка» на странице «Свойства» для файлов, не относящихся к Office) и приложения Windows используют их, и Microsoft разрабатывала файловую систему следующего поколения , которая имеет в качестве основы такую функцию.
Ранние версии BeOS реализовали базу данных в файловой системе, которую можно было использовать аналогично ресурсной вилке. Проблемы с производительностью привели к изменению в более поздних выпусках на систему сложных атрибутов файловой системы. В этой системе ресурсы обрабатывались способом, несколько более аналогичным Mac.
AmigaOS не использует разветвленные файлы. Ее исполняемые файлы внутренне разделены на модульную структуру больших частей ( hunk ), способных хранить код, данные и дополнительную информацию. Аналогично, файлы данных и проектов имеют структуру кусков , кодифицированную в стандарте IFF . Другие типы файлов хранятся аналогично другим операционным системам. Хотя AmigaOS не является строго ответвлением ресурсов, она хранит метаданные в файлах, известных как .infoфайлы. .infoфайлы можно идентифицировать по .infoрасширению; например, если вы сохраняете проект на диск, будут сохранены два файла, MyProjectи MyProject.info. MyProjectбудет фактическими данными проекта и MyProject.infoбудет содержать значок проекта, информацию о том, какая программа необходима для открытия проекта (поскольку в AmigaOS нет привязки к приложениям ), специальные параметры проекта и любые комментарии пользователя. .infoфайлы невидимы на рабочем столе Amiga ( Workbench ). Значок на рабочем столе, взятый из .infoсамого себя, является метафорой интерфейса , через который пользователь взаимодействует как с самим проектом, так и с его связанным .infoфайлом. Диалоговое окно, доступное по щелчку правой кнопкой мыши по значку, позволяет пользователю просматривать и изменять метаданные, присутствующие в .infoфайле. .infoФайлы можно просматривать как отдельные файлы в интерфейсе командной строки или в файловом менеджере . Современные клоны AmigaOS ( AROS , MorphOS и AOS4 ) наследуют структуру (вместе с метаданными) файлов .infoстарых версий AmigaOS, а также могут принимать стандартные графические файлы PNG в качестве битовых карт значков в своих .infoфайлах.
Операционные системы NeXT NeXTSTEP и OPENSTEP , их преемник macOS и другие системы, такие как RISC OS, реализовали другое решение. В этих системах ресурсы остаются в исходном формате, например, изображения включаются как полные файлы TIFF , а не кодируются в какой-то контейнер. Затем эти ресурсы помещаются в каталог вместе с исполняемым кодом и «сырыми данными». Каталог (называемый « пакетом » или « каталогом приложения ») затем представляется пользователю как само приложение. Это решение обеспечивает всю ту же функциональность, что и ветвь ресурсов, но позволяет легко манипулировать ресурсами с помощью любого приложения — «редактор ресурсов» (например, ResEdit ) не нужен. Из интерфейса командной строки пакет выглядит как обычный каталог. Этот подход не был вариантом в классической Mac OS , поскольку файловая система ( MFS ) не поддерживала отдельные каталоги каталогов. Когда поддержка файлов каталогов была включена в Mac OS, с файловой системой HFS, ветвь ресурсов была сохранена. macOS сохраняет классический API Resource Manager как часть своих библиотек Carbon для обратной совместимости. Однако сами ресурсы теперь могут храниться в отдельных файлах данных в файловой системе — Resource Manager теперь скрывает это изменение реализации от клиентского кода.