Ressourcenfork

Ein Ressourcenfork ist eine Dateiabzweigung im klassischen Mac OS von Apple , die zur Speicherung strukturierter Daten dient. Er ist neben dem Datenfork , der Daten speichert , die das Betriebssystem als unstrukturiert behandelt, einer der beiden Forks einer Datei. ^{[ 1 ] : 1-4} Die Ressourcenfork-Funktionalität wurde aus Kompatibilitätsgründen in das moderne macOS übernommen .

Ein Ressourcen-Fork speichert Informationen in einer spezifischen Form und enthält Details wie Symbol-Bitmaps, Fensterformen, Definitionen von Menüs und deren Inhalten sowie Anwendungscode ( Maschinencode ). Jede Datei kann einen Ressourcen-Fork besitzen, nicht nur Anwendungen. Beispielsweise kann die Bildschirmposition eines Dokumentfensters als Ressource im Ressourcen-Fork des Dokuments gespeichert werden, getrennt vom Dokumentinhalt im Daten-Fork. ^{[ 1 ] : 1-5}

Das Konzept der Ressourcen und Ressourcenforks wurde vom Apple-Programmierer Bruce Horn entwickelt und implementiert . ^{[ 2 ]} Es wurde von der dynamischen und objektorientierten Programmierumgebung Smalltalk und insbesondere von dem objektorientierten virtuellen Speichersystem OOZE inspiriert, das von Ted Kaehler entworfen wurde . ^{[ 3 ]}

Im klassischen Mac OS dienten Ressourcen und Ressourcenforks mehreren Zwecken:

• Die RAM-Nutzung großer Datenmengen, wie z. B. Bitmaps , kann durch die Implementierung einer Form von virtuellem Speicher reduziert werden : Ressourcen können bei Bedarf von der Festplatte in den Speicher geladen und wieder entladen werden, wenn sie nicht mehr benötigt werden. ^{[ 3 ]}
• Es bietet Nicht-Programmierern die Möglichkeit, Internationalisierung und Lokalisierung durchzuführen oder die grafischen Elemente einer Anwendung zu ändern, ohne Zugriff auf den Quellcode zu benötigen. ^{[ 3 ] [ 1 ] : 1-3, 1-4}
• Die Finder -Desktopdatenbank, in der Dateitypzuordnungen und Symbole als Ressourcen gespeichert wurden, wurde gespeichert. ^{[ 3 ] [ 4 ]}
• Dadurch können Anwendungen nahezu alle ihre Komponenten in einer einzigen Datei verteilen, was die Unübersichtlichkeit reduziert und die Installation und Deinstallation der Anwendung vereinfacht.

Ressourcengabeln werden von allen Dateisystemen, die für Systemlaufwerke im klassischen Mac OS verwendet wurden ( MFS , HFS und HFS Plus ), sowie vom macOS -exklusiven APFS nativ unterstützt (jedoch nicht von UFS ^{[ 5 ]} , einer in frühen Mac OS X-Versionen unterstützten Option für Systemlaufwerke). Mithilfe einer Ressourcengabel lassen sich diverse Zusatzinformationen einfach speichern, beispielsweise ein Symbol , das auf dem Desktop für die jeweilige Datei angezeigt werden soll. Während die Datengabel den wahlfreien Zugriff auf jeden beliebigen Offset innerhalb ihrer Grenzen ermöglicht, funktioniert der Zugriff auf die Ressourcengabel wie das Extrahieren strukturierter Datensätze aus einer Datenbank .

Die Macintosh-Dateisysteme speichern Metadaten, die sich von den Daten- oder Ressourcenforks unterscheiden, wie z. B. Erstellungs- und Änderungszeitstempel, Dateityp- und Erstellercodes sowie Forklängen.

