Sign in to follow this  
Guest

NUOVE iAPPLICAZIONI su X - impressioni d'uso e suggerimenti

Recommended Posts

Guest

<font color="ff0000">questa citazione viene dal knowledge base di microsoft nr 243693

"The Macintosh operating system stores resource information, such as the file's creator and file type, in the resource fork." </font>

Il knowledge base di Microsoft farebbe bene a occuparsi di Windows, invece che di Mac.

Questa è la schermata di info di File Buddy per un comune file di Excel.

Posted Image

Si vede benissimo come il resource fork sia vuoto (0 bytes) mentre il file possiede le informazioni sia sul tipo che sul creatore.

Informazioni che, evidentemente, non vengono memorizzate nel resource fork.

Notare che l'esempio è stato fatto in OS9, non in OSX.

Share this post


Link to post
Share on other sites
Guest

Andiamoci piano....

pero' Creatore e Tipo non sono contenuti nella risorsa BNDL?

Share this post


Link to post
Share on other sites

Camillo >Kiko: A spanne e sperando di non dire castronerie, in un file il resource fork contiene i dati di individuazione del file stesso (applicazione che l'ha generato, percorso....)

Niente di questo.<

Ok, è un semplice no ma poiché ho detto una castroneria me ne devo stare zitto zitto o devo rifare la domanda per sapere che cavolo è, non è o sembra che sia il resource fork?

Dai post seguenti (l'iconoclastica domanda) non ho trovato lumi...

Ciao

Share this post


Link to post
Share on other sites
Guest

Intendo per le applicazioni che devono avere la risorsa BNDL.

Per i files l'associazione tipo/creatore avviene a livello di desktop file. Infatti se si corrompe il desktop file, i files perdono l'icona rappresentativa e non vengono aperti con il doppi click ( parlo di os 9) ma ricostruendo al scrivania (cioe' ricostruendo il database delle associazioni) tutto torna a posto

Share this post


Link to post
Share on other sites
Guest

La risorsa BNDL in OS9 e precedenti riguarda le applicazioni e, credo, non i documenti.

Contiene la Signature dell'applicazione (per esempio 8BIM per Photoshop) e un elenco di tutti i tipi di file, con le relative icone, che quella applicazione può gestire.

Per rimanere all'esempio di Photoshop, nella risorsa BNDL troviamo moltissimi tipi di file, PICT, TIFF, JPEG, EPSF etc.

Share this post


Link to post
Share on other sites
Guest

ah, per zippare:

si chiama "zip tools"

cercare su versiontracker

Share this post


Link to post
Share on other sites

Ho installato ieri sera iChat AV beta.

Stamattina noto che non sento i suoni.

Ho una scheda sonora M-Audio Revolution 7.1 PCI.

Vado nel Pannello a controllare ma non è cambiato niente, la scheda è selezionata come output in entrambi i pannelli.

Apro iChat AV e vedo nelle pref che si può selezionare il dispositivo di uscita.

Era su built-in lo metto su Revolution.

Niente, tutto muto dalla scheda.

La scheda non si è bruciata, l'ingresso mic funziona.

Ora la probabilità che l'installazione di iChat AV abbia toccato qualcosa nell CoreAudio che il driver della scheda non gradisce è piuttosto elevata.

Soluzioni? Suggerimenti?

Grazie.

Share this post


Link to post
Share on other sites
Guest

<font color="119911">Soluzioni? Suggerimenti? </font>

Digli di ritornare alla "vecchia" versione di iChat. C'è una voce apposita nel Menu di iChat!

Share this post


Link to post
Share on other sites

Nalin: <font color="ff0000">Non si può. Comunque Camillo ti abbiamo scoperto! Che computer nuovo hai comprato?</font>

??? O.o

Massimo: <font color="aa00aa">Come vedi Mail codifica il file allegato in 3 parti che su PC non vengono piu' riconosciute.</font>

In realtà, il messaggio di Mail è diviso in due parti (testo e attachment), esattamente come quello di Entourage; l'attachment è a sua volta diviso in due parti, secondo il formato AppleDouble. Una di queste due parti è il data fork, che è identico all'attachment di Entourage.

Sono sorpreso che Notes non gestisca la codifica AppleDouble, sia perché non è certo una novità, sia perché sarebbe sufficiente eseguire ricorsivamente il parser multiparte MIME, che viene usato per separare l'attachment in ogni caso. Mah, aggiungiamola all'elenco di cose brutte che ho sentito dire di Notes... ~_~

Ciò non toglie, ovviamente, che Apple dovrebbe permettere di scegliere la codifica da utilizzare.

Fish: <font color="aa00aa">PS. Camillo questa citazione viene dal knowledge base di microsoft nr 243693

"The Macintosh operating system stores resource information, such as the file's creator and file type, in the resource fork."

Che dire?</font>

Stendiamo un telone pietoso.

Nalin: <font color="ff0000">CAMILLO HA TOPPATO?! Sembra di no per fortuna</font>

PALESE modifica fatta dopo il messaggio di Luciano. Vergonga!!! ¬_¬

Luciano: <font color="ff6000">Si vede benissimo come il resource fork sia vuoto (0 bytes) mentre il file possiede le informazioni sia sul tipo che sul creatore.</font>

Ottimo. ^__^

<font color="ff6000">Informazioni che, evidentemente, non vengono memorizzate nel resource fork.</font>

Infatti stanno nella directory del volume, insieme a tutti gli altri attributi del file (nome, data di creazione, data di modifica, flags etc.).

<font color="ff6000">Notare che l'esempio è stato fatto in OS9, non in OSX.</font>

Vale anche per OS X, naturalmente se si utilizzano volumi HFS o HFS+. Con altri tipi di file system, originari di altre piattaforme (es. FAT, UFS), gli attributi specifici del Mac vengono memorizzati in file invisibili gestiti dal sistema in modo trasparente per le applicazioni.

Massimo: <font color="aa00aa">Andiamoci piano....

pero' Creatore e Tipo non sono contenuti nella risorsa BNDL?</font>

Se scrivo 'TIFF', in questo messaggio è contenuto il tipo dei file TIFF. E allora? :P

La risorsa BNDL, presente nelle applicazioni, identifica i tipi di file gestiti da quell'applicazione e assegna ad essi le icone corrispondenti. Per questo motivo, ovviamente, fa riferimento alla firma dell'applicazione (cioè il suo codice creatore) e ai vari tipi di file, ma non per questo li determina.

Kiko: <font color="119911">Ok, è un semplice no ma poiché ho detto una castroneria me ne devo stare zitto zitto o devo rifare la domanda per sapere che cavolo è, non è o sembra che sia il resource fork?</font>

Il resource fork è una sequenza di byte di lunghezza variabile, esattamente come il data fork. A differenza di quest'ultimo, però, utilizza (per solida convenzione, non per necessità assoluta) un formato che lo rende una sorta di database, adatto a memorizzare piccoli blocchi di informazione identificati da un tipo e da un numero identificatore (ed eventualmente da un nome), detti risorse. L'accesso a questo database è gestito da una parte del Mac OS chiamata Resource Manager.

Fish: <font color="aa00aa">Intendo per le applicazioni che devono avere la risorsa BNDL.

Per i files l'associazione tipo/creatore avviene a livello di desktop file.</font>

<font size="-2">*cough*lasciaperdere*cough*</font>

Il tipo e il creatore di un file sono contenuti nella directory del disco (su file system HFS/HFS+) e sono *sempre* presenti, proprio come il nome o la data di modifica.

Il desktop database (che da un pezzo non è più un singolo file) non è altro che una cache delle informazioni contenute nelle risource BNDL, FREF, kind, ICN#, etc. etc. etc. delle applicazioni.

<font color="aa00aa">Infatti se si corrompe il desktop file, i files perdono l'icona rappresentativa e non vengono aperti con il doppi click ( parlo di os 9) ma ricostruendo al scrivania (cioe' ricostruendo il database delle associazioni) tutto torna a posto</font>

Un file è sempre associato al suo tipo e all'applicazione che lo ha creato.

Il problema è che quando il Finder deve aprire un file, o anche semplicemente visualizzarne l'icona (che non è contenuta nel file, ma proviene dall'applicazione - a meno che non si tratti di un'icona personalizzata), non può certo mettersi a cercare tutte le applicazioni sul disco e a controllare le loro risorse. Per questo motivo, il sistema mantiene una cache, chiamata desktop database, che memorizza la posizione dell'applicazione associata a ciascun codice di creatore, nonché una copia di tutte le informazioni sui tipi di file gestiti, sulle icone etc., estratte dall'applicazione stessa.

Se questa cache si scassa, il Finder ha dei problemi a trovare l'icona da visulizzare per i file con un certo tipo e creatore, o a trovare l'applicazione con cui aprire i file che hanno un certo creatore, etc.. Tuttavia, queste informazioni sono ancora tutte presenti sul disco: il tipo e il creatore dei file sono intatti, mentre le informazioni sulle applicazioni sono contenute nelle risorse al loro interno. Per questo motivo è sufficiente effettuare una scansione dell'intero disco, estraendo le risorse appropriate dalle applicazioni (e anche dalle estensioni, dai pannelli di controllo etc.), per ricostruire la cache. Questa operazione è chiamata "ricostruzione della scrivania".

Share this post


Link to post
Share on other sites
Guest

Comunque, questi sono i file installati dalla 2.0:

/Applications/iChat.app

/System/Library/CoreServices/Menu Extras/iChat.menu

/Library/Audio/Plug-Ins/HAL/QuickTimeIIDCAudio.plugin

/System/Library/Components/VCH263Codec.component

/System/Library/CoreServices/SystemUIServer.app

/System/Library/PrivateFrameworks/InstantMessage.framework

/System/Library/PrivateFrameworks/VideoConference.framework

/System/Library/QuickTime/QuickTimeIIDCDigitizer.component

/Library/Receipts/Surf.pkg

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this