IL SIGNORE NELL'OMBRA

di Luca Accomazzi e Carlo Lucio Bocchetti

Battete LOAD MIOFILE e dopo qualche secondo di attività, di lucette rosse, di ronzio, un programma è disponibile in memoria centrale per essere usato: il sistema operativo, invisibile padrone del vostro personal, ha eseguito ancorta una volta il suo compito.
O, forse, per svolgere lo stesso compito, avete battuto due volte il pulsante del mouse su un icona che raffigura il programma MIOFILE.
E' anche possibile che abbiate scelto un F)iler, chiesto un L)oad e battuto il nome del programma. Il sistema operativo ha tanti aspetti quanti computer diversi esistono e quanti linguaggi sono implementati: esaminiamo questa relazione più in dettaglio.

Ambiente aperto e ambiente chiuso.

Se avete un Mac per amico sapete certo che dopo l'accensione vi ritrovate in un ambiente (Scrivania, controllata dal programma di sistema Finder) in cui in ogni momento vi si presentano un numero limitato di possibilità, selezionabili col mouse, che vi porteranno nell'affascinante mondo delle finestre e di bottoni per decidere, scegliere, operare gli scambi di dati della vostra macchina con il disco e, più genericamente, col mondo esterno. Da Finder il ferale ?SYNTAX ERROR non vi ha mai tormentato, perchè il paziente Mac vi impedisce di chiedergli assurdità, e se proprio lo fate (per esempio se cercate di cancellare un file protetto o peggio ancora il disco di sistema che state usando) Finder in modo cortese ma fermo si rifiuta di obbedire alle vostre sconsiderate richieste.

Il sistema è chiuso. Difficilmente potrete aggiungergli comandi se non disponete del software opportuno nè d'altra parte ne avrete bisogno, con ogni probabilità: l'ambiente scrivania e la filosofia Mac che rappresenta sono fatti per utenti che poco o nulla si interessano allo scambio di byte, alle sincronizzazioni, all'error handling.
Qualcosa di simile vi accade se state lavorando in Pascal sotto il sistema UCSD-P; quella sbarra in "reverse" sulla prima riga dello schermo del vostro IBM od Apple vi presenta quietamente le possibilità di operazione ed ignora qualunque tentativo di gabbarlo premendo tasti fasulli.

D'altra parte, prendete un Apple // o un Commodore 64 nel loro ambiente di lavoro default: il Basic. Un cursore lampeggiante attende paziente che voi battiate un comando e lo terminiate con il RETURN, pronto a tampinarvi con un petulante BEEP ed il messaggio d'errore se il comando gli risulta incomprensibile.
Il sistema è aperto: potete aggiungervi comandi, magari usando i vettori & e USR, o lo XTERNCMD (external command) del piccolo Apple //, o sul Commodore 64 eliminando qualche comando Basic a favore dell'opzione desiderata. Le riviste sono colme di simili suggerimenti.
D'altra parte si suppone che la vostra conoscenza del mezzo sia superiore a quella del manager affaccendato che si può permettere un Mac e gli chiede di guidarlo nel proprio lavoro.

Una caratteristica di flessibilità e di modificabilità è ulteriormente esaltata in Unix, grazie alla eccellente integrazione con il linguaggio C ed alla filosofia dello Shell.
Per dirla in sintesi, tutti i comandi di Unix sono altrettanti file eseguibili in una speciale directory del file system (cioè del disco rigido di sistema). Ma ogni altro file eseguibile che sia contenuto nelle directory pre-specificate nel PATH (una variabile riservata) può similmente venire accesso ed eseguito chiamandolo per nome. In pratica, questo significa che il vostro programma PIPPO, che si trova nella vostra directory /CASA viene eseguito semplicemente battendo PIPPO <RETURN>. Il comando PIPPO viene trattato come un qualunque altro comando del sistema operativo: potete aggiungere al vostro ambiente di lavoro tutti i comandi che desiderate scrivendo un programma (in qualunque linguaggio e tipicamente in C) che svolga le funzioni richieste.
In questa maniera l'ambiente di lavoro è "tailored", per dirla con gli americani, ovvero tagliato su misura alle vostre specifiche necessità, ampliabile ove ve ne sia bisogno quanto volete.

Linguaggio e sistema operativo

