Capitolo 002 - Il Sistema Operativo

Vado via veloce, giusto per avere un'idea...

Sorgenti: Leggo, traduco e riassumo dai documenti OSX Technology Overview e Cocoa Fundamentals di Apple.

Primo inserimento: Settembre-Ottobre 2001. Parziale riscrittura: 24 settembre 2006.

System Overview

Programmare per Mac Os X richiede almeno una minima conoscenza del sistema operativo. Senza pretendere di essere esaustivo, corretto e soprattutto particolarmente originale, ho saccheggiato a piene mani il documento Mac Os X Technology Overview, cui rimando i più coraggiosi.

Cipolle

Il tipico modello cognitivo utilizzato per esporre architetture informatiche molto strutturate è la classica cipolla. Come in una cipolla ci sono diversi strati, uno sopra l'altro, che partono dal cuore della cipolla e via via crescono verso l'esterno, l'ambiente operativo di Mac Os X si può descrivere come una cipolla.

I diversi strati, chiamati layer, partono dal cuore. Il primo layer, quello più interno, è infatti chiamato Core OS: qui si trova il kernel, i driver dei vari dispositivi ed i comandi di basso livello del sistema operativo. Qui risiede Darwin, una sorta di cappello per tutta una serie di tecnologie, che può essere considerato a tutti gli effetti un sistema operativo della famiglia Unix, nella sua variante BSD. Darwin è open-source (nel senso che il codice sorgente è disponibile a tutti per miglioramenti e modifiche) ed è utilizzabile anche da solo. Tra le varie tecnologie incorporate in Darwin c'è Mach, elemento di base di tutta la faccenda, che provvede ad una serie di servizi di base (memoria protetta, gestione del multi-tasking, memoria virtuale, supporto real-time) senza i quali nulla funzionerebbe; c'è il sottosistema BSD, che fornisce comandi di basi per la gestione dei processi, della politica degli accessi ed il supporto di base per la rete; ci sono i driver dei dispositivi (mouse, tastiera, eccetera); c'è il supporto dei vari file system (molti, e non solo quelli tipici di Apple, ma anche Unix e Windows, anche se mi irrita l'impossibilità di scrittura su NTFS); c'è il supporto per i servizi di base della rete.

Il layer successivo è chiamato Core Services. Si tratta in pratica di una libreria di funzioni a disposizione di tutti (non solo del sistema operativo, ma anche e soprattutto delle applicazioni) per la gestione di tipi di dati astratti (stringhe, ad esempio, ma anche URL, dati XML, le Preferenze, eccetera). è (dovrebbe essere) altamente ottimizzata, ed alla base di ogni possibilità di scambiare informazioni tra applicazioni e sistema operativo. In pratica, all'interno dello strato Core Services si trovano tutte quelli funzioni che non hanno a che fare con l'interfaccia grafica. Lo strato cerca di dare un'aspetto più pulito e maneggiabile alle funzioni messe a disposizione dal kernel. Se ad esempio nel kernel ci sono tutte le chiamate per gestire i file (aprire un file, chiudere un file, eccetera, ad un livello molto basso), nei Core Service si trova il File Manager, che fa le stesse cose in maniera più pulita, e combina opportunamente il tutto per rendere più facile la programmazione.

Il passo successivo è in realtà bipartito, perché si trovano due layer in parallelo. Il primo si chiama Application Services, e raccoglie tutta una serie di tecnologie che possono essere utilizzate in maniera uniforme da chiunque. In questo modo, applicazioni diverse riutilizzano gli stessi componenti software per eseguire le stesse cose (che so, visualizzazione di pagine HTML attraverso il WebKit, sistemi di ricerca attraverso il Search Kit, cose del genere), con grande beneficio per l'utente finale, che non deve imparare modi diversi per fare le stesse cose. Il secondo è chiamato Graphics And Multimedia, e come si evince dal nome raccoglie tutte le tecnologie per la visualizzazione 2D e 3D delle informazioni, compresa Quicktime (e quindi anche tutto l'audio). Si tratta di un layer bello corposo, in quanto rientrano appunto QuickTime, Open GL, ma anche Core Audio e Core Video, i sistemi di stampa, ColorSync, eccetera. Questi due layer forniscono in pratica tutto ciò che occorre ad una applicazione per interagire con un utente a livello schermo, audio e video.

