Community > ReactOS Newsletter Archive > ReactOS Newsletter: Newsletter 63

Newsletter 63

by Z98 on 2009-07-31
translated by Gabriel ilardi on 2009-08-03

Interruzioni dei Test

Per diversi giorni la suite di test automatici che gira ogni revisione di ReactOS si è bloccata in un loop infinito una volta giunta ai test msi. Diverse persone che seguono i test hanno notato la questione e hanno suggerito le possibili cause ma Jeffrey Morlan ha fornito una patch che risolve la questione. Il problema sembrava di essere nella funzione LoadLibraryExW, in un caso specifico dove veniva impostato il flag LOAD_LIBRARY_AS_DATAFILE. La funzione riceveva come uno dei sui input DllName, il nome della libreria che gli veniva richiesto di caricare. Se c'erano spazi, la funzione allocava una copia privata che li tagliava. Una vola che la funzione terminava il suo lavoro liberava questa copia privata. Tuttavia, il codice creato da Dmitry Chapsev in realtà cercava di liberare la copia privata indipendentemente dal fatto che fosse usata o meno. Quando la stringa non aveva bisogno di essere tagliata, il tentativo di liberarla causava corruzione nella memoria che sembra di essere la causa del loop infinito. La patch di Jeffrey corregge questo problema e la suite di test non si blocca più. Anche se la suite di test sembrava di impallarsi all'infinito, ha fatto il suo lavoro esponendo il bug velocemente. Altrimenti l'errore potrebbe esserci sfuggito per un lungo periodo di tempo prima che ci desse più fastidio ancora.

Fix per MSVC

Stefan Ginsberg ha controllato ReactOS modulo per modulo per gestire numerose questioni di sintassi che impediscono a MSVC di compilare ReactOS. GCC è considerevolmente più indulgente di MSVC quando si parla di sintassi del codice e come risultato certe convenzioni nel codice di ReactOS anche se accettate perfettamente da GCC soffocano MSVC. Uno di questi casi era la definizione di prototipi di funzioni, dove differivano la convezione di chiamata, e la posizione e il raggruppamento del tipo restituito. MSVC si aspettava che la convezione di chiamata e il nome della chiamata fossero separati da parentesi mentre GCC non lo richiedeva. Questo particolare evento è cosparso in tutto il codice ma per fortuna è abbastanza facile da trovare e sistemare.

Un altro problema che è venuto fuori ma molto più grave è il fatto che GCC non avvertisse quando una funzione chiamava se stessa. Concesso il fatto che ci sono casi in cui servono chiamate ricorsive ma questa volta i risultati sono stati più che indesiderati perché hanno permesso una chiamata ricorsiva infinita. Il problema aveva origine negli header di w32api usati da mingw per Windows. Negli header, la funzione ExAllocatePoolWithQuotaTag era definita come ExAllocatePoolWithQuota. Questo causava una situazione molto scomoda poiché ExAllocatePoolWithQuota consisteva semplicemente in una chiamata a ExAllocatePoolWithQuotaTag visto che la prima funziona come un wrapper attorno alla seconda. Il codice compilato usando quegli header che tentava di usare la funzione ExAllocatePoolWithQuotaTag sicuramente finiva in un loop infinito, eventualmente esaurendo lo stack e causando un blue screen. MSVC rilevava questo problema ed emetteva un avviso anche al livello minimo di avvisi mentre GCC non sembrava che lo notasse e gliene importasse.

ARWINSS Redux

Sembra che ci sia ancora confusione riguardo lo scopo di ARWINSS dovuta alla limitata quantità d'informazione su di essa. Diverse persone l'hanno interpretata come un sostituto del sottosistema Win32, cosa che non è. Questo è stato chiarito esplicitamente prima e ha portato a speculazioni incontrollate. Alla luce di questo, Aleksey Bragin ha affermato che esiste come misura temporanea, approfittando del progresso di Wine nel girare applicazioni Windows per fare ReactOS più funzionale. La gente che si ricorda l'anno in cui Alex Ionescu in sostanza riscrisse il kernel si ricorderà la massiccia quantità di perturbazioni e disservizi causati perché tutto di un colpo tutti gli hack che tenevano il sistema insieme iniziavano a svanire. La riscrittura ci voleva proprio, ma il resto del sistema incampava quando doveva usare i diversi servizi del kernel correttamente. Il sistemare il sottosistema Win32 richiederebbe un livello simile di disservizi per via di questioni maggiori nei componenti critici. Sia Jim Tabor che Timo Kreuzer hanno lottato per tenere le regressioni ad un minimo mentre riscrivono il sistema , ma è una lotta continua. Questo, dal punto di vista di un utente, sarebbe inaccettabile. Ci deve essere qualcosa lì mentre avviene la riscrittura e a questo scopo si può usare ARWINSS. Se ha un posto a lungo termine resta da vedere, poiché le sue differenze possono permettere delle sperimentazioni che non non sono possibili con il sottosistema Win32 attuale.

Anche tenendo presente questo, non tutti sono d'accordo sul fatto della necessità di ARWINSS. Originariamente diversi sviluppatori avevano pensato che Aleksey stava cercando di sostituire il sottosistema Win32 in trunk e non hanno reagito bene a quella nozione. Anche dopo i chiarimenti ci sono delle preoccupazioni sul fatto che ARWINSS possa distrarre l'attenzione dall'attuale riscrittura.  Detto ciò, ARWINSS sta esponendo delle questioni interessanti dentro al sistema operativo come un insieme.  Si spera che ARWINSS fornisca un contributo positivo al progetto ma solo il tempo dirà.