E' meglio Basic o Pascal? Ahi, annosa domanda! D'altra parte, è meglio un martello o una pinza? Dipende dal compito che bisogna intraprendere! Lo stesso vale per i linguaggi... Basic non ha pari nel trattamento di stringhe, ma Pascal ha i record e i tipi di dati astratti che sono una vera sciccheria quando ne avete bisogno. A ognuno il suo! Il linguaggio su cui state operando ha anche una influenza fondamentale sul sistema operativo.
Vediamo come.
Siete in Pascal, e dovete scrivere un programma. Di cosa avete bisogno? Di un editore e del compilatore, fondamentalmente, magari di un linker ed un assemblatore se vogliamo strafare. La forma di sistema operativo ottimale per un compito del genere è quella chiusa: è sufficiente avere le risorse disponibili e chiamate con un semplice comando piuttosto che perdersi in un ambiente di sviluppo complesso e che in verità non è necessario.
Ma in Basic le cose sono differenti: Basic è interpretato, dunque non c'è bisogno del compilatore, e l'editore è sostituito da un editing di linea molto più semplice in quasi tutti i casi - Mac in questo non fa testo, anche se fa gola.
Il Basic dispone anche di comandi, come SAVE o LOAD, che sono effettivamente parti del sistema operativo (non confondetevi! Le chiamate READ e WRITE di Pascal sono solo richiami al sistema operativo, mentre il Basic è legato con filo doppio al s.o.), dunque il Basic non è solo un linguaggio ma anche un ambiente di sviluppo del software. Non per niente Basic ammette i comandi in modo diretto, sua prima caratteristica.
Da notare che la possibilità di avere un ambiente di lavoro ottimale non dipende tanto dal linguaggio in sé e per sé, quanto dal sistema operativo stesso e dal modo in cui questo viene interfacciato con il linguaggio.
Per capire questo concetto fondamentale consideriamo il caso di MacPascal, un ambiente di lavoro completo e interattivo, in grado di operare su finestre diverse, con icone, cursori e sfogliatori (vedi figura) e tutta una serie di utilities per il programmatore da fare invidia a tanti ambienti Basic pur ben supportati oppure, in negativo, la pessima interfaccia utente tipica di un qualsiasi Pascal da mainframe (tipo lo UW Pascal, tanto per non far nomi) implementato su un sistema multiutente.

In sostanza il sistema operativo è, se non di nome almeno di fatto, il supporto per l'utente, è l'insieme di quei programmi (assemblatori, compilatori, editor, debugger, utility) che contribuiscono a creare un ambiente di lavoro idoneo per lo sviluppo di software e per l'utilizzo dei programmi.

Sistemi mono-utente e sitemi multi-utente