Manche Dateien besitzen nur einen Ressourcenzweig. Ein Beispiel hierfür ist eine Schriftartdatei im klassischen Mac OS. Ein weiteres Beispiel ist eine Classic- 68k- Anwendung, bei der sogar der ausführbare Code in Ressourcen vom Typ „CODE“ enthalten ist. Spätere PowerPC- Binärdateien speicherten den ausführbaren Code im Datenzweig.

Da Ressourcenforks nur auf Macintosh-Dateisystemen wie MFS, HFS, HFS Plus und APFS unterstützt wurden, konnten sie nicht auf die Dateisysteme anderer Betriebssysteme kopiert werden . Die Formate Mac BinHex und MacBinary wurden entwickelt, um Ressourcen- und Datenforks in einer einzigen Datei für den systemübergreifenden Austausch zu kodieren. A/UX unterstützte Ressourcenforks auf Unix-Dateisystemen über die Formate AppleSingle und AppleDouble . Ab Mac OS X Tiger wurde AppleDouble verwendet, um Ressourcenforks auf Dateisystemen wie Windows- SMB- Freigaben und FAT32- Volumes zu speichern.

Im HFS Plus-Dateisystem können Einstellungen vorgenommen werden, um neben den Daten- und Ressourcenforks auch andere Forks zuzulassen und so eine „Multi-Fork“-Anwendung zu erstellen. ^{[ 6 ]}

Am 7. August 2002 empfahl Apple Entwicklern, keine Ressourcen in Ressourcenforks in Mach-O- Binärdateien unter Mac OS X einzubauen. ^{[ 7 ]}

Jede Ressource besitzt einen OSType -Bezeichner (einen 4-Byte-Wert), eine ID (ein vorzeichenbehaftetes 16-Bit -Wort ) und optional einen Namen. Es gibt standardisierte Ressourcentypen für Dialogfelder ( Dialogfelder DITL), Bilder (Bilder PICT), Töne (Sounds snd ) und ausführbare Binärdateien ( ausführbare Binärdateien CODE), die bis zum Aufkommen des PowerPC- Prozessors ausnahmslos im Ressourcen-Fork gespeichert wurden. Unterprogramme zum Rendern von Fenstern werden in einem eigenen Ressourcentyp (Fenster WDEF) und Unterprogramme zum Rendern von Menüs in einem eigenen (Menü MDEF) gespeichert. Diese Struktur ermöglichte es Benutzern, nicht nur einzelne Anwendungen, sondern auch das Betriebssystem selbst mithilfe von Tools wie ResEdit einfach anzupassen und die Ressourcen einer Anwendungsdatei oder beliebiger Systemdateien zu modifizieren.

Innerhalb einer Anwendung oder anderen Codes können Ressourcen einfach durch eine Kombination aus Typ, ID oder Name geladen werden, unabhängig davon, wie und wo sie im Ressourcen-Fork gespeichert sind. Der Client erhält ein Handle zur geladenen Ressource, auf das wie auf andere Heap-basierte Daten zugegriffen werden kann. Die Betriebssystemkomponente, die dies ermöglicht, ist der Ressourcenmanager. Zusätzlich zur Abstraktion der Datenspeicherdetails ordnet der Ressourcenmanager offene Ressourcen-Forks in einem Stapel an, wobei die zuletzt geöffnete Datei oben liegt. Beim Laden einer Ressource wird zuerst im obersten Stapel gesucht (z. B. im Ressourcen-Fork des aktuellen Dokuments), dann im nächsten (im Ressourcen-Fork der Anwendung) und schließlich im nächsten (im System-Ressourcen-Fork). Diese Anordnung ist sehr leistungsstark – sie ermöglicht es lokalen Ressourcen, globale Ressourcen weiter unten zu überschreiben – sodass eine Anwendung beispielsweise eigene Symbole oder Schriftarten anstelle der Standard-Systemsymbole verwenden kann. Es ermöglicht einer Anwendung außerdem, Ressourcen aus dem System über dieselbe API wie jede andere Ressource zu laden, unabhängig davon, wo oder wie diese Ressource gespeichert ist – für die Anwendung sind alle Ressourcen gleichermaßen verfügbar und einfach zu verwenden. Das System reserviert Ressourcen-IDs in einem bestimmten Bereich, um daraus resultierende Ressourcenkonflikte zu vermeiden. Die APIs des Ressourcenmanagers erlauben dem Programmierer, den Stack zu bearbeiten und das Suchverhalten anzupassen.

