Fork zasobu

Fork zasobu (ang. Resource Fork) – fork lub sekcja pliku w klasycznym systemie operacyjnym Mac OS, został również przeniesiony do nowoczesnego macOS dla kompatybilności, używany do przechowywania strukturyzowanych danych wraz z niestrukturyzowanymi danymi przechowywanymi w forku danych.

Fork zasobu przechowuje informacje w określonej formie, zawierające szczegóły, takie jak mapy bitowe ikon, kształty okien, definicje menu i ich zawartości oraz kod aplikacji (kod maszynowy). Na przykład plik edytora tekstu może przechowywać tekst w forku danych, a jednocześnie przechowywać wszelkie osadzone obrazy w forku zasobu tego samego pliku. Fork zasobu jest używany głównie przez pliki wykonywalne, ale każdy plik może mieć fork zasobu.

System plików Macintosh (MFS)[edytuj | edytuj kod]

Pierwotnie pomyślany i zaimplementowany przez programistę Bruce’a Horn, fork zasobu został wykorzystany do trzech celów w systemie plików Macintosh:

Służył do przechowywania wszystkich danych graficznych na dysku, dopóki nie były potrzebne, a następnie pobrane, rysowane na ekranie i wyrzucane. Ten wariant oprogramowania pamięci wirtualnej pomógł Apple zmniejszyć wymagania dotyczące pamięci z 1 MB w Apple Lisa do 128 KB w Macintoshu.
Ponieważ wszystkie obrazy i tekst były przechowywane osobno w forku zasobów, można było go użyć, aby umożliwić nieprogramistom na tłumaczenie aplikacji na rynek zagraniczny, proces ten nazywany jest internacjonalizacją i lokalizacją.
Można było go wykorzystać do dystrybucji prawie wszystkich komponentów aplikacji w jednym pliku, zmniejszając bałagan i upraszczając instalację i usuwanie aplikacji.

Fork zasobu jest zaimplementowany we wszystkich systemach plików używanych dla dysków systemowych na komputerach Macintosh (MFS, HFS i HFS Plus). Obecność forka zasobu ułatwia przechowywanie szeregu dodatkowych informacji, takich jak umożliwienie systemowi wyświetlenia właściwej ikony pliku i otwarcia go bez potrzeby rozszerzenia pliku w nazwie pliku. Podczas gdy dostęp do forka danych działa jak dostęp do pliku w dowolnym innym systemie operacyjnym – wybierz plik, wybierz przesunięcie bajtu, przeczytaj niektóre dane – dostęp do forka zasobu działa bardziej jak wyodrębnianie uporządkowanych rekordów z bazy danych. (Microsoft Windows ma również pojęcie „zasobów”, ale są one całkowicie niezwiązane z zasobami w Mac OS.)

Fork zasobu jest czasem używany do przechowywania metadanych pliku, chociaż może być również używany do przechowywania rzeczywistych danych, tak jak miało to miejsce w przypadku plików czcionek w klasycznych systemach operacyjnych Mac. Należy zauważyć, że systemy plików Macintosh mają również oddzielny obszar dla metadanych, inny niż fork danych lub zasobu. Będąc częścią katalogowego wpisu pliku, dostęp do tego jest znacznie szybszy. Jednak ilość przechowywanych tutaj danych jest minimalna, są to tylko znaczniki czasu tworzenia i modyfikacji, typ pliku i kody twórcy, długości forka i nazwa pliku. Niektóre pliki mają tylko forka zasobów. Klasyczne aplikacje 68k są jednym przykładem, w którym nawet kod wykonywalny jest zawarty w zasobach typu „KOD”. Późniejsze pliki binarne PowerPC przechowują kod wykonywalny we forku danych.

