Device driver per OS/2

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "Device driver per OS/2"

Transcript

1 Device driver per OS/2 Consigli e considerazioni Tratti dalla Developer Connection News Autore: Steve Mastrianni (IBM) Traduzione e adattamento per il PIDO/2: Mentore Siesto Marzo 2007

2 Note del traduttore. Questi articoli risalgono ai primissimi anni 90, quando la versione ufficiale di OS/2 era la 1.3 e il divorzio tra IBM e Microsoft non era ancora concluso. Alcune di queste considerazioni, pertanto, riguardano la vecchia versione a 16 bit di OS/2 e non sono applicabili direttamente alle recenti revisioni del sistema operativo. Inoltre, questa non è una guida completa allo sviluppo di device driver per OS/2, quanto una serie di considerazioni sullo sviluppo; solo nell ultima parte si hanno a disposizione effettive utilità per la programmazione. Per informazioni maggiormente complete sullo sviluppo di device driver per OS/2, si rimanda al libro di Mastrianni Writing OS/2 2.1 device drivers in C, che eventualmente verrà tradotto per il PIDO/2 (si tratta di un tomo particolarmente ponderoso, di oltre 700 pagine) e alla documentazione già tradotta per il PIDO/2 in merito. Indice Generale Pag. Racconti dalla trincea 3 Assemblaggio richiesto: i device driver per OS/2 6 Finalmente, arrivano gli strumenti di programmazione per OS/ Confessioni di uno sviluppatore DDK 18 OS/2 ha supporto ai device 21 Scrivere device driver come ottenere il meglio da OS/2 22 Scrivere device driver: da dove partire? 23 Scrivere device driver una breve occhiata a OS/2 SMP 25 Scrivere device driver Interrupt 27 Scrivere device driver basi del Plug & Play 28 Scrivere device driver segmenti multipli 29 2

3 Steve Mastrianni è un Industry Consultant, specialista in device driver e applicazioni real time per OS/2. Autore del libro Writing OS/2 2.1 device drivers in C, Steve è considerato uno dei maggiori esperti nel campo di OS/2 e dei device driver per OS/2. Steve è raggiungibile su oppure in Internet come I consigli dell esperto OLTRE IL DOS: WINDOWS e OS/2 Racconti dalla trincea Discorsi di un programmatore specializzato nella scrittura di device driver per OS/2 Autore: Steve Mastrianni Nel gennaio del 1989, stavo effettuando una presentazione su OS/2 ai rappresentanti di un possibile cliente. Costoro avevano un sistema basato su DOS per l acquisizione dati, che mancava della capacità di acquisire ed elaborare i dati in contemporanea. Fatte le loro considerazioni, avevano concluso che OS/2 avrebbe potuto fare al caso loro, ma ancora non erano convinti che ciò non sarebbe stato possibile con Unix. L applicazione era perfetta per OS/2. Il sistema doveva controllare le transazioni sul bus seriale e i livelli di tensione in tempo reale, e doveva agire immediatamente al verificarsi di certe condizioni. Questo portava subito Unix fuori dal discorso, dato che esso manca di prelazione. Tutto andava bene, fino a che uno degli ingegneri senior pose la domanda ovvia: Ovviamente possiamo avere device driver per il nostro hardware specializzato, no?. Feci un po di scena e passai ad altri argomenti, promettendo di tornare sul discorso dei driver in seguito. Chiamando i rivenditori hardware, ho avuto da tutti la stessa risposta: Ci dispiace, abbiamo solo i driver per DOS. Vorremmo supportare OS/2, ma non abbiamo chi sappia come scriverli. Sappiamo che sono molto difficili da scrivere, e solo pochi clienti, comunque, ce ne hanno richiesti.. Decisi di capire il perché: perché dovrebbe essere così difficile scrivere un driver per OS/2? E dunque, feci le valigie e andai alla Microsoft University per il corso di scrittura di device driver per OS/2. Il corso durò una settimana, e fu uno dei più intensivi che io abbia mai seguito. Basi dei device driver. Quando un applicazione OS/2 deve effettuare un operazione di I/O, essa formula una richiesta di I/O al kernel. Il kernel verifica la richiesta, la traduce in un pacchetto di richieste al driver, e chiama il device driver per il servizio. Il driver gestisce tutti i dettagli dell hardware: indirizzamento I/O, temporizzazione, impostazione dei registri, gestione degli interrupt e controllo degli errori. Quando il dispositivo risponde, il driver organizza e formatta i dati in un formato che l applicazione possa riconoscere, reinvia i dati o un messaggio di stato e notifica al kernel che la richiesta di servizio è stata completata. Se il driver non riesce a gestire direttamente la richiesta, può bloccare il thread che l ha formulata oppure restituire un request not done al kernel. In qualsiasi caso, il driver lascia libera la CPU e permette l esecuzione di altri thread. In caso d errore, il driver lo invia al kernel assieme a un messaggio di stato request complete. 3

4 Quel che rende unici i driver per OS/2 è la necessità di operare in modo reale e protetto. Gli indirizzi calcolati nel modo reale non valgono se il sistema passa al modo protetto, e viceversa. Il driver deve gestire le commutazioni di modo al volo. Comprendere questa operazione bimodale è la chiave della scrittura dei driver per OS/2 1.x. Molte routine Device Helper (DevHlp) supportano le operazioni bimodali, ma imparare come organizzarle può aiutare molto. Un salto in profondità Rientrato dalla Microsoft University, ero ansioso di provare il mio primo driver. Ordinai il Device driver development kit (DDK) da Microsoft, che contiene l importante kernel debugger. Il KDB è un kernel sostitutivo che, tra le altre cose, conosce le strutture dei driver. Per esempio, per mostrare un pacchetto di richieste, basta usare il comando.d req es:bx. KDB formatta i dati e li mostra nella forma del pacchetto di richieste. Non potete nemmeno pensare di scrivere un driver per OS/2, senza questo strumento! Iniziai con un semplice driver nullafacente, basandomi sugli esempi dati nel corso: esso funzionò perfettamente. A quel punto iniziai con il vero problema: i miei clienti necessitavano di un driver per una scheda A/D a otto canali. La scheda usava un controller intelligente pilotato a interrupt e permetteva i trasferimenti in DMA. Scartabellai furiosamente tra la mia documentazione da studente per cercare esempi di come implementare un simile driver, inutilmente. Non vi erano esempi di gestori di interruzione, niente sul DMA, niente sulle funzioni di controllo dell I/O definite dall utente. Microsoft, chiamata da me, mi rinviò a Compaq (che forniva la versione di OS/2 in mio possesso), la quale mi rimandò a Microsoft. Cercai nelle librerie di informatica senza successo: alla fine, mi rimboccai le maniche e cominciai a sperimentare. Il driver fa un lavoro semplice in linea di principio. Esso deve gestire le richieste del kernel e restituire i risultati all applicazione. Un driver per OS/2 riceve due tipi di richieste: alcune possono essere completate immediatamente, altre no. Le richieste vengono realizzate tramite una struttura dati standard chiamata pacchetto richieste (request packet). Il kernel manda al driver un puntatore bimodale al request packet. Dato che il driver deve poter operare in modalità reale o protetta, il puntatore bimodale assicura che il request packet sia accessibile in entrambi i modi. Quando una richiesta non può essere gestita istantaneamente (es., nel caso di una ricerca su disco). Il driver (tramite alcune routine DevHlp) la pone in una coda. I driver per dischi possono scegliere se ordinare le richieste pendenti per ricerche su disco in ordine di settore, per minimizzare il tempo di ricerca. L architettura a thread di OS/2 dà una responsabilità extra al programmatore. Quando un driver non riesce a gestire una richiesta all istante, esso blocca il thread richiedente; al completamento della richiesta, il driver sblocca il thread. Strumenti di sviluppo Il DDK arriva con un raccoglitore ad anelli contenente le strutture dei driver, le descrizioni delle routine DevHlp, e le istruzioni per l uso del KDB. Solo le prime 40 pagine circa sono state utili. Il libro descrive le DevHlp in dettaglio, ma non contiene esempi di driver funzionanti. Tutti i driver che scrivo, inclusi i gestori di interruzione, sono realizzati in C Microsoft 6.0 alla massima ottimizzazione. Non sprecate tempo a scrivere driver in assembler. Scrivere un driver in C richiede circa la metà del tempo che serve per lo stesso driver in assembler, ottenendo un modulo che funziona nello stesso modo. 4

5 Un altro strumento utile è DDC.LIB, una libreria per device driver chiamabile dal C e distribuita da Pentasoft (17541 Stone Ave. N, Seattle, WA 98133, (206) ). Forse la funzione più importante dalla DDC.LIB è Transfer, che trasporta i dati tra i driver e le applicazioni e tiene conto del cambio di modalità durante il trasferimento. DDC.LIB gestisce il trasferimento di dati dalla memoria virtuale a quella fisica e viceversa, da virtuale a virtuale e da fisica a fisica. Se intendete lavorare seriamente sullo sviluppo di driver per OS/2, questa libreria è obbligatoria. La luce alla fine del tunnel? Chiunque abbia scritto driver per altri sistemi operativi multitasking (come Unix o VMS) avrà buone basi per la scrittura di driver per OS/2. Microsoft stima che un programmatore C esperto che abbia seguito il corso alla Microsoft University impiega da quattro a sei mesi per scrivere il suo primo driver per OS/2. Driver successivi impiegano da due a quattro mesi: i disk driver sono più impegnativi e possono richiedere più tempo. Per il mio primo driver ho impiegato circa tre mesi. Il successivo ne richiese due, e in seguito riuscii a scrivere alcuni semplici driver in una settimana circa, quindi la cosa si semplifica con la pratica. Anche se i driver per OS/2 divengono più comuni al tempo attuale, la situazione è comunque grama. Per la maggior parte sono driver specializzati e non immediatamente disponibili. Quel che serve sono driver standard di uso generico, adattabili a hardware diverso. Per esempio, mi piacerebbe vedere un driver per CD-ROM per OS/2, o per schede fax o nastri magnetici, ma ancora non ne vedo. Perché? Ci sono certamente più clienti, adesso, che richiedono driver per OS/2. Senza di essi, il sistema operativo prescelto potrebbe non essere OS/2. OS/2 2.0 non semplificherà la scrittura dei device driver. Certamente, sparirà il modo reale, per cui il driver non dovrà occuparsi delle operazioni bimodali. L architettura dei driver DOS però cambierà radicalmente. I programmi DOS chiameranno un Virtual Device Driver, invece che accedere direttamente all hardware. Il VDD gestirà la richiesta e la manderà al device driver fisico (PDD). Il PDD effettuerà le comunicazioni a basso livello con il device e rinvierà i dati al VDD. L interfaccia VDD è nuova, mentre il PDD altro non è che il meccanismo standard bimodale di OS/2 1.x, privo della parte in modalità reale. Il VDD esamina il BIOS e le altre funzioni di interrupt, permettendo così a un applicazione DOS di pensare di stare parlando con il dispositivo, mentre essa sta in realtà comunicando con il VDD. Le applicazioni che funzionano in modo protetto continueranno a chiamare i driver per OS/2, come nella versione 1.x, ma potranno usare l indirizzamento lineare 0:32. A giugno, Microsoft ha annunciato una nuova architettura per device driver per memorie di massa, chiamata LAyered Device DRiver architecture (LADDR). Microsoft asserisce che la LADDR possa ridurre del 90 % il tempo necessario a realizzare un sistema di memorie di massa. Spero che ciò sia vero, ma in base a quanto ho visto finora non ci scommetterei la casa. Un nuovo DDK porterà con sé codice standard per i driver, per cui lo sviluppatore dovrà solo aggiungere il codice specifico del device per implementare un driver completo. Non ho ancora visto il nuovo DDK, quindi non posso verificare le affermazioni di Microsoft. Alla data della scrittura, Microsoft non ha ancora una data di rilascio per il kit LADDR. I driver non destinati alle memorie di massa continueranno a essere scritti con i metodi convenzionali. IBM e Microsoft non hanno ancora fatto abbastanza per aiutare coloro che cercano di realizzare i driver di cui OS/2 ha tanto bisogno. L aggiornamento del DDK dalla versione 1.1 alla 1.2 è molto indietro con i tempi, e anche l NDDK, usato per sviluppare i driver per schede di rete per la Extended Edition, è in ritardo. Il DDK versione 1.1 non funziona sulle macchine PS/2, per cui i driver vanno sviluppati per l architettura ISA. 5