Da sich Ressourcenforks mit einem Ressourceneditor wie ResEdit bearbeiten lassen, können sie zur Lokalisierung und Anpassung von Software verwendet werden . Die meisten Ressourceneditoren ermöglichen zudem die visuelle Bearbeitung von Daten. Unter macOS können Ressourcen während der Anwendungsentwicklung genutzt werden. Soll die Anwendung jedoch im UFS ( Unified File System) verwendet werden , lässt sich die gesamte Ressourcenfork mithilfe der Einstellung „Raw Resource File“ in die Datenfork verschieben. Die von Apple Inc. kostenlos bereitgestellten integrierten Entwicklungsumgebungen , darunter MPW (Multi-Processing Workstation) und die Apple Developer Tools , enthalten den Compiler Rez. ^{[ 1 ] :1–3} Dieser verwendet eine eigene Sprache, ebenfalls Rez genannt, mit der durch Kompilieren von Quellcode Ressourcenforks erstellt werden können . Ein Dekompiler, DeRez, mit dem Ressourcenforks wieder in Rez-Code umgewandelt werden können, ist ebenfalls enthalten.

In der Struktur des Ressourcen-Forks befindet sich eine Datenkomponente namens „Ressourcenkarte“, die die Positionen der Ressourcendatenelemente speichert. ^{[ 1 ] : 1–8} Dies ermöglicht den wahlfreien Zugriff auf Ressourcendaten anhand der definierten IDs und Namen. Der Ressourcen-Fork kann im Wesentlichen als aus drei Objekten bestehend betrachtet werden: dem Ressourcen-Header, der Ressourcenkarte und den Ressourcendaten selbst. ^{[ 1 ] : 1–4, 1–5} Tatsächlich ist jedoch jeder Datentyp eine hierarchische Struktur, die mehrere Datenelemente speichert. Das Format, in dem die Informationen in den Ressourcendaten gespeichert werden, wird anhand der Informationstypen, den sogenannten „Ressourcentypen“, definiert. Ressourcendaten verweisen häufig auf andere Datentypen.

Resource Forks erscheinen als das erweiterte Attribut com.apple.ResourceFork. ^{[ 8 ]}

Zuvor erfolgte der Zugriff auf Ressourcenforks über die „Resource Manager“ -API . Diese API ist nun veraltet. ^{[ 9 ]}

Unter der veralteten API:

1. Beim Zugriff auf einen Ressourcenzweig werden Daten, einschließlich der Startposition und Länge der Ressourcendaten und der Ressourcenzuordnung, aus dem Header eingelesen.
2. Wenn ein Ressourcentyp zum Einlesen angegeben wurde, wird geprüft, ob dieser Typ in der Ressourcenliste vorhanden ist. Anschließend wird die Anzahl der Datenelemente, die diesen Typ enthalten, sowie deren Offsets in der Ressourcenreferenzliste vom Startpunkt der Ressourcenzuordnung ermittelt.
3. Es werden die Ressourcen-ID, der Offset des Ressourcennamens, die Ressourceneigenschaften und der Offset der Daten von der Startposition der Ressourcendaten ermittelt.
4. Wenn Ressourcendaten mit der angegebenen ID oder dem angegebenen Namen vorhanden sind, wird auf den oben ermittelten Offset zugegriffen, die Datenlänge ermittelt und alle dort gespeicherten Daten werden eingelesen und als Rückgabewert zurückgegeben.