Ponieważ forki zasobu są obsługiwane tylko w systemach plików HFS i HFS Plus, nie można ich używać w systemach operacyjnych, które używają innych systemów plików. Obecnie HFS jest obsługiwany tylko przez system operacyjny Macintosha, co oznacza, że tylko komputery z systemem Mac OS mogą korzystać z forków zasobu. Nawet w systemie Mac OS nie można używać forków zasobów, jeśli Uniksowy system plików został zainstalowany. W systemie plików HFS Plus, który jest obecnie systemem najczęściej używanym w systemie Mac OS, można wprowadzić ustawienia pozwalające innym forkom oprócz forków danych i zasobu, tworzyć aplikację „multi-fork”. Ponieważ jednak forki mogą utrudniać wymianę plików z innymi systemami operacyjnymi, ta funkcja nie jest powszechnie używana. Nawet w macOS forki zasobu są rzadko używane.

Obecnie macOS obsługuje forki zasobu w Windowsowych udziałach SMB, tworząc ukryty plik ze znakami „. _” dodanymi na początku nazwy pliku, w tym samym katalogu, co plik forka danych.

Identyfikatory zasobu[edytuj | edytuj kod]

Każdy zasób ma identyfikator OSType (wartość czterobajtową) i identyfikator (podpisane 16-bitowe słowo), a także opcjonalną nazwę. Istnieją standardowe typy zasobów dla okien dialogowych („DITL”), obrazów („ PICT „), dźwięków („snd”) – a nawet plików wykonywalnych („CODE”), które do czasu pojawienia się procesora PowerPC były bez wyjątku przechowywane w forku zasobów. Podprogramy do renderowania okien są przechowywane we własnym typie zasobów („WDEF”), podprogramy do renderowania menu w ich („MDEF”), a jeśli istnieje rodzaj danych, który Twoim zdaniem nie pasuje do żadnej ze standardowych kategorii, możesz równie dobrze może użyć własnego typu (np. „John”) – właściwie dowolne cztery znaki lub wartość 32-bitowa mogą służyć jako typ zasobu. Takie ustawienie umożliwiło użytkownikom łatwe dostosowanie nie tylko poszczególnych aplikacji, ale także samego systemu operacyjnego, za pomocą narzędzi takich jak ResEdit do modyfikowania zasobów pliku aplikacji lub dowolnego pliku systemowego.

W aplikacji lub innym kodzie zasoby mogą być ładowane po prostu za pomocą kombinacji ich typu, identyfikatora lub nazwy, bez względu na to, jak i gdzie są przechowywane w forku zasobu. Klient otrzymuje uchwyt do załadowanego zasobu, do którego następnie można uzyskać dostęp, jak każdych innych danych opartych na puli. Składnikiem systemu operacyjnego, który to ułatwia, jest Menedżer Zasobu. Oprócz wyodrębnienia szczegółów przechowywania danych z samych danych, Menedżer Zasobu układa również zestawy otwartych forków zasobu w stos, z ostatnio otwieranym plikiem na górze. Podczas próby załadowania zasobu, najpierw zajrzy na górę stosu (być może fork zasobu bieżącego dokumentu), następnie następny w dół (fork zasobu aplikacji), a następnie następny (fork zasobu systemowych). To ustawienie jest bardzo wydajne – pozwala lokalnym zasobom na zastąpienie bardziej globalnych niżej – tak więc aplikacja może na przykład udostępnić własne ikony lub czcionki zamiast standardowych systemowych. Pozwala również aplikacji ładować zasoby z systemu przy użyciu tego samego interfejsu API, co każdy inny zasób, bez względu na miejsce i sposób przechowywania tego zasobu – w aplikacji wszystkie zasoby są jednakowo dostępne i łatwe w użyciu. System rezerwuje identyfikatory zasobów w pewnym zakresie, aby uniknąć wynikających z tego konfliktów zasobu. Interfejsy API Menedżera Zasobu pozwalają programiście manipulować stosem i modyfikować zachowanie wyszukiwania.

Edycja forków zasobu[edytuj | edytuj kod]