L'ultimo layer di interesse è finalmente lo Application Environment, che chiamerò in italiano l'ambiente applicativo, all'interno del quale si possono sviluppare le applicazioni Macintosh. È da qui che, per la maggiornanza degli sviluppatori, si parte per lo sviluppo dell'applicazione. In realtà non esiste un solo ambiente applicativo, ma ne esistono diversi, a seconda delle tecnologie utilizzate: Carbon, Cocoa, Java, Applescript, BSD/X11 e WebObjects (una volta, e per qualcuno è ancora disponibile, esisteva un ulteriore ambiente, chiamato Classic, dove programmare per Max OS 9). Questi ambienti applicativi forniscono i diversi mattoncini con cui si possono costruire le applicazioni. Un programmatore più decidere di usare i mattoncini di tipo BSD per fare la propria applicazione, un altro può scegliere i mattoncini di tipo AppleScript, un terzo Carbon. Io invece ho scelto i mattoncini di tipo Cocoa (ma ci saranno invasioni di campo, o meglio, di vari altri campi).

Costruire un ambiente applicativo è lo scopo finale di un sistema operativo. Un sistema operativo copre fondamentalmente i dettagli operativi del calcolatore sul quale risiede, nascondendo appunto le varie differenze hardware, interagendo con il mondo esterno, e mascherando il tutto attraverso una API, Application Programmatic Interface (qualcosa del genere), in pratica una collezione di funzioni che permettono il funzionamento delle applicazioni. Di più: chiamare funzioni di questa API è l'unico modo che hanno le applicazioni per interagire con il calcolatore.

Detto questo, appare chiaro che Mac Os X è un sistema operativo molto ricco: non fornisce un solo ambiente applicativo, ma sei! In realtà, mentre Carbon, Cocoa, Java e AppleScript sono in grado di costruire applicazioni sostanzialmente simili, quelle con la tipica interfaccia Macintosh, gli ambienti BSD/X11 e WebObject sono adatti solo per particolari applicazioni.

Gli ambienti Operativi

L'ambiente BSD/X11

