Home >ReactOS News >News #48: Anno in Rassegna
2009-01-16, Z98
Anno in Rassegna
translated by Gabriel ilardi on 2009-05-12
Guardando indietro al 2008
Anno in rassegna
Il 2008 ha visto un totale di quattro versioni rilasciate, tutte pubblicate dopo che è stata completata la riscrittura del kernel. Quindi le instabilità viste nella 0.3.1 sono state ridotte in gran parte, ci sono state più chance di far girare ReactOS su hardware reale e non solo su macchine virtuali. Non dico che il sistema gira in modo affidabile, ma ci sitamo avvicinando. Il numero di rilasci è certamente più alto che in anni passati, poiché il progetto era in una fase di stallo per le instabilità nel kernel.
Come tutti possono vedere, il 2008 è stato un anno intenso per noi, con continui sviluppi e la posa delle fondamenta per nuove iniziative che speriamo diano i suoi frutti in futuro. Inoltre, gli sforzi avviati anni addietro hanno iniziato a mostrare i risultati, facendo ReactOS più funzionale e stabile. Qui si evidenziano, parte dei progressi e sforzi che sono d'interesse per la comunità.
Vecchio e nuovo sangue
Diverse persone si sono unite al progetto come sviluppatori quest'anno, molti di questi, membri della comunità da tempo, e al meno una persona è ritornata al progetto dal suo iato. Un totale di 10 nuovi arrivati e uno ritornato sono adesso con noi e hanno contribuito tanto al lavoro di sviluppo. All'inizio dell'anno, in primo luogo la coppia Andrey Korotaev e Dmitry Chapsyshev. Dopo, Steven Edwars, il nostro contatto con Wine, è tornato per un po' con noi. Gli sono seguiti Matthias Kupfer, un vecchio membro della comunità, e Jeffrey Morlan, chi ha scoperto il progetto praticamente prima di diventare uno sviluppatore. Dopodiché, Stefan Ginsberg, che detiene la distinzione del più giovane sviluppatore di ReactOS, si è unito assieme a Cameron Gutman, un altro membro del forum che si è messo in contatto direttamente con gli sviluppatori in IRC. A questo punto, Samuel Serapion, nominalmente l'altro scrittore delle newsletter, ha ricevuto l'accesso commit. Da allora, deve ancora scrivere un'altra newsletter. Gli ultimi tre sono Michael Martin, Gregor Schneider, e Kamil Hornicek, tutti unitisi a un mese di distanza tra di loro. Con la manodopera aggiunta, il futuro di ROS sembra molto promettente.
Grafica
Visto che il kernel si è in qualche modo stabilizzato, l'attenzione si è spostata al sottosistema grafico. Il codice è molto vecchio e ha molti "hack", ma risolverli è la chiave per fare girare più applicazioni. A tal fine, molti sviluppatori hanno iniziato quello che è essenzialmente una riscrittura del sottosistema Win32. L'obiettivo primario è ripulire l'implementazione, l'architettura interna e le strutture dei dati, alcuni dei quali non esistono nell'implementazione Windows. Questo non è accettabile se vogliamo veramente essere compatibili, quindi Timo Kreuzer ha iniziato a separarli. Molte delle strutture di dati sono in realtà, combinazioni o fusioni di strutture esistenti. Timo è già risucito a togliere una struttura specifica di ROS e sostituire il codice che la utilizzava con un'implementazione adeguata, ma esistono molte altre sparpagliate in posti diversi. Per sostituirle tutte ci vorrà un po' tempo, specialmente se il codice si è evoluto per dipendere da queste strutture errate.
Un'altra questione interna che ha ricevuto tanta attenzione quest'anno è l'interdipendenza dentro al sottosistema Win32. Poiché il suo sviluppo iniziò prima che ci fossero informazioni pubbliche disponibili, sono state fatte certe supposizioni riguardo come si collegavano insieme. Questo ha creato alla fine dipendenze circolari, dove i moduli dipendevano gli uni dagli altri anziché essere uno strato dall'alto verso il basso. Eric Kohl ha speso un bel po' di tempo cercando di risolverlo e uno dei sui successi è stato far sì che CSRSS facesse l'inizializzazione senza usare shell32, un componente che non era stato caricato quando CSRSS iniziava. Questo sfortunatamente non risolve tutti i problemi di interdipendenze ma Jim sta continuando la sua ricerca.
Una terza questione architetturale riguardante il sottosistema Win32 è l'implementazione di ReactX, la nostra sostituzione di DirectX. Magnus Olsen si è reso conto durante l'anno che tale tentativo richiedeva più tempo di quanto aveva pensato, specialmente il supporto per il rendering 3D accelerato da hardware. Di conseguenza sono state perseguite due soluzioni a breve termine. La prima coinvolgeva l'uso di codice Wine, che traduce le chiamate Direct3D nelle controparti OpenGL approssimative, per fare lo stesso in ReactOS. Noi supportiamo l'accelerazione hardware, quindi questo trucco può aiutare a migliorare la performance. Tuttavia, Magnus ancora intende fare un'implementazione adeguata, che non abbia bisogno di essere instradata attraverso OpenGL. La seconda soluzione era migliorare il sottosistema Win32 al punto dove le librerie ufficiali runtime DirectX di Microsoft girassero in ReactOS. Questo richiederebbe la sistemazione delle strutture interne da cui dipende DirectX e farle identiche a quelle in Windows. Il lavoro per fare funzionare le DirectX di Microsoft in ReactOS iniziò nel 2004 e sta cominciando a mostrare i segni di progresso. Il driver DirectX viene caricato e funziona il rendering 2D con accelerazione hardware, ma manca ancora perché funzioni quello a 3D. Il lavoro fu uno sforzo tra Magnus Olsen, Timo Kreuzer, Jim Tabor, Maarten Bosma, e Alex Ionescu, di recente gli si è aggiunto Kamil Hornicek. C'è ancora tanto da fare, ma siamo al punto dove il progresso è visibile e non solo interno.
Finalmente, è da notare che c'è stato un duro lavoro di "bugfixing" assieme al lavoro nelle infrastrutture. Il rendering di grafici semplici è migliorato notevolmente durante l'anno, con più applicazioni effettivamente utilizzabili ora che vengono disegnate correttamente. In parte dovuto all'aggiornamento del codice che usiamo di Wine, ma anche agli sforzi da parte dei nostri sviluppatori. Non è stato cosa da poco, poiché il sistemare problemi architetturali nel sottosistema Win32 rivela "hack" usati per far sì che le cose vengano disegnate correttamente, quindi gli sviluppatori di Win32 dovevano risolvere prima i problemi e dopo gli "hack" che non funzionavano più bene avendo l'implementazione corretta.
Filesystem e Memoria
Il lavoro in questi due componenti è stato in contemporaneo, perché i driver di filesystem dipendono pesantemente dai servizi che fornisce il Gestore di Memoria. In realtà il lavoro è iniziato nel 2008 per riempire i buchi che ci impedivano di usare altri filesistem oltre al FAT32. I più grossi che ci bloccano sono la Libreria di Runtime del Filesystem estremamente incompleta e l'implementazione incorretta delle Cache Comune.
Il problema con la Cache Comune (CC) lo si conosce da un po' di tempo, con diversi sforzi per riscriverla in passato. In realtà la CC non è un componente separato in sé, ma semplicemente espone funzionalità nel Gestore di Memoria (GM). Per noi significa che per avere una CC adeguata bisogna anche avere un GM adeguato. Sfortunatamente, non era questo il caso. La CC e il GM si suppone abbiano un certo grado di astrazione ma la nostra implementazione essenzialmente li mischiava insieme. Quindi il primo passo è stato dissociarli, che è stato l'obiettivo dello sforzo NoCc iniziato da Aleksey Bragin e ripreso da Art yerkes. Aleksey intendeva con NoCc, il rimuovere le funzionalità che si suppone fornisce la CC, così che ci potessimo preoccupare prima nel sistemare i problemi sottostanti le operazioni di memoria prima di cercare di risolvere il compito della CC. Una volta certi che il gestore di memoria funzionava correttamente, potevamo cercare di implementare gli algoritmi di caching in CC. Art è riuscito a separarli, eliminando strutture di dati condivise che non sarebbero dovute esistere. Dopo ha implementato un algoritmo di caching semplice di "meno utilizzato recentemte" (LRU in inglese) ed è riuscito a fare il boot de ReactOS fino alla GUI prima che vada in crash. Considerando il fatto che CC non esisteva quando lo sforzo è stato avviato, molto è stato fatto, ma bisognerà fare altrettanto quest'anno.
L'altro componente da cui dipendono pesantemente i driver di filesystem e la libreria di runtime dei filesystem (FsRtl). Gran parte della FsRtl non esisteva in realtà, in quanto FAT32 è abbastanza semplice per poter "hackarlo" e farlo funzionare senza. Pierre Schweitzer si era unito originariamente per aiutare con RosBE, ma si è spostato alla FsRtl nel 2008. Ha lavorato parecchio in un branch separato, implementando funzionalità mancante sia in FsRtl sia nei servizi in altri componenti sui quali si basa la FsRtl. Questa è un'altra iniziativa per la quale ci vorrà un po' per vederla emergere, ma quando lo farà, potremo iniziare sforzi più seri per supportare nuovi filesystem.
Port
Si sono avviati due sforzi nel 2008 per portare ReactOS a differenti architetture, x64 e ARM. Entrambi hanno visto un progresso considerevole, con il port di ARM adesso al punto dove hanno iniziato a lavorare nell'inizializzazione dei componenti dello user mode nel processo di boot. Il port x64 sta andando più lentamente ma ha anche lui è arrivato ad un boot parziale. Entrambi gli sforzi hanno finito per esporre tanti bug nel Gestore della Memoria, il quale trae vantaggio dal lavoro nella piattaforma x86 anche. Gran parte del lavoro su x64 non è stato ancora aggiunto al trunk, mentre il lavoro in ARM
si fa direttamente nel trunk. Tuttavia, il lavoro fatto offre una base solida per lo sviluppo futuro, un port riuscito aprirebbe nuove opportunità per ReactOS.
Infrastruttura
E' stato fatto qualcosa per cercare di aiutare gli sviluppatori nell'essere più produttivi durante l'anno scorso. Oltre allo spostamento del server e l'upgrade, il progetto ha iniziato dei lavori su un sistema automatizzato di test per ogni revisione. Il primo passo in questo processo è stato l'ultimazione del programma Sysreg di Johannes Anderwald e Christoph von Wittich. Adesso gira sulle macchine di build, per il momento solo esegue test di Wine e si ferma al primo crash o fallimento. Eventualmente, eseguirà tutti i test nel modulo Rostest e finirà tutti indipendentemente dai fallimenti. Il rapporto che attualmente viene generato è molto grande, e Colin Finck e altri membri della comunità stanno lavorando per fornire un'interfaccia web per lo stesso. Fortunatamente ce l'avremo quest'anno.
Un'altra aggiunta importante è stato l'aggiornamento delle pagine Doxygen per il codice sorgente di ReactOS. Un bug nelle versioni precedenti di Doxygen, causava un loop infinito all'interno del codice quindi nessuno si disturbava nel generare nuova documentazione per nuove versioni. Questo significava che la documentazione presente era irrimediabilmente obsoleta per chiunque volesse utilizzarla. Adesso che il sistema è su e funzionante, possiamo utilizzare altre funzioni di Doxygen per rintracciare il progresso dello sviluppo e fornire un riferimento migliore per le persone che vogliano studiare il codice sorgente.
Bugzilla ha visto anche diversi miglioramenti. Grazie al nuovo articolo sul debugging nella wiki, chi segnala un bug adesso può fornire informazioni utili e log di debug, migliorando di conseguenza la qualità dei rapporti. Bugzilla ha visto anche una pulizia generale e una manutenzione migliorata, rintracciando e segnalando i problemi già risolti, eliminando rapporti duplicati e occupandosi delle patch inviate per una riesaminazione da parte degli sviluppatori.
Scansione di Coverity
Siamo stati messi in contatto con Coverity da Urias McCullough, un membro della comunità Haiku, abbiamo inviato il nostro codice per l'analisi. L'essere aggiunti come progetto open source analizzato da Coverity ci porterà grandi vantaggi a lungo termine, aiutandoci ad evitare certi tipi di bug e fornendo un controllo per la qualità in generale.
Compilatori
Uno dei problemi più grandi che il progetto ha dovuto gestire dovuto all'utilizzo di GCC come compilatore primario è la mancanza per il supporto alla SEH (Structured Exception Handling). KJK::Hyperion ha prodotto la libreria PSEH per compensarlo e nel tardo 2008 l'ha aggiornata alla versione 2.0. Ci sono ancora problemi sui quali KJK sta lavorando, ma dovrebbe portarci un passo più vicini all'utilizzo di uno schema di gestione delle eccezioni che è identico a livello sorgente con GCC e MSVC. Questo sarà molto pratico poiché KJK ha iniziato anche uno sforzo
per poter compilare ReactOS in MSVC, il compilatore Microsoft. Questi due insieme ci dovrebbero aiutare a migliorare la qualità del codice.
Idee Finanziate dalla Comunità
E' stato proposto diverse volte in passato ma non è stato sino a metà 2008 che è stato fatto uno sforzo per organizzarlo. Le IFC (CFI in inglese) sono pensate per permettere ai membri della comunità di donare per una caratteristica specifica di una lista che vogliono vedere completata. L'intento è fornire i fondi necessari agli sviluppatori perché possano impegnare il loro tempo nel completare la caratteristica senza doversi preoccupare delle responsabilità finanziarie della vita reale. Qualche progetto ha già ricevuto una quantità decente di donazioni e speriamo che le CFI come insieme si mostrino di successo in futuro. Lo sforzo attraversa ancora una tappa di pianificazione e organizzazione, ma gli sviluppatori hanno già iniziato il lavoro preliminare in alcuni dei progetti proposti.