Dateimanager-APIs wie beispielsweise PBOpenRF()ermöglichten ebenfalls den Zugriff auf den rohen Ressourcenfork; sie sollten jedoch nur für Anwendungen wie das Kopieren einer Datei verwendet werden – Apple warnt ausdrücklich davor, den Ressourcenfork als „zweiten Datenfork“ zu verwenden. ^{[ 10 ] [ 1 ] : 1-5}

Über die POSIX- Schnittstelle konnte auf den Resource Fork mit filename/..namedfork/rsrcoder zugegriffen werden filename/rsrc; die kürzere Form wurde in Mac OS X v10.4 als veraltet markiert und in Mac OS X v10.7 vollständig entfernt . ^{[ 11 ]}

Die unten aufgeführten Typcodes werden, wie die oben genannten Datentypen, nicht nur als Typbezeichner für Resource Forks selbst verwendet: Sie dienen auch dazu, Dateien selbst zu identifizieren, Daten in der Zwischenablage zu beschreiben und vieles mehr.

Typen müssen 4 Byte lang sein, daher haben Typen wie snd und STR tatsächlich ein Leerzeichen (0x20) am Ende.

ResEdit

Kostenlos von Apple vertrieben. Kann zur visuellen Bearbeitung von Ressourcendaten verwendet werden. Bei bekannter Datenstruktur lassen sich verschiedene Datentypen visuell darstellen. Läuft nicht unter modernen macOS-Versionen.

Resorber

Teuer, aber beliebt, da es im Vergleich zu ResEdit für die visuelle Bearbeitung von viel mehr Datentypen verwendet werden kann.

HexEdit

Ein Binäreditor, der in der Praxis eher zum Bearbeiten des Datenzweigs als des Ressourcenzweigs verwendet wird.

ResKnife

Open-Source-Editor für Mac OS X ; wird nicht mehr weiterentwickelt.

Recycling

Ein macOS-Tool, das Ressourcen aus einem Resource Fork in separate Binärdateien extrahiert und dabei viele Typen in für die moderne Entwicklung geeignete Formate konvertiert. ^{[ 12 ]}

resource_dasm

Ein Open-Source-Ressourcenextraktor für macOS und Linux, der auch viele Ressourcen in moderne Formate konvertieren kann. ^{[ 13 ]}

ResForge

Ressourcen-Editor für macOS, der klassische Resource-Fork-Dateien und verwandte Formate bearbeiten kann. Kompatibel mit macOS 10.14 oder höher. Läuft nativ auf 64-Bit-Intel- und Apple-Silicon-Systemen. ^{[ 14 ]}

Da Resource Forks ein Mac-spezifisches Feature sind, haben sie zu Kompatibilitätsproblemen geführt, wenn Mac-Dateien auf Dateisystemen gespeichert werden, die Resource Forks nicht nativ unterstützen, wie z. B. FAT , wenn sie auf Netzwerkfreigaben gespeichert werden oder wenn sie auf andere Weise über ein Netzwerk übertragen werden, z. B. per E-Mail .

AFP unterstützt Resource Forks nativ. Viele AFP-Server verwenden intern Dateisysteme ohne Resource-Fork-Unterstützung und speichern Resource Forks daher auf andere Weise, beispielsweise in einer speziellen Datei oder einem Verzeichnis oder in einem alternativen Datenstrom . Dies geschieht serverseitig, sodass die Dateien auf der AFP-Freigabe aus Client-Sicht native Resource Forks aufweisen.

Das SMB- Protokoll unterstützt ein Dateimetadatensystem ähnlich den Mac-Forks, bekannt als alternative Datenströme , die macOS seit Mac OS X 10.6 standardmäßig verwendet, sofern sie vom SMB-Server unterstützt werden. In früheren Versionen von Mac OS X, einschließlich aktualisierter Versionen von 10.6, ist diese Funktion standardmäßig deaktiviert, kann aber manuell aktiviert werden. ^{[ 15 ]}

