a cura di Luciano Giustini

Utilizzo

Windows 95 e il Multitasking

Le relazioni pericolose: Windows 95 e il DOS

Affidabilità

D: Cosa succede alle applicazioni a 32 bit quando una a 16 bit va in crash sotto Windows 95?

R: Esse possono smettere di girare. Poichè Microsoft ha costruito Windows 95 usando lo stesso modello di VM di sistema (System Virtual Machine) di Windows 3.1, il sistema operativo è alla merce delle applicazioni a 16 bit. Se un programma Win16 diviene instabile, può facilmente bloccare moduli critici a 16 bit che si trovano nella VM di sistema. Tutti gli altri processi si bloccano.

D: Windows 95 protegge il contenuto della sua cache di sistema dalle intrusioni dei programmi Win32?

R: No. A causa della struttura sumenzionata Windows 95, inoltre, fallisce nel proteggere i contenuti della sua cache di sistema - cache disco, cache di rete e cache CD-ROM. Come risultato, un'applicazione Win32 che entra in errore puo' scrivere nella memoria in uso dalla cache. Potenziali risultati: dati errati, scritture su file system corrotte, ecc.

D: Come si comporta Microsoft sul problema dei VxD (Virtual Device Driver) e della loro instabilità?

R: Non si pone affatto la questione. Windows 95, infatti, fa un uso pesante dei VxD per supplire e, in molti casi, sostituire le funzionalità del DOS. I VxD sono programmi estremamente potenti che possono letteralmente andare ovunque e fare qualsiasi cosa nel sistema operativo. Essi hanno libertà di indirizzare la memoria di sistema direttamente, manipolare l'hardware, e persino sostituire porzioni di Windows 95 stesso a tempo di esecuzione. Ciò dà al creativo programmatore di VxD flessibilità illimitata nel disegnare applicazioni con l'esigenza di modificare le operazioni di Windows 95. Microsoft stessa ha spesso promosso l'interfaccia VxD come un meccanismo per ottenere buone prestazioni con applicazioni Windows time-critical. Sfortunatamente, la potenza dei VxD può anche rappresentare una maledizione. Nel momento in cui sempre più sviluppatori iniziano a utilizzare questa interfaccia - un'interfaccia che ha controlli limitati e isolamento inter-processo prossimo allo zero - i VxD prodotti da terze parti possono modificare il sistema in modi simili, con risultati imprevedibili. L'errore di un singolo VxD può minare la stabilità dell'intero ambiente Windows 95.

D: E' vero che Windows 95 non protegge il suo codice di sistema dagli errori delle applicazioni Win32?

R: Si. Le applicazioni Win32 possono scrivere in regioni dello spazio indirizzabile anche molto basse o molto alte nella VM di sistema, regioni che sono critiche per le operazioni di ambiente. Come risultato, una operazione in memoria sbagliata può minare la stabilità e potenzialmente bloccare l'intero sistema operativo.

D: Quando si eseguono applicazioni DOS, Windows 95 è in grado di virtualizzare l'hardware del PC come protezione contro possibili bug delle applicazioni stesse?

R: No. Windows 95 non è in grado di virtualizzare componenti critici dell'hardware come i flag di interruzione. Questo, in pratica, può portare a un crash di sistema se un programma DOS in errore non risponde mentre le interruzioni sono disabilitate.

[ Ritorna al menu ]

Utilizzo

D: Windows 95 tiene traccia dinamicamente degli oggetti?

R: No. Windows 95 usa una serie di nomi di percorso DOS statici e un mix di file .INI e .lnk per segnare la relazione tra icone del desktop e file su disco. Per esempio, il meccanismo Shortcut dell'interfaccia di Windows 95 si basa su una copia di archivio delle informazioni di percorso originali. Se il file fisico viene mosso all'interno della struttura delle directory, Windows 95 deve cercare il programma sul disco fisso basandosi sulla data e l'ora archiviati. Sebbene questa tecnica funzioni il più delle volte, essa è limitata a una ricerca sul singolo volume (partizione, NdR). Se il file viene mosso in un altro volume, il collegamento viene completamente rotto. Non solo, poichè Windows 95 se è connesso a una rete cerca all'interno di essa, può impiegare un tempo infinito se, per esempio, essa dispone di capacità di archiviazione dell'ordine delle decine di GigaByte.