Ponieważ forka zasobu można edytować za pomocą edytora zasobu, takiego jak ResEdit, można go używać do lokalizowania i dostosowywania oprogramowania. Ponadto większość edytorów zasobu umożliwia wizualną edycję danych. W macOS możliwe jest korzystanie z zasobów podczas tworzenia aplikacji. Jeśli jednak aplikacja może wymagać użycia w systemie plików UFS, można ją również skonfigurować tak, aby cały fork zasobu został przeniesiony do forka danych za pomocą ustawienia Raw Resource File. Zintegrowane środowiska programistyczne dystrybuowane za darmo przez Apple Inc., w tym MPW i Apple Developer’s Tools, zawierają kompilator o nazwie Rez. Używa on specjalnego języka, zwanego także Rez, którego można użyć do utworzenia forka zasobu poprzez kompilację kodu źródłowego. Uwzględniono również dekompilator DeRez, którego można użyć do zmiany forka zasobu z powrotem na kod Rez.

W strukturze forka zasobu znajduje się część danych zwana „mapą zasobu”, która przechowuje pozycje elementów danych zasobu. Można to wykorzystać, aby umożliwić losowy dostęp do danych zasobu na podstawie zdefiniowanych identyfikatorów i nazw. Fork zasobu można uznać za składający się zasadniczo z dwóch obiektów, mapy zasobu i samych danych zasobu, ale w rzeczywistości każdy typ danych jest strukturą hierarchiczną, która przechowuje wiele elementów danych. Format, w którym przechowywane są informacje w danych zasobu, jest definiowany na podstawie typów informacji, które są znane jako „typy zasobu”. Dane zasobu często zawierają odniesienia do innych typów danych.

W macOS forki noszą nazwę plik/..nazwanyfork/nazwaforka, np. Fork zasobu pliku IMG_0593.jpg to IMG_0593.jpg/..namedfork/rsrc. Polecenie ls obsługuje opcję -l@, która wyświetla listę forków pliku.

Jak uzyskiwany jest dostęp do forka zasobu[edytuj | edytuj kod]

Forki zasobu pojawiają się jako rozszerzony atrybut com.apple. ResourceFork^[1].

Wcześniej dostęp do forków zasobu był możliwy za pośrednictwem API „Menedżer Zasobu”. Ten interfejs API jest teraz przestarzały^[2].

W przestarzałym interfejsie API:

Gdy dostęp do forka zasobu jest uzyskiwany, dane zawierające pozycję początkową i długość danych zasobu oraz mapę zasobu są wczytywane z nagłówka.
Jeśli określono typ zasobu do odczytu, przeprowadzane jest sprawdzenie, aby upewnić się, że ten typ znajduje się na liście zasobu, a także liczbę pozycji danych zawierających ten typ i ich przesunięcia na liście referencyjnej zasobu od pozycji początkowej mapa zasobu została znaleziona.
Znaleziono identyfikator zasobu, przesunięcie nazwy zasobu, właściwości zasobu i przesunięcie danych od pozycji początkowej danych zasobu.
Jeśli dane zasobu o określonym identyfikatorze lub nazwie znajdują się w danych zasobu, uzyskiwany jest dostęp do przesunięcia uzyskanego powyżej, długość danych zostaje znaleziona, a wszystkie przechowywane tam dane są wczytywane i zwracane jako wartość zwracana.

API menedżera plików, takie jak PBOpenRF() również umożliwiały dostęp do forka zasobu; należy ich jednak używać tylko w aplikacjach, takich jak kopiowanie pliku – Apple zdecydowanie ostrzega przed użyciem forka zasobu jako „drugiego forka danych”.

Z interfejsu POSIX można uzyskać dostęp do forka zasobu jako nazwapliku/..nazwaforka/rsrc lub jako nazwapliku/rsrc; krótsza wersja została wycofana w Mac OS X 10.4 i całkowicie usunięta w Mac OS X 10.7^[3].

Typy danych w forku zasobu[edytuj | edytuj kod]