On volumes that do not natively support resource forks, extended attributes, or alternate data streams, such as local FAT file systems or NFSv3 network shares, macOS uses a technique called AppleDouble to store resource forks and other Mac-specific metadata. In this case, the data fork is written as a regular file, while the resource fork and metadata are written to a separate hidden file whose name is the original file name with "._" prepended. For example, "ExampleFile.psd" would contain the data fork and "._ExampleFile.psd" would contain the corresponding resource fork and metadata.

Compatibility problems can arise if Mac clients connecting to the same network share don't use the same way of storing resource forks. For example, if one client uses a protocol with native resource fork support like AFP, but another client connects via a protocol like NFSv3 that requires AppleDouble to store resource forks, the two clients may see different resource fork contents for the same file.

Another challenge is preserving resource forks when transmitting files using non-resource fork-aware applications or with certain transfer methods, including email and FTP. A number of file formats, such as MacBinary and BinHex, have been created to handle this. Command-line system tools SplitForks and FixupResourceForks allow manual flattening and merging of resource forks.

Carbon applications compiled for the Intel architecture may have byte order issues when working with resources, because most resource data is stored in big-endian byte order, as used by the 68000 and PowerPC architectures, which does not match the Intel architecture's little-endian byte order. While the operating system automatically handles these byte order differences for the overall resource fork format and for standard resource types like 'snd ' or 'moov', any resources with non-standard types must have their data byte-swapped manually to ensure consistent behavior regardless of architecture.^[16]

Until the advent of Mac OS X v10.4, the standard UNIX command-line utilities in macOS (such as cp and mv) did not respect resource forks. To copy files with resource forks, one had to use ditto or CpMac and MvMac.

Das Konzept eines Ressourcenmanagers für Grafikobjekte zur Speichereinsparung entstand im OOZE-Paket des Xerox Alto unter Smalltalk-76. ^{[ 17 ]} Dieses Konzept ist heute in fast allen modernen Betriebssystemen weit verbreitet. Die Verwendung von Ressourcenverzweigungen (Resource Forks) ist jedoch ein Alleinstellungsmerkmal des Macintosh. Die meisten Betriebssysteme nutzten eine Binärdatei mit den Ressourcen, die an das Ende einer bestehenden Programmdatei angehängt wurde. Diese Lösung wird beispielsweise für Windows-Ressourcen verwendet , und ähnliche Lösungen kommen beim X Window System zum Einsatz , obwohl die Ressourcen dort oft in einer separaten Datei gespeichert werden.

Das Windows NT NTFS unterstützt Forks (und kann somit als Dateiserver für Mac-Dateien dienen). Die dafür notwendige native Funktion heißt alternativer Datenstrom . Windows-Betriebssystemfunktionen (wie die standardmäßige Registerkarte „Zusammenfassung“ in den Eigenschaften von Nicht-Office-Dateien) und Windows-Anwendungen nutzen diese Funktion. Microsoft entwickelte ein Dateisystem der nächsten Generation , das auf dieser Funktion basiert.

Frühe Versionen von BeOS implementierten eine Datenbank innerhalb des Dateisystems, die ähnlich wie ein Resource Fork genutzt werden konnte. Leistungsprobleme führten in späteren Versionen zu einem System mit komplexen Dateisystemattributen. Unter diesem System wurden Ressourcen ähnlich wie beim Mac verwaltet.

