Sign in to follow this  

Recommended Posts

OK Camillo...

Facci tu un articolo al proposito e lo pubblichiamo. Molti (tutti) non hanno la tua competenza in merito e forse potrebbe essere utile ai lettori e anche a noi.

Share this post


Link to post
Share on other sites

Grazie Camillo, ma dove e' scritto che "non" sono cittadini a pari diritto?

Se ci sono delle imprecisioni o degli sbagli nei nostri articoli ti invitiamo a segnalarceli (magari direttamente - i nostri email sono pubblici)... la collaborazione dei lettori e' fondamentale... anche perche' i nostri articoli rimangono in linea per mesi e in questi casi la permanenza equivale alla perseverazione in un possibile errore.

Share this post


Link to post
Share on other sites
Guest

Settimio, non ti so dire un articolo su macity, ma è vero che spesso quando si leggono articoli su MacOS X o sul porting di applicazioni, si intuisce che Carbon viene vista come una sorta di 'emulazione' con prestazioni ridotte e Cocoa come il 'vero' ambiente nativo. In effetti non c'è nessun motivo per cui questo sia vero... Ma Camillo 'Carbon Dev. List' Lugaresi ;-) può essere sicuramente più preciso, visto che per adesso mi manca il tempo per approfondire di più la cosa ... non ho ancora neanche installato l'aggiornamento di Codewarrior :-(

Share this post


Link to post
Share on other sites
Guest

La risposta tutti i dubbi e’ in SystemOverview.pdf di Apple.

Il capitolo 3 “System Architecture†spiega nel dettaglio il ruolo dei diversi ambienti di sviluppo e di funzionamento disponibili in OS X.

In esterma sintesi OS X dispone di 5 ambienti “applicativiâ€: Classic, Carbon, Cocoa, Java e BSD.

Classic permette il funzionamento delle applicazioni scritte per mac OS 9 e proprio per questo non supporta le caratteristiche specifiche di OS X quali la memoria protetta e il multitasking preemptive ne’ l’interfaccia Aqua.

Carbon e’ un ambiente basato su un set di API derivato da quelle del vecchio Mac OS in modo che possa nativamente lavorare in OS X. Apple dice che contiene il 70% delle funzioni del vecchio mac OS e che queste sono il 95% di quelle utilizzate dalle applicazioni piu’ comuni. Quindi permette di fare girare le applicazioni per OS 8 e 9 il cui codice e’ stato “rimesso a modello†sostituendo le chiamate alle funzioni eliminate e che cosi' beneficiano delle caratteristiche specifiche di OS X quali la memoria protetta e il multitasking preemptive.

Cocoa è un ambiente basato su set di API nuovo, object oriented, cui ci si interfaccia in Objective C o in Java. Apple lo definisce “un ambiente di programmazione object oriented avanzato con cui creare le migliori applicazioni del futuroâ€.

Java e’ un ambiente basato su un set di classi con i suoi tools di sviluppo, la sua Virtual Machine e il suo Just in time compiler.

Quindi c’e’ da aspettarsi che nell’immediato molte applicazioni vengano “carbonizzate†in modo da essere immediatamente disponibili per OS X, mentre in futuro le nuove applicazioni scritte da zero, saranno sviluppate con e per Cocoa.

Share this post


Link to post
Share on other sites
Guest

...io ho fatto "cocoa"...

...Ma dalle nostre parti era COmplementi di COntrolli Automatici...

:-)

(come sempre Off topic)

renzo

Share this post


Link to post
Share on other sites
Guest

<FONT COLOR="ff0000">“un ambiente di programmazione object oriented avanzato con cui creare le migliori applicazioni del futuroâ€</FONT>

Mi dici dove è scritto? visto che nel capitolo 3 non riesco a vedere una frase del genere.

Hai dimenticato anche il layer BSD ;-)

La situazione è questa:

Se se un programmatore Macintosh la via più semplice è probabilmente usare Carbon sia per il porting di applicazioni preesistenti sia per nuove applicazioni, in questo modo non sei obbligato a partire da zero e ad imparare nuove API. Ho anche l'impressione che Carbon piano piano si stia evolvendo in qualcosa di più rispetto agli obiettivi originali, ma Camillo ne sa sicuramente più di me.

Se sei uno sviluppatore Next o 'nuovo' per il mondo Mac , Cocoa dovrebbe consentire uno sviluppo più veloce grazie alla sua 'fondazione' a oggetti. Come linguaggi puoi usare sia java che objective-c

Se sei uno sviluppatore java puoi scegliere di usare cocoa oppure l'ambiente 'java' con una virtual machine più classica

Se sei uno sviluppatore unix puoi usare il layer BSD (anche se è un po' in disparte rispetto agli altri ambienti) e per il front-end grafico utilizzare uno degli altri ambienti a scelta. E' la soluzione scelta per Webstar 5, ad esempio, ed è un'applicazione nuova nata e pensata per MacOS X

La cosa importante è che tutti questi ambienti hanno la stessa 'dignità' e proprio questo è uno degli obiettivi più ambiziosi del 'progetto MacOS X: un utente finale non dovrà sapere se un'applicazione gira con Carbon, Cocoa o Java, nè dal punto di vista dell'uso, nè da quello delle prestazioni, sarà lo sviluppatore a scegliere l'ambiente 'preferito'.

Share this post


Link to post
Share on other sites
Guest

<FONT COLOR="ff0000">Ma dalle nostre parti era COmplementi di COntrolli Automatici</FONT>

questo mi ricorda un PACCO sviluppato (anche) da alcuni miei amici. ;-)

Share this post


Link to post
Share on other sites

Settimio: <FONT COLOR="ff0000">"Cocoa non e' soltanto il nome attribuito per la programmazione nativa in Mac OS X [...]"</FONT>; <FONT COLOR="ff0000">"[...] Cocoa saranno le applicazioni scritte appositamente per il "decimo" sistema operativo del Mac; Carbon saranno quelle applicazioni parzialmente riscritte per poter funzionare ed usufruire di <U>alcune</U> potenzialita' di Mac OS X [...] "</FONT>

Massimo Senna: hai centrato il punto, le diverse API hanno tutte la stessa dignità, e tutte possono essere utilizzate per realizzare nuovi prodotti.

Questo vale anche per Carbon, a tal punto che è in corso di sviluppo un intero nuovo modello di gestione degli eventi (Carbon Event Model), che naturalmente non serve a chi deve solo portare un programma "classico" su Mac OS X. Questo nuovo modello di eventi è la base di una sorta di framework che fa sì che anche con Carbon il sistema si faccia carico della gestione delle funzioni di base di un'applicazione e dei comportamenti standard dell'interfaccia.

Share this post


Link to post
Share on other sites
Guest

Massimo Senna> Infatti non lo trovi nel capitolo 3 peche' l'ho letto nel capitolo 2 "System Technologies" a pagina 20....

Il bel disegnino sempre tratto dal citato SystemOverview di Apple dovrebbe chiarire in modo sintetico il ruolo dei diversi ambienti:

Posted Image

Share this post


Link to post
Share on other sites
Guest

Hello,

Qualcuno ha idea di come funzioni il discorso delle risorse (menu, dialog, stringhe, ecc) in Mac OS X?

Quale la struttura e quali i programmi.

E la documentazione?

Grazie

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