Najmniejsze elementy tworzące forka zasobu nazywane są typami danych. Istnieje kilka typów danych. Po uzyskaniu dostępu do forka zasobu jego zawartość można znaleźć, odczytując go odpowiednio dla typów danych zdefiniowanych wcześniej. Umieszczenie w programie definicji określających sposób przetwarzania danych umożliwia również przechowywanie zasobu zwanych zasobami TMPL. Zastosowanie tej metody zwiększa widoczność danych podczas przeglądania za pomocą programu takiego jak ResEdit, co ułatwia późniejszą edycję. Ponieważ platforma Macintosh pochodzi z procesorów Motorola (68k i PPC), dane są serializowane na dysk w formacie big endian.

Poniżej znajduje się lista głównych typów danych w kolejności alfabetycznej.

Typ danych	faktyczna nazwa	Opis
BBIT	binary bit	Reprezentuje pojedynczy bit boolean (prawda lub fałsz). Zwykle liczba BBIT musi być wielokrotnością 8.
BOOL	boolean	Reprezentuje wartość boolean. Składa się z 2 bajtów; 256 to prawda, a 0 to fałsz.
CHAR	character	Reprezentuje znak jednobajtowy.
CSTR	C string	Reprezentuje ciąg formy używanej w języku programowania C: zakończony zerem ciąg bajtów.
DLNG	decimal long word integer	Długie dziesiętne słowo (4-bajtowa liczba całkowita). Reprezentuje wartości od około – 2,1 miliarda do 2,1 miliarda.
HEXD	hex dump	Wskazuje, że dane od tej pozycji do końca są szesnastkowe. Służy do reprezentowania zasobu kodu lub skompresowanych danych.
HLNG	long word hexadecimal	Te dane są traktowane jako 4-bajtowa wartość szesnastkowa. Jest on używany między innymi do reprezentowania liczb całkowitych większych niż 2,1 miliarda, takich jak długie niepodpisane wartości w C.
PSTR	Pascal string	Reprezentuje ciąg Pascal, przy czym pierwszy bajt podaje długość ciągu.
TNAM	type name	Ciąg reprezentujący wartość, taką jak kod twórcy, który zawsze ma 4 bajty.
RECT	rectangle	Reprezentuje współrzędne narożników prostokąta (górny, lewy, dolny, prawy). Zawsze 8 bajtów.

Główne typy zasobu[edytuj | edytuj kod]

Poniższe kody typów, podobnie jak powyższe typy danych, są używane jako identyfikatory typu dla więcej niż samych forków zasobu: służą one do samodzielnej identyfikacji pliku, opisu danych w schowku i wielu innych.

Zauważ, że typy muszą mieć 4 bajty, więc typy takie jak snd i STR faktycznie mają spację (0x20) na końcu.

Nazwa typu zasobu	faktyczna nazwa	Opis
alis	alias	Przechowuje alias w innym pliku, w forku zasobu pliku w którym ustawiony jest bit atrybutu „alias”
ALRT	alert	Określa kształt pola ostrzeżenia aplikacji
APPL	application	Przechowuje informacje o aplikacji
BNDL	bundle	Definiuje dane, takie jak ikona typu pliku używana w aplikacji
cicn	color icon	Definiuje ikonę koloru używaną w danych
clut	color look-up table	Definiuje paletę kolorów używaną w danych
CNTL	control	Definiuje szczegóły komponentu umieszczonego w oknie
CODE	code resource	Przechowuje kod maszynowy dla programu
CURS	cursor	Określa kształt kursora monochromatycznego (kwadrat 8 × 8 bitów)
DITL	dialog item list	Definiuje komponent okna
DLOG	dialog	Określa kształt okna dialogowego dla aplikacji
FREF	file reference	Definiuje typ pliku obsługiwany przez aplikację
hfdr	icon balloon help	Definiuje zawartość i kształt dymku pomocy wyświetlanego, gdy kursor znajdzie się nad plikiem w Finderze
icl8	8 bit icon list	Definiuje ikonę wyświetlaną w Finderze
icns	32 bit icon list	Definiuje ikonę wyświetlaną w Finderze
ICON	ICON	Definiuje element monochromatyczny używany w danych
kind	file description	Definiuje opis typu pliku
MBAR	menu bar	Definiuje menu i pasek menu dla aplikacji
MDEF	menu definition	Definiuje menu dla aplikacji. Może być również używany do definiowania menu o złożonych kształtach, takich jak palety kolorów.
MENU	menu	Definiuje pozycje menu w aplikacji
MooV	movie	Przechowuje film QuickTime
open	open	Definiuje typ pliku, który aplikacja może otworzyć
PICT	picture	Przechowuje obraz PICT zawarty w pliku
PREF	preference	Przechowuje ustawienia środowiska dla aplikacji
snd	sound	Przechowuje dźwięk użyty w pliku
STR	string	Przechowuje ciąg lub dane szesnastkowe użyte w pliku
STR#	string list	Przechowuje wiele ciągów używanych w pliku
styl	style	Definiuje informacje o stylu, takie jak czcionka, kolor i rozmiar tekstu
TEXT	text	Przechowuje tekst
TMPL	template	Definiuje format danych zasobu
vers	version	Określa wersję lub region użytkowania pliku
WDEF	window definition	Definiuje okno aplikacji. Okna o nieokreślonym kształcie można również zdefiniować.
WIND	window	Określa kształt okna aplikacji