6 Le informazioni sono ancora grezze e incomplete. Sono apparsi molti libri, ma nessuno di essi fornisce esempi di device driver in C. La maggior parte della documentazione disponibile descrive le funzioni DevHlp e le loro sequenze di chiamata, ma non come organizzarle in un driver. Quel che serve è una guida alla scrittura di driver che demistifichi la scrittura dei device driver per OS/2. La guida dovrebbe contenere esempi di driver scritti in C, non frammenti sparsi di codice Assembly. Dovrebbe anche contenere una lista di utili funzioni per aiutare lo sviluppo e la correzione di device driver. Fino a che queste informazioni resteranno indisponibili, lo sviluppo dei device driver resterà il tallone d Achille di OS/2. Assemblaggio richiesto: i device driver per OS/2. Guida allo sviluppo di un driver asincrono per terminale RS-232 per OS/2 in C. Autore: Steve J. Mastrianni I device driver per OS/2 continuano a essere un fattore limitante nell accettazione e nell uso di OS/2. I driver per DOS abbondano, ma quelli per OS/2 sono rari come i denti in un neonato, per vari motivi. I driver per OS/2 sono più complicati di quelli per DOS. Essi devono gestire la commutazione di contesto e le priorità, e permettere le operazioni in due modi, reale e protetto, cose sconosciute a molti programmatori DOS. Nell articolo descriverò come scrivere un driver per terminale RS-232 asincrono in C per OS/2, completo di gestione degli interrupt e supporto del timer (il codice necessario per il driver è disponibile su BIX). Una volta vista la strada, avrete la comprensione base per scrivere driver per OS/2 per altri dispositivi. La natura della Bestia I device driver per OS/2, come altri driver multitask, nascondono alle applicazioni le caratteristiche fisiche dei dispositivi di I/O (come la temporizzazione o l indirizzamento delle porte di I/O). Un applicazione che richiede un servizio di I/O manda una richiesta al kernel, che a sua volta chiama un driver. Il driver gestisce tutti i dettagli hardware, come l impostazione dei registri, la gestione degli interrupt e il controllo degli errori. Quando la richiesta è completa, il driver prepara i dati in un formato riconoscibile dall applicazione. Esso poi manda i dati o un messaggio di stato all applicazione, e notifica al kernel il completamento dell operazione. Se la richiesta non può essere gestita al momento, il driver può bloccare il thread oppure restituire un messaggio di Request Not Done al kernel: in ogni caso, il driver libera la CPU e permette l esecuzione di altri thread. I device driver per Dos non hanno una controparte OS/2 diretta. Essi sono semplici driver monotask in polling. Anche i driver a interrupt sotto DOS eseguono il polling fino a che l elaborazione dell interrupt non viene completata. I device driver per DOS supportano una richiesta per volta, e altre richieste successive dal kernel DOS portano al crash del sistema. Al contrario, un driver per OS/2 deve gestire il sovrapporsi di richieste provenienti da diversi processi e thread, per cui dev essere rientrante. Deve anche gestire gli interrupt dal dispositivo e quelli provenienti dal gestore del timer. Inoltre, il driver per OS/2 deve sovrintendere alle commutazioni tra modo reale e protetto. Queste operazioni devono essere portate a termine con efficienza, permettendo ad altri thread di avere accesso alla CPU, e soprattutto, deve lavorare in maniera affidabile. Dato che opera a livello 0, il driver per OS/2 è il solo programma che ha accesso alle funzioni critiche del sistema (es., il sistema di interrupt e il timer). Il driver, pertanto, dev essere affidabile, dato che qualsiasi errore in esso può causare un crash dell intero sistema. 6

7 I device driver per OS/2 devono essere anche bimodali, ossia in grado di operare in modalità reale e protetta (per OS/2 1.3). È necessario continuare a elaborare gli interrupt, e le richieste devono essere completate anche se l utente rientra nel prompt di OS/2 dal DOS compatibilità box e viceversa. I driver devono poter essere disinstallati a richiesta, liberando la memoria utilizzata. Inoltre, i driver possono supportare monitor per il dispositivo, ossia programmi che controllano i dati che passano dal driver al kernel e viceversa. Fortunatamente OS/2 fornisce una vasta gamma di servizi di sistema chiamati routine Device Helper, o DevHlp, che forniscono queste funzionalità. Gli strumenti dell officina Sviluppare un driver per OS/2 richiede una comprensione completa del ruolo di un device driver, oltre a una solida conoscenza del sistema operativo e della filosofia di OS/2. Il debug di driver OS/2 può essere difficile, anche con gli strumenti adatti. Il driver opera a livello 0, con accesso totale all hardware di sistema. Però, esso quasi non ha accesso ai servizi di supporto di OS/2, eccezion fatta per una manciata di routine DevHlp. Molte volte si hanno fallimenti nei driver in un contesto di tempo reale, come nel mezzo della gestione di un interrupt. Può essere difficile, se non impossibile, trovare un problema in un driver con le normali tecniche di debug. In tali casi è necessario visualizzare il lavoro del driver e di OS/2 al momento dell errore, per poter rilevare il problema e correggerlo. Lo strumento più importante in assoluto è il debugger per il driver. Generalmente io uso il kernel debugger di Microsoft, presente nel DDK. Molte altre compagnie offrono buoni strumenti per lo sviluppo di driver. Una versione più completa di questo articolo in forma di libro e una libreria DevHlp completa e utilizzabile in C sono disponibili presso PSS. PentaSoft dispone di un interfaccia per il linguaggio C alle routine DevHlp. OS Technologies offre un debugger per driver indipendente dalla versione di OS/2. FutureWare, infine, vende un debugger per driver e un interfaccia in C per le routine DevHlp. Io scrivo tutti i miei driver, inclusa la gestione di interrupt e timer, con Microsoft C 6.0. Un driver in C viene scritto in circa metà del tempo che impiega la sua scrittura in assembly con il Microsoft Macro Assembler. In casi speciali, soprattutto scrivendo driver per dispositivi molto veloci o dove le prestazioni sono assolutamente critiche, ha senso scrivere alcune routine in assembly: la massima parte dei driver, comunque, funziona correttamente anche scritta in C. Anatomia di un device driver per OS/2 I driver ricevono le richieste dal kernel di OS/2. Quando il driver viene inizialmente aperto tramite una chiamata a DosOpen, il kernel restituisce uno handle al programma che ha richiesto l accesso al driver. Questo handle viene usato per gli accessi successivi al driver, il cui nome non è più necessario né usato. Quando un applicazione chiama un driver, il kernel intercetta la chiamata e formatta la richiesta per il driver in una struttura dati standard chiamata request packet. Il request packet contiene i dati e i puntatori usati dal driver per far fronte alla richiesta. Nel caso di DosRead o DosWrite, per esempio, il request packet contiene l indirizzo fisico del buffer del chiamante. Nel caso di un operazione di controllo di I/O (IOCtl), il request packet contiene l indirizzo virtuale di un buffer di dati e parametri. In dipendenza dalla richiesta, i dati nel request packet cambieranno, ma la lunghezza e il formato dell intestazione del request packet rimangono costanti. Il kernel passa al driver un puntatore bimodale al request packet. Questo indirizzo bimodale, o impilato, è un puntatore valido in modo protetto e reale, dato che il processore potrebbe essere in uno qualsiasi di questi due modi alla chiamata al driver. 7

8 Come fa il kernel a sapere quale driver chiamare? I driver vengono caricati da OS/2 a tempo di avviamento, e il kernel mantiene un elenco dei driver installati per nome. Prima di usare un driver, questo va aperto da parte dell applicazione con DosOpen. Questa API specifica una stringa ASCII-Z con il nome del device come parametro. Il kernel confronta tale nome con l elenco dei driver installati e, se trova il nome corrispondente, chiama la parte Open della sezione Strategy del driver per aprire il dispositivo. Se l operazione ha successo, il kernel restituisce uno handle all applicazione per l uso futuro del driver. Il nome ASCII-Z non viene più usato, per tutto il periodo in cui il driver resta aperto. Gli handle al dispositivo sono di norma assegnati in sequenza, a partire da 3 (0, 1 e 2 sono riservati a OS/2). Non è comunque buona idea dare per scontato il valore dello handle. Il nome ASCII-Z del dispositivo invece è localizzato nell intestazione del driver. Il request packet di OS/2 Un device driver per OS/2 consiste di una sezione Strategy e di sezioni opzionali Interrupt e Timer. La sezione Strategy riceve le richieste dal kernel in forma di request packet. La sezione verifica la richiesta e, se possibile, la completa e manda il risultato al kernel. Se la richiesta non può essere completata immediatamente, il driver può opzionalmente accodare la richiesta da completare a tempo successivo e lancia l operazione di I/O se necessario. Il kernel chiama la sezione Strategy direttamente, trovando il suo indirizzo offset nell intestazione del driver. La prima voce nel request packet è la lunghezza dello stesso, data dal kernel. Il secondo parametro è il codice di unità. Quando un driver supporta più unità logiche, il valore qui presente seleziona l unità. Il terzo campo è il codice di comando, dato dal kernel, ossia il codice usato dal comando switch della sezione Strategy per comprendere il tipo di richiesta proveniente dal kernel. Il campo successivo è la word di stato restituita al kernel. Questo campo conterrà il risultato dell operazione del driver, assieme al bit Done per notificare al kernel che la richiesta è completa (non è sempre così: il driver potrebbe ritornare senza aver settato tale bit). Per facilitare le cose, uso un tipo unione per accedere a tipi specifici di richiesta e piazza le strutture dei request packet in un file include. Creare il device driver per OS/2 Un semplice device driver per OS/2 consiste di un segmento codici e un segmento dati, anche se a richiesta è possibile allocare più memoria (grazie alle routine DevHlp). I primi dati che appaiono nel segmento dati corrispondono all intestazione del driver. Tale intestazione è una struttura a lista collegata di lunghezza fissata, che contiene informazioni utilizzabili dal kernel durante la fase di INIT e le operazioni normali. La prima voce dell intestazione è un puntatore al prossimo dispositivo supportato dal driver. Se nessun altro dispositivo viene supportato, il puntatore viene posto a -1L: ciò termina l elenco dei dispositivi supportati dal driver. Se il driver supporta più dispositivi, come capita a una scheda seriale a quattro porte o a un controller per dischi, il collegamento è un puntatore FAR alla prossima intestazione. La voce successiva nell intestazione del dispositivo è la word degli attributi, seguita da un offset di una word alla sezione Strategy del driver. Solo l offset è necessario, perché il driver è scritto con il modello small con un segmento codice di 64 kib e un segmento dati di 64 kib (non è sempre vero: in certi casi il driver può allocare più spazio per codice e dati, se necessario). La voce seguente è un indirizzo offset a una routine di comunicazione interdriver, se il driver supporta l IDC (il bit DAW_IDC nella word di attributi del driver dev essere settato; in caso contrario, la chiamata ad AttachDD dall altro driver fallirà). 8

9 L ultimo campo è il nome del dispositivo, che dev essere lungo otto caratteri. I nomi con meno di otto caratteri vanno riempiti con spazi vuoti. Ricordate che un errore nel codificare l intestazione del device driver causerà il crash immediato all avvio del sistema. Dare al driver C un interfaccia ai registri I driver per OS/2 sono normalmente scritti in C con il modello di memoria small, quindi in genere accedono a 64 kib di codice e 64 kib di dati. Il file.sys del driver deve caricare il segmento dati prima del segmento codice. Quando scrivete un driver per OS/2 in C, dovete fornire un meccanismo per porre i segmenti codice e dati nell ordine opportuno, e dovete dare anche un interfaccia a basso livello per gestire gli interrupt del dispositivo e del timer. Dato che l intestazione del device dev essere il primo elemento del segmento dati, è necessario che il compilatore C non inserisca il codice C di avvio prima dell intestazione. Potreste dover inoltre fornire un metodo per rilevare quale dispositivo viene richiesto per driver che supportano più unità. Il breve programma assembly nel listato 4 si occupa di queste richieste: l entry point _actrused impedisce l inserimento del codice di avvio C prima del segmento dati del driver. Le direttive di ordinamento dei segmenti assicurano che il segmento dati preceda quello codice. Notate l entry point _STRAT. Come viene chiamato? Ricordate che questo è l indirizzo posto nell intestazione del device, nel segmento dati del driver. Quando il kernel fa una richiesta al driver, esso cerca questo indirizzo nell intestazione del device e realizza una chiamata FAR a tale indirizzo. La routine in assembly, quindi, chiama la linea C. In tal modo viene stabilito il collegamento tra il kernel e il driver. Perché vi è un push 0 all inizio della routine _STRAT? Quello è il numero del dispositivo. Ogni dispositivo supportato dal driver richiede un intestazione separata, ognuna delle quali contiene un suo indirizzo offset per la propria sezione Strategy. Usando l interfaccia assembly, la routine spinge nello stack il numero del dispositivo e lo passa alla sezione Strategy del driver. La sezione Strategy Questa sezione è né più né meno di un grosso switch. Le richieste comuni al driver, come DosWrite e DosRead, hanno codici di ritorno e funzionamento standard. Il driver può ignorare una o tutte le richieste restituendo uno stato Done al kernel: ciò dice al kernel che la richiesta è stata completata. Lo stato restituito al kernel può includere anche informazioni sugli errori, che il kernel restituisce quindi al chiamante. Notate che in caso di funzionamento standard, il kernel mapperà il valore di errore restituito dal driver in uno dei codici di ritorno standard. Pertanto, è impossibile passare un codice speciale di ritorno all applicazione tramite una richiesta standard al driver. Se tenterete di farlo, il kernel intercetterà il codice di ritorno speciale e lo mapperà a un codice standard. Il solo modo di restituire un codice speciale all applicazione è l uso di una richiesta IOCtl. Gli IOCtl sono usati per operazioni speciali del driver (I/O di porta, per esempio). Gli IOCtrl vengono accessati quando l applicazione lancia una chiamata a DosDevIOCtl con l handle del dispositivo. Questa flessibilità consente al programmatore di personalizzare il driver per ogni dispositivo. Per esempio, avendo un driver seriale che controlla il traffico e riporta l occorrenza di caratteri speciali, si può usare una lettura IOCtl e passare il carattere nel codice di ritorno. Nel listato 5 è presentato lo scheletro di una sezione Strategy. Notate lo switch sul comando request packet. Parecchie funzioni standard dei driver hanno codici di comando predefiniti in OS/2. Il programmatore può agire sulle richieste o ignorarle a piacimento. Nonostante non abbia senso, il driver potrebbe ignorare il comando Open lanciato dal kernel in risposta a una chiamata a DosOpen. 9