AmigaOS verwendet keine verzweigten Dateien. Seine ausführbaren Dateien sind intern in eine modulare Struktur aus großen Blöcken ( Hunks ) unterteilt, die Code, Daten und zusätzliche Informationen speichern können. Auch Daten- und Projektdateien besitzen eine im IFF- Standard kodifizierte Blockstruktur . Andere Dateitypen werden ähnlich wie in anderen Betriebssystemen gespeichert. Obwohl AmigaOS nicht im eigentlichen Sinne ein Resource Fork ist, speichert es Metadaten in Dateien, die als .txt-Dateien bezeichnet werden. Diese Dateien lassen sich an ihrer Dateiendung identifizieren. Speichert man beispielsweise ein Projekt auf der Festplatte, werden zwei Dateien gespeichert: .txt und .txt. Die .txt-Datei enthält die eigentlichen Projektdaten, das Projektsymbol, Informationen darüber, welches Programm zum Öffnen des Projekts benötigt wird (da AmigaOS keine Anwendungsbindung kennt ), spezielle Projektoptionen und Benutzerkommentare. .txt-Dateien sind auf dem Amiga-Desktop ( Workbench ) unsichtbar. Das Symbol auf dem Desktop, das von der .txt-Datei selbst stammt, dient als Schnittstelle , über die der Benutzer sowohl mit dem Projekt selbst als auch mit der zugehörigen .txt- Datei interagiert. Ein Dialogfeld, das per Rechtsklick auf das Symbol aufgerufen werden kann, ermöglicht es dem Benutzer, die in der .txt-Datei enthaltenen Metadaten anzuzeigen und zu bearbeiten. Dateien können in der Kommandozeilenschnittstelle oder einem Dateimanager als einzelne Dateien angezeigt werden . Moderne AmigaOS-Klone ( AROS , MorphOS und AOS4 ) übernehmen die Struktur (einschließlich Metadaten) der Dateien älterer AmigaOS-Versionen und können auch Standard -PNG- Grafikdateien als Symbol-Bitmaps in ihren Dateien akzeptieren. .info.info.infoMyProjectMyProject.infoMyProjectMyProject.info.info.info.info.info.info.info.info

Die NeXT -Betriebssysteme NeXTSTEP und OPENSTEP , ihr Nachfolger macOS sowie andere Systeme wie RISC OS implementierten eine andere Lösung. Bei diesen Systemen bleiben die Ressourcen im Originalformat erhalten; beispielsweise werden Bilder als vollständige TIFF- Dateien eingebunden, anstatt in einen Container kodiert zu werden. Diese Ressourcen werden dann zusammen mit dem ausführbaren Code und den Rohdaten in einem Verzeichnis abgelegt. Dieses Verzeichnis (auch „ Bundle “ oder „ Anwendungsverzeichnis “ genannt) wird dem Benutzer als die Anwendung selbst präsentiert. Diese Lösung bietet dieselbe Funktionalität wie die Ressourcenabspaltung, ermöglicht aber die einfache Bearbeitung der Ressourcen durch jede beliebige Anwendung – ein Ressourceneditor (wie ResEdit ) ist nicht erforderlich. Über die Kommandozeile erscheint das Bundle als normales Verzeichnis. Dieser Ansatz war unter dem klassischen Mac OS nicht möglich , da das Dateisystem ( MFS ) keine separaten Katalogverzeichnisse unterstützte. Mit der Einführung der Katalogdateiunterstützung in Mac OS und dem HFS-Dateisystem wurde die Ressourcenabspaltung beibehalten. macOS behält die klassische Resource Manager API aus Gründen der Abwärtskompatibilität als Teil seiner Carbon- Bibliotheken bei. Die Ressourcen selbst können nun jedoch in separaten Datendateien im Dateisystem gespeichert werden – der Resource Manager verbirgt diese Implementierungsänderung nun vor dem Clientcode.

• Fork (Dateisystem)

• Beschreibung des Ressourcendateiformats
• Apple-Entwicklerdokumentationsarchiv: Referenz zum Ressourcenmanager
• Apple-Entwicklerdokumentationsarchiv: Leitfaden zur Bundle-Programmierung
• Mac OS X-Dienste  – Ein Mac OS X-Dienst zum Löschen der Ressourcenabspaltung einer Datei über das Kontextmenü
• Was hat es mit Mac OS X Resource Forks, erweiterten Attributen, NTFS-Streams und Dot-Underscore-Dateien auf sich?
• Wenn ich eine Datei über das SMB-Protokoll speichere, welche Informationen werden in den „._“-Dateien gespeichert? Wie werden diese Informationen auf einem NTFS-Dateisystem gespeichert?