Вилка ресурса — это вилка файла в классической операционной системе 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-битное слово со знаком ) и необязательное имя. Существуют стандартизированные типы ресурсов для диалоговых окон ( ), изображений ( ), звуков ( ) и исполняемых двоичных файлов ( ), которые до появления процессора PowerPC без исключения хранились в ответвлении ресурсов. Подпрограммы для отрисовки окон хранятся в своих ресурсах ( ), а подпрограммы для отрисовки меню — в своих ( ). Такое расположение позволило пользователям легко настраивать не только отдельные приложения, но и саму операционную систему, используя такие инструменты, как ResEdit , для изменения ресурсов файла приложения или любого из системных файлов.DITLPICTsnd CODE WDEFMDEF
Внутри приложения или другого кода ресурсы можно загружать, просто используя комбинацию их типа, идентификатора или имени, независимо от того, как и где они хранятся в ответвлении ресурсов. Клиенту возвращается дескриптор загруженного ресурса, к которому затем можно получить доступ, как и к любым другим данным на основе кучи. Компонентом ОС, который облегчает это, является диспетчер ресурсов. Помимо абстрагирования деталей хранения данных от данных, диспетчер ресурсов также упорядочивает наборы ветвей открытых ресурсов в стек, причем последний открытый файл находится наверху. При попытке загрузить ресурс он сначала просматривает верхнюю часть стека (возможно, ветвь ресурса текущего документа), затем следующую вниз (ветвь ресурса приложения), а затем следующую (ветвь системного ресурса). Такое расположение очень мощное — оно позволяет локальным ресурсам переопределять более глобальные ресурсы ниже — поэтому приложение может предоставлять, например, свои собственные значки или шрифты вместо стандартных системных. Это также позволяет приложению загружать ресурсы из системы, используя тот же API, что и любой другой ресурс, независимо от того, где и как этот ресурс хранится — для приложения все ресурсы одинаково доступны и просты в использовании. Система резервирует идентификаторы ресурсов в определенном диапазоне, чтобы избежать возникающих из-за этого конфликтов ресурсов. API-интерфейсы Resource Manager позволяют программисту манипулировать стеком и изменять поведение поиска.
Поскольку ветвь ресурса можно редактировать с помощью редактора ресурсов, такого как ResEdit , ее можно использовать для локализации и настройки программного обеспечения . Кроме того, большинство редакторов ресурсов позволяют визуально редактировать данные. В macOS есть возможность использовать ресурсы при разработке приложения. Однако если приложение может потребоваться использовать в UFS , его также можно настроить так, чтобы вся вилка ресурсов была перемещена в вилку данных, используя параметр «Необработанный файл ресурсов». Интегрированные среды разработки, бесплатно распространяемые 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 «Диспетчера ресурсов» . Этот 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), данные сериализуются на диск в формате с прямым порядком байтов .
Ниже приведен список основных типов данных в алфавитном порядке.
Приведенные ниже коды типов, как и приведенные выше типы данных, используются в качестве идентификаторов типов не только для самих разветвлений ресурсов: они используются для идентификации самих файлов, для описания данных в буфере обмена и многого другого.
Типы должны иметь длину 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, где поддержка альтернативного потока данных не включена. В этих случаях macOS хранит метаданные и ветки ресурсов с использованием метода AppleDouble , при котором вилка данных записывается как один файл, а вилка ресурса и метаданные записываются как совершенно отдельный файл, которому предшествует соглашение об именах «._». Например: exampleFile.psd будет содержать ветку данных, а ._ExampleFile.psd будет содержать вилку ресурса и метаданные.
Могут возникнуть проблемы с совместимостью, поскольку macOS по-разному обрабатывает хранилище ветвей ресурсов в зависимости от версии macOS, настроек и типа файловой системы. Например, в сети SMB со смесью клиентов 10,5 и 10,6. Только что установленный клиент 10.6 будет искать и сохранять ветки ресурсов на томе SMB в ADS, но клиент 10.5 (по умолчанию) будет игнорировать ADS и использовать формат AppleDouble для обработки вилок. Если файловый сервер поддерживает как AFP, так и NFS, то клиенты, использующие NFS, будут хранить файлы в формате AppleDouble , тогда как пользователи AFP будут хранить ветвь ресурсов изначально. В таких случаях совместимость иногда можно обеспечить, заставляя клиентов использовать или не использовать формат AppleDouble .
Многие файловые серверы, обеспечивающие поддержку AFP, изначально не поддерживают разветвления ресурсов в своих локальных файловых системах. В этих случаях ответвления могут храниться особым образом, например, в файлах со специальными именами, специальных каталогах или даже в альтернативных потоках данных.
Еще одна проблема — сохранение разветвлений ресурсов при передаче файлов с использованием приложений, не поддерживающих разветвление ресурсов, или с помощью определенных методов передачи, включая электронную почту и FTP. Для этого был создан ряд форматов файлов, таких как MacBinary и BinHex . Системные инструменты командной строки SplitForks, FixupResourceForksпозволяющие вручную выравнивать и объединять ветки ресурсов. Кроме того, файловый сервер, стремящийся предоставить файловые системы клиентам Macintosh, должен поддерживать ветвь ресурсов, а также ветвь данных файлов; Серверы UNIX , обеспечивающие поддержку AFP, обычно реализуют это с помощью скрытых каталогов.
У старых приложений, написанных с использованием Carbon API, могут возникнуть потенциальные проблемы при портировании на современные компьютеры Intel Mac. Хотя диспетчер ресурсов и операционная система знают, как правильно десериализовать данные для общих ресурсов, таких как ' snd ' или ' moov', ресурсы, созданные с использованием ресурсов TMPL, должны быть заменены байтами вручную, чтобы обеспечить совместимость файлов между PPC и версиями приложения на базе Intel. (Хотя карта ресурсов и другие детали реализации имеют обратный порядок байтов , диспетчер ресурсов сам по себе не имеет никаких знаний о содержимом общего ресурса и поэтому не может автоматически выполнять замену байтов.)
До появления Mac OS X v10.4 стандартные утилиты командной строки UNIX в macOS (такие как cpи mv) не учитывали разветвления ресурсов. Для копирования файлов с разветвлениями ресурсов приходилось использовать dittoлибо CpMac, либо MvMac.
Идея менеджера ресурсов графических объектов для экономии памяти возникла в пакете OOZE на Xerox Alto в Smalltalk-76. [10] В настоящее время эта концепция в значительной степени универсальна для всех современных операционных систем. Однако концепция разветвления ресурсов остается характерной для Macintosh. Большинство операционных систем использовали двоичный файл, содержащий ресурсы, который затем «прикреплялся» к концу существующего программного файла. Это решение используется, например, в Microsoft Windows , а аналогичные решения используются в системе X Window , хотя ресурсы часто оставляются в виде отдельного файла.
Windows NT NTFS может поддерживать разветвления (и поэтому может быть файловым сервером для файлов Mac), встроенная функция, обеспечивающая эту поддержку, называется альтернативным потоком данных . Функции операционной системы Windows (такие как стандартная вкладка «Сводка» на странице «Свойства» для файлов, отличных от Office) и приложения Windows используют их, и Microsoft разрабатывает файловую систему следующего поколения , в основе которой лежит такая функция.
Ранние версии BeOS реализовали базу данных внутри файловой системы, которую можно было использовать аналогично разветвлению ресурсов. Проблемы с производительностью привели к изменению в более поздних выпусках системы сложных атрибутов файловой системы. При этом системные ресурсы обрабатывались способом, более похожим на Mac.
AmigaOS не использует раздвоенные файлы. Его исполняемые файлы внутри разделены на модульную структуру из больших частей ( ханков ), способных хранить код, данные и дополнительную информацию. Аналогично, файлы данных и проектов имеют порочную структуру, кодифицированную в стандарте 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 для обеспечения обратной совместимости. Однако сами ресурсы теперь могут храниться в отдельных файлах данных внутри файловой системы — диспетчер ресурсов теперь скрывает это изменение реализации от клиентского кода.