Windows ConfidentialIl potere dei bug

Raymond Chen

In Windows 95 , era possibile accedere alla pagina Risoluzione dei problemi e scegliere Disattiva il buffer sincrono. Ma che cosa succede dopo averla selezionata? E perché?

Il comportamento normale della funzione Commit di MS-DOS® era quello di cancellare tutti i dati non scritti per un determinato file sul disco e aspettare finché i dati non venivano confermati come scritti prima restituirli. Attivando l'opzione Disattiva il buffer sincrono, la chiamata verrebbe restituita subito piuttosto che aspettare la scrittura dei dati. Si trattava, certamente, di una violazione della specifica funzionale, in base alla quale la chiamata non doveva essere restituita finché i dati non venivano scritti. Di conseguenza aumentava il rischio di ciò che l'articolo 139669 della Knowledge Base definisce, in modo eufemistico, "problemi di integrità del file" poiché il programma che emetteva la richiesta di cancellazione presupponeva che i dati fossero al sicuro sul disco quando non lo erano.

È possibile che un programma di database utilizzi la funzione Commit per stabilire i punti in cui lo stato del file sul disco corrisponde a quanto il programma prevede sia presente sul disco. Se, durante un aggiornamento, viene a mancare l'alimentazione, il programma di database è in grado di utilizzare le informazioni registrate nell'ultimo punto di commit per ristabilire l'integrità del database. Se veniva restituito un risultato subito prima del termine del commit, questo punto di controllo di integrità veniva perso. Come conseguenza il database risultava danneggiato.

Perché quest'opzione era disponibile se le conseguenze erano così terribili? La causa: un bug in Windows® 3.11.

Figura 1 Abilitare il comportamento anomalo in Windows Server 2003

Figura 1** Abilitare il comportamento anomalo in Windows Server 2003 **(Fare clic sull'immagine per ingrandirla)

Windows 3.11 ha introdotto "l'acceso al file a 32 bit", un'implementazione a 32 bit dell'interfaccia I/O del file di livello inferiore. Ma l'implementazione della funzione Commit conteneva un bug che ignorava le richieste di cancellazione dei buffer di file. Se si utilizzava un programma che cancellava i buffer di file e lo si eseguiva in Windows 3.11, la chiamata di cancellazione non aveva effetto. Di conseguenza, se l'alimentazione mancava al momento sbagliato, il database risultava danneggiato.

Il team che si occupava del file system di Windows 95 ha corretto questo bug ma allo stesso tempo sono aumentate le segnalazioni di nuovi bug. Un sistema di contabilità fornitori ha iniziato a funzionare molto lentamente. Poi un altro programma di database ha subito forti rallentamenti. Cos'era successo?

Si è scoperto che questi programmi emettevano costantemente chiamate di cancellazione. I programmatori hanno notato che le chiamate di cancellazione erano veloci in Windows 3.11, quindi le hanno inserite in tutto il programma. Scrivere un byte, cancellare. Scrivere una stringa, cancellare. Poiché i flussi erano così veloci, l'applicazione avrebbe potuto eseguire il commit dei dati sul disco dopo ogni operazione senza alcun effetto negativo sulle prestazioni. Ma una volta corretto il bug in Windows 95, l'esecuzione di questi programmi è diventata molto lenta a causa delle chiamate di Commit.

Certamente, se il team di file system non avesse fatto niente, questi programmi avrebbero continuato ad essere eseguiti lentamente e gli utenti sarebbero arrivati alla conclusione che la causa del problema risiedeva in Windows 95. "Windows 95 è lentissimo", avrebbero detto. D'altra parte, se il file system fosse ritornato al vecchio comportamento di Windows 3.11, sarebbe stato reintrodotto un bug che avrebbe portato a quei noiosi "problemi di integrità dei file".

Quindi si è giunti alla conclusione che la soluzione era di lasciare la correzione del bug e aggiungere una casella di controllo, nascosta nella pagina della Risoluzione problemi, per consentire il ritorno al comportamento di Windows 3.11 a coloro che eseguivano programmi in cui si verificavano problemi dovuti al bug da correggere.

E la storia si ripete. In Windows Server® 2003, il team di I/O ha trovato un bug che causava la perdita del tag FUA per le richieste contrassegnate come Forced Unit Access (FUA) e la conseguente esecuzione di tali richieste come normale I/O. Era la versione moderna della soluzione che in passato consisteva nell'ignorare le richieste di cancellazione. Il bug è stato corretto ma è sempre disponibile un'opzione per ritornare al vecchio comportamento anomalo. La versione di Windows Server 2003 di questa casella di controllo è denominata "Abilita prestazioni avanzate" ma adesso si sa che non significa altro che "Ripristina il vecchio comportamento anomalo".

Raymond ChenSempre la stessa storia e il libro dall'omonimo titolo (Addison-Wesley, 2007) illustrano la storia di Windows e la programmazione in Win32. Raymond Chen non offre alcuna soluzione.

© 2008 Microsoft Corporation e CMP Media, LLC. Tutti i diritti riservati. È vietata la riproduzione completa o parziale senza autorizzazione.