Prima di tutto bisogna sapere che l'AmigaOS é composto da piú sotto parti sovrapposte in vari strati. Vi sono i device, le resource e le library. Quelli piú a basso livello sono le resource, poi vengono i device ed infine le library.
Un esempio di questi sono: ciaa.resource, audio.device, exec.library. Un esempio molto semplificato della struttura interna dell'AmigaOS puó essere rappresentato cosi (a partire dall'HW):
exec.library layers.library
dos.library graphics.library
icon.library intuition.library
workbench.library gadtools.library
MUI.library (anche se non fa parte dell'OS).
Compito della exec.library é gestire l'intero sistema creando/schedulando/rimuovendo task, gestendo porte messaggi, semafori, liste di blocchi di memoria libera e cosí via.
Exec é il cuore dell'AmigaOS ed in genere é il gestore di tutte le risorse di amiga (infatti é con una funzione della exec.library che si possono "aprire" le resource ed i device).
Sopra ad exec, c'é il DOS che fornisce anch'esso la possibilitá di interagire con i processi (livello superiore di un task) e con il filesystem, gestendo i file, i cassetti, i pacchetti DOS ecc. ecc.
Il livello superiore é occupato (quasi a pari merito) dalla icon.library (gestione delle icone) e dalla workbench.library (appicon, appmenu).
Compito della layers.library é gestire la sovrapposizione delle finestre (layer = strato) piú altre cose. Il piú delle volte questa libreria viene usata dall'OS e poche volte viene manipolata direttamente dall'utente/programmatore.
Sopra, ma in pratica é a fianco, della layers.library risiede la graphics.library. Questa libreria si incarica di svolgere quelle attivitá di grafica a basso livello come puó essere il tracciamento di un cerchio, il riempimento di un'area, lo spostamento di un'area di pixel da una zona ad un'altra (blitting) e via dicendo. Viene usata da intuition per il tracciamento delle finestre, dei gadget e cosí via.
Infatti, sopra alla graphics.library c'é la intuition.library. Suo é il compito di gestire prevalentemente schermi, finestre, menú e bottoni. Ultimamente la Intuition é stata potenziata ed estesa con il sistema BOOPSI (Basic Object Oriented Programming System for Intuition) che ha permesso il proliferare di librerie quali MUI, ClassAct et simila.
Chiudono il livello ultimo quelle librerie rivolte a semplificare la vita al programmatore quali: gadtools.library (creazione/gestione di bottoni e menú), MUI.library bgui.library e compagnia bella.
Ora che abbiamo descritto molto sommariamente le varie librerie portanti dell'AmigaOS, passiamo ad esaminare brevemente, alcuni dei piú importanti device. Quest'ultimi non sono organizzati a livelli, in quanto ognuno di essi, ha il compito di controllare/gestire l'hardware per il quale é stato progettato: audio.device, trackdisk.device, timer.device, serial.device, parallel.device, narrator.device, input.device.
Fatta eccezione per quelli il cui compito lo si intuisce dal nome, il timer.device viene principalmente usato per la gestione delle temporizzazioni, permettendo la richiesta di invio di un segnale allo scadere di un determinato lasso di tempo; il trackdisk.device per gestire i floppy disk, il narrator.device per la gestione dei fonemi e la riproduzione di liguaggio umano; l'input.device per la gestione di tastiera e mouse (per il joystick esiste un device specifico: game.device, se non ricordo male).
In generale, questi device sono l'ultima risorsa per accedere all'hw visto che di solito, funzioni similari sono offerte da librerie poste ad un livello piú elevato. Per fare un esempio: se un nostro programma ha bisogno di essere sospeso per due secondi, il piú delle volte é sufficente fare una chiamata alla dos.library con la funzione Delay(100) (2 secondi espressi in 50mi di secondo).
Se invece abbiamo bisogno di tempi piú accurati (la dos.library é sufficentemente imprecisa), allora sará il caso di rivolgersi alla timer.device o addirittura alla ciaa.resource o ciab.resource.
Anche per fare una stampa, anziché usare il parallel.device (o il printer.device) il piú delle volte puó bastare un semplice 'Copy xxx to PRT:' fatta con una Run() o una Exec() della dos.library.
E` ovvio, che non tutte le volte si puó fare una determinata cosa con le procedure fornite; perchè sono troppo lente, o troppo complesse per l'uso che se ne vuole fare o per altre ragioni. Ecco perchè esistono i device e le resource che permetto un'accesso a basso livello ma LEGALE, dell'HW.
Adesso che abbiamo descritto in maniera sommaria le library ed i device (non ho mai usato le resource e quindi ne so molto poco), passiamo al primo programmino semplice semplice per spiegare praticamente ció che ho descritto poco prima.#include <dos/dos.h>
#include <proto/exec.h>
#include <proto/dos.h>
#include <stdio.h>
#include <error.h>
struct DOSBase *DOSBase;
void main(void)
{
if(DOSBase = (struct DOSBase *)OpenLibrary("dos.library",0))
{
printf("Aspetto per due secondi e poi termino...");
Delay(100);
printf("fatto.\n");
CloseLibrary((struct Library *)DOSBase);
}
else
perror("Impossibile aprire la libreria DOS!\n");
}
Questo programmino semplicissimo ed idiota, apre la dos.library, e, usando una sua funzione, aspetta due secondi prima di terminare.
Esaminiamo con la lente il sorgente:
Le prime quattro righe sono degli include per non generare errori e/o warning mentre si compila.
Il primo file contiene la dichiarazione del tipo di dato struct DOSBase, il secondo contiene i prototipi delle funzioni OpenLibrary e CloseLibrary, il terzo il prototipo della Delay(), il quarto della printf().
Adesso analizziamo le funzioni coinvolte.
Come molti di voi sapranno, nel C non esistono le procedure, queste in realtá sono delle funzioni che non ritornano nulla. Anche l'AmigaOS, rispetta quasi sempre queste direttive e le sue librerie hanno moltissime funzioni e poche procedure, anche perchè il piú delle volte si richede qualcosa che deve essere per forza ritornato. Infatti, con la prima chiamata di funzione, richiediamo l'apertura delle libreria dos.library versione 0.
Apriamo una piccola digressione: in generale, le librerie principali, sono giá aperte all'avvio del sistema (exec stessa non necessita di essere aperta: come si fa a chiamare la OpenLibrary, di exec, per aprire la libreria stessa?), l'apertura serve per permettere l'accesso al puntatore alla BASE della libreria per poi poter effettuare con questo puntatore i salti alle varie funzioni.
La struttura infatti contiene i vari spiazzamenti che devono essere compiuti per ottenere l'indirizzo di una determinata funzione. Le uniche librerie che potrebbero non essere aperte, sono quelle su disco, che quindi necessitano di essere caricate in memoria.
Tornando al programma: si cerca nella lista di exec delle librerie attualmente aperte, la libreria interessata, se exec non la trova apre la versione su disco, altrimenti la versione presente su ROM.
Il numero 0 della versione, é il numero MINIMO richiesto.
Siccome dal kickstart 1.0 al 3.1 le librerie sono state modificate ed ampliate, diverse funzioni sono state aggiunte. Quindi é necessario, prima di compiere una chiamata ad una determinata funzione, assicurarsi che questa esista nella versione di libreria correntemente utilizzata.
Specificando 0, come numero di versione, vuol dire che il nostro programma non necessita di particolari funzioni e che quindi va benissimo anche la libreria del 1.0. Se invece, avessimo bisogno, per esempio di una funzione presente solo dal 2.0 in su, allora avremmo dovuto specificare 37.
Altra piccola digressione, sui numeri di versione:
33 - 1.2
34 - 1.3
35, 36 - beta interne, ovviamente non utilizzate
37 - 2.0
38 - 2.1 (mai visto in Italia)
39 - 3.0
40 - 3.1
In definitiva, questa funzione, ritorna il puntatore alla base della libreria, se l'apertura ha avuto successo; NULL in caso contrario.
Una volta aperta con successo la libreria, é possibile chiamare tutte le funzioni in essa contenute, ecco quindi la chiamata alla procedura Delay che richiede come parametro, il numero di 50mi di secondo per il quale sospendere il processo chiamante.
Fatto questo, ecco la chiamata alla procedura di exec CloseLibrary, che rilascia il puntatore della libreria.
Altra piccola digressione sulla CloseLibrary. Quando questa procedura, viene chiamata, non corrisponde quasi mai alla effettiva chiusura della libreria. Molto spesso, questa viene lasciata in memoria per ottimizzare eventuali richieste successive. Nel caso in cui venga effettuata una richesta di memoria, che il sistema non riesce a soddisfare, prima di ritornare negativamente, scandisce la memoria alla ricerca di librerie, device e resource, chiuse ed inutilizzate: se ne trova, queste vengono scaricate dalla memoria che torna ad essere libera.
Questa operazione, puó essere forzata con il comando 'avail flush' di AmigaDOS.
Bene, per oggi direi che ho scritto abbastanza, vi lascio da provare il programmino descritto.