Jump to content

Ресурсная вилка

(Перенаправлено с Resource Fork )

Вилка ресурса — это в классической вилка файла операционной Apple от Mac OS системе , которая используется для хранения структурированных данных. Это одна из двух ветвей файла, наряду с вилкой данных , в которой хранятся данные, которые операционная система считает неструктурированными. Возможность разветвления ресурсов была перенесена в современную macOS для совместимости.

Ответвление ресурса хранит информацию в определенной форме, содержащей такие детали, как растровые изображения значков, формы окон, определения меню и их содержимого, а также код приложения ( машинный код ). Например, файл текстового процессора может хранить свой текст в ответвлении данных, а любые встроенные изображения — в ответвлении ресурсов того же файла. Вилка ресурса используется в основном исполняемыми файлами , но вилка ресурса может быть у любого файла.

В технической записке 1986 года Apple настоятельно рекомендовала разработчикам не помещать общие данные в ответвление ресурса файла. По словам Apple, некоторые части системного программного обеспечения полагаются на разветвления ресурсов, содержащие только действительную информацию Resource Manager. [1]

Форк ресурса был задуман и реализован программистом Apple Брюсом Хорном .

Файловые системы Macintosh

[ редактировать ]

В классических файловых системах Macintosh ветвь ресурсов имеет три цели:

  • Он хранит все графические данные на диске до тех пор, пока они не потребуются, затем извлекаются, рисуются на экране и выбрасываются. Этот программный вариант виртуальной памяти снижает требования к памяти с 1 МБ в Lisa до 128 КБ в Macintosh. [ нужна ссылка ]
  • Он предоставляет возможность непрограммисту выполнить интернационализацию и локализацию , поскольку все изображения и текст хранятся отдельно в ответвлении ресурса.
  • Его можно использовать для распределения почти всех компонентов приложения в одном файле, что уменьшает беспорядок и упрощает установку и удаление приложения.

Разветвление ресурсов реализовано во всех файловых системах, используемых для системных дисков в классической Mac OS ( MFS , HFS и HFS Plus ), а также в macOS только для APFS . Наличие ответвления ресурса позволяет легко хранить различную дополнительную информацию, например значок , который должен отображаться на рабочем столе для этого файла. Хотя ветвь данных допускает произвольный доступ к любому смещению внутри нее, доступ к ветвлению ресурсов работает как извлечение структурированных записей из базы данных . ( В 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 процессора поголовно хранились в форке ресурсов. Подпрограммы для рендеринга окон хранятся в ресурсах собственного типа ( WDEF), и подпрограммы для отрисовки меню в своих ( MDEF). Такое расположение позволило пользователям легко настраивать не только отдельные приложения, но и саму операционную систему, используя такие инструменты, как ResEdit, для изменения ресурсов файла приложения или любого из системных файлов.

Внутри приложения или другого кода ресурсы можно загружать, просто используя комбинацию их типа, идентификатора или имени, независимо от того, как и где они хранятся в ответвлении ресурсов. Клиенту возвращается дескриптор загруженного ресурса, к которому затем можно получить доступ, как и к любым другим данным на основе кучи. Компонентом ОС, который облегчает это, является диспетчер ресурсов. В дополнение к абстрагированию деталей хранения данных от данных, диспетчер ресурсов также упорядочивает наборы ветвей открытых ресурсов в стек, причем последний открытый файл находится наверху. При попытке загрузить ресурс он сначала просматривает верхнюю часть стека (возможно, ветвь ресурса текущего документа), затем следующую вниз (ветвь ресурса приложения), а затем следующую (ветвь системного ресурса). Такое расположение очень мощное — оно позволяет локальным ресурсам переопределять более глобальные ресурсы ниже — поэтому приложение может предоставлять, например, свои собственные значки или шрифты вместо стандартных системных. Это также позволяет приложению загружать ресурсы из системы, используя тот же API, что и любой другой ресурс, независимо от того, где и как этот ресурс хранится — для приложения все ресурсы одинаково доступны и просты в использовании. Система резервирует идентификаторы ресурсов в определенном диапазоне, чтобы избежать возникающих из-за этого конфликтов ресурсов. API-интерфейсы Resource Manager позволяют программисту манипулировать стеком и изменять поведение поиска.

Редактирование

[ редактировать ]

Поскольку ветвь ресурса можно редактировать с помощью редактора ресурсов, такого как 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 . Этот API устарел. [5]

В устаревшем API:

  1. При доступе к ответвлению ресурса данные, включая начальную позицию и длину данных ресурса и карту ресурса, считываются из заголовка.
  2. Если указан тип ресурса для чтения, выполняется проверка, чтобы убедиться, что тип присутствует в списке ресурсов, а также количество элементов данных, содержащих этот тип, и их смещения в списке ссылок на ресурсы от начальной позиции. карта ресурсов найдена.
  3. Находят идентификатор ресурса, смещение имени ресурса, свойства ресурса и смещение данных от начальной позиции данных ресурса.
  4. Если данные ресурса с указанным идентификатором или именем присутствуют в данных ресурса, осуществляется доступ к полученному выше смещению, определяется длина данных, и все хранящиеся там данные считываются и возвращаются в качестве возвращаемого значения.

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), данные сериализуются на диск в формате с прямым порядком байтов .

