Copyrigtht © 1997 Università di Firenze. All rights reserved.
Free license available.
In questo primo capitolo vengono spiegate per sommi capi le piattaforme di comunicazioni di Windows 95. Viene descritta l'architettura del software di rete, il modello WOSA e il supporto delle comunicazioni remote. Infine si analizzano le due API più importanti per le comunicazioni: TAPI e MAPI.
1.1 COMUNICARE CON WINDOWS 95
Molte nuove caratteristiche di Windows 95 - il sistema operativo e le applicazioni a 32 bit, gli elementi grafici della shell e le possibilità incorporate di collegamento alle reti locali - prevedono l'uso di un sistema desktop abbastanza potente. Ma bisogna tener conto anche delle necessità di una vasta gamma di utenti che non possono accedere continuamente ad un potente sistema desktop. Questi vengono generalmente chiamati "mobili", a indicare che usano computer in vari luoghi e in momenti diversi. Alcuni lo sono veramente, utilizzano solo laptop e viaggiano spesso, restando in contatto con le proprie sedi o i loro clienti attraverso posta elettronica, telefono e fax. Se a queste esigenze già consolidate si aggiungono quelle derivanti dai dati di mercato, che mostrano come le vendite di computer portatili crescano più rapidamente di quelle di qualsiasi altro tipo di macchina e quelle dei modem vadano oltre le previsioni più ottimistiche, diventa chiaro che Windows 95 ha bisogno di essere un buon prodotto per le macchine più piccole e per la comunicazione. Esamineremo un insieme di funzionalità di Windows 95 genericamente raggruppate sotto la dizione "mobile computing" (uso non fisso dei computer): supporto alle comunicazioni, supporto della posta elettronica e dei fax, supporto dei sistemi portatili. Gran parte del supporto delle comunicazioni si basa su elementi di Windows 95: l'architettura a strati della rete e le funzioni del fornitore di servizi WOSA. Vedremo poi i supporti di Windows 95 alle comunicazioni remote, i vari tipi di accesso alle reti remote ed infine le due API più importanti per le comunicazioni con le loro applicazioni più comuni: le TAPI e le MAPI.
1.2 ARCHITETTURE DEL SOFTWARE DI RETE
Il supporto delle reti in Windows 95 si basa su un modello stratificato e suddivide le funzioni in moduli distinti. I primi approcci formalizzati in questo campo sono stati tra i primi esempi di questa tecnica, mentre i componenti di architetture di reti esistenti, quali il modello OSI, hanno la tendenza ad assumere un atteggiamento decisamente dottrinario rispetto all'approccio a strati. La figura sotto mostra la configurazione generale del software di rete in un sistema Windows 95 "tipico" che consente di accedere a due reti tramite un solo adattatore.
1.3 WOSA
Le funzioni di rete di Windows 95 rappresentano uno degli esempi migliori dell'uso della Windows Open Service Architecture (WOSA) (architettura aperta dei servizi di Windows). La Microsoft ha coniato il pesante termine WOSA per indicare una specie di ombrello per un insieme di componenti software che, sebbene provengano da vari progetti, mostrano molte caratteristiche simili. Gran parte dell'impulso per la WOSA deriva dall'esigenza che le applicazioni possano essere interfacciate a diverse reti, sebbene la WOSA possa essere riferita anche ad ambienti non di rete. Essenzialmente, essa comprende una serie di interfacce progettate per consentire la coesistenza nel sistema di più componenti software con funzioni simili. L'interazione dell'utente con una applicazione fa sì che questa finisca per manipolare i dati tramite le routine API definite dal sistema. La WOSA introduce l'interfaccia dei fornitori di servizi (service provider interface) o SPI, che consente al sistema operativo di chiamare componenti del sistema (denominate service providers, fornitori di servizi) per portare a termine l'elaborazione dei dati. Mentre l'API è indipendente dall'hardware o dal servizio sottostante, la SPI rimane indipendente dall'hardware ma di solito dipende dal servizio, e la componente che lo fornisce è intimamente collegata al proprio ambiente di destinazione. Per quanto riguarda l'utente o un'applicazione, un fornitore di servizi è semplicemente una parte del sistema operativo.
La figura sopra illustra le componenti comuni che si trovano ogni volta che la WOSA viene utilizzata come modello del sistema. La configurazione standard comprende lo strato API, il modulo di instradamento (routing), lo strato SPI e i fornitori di servizi sottostanti. Per svolgere il proprio lavoro, un fornitore di servizi può chiamare qualsiasi funzione del sistema operativo o utilizzare altri fornitori di servizi di livello più basso (di nuovo, tramite una SPI definita). Un buon esempio dell'uso della WOSA è quello di un applicazione di posta elettronica. La maggior parte dei grandi utilizzatori di e-mail devono come minimo imparare un paio di editor di messaggi, diversi schemi di indirizzi per la posta e le idiosincrasie del sistema postale sottostante. La situazione desiderabile sarebbe quella di preparare i messaggi utilizzando un'unica applicazione e lasciare che sia il software sottostante a stabilire come consegnare il messaggio, indipendentemente che sia rivolto a qualcuno in ufficio, ad un collegamento su CompuServe o ad un utente di Internet. Esistono applicazioni che cercano di ottenere questo risultato, ma dal punto di vista dello sviluppatore di applicazioni, la prospettiva di dover scrivere un unico programma che sappia tutto di tutti i sistemi di posta elettronica è agghiacciante. Se scrivete il miglior editor di messaggi del mondo, vorrete poter fornire un messaggio completo al miglior programma di spedizione su Internet o al migliore su CompuServe, e così via. Più in basso nel sistema, i programmi di posta elettronica dovrebbero avere la possibilità di utilizzare uno dei tanti trasporti in rete per portare a termine la trasmissione fisica dei dati, e scrivere trasporti in rete non è quello su cui un produttore di applicazioni di posta elettronica vuole investire. La WOSA rappresenta la base per fornire questa distinzione funzionale all'interno di Windows. Ampliando l'esempio precedente, un editor di messaggi di posta elettronica utilizzerebbe l'API di Windows. Un fornitore di servizi postali implementerebbe la SPI appropriata (in questo caso, la MAPI della Microsoft), e sarebbe Windows stesso a collegare le componenti tramite il modulo di instradamento. Un sistema del genere esisterebbe per altri servizi. Ci sono già numerosi esempi del modello WOSA: l'interfaccia TAPI per i produttori di apparecchiature telefoniche, l'interfaccia WinSock che standardizza l'interfaccia socket TCP/IP sotto Windows, l'ODBC per accedere ai database ed altri. Ognuna di queste interfacce è un fornitore di servizi.
1.4 STRATI DI RETE
Riguardando la figura n°1, si può vedere l'influenza esercitata dalla WOSA sul sottosistema di rete di Windows 95: si utilizzano le tecniche WOSA per supportare contemporaneamente quanti collegamenti in rete si desidera. L'instradatore multiplo (multiple provider router, MPR) della figura suddetta è la componente di instradamento (routing) dei collegamenti in rete di Windows 95. Sia il modulo fornitore di rete, sia quello trasporti in rete seguono le regole SPI e al loro livello più basso, la popolare interfaccia NDIS (Network Driver Interface Specification, specifiche per le interfacce dei driver di rete) fornisce un ulteriore supporto per un accesso condiviso e l'astrazione dell'hardware di rete. Diamo una spiegazione delle funzioni di ognuna delle componenti illustrate nella figura n°1:
API. Lo strato API e l'API standard Win32. A parte le operazioni relative ai file, quali la loro apertura, effettuate per indirizzare sistemi di file remoti, l'API Win32 fornisce routine che si riferiscono specificamente alle reti. La routine WnetGetUser(), per esempio, consente ad una applicazione di determinare il nome dell'utente associato a un particolare collegamento in rete. Tutte le routine API di rete di Win32 hanno il prefisso Wnet.
Instradatore multiplo (MPR). L'MPR è la componente di instradamento per le operazioni di rete di Windows 95. L'MPR implementa anche le operazioni di rete comuni a tutti i tipi di rete. L'MPR gestisce tutte le routine API di rete, alcune delle quali possono essere instradate verso il modulo fornitore di servizi appropriato. L'MPR e i moduli fornitori di rete sono DLL in modo protetto a 32 bit.
Fornitore di rete (NP). Il fornitore di rete implementa l'interfaccia del fornitore di servizi definita dalla rete e offre operazioni quali effettuare il collegamento in rete, interromperlo e fornire informazioni sullo stato della rete. Solo l'MPR chiama il fornitore di rete: un applicazione non può rivolgerglisi direttamente.
Gestore dell'IFS. Il gestore dell'IFS svolge il proprio normale compito di instradare le richieste relative ai sistemi dei file al driver di sistema dei file appropriato (FSD). L'MPR non vedrà le chiamate di applicazioni basate sul nome di percorso o sullo handle: spetta al gestore dell'IFS indirizzarle al driver del sistema dei file di rete. I fornitori di rete possono chiamare il gestore dell'IFS direttamente per svolgere operazioni relative ai file.
Driver del sistema dei file di rete (FSD). Ogni FSD di rete deve implementare la semantica di un determinato sistema dei file remoto. L'FSD può essere chiamato dal gestore dell'IFS con richieste di tipo analoghe a quelle inviate ai sistemi dei file locali (per esempio, apri file o leggi file), oppure il fornitore di rete può chiamare l'FSD direttamente. Chiaramente, un produttore di rete deve sviluppare insieme l'NP e l'FSD di rete poiché ognuno dei due capisce qualcosa della semantica del sistema di file sottostante, così questi moduli non possono essere scambiati con altri dello stesso livello. Ogni FSD di rete è un VxD in modo protetto a 32 bit. (Già questo garantisce un notevole miglioramento nelle prestazioni di rete di Windows 95.)
Trasporto di rete. Il VxD del trasporto di rete implementa il protocollo di trasporto riferito al dispositivo. Windows 95 consente i trasporti multipli. L'FSD di rete richiama il trasporto per la consegna effettiva e il ricevimento di dati di rete. Date le probabili configurazioni delle reti dei sistemi Windows 95, probabilmente ogni FSD di rete userà un trasporto particolare, comunque la distinzione delle funzioni implica che è perfettamente legittimo che più FSD usino lo stesso trasporto. Il NetBEUI della Microsoft e l'IPX/SPX della Novell sono esempi di trasporti di rete che devono essere forniti con Windows 95.
NDIS. Le Network Driver Interface Specification (specifiche per le interfacce dei driver di rete) sono specifiche software indipendenti dai produttori che definiscono l'interazione fra ogni trasporto di rete e il driver del dispositivo sottostante. Le NDIS sono state originariamente messe a punto per consentire a più trasporti di utilizzare lo stesso adattatore fisico di rete ed il relativo driver di dispositivo. Le NDIS sono state revisionate nel corso degli anni, e le funzioni di rete diWindows 95 ne supportano la versione 3.0, anche se consentono l'uso dei vecchi driver a 16 bit che seguono il modello ODI (Open Datalink Interface della Novell) o versioni precedenti dell'NDIS. Sia Windows NT sia Windows 95 supportano l'interfaccie NDIS 3.0, il che significa che gli sviluppatori di driver di dispositivi di rete devono solo seguire le regole appropriate per ottenere un driver che funzioni sotto entrambi i sistemi operativi.
Driver dell'adattatore di rete. Il VxD del driver dell'adattatore di rete controlla l'hardware della rete. L'interfaccia NDIS consente al driver di non preoccuparsi della maggior parte delle questioni di protocollo: il driver lavora semplicemente in concerto con i trasporti di rete per inviare e ricevere pacchetti di dati. I driver progettati per i prodotti di rete della Microsoft vengono chiamati driver di controllo di accesso ai media, o semplicemente driver MAC. Il driver non deve incorporare il supporto per il sottosistema Plug and Play per poter partecipare completamente all'ambiente di Windows 95. Il driver dell'adattatore di rete supporta il Plug and Play insieme al VxD NDIS.386, che è una componente standard di Windows 95.
1.5 SUPPORTO DELLE COMUNICAZIONI REMOTE
Il progetto del sottosistema di comunicazioni di Windows 95 deriva in gran parte dal progetto del sottosistema per le reti locali. Un aspetto importante del software di rete di Windows 95 è la sua capacità di supportare molti collegamenti simultanei tramite diversi protocolli e trasporti su rete. Uno o più di questi collegamenti può andare dalla macchina dell'utente, tramite il sottosistema di comunicazione, a una rete remota o ad un altro fornitore di comunicazioni, per esempio una bacheca elettronica o un terminale d'accesso per la posta elettronica. Dal punto di vista dell'utente, la shell di Windows 95 integra l'accesso a sistemi remoti con accessi tramite reti locali, e almeno ai fini di condivisione dei file e delle stampanti, le comunicazioni remote appaiono e agiscono come qualsiasi altro collegamento in rete. Questa coerenza viene preservata nelle applicazioni che devono utilizzare servizi remoti: la API Win32 fornisce un interfaccia costante indipendentemente dal fatto che la risorsa utilizzata sia un file sul server di rete in fondo al corridoio o un file a migliaia di chilometri di distanza, accessibile solo tramite modem. Le applicazioni non devono tenere in particolare conto queste differenze fisiche nella connettività (anche se ne tengono conto quando sia possibile una certa ottimizzazione). Windows 95 fornisce alle varie componenti del sistema tutto il collante necessario per effettuare qualunque tipo di collegamento. E naturalmente, quelle funzioni vengono offerte da molte routine API specifiche per le applicazioni che sfrutteranno le possibilità della connessione remota. Una novità di Windows 95 è la Windows Telephony API, o TAPI. Questo nuovo insieme di interfacce Win32 integra molte funzioni collegate ai dispositivi di controllo di tipo telefonico, fra i cui i fax, le segreterie telefoniche e simili. Le precedenti versioni di Windows non disponevano di un insieme standard di routine API per supportare operazioni quali la composizione dei numeri e le risposte automatiche, così gli sviluppatori di applicazioni dovevano inventarsi le proprie. La TAPI affronta questo problema e offre i vantaggi della standardizzazione e la possibilità che i dispositivi vengano condivisi dalle applicazioni attive. Alla base di molte caratteristiche che rientrano nella categoria delle comunicazioni c'è il supporto dei dispositivi offerto in Windows 95. Sia che possediate un venerabile modem a 1200 bps o l'ultimo dispositivi fax cellulare, il driver delle comunicazioni, di solito chiamato semplicemente VCOMM, costituisce una componente cruciale del software di ogni collegamento tramite quei dispositivi. Sono state dette molte malignità sul driver delle comunicazioni (porta seriale) di Windows 3.1, soprattutto per quanto riguarda la sua incapacità a gestire i collegamenti alle velocità più alte. Come conseguenza, gli sviluppatori di molte applicazioni di comunicazione quali i pacchetti per i fax o i programmi di terminali, hanno sostituito il proprio driver a quello di Windows. Questo sviluppo irregolare ha spesso generato conflitti e bachi che un utente di due applicazioni non era in grado di risolvere. Nel caso di Windows 95 la Microsoft si è notevolmente impegnata per fornire un driver di comunicazione che gestisca in modo affidabile velocità di trasmissione estremamente elevate. Il sottosistema di comunicazione trae anche vantaggi sostanziali dai miglioramenti apportati al kernel del sistema operativo di Windows 95, in particolare dallo scheduling a sospensione e dal caricamento dinamico dei VxD. Il progetto del modulo VCOMM segue quella che è diventata una tecnica di progettazione molto praticata per le componenti di Windows: VCOMM viene condiviso fra le singole porte, con le operazioni che dipendono dall'hardware gestite da driver individuali per le porte di comunicazione. Ognuna delle porte seriali e parallele standard di una macchina ISA, per esempio, avrebbe il proprio driver di porta e condividerebbe le funzioni fornite nell'unico modulo VCOMM.
La figura sopra illustra le principali componenti software che dovrebbero essere presenti in un sistema Windows 95 configurato per le comunicazioni remote. Alcune di queste componenti sono facoltative o ridondanti, mentre altre hanno nomi ancora più acronimici. Diamo una spiegazione delle loro funzioni:
RNA. Il Remote Network Access (accesso a reti remote) è il sottosistema che consente ad un utente di uscire dal proprio sistema locale ed effettuare il logon su una rete remota. Il collegamento viene impostato in modo che l'utente vede la rete come se avesse effettuato il logon da una stazione di lavoro collegata direttamente. L'RNA ha una componente client e una server.
TAPI. La DLL che implemeta la Telephony API incorpora le nuove funzioni Win32 per la gestione delle linee telefoniche.
Unimodem. Il fornitore di servizi Unimodem rappresenta il tentativo della Microsoft di semplificare e unificare il supporto per i dispositivi modem sotto Windows. Per evitare che ogni singolo sviluppatore producesse e sperimentasse la propria interfaccia modem, la Microsoft fa usare a Unimodem un insieme di file di descrizione per consentire a tutte le applicazioni collegate di stabilire la configurazione di un modem e le sequenze appropriate del suo controllo a seconda delle necessità. In molti casi l'applicazione utilizza semplicemente chiamate API tipo apri e chiudi e il driver della porta Unimodem accede al file di informazioni del modem.
PPP. Il driver protocollo da punto a punto serve per un semplice protocollo che è stato ampiamente adottato. Il PPP viene usato per comunicazioni in un'unica sessione su linee con velocità relativamente bassa (tipicamente linee telefoniche). Il modulo PPP gestisce il bloccaggio e lo sbloccaggio dei pacchetti di dati e le correzioni di errori semplici.
VCOMM. Il nuovo driver di comunicazione per Windows 95 comprende un insieme di funzioni che devono essere usate dai driver delle porte e da altri client a livello diVxD. L'equivalente più vicino a VCOMM in Windows 3.1 è il driver della porta seriale, ma VCOMM si rivolge anche ad altri tipi di dispositivi di collegamento, compresi quelli a infrarossi e radiofonici.
Driver delle porte. Le componenti dei driver delle porte contengono il codice riferito all'hardware per i semplici dispositivi, quale la porta seriale o un collegamento a infrarossi. Windows 95 offre driver standard per dispositivi seriali e paralleli. Altri driver per le porte vengono forniti dai produttori dei dispositivi.
1.6 ACCESSO A RETI REMOTE
L'accesso a reti remote, o RNA, si riferisce, appunto, alla capacità di un sistema Windows 95 di accedere ad una rete remota. Lo scenario tipico presente una persona che viaggia per affari con un sistema portatile e che chiama da una stanza d'albergo per ricevere posta elettronica e altri documenti dalla sede della società. Molti prodotti attualmente sul mercato offrono queste possibilità. Sono di tre tipi:
L'RNA di Windows 95 implementa le prime due di queste possibilità. Un'applicazione Terminale migliorata utilizza i livelli inferiori del sottosistema di comunicazione per fornire l'accesso mediante commutazione. Il sottosistema RNA completo fornisce l'accesso in rete agli utenti remoti che usano Windows NT o un sistema Windows 95 con collegamenti per reti locali. Dal lato server, il sottosistema RNA supporta un solo collegamento, così questa possibilità sarà quella più usata da un'utente in una postazione remota che si collega al proprio sistema in ufficio oppure che chiama a casa dall'ufficio. In questo caso, può darsi che non entri in gioco una rete e che il server RNA fornisca semplicemente l'accesso alle risorse della macchina su cui viene eseguito.
1.7 TIPI DI ACCESSO REMOTO
Windows 95 fornisce tre modi diversi per stabilire un contatto con una rete remota:
I collegamenti in rete impliciti sono generalmente gestiti dalla shell. Quando l'utente cerca di accedere a una risorsa remota, la shell inizia il tentativo di collegamento, con un ulteriore intervento minimo da parte dell'utente. L'API Win32 associata all'RNA fornisce diverse funzioni che consentono a una applicazione di impostare e gestire un collegamento remoto:
RasDial() Gestisce il processo per effettuare un collegamento remoto.
RasHangrup() Pone termine a un collegamento attivo.
RasEnumConnections() Fornisce informazioni sui collegamenti attivi.
RasGetConnectStatus() Fornisce informazioni sullo stato corrente del collegamento iniziato da una chiamata a RasDial().
1.8 L'API TELEPHONY
Lo sviluppo della Windows Telephony API (TAPI) iniziò come parte del progetto At Work per l'automazione degli uffici. Il suo scopo è di integrare le attrezzature comuni degli uffici quali fax e fotocopiatrici, con i PC desktop. Un utente di PC potrebbe inviare, ricevere e stampare documenti in un formato digitale comune sotto la copertura di dispositivi supportati dal sistema operativo At Work. Il dispositivo più diffuso negli uffici è il telefono e At Work comprendeva le specifiche di un'API che consentiva agli sviluppatori di applicazioni Windows di controllare impianti telefonici adatti e apparecchiature di scambio appropriate. Windows 95 si concentra su quelle che la Microsoft chiama applicazioni di telefonia personale: essenzialmente quelle che assumono che venga usato un solo PC e un solo apparecchi telefonico. La maggior parte delle apparecchiature telefoniche attuali che possono essere collegate a un PC offrono allo sviluppatore di applicazioni una sorprendente gamma di interfacce (spesso proprietarie), e la maggior parte delle soluzioni disponibili tendono a essere altamente specializzate o a riferirsi a un gruppo ristretto di dispositivi. La TAPI rappresenta il tentativo della Microsoft di standardizzare un'interfaccia e, oltre ad affrontare la sfida dello sviluppo di un'API adeguata, la Microsoft deve convincere i produttori di apparecchiature telefoniche a supportare l'interfaccia del fornitore di servizi (SPI) nel contesto WOSA. L'uso del WOSA consente alla TAPI di rimanere indipendente dalle specifiche di qualsiasi dispositivo hardware. In Windows 95, viene preservata la filosofia dei fornitori multipli: per esempio, un fornitore di servizi può consentire l'accesso a un dispositivo condiviso insieme a un dispositivo collegato localmente. Per lo sviluppatore di applicazioni, il successo della TAPI renderebbe possibile sviluppare applicazioni Windows per controllare un'ampia gamma di hardware telefonico. Per l'utente, l'incorporazione della TAPI nel nucleo di Windows 95 dovrebbe significare che saranno disponibili molte applicazioni di tipo telefonico: applicazioni specializzate (filtraggio delle chiamate, per esempio) o applicazioni che sono estensioni delle funzioni disponibili nelle applicazioni desktop più diffuse (per esempio, l'integrazione dei messaggi vocali in un pacchetto di posta elettronica). Lo stesso RNA utilizza le TAPI quando attiva e controlla collegamenti remoti effettuati sulle linee telefoniche.
1.9 APPLICAZIONI DELLA TELEFONIA
La TAPI identifica due tipi distinti di collegamento: uno telefono-centrico, nel quale l'apparecchio telefonico è collegato direttamente alla rete telefonica e poi al PC attraverso un'interfaccia seriale, e un tipo di collegamento PC-centrico, nel quale una scheda di adattamento nel PC host è collegata sia alla linea telefonica sia all'apparecchio. Nel caso telefono-centrico, l'applicazione controlla la rete telefonica inviando comandi all'apparecchio per l'inoltro delle chiamate. Nel caso PC-centrico, la combinazione hardware del PC e applicazione TAPI emula un apparecchio telefonico per la rete e chiama in causa il vero apparecchio solo quando è necessario. Nello sviluppo delle applicazioni telefoniche, questi collegamenti hardware si manifestano come una classe di dispositivi in linea e una di dispositivi di telefono. Un dispositivo di linea è il collegamento tra desktop e rete telefonica. Il dispositivo di linea risponde agli oggetti dati, come un indirizzo (il numero telefonico), e a cambiamenti di stato, quali attivo e inattivo. Il dispositivo di telefono è la componente dell'apparecchio che fornisce l'accesso logico a componenti quali il campanello e qualsiasi pulsante o indicatore sull'apparecchio. Un concetto importante alla base del modello Microsoft delle applicazioni telefoniche è l'idea che una sola macchina desktop possa eseguire diverse applicazioni concorrenti interessate a un'unica linea telefonica. Una chiamata in arrivo può essere un fax, per esempio, una normale chiamata o una richiesta di collegamento da parte di un modem remoto. Un'applicazione conforme all'interfaccia TAPI dev'essere pronta ad esaminare la chiamata e, se non le interessa, a passarla all'applicazione successiva potenzialmente interessata. Analogamente, una volta che la linea telefonica è attiva, un'applicazione che cerchi di usare la linea dev'essere pronta a gestire elegantemente la condizione di errore dovuta al segnale di linea occupata.
1.10 SUPPORTO DEL MODEM
Prima c'era un driver universale per le stampanti, e adesso con Windows 95 sono arrivati un driver universale per i video e un driver universale per i modem. Ancora una volta, lo scopo è quello di fornire un'insieme comune di funzioni sperimentate in grado di controllare un'ampia gamma di dispositivi simili. Il nome Unimodem è stato assegnato sia a un fornitore di servizi TAPI sia a un driver di basso livello (implementato come VxD) che opera insieme a un driver di porta per controllare direttamente un modem collegato. Ci sono stati altri tentativi per standardizzare un'interfaccia di controllo dei modem, in particolare sul sistema Unix. Sotto un certo punto di vista, il problema è più risolvibile di quanto non lo fosse un tempo, in quanto praticamente tutti i produttori di modem utilizzano stringhe di comandi di tipo Hayes per il controllo diretto dei modem. In effetti, il driver Unimodem prende l'insieme dei comandi Hayes come base e poi definisce le eccezioni per i modem specifici. La descrizione di un modem è contenuta in un file di testo che può essere fornito dal produttore dell'hardware. Windows 95 fornisce un grande database dei modem conosciuti: le loro descrizioni sono nel file MODEMS.INF, che è una componente standard di Windows 95. Quando impostate un modem tramite il panello di controllo, le opportune stringhe dei comandi vengono copiate nel registro o da MODEMS.INF o dal file .INF fornito dal produttore. Una volta che le stringhe dei comandi sono state installate, il driver universale dei modem (UNIMODEM.386) può accedervi direttamente. Un'applicazione non vede mai le stringhe dei comandi utilizzate ai livelli più bassi, ma impartisce semplicemente richieste quali apri e chiudi. Questa organizzazione nasconde all'applicazione le caratteristiche di qualsiasi modem. La figura sotto illustra le interazioni fra le varie componenti quando viene utilizzato un modem collegato a una porta seriale.
Notate che il livello superiore del driver universale dei modem è un fornitore di servizi TAPI e che può coesistere con altri fornitori di servizi. Al livello più basso, il driver delle comunicazioni (VCOMM) instrada al driver dei modem le chiamate che lo riguardano; questo, da solo, si occupa del registro. Per il controllo effettivo del modem collegato, il driver chiama il VCOMM, che a sua volta chiama il driver della porta associata (in questo esempio quello della porta seriale SERIAL.386).
1.11 IL DRIVER DI COMUNICAZIONE
In Windows 3.1, il driver della porta delle comunicazioni aveva problemi di prestazioni perché doveva continuamente passare da modo protetto a modo reale e perché il sistema operativo non offriva funzioni multitasking a sospensione. Il driver VCOMM di Windows 95 contribuisce a risolvere il problema delle prestazioni fornendo un percorso in modo protetto dall'applicazione all'hardware. E le migliorie apportate al sistema operativo contribuiscono a conseguire l'obbiettivo di un supporto dei dispositivi di comunicazione affidabile e ad alta velocità.
La figura sopra illustra il modo in cui VCOMM interagisce con le altre componenti del sistema. E' da notare come il modulo COMM.DRV possa fornire la compatibilità per le applicazioni Win16 esistenti. Si tratta semplicemente di uno strato thunk che traduce le chiamate API a 16 bit per l'interfaccia Win32, non di una versione aggiornata del driver di comunicazione di Windows 3.1. VCOMM è un VxD statico che viene sempre caricato durante il processo di avvio di Windows 95. VCOMM partecipa al sottosistema Plug and Play caricando prima l'enumeratore appropriato, poi i singoli driver delle porte (che sono VxD caricati dinamicamente) quando le porte vengono aperte per la prima volta. VCOMM è a thread multipli e il suo codice è condiviso fra tutti i driver di porte di livello più basso che interagiscono direttamente con l'hardware. I servizi di VCOMM sono a disposizione degli altri VxD, ma non vengono mai richiamati direttamente da un'applicazione, ma solo tramite l'apposita routine API Win32. Tutti i servizi VCOMM possono essere identificati dal prefisso _VCOMM_. Windows 95 fornisce driver sia per le porte seriali (SERIAL.386), sia per quelle parallele (LPT.386). Quando VCOMM carica per la prima volta un driver di porta, questo registra la propria presenza tramite il servizio _VCOMM_Register_Port_Driver e fornisce l'indirizzo di una funzione Driver-Control() nel driver della porta. VCOMM utilizza il punto di ingresso Driver-Control() per dare istruzione al driver di inizializzare una porta hardware. Una volta che questa è stata riconosciuta e registrata, VCOMM la apre tramite la funzione PortOpen() del driver. Successive chiamate da VCOMM al driver passano attraverso una tabella di funzioni, il cui indirizzo viene fornito a VCOMM quando una chiamata PortOpen() è andata a buon fine.
1.12 L'INFO CENTER
La Microsoft ha raggruppato le varie componenti per accedere alle informazioni sotto il nome collettivo di "Info Center" (centro informazioni). Sebbene questo nome sia poco più di un semplice riferimento a un insieme di moduli per accedere alle informazioni, rappresenta un raggruppamento utile. L'Info Center di Windows 95 funge da punto di accesso comune per le applicazioni e i servizi che si occupano di informazioni per l'ufficio: messaggi di posta elettronica, messaggi di posta vocale, fax, moduli standard, e altri tipi di dati di testo, con strutture poco rigide. Per l'utente, Windows 95 fornisce un client di Microsoft Mail e gli strumenti di accesso ad Internet che si basano sull'API WinSock e lo stack di protocollo TCP/IP. Per lo sviluppatore di applicazioni, i servizi sottostanti forniscono un'interfaccia standard per i vari sistemi di messaggi. La struttura dell'Info Center consente di aggiungere con grande semplicità le applicazioni e i moduli dei fornitori di servizi. La figura illustra le componenti che Windows 95 riunisce sotto l'intestazione Info Center.
L'Info Center è suddiviso in tre strati di software: il livello delle applicazioni, visibile agli utenti finali, comprendente un'applicazione di posta elettronica, per esempio, e due livelli più bassi. Il primo è un'insieme di DLL Windows che implementano le routine API relative ai messaggi; il secondo è uno strato di fornitori di servizi che permette di accedere a vari servizi relativi ai messaggi. Ancora una volta la struttura è conforme al modello WOSA della Microsoft. Sotto lo strato dei fornitori di servizi può esserci qualsiasi protocollo o trasporto di rete oppure, per esempio nel caso di gestione di posta vocale, qualche altro sottosistema come la TAPI.
1.13 ROUTINE RELATIVE AI MESSAGGI
Le routine API relative ai messaggi in Windows 95 si suddividono in tre moduli distinti, due dei quali implementano il nucleo di quello che la Microsoft offre per quanto riguarda i messaggi: la Messaging Application Programming Interface (interfaccia di programmazione delle applicazioni relative ai messaggi) o MAPI. Sebbene la Microsoft sia riuscita ad ottenere l'appoggio di altre società per la MAPI, il suo progetto e il suo sviluppo sono senz'altro rimasti sotto il controllo della Microsoft. Le componenti dell'API relative ai messaggi sono tre:
MAPI semplice. Le funzioni base di invio e ricezione della MAPI.
MAPI estesa. Un sopra insieme della MAPI semplice, che incorpora possibilità per la memorizzazione, il reperimento e la ricerca dei messaggi.
CMC. Le Common Messaging Calls (chiamate comuni relative ai messaggi), un'implementazione di Windows 95 delle funzioni definite dalla X.400 API Association, della quale la Microsoft è un membro attivo.
Tanto le MAPI che le CMC consentono ad un'applicazione di utilizzare un insieme standard di funzioni relative ai messaggi. Lo sviluppatore di applicazioni non deve preoccuparsi dei dettagli del sistema di messaggi sottostante. La differenza essenziale fra la MAPI e le CMC sta nel fatto che la MAPI è definita solo per i sistemi Windows: la Microsoft non ha cercato di adattarla ad altri sistemi operativi. Le CMC, invece, sono definite come indipendenti dal sistema operativo e se state sviluppando un'applicazione che deve fornire messaggi a più ambienti hardware e software, le CMC sono preferibili alle MAPI. Quanto alle loro funzioni base, le CMC e la MAPI semplice sono molto simili. La MAPI semplice contiene solo 12 funzioni relative ai messaggi, ed è rivolta soprattutto all'uso di applicazioni consapevoli dei messaggi piuttosto che per implementare un'applicazione rivolta esclusivamente ai messaggi, per esempio un pacchetto di posta elettronica. Le funzioni della MAPI semplice consentono ad un'applicazione di inviare e ricevere messaggi e di manipolare informazioni relative agli indirizzi dei messaggi. La MAPI semplice consente anche di collegare file ai messaggi e di incorporare oggetti OLE in messaggi (da qui la dipendenza da Windows). La MAPI estesa è rivolta a grosse applicazioni relative ai messaggi: sistemi di posta elettronica, applicazioni di flussi di lavoro e pacchetti per la gestione di formulari, per esempio. Le funzioni della MAPI estesa consentono alle applicazioni di accedere alla memoria dei messaggi e alle agende supportate dai fornitori di servizi e di intervenirvi, oltre che di incorporare le funzioni di gestione dei formulari.
1.14 FORNITORI DI SERVIZI RELATIVI AI MESSAGGI
Sotto l'API relativa ai messaggi c'è l'insieme dei fornitori di servizi che capiscono i particolari del sistema di messaggi che gestiscono. Tutti i fornitori supportano la stessa interfaccia per fornitori di servizi, ma ognuno di essi viene scritto in modo che si interfacci ad un determinato sistema di messaggi. Così, per esempio, un fornitore di servizi supporterà Microsoft Mail sulla rete locale, mentre un altro potrebbe supportare l'accesso per telefono a MCI Mail. Tutti i fornitori di servizi MAPI hanno un fornitore di memoria (strore provider) nel quale le informazioni possono essere memorizzate e reperite, un fornitore di indirizzari (Address BooK Provider), che offre alcuni strumenti per tradurre un nome in indirizzo e un fornitore di trasporto (Transport Provider), che prende le informazioni e le trasmette materialmente al ricevitore previsto tramite qualche mezzo fisico, quale un fax o la semplice copia di un file. Questa separazione dei compiti è mascherata dall'API dei messaggi e, infatti, il fornitore di servizi sottostante può essere implementato come modulo singolo. La Microsoft intende includere un fornitore di indirizzari e di trasporti per l'interfaccia At Work Fax e per Microsoft Mail. L'indirizzario locale in un sistema Windows 95 è l'unico posto in cui vengono raccolti i nomi degli utenti e le informazioni relative. Il sistema di rete, per esempio, utilizza la MAPI come strumento per acquisire informazioni sugli utenti e tradurre i nomi di login.
Ultimo aggiornamento: 29/09/1997