Home | Informazioni | Community | Sviluppo | myReactOS | Contattaci

  1. Home
  2. Informazioni
  3. Community
  4. Sviluppo
  5. myReactOS

  1. Descrizione
  2. Le persone di ReactOS
  3. Forum
  4. Wiki
  5. Mailing List
  6. Canali IRC
  7. Newsletter
  8. Blog
  9. FAQ per gli utenti

Community > ReactOS Newsletter Archive > ReactOS Newsletter: Newsletter 69

Newsletter 69

by Z98 on 2010-03-03
translated by Gabriel ilardi on 2010-03-09

top

Trap Handling


Uno dei modi in cui viene gestita la comunicazione di basso livello con l'hardware è con le interruzioni e con le eccezioni. Serve però del codice per gestirle e quel codice è il trap handler. Il codice di trap handler originale di ReactOS era assemblatore puro, cosa che è inevitabile per certe operazioni, per le quali il linguaggio C non specifica un metodo. Tali operazioni comprendono la manipolazione dello stack e la lettura e scrittura di registri specifici, che sono per definizione dipendenti dalla piattaforma la cui inclusione diminuirebbe la natura multi piattaforma del C. Come parte dello sforzo per portare ReactOS alla piattaforma ARM, il team ARM ha iniziato a riscrivere il codice per fornire al meno uno strato molto fino in C, con tutti i componenti specifici dell'architettura scritti in assemblatore intrinseco. L'assemblatore intrinseco è una serie di macro specifiche del compilatore che indicano quale istruzione assembler si vuole utilizzare nel codice C. Questo ha aiutato ad aumentare la manutenibilità e la leggibilità e ha risolto diversi bug nel processo. Questo non era necessario assolutamente per il port ARM, ma il team ARM ha pensato che il farlo porterà benefici a lungo termine per il progetto nel complesso. Sfortunatamente, l'uso di assembler intrinseco GCC ha impedito la compilazione del codice con MSVC. Prima i file in assemblatore potevano essere compilati in oggetti binari con i quali poteva lavorare dopo MSVC, ma la transizione al codice C l'ha reso impossibile. Qui è entrato Timo Kreuzer e ha cambiato l'intrinseco per assemblatore puro. Questo può sembrare un piccolo passo indietro, ma il framework in C è ancora al suo posto, e l'unica cosa che è stata cambiata è l'uso di assemblatore intrinseco di GCC. Nel processo Timo ha anche sistemato delle impostazioni di segmento e flag nel codice assemblatore e ha cambiato il modo in cui si passavano i parametri delle funzioni attraverso i registri da un metodo specifico per GCC a uno multi compilatore. Teoricamente, questo permetterà anche l'uso di Microsoft assembler per compilare l'assemblatore.

top

ACPI


Advanced Configuration and Power Interface è uno standard che dettaglia le specifiche per la gestione della alimentazione dei computer. Il supporto di ReactOS per questo standard era stato iniziato da Samuel Serapion, chi è anche l'altro scrittore delle newsletter e contributore del port x64. Sam ha preso l'implementazione di riferimento ACPI fornite dal comitato degli standard e l'ha portata a ReactOS. Tuttavia, dovuto al modo in cui venivano rappresentati nel codice gli ID hardware inizialmente lo stesso non funzionava. Cameron Gutman ha dato un'altra occhiata al codice recentemente e ha trovato il problema, adesso i componenti ACPI funzionano. Tuttavia, il codice in ReactOS è incompleto e qualche IRP (I/O Request Packets) generato dall'ACPI non viene ancora gestito. Comunque, Cameron ha risolto il problema principale per il quale non funzionava il lavoro iniziale di Sam.

top

Header dei Driver Windows


C'è stata in passato una collaborazione in doppio senso con il progetto mingw64, ma cinque giorni fa Kai Tietz ha avvicinato Amine Khaldi, the bug report wrangler, e gli ha chiesto se ReactOS fosse interessato in una collaborazione sugli Header dei Driver Windows. La maggior parte degli header di ReactOS sono corretti o al meno più completi, anche se un po' disorganizzati. Amine e Kai sperano di poter separare l'informazione negli header e fornirgli correttamente strutturati. Questo lavoro sarà fatto un branch per evitare interruzioni dello sviluppo nel trunk. Timo Kreuzer e Aleksey Bragin si sono accordati anche e Timo ha suggerito l'auto generazione del set di header pubblici per i drivers, simile a come Microsoft genera gli header per i suoi SDK e WDK. Ci sono anche certi casi dove serve qualche modifica per renderli compatibili con mingw64, ma il risultato finale sarebbe un kit di sviluppo driver (DDK) per Windows separato da quello rilasciato da Microsoft. Ci sono ancora delle questioni nell'uso di GCC per compilare driver nativi per Windows, la maggior parte dovuta al supporto per SEH, ma al meno è un inizio.

top

ReactOS nel Chemnitz Linux Day


Diversi membri del team di ReactOS saranno presenti al Chemnitz Linux Day expo che si terrà il 13 e il 14 Marzo. Saranno lì per promuovere il progetto, rispondere alle domande, e socializzare con la community open source.


top

ReactOS is a registered trademark or a trademark of ReactOS Foundation in the United States and other countries.