10 O, più logicamente, il driver può rifiutare la richiesta di de-installazione lanciata tramite una Deinstall. La chiamata a INIT viene fatta una sola volta, durante il caricamento del sistema operato dalla linea DEVICE = in CONFIG.SYS. La chiamata viene fatta in modo INIT da ring 3, con privilegi di I/O. La routine INIT è il punto in cui si inserisce il codice per inizializzare il dispositivo, come la configurazione della UART oppure l invio del disco alla traccia 0. La primissima cosa da fare nell inizializzazione è salvare l indirizzo dell entry point DevHlp nel segmento dati del driver. Questo è l unico momento in cui l indirizzo è valido. Esso va salvato, o verrà perso irrimediabilmente. L indirizzo dell entry point DevHlp viene passato nel request packet INIT. Il codice di inizializzazione fa altre due cose. Innanzitutto, manda su schermo il messaggio di tentato caricamento del driver. Quindi, trova l indirizzo del segmento dell ultimo elemento codice e dell ultimo elemento dati, e li rinvia a OS/2. Questi usa i valori ricevuti per dimensionare la memoria. Se un driver non completa l installazione, deve rimandare indietro i valori 0 per CS e DS, in modo che OS/2 possa riutilizzare lo spazio lasciato. Una delle tecniche più comuni nella realizzazione di driver per OS/2 è che la sezione Strategy richieda servizi dal dispositivo e aspetti che un interrupt (device o timer) segnali il completamento della richiesta. Il frammento del listato 6 mostra un implementazione dello schema per la funzione Read del mio driver di comunicazione seriale d esempio. In tal caso, la sezione Strategy inizia l I/O e lancia una chiamata alla DevHlp Block, che blocca il thread chiamante. Quando il dispositivo segnala il completamento dell operazione tramite interrupt, la sezione lancia il thread bloccato e completa così la richiesta. Per proteggersi dal rischio di richieste mai completate (dispositivo spento, per es.), la chiamata a Block può contenere un parametro di timeout: se il tempo prima dell interrupt di completamento supera il valore limite, la sezione Strategy può mandare l errore corretto al kernel. Un altro modo per dare un timeout al dispositivo è usare la routine SetTimer delle DevHlp. Si può attaccare un gestore di timer all orologio di sistema di OS/2 e lasciare che il gestore lanci il thread bloccato dopo un numero di tick specificato. I comandi consentiti dalla sezione Strategy sono lasciati al programmatore. Si possono elaborare solo i comandi che si desidera elaborare, lasciando semplicemente passare gli altri inviando uno stato Done al kernel. Altrimenti si possono intrappolare le chiamate illecite restituendo al kernel un errore ERROR_BAD_COMMAND. Tenete a mente, peraltro, che il kernel lancia spesso i suoi comandi al driver, a vostra insaputa. Per esempio, quando l utente di un applicazione che aveva aperto un driver preme Ctrl-C, il kernel controlla l elenco dei driver aperti dall applicazione e manda una richiesta Close a tutti. In generale, ho notato che è più semplice ignorare tutte le richieste che non si attendono e marcarle come eseguite. Nel driver più semplice, la sezione Strategy può contenere le sole richieste Open, Close e Read o Write. In un driver complesso come quelli per unità a disco, la sezione Strategy può contenere oltre due dozzine di funzioni standard e parecchie chiamate IOCtl addizionali. Queste sono effettivamente funzioni Strategy, ma sono ulteriormente suddivise per permettere operazioni specialistiche del dispositivo o maggiormente dettagliate. Per esempio, un driver potrebbe inviare un elenco di parametri a una porta di I/O per inizializzarla, e restituire il valore d ingresso di una porta di stato con lo stato dell inizializzazione. 10

11 Un campione delle funzioni standard del driver INIT (codice 0x00). Questa funzione viene chiamata dal kernel all inizializzazione del driver, al momento dell avvio del sistema. La sezione INIT deve inizializzare il dispositivo, come per esempio impostare il baud rate, la parità e altro per quanto riguarda una porta seriale, oppure controllare che il dispositivo sia installato, lanciando una richiesta di stato al controller. La funzione INIT viene chiamata in una modalità speciale del livello 3, con alcune funzioni del livello 0. Il driver potrà disattivare gli interrupt, che però vanno ripristinati prima di rientrare al kernel. Il codice di INIT può effettuare I/O diretto sulle porte senza violazione di protezione. Solitamente, il programmatore del driver allocherà buffer e salvataggio dei dati durante l inizializzazione, per accertarsi che il driver funzioni dopo l installazione. Dato che l inizializzazione avviene a livello 3, il sistema può controllare per assicurarsi che il buffer e l allocazione di memoria siano validi e che i segmenti siano di proprietà del driver. In caso contrario il driver può rimuoversi dalla memoria, liberando tutto lo spazio precedentemente allocato per altri componenti di sistema. Dato che l inizializzazione avviene una sola volta all avvio, non è indispensabile ottimizzarla. Fate qui tutte le inizializzazioni necessarie, dato che potrebbe essere proibitivo o addirittura impossibile farle durante l uso del driver. Media Check (codice 0x01). La funzione viene chiamata dal kernel prima dell accesso ai dischi, e pertanto è valida solo per dispositivi a blocchi. Il kernel passa al driver il byte del media ID corrispondente al tipo di disco che aspetta di trovare nell unità selezionata. BuildBPB (codice 0x02). Quando il driver di blocco riceve una chiamata Build Bios Parameter Block, deve restituire un puntatore al BPB che descrive l unità di memoria di massa. Read (codice 0x04). L applicazione chiama la sezione Read lanciando l API DosRead con l handle ottenuto tramite DosOpen. La routine Read può restituire un carattere per volta, ma più spesso restituisce un buffer di dati. Come la funzione Read lavori, sta al programmatore deciderlo. Il driver restituisce il conteggio di caratteri letti e salva i dati ricevuti nel segmento dati dell applicazione. Read restituisce un codice di ritorno driver standard. Nondestructive Read (codice 0x05). In risposta a questa richiesta, il driver deve leggere il primo carattere del buffer del driver e restituirlo al chiamante. Se non sono presenti caratteri, il driver ritorna immediatamente con il bit Done e gli opportuni bit d errore impostati. Input Status (codice 0x06). Il driver deve azzerare il bit Busy nel request packet se uno o più caratteri sono nel buffer del driver, o impostato se nessun carattere è presente. Si tratta di una funzione Peek (osserva) per determinare la presenza di dati. Flush Input Buffer(s). Dovrebbe svuotare le code dei ricevitori o i buffer, e restituire uno stato Done al kernel. Write (codice 0x08). Richiesta standard effettuata dall applicazione a seguito di una chiamata all API DosWrite. L applicazione passa al driver l indirizzo dei dati da scrivere (solitamente nel segmento dati dell applicazione) e il numero di caratteri da scrivere. Il driver scrive i dati e restituisce all applicazione lo stato, assieme al numero di caratteri scritti. Write restituisce un codice di ritorno standard da driver. Write with Verify (codice 0x09). Il driver scrive dati come in Write, ma verifica la scrittura. 11

12 Output Status (codice 0x04a). Il driver imposta il bit Busy nel request packet se un operazione è attiva, e lo azzera se l operazione è completata e il trasmettitore è libero. Output Flush (codice 0x0b). Il driver svuota le code di uscita e i buffer, e restituisce lo stato Done al kernel. Device Open (codice 0x0d). Chiamata come risultato della chiamata a DosOpen da parte dell applicazione. Il kernel prende nota della richiesta a DosOpen, e se non vi sono errori manda all applicazione uno handle da usare per i servizi successivi. Il programmatore può usare questa sezione per inizializzare un dispositivo, svuotare i buffer, resettare il puntatore ai buffer, inizializzare le code o qualsiasi cosa sia necessaria per la corretta operatività. Device Close (codice 0x0e). Chiamata come risultato dell API DosClose usata dall applicazione con il corretto handle di dispositivo. È bene assicurarsi che l applicazione che chiude il driver sia la stessa che l ha aperto, quindi salvate il PID dell applicazione che ha aperto il driver e fate in modo che il PID usa in chiusura siano identici. In caso contrario rigettate la richiesta. Dovreste avere tutti i dispositivi in quiescenza, a questo punto. Removable Media (codice 0x0f). Il driver riceve questa richiesta quando un applicazione genera una chiamata a IOCtl categoria 8, funzione 0x20. Invece di chiamare l IOCtl, il kernel lancia la richiesta citata. Il driver deve impostare il bit Busy dello stato del request packet se l unità non è rimovibile, o azzerarlo in caso contrario. Generic IOCtl (codice 0x10). Questa è una chiamata speciale. È molto flessibile, poiché i dati passati al driver vengono salvati in due buffer di proprietà del chiamante. Tali buffer possono contenere qualsiasi tipo di dati; il formato è lasciato al programmatore. Il primo e il secondo parametro di un IOCtl sono l indirizzo del buffer dei dati e dei parametri del programma applicativo, rispettivamente. Il buffer dei parametri potrebbe contenere un elenco di USHORT, UCHAR o puntatori. Il parametro buffer dati potrebbe essere l indirizzo di un buffer per dati nel programma applicativo, dove il driver salverebbe dati provenienti dal dispositivo. Gli IOCtl possono estendere la gamma di informazioni di stato che i driver possono mandare alle applicazioni. Supponete, per esempio, che un driver necessiti di riportare a un applicazione il formato (ASCII o binario) dei dati, o di dover segnalare un errore di parità in ricezione. Un IOCtl potrebbe essere la risposta. Questo perché il kernel modifica i codici di ritorno dalle chiamate a funzioni standard per rientrare nelle definizioni di errore standard. L IOCtl, comunque, passerà i codici direttamente all applicazione, esattamente come sono stati impostati nel driver. In molti driver scritti da me, le sezioni DosRead e DosWrite della sezione Strategy sono commentate e mai utilizzate. Uso gli IOCtl per letture e scritture, per consentire al driver di comunicare con l applicazione senza che il kernel interferisca. PrepareForSysShutdown. La funzione dice al driver di postare tutti i buffer aperti verso i dispositivi comandati, prima della chiusura del sistema. Questo si ha quando si seleziona Chiusura dalla finestra della Scrivania. La sezione Interrupt Quando OS/2 chiama il gestore di interruzioni, lo fa con gli interrupt disabilitati, per cui il tempo passato nel gestore di interruzioni potrebbe causare problemi alle prestazioni. Se viene attivato in risposta alla ricezione di dati, il gestore deve salvare i dati e uscire rapidamente. Per dispositivi a carattere, la libreria DevHlp supporta letture e scritture rapide a code circolari. Per dispositivi a 12