L'ambiente BSD è un ambiente tipico di Unix, dove si possono scrivere applicazioni senza interfaccia grafica, rispettando le interfacce Posix e FreeBSD. Non avendo interfaccia grafica, sono applicazioni che sono lanciate da linea di comando (ad esempio da Terminale) ed operano generalmente con file (che in Unix è un concetto piuttosto esteso). Non si deve sottovalutare la potenza di questo ambiente, visto che con strumenti sviluppati all'interno di questo ambiente si possono fare moltissime operazioni che si fanno con molta più grazia con una interfaccia grafica (potrebbe sorprendervi il fatto che si può anche navigare il web all'interno di questo ambiente...).

L'ambiente X11 è uno strato di librerie e meccanismi per aggiungere una interfaccia grafica (uno standard in ambiente Unix, piuttosto portabile tra diverse realizzazioni) alle applicazioni dell'ambiente BSD. L'eleganza della programmazione in X11 è per certi versi ancora insuperata a vent'anni (più o meno) dalla sua nascita. Molti porting da Unix o applicazioni multi-piattaforma (ad esempio, allo stato attuale, OpenOffice) utilizzano in massima parte questo ambiente.

L'ambiente Classic

L'ambiente Classic non esiste più. Era l'ambiente all'interno del quale funzionano le vecchie applicazioni Macintosh. Non c'è ragione per cui qualcuno debba sviluppare in ambiente Classic. Sul mio iMac Intel questo ambiente non esiste.

E' un po' buffo trattare così male l'ambiente Classic, che nel bene e nel male ci ha accompagnato dal 1984 al 2000... cosa volete, è la vita!

L'ambiente Carbon

Carbon è l'insieme di tutte le chiamate possibili al sistema operativo, ripulite da ogni complicazione dovute a Unix, comprensive di grafica, file system, network, eccetera. È in pratica la API nuda e cruda. Utilizzando direttamente le chiamate messe a disposizione da Carbon è possibile scrivere applicazioni perfettamente adeguate a funzionare con Mac Os X. Il problema di Carbon è che bisogna lavorare a basso livello, reinventando la ruota ogni volta che si riproduce un meccanismo tipico delle applicazioni. Il vantaggio di Carbon è che, lavorando a basso livello, non ci sono orpelli inutili e si raggiunge un elevato grado di efficienza. Carbon è l'ambiente applicativo fondamentale del Mac Os X, quello cui rivolgersi per scrivere le applicazioni standard, con i buoni vecchi linguaggi di programmazione (che so, C e C++).

L'ambiente Java

Java è un ambiente di sviluppo per il linguaggio omonimo. Si possono così scrivere sia applicazioni in puro Java (facilmente trasportabili in altri ambienti), sia programmare in Java nativo producendo applicazioni per il Mac Os X, perdendo la portabilità dell'applicazione.

L'ambiente Applescript

Più che un ambiente a se stante, AppleScript permette di scrivere applicazioni complete utilizzando molte tecnologie Cocoa, tanto da confondersi spesso con questo ambiente. Di fatto, gli strumenti di base per la scrittura di applicazioni in AppleScript sono gli stessi utilizzati da Cocoa.

L'ambiente WebObjects

WebObjects è un ambiente applicativo che comprende una serie di strumenti e costrutti adatti alla realizzazione di applicazioni su Web. Si possono realizzare sistemi con dati dinamici, interagendo con database e altre applicazioni, e costruire servizi web tramite SOAP, XML e tecnologie similari. Mi pare di ricordare che lo AppleStore è interamente realizzato con WebObjects.

L'ambiente Cocoa

Siamo finalmente arrivati a Cocoa.

Cocoa è una libreria di pezzi di codice che fanno la maggior parte del lavoro ripetitivo legato alle applicazioni per Mac Os X. Dovrei dire che Cocoa è una collezione di classi (un framework, come si dice) sulla quale basare lo sviluppo di applicazioni per Mac Os X. L'affermazione è perfettamente lecita se uno capisce cosa significa classi, e l'associa alla programmazione orientata agli oggetti.

Finché non parlo di questa programmazione object oriented, occorre spiegare in altro modo Cocoa.

Cocoa è una estesa libreria di componenti software che si possono utilizzare per costruire applicazioni per Mac Os X. In realtà Cocoa si pone ad un livello un po' più alto della API di Carbon: se Carbon è l'insieme dei vari mattoncini, Cocoa è un insieme di blocchi pre-fabbricati con i quali costruire in maniera più rapida le applicazioni per Mac Os X. Come gli elementi prefabbricati, è molto facile costruire software mettendo assieme nel giusto ordine gli elementi: basta solo aggiungere qui e lì un po' di collante. Altre volte invece, volendo costruire edifici particolari, gli elementi prefabbricati dovranno essere ritoccati qui e lì per adattarli alle nuove esigenze (che so, aprire una finestra qui, allargare quella porta là, cose del genere). Potrebbe essere viceversa molto difficile fare cose esotiche, grattacieli, palazzi barocchi, architetture bizzarre. Per queste cose, non si può che usare Carbon. Tuttavia, la ricchezza espressiva di Cocoa dovrebbe essere così grande e l'interazione coi livelli inferiori così completa, da rendere difficile raggiungere i limiti operativi di Cocoa.

Tra gli elementi prefabbricati presenti in Cocoa, ci sono molte cose: ci sono ad esempio, già pronti per l'uso, tutti gli elementi dell'interfaccia utente, già con aspetto aquatico: pulsanti, check box, campi di testo, eccetera. C'è un prefabbricato che rappresenta un Documento: basta solo colorarlo con le vernici giuste ed abbiamo già pronto un meccanismo per presentare e salvare i dati. Cose del genere. Di elementi prefabbricati ce ne sono veramente tanti. Proprio questo è uno dei problemi di Cocoa: ci sono talmente tanti elementi che conoscerli tutti è quasi impossibile. Non si può pensare di studiarli tutti e poi cominciare a sperimentare. Conviene impadronirsi di qualche elemento, e poi cominciare subito. Quando avrò bisogno di un qualche costrutto particolare, prima di farmelo da solo, converrà impiegare un po' di tempo per vedere se non è già disponibile in Cocoa sotto qualche forma. Ci sono ottime possibilità che ci sia già disponibile non dico quello che mi occorre, ma almeno qualcosa di simile (e che potrà essere modificato alla bisogna).

La maggior parte dei nomi degli elementi di Cocoa ha un nome che comincia con 'NS': una stringa ad esempio è un elemento di tipo NSString. Ho il sospetto che questa convenzione derivi dal fatto che Cocoa è l'erede dell'ambiente applicativo OpenStep di NextStep (ricordate? Next era la società fondata da Steve Jobs al momento della sua uscita da Apple; era circa il 1987 o giù di lì). Sono quindi circa quindici anni che le idee e la realizzazione di Cocoa sono in giro, per cui dovrebbe essere una cosa abbastanza assestata e corretta.

Si possono utilizzare diversi linguaggi di programmazione per lavorare con Cocoa, ma il predestinato è Objective-C (ObjC). ObjC non è parte di Cocoa, ma Cocoa è basato fortemente su tale linguaggio; gli oggetti di Cocoa sono scritti appunto in ObjC.

ObjC comprende al suo interno il C standard. In pratica, è il C standard con una serie di costrutti aggiuntivi, e si possono mescolare senza problemi istruzioni C ed istruzioni ObjC. Questo significa che in ObjC si possono utilizzare anche gli ambienti BSD/X11 e Carbon, mescolandoli gli uni con gli altri. Benché non una cosa pulitissima, è di una comodità spaventosa...

Ciò che si ottiene scegliendo di lavorare con Cocoa è un insieme di funzionalità già disponibili senza scrivere nemmeno una riga di codice. Senza far nulla, ad esempio, si può avere un'applicazione funzionante con una sola riga di codice (per altro, scritta automaticamente dall'ambiente di sviluppo). Ora, l'applicazione non farà molto, anzi, praticamente nulla. Però si avrà un'applicazione, che apre una finestra, presenta dei menu, si comporta come tutte le altre applicazioni, può stampare (una pagina bianca, va da sé) e perfino rispondere a semplici comandi AppleScript.