Główne edytory zasobu[edytuj | edytuj kod]

ResEdit: Dystrybucja bezpłatna przez Apple. Może być używany do wizualnej edycji danych zasobu. Jeśli znana jest struktura danych, może wyświetlać zakres różnych typów danych w formacie wizualnym.
Resorcerer: Drogi, ale popularny, ponieważ można go używać do wizualnej edycji wielu innych typów danych niż ResEdit.
HexEdit: Edytor binarny, który w rzeczywistości zwykle służy raczej do edytowania forka danych niż forka zasobu.
ResKnife: Otwarty edytor dla MacOS X
Rezycle: Narzędzie macOS, które wyodrębnia zasoby z forka zasobu do oddzielnych plików binarnych, konwertując wiele typów do formatów odpowiednich dla współczesnego programowania.

Problemy ze zgodnością[edytuj | edytuj kod]

Złożoność programowania przy użyciu forków zasobu doprowadziła do problemów ze zgodnością podczas uzyskiwania dostępu do innych systemów plików za pośrednictwem protokołów udostępniania plików, takich jak AFP, SMB, NFS i FTP, podczas przechowywania na woluminach innych niż HFS lub podczas przesyłania plików do innych systemów w inny sposób (takich jak e-mail). Protokół AFP natywnie obsługuje Forki Zasobu, więc forki zasobu są zazwyczaj przesyłane do tych woluminów w stanie niezmienionym i przechowywane przez serwer w sposób przezroczysty dla klientów. Protokół SMB obsługuje system metadanych plików podobny do forków Macintosh zwanych alternatywnymi strumieniami danych (dalej ADS). macOS do wersji Mac OS X 10.6 nie obsługiwał przechowywania forków zasobu w ADS na woluminach SMB. W poprzednich wersjach systemu operacyjnego, w tym w zaktualizowanych wersjach 10.6, tę funkcję można włączyć za pomocą zmiany parametrów lub poprzez utworzenie specjalnego pliku^[4].

Sieciowe protokoły udostępniania plików, takie jak NFSv3 i FTP, nie mają koncepcji metadanych plików, więc nie ma możliwości natywnego przechowywania forków zasobu. Dotyczy to również zapisu do niektórych typów lokalnych systemów plików, w tym UFS, oraz na woluminach SMB, w których obsługa alternatywnego strumienia danych nie jest włączona. W takich przypadkach macOS przechowuje metadane i forki zasobu przy użyciu techniki o nazwie AppleDouble, w której Fork danych jest zapisywany jako jeden plik, a Fork zasobu i metadane są zapisywane jako osobny plik poprzedzony znakiem „. _” Konwencja nazewnictwa. Na przykład: PrzykladowyPlik.psd zawierałby forka danych, a. _PrzykladowyPlik.psd zawierałby forka zasobu i metadane.