13 blocchi, la gestione degli interrupt è veloce perché l interrupt viene di norma causato dal completamento di un operazione di DMA o di ricerca su disco. I dati quindi vengono, di norma, trasferiti al buffer utente usando il DMA, eliminando il bisogno di trasferire dati durante l elaborazione degli interrupt. Su un trasferimento DMA, il driver può uscire quando il controller DMA inizia, in modo da lanciare altri thread. Al completamento dell operazione, si ha una DMA completion, che attiva il gestore di interrupt del driver. La routine di gestione degli interrupt non è difficile da capire o scrivere, ma può divenire molto difficile correggerla. Un errore in tale sezione spesso compare solo in un contesto in tempo reale, quando il gestore è attivo in risposta a un interrupt hardware. Non si può lanciare printf() dalla routine di interrupt, o ispezionare le variabili con un debugger per applicazioni. Si deve invece usare il Kernel debugger di OS/2 dal DDK, o un debugger simile. Anche usando il KDB, un breakpoint ferma il programma, e ulteriori interrupt potranno passare non rilevati mentre decidete cosa scrivere. A causa di questa pausa nell esecuzione, si perde il contesto di tempo reale del programma, che potrebbe essere la radice del problema. In definitiva, non vi è sostituto dell abilità di visualizzare l operazione corretta del gestore di interruzioni. Il gestore del timer In un driver per OS/2, l interrupt del timer di sistema può essere agganciato tramite una chiamata alla funzione DevHlp SetTimer. Si passa a OS/2 un puntatore NEAR al gestore del timer, e per ogni tick del timer, OS/2 chiama la routine e altri gestori di timer registrati in precedenza. Se non appaiono dati entro uno o due tick da 32 ms, il driver suppone che l ingresso dati si sia fermato o sia in pausa. Se è in attesa una richiesta di lettura, esso invia i dati alla sezione Strategy bloccata lanciando una richiesta Run con lo stesso ID usato per bloccare il thread richiedente. La sezione Strategy viene sbloccata, riceve i dati dalla coda del ricevente, e li invia al buffer dati dell applicazione. Serve davvero un device driver? Forse no. OS/2 1.x consente ai programmi con privilegi di I/O (IOPL) di fare I/O diretto verso un dispositivo. Per una porta parallela, o un interruttore digitale, un driver potrebbe non essere necessario. Si possono impostare o azzerare bit tramite istruzioni IN e OUT, e fintanto che il dispositivo non è critico alle temporizzazioni, il metodo è sufficiente. Peraltro, dispositivi che generano interrupt, richiedono servizio asincrono, oppure operano in ambienti time critical, devono usare i device driver. Considerate come esempio una porta seriale. Sarebbe difficile, se non impossibile, leggere dati dal dispositivo tramite IOPL. Per definizione infatti i dati asincroni possono arrivare in qualsiasi momento. Dato che OS/2 potrebbe star facendo girare un altro thread al momento, le probabilità di perdere dati sono molto elevate. Un driver a interrupt potrebbe invece leggere e bufferizzare i dati in arrivo fino a che lo scheduler di OS/2 non lanciasse il thread che legge i dati. Opzionalmente, si può fare in modo che gli interrupt fermino il thread in esecuzione e lancino il vostro immediatamente. Non è necessario attendere lo scheduler. Questo tipo di multitasking prelazionale è unico in OS/2 rispetto a sistemi come Unix. In Unix il programma in esecuzione attualmente mantiene il controllo della CPU fino a esaurire il suo time slice. Ecco perché OS/2 è la scelta obbligata per le applicazioni time critical. 13

14 Compagnie citate: FutureWare, Inc. 78 Temple Ave., Suite 15 Hackensack, NJ (201) Microsoft Corp. One Microsoft Way Redmond, WA (800) OS Technologies 532 Longley Rd. Groton, MA (508) PentaSoft Stone Ave. N Seattle, WA (206) PSS Corp. 290 Brookfield St. South Windsor, CT (203) Finalmente, arrivano gli strumenti di programmazione per OS/2 2.0 Numerosi strumenti di sviluppo per OS/2 2.0 cominciano finalmente ad apparire. Ora che IBM ha rilasciato OS/2 2.0, iniziano a comparire anche gli strumenti di sviluppo. La versione a 32 bit di OS/2 riesce a far girare pressoché qualsiasi programma disponibile per DOS, Windows e OS/2. A parte alcuni bug nell installazione, OS/2 2.0 funziona bene. È facile e veloce da usare, e offre un ampia gamma di opzioni di configurazione prima d ora mai supportate. Meglio che mai, gli sviluppatori hanno a disposizione gli strumenti che servono. Versioni beta L IBM ha capito presto che doveva fornire strumenti di sviluppo adatti a OS/ Prima erano disponibili solo strumenti a 16 bit, e il solo compilatore di IBM, il C/2, si basava su una versione obsoleta del compilatore Microsoft C. Durante lo sviluppo del compilatore IBM C, sono state rilasciate alcune versioni beta, insieme a un ambiente di sviluppo e debug chiamato WorkFrame/2. Per gli sviluppatori professionisti, il programma beta di OS/2 2.0 fu un incubo. I rilasci del toolkit erano in ritardo rispetto al sistema, per cui sviluppare software con l ultima beta degli strumenti significava usare una versione vecchia del sistema. La documentazione dei toolkit beta era piena di errori e omissioni, e alcuni manuali avevano riferimenti a funzioni obsolete di OS/2 1.x. L IBM batteva il tamburo dei 32 bit, ma non era in grado di dare agli sviluppatori versioni tempestive degli strumenti necessari a realizzare le nuove applicazioni a 32 bit. 14

15 IBM informò tutti tramite mailing list e le conferenze di Compuserve OS2DEV e IBMOS2. La compagnia non tentò di mascherare o nascondere problemi delle versioni beta e non richiese accordi di riservatezza per ottenere il codice. Fu un cambio rivitalizzante, molto utile per ristabilire la credibilità di IBM presso gli sviluppatori. I primi passi Pochi mesi dopo la versione GA di OS/2 2.0, IBM iniziò a distribuire la versione 1.0 del compilatore C a 32 bit IBM CSet/2, come parte dello IBM C Developer s WorkSet/2. In tale ambiente erano inclusi il Presentation Manager Debugger IPMD, WorkFrame/2, il kernel debugger, DLL di esempio, il programma PMSpy, il compilatore delle risorse, i file include, strumenti per la migrazione e molti esempi di codice ben scritti. WorkFrame/2 è un ambiente plug-in che permette di specificare il compilatore, l assembler, il debugger e il linker da usare. Permette di impostare le opzioni di compilazione, link e debug a qualsiasi valore si voglia. Può generare makefile e librerie, ed è configurabile tramite una semplice finestra. WorkFrame/2 funziona gestendo progetti, piuttosto che file e directory. Un progetto viene creato inserendone i parametri nella finestra Project Control. Qui vanno informazioni come nome e descrizione del progetto, nome dei makefile, e opzioni di compilazione/link/lancio. Inserite le informazioni sul progetto, si può realizzare una nuova versione del codice cliccando sul bottone new nella finestra Project Control. CSet/2 è un compilatore ottimizzante completamente conforme alle specifiche ANSI 1989, che genera codice a 32 bit per OS/ Il compilatore supporta la coesistenza 32 bit 16 bit a tempo di esecuzione, librerie statiche e dinamiche, HPFS e I/O mappato in memoria. Fornisce supporto alla migrazione per convertire programmi da OS/2 1.x a OS/2 2.0, e produce codice veloce, leggero e consistente. Non è possibile usarlo per realizzare device driver fisici o virtuali, ma è perfetto per le applicazioni a 32 bit. IPMD rende elementare il debug di applicazioni a 32 bit. Peraltro, il prezzo iniziale di 895 dollari del WorkSet/2 irritò molto gli sviluppatori, che costrinsero IBM a ridurre il prezzo a 295 dollari fino al primo settembre. Al momento del comunicato stampa non è chiaro se IBM intenda estendere tale politica. Supporto del ISV locale IBM ha anche cominciato a supportare meglio i venditori di software indipendenti (ISV), critici per il successo di OS/ Il personale di supporto tecnico di IBM è apparso su tutte le maggiori BBS e sistemi di conferenza, inclusi Compuserve, BIX, usenet e fidonet. Molti altri programmi di supporto a OS/2 sono attivi. Il Developer Assistance Program aiuta gli sviluppatori commerciali. IBM ha aperto una linea verde per materiale software e di supporto per OS/2, e la IBM I. V. League supporta autori ed editori. L IBM sponsorizza molte conferenze sugli strumenti per OS/2 2.0, in cui gli sviluppatori possono avere le informazioni più aggiornate su OS/2 2.0 e sugli strumenti di sviluppo associati, e workshop di migrazione a OS/2, in cui gli sviluppatori possono ottenere assistenza tecnica nella conversione delle loro applicazioni in OS/ In arrivo Alcuni rivenditori hanno cominciato a sviluppare strumenti per OS/2 prima dell uscita della GA. Altri, notando l enorme risposta all uscita di OS/2 2.0, hanno annunciato prodotti o piani di rilascio per OS/2 2.0 nell ultima parte dell anno. Le offerte attuali includono linguaggi, applicazioni CASE, debugger e altro. 15

16 Nel campo dei linguaggi, Borland International, Clarion Software, MicroWay, Symantec e Watcom hanno annunciato la realizzazione di compilatori C e C++. Watcom ha un compilatore FORTRAN a 32 bit, e Clarion ha annunciato le versioni per OS/2 2.0 dei suoi compilatori Pascal e Modula-2. IBM apparentemente sta lavorando a un suo compilatore C++, mentre Arity vende un compilatore Prolog a 32 bit per OS/ Digitalk ha rilasciato una versione OS/2 2.0 del suo Smalltalk/V PM. Micro Focus e Liant Software hanno annunciato compilatori COBOL per OS/ Caseworks, The Stirling Group, Guild Products, Guidance Technologies, Gpf Systems, VZ, Vleermuis Software Research, Software Engineering International, Enfin Software, ImageSoft, ed Intelligent Environments hanno annunciato nuovi tool CASE per OS/2 2.0 in PM. Se intendete migrare applicazioni Windows in OS/2, cercate il Software Migration Kit di Micrografx. Difficilmente vi serviranno altri strumenti di debugging al di là di quelli offerti da IBM. Comunque, potreste considerare l uso di Periscope debugger e di Soft & GUI s Error Manager. SourceLine software vende un browser ipertestuale per codice sorgente per OS/ Personal Systems Software vende un toolkit chiamabile dal C per scrivere device driver in OS/ Intersolv ha annunciato versioni per OS/2 2.0 di PVCS, PolyMake, PolyAwk e del Sage Professional Editor. Hamilton Laboratories ha una versione a 32 bit della sua C shell. GammaTech ha una versione a 32 bit delle utilità HPFS, e Parallel PC s sta vendendo una versione per OS/2 2.0 del Synetics SDK. Per chi ha meno denaro a disposizione, per OS/2 2.0 sono disponibili molti strumenti di pubblico dominio e shareware di buona qualità. Il compilatore GNU C/C++ per OS/2 2.0 è disponibile su BIX, CompuServe e su altre BBS. È possibile scaricare anche molte utilità GNU (rcs, make, awk, grep e altri) e GNU emacs. La parola scritta IBM ha annunciato la OS/2 Technical Library, un insieme di manuali per sviluppatori OS/2 al prezzo di 295 dollari. I manuali sono indispensabili per chiunque programmi in OS/2. Uno sguardo approfondito ai dettagli tecnici di OS/2 si può dare in The Design of OS/2, di H. M. Deitel ed M. S. Kogan, pubblicato da Addison-Wesley (ISBN ). Van Nostrand Reinhold ha pubblicato molti nuovi libri, inclusi Client-Server Programming with OS/2 2.0 di Robert Orfali e Daniel Harkey (ISBN ), Writing OS/2 2.0 Device Drivers in C di Steve Mastrianni (ISBN ), e OS/2 Presentation Manager GPI di Graham Winn (ISBN ). Van Nostrand offre inoltre una raccolta di sei libri a prezzo speciale. Il tempo è giusto L interesse in OS/2 2.0 sta crescendo a grandi passi. Anche i suoi oppositori più decisi sono rimasti impressionati dalle sue capacità. I fan del vecchio OS/2 1.x sono sempre qui, e sono stati raggiunti da un gruppo di utenti e sviluppatori anche più ampio, e desideroso di toccare il supporto multitask e multipiattaforma di OS/ La politica di prezzi aggressiva di IBM ha suggerito a molti utenti Windows di aggiornarsi e passare a OS/2 2.0 a soli $: gli utenti DOS possono fare l aggiornamento a 99 $. L interesse in OS/2 2.0 è provato anche dai molti messaggi nelle conferenze elettroniche pubbliche. I tool per sviluppare il nuovo software a 32 bit per OS/2 sono arrivati? Farete meglio a crederci. È ora di sviluppare. Certamente vorrete mantenere alcune delle vostre applicazioni DOS e Windows, ma non potete ottenere la piena potenza di OS/2 senza le applicazioni specifiche a 32 bit. Al crescere delle richieste degli utenti di PC, la potenza e la flessibilità di OS/2 diverranno sempre più richieste e apprezzate. La possibilità di scaricare un file da linea telefonica mentre si aggiorna un 16

