Community > ReactOS Newsletter Archive > ReactOS Newsletter: Newsletter 54

Newsletter 54

by Z98 on 2009-03-04
translated by Gabriel ilardi on 2009-03-25

Utilizzo di memoria

La quantità minima di memoria richiesta da ReactOS è cresciuta, più che altro per l'installatore. In generale, gli sviluppatori sapevano che la memoria richiesta da ReactOS era molto inferiore dopo l'installazione che prima. La maggioranza aveva presunto che fosse un problema di perdita di memoria nell'installatore oppure nel gestore della memoria. Era una questione che molti volevano risolta, ma non è stato finché Alex Ionescu ha dato un'occhiata, che si è trovata la soluzione. Alex prima ha modificato la schermata dell'installatore per mostrare la cache del kernel e la pool del kernel anziché il pool paginato e non paginato per poter capire dove si perdeva la memoria. Alex ha anche rimosso un "hack" che rallentava l'installatore quando l'utilizzo di memoria superava il 40%. Dopo ha riparato parte del gestore della memoria e della cache comune, portanto la richiesta di memoria a 24mb. Il problema riguardava i file che finivano nella memoria cache del kernel però non venivano mai rilasciati quindi consumando memoria. L'installazione delle applicazioni dovrebbe richiedere anche meno memoria adesso. Oltre alle fix dell'installatore, l'utilizzo di memoria da parte del sistema operativo dopo il primo avvio è diminuito di 20mb. Son sicuro di non essere l'unico che apprezza queste fix.

CSR

Il componente CSRSS gestisce la console ed è rimasto dai primi tempi dove il codice di ReactOS era un caos, Timo Kreuzer ha cercato di sistemare la struttura di dati CSR_API_MESSAGE per qualche giorno. Questa struttura dati serve per CsrClientConnectToServer e una corretta inizializzazione di user32, che gestisce il passaggio dei messaggi, finestre, e altre cose che servono per fare funzionare Windows correttamente. La versione originale scritta in ROS è incorretta, e di conseguenza utilizzata in modo sbagliato da CsrClientConnectToServer. Tuttavia, in qualche parte del codice c'è un componente che sta utilizzando una dimensione hardcoded, quindi qualsiasi tentativo di aggiungere o togliere membri dalla stessa dà come risultato un crash. Timo ha cercato di rintracciare il problema ma non ha trovato la causa. Per il momento ha deciso di non indagare più nel componente né ricercare nel codice, non posso dargli torto. Ci sono righe dove qualcuno ha fatto cast multipli, prima a un tipo di puntatore generico, dopo incrementando l'indirizzo di quel puntatore della dimensione di quella struttura, e dopo facendo un altro cast ad un altro tipo di puntatore per diversi motivi. Qualsiasi persona con un minimo di conoscenza di C rabbrividirebbe solo guardando un codice del genere, oltre ad essere orribile è propenso a farci commettere errori.

Networking

E' passato un po' di tempo da quando Art Yerkes è riuscito a far funzionare il codice di networking. Da allora, Cameron Gutman l'ha continuato a rivedere, cercando di migliorarlo ed implementare nuove funzionalità. La maggior parte di questo lavoro era in un branch, ma ormai è stato sincronizzato col trunk. Tuttavia, Art si è preso un po' di tempo per occuparsi di vecchi bug adesso che ha una comprensione migliore dello stack di rete e dei protocolli.

Art ha fatto un lavoro aggiuntivo sul codice, risolvendo di recente un problema con il loopback. Per potersi collegare ad un socket in ascolto, l'indirizzo di bound dev'essere 0 oppure combaciare con l'indirizzo al quale l'applicazione si è associata. Per applicazioni che vogliono ascoltare il loopback, possono legare all'indirizzo 0 oppure 127.0.0.1. Utilizzando quest'ultimo l'applicazione potrà ascoltare solo il traffico locale, mentre se si usa il primo potrà ascoltare tutte le schede. Comunque in ReactOS, le applicazioni che cercavano di legare all'indirizzo 0, ascoltavano sull'indirizzo della prima scheda che ReactOS trovava. Questo significava normalmente, che non potevano ascoltare il traffico locale, e le applicazioni che dipendevano dall'indirizzo 0 non funzionavano. Art ha trovato il problema e l'ha risolto, adesso si si lega all'indirizzo 0 non ci sono problemi.

Un'altra questione risolta da Art è stata la gestione sbagliata di IRP_MJ_CLEANUP e IRP_MJ_CLOSE. Originariamente Art non aveva compreso correttamente a cosa servivano. IRP_MJ_CLEANUP si suppone cancella tutti gli IRP in attesa per l'oggetto per cui era stata chiamata. L'oggetto stesso era ancora valido dopo l'IRP ed era IRP_MJ_CLOSE che doveva de-allocare l'oggeto. Tuttavia, ReactOS trattava tutti i due gli IRP allo stesso modo e quindi de-allocava l'oggetto quando qualsiasi delle due veniva chiamata. Poiché il SO si aspettava ancora l'oggetto dopo una chiamata a CLEANUP, questo generava problemi con risorse mancanti.

Suono

Il progresso del supporto audio ha raggiunto il punto dove Andrew Greenwood può usare Winamp per riprodurre musica. Teoricamente si poteva fare in passato, ma usando il driver sndblst.dll per NT4. Adesso, è possibile farlo usando il driver sndblst.dll scritto da Andrew. Per il momento, si può riprodurre solo un file, anche se Andrew non ha cercato di vedere cosa succederebbe con stream multipli. Teoricamente dovrebbe dare un avviso dicendo che la periferica è già in uso. Kernel streaming non funziona ancora, al meno per Andrew. Per riuscire a fare comunicare wdmaud.drv con il codice di Johannes Anderwald ci vorrà ancora del tempo, così come per scrivere sndblst.sys, la parte kernel di sndblst.dll.

Piattaforma mirata

La versione di Windows che ReactOS mira ufficialmente è stato un punto di confusione da un po' di tempo.  Ci sono in realtà due mire specificate, una coinvolgendo il kernel NT e l'altra il sottosistema Win32.  Ufficialmente il kernel di ReactOS ancora punta al kernel di Windows Server 2003, noto anche come NT 5.2.  Questo obiettivo cambia molto lentamente.  D'altra parte il sottosistema Win32 mira sempre all'ultima versione di Windows rilasciata, che sarebbe Windows Vista al momento di scrivere questo articolo.  Questo è il motivo per il quale si vedono spesso commmit dichiarando aggiornamenti o implementazioni basati su Vista.  Quando Windows 7 verrà rilasciato, si sposterà anche la mira del sottosistema Win32 nuovamente, ma questo non vuol dire che si prenderà una decisione per spostare anche la versione del kernel.