Mogą pojawić się problemy ze zgodnością, ponieważ macOS będzie obsługiwał przechowywanie forków zasobu w różny sposób, w zależności od wersji macOS, ustawień i typu systemu plików. Na przykład w sieci SMB z mieszanką klientów 10.5 i 10,6. Świeżo zainstalowany klient 10.6 będzie szukać i przechowywać forki zasobu na woluminie SMB w ADS, ale klient 10.5 (domyślnie) zignoruje ADS i użyje formatu AppleDouble do obsługi forków. Jeśli serwer plików obsługuje zarówno AFP, jak i NFS, klienci korzystający z NFS będą przechowywać pliki w formacie AppleDouble, podczas gdy użytkownicy AFP będą przechowywać natywny forka zasobu. W takich przypadkach zgodność można czasem zachować, zmuszając klientów do używania lub nieużywania formatu AppleDouble.

Wiele serwerów plików obsługujących AFP nie obsługuje natywnie forków zasobu w swoich lokalnych systemach plików. W takich przypadkach forki mogą być przechowywane w specjalny sposób, taki jak specjalnie nazwane pliki, specjalne katalogi, a nawet alternatywne strumienie danych.

Kolejnym wyzwaniem jest zachowanie forków zasobu podczas przesyłania plików przy użyciu aplikacji nieobsługujących forków zasobu lub określonych metod przesyłania, w tym poczty e-mail i FTP. Aby to obsłużyć, utworzono wiele formatów plików, takich jak MacBinary i BinHex. Narzędzia systemowe wiersza poleceń SplitForks i FixupResourceForks umożliwiają ręczne spłaszczanie i scalanie wideł zasobu. Ponadto serwer plików, który chce prezentować systemy plików klientom Macintosh, musi obsługiwać forka zasobu, a także forka danych plików; Serwery UNIX zapewniające obsługę AFP zazwyczaj implementują to z ukrytymi katalogami.

Starsze aplikacje napisane przy użyciu Carbon API mogą mieć problem z przeniesieniem na obecne komputery Mac z procesorami Intel. Podczas gdy Menedżer Zasobu i system operacyjny wiedzą, jak poprawnie dokonać deserializacji danych dla typowych zasobu, takich jak „snd” lub „MooV”, zasoby utworzone przy użyciu zasobu TMPL muszą zostać ręcznie zamienione bajtami, aby zapewnić interoperacyjność plików między wersjami aplikacji opartymi na PPC i Intel. (Chociaż mapa zasobu i inne szczegóły implementacji są big endianami, sam Menedżer Zasobu nie ma żadnej wiedzy na temat zawartości zasobu ogólnego, a zatem nie może automatycznie zamieniać bajtów.)

Do czasu pojawienia się systemu Mac OS X 10.4 standardowe narzędzia wiersza poleceń systemu UNIX w systemie macOS (takie jak cp i mv) nie szanowały forków zasobu. Aby skopiować pliki z forkami zasobu, trzeba było użyć ditto lub CpMac i MvMac.

Inne systemy operacyjne[edytuj | edytuj kod]

Koncepcja menedżera zasobu dla obiektów graficznych w celu oszczędzania pamięci powstała w pakiecie OOZE na Alto w Smalltalk-76.^[5] Koncepcja jest obecnie w dużej mierze uniwersalna we wszystkich nowoczesnych systemach operacyjnych. Jednak koncepcja forka zasobu jest charakterystyczna dla komputerów Macintosh. Większość systemów operacyjnych używa pliku binarnego zawierającego zasoby, który jest następnie „przyczepiany” do końca istniejącego pliku programu. To rozwiązanie jest stosowane na przykład w systemie Microsoft Windows, a podobne rozwiązania są stosowane w systemie X Window, chociaż zasoby często są pozostawione jako osobny plik.

Windowsowy NTFS może obsługiwać forki (a więc może być serwerem plików dla plików Mac), natywna funkcja zapewniająca obsługę nazywana jest alternatywnym strumieniem danych (ADS). Funkcje systemu operacyjnego Windows (takie jak standardowa karta Podsumowanie na stronie Właściwości plików innych niż Office) i aplikacje Windows z nich korzystają, a Microsoft opracowywał system plików nowej generacji, który ma taką funkcję jako podstawę.

