ReactOS Newsletter: Newsletter 46

ReactOS Newsletter - Newsletter 46 (#46)

Estensioni della cartella Shell
Bugfixing
Compilazione di ReactOS
I filesystem

Newsletter Archive

by Z98 on 2008-08-20
translated by Gabriel ilardi on 2008-08-20

top

Estensioni della cartella Shell

Tutte le cartelle speciali come il pannello di controllo, la cartella stampanti, strumenti di amministrazione sono in realtà estensioni della cartella shell che la shell Explorer implementa usando IShellFolder. Johannes Anderwald ha implementato quelle che mancavano in ReactOS e ha anche esteso e sistemato delle altre. Due nuove sono la cartella caratteri e la cartella Strumenti di Amministrazione. Joahnnes ha anche implementato il dialogo per formattare le unità, ma questo non è funzionale chiaramente.

Il cestino è stato riparato con l'aiuto di Hervé Poussineau, perché precedentemente c'erano dei problemi in Trash_CanTrashFile che impedivano i file di essere spostati. Questo significava che i file erano cancellati direttamente se si confermava la richiesta di cancellazione. Questo è stato risolto, assieme al ripristino di file e cancellazione di elementi individuali. La cartella stampanti aveva qualche problema, compreso il non comparire e in modo random l'allocare memoria. EnumPrinter è stata implementata, ma dato che il sottosistema di stampa non è ancora pronto, una fix completa dovrà aspettare.

C'è ancora tanto lavoro da fare, compresa la sistemazione dei menù contestuali. Il lavoro di Johannes è complicato dal fatto che Microsoft non ha implementato in modo adeguato tutte le estensioni dei menù contestuali, invece le ha codificate fisse per prevenire gli utenti dall'eliminarle. Questo sta creando qualche problema mentre lui cerca di implementarle tutte nel modo standard. La sua soluzione corrente è riscrivere la gestione dei menù contestuali, e sta facendo dei passi avanti.

top

Bugfixing

Uno dei bug più fastidiosi nascosti nel codice di ReactOS era il crash del sistema quando si terminavano dei thread worker. I thread worker sono thread del modo kernel, che fanno qualcosa per conto dei driver delle periferiche. Esiste un pool generale di thread worker, mantenuto dall'esecutivo NT, ma anche i driver possono creare il loro gruppo per necessità specifiche. Questo problema è stato trovato da Cameron Gutman mentre testava l'uptime di ReactOS. Dopo diverse ore quando i thread worker dinamici cercavano di terminare il sistema andava in crash.

La causa del crash era un check inadeguato in PspExitThread, il quale si supponeva andasse in crash se lo stack swapping era disabilitato. Il check era al contrario, quindi causava dei problemi quando lo stack swapping era abilitato. Ironicamente, c'era anche un altro problema in KeInitThread, nel quale la bandiera che abilitava lo stack swapping era impostata in falso quando doveva essere vero, ragione per la quale il bug è rimasto nascosto per tanto tempo. Entrami i problemi sono stati risolti da Stefan Ginsberg e dovrebbero permettere al sistema di stare su per più tempo. Solo il tempo dirà se questi cambiamenti esporranno altri problemi.

top

Compilazione di ReactOS

C'è una bandiera 'magic' in GCC, -enable-stdcall-fixup, che si usa quando si compila ReactOS. In situazioni dove delle funzioni sono degli alias di altre e il numero di parametri non concordano, questa flag lo permette comunque. Questa è ovviamente una cattiva pratica di programmazione e richiama solo problemi. Hervé Poussineau ha piano piano sistemato l'export delle funzioni così che possiamo non utilizzare più questa flag. Questo ha causato chiaramente qualche problema, ma lui pensa di aver risolto tutte le incongruenze delle export, e Hervé ha il record per rintracciare i problemi, sia quelli generati da lui stesso sia quelli degli altri.

Oltre alla sistemazione delle export, Hervé ha lavorato su un altro problema che coinvolge la compilazione dei componenti di ReactOS. Il compilare DLL è un po' più complesso che compilare degli eseguibili. Le DLL sono fondamentalmente una collezione di funzioni che si possono usare da altre applicazioni. Dovete chiaramente specificare quali funzioni volete che siano disponibili e quali non devono essere pubbliche. Ci sono due approcci, l'utilizzare la keyword di esportazione prima della funzione in questione oppure utilizzare un file .def per listare le funzioni che volete esportare. Se usate l'approccio .def, allora al meno con GCC, inviate a dlltool il file .def e il nome della dll in questione. Questo genererà un file .a che lista le funzioni richiamabili dall'esterno della DLL. Il file .a si usa ogni volta che scrivete un programma che utilizza la DLL. LD si lamenterà ovviamente di non trovare le funzioni in questione, ma se linkate usando il file .a con i file oggetto generati, proseguirà.

Il file .def menzionato sopra è diverso per GCC e MSVC. Dovuto a questo, se cercassimo di compilare una DLL in MSVC con il nostro .def attuale, fallirebbe. Per raggirare il problema, Hervé ha convertito tutti i nostri file .def in .spec. Lui intende migliorare Winebuild, un programma che converte file .spec in file .def di GCC, così che sarà in grado anche di generare file .def di MSVC. Una volta fatto questo, avremo un problema in meno per poter compilare usando il compilatore Microsoft. Per quelli curiosi sul come MSVC crea le DLL, l'unica differenza è che lui crea file .lib invece che .a ed entrambi sono funzionalmente identici. MingW crea anche file .lib, perché compila per la piattaforma Windows.

top

I filesystem

E' stato menzionato prima che i problemi con la Cache Comune, ci impedivano l'esecuzione da qualsiasi filesystem più avanzato del FAT. Per essere onesti, anche il driver FAT è stato "hackato" per raggirare i problemi nella Cc. Tuttavia, ai driver di filesystem non basta Cc per funzionare correttamente. C'è anche la FsRtl, oppure la Libreria di Runtime dei Filesystem. Senza l'implementazione di FsRtl, i driver di filesystem che ReactOS utilizza correntemente erano tutti stati scritti per non utilizzarla, il che complica ulteriormente la cosa perché i driver di FS si suppone usino quelle API. Mentre filesystem semplicisti riescono appena a funzionare senza di loro, le caratteristiche che fornisce la FsRtl sono essenziali per implementare ext2/3/4 e NTFS.

Mentre Art Yerkes e Aleksey Bragin hanno lavorato nella parte Cc, Pierre Schweitzer ha un "ramo" per implementare FsRtl e testare il driver ext2 che abbiamo importato scritto da Matt Wu. Una caratteristica sulla quale Pierre si sta focalizzando è la notficia di modifica di directory, la cui mancanza crea problemi di auto-aggiornamento sul desktop. Tuttavia, FsRtl è probabilmente una della API NT meno ricercate e anche con la documentazione del kit di sviluppo di filesystem ci sono tanti buchi neri. Attualmente Pierre sta facendo ricerca, cercando di vedere cosa succede quando le funzioni vengono chiamate in diverse circostanze. Questa tecnica di ricerca viene chiamata generalmente blackboxing ed è una utilizzata da diversi sviluppatori di ReactOS.

Anche se sono state implementate delle funzioni, Pierre pensa che ci vorrà un po' di tempo prima di avere un progresso tangibile.

top