Questa volta siete alla tastiera di un terminale di una macchina multiutente e state cercando di far compilare di un programma lungo più di 1000 righe senza possedere la password (parola d'ordine) da superutente che vi garantirebbe la precedenza sui molti, troppi utenti attualmente collegati al sistema.
Il cursore lampeggiante sembra irridervi, e vi conviene rilassarvi, perché comunque lo schermo non darà segni di vita per la prossima mezzora.
Su di un personal la stessa operazione sarebbe stata eseguita immediatamente: la CPU è infatti a disposizione dell'unico utilizzatore, mentre nell'altro caso deve essere suddivisa fra molti.
Vista la situazione, allora, come mai si continuano ad utilizzare i mainframe per dei lavori che potrebbero benissimo essere svolti con dei personal computer? Beh, la questione è complessa ed ha ragioni storiche.
I primi sistemi operativi degni di questo nome comparvero verso la fine degli anni cinquanta (come facevano prima? Semplice! Si arrangiavano ...).
I computer dell'epoca erano enormi, inefficienti se paragonati agli attuali e soprattutto costosissimi. Pensate che una CPU da 64k RAM agli inizi degli anni 60 poteva costare tranquillamente qualche miliardo di lire (di allora!).
Era naturale pensare che una risorsa così costosa andasse condivisa fra molti utenti, e si cercò di realizzare dei sistemi operativi che consentissero ad una sola CPU di far girare contemporaneamente una gran quantità di programmi, gestendo il maggior numero possibile di periferiche (terminali, stampanti, lettori di schede e memorie di massa).

Lo stesso Basic venne concepito come un linguaggio per facilitare la multiprogrammazione. Naturalmente con 64k o poco più da dividere fra diversi utenti (esistevano anche macchine da 1 Mega e oltre, ma gli utenti in tal caso erano centinaia o migliaia...) non era il caso di pensare a troppi fronzoli. Per esempio su un sistema multiutente la parola "grafica" ha suonato aliena fino a pochi anni fa, e tuttora un buon C64 o un Apple// hanno una grafica generalmente superiore a quella ottenibile dai mainframe, con l'eccezione, ovviamente, delle macchine specializzate, per esempio i terminali Apollo.
Oggi le cose sono molto cambiate: 64k di CPU è diventato il limite minimo per qualsiasi home computer, chip da 256k vengono venduti a pochi dollari l'uno e sono sempre più numerosi i personal espandibili fino a un Megabyte e più.
Questo fenomeno si è ovviamente prodoto anche nelle macchine più grosse, per cui se 15 anni fa un PDP 11 aveva a disposizione 64k RAM oggi la maggior parte dei sistemi multiutente viaggiano a livello di Megabyte e, nel caso dei Mainframe, di Gigabyte.

Ahime! Tutto questo in genere è servito a poco: sono aumentati nel frattempo i terminali da gestire e ancor più la mole di dati e programmmi da lavorare. Il mesto coro di tutti i responsabili di sistema è, regolarmente e perennemente: "Ci vorrebbe una espansione di memoria...", "Chissà quando arrivano gli hard disk aggiuntivi..." Non è detto, naturalmente, che i mainframe debbano andare in pensione anticipata: laddove occorra accumulare enormi quantità di dati, colloquiare con centinaia di utenti, amministrare aziende medie e grandi il computer grande una stanza è ancora insostituibile.
E tuttavia la crescente integrazione personal-mainframe, il migliorarsi delle LAN (local area network, rete locale in italiano) e il diffondersi di nuove esigenze informatiche tendono sempre più a ridimensionare o almeno a circoscrivere i luoghi d'uso dei mainframe. Che vanno evitati, nonostante il pensiero contrario dei brontosauri ancora in circolazione, dovunque possano essere sostituiti da una CPU dedicata, vale a dire da un personal. Di fronte alla prospettiva di rendere più amichevole l'uso di un computer che importa se una CPU deve passare la maggior parte del proprio tempo in attesa che qualcuno prema un tasto?

Il sistema operativo come gestore delle risorse disponibili. Sia nelle macchine monoutente che in quelle multiutente è il sistema operativo che si preoccupa di gestire le risorse disponibili.
In un mainframe il lavoro del SO è complicato essemzialmente dalla presenza di molti utilizzatori: suddividere la memoria centrale in parti rigidamente separate, stabilire zone di lavoro distinte a livello di memoria di massa, assegnare un tempo macchina ad ogni processo in esecuzione, secondo criteri di priorità tanto più complessi quanto maggiore è il numero di utenti e periferiche che il sistema può gestire.
Da questo punto di vista il SO di un personal ha la vita molto più semplice: l'utente è uno solo, è il padrone assoluto (anche in senso finanziario) di tutta la macchina e quindi può permettersi tutte le libertà che in un grande sistema sarebbero riservate al solo superutente. Del resto, i collegamenti con le periferiche sono diretti, un filo per ciascuna e non uno per ogni dieci o venti come accade nei grossi sistemi (i fili costano... specialmente se state interrogando da New York il computer del Pentagono a Washington).
Vita più semplice dovrebbe voler dire maggiori funzionalità, il che non è sempre vero: Unix resta insuperato, se non vogliamo considerare la lentezza che impone ai sistemi oberati di lavoro. Ai programmatori di sistemi operativi di domani, che affronteranno il problema dello sfruttamento dei nostri super-personal sopra il megabyte sta il compito di inventare nuovi compiti per il s.o., nuove possibilità a nostra disposizione, nuovi compiti di coordinazione (magari tra più microprocessori per un solo utente anzichè viceversa). E il Signore del Computer continuerà a regnare, dall'ombra, sui vostri programmi.

---

Originalmente pubblicato sulle pagine di Bit nel 1984

Originariamente pubblicato in data 08/04/1999

• Condividi