17 database, si stampano molti file e si modifica un documento dovrebbe convincere anche l utente più scettico del fatto che OS/2 2.0 rappresenta la miglior soluzione per le applicazioni software. Informazioni sulle compagnie: Arity Corp. (Prolog/32) (508) Borland International, Inc. (C++ for OS/2 2.0) (408) Caseworks, Inc. (CASE:PM 2.2, CASE:PM VIP (CUA 91)) (404) Clarion Software, Inc. (TopSpeed C, C++, Modula-2, Pascal) (305) Digitalk, Inc. (Smalltalk/V PM) (310) Enfin Software Corp. (Enfin/2) (619) GammaTech (GammaTech Utilities) (405) Gpf Systems, Inc. (Gpf 2.0) (203) Guidance Technologies, Inc. (Choreographer) (412) Guild Products, Inc. (Guild) (415) Hamilton Laboratories (C shell) (508) ImageSoft, Inc. (CommonView) (516) Intelligent Environments, Inc. (AM (Applications Manager)) (508) Intersolv (PVCS, PolyMake, PolyAwk) (503) Liant Software Corp. (RM/COBOL-85) (512) Micro Focus, Inc. (Micro Focus/2 COBOL) (415) Micrografx, Inc. (Software Migration Kit) (214) MicroWay, Inc. (NDP FORTRAN 386/486, C-C++ NDP 386/486) (508) Parallel PC's (Synectics SDK) (215) The Periscope Co., Inc. (Periscope/32) (404) Personal Systems Software, Inc. (C-Callable DevHlp Driver Library) (203) Soft & GUI, Inc. (Error Manager) (718) Software Engineering International (Primary Window Class) (407)

18 SourceLine Software (SourceLink) (619) The Stirling Group (TbxShield, InstallShield) (708) Vleermuis Software Research (GUI Master) fax: VZ Corp. (VZ Programmer) (801) Watcom (C 9.0/386, FORTRAN 77/ ) (519) Confessioni di uno sviluppatore DDK Il DDK di OS/2 non fa molta strada, ma è un inizio In un freddo pomeriggio di febbraio, dopo lunga attesa, ricevetti una lettera dall IBM che annunciava il DDK della versione 2.0 di OS/2. Firmai immediatamente e rispedii il modulo di risposta con un check di 15 $, e meno di una settimana dopo giocherellavo con l OS/2 DDK. Avevo sentito parlare del pacchetto per mesi. L IBM aveva continuato a promettere di distribuirlo, ma molti ritardi trascinarono le cose e la ditta fu costretta a chiedere agli sviluppatori di pazientare. Fonti vicine a IBM dicevano che il problema non era dal punto di vista del codice: invece, nessuno aveva la responsabilità di mettere assieme il codice e realizzare il DDK. Si parlò anche di problemi legali con Microsoft. Alla fine, i problemi vennero risolti. Un inizio dubbioso Il DDK era contenuto in un CD-ROM, con i driver per Win-OS2 su due floppy disk. Ansioso di capire cosa occupasse tutto quello spazio, iniziai a installarlo immediatamente su una macchina con installata la beta 2.1 di dicembre. L installazione chiedeva 50 MiB di spazio su disco. Avendone 52 liberi, pensai che andava tutto bene. Sbagliato. Circa al 95% dell installazione, ottenni un errore di protezione generico e il temuto messaggio The system is stopped. A giudicare dall indirizzo dell errore, pareva trattarsi di un device driver, e le mie peggiori paure si realizzarono notando che le prime tracce del disco erano state riscritte. Il disco non era più avviabile: la FAT era andata, insieme ai miei dati. Fortunatamente, si trattava di un sistema privo di informazioni sensibili. Successivamente scoprii che si trattava di un bug della versione beta 2.1: il codice dei device driver, come seppi dopo, richiede 54 MiB di spazio libero. Riformattato l hard disk, reinstallai il DOS e il codice beta della 2.1. Reinstallai poi anche la maggior parte del software, facendo in modo da lasciare circa 100 MiB di spazio libero. L installazione andò a termine perfettamente, piazzando moltissimo codice sorgente sul disco. Tutti i driver vennero installati: stampante, SCSI, display, driver virtuali e fisici. Il programma di installazione permette di selezionare i driver da installare: aiuta a conservare spazio su disco, ma trovare un driver particolare è un lavoro noioso. Cosa c è Il DDK include il Microsoft CL386, un compilatore a 32 bit precedentemente assente, utilizzato per creare il codice a 32 bit di OS/ L IBM ha usato CL386 anche per costruire tutti i VDD di OS/2 2.x. Nel pacchetto è inclusa anche una versione del MASM 5.1, pur se alcuni esempi richiedono la versione 6.0. Questo mi ha disturbato: perché gli esempi non potevano richiedere un solo ambiente? 18

19 Anzi: perché in IBM si sviluppa per OS/2 con diversi compilatori e assemblatori? Gli sviluppatori, così, sono costretti a usare il Microsoft C 5.1 e 6.0, CL386, il CSet/2 di IBM, e MASM 5.1 e 6.0. In sua difesa l IBM asserisce che intende correggere il problema in versioni successive del DDK. Inoltre, nel DDK sono inclusi diversi strumenti, tra cui un programma che permette di cambiare rapidamente gli attributi estesi, un programma per visualizzare la palette hardware, un programma per controllare la stampante, TOUCH, SED, MAPSYM, LIB e il compilatore delle risorse RCPP. Il DDK include in effetti dozzine di driver. Tra i driver di schermo, nel DDK sono compresi un driver VGA a 16 bit, un driver 8514/A a 16 bit, un driver VGA a 32 bit, un driver Super VGA a 32 bit, e un driver indipendente dal dispositivo a 32 bit. Sono incluse anche le controparti virtuali. I gestori base per VGA, 8514/A, CGA, EGA e XGA sono in cima alla lista dei driver. I floppy disk contengono invece il codice sorgente di due driver video seamless basati su driver per Windows, versioni 3.0 e 3.1. Quanto alle stampanti, IBM fornisce solo due driver: un driver PostScript e un driver per plotter, che pare essere codice OS/ La cosa ha senso, dato che IBM continua a supportare tali driver su OS/ Il driver postscript va compilato con CL386. Il DDK inoltre include il codice sorgente del driver per floppy, per ASPI (Advanced SCSI Programming Interface), IDE, SCSI PS/2, floppy PS/2, e DASD PS/2. Per i driver per CD-ROM esistono i codici sorgente dei driver Hitachi, Toshiba, NEC e Sony SCSI, oltre al CD-ROM Device Manager. Sono inclusi anche i driver per mouse Mouse Systems, PC Mouse / Logitech, e VisiOn, anche se manca un driver virtuale. A caccia La prima sezione che ho esaminato è stata quella dei PDD, i miei driver preferiti. Sono da tempo un fautore della scrittura di driver in C. Dispongo di una libreria di funzioni in C che permette a un driver scritto in C di chiamare i device helper per OS/2 basati su registri, ed ero curioso di conoscere l offerta di IBM. Nel CD sono inclusi una libreria con codice sorgente e make file, ma assolutamente nessuna documentazione. Se siete bravi programmatori MASM probabilmente riuscirete a comprendere il senso del codice assembly più-complesso-del-necessario e le macro, e il modo per chiamare le funzioni leggendo il file include assembly, posto che ne abbiate il tempo. Inoltre la libreria contiene molte chiamate a device helper non documentati. La libreria necessita di documentazione, e che tale documentazione sia posta sul CD-ROM. Se le chiamate a funzione non sono supportate, l IBM farebbe bene a tenerne nota, in modo che gli sviluppatori non le usino nel codice di produzione: nondimeno, le chiamate dovrebbero essere documentate. Sono stato contento di vedere molto codice C. Dato che la maggior parte delle operazioni è veloce, non ha quasi senso scriverle in assembly. I driver in C possono essere scritti in metà del tempo richiesto per usare MASM, e sono più facili da correggere e supportare. Non ho trovato il riferimento ai PDD, la bibbia degli scrittori di PDD. Né ho trovato i riferimenti ai driver di presentazione e ai VDD. La cosa che confonde, di queste omissioni, è che IBM ha già rilasciato tale documentazione nel Professional Developer s Kit: non tutti i programmatori di driver, peraltro, hanno bisogno del PDK, per cui praticamente vengono lasciati senza documentazione. IBM intende produrre tale documentazione nelle versioni successive del DDK. 19

20 Cercare un senso nel DDK navigando attraverso oltre 50 MiB di codice è decisamente noioso. Il CD-ROM dovrebbe includere le informazioni di navigazione necessarie in formato INF. Mi piacerebbe anche avere il manuale di riferimento al Control Program, dato che la maggior parte delle chiamate ai device driver viene fatta da queste API. Nel provare i miei driver, mi riferisco sempre a tale guida, dato che trovo impossibile ricordare tutti i parametri e il loro ordine. È notevole, inoltre, l assenza di un esempio di driver di filesystem. Le informazioni sugli IFS di OS/2 sono parziali e possono essere ottenute solo con un permesso speciale. Un breve scheletro di IFS è ottenibile tramite CompuServe, ma l IBM deve fare un lavoro migliore sugli IFS fornendo codice di esempio e documentazione come parte standard del DDK. Non esiste alcuna scusa per non fornire il codice. Altri miglioramenti Il DDK è un buon punto di partenza, ma è molto difficile usarlo senza buona documentazione. Dato che IBM ha promesso di rilasciarne aggiornamenti regolarmente, dovrebbe avere il tempo di migliorare il prodotto. Molti esempi contengono centinaia di linee di codice senza documentazione, e alcuni non dicono nemmeno quel che fa l esempio. IBM deve fornire maggiore documentazione per permettere agli sviluppatori di capire cosa c è sul CD e come trovarlo. Nessuno ha tempo di navigare un intero CD cercando qualcosa che potrebbe anche non esserci. Sarebbe bene inserire un debugger come ASDT32. Il DDK manca anche di esempi su driver a carattere, come driver per porta seriale o parallela, driver di acquisizione dati o memory mapped. Questi altri driver riguardano più di metà dei dispositivi che richiederanno driver per OS/2. Il DDK dovrebbe anche includere un tutorial per scrivere device driver con codice di esempio. Tutti questi documenti, inclusa la guida di riferimento ai device driver, dovrebbero essere presenti in diversi formati (INF, Read/2, ASCII e PostScript). IBM deve fare un lavoro migliore nel supporto ai programmatori di device driver, specie per il fatto che questo è il tradizionale tallone d Achille di OS/2. Attualmente IBM ha attiva una piccola BBS in cui i programmatori possono fare domande e scaricare codice di esempio. Si tratta però di un sistema single user, che manca della capacità di thread di messaggi, come si vede in CompuServe o BIX. Periodicamente, domande e risposte vengono fuse in un file scaricabile, ma la cosa non ha la comodità di un thread di messaggi su CompuServe. L IBM ha annunciato che CompuServe è il forum ufficiale di supporto pubblico a OS/2 2.x. Quindi, IBM dovrebbe supportare i device driver nel forum lì presente, dove un uditorio di sviluppatori molto più ampio potrà beneficiare del traffico di messaggi. Una sveglia? Pare che IBM abbia recepito il messaggio. È stato creato un gruppo speciale interno alla compagnia, per promuovere i device driver in OS/2 pubblicamente e internamente. Il DDK è diventato un prodotto, con un manager assegnato. IBM ha pianificato rilasci trimestrali del DDK, di cui ogni versione dovrebbe migliorare. I rilasci futuri includeranno driver e strumenti per: pen computing, multimedia, XGA, 8514/A, SCSI, mouse, tastiere, IFS, porte seriali e parallele, schermi sensibili al tatto e PCMCIA, oltre a un ampia scelta di strumenti e documentazione online. Questo mese, IBM terrà una conferenza di tre giorni sul DDK di OS/2. Gli sviluppatori di driver dei laboratori di Boca Raton saranno presenti per conversare e incontrarsi con gli sviluppatori. Probabilmente il rilascio del DDK e la conferenza segneranno un punto di svolta per lo sviluppo di device driver per OS/2. 20

Corso di Sistemi di Elaborazione delle informazioni

Corso di Sistemi di Elaborazione delle informazioni Corso di Sistemi di Elaborazione delle informazioni Sistemi Operativi a.a. 2010/2011 Francesco Fontanella Il Sistema Operativo Sistema Operativo 2 Il Sistema Operativo Il Sistema Operativo è uno strato

Dettagli

Struttura di un sistema operativo. Struttura dei Sistemi Operativi. Servizi per l utente generico. Servizi per l utente generico

Struttura di un sistema operativo. Struttura dei Sistemi Operativi. Servizi per l utente generico. Servizi per l utente generico Impossibile visualizzare l'immagine. Struttura di un sistema operativo Struttura dei Sistemi Operativi Servizi di un sistema operativo Interfaccia Utente Capitolo 2 -- Silberschatz Chiamate di sistema

Dettagli

Capitolo 2 -- Silberschatz