A disposizione ci sono poi dei meccanismi per la costruzione di applicazioni basate su finestre e per applicazioni basate su documenti (la distinzione sarà chiara più avanti), tutti gli elementi dell'interfaccia utente quali pulsanti, menu, finestre di varie fogge, pulsanti di spunta, visualizzatori di testi e di immagini, cose così. Ma poi anche meccnismi per interagire con il sistema, per gestire file, per stampare. per gestire elementi multimediali, interfacce di rete.

Cocoa viene fornito sotto forma di una coppia di Framework; dirò velocemente che un framework è una collezione di elementi con uno scopo comune. Ad esempio, il framework 'pareti' raccoglie tutti quei prefabbricati utili per la costruzione delle pareti, distinto dal framework 'tetto' che raccoglie tegole, solai ed altri oggetti del genere.

I due framework sono il Foundation Kit (che raccoglie in pratica le funzioni svolte dal layer Core Services) e l'Application Kit (le funzioni dei layer Application Services e Graphic and Multimedia Services). Questi due framework cercano di astrarre i layer inferiori a Cocoa e fornire un ambiente pulito ed ordinato. Come già detto, i framework dovrebbero bastare alla maggior parte dei programmatori. Tuttavia, se ritenuto necessario, è possibile scendere di livello e sporcarsi direttamente le mani accedendo ai layer inferiori (ad esempio, comandare direttamente OpenGL per ottimizzare la resa a video di una animazione). Tutto è facilitato dal fatto che le API sono scritte in C e ObjC ne è una estensione.