Ниже приведен список основных типов данных в алфавитном порядке.

Тип данных настоящее имя Описание
ББИТ двоичный бит Представляет один логический бит (истина или ложь). Обычно количество BBIT должно быть кратно 8.
БООЛ логическое значение Представляет логическое значение. Он состоит из 2 байтов; 256 — правда, а 0 — ложь.
ЧАР характер Представляет однобайтовый символ.
CSTR струна до Представляет строку формы, используемой в языке программирования C : завершающуюся нулем строку байтов, .
ДЛНГ десятичное длинное целое число Десятичное длинное слово (4-байтовое целое число). Представляет значения примерно от – 2,1 миллиарда до 2,1 миллиарда.
Шестнадцатеричный шестнадцатеричный дамп Указывает, что данные от этой позиции до конца являются шестнадцатеричными. Используется для представления ресурсов кода или сжатых данных.
СПГВ длинное слово в шестнадцатеричном формате Эти данные обрабатываются как 4-байтовое шестнадцатеричное значение. Он используется, среди прочего, для представления целых чисел, превышающих 2,1 миллиарда, таких как длинные значения без знака в C.
ПСТР строка Паскаля Представляет строку Pascal, где первый байт указывает длину строки.
ТНАМ введите имя Строка, представляющая значение, например код создателя , длина которого всегда составляет 4 байта.
ПРЯМОЙ прямоугольник Представляет координаты углов прямоугольника (верхнего, левого, нижнего, правого). Всегда длиной 8 байт.

Приведенные ниже коды типов, как и приведенные выше типы данных, используются в качестве идентификаторов типов не только для самих разветвлений ресурсов: они используются для идентификации самих файлов, для описания данных в буфере обмена и многого другого.

Типы должны иметь длину 4 байта, поэтому такие типы, как snd и STR, фактически имеют пробел (0x20) в конце.

Название типа ресурса настоящее имя Описание
оставлять псевдоним Сохраняет псевдоним другого файла в ответвлении ресурса файла, у которого установлен бит атрибута «псевдоним».
ALRT тревога Определяет форму окна предупреждения приложения.
ПРИЛОЖЕНИЕ приложение Сохраняет информацию о приложении
БНДЛ пучок Определяет такие данные, как значок типа файла, используемый в приложении.
цикн цветной значок Определяет цветной значок, используемый в данных
беспорядок таблица соответствия цветов Определяет цветовую палитру, используемую в данных
CNTL контроль Определяет детали компонента, расположенного в окне.
КОД ресурс кода Хранит машинный код программы.
КУРС курсор Определяет форму монохромного курсора (квадрат 8 × 8 бит).
ДИТЛ список элементов диалогового окна Определяет компонент окна
ДЛОГ диалог Определяет форму диалогового окна приложения.
ФРЕФ ссылка на файл Определяет тип файла, обрабатываемый приложением
hfdr значок всплывающей подсказки Определяет содержимое и форму всплывающей подсказки, отображаемой при наведении курсора на файл в Finder.
icl8 8-битный список значков Определяет значок, отображаемый в Finder
иконки список 32-битных значков Определяет значок, отображаемый в Finder
ИКОНА икона Определяет монохромный элемент, используемый в данных.
добрый описание файла Определяет описание типа файла
МБАР барное меню Определяет меню и строку меню для приложения.
МДЭФ определение меню Определяет меню для приложения. Также может использоваться для определения меню сложных форм, таких как цветовые палитры.
МЕНЮ меню Определяет пункты меню в приложении.
МоВ фильм Сохраняет фильм QuickTime.
открыть открыть Определяет тип файла, который приложение может открыть
ПИКТ картина Сохраняет изображение PICT, содержащееся в файле.
PREF предпочтение Хранит настройки среды для приложения.
снд звук Сохраняет звук, используемый в файле
СТР нить Хранит строку или шестнадцатеричные данные, используемые в файле.
STR# список строк Сохраняет несколько строк, используемых в файле
стиль стиль Определяет информацию о стиле, такую ​​как шрифт, цвет и размер текста.
ТЕКСТ текст Сохраняет текст
ТМПЛ шаблон Определяет формат данных ресурса
к версия Определяет версию или регион использования файла.
ВДЕФ определение окна Определяет окно для приложения. Также могут быть определены окна неопределенной формы.
ВЕТЕР окно Определяет форму окна приложения