Capitolo 2 -- Silberschatz Struttura dei Sistemi Operativi Capitolo 2 -- Silberschatz Struttura di un sistema operativo Servizi di un sistema operativo Interfaccia Utente Chiamate di sistema Tipi di chiamate Programma di sistema

Dettagli

SISTEMI OPERATIVI. Realizzazione del file system. Prof. Luca Gherardi Prof.ssa Patrizia Scandurra (anni precedenti) (MODULO DI INFORMATICA II)

SISTEMI OPERATIVI. Realizzazione del file system. Prof. Luca Gherardi Prof.ssa Patrizia Scandurra (anni precedenti) (MODULO DI INFORMATICA II) SISTEMI OPERATIVI (MODULO DI INFORMATICA II) Realizzazione del file system Prof. Luca Gherardi Prof.ssa Patrizia Scandurra (anni precedenti) Università degli Studi di Bergamo a.a. 2012-13 Sommario Realizzazione

Dettagli

Elementi di Informatica e Programmazione

Elementi di Informatica e Programmazione Elementi di Informatica e Programmazione Il Sistema Operativo Corsi di Laurea in: Ingegneria Civile Ingegneria per l Ambiente e il Territorio Università degli Studi di Brescia Docente: Daniela Fogli Cos

Dettagli

Abilità Informatiche A.A. 2010/2011 Lezione 4: SoftWare. Facoltà di Lingue e Letterature Straniere

