Cosa sono le versioni "Debug / Checked" di un sistema operativo Windows?

Durante la ricerca di un download di Windows XP nel portale degli abbonati MSDN, ho notato questo:

inserisci qui la descrizione dell'immagine

Quindi, qual è la versione Debug / Checked?

windows windows-xp msdn

— Der Hochstapler
fonte

La versione di debug / controllata viene utilizzata per i driver di dispositivo di debug. Contiene controlli di runtime per le condizioni di errore e le ottimizzazioni di runtime sono state rimosse.

— David Schwartz
fonte

Nel caso non sia abbastanza chiaro: ciò significa che le versioni di debug / controllate funzioneranno più lentamente di quelle progettate per l'uso da parte dei consumatori.

— Hengjie,

In particolare, l'interpretazione delle spiegazioni , l'utilizzo di una versione Debug / Checked è probabilmente utile solo se si scrivono componenti in modalità kernel (molto probabilmente driver) o se si fa affidamento su alcuni componenti in modalità kernel di terze parti che si ritiene potrebbe essere difettoso nelle condizioni in cui li metti.

Vale a dire: la stragrande maggioranza degli sviluppatori (ovvero quelli che sviluppano software applicativo - software con cui gli utenti interagiscono, indipendentemente dal fatto che sia "gestito" o "non gestito", da riga di comando o basato su GUI; in breve, codice spazio utente ) non ne ha affatto bisogno e non dovrebbe usarlo, perché è più lento delle versioni principali di Windows.

Quindi, se non sei sicuro di averne bisogno, quasi sicuramente dovresti evitarlo. Al contrario, se il tuo lavoro ne trarrebbe beneficio, allora ne saresti già ben consapevole (ad es. Da qualsiasi luogo in cui hai imparato come procedere allo sviluppo in modalità kernel).

— Evgeni Sergeev
fonte

La velocità è assolutamente irrilevante durante la maggior parte dei test. Il motivo per cui la maggior parte degli sviluppatori di applicazioni non usa build verificate è che nessuno dei loro codici verrà nemmeno lanciato a causa di tutte le affermazioni. Se tutti gli sviluppatori dovessero produrre codice funzionante su build verificate, staremmo molto meglio.

— EKW,

@EKW Speed is utterly irrelevant...Non vero. Molti bug insidiosi emergono solo quando le cose iniziano a funzionare abbastanza velocemente da creare le condizioni per loro. Errori di threading particolarmente sottili, callback asincroni, ecc. A volte puoi persino vederlo visivamente quando esegui un'antica applicazione a 16 bit, ad esempio una riverniciatura tremolante molto fastidiosa.

— Evgeni Sergeev,

Quindi "la maggior parte dei casi". Alla fine, è necessario verificare una build gratuita o al dettaglio del sistema operativo. In genere, le applicazioni non riescono a effettuare chiamate corrette alle funzioni del sistema operativo o a gestire le eccezioni correttamente più spesso di quanto non abbiano problemi di concorrenza.

— EKW,

Sì, forse applicazioni sulla luna.

— Evgeni Sergeev,