D: Windows 95 fa un uso coerente della tecnica del Drag & Drop?

R: No. Le caratteristiche di Drag & Drop (Trascina e Rilascia, NdR) di Windows 95 sono applicabili ad alcuni oggetti, come file o cartelle, ma non ad altri. Non si può, per esempio, trascinare la cartella Dial-Up Networking sopra al Recycle Bin; e neanche trascinare oggetti sulla cartella My Computer - entrambi sono oggetti "speciali" nell'interfaccia Windows 95 e non sono soggetti alle normali regole di Drag & Drop. Questo introduce un livello di incoerenza nella interfaccia e un possibile ostacolo per i nuovi utenti a trarre vantaggio dal Drag & Drop.

D: Si può ritenere l'interfaccia di Windows 95 coerente e orientata agli oggetti?

R: No. Per esempio, mentre si può invocare il menu a pop-up del tasto destro del mouse nella maggioranza degli oggetti, le voci dello Start Menu e dei suoi sub-menu non sono incluse. Ciò rende scomodo il processo di manipolazione delle voci Start Menu, dovendo passare per la dialog-box delle proprietà della Taskbar e per diversi strati di menu e finestre. Poichè il bottone destro del mouse funziona in molte altre aree dell'interfaccia, la deviazione dello Start Menu da questa norma rende il supporto Object-Oriented di Windows 95 incompleto.

[ Torna al Menu ]

Windows 95 e il Multitasking

D: Windows 95 è capace di multitasking sulle applicazioni Win16?

R: No. Poichè le applicazioni Win16 sono state scritte per un ambiente multitasking cooperativo, esse non possono sopportare lo stress di essere "prerilasciate" durante l'esecuzione. Perciò Windows 95 deve gestire tali applicazioni nella stesso modo in cui lo faceva Windows 3.1: dando loro il controllo esclusivo della CPU per tutto il tempo che sono in esecuzione. Quando, e solo quando, l'applicazione fa una specifica chiamata API - una di quelle poche chiamate che costituiscono punti sicuri in cui Windows può strappare il controllo dal programma - gli altri programmi possono girare. Questo è il multitasking "cooperativo", che è stato dimostrato essere inefficace quando a girare simultaneamente sia più di una manciata di programmi o in caso di programmi CPU-intensivi come comunicazione, stampa e/o fax.

D: Ci sono dei limiti nel multitasking delle applicazioni Win32 sotto Windows 95?

R: Si. Per mantenere il più alto grado di compatibilità all'indietro e contemporaneamente contenere le richieste di RAM del sistema operativo, Microsoft ha scelto di basarsi sui moduli USER (gestione delle finestre) e GDI (Graphics Device Interface) di Windows 3.1, piuttosto che crearne nuove versioni a 32 bit. Per utilizzare questo codice più vecchio a 16 bit in un ambiente potenzialmente multitasking preemptive (relativamente alle sole applicazioni a 32 bit), Microsoft è stata costretta a serializzare l'accesso a USER e GDI. Come risultato solo una singola applicazioni Win32 o Win16 alla volta può accedere a questi moduli critici (modello non rientrante). Questo deprime le performance delle applicazioni in un sistema molto carico, poichè i programmi sono forzati ad "allinearsi" e attendere la possibilità di utilizzare una routine USER o GDI. Tutte le chiamate USER (sia per le applicazioni a 16 che a 32 bit) sono serializzate e gestite da codice a 16 bit, lo stesso per la maggioranza delle chiamate GDI (di cui un 50% è gestito da nuove routine a 32 bit).

D: Cosa succede al multitasking di Windows 95 quando si eseguono applicazioni di tipo misto?

R: Esso ritorna a un modello cooperativo. L'appoggio continuato che Windows 95 concede al modello di singola VM di sistema (che era di Windows 3.1) pone il sistema operativo alla merce del più basso comune denominatore: le applicazioni Windows a 16 bit. Nel momento in cui le applicazioni Win16 girano, le capacità multitasking del sistema operativo sono compromesse dalla necessità che esso ha di assicurare a questi programmi l' "indisturbabilità" per tutto il tempo che essi la richiedono. Come risultato, quando si eseguono applicazioni di tipo misto (il caso più frequente) il multitasking preemptive è impossibile dato che , in qualsiasi momento, un'applicazione Win16 può reclamare il controllo esclusivo della CPU. Peggio, poichè ogni applicazione Win16 esegue tipicamente una porzione di codice a 16 bit USER o GDI - l'accesso al quale deve essere serializzato tra tutti i processi - tutte le applicazioni, incluse quelle Win32, sono bloccate. Il risultato è quello che potrebbe essere descritto come un "semi-preemptive" multitasking.

