OS/2 Concepts: parte I
Andrea Giordano
|
|
OS/2 Concepts: parte I
Andrea Giordano
|
|
--------------------------------------------------------------------------- Introduzionedi Andrea Giordano La decisione di presentare questi "concetti fondamentali" in un momento in cui si parla di "fix 10" per Warp 4.0 o addirittura di Warp 5.0 sembrerebbe alquanto anacronistica. Eppure la ritengo personalmente un mezzo efficace per avvicinare i nuovi utenti, o meglio, invogliarli all'esplorazione del "nostro" S.O., senza per questo dimenticare quelli più esperti ai quali viene offerta una possibilità in più di rinfrescare concetti caduti magari nel dimenticatoio.
Come nuovo utente di OS/2 (ritengo ancora di essere tale...) la mia prima difficoltà fu proprio quella di andare alla ricerca di un qualcosa di "basilare" che potesse ampliare il materiale delle guide accluse nel pacchetto, spesso e volentieri scarne o, peggio, poco chiare nell'esposizione dei contenuti. Mi accorsi che, fatta eccezione delle NewsFAQ e degli articoli dell'e-zine JustWARP! (a volte un po' ostici da digerire per un utente alle prime armi...)la disponibilità di documenti in italiano era più povera rispetto a quelli in lingua inglese.
La scoperta di questi "Some fundamental OS/2 concepts" sembrava proprio fare al caso mio. Questa guida mi ha ben impressionato fin dal primo sguardo: l'autore, quasi con umiltà, si mette "a disposizione" di chi non ha confidenza del S.O. illustrando i concetti alla base del normale funzionamento di Warp e non disdegnando di richiamare alla mente quelli che un po' tutti diamo per scontati o che magari non ricordiamo più.
Ho cercato di tradurre il testo tal quale, apportando nessuna modifica, se non saltuariamente, laddove ho ritenuto necessari alcuni "ritocchi" per migliorarne la leggibilità. Spesso alcuni termini sono stati volontariamente lasciati in inglese, perchè di uso corrente fra gli utilizzatori; nel qual caso, dove possibile, ho aggiunto tra parentesi il termine in italiano così come appare nelle guide ufficiali IBM al sistema operativo. Altrove invece il termine in inglese è riportato tra parentesi accanto a quello in lingua italiana. Un ringraziamento va ai componenti del Team OS/2 Italia per aver voluto revisionare l'intero contento del testo, riparando così ai miei "limiti" in materia, e per aver creato il formato ipertestuale di questa guida.
Non ho la pretesa di aver svolto un lavoro eccellente, pertanto invito coloro che già conoscano il testo a volermi segnalare sviste e fraintendimenti, oppure semplicemente comunicarmi i loro commenti. Chi volesse invece una spiegazione tecnica più dettagliata è invitato a contattare direttamente l'autore Peter Moylan, o a documentarsi sulle NewsFAQ, sulla rivista elettronica "JustWARP!" curata dal Team OS/2 o infine consultare il newsgroup IT.COMP.OS2.
Buona lettura! AnGiò. ---------------------------------------------------------------------------
Il materiale di queste pagine è rivolto principalmente a coloro che, pur avendo una certa dimestichezza con il computer, sono nuovi utenti di OS/2. Anche agli utenti più esperti, tuttavia, potrebbero ricavarne dalla lettura delle nuove informazioni.
Il Boot Manager di OS/2 (Gestione Caricamento) Sistemi Dual Boot (Duplice Avviamento) Concetti circa la programmazione orientata agli oggetti (Object- Oriented Programming) Librerie Dynamic Linked (Dynamic Linked Libraries)
PARTE 2 La cache del disco La cache del processore Segmentazione e paging Il file di swap Il trashing Modalità "Reale" e Modalità "Protetta" (Real Mode / Protected Mode) Cos' è un programma a 32 bit? Il modello "flat memory"
PARTE 3 Le Reti Indirizzi IP Nomi dei nodi Reti LAN (Local Area Networks) e reti WAN (Wide Area Networks) Il routing Installare il Supporto di Rete di OS/2 Configurare il dialler Clients principali di Rete Software per il server di Rete ------------------------------------------------------------------------
Il BIOSIl BIOS (Basic Input/Output System) di un PC consiste in software residente nella memoria non volatile (ROM) in grado di fornire un interfacciamento di basso livello per componenti hardware come la tastiera, la stampante, ecc. Alcune schede di I/O, specialmente quelle video, contengono ROM di tipo proprietario in aggiunta al BIOS. L'idea originale del BIOS era quella di fornire un interfacciamento standard, possibilmente indipendente dall' hardware, che potesse sollevare il sistema operativo dalla necessità di doversi confrontare con la vastità di dispositivi I/O presenti sul mercato. In teoria, i servizi del BIOS sono disponibili ad ogni sistema operativo noi vogliamo far girare sulla nostra macchina. Nella pratica, i servizi del BIOS si sono rivelati essere indipendenti dal sistema operativo solo per il DOS o uno dei suoi più stretti "parenti". Gli sviluppatori originali non presero adeguatamente in considerazione la possibilità del multitasking. Succede così che OS/2, o qualsiasi altro sistema operativo avanzato, debba scavalcare molte delle caratteristiche del BIOS. Se OS/2 fosse il solo sistema operativo da noi utilizzato, allora potremmo dire che il BIOS è in gran parte uno spreco di spazio ROM. Ci sono, tuttavia, alcune situazioni in cui OS/2 non può permettersi di ignorare il BIOS:
* durante la fase iniziale di installazione di OS/2, il software di installazione deve poter accedere all'hardware attraverso il BIOS, perchè è tutto ciò di cui dispone. Questo spiega il perchè ad alcune persone aventi problemi hardware durante l'installazione, sia consigliato di disattivare alcune impostazioni nel BIOS, per poi riattivarle a processo concluso.
* In maniera simile, il BIOS deve essere interrogato durante la fase di avviamento (boot) di OS/2. Conseguenza di ciò è che la partizione di boot di OS/2 deve essere in una regione del disco "visibile" al BIOS. Questo può essere un problema con HD di grosse capacità e BIOS di vecchia data. I BIOS moderni riescono in più di una maniera ad aggirare l'ostacolo. Ogni hard disk ha un settore principale di avvio (Master Boot Record) che contiene tra le altre cose una mappa illustrante come il disco è partizionato. Si suppone che le regole che governano la tavola di partizione siano uniformi per tutti i sistemi operativi, e OS/2 deve necessariamente aderirvi -sebbene non siano dopotutto regole eccezionali- per evitare problemi con la procedura di avviamento. Le partizioni saranno discusse dettagliatamente nella sezione seguente. LE PARTIZIONIPartizionare equivale a dividere un singolo disco fisico in due o più pseudo-dischi. Ogni partizione può essere trattata, software permettendo, come un disco separato. C'è un concetto che non sempre è pienamente compreso e apprezzato. Se noi potessimo disporre di due dischi fisici, potremmo godere di una sorta di parallelismo sfruttando ll vantaggio di avere di fatto due dispositivi hardware quasi del tutto indipendenti. Questo significa, ad esempio, che la testina di lettura/scrittura di un disco può essere spostata su una nuova traccia nel medesimo istante in cui è in progresso una procedura di lettura o di scrittura sull'altro disco. Questo "sovrapporsi" di operazioni può farci ottenere un buon punteggio in termini di velocità del sistema. Avere due partizioni su un singolo disco fisico significa non sfruttare tale vantaggio di velocità. Infatti, un' operazione come il copiare un grosso file da una partizione ad un'altra può risultare molto lenta, perchè la singola testina di lettura/scrittura deve continuamente saltare dall'una all'altra. Un altro svantaggio del partizionamento sta nel fatto che questa operazione ruba un po' di flessibilità alla modalità di allocazione dello spazio. Se siamo in prossimità di esaurire lo spazio su disco potremmo raggiungere un punto in cui lo spazio totale libero risulta sufficiente per una certa operazione, ma non è possibile usarlo perchè non c'è sufficiente spazio libero su ciascuna delle singole partizioni. Queste considerazioni potrebbero far nascere l'idea che il partizionamento sia da evitare. Ma ci sono invece buone ragioni per farlo. Eccole:
1) se abbiamo più di un sistema operativo, possiamo assegnare a ciascuno la propria partizione. (Forse è stata questa la motivazione principale a far introdurre per la prima volta questa procedura.) Ad esempio, un possibile modo per far girare entrambi i sistemi OS/2 e DOS/WINDOWS sta nel dividere il disco in *quattro* partizioni secondo lo schema seguente:
Questo approccio è di gran lunga superiore a quello di mescolare i due sistemi operativi su una singola partizione. 2) se usiamo il file system FAT, è preferibile non avere partizioni di grosse dimensioni. Questo lo spiegherò più avanti. 3) una sola grossa partizione può tradursi in uno spazio pieno zeppo di directories da farci perdere l'orientamento e non farci più ricordare dove sono i nostri files. Ovviamente è una questione di preferenze personali, ma alcuni trovano più facile organizzare i loro files se, ad esempio, si usano partizioni differenti per i files di "sistema" e per quelli delle "applicazioni". 4) quando si installa o si aggiorna un sistema operativo, può essere conveniente avere uno spazio dove poter trasferire temporaneamente i files mentre una partizione viene formattata (è chiaro che questo risulta agevole a chi ha davvero parecchio spazio disponibile su disco). Il programma che si incarica di effettuare le partizioni è FDISK. È possibile avviarlo all'interno di OS/2 a patto che non si vadano a toccare le partizioni che OS/2 sta usando in quel momento. Per cambiamenti radicali bisogna effettuare il boot dai dischetti di utilità e da quelli avviare FDISK. Durante l'installazione di OS/2, l'opzione "Installazione Avanzata" permette di avviare FDISK e preparare le partizioni.
Anche altri sistemi operativi, come il DOS, hanno un programma FDISK. Le diverse versioni non sono esattamente identiche, ma hanno parecchie cose in comune al punto tale che, con molta cautela, si potrebbero organizzare le singole partizioni da qualsiasi sistema operativo.
Le regole ci dicono che possono esistere al massimo quattro partizioni per disco. Questo suona come restrittivo, ma esiste una via di uscita: una partizione può essere "primaria" oppure "estesa", e una partizione estesa può essere suddivisa in diverse partizioni logiche. È possibile avere una sola partizione estesa per disco, ma questo è più che sufficiente. Nella pratica quindi possiamo avere:
* fino a quattro partizioni primarie e nessuna partizione logica (cioè nessuna partizione estesa);
oppure
* fino a tre partizioni primarie, e un qualsiasi numero di partizioni logiche (ndr: create fino a completamento dello spazio libero all'interno dell'unica partizione estesa). Conclusione ovvia è che è meglio usare partizioni logiche quando ciò sia possibile, ed usare partizioni primarie quando non si ha alcuna scelta.
Per sistemi avanzati quali OS/2 e Linux non costituisce un problema di sorta l'essere installati su una partizione primaria oppure su una logica. D'altrocanto invece, alcuni sistemi -e ci riferiamo principalmente a Windows NT, DOS, e shell del DOS come Windows '95- deveno necessariamente essere installati su una partizione primaria per essere avviati. Se è nostra intenzione far girare sulla macchina più sistemi operativi dobbiamo riflettere attentamente su come organizzare le nostre partizioni.
Eccoci arrivati ad un punto cruciale: se abbiamo più partizioni primarie per disco, queste non possono "vedersi" a vicenda (ndr. cioè, nel medesimo istante, può essere attiva una sola partizione primaria per disco), ed in più avranno necessariamente assegnata la stessa lettera identificativa d'unità.
Ecco un esempio di ciò che si può avere:
In questo esempio, entrambi DOS e NT devono essere installati su una partizione primaria, quindi avremo due partizioni C:. Nessuna delle due è visibile dall'altra. La partizione D: è visibile da tutti e tre i sistemi operativi, perchè di tipo FAT. La partizione E: è invisibile al DOS perchè il DOS stesso non comprende partizioni di tipo HPFS; la stessa potrebbe o non potrebbe essere vista da Windows NT a seconda che il driver PINBALL.SYS sia installato oppure no. OS/2 potrà vedere le tre partizioni, ma la versione di C: sarà quella che era "attiva" prima del boot di OS/2.
Ho lasciato per ultimo...la parte migliore! Se aggiungiamo un secondo disco fisico a questa configurazione, l'assegnazione delle lettere identificative "impazzisce". Ecco ciò che potrebbe accadere:
-> Disco 1 <-
-> Disco 2 <-
Ciò che succede qui è che l'ordine di assegnazione delle lettere identificative per le partizioni primarie precede quella per le partizioni logiche. Come risultato, le lettere che identificano i rimanenti volumi sul primo disco cambiano, anche se non l'abbiamo toccato al momento di aggiungere il secondo! ...è il caos! A rendere le cose più "interessanti" è il fatto che le partizioni viste dal DOS sono ora inconsistenti con quelle viste da OS/2, giacchè una partizione HPFS ora viene prima di una FAT.
Qual è la morale di tutto cio? Semplice: se aggiungiamo un secondo hard disk, non creiamo in esso partizioni primarie!
IL FILE SYSTEM DI TIPO FATUn blocco di dati su disco contiene 512 bytes (i PC permettono in realtà blocchi di altre capacità, ma non ho mai visto un hard disk che abbia mai usato blocchi di altre dimensioni.) Le operazioni di lettura/scrittura trasferiscono in genere un numero intero di blocchi, così la larghezza di un file deve essere arrotondata per eccesso al numero di blocchi imediatamente successivo (come vedremo più avanti, l'arrotondamento può spingersi ben oltre in là...). Ciascun file system deve avere almeno le seguenti proprietà:
1. deve esistere un modo per poter tradurre un nome di file nel corrispondente blocco di partenza. Cioè, deve esserci una sorta di indirizzario (directory) immagazzinato sul disco. 2. dato il blocco di partenza, deve esserci un modo di ricavare il numero del blocco immediatamente successivo nel file. Nel file system di tipo FAT il problema 2 è risolto dalla ricerca di una tavola chiamata "Tavola di Allocazione dei File" (File Allocation Table). Il disegno originale della FAT prevedeva che ciascun registro fosse rappresentato da un numero di 12 bit, permettendo in tal modo un totale di 4096 blocchi sul disco. Se facciamo un calcolo ci rendiamo conto che il risultato è appena adeguato per un floppy disk della capacità di circa 2 MB. Per permettere lo sfruttamento di dischi più capienti è stata introdotta una FAT a 16 bit, portando la capacità massima del disco a 32 MB circa.
Oggigiorno dischi di così piccola capienza sono solo un vago ricordo. Cosa è successo? La risposta sta nell'incremento della larghezza dei blocchi da 512 byte. Il blocco fisico in realtà è sempre il medesimo, ma per permettere le operazioni su disco i blocchi adiacenti sono raggruppati in "clusters". Se per esempio si creano cluster con una capienza di 8 Kb ciascuno (pari a 16 blocchi fisici) si possono ottenere dischi con una capienza che raggiunge i 512 MB.
La questione è che la grandezza di ciascun file deve essere ora arrotondata ad un numero intero di clusters, e 8 Kb è un numero piuttosto grande per un cluster. Questo significa, per esempio, che un piccolo file batch lungo in realtà poche dozzine di caratteri, occuperà sempre uno spazio fisico di 8 kb. Tutto ciò conduce ad un grosso spreco di spazio.
Nella pratica, allora, l'unico modo conveniente di usare un sistema FAT è quello di suddividere il disco in un numero di piccole partizioni, al fine di mantenere piccola la grandezza di ogni cluster su ciascuna partizione.
Un modo più intelligente consisterebbe nel non usare affatto il sistema FAT. D'altronde è stato concepito per i floppy disks e non è adatto per hard disks di grosse capacità. Sfortunatamente, molti di noi, se non tutti, devono conservare almeno una partizione di tipo FAT in nome della compatibilità DOS.
Tralascerò la spiegazione di come funzionino le directories in un file system, giacchè annoierebbe il più delle persone.
IL FILE SYSTEM DI TIPO HPFS (High Performance File System)Ciò che segue vuole essere solo una breve introduzione. Per una descrizione più avanzata fate click qui. ( http://murray.newcastle.edu.au/users/staff/peter/os2/HPFS.html )
La prima cosa importante è che HPFS non ha la limitazione circa la grandezza dei clusters vista per FAT. Con HPFS la grandezza dei clusters equivale sempre alla grandezza dei blocchi fisici su disco, indipendentemente da quanto sia capiente il disco stesso (in verità esiste un limite, ma nella pratica è ben lungi dall'essere raggiunto). Questo si traduce in un minore spreco di spazio, e nessuna preoccupazione circa quanto grande debba essere una partizione. Se volete, potete decidere di creare una partizione grande quanto tutto il disco.
Secondo, le directories nel HPFS sono ordinate in una struttura ad albero. In un sistema FAT una directory è solo un elenco sequenziale, e se la directory diventa lunga ci sono problemi per la sua ricerca. In un sistema HPFS esse sono organizzate in modo da rendere più veloci le operazioni di ricerca.
Terzo, la allocazione dello spazio nel sistema HPFS è un po' più complicata rispetto alla semplice strategia "cerca il primo blocco libero" del sistema FAT. HPFS tende ad assicurare che un file risieda fisicamente vicino alla sua directory, e a mantenere bassa la probabilità di frammentazione (la frammentazione di un file è quella condizione che nasce quando il file stesso consiste di molti piccoli frammenti isolati, piuttosto che di un piccolo numero di frammenti di grosse dimensioni. Stessa cosa accade allo spazio libero sul disco. Questo è importante perchè la frammentazione può rallentare in modo evidente le operazioni su disco. I volumi HPFS diventano frammentari solo in occasioni estreme - ad esempio quando il disco è quasi completamente pieno. I volumi FAT invece diventano ben presto frammentari anche in condizioni "normali". Con il sistema FAT si è costretti di tanto in tanto ad azionare un programma "deframmentante" (defragger) pena un decadimento di prestazioni. Con HPFS il grado di frammentazione quasi mai raggiunge un punto tale da manifestare una visibile differenza.
Esiste qualche svantaggio? Sì, il sistema HPFS è più complesso di quello FAT, e questo aggiunge qualche svantaggio in termini di spazio e di tempo. Per un tipico hard disk i vantaggi ripagano ampiamente degli svantaggi. Per dischi molto piccoli, o dischi che contengono solo un piccolo numero di files, HPFS non apporterebbe grandi benefici. Non è una buona idea usare HPFS per i floppy disks [ndr: l'ultimo periodo è stato tradotto letteralmente per completezza, ma il lettore sappia che non è possibile formattare un floppy disk con il formato HPFS, mentre lo è nel caso dei supporti di backup, come ad esempio le cartucce ZIP.)
GLI ATTRIBUTI ESTESIHo dimenticato di dire che cosa va all'interno di una directory. L'elemento relativo a un file contiene quelli che sono chiamati gli attributi del file: il suo nome, la sua grandezza, la sua locazione, speciali proprietà come l'essere di sola lettura, ecc. Un file system come il FAT ha spazio solo per una minima quantità di attributi per ciascun file all'interno di una directory. Directories HPFS contengono invece molte più informazioni per ogni singolo file. In particolare HPFS non ha la famosa restrizione "8.3" circa il formato dei nomi dei files. In più HPFS fornisce i cosidetti "attributi estesi" - per esempio l'icona associata al file - che vengono immagazzinati nelle vicinanze del file stesso. Possiamo pensare all'informazione contenuta negli attributi estesi come un supplemento alla directory contenuto all'interno di essa.
Su una partizione di tipo FAT, OS/2 immagazzina di nuovo gli attributi estesi (EA) di quel file vicino quel file, ma non c'è un mezzo nella directory FAT per mostrare che quello spazio extra su disco è in uso. OS/2 raggira il problema creando un file extra nascosto chiamato "EA DATA. SF" nella directory radice, e questo raccoglie insieme gli EA per tutti i file all'interno di quella partizione. (gli spazi nel nome del file sono un'artificio per renderne più difficile la cancellazione accidentale.) Volendo essere più precisi, questo file nascosto non è affatto un file, piuttosto un artificio per segnalare al sistema FAT che certi blocchi su disco sono in uso e non debbono essere ri-allocati (è facile notare altresì un file nascosto chiamato "WP ROOT. SF". Questo si trova su tutte le partizioni, anche quelle HPFS, e racchiude gli attributi per l'albero delle directories che si trovano al disotto della directory radice).
Molti files non hanno bisogno di attributi estesi, e in essi l'informazione viene registrata solo quando necessario. Tuttavia il file per gli attributi estesi prima citato può ingrossarsi considerevolmente. Questo non è un grande problema su una partizione HPFS, dove gli attributi estesi vengono immagazzinati separatamente insieme a ciascun file. Su una partizione FAT il riporre tutta l'informazione degli EA immagazzinata in un unico grosso file può creare qualche problema di sicurezza: se il file EA viene corrotto per qualche motivo, le conseguenze potrebbero essere gravi.
Su una partizione HPFS il nome file (che può essere lungo fino a 255 caratteri) è immagazzinato all'interno della directory. Su una partizione FAT non c'è abbastanza spazio nella directory per immagazzinare un nome di file lungo, così deve esserci un attributo extra che lo contenga. Una complicazione legata a questo schema è che ogni file finisce per avere due nomi. Questi vengono mostrati come "Titolo" e "Nome effettivo" quando si apre una cartella in modalità "Dettagli". I due nomi sono in genere uguali su una partizione HPFS, ma spesso diversi su una partizione FAT. Il "Titolo" - cioè il nome lungo - è quello che viene usato nelle operazioni desktop come copiare il file usando il mouse. Il "nome effettivo" è quello che viene usato nelle sessioni a linea di comando. è possibile rendere i due nomi completamente diversi l'uno dall'altro...ma non ve lo raccomando, perchè finirebbe per confondervi.
Il BOOT MANAGER DI OS/2 (GESTIONE CARICAMENTO)Se OS/2 fosse il solo sistema operativo presente nelle nostre macchine, non ci sarebbe bisogno di un programma quale Boot Manager. Potremmo considerarlo un extra comodo per chi vuole scegliere il sistema operativo al momento del boot del computer.
Quando accendiamo il nostro PC, o lo resettiamo attraverso il pulsante di reset, diamo il controllo al BIOS. Questo esegue delle routines di inizializzazione per poi caricare un "blocco di avvio". Questo blocco di avvio contiene normalmente un piccolo programma il cui compito è quello di far iniziare il caricamento del nostro S.O.
Cosa si intende per "partizione primaria attiva"? Abbiamo già visto che è possibile partizionare il disco in maniera tale che abbia più di un "disco C:". Il BIOS deve decidere quale di questi prende il controllo. Per permettere questo c'è un flag nel Master Boot Record che dice quale delle possibili partizioni primarie è quella "avviabile".
Se installate Boot Manager, esso occuperà una sua piccola partizione primaria (alla quale, comunque, non sarà assegnata alcuna lettera) e tale partizione è quella che è contrassegnata come "avviabile". Significa che il "sistema operativo" caricato dal BIOS sarà il Boot Manager. La funzione di questo programma è piuttosto semplice: vi chiede di scegliere una partizione, e poi carica il sistema operativo residente su quella partizione. Se avete due o più sistemi operativi installati (ognuno in una partizione) dovete semplicemente fare in modo che ogni sistema operativo sia visualizzato nel menù di Boot Manager. Potete personalizzare tale menù usando il programma FDISK.
Sebbene il BIOS possa avviare un sistema unicamente da una partizione primaria, il Boot Manager può avviare da qualsiasi partizione (e qualsiasi disco) voi specifichiate. In teoria, potreste anche prendere un sistema operativo che richieda di esistere su una partizione primaria, metterlo invece su una partizione logica, e poi usare Boot Manager per avviarlo. Nella pratica, quello che ve lo impedisce è il fatto che i sistemi operativi "primitivi" non si lasciano installare su una partizione che non sia quella primaria.
SISTEMI DUAL BOOT (DUPLICE AVVIAMENTO)Cosa succederebbe se volessimo installare due sistemi operativi sulla medesima partizione?
Beh, visto che lo chiedete...Il miglior consiglio che vi possa dare è NON FATELO! Fatevi piuttosto una doccia rinfrescante e pensateci un po' su, dopodichè ritornate davanti al PC ed installate Boot Manager. È cento volte meglio, per tanti motivi.
E, tuttavia, OS/2 vi permette di fare anche questo - infatti è la scelta di default per quelli che hanno già il WIN/DOS e che non sono tanto coraggiosi di selezionare l'opzione "Installazione Avanzata" - e possiamo ritenere quindi che ci sarà qualcuno che lo farà.
La procedura consiste nel modificare alcune porzioni cruciali sul disco di avvio. Se siete sotto OS/2 ed eseguite il programma "Avvia da DOS", ciò che il programma fa è copiare una piccola porzione situata all'inizio del disco in una locazione di backup, e poi la sostituisce con una riconoscibile dal DOS. Se quindi chiudete il sistema e lo riavviate il BIOS caricherà la porzione sostituita e il codice che ivi si troverà sarà quello adatto per il DOS. La cosa inversa succede quando volete ripassare da DOS a OS/2.
In aggiunta a quanto detto, è necessario copiare o rinominare i files AUTOEXEC.BAT e CONFIG.SYS. Entrambi il DOS e OS/2 hanno questi files di sistema, ma il loro contenuto è diverso. Questi files vengono trasferiti da qualche parte proprio in virtù dell'operazione di "Dual Boot".
È proprio questa operazione di trasferimento momentaneo che fa del dual boot un'opzione poco consigliabile. Un inaspettato black out, o il tasto di reset schiacciato inavvertitamente proprio nel cuore della procedura - e a volte basta davvero poco... - e vi troverete nel bel mezzo di una situazione in cui nessuno dei due sistemi può essere più avviato.
IL FILE AUTOEXEC.BATAUTOEXEC.BAT è un file usato esclusivamente nelle sessioni DOS. Se non vi trovaste mai ad eseguire programmi DOS (e Windows), non avreste bisogno di questo file.
Il file in questione contiene una sequenza di comandi DOS che sono eseguiti ogni qualvolta voi azionate un programma DOS o richiamate una finestra comandi DOS (shell). (Ai fini di questa discussione è necessario che voi ricordiate che le sessioni WinOS2 vengono ugualmente eseguite in shell DOS.) Il più delle volte questi comandi hanno lo scopo di definire alcune variabili d'ambiente, in particolare quella PATH.
Se avete entrambi il DOS e OS/2 installati sul vostro sistema, avrete due files AUTOEXEC.BAT, quindi è importante non confonderli. Supponiamo ad esempio di avere il DOS su C: e OS/2 su E:. Allora il file C:\AUTOEXEC.BAT è quello eseguito quando avviate il sistema con il DOS, mentre il file E:\AUTOEXEC.BAT è quello eseguito ogni volta voi eseguite un programma DOS all'interno di OS/2.
Se il vostro sistema è del tipo "Dual Boot" allora entrambi le versioni di AUTOEXEC.BAT risiedono nella stessa directory. Il programma Dual Boot li rinomina ogni qual volta si passa da un sistema operativo all'altro.
Un noto problema del DOS, specialmente quando vengono installate applicazioni Windows, sta nella stringa che definisce la variabile PATH, la quale tende a crescere in lunghezza. Se vi soffermate ad osservare una tipica stringa PATH vedrete che molte voci sono il più delle volte poco necessarie, e tuttavia devono esserci perchè richieste ogni tanto da qualche programma. L'emulazione DOS in OS/2 vi permette di aggirare il problema dandovi la possibilità di avere piu files "autoexec" purchè, ovviamente, di nome diverso. Per specificare un file AUTOEXEC personalizzato, aprite il blocco note "Impostazioni", scegliete "Sessione", cliccate quindi "Impostazioni DOS... - Altre impostazioni DOS" e specificate un nome file personalizzato nel campo relativo alla voce "DOS_AUTOEXEC".
IL FILE CONFIG.SYSEntrambi il DOS e OS/2 usano un file chiamato CONFIG.SYS. (Similmente a quanto detto prima, se entrambi il DOS e OS/2 sono installati ci sono due files CONFIG.SYS, uno per ciascun disco di boot. Al contrario, diversamente dall' AUTOEXEC.BAT non esiste un CONFIG.SYS per le sessioni DOS.) In DOS il file CONFIG.SYS è in genere molto corto e la sua principale funzione è specificare quei drivers che devono essere caricati durante il boot. Il CONFIG.SYS in OS/2 ha funzioni simili, ma è molto più lungo.
Un modo per scoprire la funzione dei diversi device drivers (programmi di controllo per le unità periferiche) sta nel digitare il comando "HELP BASEDEV" in una finestra OS/2. Questo comando non vi dirà tutto di tutti i drivers, ma solamente di quelli principali. Tuttavia, non si sbaglia di molto se si assume che i drivers che cominciano con la lettera "V" sono quelli che vengono usati durante le sessioni DOS.
CONFIG.SYS contiene anche le voci PATH, DPATH, LIBPATH e HELP. Come nel DOS, la variabile PATH contiene una lista di directories che specifica quelle in cui viene cercato un file eseguibile da essere avviato. DPATH è simile, ma è usato per la ricerca dei files di dati. (Sfortunatamente, non è affatto chiaro quali programmi usano DPATH per questo scopo). LIBPATH è usato durante la ricerca di una DLL (Dinamic Linked Library) e HELP è usato per la ricerca dei files di help.
Quasi tutto il resto del CONFIG.SYS contiene le definizioni delle cosidette "variabili d'ambiente". Una variabile d'ambiente è una costante di sistema (ancora non so perchè continuino a chiamarla "variabile"...) il cui valore è richiesto da molti programmi differenti. Per esempio, se avete una costante di nome TZ definita nel vostro CONFIG.SYS, allora il suo valore sarà usato da ciascun programma che ha bisogno di sapere in quale "time zone" (fuso orario) vi trovate.
Poichè il CONFIG.SYS è una risorsa globale, sarebbe sciocco usarlo per definire una variabile d'ambiente necessaria solamente ad uno o due programmi. Sfortunatamente, fin troppe applicazioni sviluppate sono precisamente sciocche in quel modo. E c'è perfino un programma (indovinate quale!) che vi inserisce una copia non criptata della password del "System Manager". Con il passare del tempo, e col continuare ad installare applicazioni poco intelligentemente sviluppate, il vostro CONFIG.SYS si riempie di voci incomprensibili e, peggio, non documentate da alcuna parte. Con molta probabilità finisce anche col contenere variabili relative a programmi cancellati oramai da tempo.
È importante capire che il CONFIG.SYS viene letto solo una volta all'avvio di OS/2. Qualsiasi cambiamento si fa in esso avrà effetto solo al momento del successivo riavvio. Ecco perchè le procedure di installazione di alcune applicazioni riavviano il computer. Un re-boot durante l'installazione quasi sicuramente significa un CONFIG.SYS modificato. Dovreste essere parecchio sospettosi nei confronti di questi programmi, perchè quasi sempre sono quelli che lasciano della vera e propria "spazzatura" in giro anche quando pensate di averli completamente rimossi dal disco.
I FILES INIAbbiamo visto come il CONFIG.SYS contenga dei parametri intesi come "settaggi permanenti". Esso è creato al momento dell'installazione del S.O. e non viene modificato a meno che voi non facciate un cambiamento come l'aggiungere una nuova periferica o un nuovo driver.
Ma c'è anche bisogno di registrare parametri che possono variare durante il normale utilizzo, come la posizione delle cartelle o i settaggi di quelle applicazioni che hanno parametri configurabili. I files INI di OS/2 servono proprio a tal scopo. Un file INI per questioni di efficienza è di tipo binario, per cui non potete leggerlo con un semplice editor di testo. Tuttavia esistono diversi INI editors sia freeware che shareware che vi permettono di darci un'occhiata.
Ciascuna voce in un file INI consiste in una tripletta del tipo "Applicazione, Chiave, Valore" (Application, Key, Value). I nomi "Applicazione" e "Chiave" sono in genere leggibili. Il formato e il significato del "Valore" dipende dall'applicazione; può essere un numero, una stringa di caratteri o qualcosa di più complicato. In genere il suo significato non è documentato da nessuna parte, poichè i programmatori non considerano i dati presenti negli INI files di interesse pubblico. (Quindi editare un file INI potrebbe diventare una questione rischiosa.)
Una grande vantaggio degli INI files è che ogni applicazione può avere i suoi privati files INI. L'alternativa sarebbe avere un enorme archivio centrale che registri i parametri dell'intero sistema. Davvero un idea poco intelligente: permetterebbe infatti alle applicazioni di interferire col sistema, con le altre applicazioni presenti, e nel complesso sarebbe in sè inefficiente a causa della grandezza stessa dell'archivio. Molto meglio per le applicazioni mantenere i loro propri dati nelle loro proprie directories.
Esistono due file INI "globali", chiamati System INI File (OS2SYS.INI) e User INI File (OS2.INI). OS2SYS.INI contiene dati richiesti dal sistema operativo mentre OS2.INI contiene dati richiesti da certe applicazioni fondamentali. Poichè non tutti i programmattori sono così competenti come li vorremmo noi, in questi INI files globali si trovano voci che in realtà dovrebbero essere in files INI "privati".
Il sistema non sempre cancella dai files INI le voci non più utili, cosicchè questi tendono a crescere in dimensione con il passar del tempo. Questo fenomeno era particolarmente pronunciato in OS/2 2.0. è stato migliorato nelle versioni successive, ma conviene sempre azionare un "INI file checker" ogni tanto, così da ripulirli dai vecchi e non più utili riferimenti.
CARTELLE E DIRECTORIESUna cartella è un contenitore di oggetti posto sul desktop, la cui funzione è, per l'appunto, quella di contenere altri oggetti. Una directory è un contenitore di oggetti posto sul disco, la cui funzione è quella di contenere dei files (ed eventualmente altre directories, che quindi sono chiamate sub-directories). Almeno, questo è il principio. Nella pratica è più facile pensare ad una directory come ad un qualsiasi altro file su disco, contenente una collezione di voci; ciascuna voce è agli effetti un "puntatore" ad un file contenuto in quella directory.
Per alcuni sistemi operativi i concetti di "cartella" e "directory" possono essere distinti. In OS/2 sono a tutti gli effetti la stessa cosa. Sul vostro disco di avvio c'è una directory chiamata "Scrivania", e se usate un qualsiasi file manager per guardarne i contenuti vedrete che in essa sono contenute sub-directories, ciascuna delle quali corrisponde da un oggetto sulla vostra scrivania. Qualsiasi file posto sulla Scrivania, o in una sua cartella, apparirà come file in quella particolare directory sul disco.
Similmente, se usate l'oggetto "Unità" per guardare in una directory su disco, ogni file vi apparirà come un oggetto e ciascuna directory come una cartella.
Una piccola eccezione può spesso confondere alcune persone. Se aprite la vostra Scrivania in modalità "Visualizzazione Dettagli" (cliccando con il tasto destro su un qualsiasi punto di essa e scegliendo "Aprire come") vedrete che alcuni oggetti hanno un "Titolo" ma non un "Nome Effettivo". Con molti file managers questi oggetti non saranno rappresentati all'interno della directory Scrivania.
Quello che succede in questo caso riflette il fatto che molti oggetti della Scrivania sono completamente definiti da informazioni contenute in un file INI, e per questo non occupano uno spazio fisico su disco come files. Alcuni file managers li visualizzeranno come file di dimensioni 0, oppure non lo faranno affatto.
OGGETTI DELLA SCRIVANIATutto quello che è rappresentato da un'icona sulla scrivania è detto "oggetto", ma esistono diversi tipi di oggetti. Fortunatamente tutti ricadono in una di queste tre categorie principali:
1. Un "vero" file è qualcosa che fisicamente occupa spazio sul disco. Può essere un file eseguibile, un documento creato con un elaboratore testi, un'immagine formato bitmap, ecc. - Anche una directory è un vero file.
2. Un "oggetto astratto" non occupa spazio sul disco, fatta eccezione del fatto che una o più voci esso riguardanti sono all'interno del file INI di sistema. Alcuni oggetti astratti non hanno una rappresentazione visibile, e quindi per adesso non ci interessano; ma alcuni invece esistono come icone sulla Scrivania con i loro blocco-note "Proprietà" (Il blocco-note Proprietà di un oggetto non è altro che una rappresentazione visuale di ciò che è contenuto nel file INI riguardante l'oggetto stesso). L'oggetto astratto che incontrerete più spesso è sicuramente l'oggetto "Programma". Questo è a tutti gli effetti un puntatore ad un file eseguibile, sebbene sia, come vedremo più avanti, qualcosa di più complesso di un semplice puntatore. Potete anche imbattervi in un oggetto "Dati", che è una sorta di puntatore ad un file fisico di dati.
3. Una "Copia Collegata" (Shadow) è un puntatore ad un vero file o ad un oggetto astratto.
Ciò che è stato detto sopra forse non rende bene l'idea della differenza tra una copia collegata e un oggetto astratto, percui conviene fare un approfondimento. Una copia collegata è in vero nient'altro che un puntatore. Se, per esempio, avete un file chiamato A.DAT e allo stesso tempo una copia collegata a questo file, allora ogni cambiamento fatto sul file si riflette automaticamente nella copia collegata. Se cambiate il nome al file, cambierà anche il nome della copia collegata. Se cambiate l'icona, anche l'icona della copia collegata cambierà. Se spostate il file in una directory differente, la copia collegata rimarrà ugualmente visibile nello stesso posto, ma registrerà internamente la nuova locazione del file. Se provate a cambiare le Proprietà della copia collegata, quello che farete è in realtà aprire il blocco-note Proprietà del file. Per finire, se cancellerete il file anche la sua copia collegata sarà cancellata (al contrario, la cancellazione di una copia collegata non comporta l'eliminazione del file originale).
Un oggetto Programma, al contrario, è un oggetto separato vero e proprio, sebbene contenga comunque un riferimento ad un qualche file eseguibile. Potete pensarlo come un puntatore molto flessibile - un puntatore avente diversi altri attributi. Il blocco-note Proprietà di un oggetto Programma è diverso dall'omologo di un file eseguibile. Ad esempio, potete decidere di assegnare due diverse icone ai due oggetti. Ma ancora più importante, potete specificare diversi valori nel campo Parametri. Più avanti spiegherò come ciò rappresenti un'utile caratteristica.
Cancellata una copia collegata, il ricostruirla è un'operazione piuttosto semplice. Oggetti programma cancellati accidentalmente possono lo stesso essere ricostruiti con un piccolo sforzo in più. Ma se eliminate un vero file o una directory, allora saranno davvero persi. Ecco perchè è importante capire con quale tipo di oggetti si ha a che fare.
Molte persone hanno schemi di colore per la Scrivania tali da poter riconoscere una copia collegata attraverso un distinto colore (ad es. quello relativo alla sua didascalia). Se non è sufficiente, provate a cliccare sopra l'oggetto con il tasto destro del mouse: se si tratta di una copia collegata, allora il menù concatenato ha una voce chiamata "Originale". Oppure, aprite il blocco-note Proprietà. Se si tratta di un vero file su disco noterete una o più voci "File". Se queste invece mancano allora l'oggetto è del tipo astratto. (ricordate comunque che anche una cartella del desktop è un "vero file" per gli scopi di questa nostra classificazione).
In un vero ufficio tutti i documenti dovrebbero essere raccolti in cartelle e queste riposte negli scaffali appropriati. La scrivania dovrebbe essere quasi spoglia e contenere solo gli strumenti di cui abbiamo bisogno più spesso e i documenti oggetto del lavoro corrente. Ok, forse la vostra non è proprio così, e la mia neppure. Ma essa avrebbe quest'aspetto se noi fossimo sufficientemente organizzati. In maniera simile, non dovrebbero esserci veri files (tranne le cartelle) nè sulla vostra Scrivania OS/2, nè nelle sue cartelle. Le uniche cose che dovrebbero esserci sono, appunto, le cartelle, gli oggetti astratti e le copie collegate.
La funzione principale di una copia collegata è quella di agire come una scorciatoia agli oggetti di più frequente utilizzo. Se volete mettere sulla Scrivania un oggetto Programma potreste usare una copia collegata. Ma ha più senso invece usare un Oggetto Programma. Ecco perchè:
1. I files eseguibili, soprattutto su partizioni FAT, hanno spesso e volentieri nomi alquanto difficili da decifrare. Un oggetto Programma non deve necessariamente avere lo stesso nome del file eseguibile. Per esempio potreste avere un eseguibile dal nome CMFW.EXE e creare per esso un oggetto Programma col nome "Apri il database".
2. I blocco-note degli oggetti Programma e degli eseguibili offrono entrambi la possibilità di specificare parametri e una directory di lavoro. Se riempite questi campi per un eseguibile finirete per usare gli stessi parametri ogni qualvolta avvierete quel programma. Ha invece più senso specificare questi parametri per un oggetto Programma. Potrete così creare diversi oggetti Programma basati sullo stesso file eseguibile, ma ognuno avente parametri differenti. Ad esempio potreste creare un oggetto Programma per avviare un'applicazione in una finestra e un altro per avviare la stessa applicazione a schermo intero.
CONCETTI CIRCA LA PROGRAMMAZIONE ORIENTATA AGLI OGGETTI (OBJECT-ORIENTED PROGRAMMING)Avrete sicuramente sentito più volte che OS/2 è un sistema operativo orientato agli oggetti. Cosa significa? Invece di rispondere immediatamente a questo interrogativo introdurrò prima il concetto di Programmazione Orientata agli Oggetti (Object-Oriented Programming o OOP).
È quasi un peccato che molte persone siano introdotte all' OOP attraverso il C++. Sta crescendo una intera generazione di programmatori con l'idea che l' OOP sia qualcosa di incredibilmente complesso, con una marea di regole oscure e casi speciali che farebbero la gioia solo di un avvocato.
Questa impressione è fuorviante. Succede solo perchè i cultori del C++ seguono una vecchia tradizione legata al C: "Non importa quanto complessa e oscura è la tua idea, ci sarà senz'altro un modo per realizzarla". Se guardaste ad un qualsiasi linguaggio di programmazione che supporta una forma "pura" di OOP, trovereste che la filosofia dell'OOP si basa sulla nozione di "economia dei concetti".
Il punto di partenza di base sta in un oggetto chiamato "classe". Una classe è un tipo di dati ed è simile al tipo "record" di molti linguaggi di programmazione, o ad un costrutto C. La differenza è questa: la definizione di classe racchiude non solo i dati componenti, ma anche una lista di procedure e funzioni che possono operare su oggetti di quella classe. (Nella terminologia OOP queste procedure e funzioni sono comunemente chiamati "metodi".) Per ragioni di sicurezza, e per incoraggiare uno stile di programmazione "pulito", ha senso insistere che non esiste modo di trattare i dati dell'oggetto se non attraverso i metodi che gli sono propri.
Riformuliamo quanto appena detto. Il tradizionale tipo di dati detto "record" definisce i dati componenti di un oggetto. La definizione di classe va al di là di questo: nel medesimo istante in cui si definisce la struttura di un oggetto si definisce anche l'insieme di operazioni che è possibile attuare su quell'oggetto.
Questo di per sè non definisce l'OOP. Si ottengono i medesimi risultati -sebbene con modalità diverse- in ciascun linguaggio di programmazione che supporta principi di "information hiding". Per renderlo orientato agli oggetti, ovvero object-oriented, dobbiamo introdurre il concetto di "ereditarietà".
Supponiamo di aver definito una classe oggetto C1 e di essere in procinto di definirne una nuova che chiameremo C2. Se specifichiamo che C2 eredita da C1 il risultato sarà che C2 includerà tutti i dati componenti e i metodi definiti per C1. In aggiunta C2 potrà avere alcuni componenti e metodi extra che non sono presenti negli oggetti di classe C1. Questo significa che un'oggetto della classe C2 è un oggetto della classe C1, ma con qualche proprietà in più.
Un modo di descrivere ciò è dire che C2 è una sottoclasse di C1. Personalmente trovo che questa descrizione può generare confusione; preferisco dire che C2 è un raffinamento di C1, ma entrambi i termini sono di uso corrente.
Molte implementazioni dell'OOP supportano anche una proprietà chiamata polimorfismo. Funziona così. Supponiamo che C1 includa un metodo chiamato F, e che anche C2 includa un metodo con lo stesso nome, ma con una diversa implementazione. Se ciò fosse legale -cosa che di fatto è in molti linguaggi OOP- il nome F genererebbe ambiguità perchè avremmo due funzioni con lo stesso nome. L'ambiguità è risolta nell' ovvio modo seguente: se F è applicato ad un oggetto di classe C2 è usato il metodo della classe C2. Viceversa, se applicato ad un oggetto della classe C1 (ma non di C2), allora è usato il metodo della classe C1.
Risultato finale è che si possono avere molte versioni differenti di una funzione. Quando questa funzione opera su un oggetto, la classe di quell'oggetto determina quale versione sarà usata.
Ci sarebbe in realtà molto altro da dire, ma ulteriori dettagli interessano solo i programmatori. Il nostro vero obiettivo qui è dare un'occhiata a ciò che l'orientamento agli oggetti significa per un sistema operativo.
In un certo senso, i termini "programmazione orientata agli oggetti" e "sistema operativo orientato agli oggetti" sono due cose diverse. Si può scrivere un sistema operativo orientato agli oggetti usando un linguaggio di programmazione che non è "orientato agli oggetti" e viceversa. Tuttavia, gli stessi concetti di "ereditarietà" sono usati in entrambi i casi. Un sistema operativo è orientato agli oggetti se supporta l'ereditarietà delle classi. L'interfaccia utente è orientata agli oggetti se le conseguenze di tale ereditarietà sono evidenti all'utente.
Facciamo un esempio concreto. Possiamo iniziare con una classe chiamata "file". I metodi di questa classe potrebbero includere le operazioni standard che si conducono su un file: apertura, chiusura, lettura e scrittura.
Potremo poi raffinare la classe, mediante la definizione di alcune sottoclassi, in svariati modi diversi. Potremmo per esempio definire una sottoclasse "directory"; gli oggetti di questa classe sono di un tipo speciale. Tutte le operazioni condotte sugli oggetti "file" sono applicabili agli oggetti "directory", ma gli oggetti di questa ultima godono di alcune operazioni extra che non sono applicabili agli oggetti della prima.
Un altro esempio: non è difficile comprendere come i vari tipi di oggetti dello schermo possano essere costruiti mediante successivi raffinamenti di classi. Si potrebbe, ad esempio, definire una classe "rettangolo su video" caratterizzata da poche operazioni elementari per scrivere in tale rettangolo. Poi si potrebbe successivamente promuoverla a classe "finestra a video" tale da includere cose come una barra del titolo. Dopo altri successivi passi si potrebbe finire con una classe "finestra con testo editabile" che ha tutte le proprietà di quelle precedenti e in più alcune speciali operazioni specifiche dell'editing a video (taglia, incolla, ecc.) L'editor di sistema di OS/2 è un esempio concreto di un oggetto costruito mediante questa specie di raffinamento appena descritto.
Per i programmatori l'aspetto principale dell'approccio "object-oriented" è che esso fornisce un meccanismo per il riutilizzo di software. Se vogliamo definire una nuova classe oggetto il modo per farlo è prendere una classe esistente che si avvicina per le sue caratteristiche a quello che ci serve, e da quella creare una sotto-classe con alcune caratteristiche in più. Se non esiste una classe che sia vicina a sufficienza alle nostre esigenze, vorrà dire che dovremo prepararci a realizzare un raffinamento multi-step - forse è un bel po' di lavoro, ma sempre meglio che iniziare da zero.
È anche importante capire che tutto questo non è nascosto all'interno del sistema operativo. Supponiamo che voi vogliate sviluppare una versione "drag & drop" delle popolari utilities "zip" e "un-zip". OS/2 ha già una classe "cartella" che include metodi che permettono all'utente di trascinare oggetti dentro e fuori le cartelle. Tutto quello che dovreste fare è sviluppare una sotto-classe della classe "cartella" con delle proprietà extra che permettano ad un oggetto di essere automaticamente compresso se spostato all'interno della cartella e decompresso se trascinato fuori di essa. Realizzare questo non richiede che voi facciate parte del team di sviluppo di OS/2, o abbiate accesso al codice sorgente di OS/2. è un qualcosa che può essere fatto con un qualsiasi programma per sviluppare applicazioni. Con un sistema operativo orientato agli oggetti è facile aggiungere estensioni personalizzate all'interfaccia utente.
Per l'utente il grande vantaggio dell'orientamento agli oggetti sta nel fatto che esso fornisce consistenza all'interfaccia. Esistono molti tipi differenti di oggetti, ma tutti hanno una classe ancestrale di appartenenza che supporta le operazioni basilari condotte con il mouse (trascinamento, apertura di menù, ecc.). Una volta che l'utente ha compreso come eseguirle, le ritroverà in tutti gli oggetti che derivano da quella classe ancestrale.
LIBRERIE A COLLEGAMENTO DINAMICO (DYNAMIC LINKED LIBRARIES)Una libreria è una collezione di codice eseguibile, meglio se di tipo sufficientemente versatile da poter essere utilizzato in molti programmi diversi. Lo scopo di una libreria è ovviamente quello di risparmiare ai programmatori la necessità di ricominciare a scrivere da capo del codice ogni volta. L'uso più tradizionale di una libreria consiste nel richiamo di procedure e funzioni dalla libreria stessa e nell'incorporazione di queste porzioni di codice nel programma eseguibile in via di sviluppo. Ma cosa succederebbe se due programmi che usano la stessa libreria di funzioni fossero avviati nello stesso istante? Due copie della stessa libreria si ritroverrebbero caricate in memoria. Uno spreco questo che potrebbe essere evitato se esistesse un modo per assicurare che solo una copia del codice condiviso venga caricato.
Un modo per raggiungere lo scopo può essere quello di pre-caricare l'intera libreria in memoria, permettendo all'applicazione di richiamare le funzioni necessarie piuttosto che incorporare il codice dell'intera libreria all'interno del file eseguibile. Questo era quello che effettivamente veniva fatto in alcuni software del passato. Il problema è che oggigiorno abbiamo un numero elevato di librerie, per di più di grosse dimensioni. Finiremmo con l'impegnare grosse quantità di memoria solo per esse. Inoltre, gran parte del loro codice finirebbe con l'essere inutilizzato. Di certo questo non rappresenterebbe un uso efficiente della memoria centrale.
Una DLL sta un po' nel mezzo di questi due estremi. Quando nel codice di un'applicazione è specificato il richiamo di una certa funzione da una data libreria, il collegamento del programma con questa libreria (linking) non viene effettuato fin tanto chè il programma stesso non sia eseguito (per questo il linking è definito "dinamico"). Quando il sistema "apprende" della necessità dell'utilizzo di una DLL, questa viene caricata in memoria. Se due programmi differenti usano la stessa DLL, solo una copia di essa viene caricata. Quando il suo utilizzo è terminato, la DLL può essere scaricata dalla memoria centrale per lasciar spazio ad altre applicazioni.
Il linking dinamico ha solamente un piccolo inconveniente di run-time, cioè viene effettuato in tempi un po' più lunghi rispetto a quello non dinamico (quando cioè le porzioni della libreria sono legate fisicamente al resto del codice dell'applicazione). Ma, dato il migliore utilizzo della memoria, è considerato da molta gente come un inconveniente del tutto accettabile.
VIO, PM e la WPSAbbreviazioni come "WPS" (Work Place Shell o Scrivania) sono usate moltissimo tra gli utenti di OS/2. È bene allora familiarizzare con il gergo per non sentirsi, in qualche modo, "tagliati fuori".
Il VIO (Virtual Input/Output) è quella parte di OS/2 che ha a che fare con l'output a schermo in "modalità testo". I programmatori usano chiamate di tipo VIO per far girare i loro programmi in una sessione "OS/2 finestra" oppure "OS/2 a schermo intero" (OS/2 Full Screen). Detto in parole più semplici, qualsiasi applicazione OS/2 in "modalità testo" è generalmente un'applicazione VIO. (è anche possibile scrivere applicazioni grafiche in modalità "schermo intero" che possano by-passare il layer VIO e lavorare più direttamente con lo schermo. Una applicazione del genere può solo funzionare in una sessione a "schermo intero"; il sistema infatti non le permetterebbe di girare in una finestra.)
Il Presentation Manager (PM) è un software di livello più alto, che fornisce caratteristiche quali finestre grafiche, finestre nidificate, menù, bottoni, fonts a corpo variabile, ecc. Le applicazioni OS/2 in "modalità grafica" sono quasi sempre applicazioni per PM.
Una "shell di comando" (command shell) è quella parte del sistema operativo che accetta un input fornito dall'utente. Alcune shell sono in modalità testo e accettano comandi digitati sulla tastiera. Altre sono shell di tipo GUI (Graphic User Interface) ad interfaccia grafica e usano ad esempio un mouse come fonte primaria di input. Nativamente, OS/2 è corredato di una shell in modalità testo ed una di tipo GUI. Ognuno ha la possibilità di sostituire a suo piacimento queste shell con altre fornite da terze parti. La shell a linea di comando è CMD.EXE. Questo è il programma che viene attivato quando apriamo una finestra OS/2 o richiamiamo una sessione OS/2 a schermo intero.
La shell GUI standard è PMSHELL.EXE, meglio conosciuta come Work Place Shell (WPS o Scrivania). Normalmente nel file CONFIG.SYS è contenuta una riga PROTSHELL che avvia la WPS al boot del sistema. Nel caso si desiderasse avviare OS/2 senza la WPS basta cambiare "PMSHELL" con "CMD" in corrispondenza della riga PROTSHELL.
Quando si avvia una sessione OS/2 a schermo intero quello che si fa è disabilitare temporaneamente la WPS dando il controllo alla shell testuale. Una finestra OS/2 è qualcosa di lievemente diverso: la shell in modalità testo viene eseguita come un'applicazione per PM ed è controllata dalla WPS.
La ragione per la quale un interprete dei comandi è chiamato "shell" è perchè non è, strettamente parlando, parte del sistema operativo; è invece uno strato più esterno, un "guscio". Una shell di comando non è altro che un programma applicativo in più.
CLASSI REGISTRATEEccoci di nuovo sull'argomento "orientamento agli oggetti"
Quando un programmatore definisce una nuova classe oggetto, la sua definizione deve essere accessibile a tutti i potenziali utilizzatori di quella classe. Se la classe è usata solo all'interno dello stesso programma, la sua gestione dipende dal linguaggio di programmazione usato e il sistema operativo non è necessitato ad intervenire. Se, invece, quella classe è stata creata per essere disponibile ad altri programmi, il sistema operativo deve necessariamente esserne "informato". La classe diventa quindi una "classe registrata"
[nota: per brevità il discorso è stato molto semplificato. La storia completa circa una classe registrata è un qualcosa di piuttosto complesso, ed io stesso non sono del tutto sicuro di averla capita pienamente. Considerate quindi tutto quello che segue come una grossolana approssimazione di ciò che è nella realtà.]
Ricordate che una classe consiste di una struttura di dati e di un set di metodi - ovvero, codice eseguibile - che operano sui dati di quella classe. Dove si mantiene il codice eseguibile? La soluzione di OS/2 sta nel metterlo in una DLL. Quando una classe è registrata per un uso pubblico, il programmatore fornisce il nome della classe ed il nome della DLL. Di conseguenza, qualsiasi uso di quella classe comporta il richiamo del codice dall'interno della DLL.
Nelle versioni più recenti di OS/2 le DLLs per alcune classi vengono caricate in memoria all'avvio del S.O. (non ricordo bene quando questo aspetto venne introdotto per la prima volta, ma di sicuro è ciò che accade in Warp 4). Questo rallenta il processo di boot, ma è un modo per assicurare un accesso veloce alle DLLs di uso più frequente. Da ciò deriva che se una particolare DLL è caricata ma non usata, presto viene spostata dalla memoria principale al file di swap.
Le classi pre-caricate all'avvio sono elencate come voci PM_Workplace:IplLoad nel file OS2.INI. In aggiunta, ve ne sono altre, per così dire pre-caricate, presenti fin dall'avvio semplicemente perchè usate da componenti software (come appunto la WPS) presenti per tutta la durata dell'utilizzo del s.o.
Da notare anche che molte di queste DLLs, se non tutte, implementano più di una classe. Alla richiesta di una specifica classe l'intera libreria è caricata fornendo il supporto per tutte le altre in essa contenute. Questo spiega perchè, ad esempio, il poco amato viewer di immagini di sistema non può essere rimosso se non con la rimozione dell'intero supporto multimediale.
ASSOCIAZIONIL'intero contenuto del vostro file system può essere a grandi linee suddiviso tra files di programma e files di dati. La gente che ha familiarità con i computers tende comunemente a considerare i programmi come gli elementi "attivi" e i files come un qualcosa che è manipolato dai programmi.
Gli utenti che invece non sono molto esperti di "software" in generale tendono a guardare la cosa da un lato diverso. Per essi i files importanti sono i documenti creati con il word processor, oppure i fogli di calcolo, i databases, ecc. I programmi sono solo un qualche cosa facente parte del "meccanismo interno" del computer - un qualcosa che "deve" essere lì, senza che per questo si debbe necessariamente comprenderne appieno il loro funzionamento -
Un approccio "orientato agli oggetti" calza proprio le esigenze di questo secondo gruppo di persone. Quando si inizia a lavorare con qualche tipo di oggetto, l'operazione base è "aprire quell'oggetto". È una faccenda del computer capire se aprirlo come documento di un elaboratore testi, oppure pagina web, o qualcos'altro di appropriato.
Questo si rende possibile stabilendo associazioni tra gli oggetti dati e i programmi. Una volta fatto, un operazione del tipo "apri" condotta su un oggetto invocherà il programma associato. OS/2 permette di stabilire due tipi di associazioni:
1. associazioni per "tipo oggetto". Ogni oggetto nel file system è di un tipo, ed è quindi possibile associare un programma con ciascuno di questi "tipi" (è anche possibile creare nuovi tipi di oggetto). Se, per esempio, usate IBM Works, scoprirete che i documenti creati dal word processor sono oggetti del tipo "FPWorks WP", e che il programma IBM Works è associato con oggetti di questo tipo. A proposito, "tipo" e "classe registrata" non sono la stessa cosa, sebbene "lavorino" quasi allo stesso modo.
2. associazioni attraverso un filtro. Questo approccio è di tipo più tradizionale, dove le associazioni sono determinate sulla base del nome dell'oggetto. Ad esempio, vi potrebbe essere utile scompattare automaticamente un file compresso "*.ZIP" semplicemente facendo doppio click su di esso. Il modo per farlo è specificare la voce "*.ZIP* come associazione con il programma incaricato dello scompattamento. Altro esempio (forse meno utile del primo), potreste specificare un'associazione tra un programma e tutti i files chiamati "A?B.TXT", dove "?" sta per qualsiasi carattere.
Un file può essere associato a più di un programma. In questo caso la voce del menù dell'oggetto "Apri come" avrà più opzioni, di cui una sarà selezionata per default. È possibile cambiare il valore di default (per un oggetto alla volta) alla voce "Menu" del blocco note "Proprietà" di quell'oggetto. Per operare un cambiamento su larga scala bisogna avere un editor delle associazioni.
[Nota: il viewer di immagini di Warp 4 è azionato di default ogni qualvolta si vogliono visualizzare i vari files grafici e sembra non esserci alcun modo per cambiare tale valore di default, se non agendo su ciascun file alla volta. Questo sembrerebbe essere un bug di Warp 4]
Se si dà un'occhiata al blocco-note "Proprietà" dei vari oggetti di sistema si scopre che gli oggetti programma (files eseguibili) hanno una pagina "Associazioni", mentre gli oggetti di dati in genere non l'hanno. Questa è una nuova caratteristica di Warp 4. Nelle versioni precedenti del S.O. molti utenti provavano a cambiare le associazioni agendo sul blocco-note Proprietà degli oggetti stessi, per poi meravigliarsi di non ottenere l'effetto desiderato. (In questo caso accadeva che l'associazione veniva stabilita per quel particolare oggetto, ma non per *tutti* gli oggetti di quel tipo.)
In Warp 4.0, dove le associazioni si stabiliscono agendo sull'oggetto Programma, è meno probabile incappare in questo inconveniente. Noterete inoltre che il blocco-note Proprietà di un oggetto di dati possiede di solito una pagina "Tipo", e qualche volta anche una pagina "Nuova classe". OS/2 imposta le associazioni e la classe di appartenenza dell'oggetto usando alcune "ragionevoli" definizioni standard, ma se la scelta non vi piace, potete cambiarla. |
![[Pagina precedente]](../../images/tab01.gif)
![[Sommario]](../../images/tab02.gif)
![[Pagina successiva]](../../images/tab03.gif)