b'\n_START_ARTICLE_\nResource fork\n_START_PARAGRAPH_\nLa resource fork \xc3\xa8 una delle due parti di cui sono costituiti i file del sistema operativo Mac OS (l\'altra \xc3\xa8 la data fork); la resource fork \xc3\xa8 usata per memorizzare dati strutturati, mentre la data fork contiene una semplice sequenza di byte, e corrisponde quindi al modello dei file di UNIX._NEWLINE_Il sistema dei fork \xc3\xa8 implementato su tutti i file system usati per i dischi di sistema del Macintosh: MFS, HFS e HFS Plus. Progettato originariamente da Bruce Horn per la prima versione del Mac OS, il sistema dei fork divenne immediatamente una caratteristica molto usata dai programmatori. Sebbene le resource fork siano usate prevalentemente nei file eseguibili (per esempio, per contenere le icone usate dall\'applicazione), non c\'\xc3\xa8 nulla nel sistema che restringa il loro impiego, e qualunque file pu\xc3\xb2 avere una resource fork. Per esempio, un word processor potrebbe memorizzare il testo di un documento nella data fork, e le immagini contenute nello stesso documento nella resource fork del file che memorizza il documento._NEWLINE_In altri casi, la resource fork viene usata per memorizzare metadati su un file (autore, icona, ecc.). Il file sistem del Macintosh dispone comunque di un\'area separata per memorizzare i metadati, distinta sia dalla resource fork che dalla data fork, il cui accesso \xc3\xa8 particolarmente veloce. Tuttavia lo spazio disponibile in quest\'area, che \xc3\xa8 incorporata nello spazio di memorizzazione delle directory, \xc3\xa8 alquanto limitato, e tipicamente contiene soltanto le date di creazione e modifica, il tipo di file e il codice del suo creatore, la lunghezza delle fork, e il nome del file stesso._NEWLINE_Alcuni tipi di file hanno soltanto una resource fork. Per esempio, i file eseguibili per Motorola 68000 contengono il codice eseguibile fra le risorse (con tipo \'CODE\', codice). Al contrario, i file eseguibili per PowerPC memorizzano il codice nella data fork.\n_START_SECTION_\nDettagli sulla tecnologia Macintosh\n_START_PARAGRAPH_\nIl sistema operativo del Macintosh offre numerosi servizi per l\'interfaccia grafica. Molte delle strutture dati usate per questi servizi, e in particolare quelle usate per descrivere gli elementi della GUI come icone, menu e finestre, sono memorizzati in formati con strutture definite note come risorse. Le risorse sono memorizzate su disco nella resource fork del file che contiene l\'eseguibile dell\'applicazione relativa (o anche di un qualunque altro file, bench\xc3\xa9 si tratti di un uso raro). Il sistema operativo del Mac consente l\'accesso alla data fork con modalit\xc3\xa0 analoghe a quelle degli altri sistemi operativi (apertura del file, spostamento a un offset indicato, lettura di dati sotto forma di sequenza di byte). Al contrario, l\'accesso alla resource fork \xc3\xa8 pi\xc3\xb9 simile all\'estrazione dei dati da un database: si indica a quale risorsa si vuole accedere, e il sistema operativo provvede a ricercarla nella resource fork del file e a caricarla in memoria.\n_START_SECTION_\nProblemi di compatibilit\xc3\xa0\n_START_PARAGRAPH_\nLa suddivisione dei file in due fork ha sempre causato problemi di compatibilit\xc3\xa0 con altri file system. Per inviare un file Macintosh _NEWLINE_attraverso una rete o un altro mezzo (nastri, dischi, ecc.), la data fork e la resource fork devono essere serializzate insieme, in modo da ottenere un unico file. Tuttavia, questa operazione rende anche i file contenenti tipi di dato standardizzati (per esempio, un testo ASCII) incompatibili con l\'equivalente file UNIX o Windows. Sono stati sviluppati negli anni numerosi formati specializzati, fra cui MacBinary e BinHex che definiscono il modo in cui questa serializzazione viene fatta; naturalmente, \xc3\xa8 poi necessario un tool corrispondente per trasformare il file serializzato in un nuovo file con due fork (sul Mac) o in due file distinti, contenenti ciascuno una delle fork (altri sistemi). Lo stesso problema si verifica con il file server di rete; tipicamente i file server UNIX aggirano l\'ostacolo memorizzando le resource fork dei file scritti da un Mac in una directory nascosta._NEWLINE_Fino all\'uscita di macOS v10.4, i comandi UNIX forniti dal Mac OS X (come cp e mv) non rispettavano le resource fork, che venivano cos\xc3\xac perse \xe2\x80\x94 in alcuni casi distruggendo in effetti il file. Erano tuttavia forniti altri comandi, distinti da quelli standard, per compiere le stesse operazioni.\n_START_SECTION_\nAltri sistemi operativi\n_START_PARAGRAPH_\nIl concetto di risorsa \xc3\xa8 ormai di uso comune in tutti i moderni sistemi. Nonostante ci\xc3\xb2, il concetto di resource fork rimane legato solamente ai sistemi Mac. La maggior parte dei sistemi utilizzano un file binario che contiene le risorse, che viene poi "attaccato" alla fine di un file di programma gi\xc3\xa0 esistente. Questa soluzione \xc3\xa8 utilizzata in Microsoft Windows, per esempio, e soluzioni simili vengono utilizzate con sistemi X Window, anche se spesso le risorse vengono lasciate in un file separato._NEWLINE_Nonostante il formato NTFS di Windows NT possa supportare le fork (e quindi possa essere un file server per file Mac), la caratteristica che fornisce tale supporto, chiamata "alternate data stream", non \xc3\xa8 mai stata utilizzata intensivamente e sicuramente mai come una vera resource fork. Comunque, le caratteristiche del sistema operativo Windows (come il pannello standard Sommario nella pagina delle propriet\xc3\xa0 per file non-Office) e i programmi Windows le stanno utilizzando pi\xc3\xb9 spesso adesso, e Microsoft sta sviluppando un file system di nuova generazione che ha questa caratteristica alla sua base._NEWLINE_Le prime versioni di BeOS implementavano un database integrato nel file system che poteva essere usato in maniera analoga al resource fork. Problemi di efficienza portarono a modificare questo approccio nelle release successive ad un sistema pi\xc3\xb9 complesso di attributi del file system. Mediante questo sistema le risorse venivano gestite in modo pi\xc3\xb9 simile a quanto avviene nel Mac._NEWLINE_AmigaOS non fa uso dei fork e resource. Il formato eseguibile di Amiga spezza il file eseguibile in tanti hunk o grosse porzioni di dati dove sono presenti di seguito, codice e dati, alcuni tipi validi di hunk sono: HUNK_UNIT, HUNK_NAME, HUNK_CODE, HUNK_DATA, eccetera. L\'eseguibile viene riconosciuto tramite un magic cookie $000003f3 posto all\'inizio del file, detto anche in Unix magic number. Di seguito viene il numero di hunk in cui \xc3\xa8 composto il file, il numero progressivo degli hunk partendo da 0 e infine, prima che inizino gli hunk veri e propri vi \xc3\xa8 la tabella con la grandezza dei vari hunk presenti nel file eseguibile._NEWLINE_Amiga registra anche dei metadati in file noti come .info (dal nome della loro estensione), sebbene non siano esattamente equivalenti ai resource fork. Ad esempio: salvando un progetto su disco, vengono salvati due file, MyProject e MyProject.info. In MyProject saranno registrati i dati veri e propri del progetto, mentre in MyProject.info saranno contenute, l\'icona del progetto, e l\'informazione riguardante quale programma \xc3\xa8 quello originale (oppure quello preferito dall\'utente) per aprire il progetto (in AmigaOS non esiste l\'application binding), inoltre le opzioni particolari del progetto ed i commenti dell\'utente. I file .info sulla scrivania dell\'Amiga non appaiono come file a s\xc3\xa9 ma l\'icona stessa, estratta dall\'interno dell\'info cui si riferisce, essendo visibile sulla scrivania, \xc3\xa8 il medium che interconnette fisicamente l\'info con il file dati che gli appartiene. La pressione del tasto destro del mouse sull\'icona, apre una finestra di input che permette di leggere o modificare i metadati. Per visualizzare i file info come file a s\xc3\xa9, questi devono essere visualizzati usando la riga di comando o tramite un file manager. L\'utente pu\xc3\xb2 anche fare a meno del file info, cancellandolo, rinunciando per\xc3\xb2 alla comodit\xc3\xa0 dell\'icona e dei metadati. I cloni moderni dell\'Amiga (AROS, MorphOS e AmigaOS4.0) possono anche accettare file grafici standard PNG come immagine dell\'icona del file .info._NEWLINE_Forse la migliore soluzione al problema \xc3\xa8 stata implementata sul sistema operativo NeXTSTEP e sul suo successore macOS, oltre ad altri sistemi come RISC OS. In questi sistemi le risorse sono lasciate nella loro forma originaria, ad esempio le immagini, anzich\xc3\xa9 essere codificate in qualche specie di contenitore, sono incluse come interi file TIFF. Le risorse vengono poi poste in un direttorio usando un file system Unix assieme al codice eseguibile. Il direttorio, chiamato bundle (pacchetto), viene poi presentato all\'utente come l\'applicazione stessa._NEWLINE_Questa soluzione fornisce tutte le funzionalit\xc3\xa0 della resource fork, ma permette una facile manipolazione delle risorse da qualsiasi applicazione, non \xc3\xa8 pi\xc3\xb9 quindi necessario un editor delle risorse come ResEdit. Da riga di comando il bundle appare come un normale direttorio. Questa approccio non fu possibile per il Mac OS originale dato che il file system MFS non supportava i direttori e le cartelle. Mac OS X mantiene le API del gestore delle risorse classico come parte delle librerie Carbon per la retrocompatibilit\xc3\xa0. Comunque, le stesse risorse possono ora essere registrate in file di dati separati all\'interno del file system dato che il gestore delle risorse ora nasconde questa implementazione dal codice utilizzatore.'