Abilità Informatiche A.A. 2010/2011 Lezione 4: SoftWare. Facoltà di Lingue e Letterature Straniere Abilità Informatiche A.A. 2010/2011 Lezione 4: SoftWare Facoltà di Lingue e Letterature Straniere Software È un insieme di programmi che permettono di trasformare un insieme di circuiti elettronici (=

Dettagli

Il Sistema Operativo. Funzionalità. Sistema operativo. Sistema Operativo (Software di base)

Il Sistema Operativo. Funzionalità. Sistema operativo. Sistema Operativo (Software di base) Sistema Operativo (Software di base) Il Sistema Operativo Il sistema operativo è un insieme di programmi che opera sul livello macchina e offre funzionalità di alto livello Es.organizzazione dei dati attraverso

Dettagli

Sistema Operativo Compilatore

Sistema Operativo Compilatore MASTER Information Technology Excellence Road (I.T.E.R.) Sistema Operativo Compilatore Maurizio Palesi Salvatore Serrano Master ITER Informatica di Base Maurizio Palesi, Salvatore Serrano 1 Il Sistema

Dettagli

Il supporto al Sistema Operativo

Il supporto al Sistema Operativo Il supporto al Sistema Operativo Obiettivi e funzioni del S.O. Il Sistema Operativo è il software che controlla l esecuzione dei programmi e amministra le risorse del sistema. Ha due obiettivi principali:

Dettagli

Sistemi Operativi. Organizzazione logica ed implementazione di un File System

Sistemi Operativi. Organizzazione logica ed implementazione di un File System Modulo di Sistemi Operativi per il corso di Master RISS: Ricerca e Innovazione nelle Scienze della Salute Unisa, 17-26 Luglio 2012 Sistemi Operativi Organizzazione logica ed implementazione di un File

Dettagli

Strutture dei Sistemi Operativi

Strutture dei Sistemi Operativi Strutture dei Sistemi Operativi Componenti di sistema Servizi del sistema operativo Chiamate di sistema Programmi di sistema Struttura del sistema Macchine virtuali Progetto e implementazione di sistemi

Dettagli

Sistemi Operativi (modulo di Informatica II) Sottosistema di I/O

Sistemi Operativi (modulo di Informatica II) Sottosistema di I/O Sistemi Operativi (modulo di Informatica II) Sottosistema di I/O Patrizia Scandurra Università degli Studi di Bergamo a.a. 2009-10 Sommario L hardware di I/O Struttura Interazione tra computer e controllori

Dettagli

Sistemi Operativi. Funzioni e strategie di progettazione: dai kernel monolitici alle macchine virtuali

Sistemi Operativi. Funzioni e strategie di progettazione: dai kernel monolitici alle macchine virtuali Modulo di Sistemi Operativi per il corso di Master RISS: Ricerca e Innovazione nelle Scienze della Salute Unisa, 17-26 Luglio 2012 Sistemi Operativi Funzioni e strategie di progettazione: dai kernel monolitici

Dettagli

Software Applicativo. Hardware. Sistema Operativo Software di Base Traduttori e Linguaggi

Software Applicativo. Hardware. Sistema Operativo Software di Base Traduttori e Linguaggi : di base e applicativo L HardWare (monitor, tastiera, circuiti, stampante, ) è il nucleo fondamentale del calcolatore ma da solo non serve a nulla. Bisogna utilizzare il software per poterlo fare funzionare.

Dettagli

Calcolo numerico e programmazione. Sistemi operativi

Calcolo numerico e programmazione. Sistemi operativi Calcolo numerico e programmazione Sistemi operativi Tullio Facchinetti 25 maggio 2012 13:47 http://robot.unipv.it/toolleeo Sistemi operativi insieme di programmi che rendono

Dettagli

Il sistema di I/O. Hardware di I/O Interfacce di I/O Software di I/O. Introduzione

Il sistema di I/O. Hardware di I/O Interfacce di I/O Software di I/O. Introduzione Il sistema di I/O Hardware di I/O Interfacce di I/O Software di I/O Introduzione 1 Sotto-sistema di I/O Insieme di metodi per controllare i dispositivi di I/O Obiettivo: Fornire ai processi utente un interfaccia

Dettagli

Architettura di un sistema di calcolo

Architettura di un sistema di calcolo Richiami sulla struttura dei sistemi di calcolo Gestione delle Interruzioni Gestione della comunicazione fra processore e dispositivi periferici Gerarchia di memoria Protezione. 2.1 Architettura di un

Dettagli

Fondamenti di Informatica: Sistemi Operativi 1. Introduzione

Fondamenti di Informatica: Sistemi Operativi 1. Introduzione Introduzione Fondamenti di Informatica: Sistemi Operativi 1 Elaboratori necessitano di SOFTWARE SOFTWARE DI SISTEMA (SISTEMI OPERATIVI): fanno funzionare le varie componenti del computer e permettono all

Dettagli

uomo Software (sistema operativo) hardware

uomo Software (sistema operativo) hardware uomo Software (sistema operativo) hardware 1 Sistema operativo Insieme di programmi che svolgono funzioni essenziali per l uso del sistema di elaborazione Questi programmi sono i primi ad essere eseguiti

Dettagli

STRUTTURE DEI SISTEMI DI CALCOLO

STRUTTURE DEI SISTEMI DI CALCOLO STRUTTURE DEI SISTEMI DI CALCOLO 2.1 Strutture dei sistemi di calcolo Funzionamento Struttura dell I/O Struttura della memoria Gerarchia delle memorie Protezione Hardware Architettura di un generico sistema

Dettagli

Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2013-14. Pietro Frasca.

Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2013-14. Pietro Frasca. Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2013-14 Pietro Frasca Lezione 3 Martedì 15-10-2013 1 Struttura ed organizzazione software dei sistemi

Dettagli

Implementazione del File System

Implementazione del File System Implementazione del file system Implementazione del File System Struttura del file system. Realizzazione del file system. Implementazione delle directory. Metodi di allocazione. Gestione dello spazio libero.

Dettagli

Gianluigi Magnasco easitec S.r.l. Parma, 16 Settembre 2010

Gianluigi Magnasco easitec S.r.l. Parma, 16 Settembre 2010 Soft Control facile con RTX e Windows Embedded Standard 7 RTX 2009: funzionalità ed uso pratico Gianluigi Magnasco easitec S.r.l. Parma, 16 Settembre 2010 Definizione di Sistema Tempo Reale: Definizione

Dettagli

Introduzione all Informatica

Introduzione all Informatica Lezione 3 Davide Di Ruscio Alfonso Pierantonio Dipartimento di Informatica Università degli Studi dell Aquila Università degli Studi dell Aquila alfonso@di.univaq.it diruscio@di.univaq.it. Sommario 2 2»

Dettagli

Lezione 11. Sistemi operativi. Marco Cesati System Programming Research Group Università degli Studi di Roma Tor Vergata.

Lezione 11. Sistemi operativi. Marco Cesati System Programming Research Group Università degli Studi di Roma Tor Vergata. Lezione 11 system Sistemi operativi 12 maggio 2015 System Programming Research Group Università degli Studi di Roma Tor Vergata SO 15 11.1 Di cosa parliamo in questa lezione? L interfaccia : system 1 Il

Dettagli

Sistemi Operativi IMPLEMENTAZIONE DEL FILE SYSTEM. Implementazione del File System. Struttura del File System. Implementazione

Sistemi Operativi IMPLEMENTAZIONE DEL FILE SYSTEM. Implementazione del File System. Struttura del File System. Implementazione IMPLEMENTAZIONE DEL FILE SYSTEM 9.1 Implementazione del File System Struttura del File System Implementazione Implementazione delle Directory Metodi di Allocazione Gestione dello spazio libero Efficienza

Dettagli

Sistemi Operativi IMPLEMENTAZIONE DEL FILE SYSTEM. D. Talia - UNICAL. Sistemi Operativi 9.1

Sistemi Operativi IMPLEMENTAZIONE DEL FILE SYSTEM. D. Talia - UNICAL. Sistemi Operativi 9.1 IMPLEMENTAZIONE DEL FILE SYSTEM 9.1 Implementazione del File System Struttura del File System Implementazione Implementazione delle Directory Metodi di Allocazione Gestione dello spazio libero Efficienza

Dettagli

Il sistema operativo

Il sistema operativo Il sistema operativo Percorso di Preparazione agli Studi di Ingegneria Università degli Studi di Brescia Docente: Massimiliano Giacomin Cos è un Sistema Operativo? Per capirlo, immaginiamo inizialmente

Dettagli

Il Sistema Operativo. C. Marrocco. Università degli Studi di Cassino

Il Sistema Operativo. C. Marrocco. Università degli Studi di Cassino Il Sistema Operativo Il Sistema Operativo è uno strato software che: opera direttamente sull hardware; isola dai dettagli dell architettura hardware; fornisce un insieme di funzionalità di alto livello.

Dettagli

Software relazione. Software di base Software applicativo. Hardware. Bios. Sistema operativo. Programmi applicativi

Software relazione. Software di base Software applicativo. Hardware. Bios. Sistema operativo. Programmi applicativi Software relazione Hardware Software di base Software applicativo Bios Sistema operativo Programmi applicativi Software di base Sistema operativo Bios Utility di sistema software Software applicativo Programmi

Dettagli

Parte V. Sistemi Operativi & Reti. Sistemi Operativi. Sistemi Operativi

Parte V. Sistemi Operativi & Reti. Sistemi Operativi. Sistemi Operativi Parte V & Reti Sistema operativo: insieme di programmi che gestiscono l hardware Hardware: CPU Memoria RAM Memoria di massa (Hard Disk) Dispositivi di I/O Il sistema operativo rende disponibile anche il

Dettagli

Controllo I/O Costituito dai driver dei dispositivi e dai gestori dei segnali d interruzione.

Controllo I/O Costituito dai driver dei dispositivi e dai gestori dei segnali d interruzione. C6. REALIZZAZIONE DEL FILE SYSTEM Struttura del file system Un file è analizzabile da diversi punti di vista. Dal punto di vista del sistema è un contenitore di dati collegati tra di loro, mentre dal punto

Dettagli

Sommario della lezione

Sommario della lezione Sistemi Operativi Docente: Ugo Erra ugoerr+so@dia.unisa.it 2 LEZIONE STRUTTURE DEI SISTEMI OPERATIVI CORSO DI LAUREA TRIENNALE IN INFORMATICA UNIVERSITA DEGLI STUDI DELLA BASILICATA Sommario della lezione

Dettagli

IL SOFTWARE TIPI DI SOFTWARE. MACCHINE VIRTUALI Vengono definite così perché sono SIMULATE DAL SOFTWARE, UNIFORMANO L ACCESSO SISTEMA OPERATIVO

IL SOFTWARE TIPI DI SOFTWARE. MACCHINE VIRTUALI Vengono definite così perché sono SIMULATE DAL SOFTWARE, UNIFORMANO L ACCESSO SISTEMA OPERATIVO IL SOFTWARE L HARDWARE da solo non è sufficiente a far funzionare un computer Servono dei PROGRAMMI (SOFTWARE) per: o Far interagire, mettere in comunicazione, le varie componenti hardware tra loro o Sfruttare

Dettagli

Corso di Sistemi di Elaborazione delle informazioni

Corso di Sistemi di Elaborazione delle informazioni Corso di Sistemi di Elaborazione delle informazioni Sistemi Operativi Francesco Fontanella Complessità del Software Software applicativo Software di sistema Sistema Operativo Hardware 2 La struttura del

Dettagli

INTRODUZIONE AI SISTEMI OPERATIVI

INTRODUZIONE AI SISTEMI OPERATIVI INTRODUZIONE AI SISTEMI OPERATIVI Il sistema operativo è il software che permette l esecuzione di programmi applicativi e lo sviluppo di nuovi programmi. CARATTERISTICHE Gestisce le risorse hardware e

Dettagli

Il sistema di I/O. Calcolatori Elettronici 1. Architettura a bus singolo. Memoria. Unità di I/O. Interfaccia. Unità di I/O.

Il sistema di I/O. Calcolatori Elettronici 1. Architettura a bus singolo. Memoria. Unità di I/O. Interfaccia. Unità di I/O. Il sistema di I/O Calcolatori Elettronici 1 Architettura a bus singolo Memoria CPU Interfaccia Unità di I/O Interfaccia Unità di I/O Calcolatori Elettronici 2 1 Interfaccia Svolge la funzione di adattamento

Dettagli

Il Software. Il software del PC. Il BIOS

Il Software. Il software del PC. Il BIOS Il Software Il software del PC Il computer ha grandi potenzialità ma non può funzionare senza il software. Il software essenziale per fare funzionare il PC può essere diviso nelle seguenti componenti:

Dettagli

Il Sistema Operativo (1)

Il Sistema Operativo (1) E il software fondamentale del computer, gestisce tutto il suo funzionamento e crea un interfaccia con l utente. Le sue funzioni principali sono: Il Sistema Operativo (1) La gestione dell unità centrale

Dettagli

CAPITOLO 1 I SISTEMI OPERATIVI

CAPITOLO 1 I SISTEMI OPERATIVI CAPITOLO 1 I SISTEMI OPERATIVI Introduzione ai sistemi operativi pag. 3 La shell pag. 3 Tipi di sistemi operativi pag. 4 I servizi del sistema operativo pag. 4 La gestione dei file e il file system Il

Dettagli

APPLICAZIONE COMPACTRIO DI RIFERIMENTO PER UN DATALOGGER A BORDO VEICOLO BASATO SU TIPS & TECHNIQUES

APPLICAZIONE COMPACTRIO DI RIFERIMENTO PER UN DATALOGGER A BORDO VEICOLO BASATO SU TIPS & TECHNIQUES APPLICAZIONE DI RIFERIMENTO PER UN DATALOGGER A BORDO VEICOLO BASATO SU COMPACTRIO Ryan King Q uesta applicazione presenta una soluzione software per un datalogger embedded stand-alone basato su hardware

Dettagli

Introduzione ai sistemi operativi

Introduzione ai sistemi operativi Introduzione ai sistemi operativi Che cos è un S.O.? Shell Utente Utente 1 2 Utente N Window Compilatori Assembler Editor.. DB SOFTWARE APPLICATIVO System calls SISTEMA OPERATIVO HARDWARE Funzioni di un

Dettagli

Strutture dei sistemi operativi

Strutture dei sistemi operativi Contenuti della lezione di oggi Strutture dei sistemi operativi Descrizione dei servizi messi a disposizione dell utente dal SO Utente generico Programmatore Esame delle possibili strutture di un SO Monolitica

Dettagli

Dispensa di Fondamenti di Informatica. Architettura di un calcolatore

Dispensa di Fondamenti di Informatica. Architettura di un calcolatore Dispensa di Fondamenti di Informatica Architettura di un calcolatore Hardware e software La prima decomposizione di un calcolatore è relativa ai seguenti macro-componenti hardware la struttura fisica del

Dettagli

Software che sovrintende al funzionamento del computer eseguendo compiti diversi:

Software che sovrintende al funzionamento del computer eseguendo compiti diversi: Sistema Operativo dispensa a cura di Alessandro Bellini Software che sovrintende al funzionamento del computer eseguendo compiti diversi: 1. Gestire interazione utente macchina 2. Fornire un interfaccia

Dettagli

Capitolo 11 -- Silberschatz

Capitolo 11 -- Silberschatz Implementazione del File System Capitolo 11 -- Silberschatz Implementazione del File System File system: Definizione dell aspetto del sistema agli occhi dell utente Algoritmi e strutture dati che permettono

Dettagli

Indice. settembre 2008 Il File System 2

Indice. settembre 2008 Il File System 2 Il File System Indice 4. Il File System 5. Vantaggi del FS 6. Protezione 7. Condivisione 8. I file - 1 9. I file - 2 10. Attributi dei file 11. Directory 12. Livelli di astrazione - 1 13. Livelli di astrazione

Dettagli

SOFTWARE. SOFTWARE Sistema operativo. SOFTWARE Sistema operativo SOFTWARE. SOFTWARE Sistema operativo. SOFTWARE Sistema operativo

SOFTWARE. SOFTWARE Sistema operativo. SOFTWARE Sistema operativo SOFTWARE. SOFTWARE Sistema operativo. SOFTWARE Sistema operativo Franco Sartore ottobre 2006, febbraio 2010 v_03 Software di base: programmi di gestione dell Elaboratore: Programmi di Utilità Applicazioni: Programmi che svolgono attività specifiche di alto livello (Word

Dettagli

Compiti del S.O. Lezione 2: Gestione dei processi. La struttura e funzioni dei Sistemi Operativi

Compiti del S.O. Lezione 2: Gestione dei processi. La struttura e funzioni dei Sistemi Operativi Lezione 2: Compiti del S.O. La struttura e funzioni dei Sistemi Operativi Un S.O. ha il compito di rendere semplice (all utente), l utilizzo del calcolatore componenti di un sistema operativo servizi dei

Dettagli

Sistemi Operativi I Corso di Laurea in Ingegneria Informatica Facolta di Ingegneria, Universita La Sapienza Docente: Francesco Quaglia

Sistemi Operativi I Corso di Laurea in Ingegneria Informatica Facolta di Ingegneria, Universita La Sapienza Docente: Francesco Quaglia Sistemi Operativi I Corso di Laurea in Ingegneria Informatica Facolta di Ingegneria, Universita La Sapienza Docente: Francesco Quaglia Introduzione: 1. Principi di base dei sistemi operativi 2. Sistemi

Dettagli

CAPITOLO 5 - Sistemi Operativi Moderni

CAPITOLO 5 - Sistemi Operativi Moderni CAPITOLO 5 - Sistemi Operativi Moderni PRESENTAZIONE DI INSIEME Vedremo ora come si è evoluta nel tempo la struttura di un sistema operativo, per passare dalle vecchie strutture di tipo normalmente modulari,

Dettagli

Infrastrutture Software

Infrastrutture Software Infrastrutture Software I componenti fisici di un sistema informatico sono resi accessibili agli utenti attraverso un complesso di strumenti software finalizzati all utilizzo dell architettura. Si tratta

Dettagli

DATA: 21-09-08 CLASSE: V a EL. TITOLO: ELABORAZIONE DEL SISTEMA OPERATIVO PER mp0

DATA: 21-09-08 CLASSE: V a EL. TITOLO: ELABORAZIONE DEL SISTEMA OPERATIVO PER mp0 DATA: 21-09-08 CLASSE: V a EL. TITOLO: ELABORAZIONE DEL SISTEMA OPERATIVO PER mp0 nelle lezioni precedenti abbiamo preso in esame tutte le caratteristiche e le funzionalità del microprocessore didattico

Dettagli

Elementi del calcolatore: CPU

Elementi del calcolatore: CPU Elementi del calcolatore: CPU Elementi del calcolatore: Memoria Elementi del calcolatore: Memoria Elementi del calcolatore: Hard Disk Antefatto Sistema Operativo Come il computer appare Il calcolatore

Dettagli

CAP. 6: Nucleo del sistema operativo (La gestione dei processi)

CAP. 6: Nucleo del sistema operativo (La gestione dei processi) Struttura interna del sistema operativo Linux CAP. 6: Nucleo del sistema operativo (La gestione dei processi) Architettura del sistema operativo shell Programmi utente Modo utente Interfaccia delle chiamate

Dettagli

EUCIP IT Administrator - Modulo 2 Sistemi operativi Syllabus Versione 3.0

EUCIP IT Administrator - Modulo 2 Sistemi operativi Syllabus Versione 3.0 EUCIP IT Administrator - Modulo 2 Sistemi operativi Syllabus Versione 3.0 Copyright 2011 ECDL Foundation Tutti i diritti riservati. Questa pubblicazione non può essere riprodotta in alcuna forma se non

Dettagli

Software di sistema e software applicativo. I programmi che fanno funzionare il computer e quelli che gli permettono di svolgere attività specifiche

Software di sistema e software applicativo. I programmi che fanno funzionare il computer e quelli che gli permettono di svolgere attività specifiche Software di sistema e software applicativo I programmi che fanno funzionare il computer e quelli che gli permettono di svolgere attività specifiche Software soft ware soffice componente è la parte logica

Dettagli

Definizione e storia dei sistemi operativi

Definizione e storia dei sistemi operativi Definizione e storia dei sistemi operativi Dipartimento di Informatica Università di Verona, Italy Che cos è un Sistema Operativo? E un insieme di programmi agisce come intermediario tra HW e uomo per

Dettagli

Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2015-16. Pietro Frasca.

Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2015-16. Pietro Frasca. Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2015-16 Pietro Frasca Lezione 15 Martedì 24-11-2015 Struttura logica del sottosistema di I/O Processi

Dettagli

IL LINGUAGGIO C NOSTRO APPROCCIO AL C. Sempre con esempi che illustrano le caratteristiche del linguaggio. SCRIVERE ED ESEGUIRE IL PRIMO PROGRAMMA C

IL LINGUAGGIO C NOSTRO APPROCCIO AL C. Sempre con esempi che illustrano le caratteristiche del linguaggio. SCRIVERE ED ESEGUIRE IL PRIMO PROGRAMMA C IL LINGUAGGIO C Sviluppato agli inizi degli anni '70 nei Bell Laboratories per ricerca, ha caratteristiche che lo rendono ideale per uso scientifico. Si sviluppa e si diffonde parallelamente a Unix. È

Dettagli

HARDWARE. Relazione di Informatica

HARDWARE. Relazione di Informatica Michele Venditti 2 D 05/12/11 Relazione di Informatica HARDWARE Con Hardware s intende l insieme delle parti solide o ( materiali ) del computer, per esempio : monitor, tastiera, mouse, scheda madre. -

Dettagli

NozionidiBase di Informatica

NozionidiBase di Informatica Università degli Studi di Parma Facoltà di Scienze MM.FF.NN. Corso di Laurea in Informatica NozionidiBase di Informatica Roberto Alfieri Giulio Destri Nozioni Base di Informatica - 1 R. Alfieri e G. Destri

Dettagli

Fondamenti di Informatica

Fondamenti di Informatica Fondamenti di Informatica Il software Dipartimento di Ingegneria dell Informazione Universitàdegli Studi di Parma SOFTWARE I componenti fisici del calcolatore (unità centrale e periferiche) costituiscono

Dettagli

Corso di Sistemi di Elaborazione delle informazioni

Corso di Sistemi di Elaborazione delle informazioni Corso di Sistemi di Elaborazione delle informazioni Sistemi Operativi Francesco Fontanella La Complessità del Hardware Il modello di Von Neumann è uno schema di principio. Attualmente in commercio esistono:

Dettagli

1. I dispositivi periferici

1. I dispositivi periferici La gestione dell I/O 1. I dispositivi periferici Un ulteriore aspetto fondamentale del SO è la gestione dei dispositivi periferici (periferiche) Dal punto di vista del sistema operativo per periferiche

Dettagli

Sistemi Operativi STRUTTURA DEI SISTEMI OPERATIVI 3.1. Sistemi Operativi. D. Talia - UNICAL

Sistemi Operativi STRUTTURA DEI SISTEMI OPERATIVI 3.1. Sistemi Operativi. D. Talia - UNICAL STRUTTURA DEI SISTEMI OPERATIVI 3.1 Struttura dei Componenti Servizi di un sistema operativo System Call Programmi di sistema Struttura del sistema operativo Macchine virtuali Progettazione e Realizzazione

Dettagli

GUIDA UTENTE INTERNET CAFE MANAGER (Vers. 5.2.0)

GUIDA UTENTE INTERNET CAFE MANAGER (Vers. 5.2.0) GUIDA UTENTE INTERNET CAFE MANAGER (Vers. 5.2.0) GUIDA UTENTE INTERNET CAFE MANAGER (Vers. 5.2.0)...1 Installazione e configurazione...2 Installazione ICM Server...3 Primo avvio e configurazione di ICM

Dettagli

Processi. Laboratorio Software 2008-2009 C. Brandolese

Processi. Laboratorio Software 2008-2009 C. Brandolese Processi Laboratorio Software 2008-2009 Introduzione I calcolatori svolgono operazioni simultaneamente Esempio Compilazione di un programma Invio di un file ad una stampante Visualizzazione di una pagina

Dettagli

Con il termine Sistema operativo si fa riferimento all insieme dei moduli software di un sistema di elaborazione dati dedicati alla sua gestione.

Con il termine Sistema operativo si fa riferimento all insieme dei moduli software di un sistema di elaborazione dati dedicati alla sua gestione. Con il termine Sistema operativo si fa riferimento all insieme dei moduli software di un sistema di elaborazione dati dedicati alla sua gestione. Compito fondamentale di un S.O. è infatti la gestione dell

Dettagli

11 Realizzazione del File System. 11.1.1 Struttura a livelli (fig. 11.1) 11.4 Allocazione dei file

11 Realizzazione del File System. 11.1.1 Struttura a livelli (fig. 11.1) 11.4 Allocazione dei file 11 Realizzazione del File System 1 Metodi di allocazione Allocazione contigua Allocazione concatenata e varianti Allocazione indicizzata e varianti Gestione dello spazio libero 11.1.1 Struttura a livelli

Dettagli

Corso di Introduzione all Informatica (corso A) MS-WINDOWS. Esercitatore: Francesco Folino

Corso di Introduzione all Informatica (corso A) MS-WINDOWS. Esercitatore: Francesco Folino Corso di Introduzione all Informatica (corso A) MS-WINDOWS Esercitatore: Francesco Folino IL SISTEMA OPERATIVO Il Sistema Operativo è il software che permette l interazione tra uomo e macchina (hardware).

Dettagli

Sistemi informatici. Informatica. Il software. Il sw di sistema. Il sw applicativo. Il sw di sistema. Il sistema operativo. Hardware.

Sistemi informatici. Informatica. Il software. Il sw di sistema. Il sw applicativo. Il sw di sistema. Il sistema operativo. Hardware. http://159.149.98.238/lanzavecchia/docum enti/sscta.htm Sistemi informatici Hardware Microprocessore Memoria Periferiche di input e output Software Software di sistema Programmi applicativi 1 2 Il sw applicativo

Dettagli

Il Software... A.A. 2013-14 Informatica 96

Il Software... A.A. 2013-14 Informatica 96 Il Software... A.A. 2013-14 Informatica 96 Il software L hardware non è direttamente utilizzabile Sono necessari dei programmi per far svolgere delle funzioni all insieme di circuiti Informatica 97 Il

Dettagli

Parte VI SISTEMI OPERATIVI

Parte VI SISTEMI OPERATIVI Parte VI SISTEMI OPERATIVI Sistema Operativo Ogni computer ha un sistema operativo necessario per eseguire gli altri programmi Il sistema operativo, fra l altro, è responsabile di riconoscere i comandi

Dettagli

Il computer: primi elementi

Il computer: primi elementi Il computer: primi elementi Tommaso Motta T. Motta Il computer: primi elementi 1 Informazioni Computer = mezzo per memorizzare, elaborare, comunicare e trasmettere le informazioni Tutte le informazioni

Dettagli

Fondamenti di Informatica Laurea in Ingegneria Civile e Ingegneria per l ambiente e il territorio

Fondamenti di Informatica Laurea in Ingegneria Civile e Ingegneria per l ambiente e il territorio Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma Fondamenti di Informatica Laurea in Ingegneria Civile e Ingegneria per l ambiente e il territorio Il software di base Software

Dettagli

I processi. Un processo è una attività, controllata da un programma, che si svolge su un processore.

I processi. Un processo è una attività, controllata da un programma, che si svolge su un processore. I processi Cos è un processo? Un processo è una attività, controllata da un programma, che si svolge su un processore. Il programma è una entità statica che descrive la sequenza di istruzioni che devono

Dettagli

Virtualizzazione delle Periferiche. Corso di Sistemi Operativi

Virtualizzazione delle Periferiche. Corso di Sistemi Operativi Virtualizzazione delle Periferiche Corso di Sistemi Operativi Introduzione Una delle funzioni principali di un SO è di controllare tutte le periferiche connesse al PC SO deve: comandare i dispositivi ascoltare

Dettagli

Il SOFTWARE DI BASE (o SOFTWARE DI SISTEMA)

Il SOFTWARE DI BASE (o SOFTWARE DI SISTEMA) Il software Software Il software Il software è la sequenza di istruzioni che permettono ai computer di svolgere i loro compiti ed è quindi necessario per il funzionamento del calcolatore. Il software può

Dettagli

File system. Chiamate di sistema POSIX Esempi: Chiamate di sistema Windows Esempio: Esercizi. 4.3 BSD Linux NTFS. Sistemi Operativi mod B 12.

File system. Chiamate di sistema POSIX Esempi: Chiamate di sistema Windows Esempio: Esercizi. 4.3 BSD Linux NTFS. Sistemi Operativi mod B 12. File system Chiamate di sistema POSIX Esempi: 4.3 BSD Linux Chiamate di sistema Windows Esempio: NTFS Esercizi 12.1 Le chiamate di sistema di UNIX per file UNIX mette a disposizione sia chiamate di sistema

Dettagli

Input/Output. Moduli di Input/ Output. gestiscono quantità di dati differenti a velocità diverse in formati diversi. n Grande varietà di periferiche

Input/Output. Moduli di Input/ Output. gestiscono quantità di dati differenti a velocità diverse in formati diversi. n Grande varietà di periferiche Input/Output n Grande varietà di periferiche gestiscono quantità di dati differenti a velocità diverse in formati diversi n Tutti più lenti della CPU e della RAM n Necessità di avere moduli di I/O Moduli

Dettagli

Fondamenti di Informatica T-1 CdS Ingegneria Informatica a.a. 2011/2012. Introduzione a Visual Studio 2005/2008/2010

Fondamenti di Informatica T-1 CdS Ingegneria Informatica a.a. 2011/2012. Introduzione a Visual Studio 2005/2008/2010 Fondamenti di Informatica T-1 CdS Ingegneria Informatica a.a. 2011/2012 Introduzione a Visual Studio 2005/2008/2010 1 Outline Solution e Project Visual Studio e linguaggio C Visual Studio schermata principale

Dettagli

Manuale dell utente. InCD. ahead

Manuale dell utente. InCD. ahead Manuale dell utente InCD ahead Indice 1 Informazioni su InCD...1 1.1 Cos è InCD?...1 1.2 Requisiti per l uso di InCD...1 1.3 Aggiornamenti...2 1.3.1 Suggerimenti per gli utenti di InCD 1.3...2 2 Installazione...3

Dettagli

Capitolo 1 Introduzione a Gambas

Capitolo 1 Introduzione a Gambas Capitolo 1 Introduzione a Gambas Gambas è stato creato inizialmente da Benoit Minisini, un residente della periferia di Parigi. Secondo Benoit, Gambas è un linguaggio Basic con estensioni per la programmazione

Dettagli

SISTEMI OPERATIVI. Gestione della memoria Domande di verifica. Luca Orrù Centro Multimediale Montiferru 18/06/2007

SISTEMI OPERATIVI. Gestione della memoria Domande di verifica. Luca Orrù Centro Multimediale Montiferru 18/06/2007 2007 SISTEMI OPERATIVI Gestione della memoria Domande di verifica Luca Orrù Centro Multimediale Montiferru 18/06/2007 Gestione della memoria 1. Si descriva il concetto di memoria virtuale (esame del 19-06-2006)

Dettagli

UTILIZZO DI WORD PROCESSOR

UTILIZZO DI WORD PROCESSOR UTILIZZO DI WORD PROCESSOR (ELABORAZIONE TESTI) Laboratorio Informatico di base A.A. 2013/2014 Dipartimento di Scienze Aziendali e Giuridiche Università della Calabria Dott. Pierluigi Muoio (pierluigi.muoio@unical.it)

Dettagli

Come fare a leggere questi dati generati da un programma windows?

Come fare a leggere questi dati generati da un programma windows? Come fare a leggere questi dati generati da un programma windows? A questo punto siamo in possesso di tutti gli elementi per sfruttare appieno le potenzialità di Linux: sappiamo destreggiarci (mai abbastanza)

Dettagli

Software di base. Corso di Fondamenti di Informatica

Software di base. Corso di Fondamenti di Informatica Dipartimento di Informatica e Sistemistica Antonio Ruberti Sapienza Università di Roma Software di base Corso di Fondamenti di Informatica Laurea in Ingegneria Informatica (Canale di Ingegneria delle Reti

Dettagli

Il sottosistema di I/O. Input Output digitale

Il sottosistema di I/O. Input Output digitale Il sottosistema di I/O Il sottosistema di I/O consente la comunicazione fra il calcolatore ed il mondo esterno. Fanno parte del sottosistema i dispositivi (Unità di I/O) per la comunicazione uomo/macchina

Dettagli

HP Capture and Route (HP CR) Guida utente

HP Capture and Route (HP CR) Guida utente HP Capture and Route (HP CR) Guida utente HP Capture and Route (HP CR) Guida utente Numero riferimento: 20120101 Edizione: marzo 2012 2 Avvisi legali Copyright 2012 Hewlett-Packard Development Company,

Dettagli

INTERAZIONE CON L UTENTEL

INTERAZIONE CON L UTENTEL IL SISTEMA OPERATIVO Insieme di programmi che opera al di sopra della macchina fisica, mascherandone le caratteristiche e fornendo agli utenti funzionalità di alto livello. PROGRAMMI UTENTE INTERPRETE

Dettagli

Capitolo 2. Esplorare l interfaccia tra uomo e computer

Capitolo 2. Esplorare l interfaccia tra uomo e computer Capitolo 2 Esplorare l interfaccia tra uomo e computer Imparare la tecnologia Gli esseri umani non hanno abilità tecnologiche innate La nostra precedente esperienza nell uso di dispositivi simili, incluse

Dettagli

PROGRAMMI UTENTE INTERPRETE COMANDI FILE SYSTEM GESTIONE DELLE PERIFERICHE GESTIONE DELLA MEMORIA GESTIONE DEI PROCESSI (NUCLEO) HARDWARE

PROGRAMMI UTENTE INTERPRETE COMANDI FILE SYSTEM GESTIONE DELLE PERIFERICHE GESTIONE DELLA MEMORIA GESTIONE DEI PROCESSI (NUCLEO) HARDWARE IL SISTEMA OPERATIVO Insieme di programmi che opera al di sopra della macchina fisica, mascherandone le caratteristiche e fornendo agli utenti funzionalità di alto livello. PROGRAMMI UTENTE INTERPRETE

Dettagli

Il Software. Scopo della lezione

Il Software. Scopo della lezione Il Software 1 Scopo della lezione Descrivere il software di base e le sue funzionalità principali la gestione della memoria centrale per l esecuzione di piu` programmi simultaneamente il file system come

Dettagli

Evoluzione dei sistemi operativi (5) Evoluzione dei sistemi operativi (4) Classificazione dei sistemi operativi

Evoluzione dei sistemi operativi (5) Evoluzione dei sistemi operativi (4) Classificazione dei sistemi operativi Evoluzione dei sistemi operativi (4) Sistemi multiprogrammati! più programmi sono caricati in contemporaneamente, e l elaborazione passa periodicamente dall uno all altro Evoluzione dei sistemi operativi

Dettagli

Introduzione. è uguale a 0, spostamento di dati da una parte della memoria del calcolatore ad un altra.

Introduzione. è uguale a 0, spostamento di dati da una parte della memoria del calcolatore ad un altra. Appunti di Calcolatori Elettronici Modello di macchina multilivello Introduzione... 1 Linguaggi, livelli e macchine virtuali... 3 La struttura a livelli delle macchine odierne... 4 Evoluzione delle macchine

Dettagli

Creare una memory stick USB bootable con cui avviare Windows XP

Creare una memory stick USB bootable con cui avviare Windows XP http://www.aprescindere.com Pag. 1 di 12 Creare una memory stick USB bootable con cui avviare Windows XP Creare una memory stick USB bootable con cui avviare Windows XP Perché avere una memory stick bootable

Dettagli

CPU chips e bus. Didattica della strumentazione digitale e sistemi a microprocessore anno accademico 2006 2007 pagina 1

CPU chips e bus. Didattica della strumentazione digitale e sistemi a microprocessore anno accademico 2006 2007 pagina 1 CPU chips e bus anno accademico 2006 2007 pagina 1 Layout di una cpu anno accademico 2006 2007 pagina 2 I bus in un sistema a microprocessore anno accademico 2006 2007 pagina 3 Proprietà di un bus Bus

Dettagli

Informatica di Base. Il software

Informatica di Base. Il software di Base 1 Sistemi informatici Hardware Microprocessore Memoria Periferiche di input e output Software Software di sistema Programmi applicativi 2 Il sw applicativo Il sw applicativo è costituito dall insieme

Dettagli