L'importanza di questi due framework si può riassumere nelle seguenti affermazioni: non si può realizzare una applicazione (con finestre, menu, eccetera) con Cocoa senza utilizzare lo Application Kit. E non si può scrivere un codice funzionante Cocoa senza utilizzare il Foundation Kit.

Foundation framework

Il Foundation Framework raccoglie in pratica tutti gli elementi di Cocoa che non hanno un corrispettivo nell'interfaccia utente. Il suo scopo è triplice: estendere le funzionalità di ObjC fornendo servizi di base per la programmazione object oriented (come vedremo poi); fornire servizi di base riguardanti il sistema operativo (e quindi memoria, controllo di esecuzione dei programmi, rete, eccetera); fornire supporto per il file system e le stringhe.

Con qualche dettaglio in più, gli elementi si possono raggruppare in diverse famiglie, come le seguenti:

• gestione di oggetti che hanno un valore, come i numeri, le date, le ore, insomma per gestire dati a livello astratto e trasformarli secondo diversi meccanismi ;
• gestione delle stringhe, loro costruzione, formattazione, eccetera. Da notare che Cocoa gestisce caratteri in accordo alla specifica Unicode, e quindi è in grado di gestire con facilità alfabeti non latini ed altre complicazioni del genere;
• gestione di collezioni di dati, sotto forma di vettori, insiemi, dizionari;
• servizi del sistema operativo, come la gestione del file system, la gestione di dati attraverso URL, la comunicazione tra processi e la gestione dei thread e dei task;
• persistenza degli elementi, con le funzioni necessarie per l'archiviazione e il recupero dei dati;
• servizi di scripting, per integrare AppleScript all'interno dell'applicazione;
• servizi ausiliari per ObjC, Meccanismo delle notifiche, oggetti distrubuiti e comunicazione remota, eccetera.

Application Framework

Lo application framework contiene tutti gli elementi utili per realizzare l'interfaccia grafica guidata dagli eventi (cioè, che reagisce a mouse e tastiera): ci sono finestre, pulsanti, menu, barre di scorrimento e cose del genere. La cosa bella di questo framework è che si occupa di tutti i dettagli noiosi (ridisegno delle finestre, dei controlli, gestione dei testi, cose del genere); è composta da una quantità impressionante di elementi, che possiamo dividere in tre grossi gruppi:

• elementi dell'interfaccia utente vera e propria;
• caratteristiche aggiuntive, come i font, le immagini, i colori, i suoni;
• servizi aggiuntivi di interfaccia, come il supporto per drag'n'ndrop, gli appunti per il copia/incolla, la stampa, la gestione dei documenti.

C'è perfino un elemento che aiuta nel controllo ortografico del testo (quest'oggetto mi interessa tanto che penso di studiarlo comunque, anche se non vedo come potere entrare in un programma che cataloga cd).

Altri Framework

Sono disponibili altri framework, che forniscono strumenti aggiuntivi per le applicazioni, che non sono però sempre necessari (e quindi mantenuti separati). Un elenco, parziale ed incompleto, potrebbe essere:

• Core Data, per la gestione di basi di dati;
• Sync Services, per la gestione di elementi da sincronizzare (ad esempio con diavolerie elettroniche attraverso Bluetooth);
• Address Book, per gestire i contatti della Rubrica Indirizzi all'interno dell'applicazione;
• Preference Panes, per scrivere un pannello delle preferenze;
• Screen Saver, per scrivere un salvaschermo;
• WebKit, per visualizzare elemento scritti in HTML.

Detto questo, partiamo dall'inizio: la programmazione object oriented e il linguaggio Objective C.

Eccetto dove diversamente specificato, i contenuti di questo sito sono rilasciati sotto Licenza Creative Commons.
Pagina a cura di Livio Sandel (macocoa2012@gmail.com).