D: Il multitasking di Windows 95 risolve qualcuna delle deficienze di Windows 3.1 relative alle applicazioni multimediali?

R: Non in realtà. Le performance incoerenti del multitasking di Windows 95 - un sottoprodotto della singola VM di sistema - compromettono la fruibilità del sistema come piattaforma di produzione multimediale. Video AVI complessi si interrompono brutalmente in presenza di un flusso di dati I/O. Anche semplici operazioni, come aprire un'applicazione, possono avere un impatto negativo sul playback multimediale.

[ Ritorna al Menu ]

Le relazioni pericolose: Windows 95 e il DOS

D: Windows 95 toglie realmente di mezzo il DOS?

R: No. Windows 95, sebbene pubblicizzato come completamente nuovo, o come sistema operativo a 32 bit, è ancora basato sulla tecnologia del DOS, datata 1980. Sotto Windows 95, anche applicazioni Win32 mantengono alcune strutture dati in modo reale dell'ambiente DOS (ancora più importante esse mantengono i PSP - Program Segment Prefix - in modo reale). Sebbene Microsoft sostenga il contrario, Windows 95 è molto sensibile alla configurazione dell'ambiente DOS reale del PC. Se, per esempio, la memoria convenzionale disponibile nella VM di sistema - la macchina virtuale DOS dove girano tutte le applicazioni a 16bit e parte del codice Win95 - scende sotto un certo livello, Windows 95 riporta il messaggio "out of memory" quando si prova ad aprire applicazioni Win16 o Win32 addizionali. Ciò non ha legami con il conosciuto fenomeno "Risorse di Sistema", e l'unica soluzione è di sostituire il più alto numero possibile di device drivers in modo reale con dei VxD oppure di investire in gestori di memori di terze parti come QEMM per ottimizzare l'ambiente DOS pre-Windows 95.

D: Cos'è il modo Single MS-DOS Application e in che modo influenza le altre applicazioni attive?

R: Microsoft ritiene il modo Single MS-DOS Application (SMA) la soluzione ultima per qualsiasi problema di compatibilità DOS. SMA è essenzialmente DOS in modo reale, solo che invece di effettuare il boot del DOS e poi caricare Windows, l'ordine è stato invertito: prima si carica Windows 95, poi lui stesso si "scarica" quando la macchina passa nel modo reale SMA. Questo elimina virtualmente ogni incompatibilità DOS dato che il PC non si trova più a girare in modo protetto V86 - esso viene riportato in modo reale tramite il caricamento di una copia del DOS. Ciò che Microsoft non ammette è che invocare un'applicazione SMA-dependent equivale nè più nè meno a uscire da Windows 95: tutte le applicazioni vengono chiuse, le connessioni di rete vengono staccate e il supporto VxD per periferiche come il CD-ROM scompare. Per mantenere queste funzioni si devono aggiungere device driver in modo reale nel DOS e poi configurarle tramite la SMA dialog-box. E dato che Windows 95 non è più attivo, qualsiasi utente che è connesso a risorse condivise sul sistema è scollegato quando esso entra nel modo SMA.

D: Come gestisce Windows 95 i device driver in modo reale del DOS?

R: La dipendenza di Windows 95 dal modo reale DOS mina l'abilità del sistema di supportare le applicazioni DOS. Poichè Windows 95, al momento di creare la VM di sistema, si basa su un' "immagine" dell'ambiente di boot-up precedente il suo caricamento, e poichè macchine virtuali DOS successive sono basate su questa stessa VM di sistema, gli utenti di Windows 95 sono costretti a caricare ogni device driver in modo reale richiesto, come parte del CONFIG.SYS originale. Le ramificazioni di questa limitazione sono significative: ogni sessione DOS sotto Windows 95 carica in memoria una copia di questi device driver in modo reale, anche se non sono richiesti per quella particolare sessione, con la possibilità che entrino in conflitto tra loro.

[ Ritorna al Menu ]