Community > ReactOS Newsletter Archive > ReactOS Newsletter: Newsletter 67

Newsletter 67

by Z98 on 2009-12-09
translated by Gabriel ilardi on 2009-12-10

Debugging

L'ultima volta che si era parlato del supporto WinDBG è stato un anno fa. Il primo passo necessario era un kernel compatibile con WinDBG, condizione ottenuta dopo la riscrittura del kernel fatta due anni fa circa. Le features richieste giravano intorno alla gestione del contesto di un thread in esecuzione e la lettura della memoria virtuale. Anche se la riscrittura del kernel l'aveva fatto possibile, c'erano ancora dei bug che impedivano l'uso. Per fare il debugging bisogna interrompere il flusso del thread in esecuzione ma bisogna anche ripristinarlo per poter permettere al programma di continuare. Uno dei bug che ne impedivano l'uso corrompeva il contesto di esecuzione e finiva per mandare in crash qualsiasi cosa si stesse debuggando. Un altro problema era l'HAL che cercava di mappare la prima pagina fisica usando il gestore di memoria. Questo falliva perché la funzione nel gestore di memoria faceva anche una sincronizzazione, che non poteva funzionare se l'HAL girava in un contesto di debug dopo il riavvio. Quando si girava nel suddetto contesto, non ce n'era bisogno di sincronizzazione alcuna, e c'era il rischio che i locks in questione fossero fatti da qualcos'altro. Ciò poteva tradursi in un deadlock e bloccare il sistema. Con queste e altre fix, Stefan è riuscito a connettersi al kernel di ReactOS con WinDBG e fare cose come impostare e cancellare breakpoints e leggere I/O e memoria. Tuttavia, per collegarsi a ReactOS ha dovuto usare il driver KDCOM di Windows 2003.

Il motivo per cui Stefan ha usato il driver KDCOM di Windows 2003 era semplicemente perché il KDCOM di ReactOS non funzionava correttamente quando Stefan aveva iniziato il suo lavoro. Nonostante gli sforzi di Timo Kreuzer per renderlo compatibile, non aveva raggiunto un punto dove lo si poteva utilizzare senza dover indagare dove era il punto dove si bloccava il collegamento tra KDCOM e il kernel. Nel momento in cui Stefan si era interessato nel supporto WinDBG, Timo aveva ripreso il suo lavoro sul KDCOM di ReactOS nel suo branch x64. Una diversità di questioni di timing creavano problemi come caratteri mancanti o pacchetti scartati, specialmente per quelli grandi, e rendevano il driver piuttosto inaffidabile. Timo ha aggiunto un ulteriore controllo e gestione degli errori per compensarlo. Una questione alquanto strana riguardante il timing erano i tentativi di scrivere sulla porta seriale che fallivano perché la periferica diceva di non essere pronta per scrivere, anche se controllando il suo stato si otteneva "pronta". La soluzione attuale di Timo consiste nell'introdurre un ritardo che sembra dare abbastanza tempo alla porta seriale per accettare dati, ma questa soluzione è molto lontana da quella ideale. La piattaforma corrente di testing di Timo è Virtual Box, che ha una storia di problematiche con la porta seriale. A volte i tester trovano dei problemi di formattazione tramite l'uscita seriale. Sembra che il progetto Virtual Box stia pianificando la riscrittura della loro implementazione seriale, fortunatamente dovrebbe risolvere i problemi che abbiamo riscontrato e permetterci di provare KDCOM a WinDBG in modo più affidabile.

Shell

La shell con cui interagiscono gli utenti è in realtà diversi componenti tutti legati l'uno con l'altro, motivo per cui non è affatto banale una riscrittura. Oltre alla shell explorer stessa ci sono le librerie shell32, browseui, comctl32, e shlwapi, tanto per dirne alcune. In ReactOS, gran parte delle funzionalità delle librerie si trova direttamente nella shell explorer perché le librerie in realtà non esistevano prima. Questo si deve all'eredità da parte di Wine dell'explorer e il fatto che Wine non ha bisogno in realtà di una implementazione shell32. Un esempio è il menù start stesso. Non è implementato realmente in explorer, ma solo esposto da esso. Un'altra è il menù di sistema. Tradizionalmente, i menù vengono gestiti da user32 nelle applicazioni Windows, ma la shell ha in realtà qualche menù customizzato che è gestito separatamente. Poche applicazioni oltre la shell ne farebbero uso quindi la loro mancanza è passata largamente inosservata, ma se qualcuno cercasse di usare una shell alternativa noterebbe immediatamente tutte le funzionalità mancanti.

Andrew Hill ha passato gli ultimi mesi a ricercare il sistema shell in Windows e vedendo cosa manca in ReactOS. E' riuscito a compilare con Visual Studio e fare girare su Windows XP diverse librerie relazionate con la shell così come explorer_new, il sostituto dell'attuale shell di ReactOS. Questo gli ha permesso di trovare funzionalità mancanti specifiche così come delle funzionalità che sono presenti ma non nel posto giusto. Un esempio di questo è la mancanza del menù start, uno di quei menù customizzati non gestiti nella
user32. Il suo obiettivo corrente è riuscire a far sì che l'explorer_new si comporti in modo identico a quello di XP e dopo reintegrare il suo lavoro in ReactOS.

Nuovi sviluppatori

Abbiamo già menzionato Andrew Hill ed è stato insieme a noi per diversi mesi, ma aveva preferito di rimanere al buio mentre ricercava. Inizialmente ha lavorato con Ged Murphy per mettersi in sesto e ultimamente ha iniziato ha committare i frutti del suo lavoro. Il suo nick in IRC è ash77, anche se molto probabilmente lo troverete con |away aggiunto alla fine, indipendentemente dalla sua attuale presenza o meno.

Un altro sviluppatore unitosi a noi è Giannis Adamopoulos, noto come smiley_ in IRC. Giannis è stato un assiduo frequentatore di IRC per diverso tempo.  Il suo interesse primario risiede nel lato kernel del sottosistema Win32 e aiuterà ad implementare funzionalità mancante.

Il recente afflusso di nuovi talenti sarà di aiuto per dare una spinta a ReactOS, ma c'è ancora tanto lavoro da fare per il quale servirebbe sicuramente una mano. Siamo ad un punto dove, la riscrittura di componenti vecchi e rotti, è abbastanza completa per permettere l'aggiunta di nuove funzionalità. Queste aiuteranno a rendere ReactOS più compatibile, serve tanto lavoro però. Fortunatamente il numero dei nuovi sviluppatori aumenterà man mano che il progetto cresce.