Wczesne wersje BeOS zaimplementowały bazę danych w systemie plików, która może być używana w sposób analogiczny do forka zasobu. Problemy z wydajnością doprowadziły do zmiany w późniejszych wersjach systemu złożonych atrybutów systemu plików. W ramach tego systemu zasoby były obsługiwane w sposób nieco bardziej analogiczny do komputera Mac.

AmigaOS nie używa forkowanych plików. Pliki wykonywalne są wewnętrznie podzielone na modułową strukturę dużych elementów (hunk) zdolnych do przechowywania kodu, danych i dodatkowych informacji. Podobnie pliki danych i projektów mają strukturę chunk’a skodyfikowaną w standardzie IFF. Inne typy plików są przechowywane podobnie jak u innych systemów operacyjnych. Chociaż nie jest to dokładnie fork zasobu, AmigaOS przechowuje metadane w plikach zwanych plikami.info. Pliki.info można rozpoznać po rozszerzeniu.info; na przykład, jeśli zapiszesz projekt na dysku, zostaną zapisane dwa pliki, MyProject i MyProject.info. MyProject byłby rzeczywistymi danymi projektu, a MyProject.info zawierałby ikonę projektu, informacje o tym, który program jest potrzebny do otwarcia projektu (ponieważ w AmigaOS nie ma powiązania aplikacji), specjalne opcje projektu i wszelkie komentarze użytkowników. Pliki.info są niewidoczne na pulpicie Amigi (Workbench). Ikona na pulpicie, zaczerpnięta z samego.info, jest metaforą interfejsu, poprzez którą użytkownik wchodzi w interakcję zarówno z samym projektem, jak i powiązanym z nim plikiem.info. Okno dialogowe dostępne po kliknięciu ikony prawym przyciskiem myszy pozwala użytkownikowi zobaczyć i zmodyfikować metadane obecne w pliku.info. Pliki.info mogą być widoczne jako pojedyncze pliki w interfejsie wiersza poleceń lub w menedżerze plików. Nowoczesne klony AmigaOS (AROS, MorphOS i AOS4) dziedziczą strukturę (wraz z metadanymi) plików.info starszych wersji AmigaOS, a także mogą akceptować standardowe pliki graficzne PNG jako mapy bitowe ikon w swoich plikach.info.

Systemy operacyjne NeXT NeXTSTEP i OPENSTEP, ich następca, macOS i inne systemy, takie jak RISC OS, zaimplementowały inne rozwiązanie. W tych systemach zasoby są pozostawione w oryginalnym formacie, na przykład obrazy są dołączane jako kompletne pliki TIFF zamiast być zakodowane w jakimś kontenerze. Zasoby te są następnie umieszczane w katalogu wraz z kodem wykonywalnym i „surowymi danymi”. Katalog (zwany „pakietem” lub „katalogiem aplikacji”) jest następnie przedstawiany użytkownikowi jako sama aplikacja. To rozwiązanie zapewnia taką samą funkcjonalność jak fork zasobu, ale umożliwia łatwą manipulację zasobami przez dowolną aplikację – „edytor zasobu” (jak ResEdit) nie jest potrzebny. Z interfejsu wiersza poleceń pakiet wydaje się być normalnym katalogiem. To podejście nie było opcją w klasycznym systemie Mac OS, ponieważ system plików (MFS) nie obsługiwał oddzielnych ścieżek katalogowych. Po włączeniu obsługi plików katalogu w systemie Mac OS z systemem plików HFS, fork zasobu został zachowany. macOS zachowuje klasyczny interfejs API Menedżera Zasobu jako część bibliotek Carbon dla kompatybilności wstecznej. Jednak same zasoby można teraz przechowywać w osobnych plikach danych w systemie plików – Menedżer zasobu ukrywa teraz tę zmianę implementacji przed kodem klienta.