Community > ReactOS Newsletter Archive > ReactOS Newsletter: Newsletter 49

Newsletter 49

by Z98 on 2008-11-17
translated by Gabriel ilardi on 2008-11-17

Configurazione di rete

Johannes Anderwald ha lavorato per sistemare un bug persistente nelle impostazioni di rete apparso dopo la reimplementazione dei dialoghi di configurazione e impostazioni di rete in netcfgx.dll utilizzando le interfacce COM. Johannes le ha dovute anche implementare poiché non esistevano prima, adesso si trovano in netshell.dll. Sfortunatamente, sembra che dhcpclient salvava le impostazioni in una chiave sbagliata del registro, quindi non si risuciva ad ottenere informazioni DNS e le applicazioni che usavano quelle funzioni andavano in crash. Questo assieme a dei bug in iphlpapi e il codice nuovo hanno rimandato il rilascio, non potevamo certo rilasciare con gli strumenti di rete non funzionanti.

Timing

Stefan Ginsberg si è scontrato con una serie di bug di timing nel kernel tempo fa e ha cercato di risolverli. Dopo essersi consultato con altri sviluppatori, il problema è stato finalmente risolto. Una delle questioni più serie era quando si cambiava l'ora del sistema, i cambiamenti non venivano fatti nell'ordine corretto e potevano generare una condizione di "race" e bloccare il sistema. Un'altra questione meno seria era il timer che non scadeva in certe situazioni dove si cambiava l'ora del sistema.

PSEH 2.0

Nelle parole di KJK::Hyperion, "PSEH 2.0 è un orribile hack funzionante solo con GCC in x86... Complessivamente, deve essere un primato mondiale nell'abuso di un compilatore." Anche se PSEH 2.0 è un vero hack, è tuttavia un notevole miglioramento rispetto alla versione 1.1, la quale usava setjmp, falsi loop, e tutti i tipi di condotte di ottimizzazione strane per fornire una sembianza di supporto SEH.

La vera SEH riesce a nascondere il fatto che certi dei sui elementi sono in realtà funzioni annidate in altre funzioni, quindi sembrano come una qualsiasi altra porzione di codice. Questo è importante, in quanto quelle sottofunzioni devono essere in grado di condividere variabili con la funzione più esterna per propositi di gestione delle eccezioni. Un modo nel quale si ottiene questo è nascondendo come precedentemente menzionato. Il risultato finale è che SEH permette a diverse funzioni di condividere lo stesso stack, cosa che il C standard tecnicamente non supporta.

PSEH 1.1 non lo permetteva, motivo per il quale bisognava raggirare questo ostacolo in un modo piuttosto "doloroso". In sostanza, bisognava dichiarare le variabili condivise in una struttura definita nella funzione principale come una variabile locale e poi fare sì che PSEH passi un puntatore alla struttura alle sottofunzioni che lo potrebbero richiedere. Mentre SEH 2.0 tecnicamente non nasconde ancora la funzione, ottiene la stessa funzionalità approfittando di una caratteristica non standard di GCC liberandosi della necessità di definire quella struttura di variabili condivise. GCC stesso fa questa cosa in realtà comunque, quindi è solo questione di ottenere un puntatore a quella struttura. E' fattibile, ma viene fuori del codice brutto. Tuttavia, questo fa sì che PSEH 2.0 sia sintatticamente 99% identico a SEH. Per quanto riguarda la 1.1, bene, diciamo che è meglio dimenticarla.

Per quanto riguarda il porting di PSEH a ARM e x64, KJK dice che è fattibile, ma richiederà parecchio lavoro.

MSVC

Chiunque conosca KJK saprà che qualcosa lo avrà spinto a creare PSEH 2.0, le lamentele riguardo 1.1 non sarebbero bastate, visto che la metà di loro erano fatte da KJK stesso. La verità è che, KJK ha finalmente iniziato uno sforzo per fare sì che ReactOS sia compilabile con il compilatore Microsoft C/C++. L'uso di MSVC eliminerebbe la necessità di PSEH (se compilato con esso) e permetterebbe l'uso della vera SEH, questo è uno dei motivi per il quale si tenta di portare la sintassi di PSEH più vicina a SEH. Altrimenti diventa molto più difficile mantenere un trunk compilabile sia con GCC che con MSVC.

Le header attualmente in uso soffrono di una diversità di difetti, uno dei quali è l'utilizzo di #pragma system_header, una caratteristica GCC che nasconde le avvertenze da qualsiasi file che ce le abbia. L'obiettivo originale era quello di nascondere le avvertenze che risultavano dall'utilizzo di caratteristiche non standard di cui avevano bisogno le API Windows, ma alla fine hanno nascosto tutti gli errori. Potete immaginare tutte le trascuratezze che questo ha generato, poiché definizioni incorrette, duplicate o altri problemi non vengo più evidenziati. Stefan ha iniziato a vedere ogni header contenente pragma rimuovendola, per poi cercare di gestire i problemi risultanti. Pragma non era presente nel kernel stesso. Uno degli errori più prevalenti con cui Stefan si trova davanti sono le redefinizioni, con molte costanti e macro essendo definite in diversi posti. Peggiora così tanto che l'ambiente di sviluppo va in overflow, quindi Stefan deve verificare il log per vedere dovono capitano gli errori.

Oltre a ripulire le header stesse, Stefan le sta separando in vere DDK e PSDK, sbarazzandosi di miscugli di header tra componenti user e kernel mode, così come inclusioni incrociate di entrambi. Una volta terminato, si potrà forse creare un PSDK e un DDK separati.