Редакторы

[ редактировать ]
Рередактировать
Распространяется бесплатно компанией Apple. Может использоваться для визуального редактирования данных ресурса. Если структура данных известна, она может отображать различные типы данных в визуальном формате. Не работает на современных macOS.
Колдун
Дорогой, но популярный, поскольку его можно использовать для визуального редактирования гораздо большего количества типов данных, чем ResEdit.
ШестнадцатеричныйПравить
Двоичный редактор, который на самом деле обычно используется больше для редактирования ветки данных, а не ветки ресурсов.
ResKnife
Редактор с открытым исходным кодом для Mac OS X ; больше не поддерживается.
Переработка
Инструмент macOS, который извлекает ресурсы из разветвления ресурсов в отдельные двоичные файлы, конвертируя при этом многие типы в форматы, подходящие для современной разработки.
ресурс_дасм
Экстрактор ресурсов с открытым исходным кодом для macOS и Linux, который также способен конвертировать многие ресурсы в современные форматы. [7]
РесФордж
редактор ресурсов для macOS, способный редактировать файлы классической ветки ресурсов и связанные форматы. Совместимо с macOS 10.14 или новее. Изначально работает как на 64-битном процессоре Intel, так и на Apple Silicon. [8]

Совместимость

[ редактировать ]

Сложность программирования с разветвлениями ресурсов привела к проблемам совместимости при доступе к другим файловым системам через протоколы общего доступа к файлам, такие как 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 как часть библиотек Carbon для обеспечения обратной совместимости. Однако сами ресурсы теперь могут храниться в отдельных файлах данных внутри файловой системы — диспетчер ресурсов теперь скрывает это изменение реализации от клиентского кода.

См. также

[ редактировать ]
  1. ^ «Техническое примечание FL19: Данные в ответвлении ресурсов: не делайте этого» . Разработчик Apple . 1 марта 1986 г. Архивировано из оригинала 16 августа 2023 г.
  2. ^ «Техническое примечание TN1150: формат тома HFS Plus» . Разработчик Apple . 5 марта 2004 г. Проверено 11 февраля 2024 г.
  3. ^ «Технические вопросы и ответы QA1175: Разветвления ресурсов в двоичных файлах Mach-O» . Разработчик Apple . 7 августа 2002 г. Архивировано из оригинала 16 августа 2023 г.
  4. ^ Стейси, Джон (21 августа 2009 г.). «Вилки ресурсов Mac OS X» . Взгляд Джона . Проверено 22 октября 2012 г.
  5. ^ «Справочник по менеджеру ресурсов» . Разработчик Apple . Архивировано из оригинала 25 октября 2012 года . Проверено 22 октября 2012 г.
  6. ^ «Использование путей» . Разработчик Apple . 31 марта 2001 г. Архивировано из оригинала 18 декабря 2002 г. Проверено 18 декабря 2002 г.
  7. ^ программное обеспечение fuzziqer. "ресурс_дасм" . Гитхаб .
  8. ^ Эндрюс05. «РесФордж» . Гитхаб .
  9. ^ «Mac OS X v10.5, v10.6: Об именованных потоках на SMB-серверах NAS, Mac OS X и Windows; могут появляться предупреждения «-36» или «-50» . Поддержка Apple . Архивировано из оригинала 24 июля 2010 г. Проверено 19 апреля 2010 г.
  10. ^ «Ранняя история Smalltalk» . Проверено 24 июля 2008 г.
[ редактировать ]
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: 27b53605016e01dd8e319e6236a98fc2__1721756580
URL1:https://arc.ask3.ru/arc/aa/27/c2/27b53605016e01dd8e319e6236a98fc2.html
Заголовок, (Title) документа по адресу, URL1:
Resource fork - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)