Community > ReactOS Newsletter Archive > ReactOS Newsletter: Newsletter 55

Newsletter 55

by Z98 on 2009-03-16
translated by Gabriel ilardi on 2009-03-27

Motore dei Font

C'è una differenza tra funzionamento corretto ed implementazione corretta, una distinzione che uno deve sempre tenere presente quando dice che un qualcosa funziona in ReactOS. Nel caso del rendering del testo, mentre l'uscita per la maggior parte ha un aspetto corretto, l'implementazione sottostante non è assolutamente come dovrebbe essere. La catena di chiamata abbreviata per fare il rendering di testo è TextOutA/W, NtGdiExtTextOutW, and GreExtTextOutW. Ci sono delle variazioni, ma quella precedente fornisce un'idea generale del percorso verso la funzione Gre. ReactOS d'altra parte non aveva nemmeno GreExtTextOutW e il modulo Win32k stava in realtà chiamando NtGdiExtTextOutW. Poiché NtGdiExtTextOutW è la syscall che interagisce con memoria dello user mode e quindi si accerta che i buffer che vengono forniti si trovino nello user mode, la chiamata alla funzione in modo kernel con buffer in modo kernel non dovrebbe funzionare. Funzionava soltanto perché c'era un altro bug in MmCopyFromCaller, che si usa per copiare dati da buffer in modo user a modo kernel. Questa funzione si supponeva doveva controllare un buffer del modo user e copiare i dati in un buffer in modo kernel. Il controllo non funzionava, quindi permettendo a Win32k la chiamata a NtGdiExtTextOutW. Oltre a tutto ciò, MmCopyFromCaller non dovrebbe esistere. E' un hack specifico di ReactOS e NtGdiExtTextOutW dovrebbe usare SEH per controllare i buffer che riceve. La ragione per cui Win32k dovrebbe usare GreExtTextOutW è che sta gestendo buffer in modo kernel e GreExtTextOutW si aspetta di ricevere buffer in modo kernel. Quindi si fida di quello che riceve senza fare controlli. Questo è molto comune tra funzioni che sono disegnate per funzionare solo quando chiamate dal modo kernel.

Un'altra cosa che ReactOS non stava facendo è usare la struttura STROB/ESTROBJ, utilizzata per descrivere un insieme di glifi e la loro posizione, essenzialmente il testo che si vuole mostrare. GreExtTextOutW chiama ESTROBJ::vInit per inizializzare la struttura, passando anche i dati per riempirla e facendo la trasformazione di coordinate necessaria. La funzione ESTROBJ::vInit controlla anche la struttura di dati RFONTOBJ per informazioni riguardo i glifi di un font. Una volta fatto il tutto, la struttura STROBJ viene passata alla funzione EngTextOut oppure DrvTextOut. Il prefisso Eng si riferisce alle funzioni integrate di display in Win32k che agiscono come backup in caso il driver di display non implementi una funzionalità specifica, che in questo caso sarebbe la funzione DrvTextOut. Tuttavia il problema in ROS è che non esite STROBJ né RFONTOBJ di conseguenza non esiste neanche la catena di rendering descritta prima. Per di più Win32k in ReactOS non ha un'implementazione EngTextOut e ignora completamente la funzione DrvTextOut se esite.

Timo Kreuzer ha lavorato per rettificare questa situazione implementando un driver di font. La struttura RFONTOBJ menzionata prima agisce anche come cache per qualsiasi glifo già renderizzato. Tuttavia quando un glifo sta per essere renderizzato per la prima volta, viene chiamato un driver di font associato alla struttura RFONTOBJ. Il driver ha una funzione chiamata DrvQueryFontData che fa il rendering del glifo e restituisce un bitmap oppure un contorno. Il prossimo passo è implementare le strutture RFONTOBJ e STROBJ e dopo riscrivere le funzioni responsabili del rendering del testo per usarle. Quello dovrebbe tenerlo occupato per il prossimo anno circa.

Avendo spiegato tutto quello che ReactOS non sta facendo, sarebbe negligente non fornire un'idea al meno di quanto sta facendo, indipendentemente da quanto sbagliato sia. Anziché andare attraverso il driver di font per l'informazione del glifo, tutto quanto descritto prima viene scavalcato e viene chiamata la DLL di Freetype direttamente. E poiché le funzioni EngTextOut e DrvTextOut non svolgono un ruolo nel rendering del testo, GreExtTextOut chiama simplemente Freetype per fare il render dei glifi e dopo EngBitBlt oppure DrvBitBlt per mostrali. Un altro esempio di quanto possono essere contorte le cose all'interno di Win32k in ReactOS.

Networking

Come abbiamo menzionato nella precedente newsletter, Cameron Gutman ha lavorato e sta lavorando sullo stack di rete dopo l'implementazione iniziale di Art Yerkes. Ha praticamente risolto dei bug, come la cancellazione delle IRP che facevano che si bloccasse il ping. La maggior parte del suo lavoro è stato integrato nelle versioni 0.3.6 e 0.3.7 ed era sparpagliato attraverso diverse parti dello stack di rete. Variavano dall'assicurarsi che le risorse fossero allocate e de-allocate correttamente e restituire i messaggi di stato adeguati dipendendo dal completamento dell'operazione riuscita.

Twitter

Ged Murphy ha impostato recentemente un gruppo pubblico in Twitter dove gli sviluppatori interessati possono fornire aggiornamenti riguardo il progetto. Questi aggiornamenti saranno inviati attraverso il metodo normale di tweet, e ricevuti da qualsiasi persona segua l'account. Chiunque si registri come seguace di ReactOS sarà automaticamente seguito dall'account ReactOS. Questo significa a sua volta che sarà ammissibile per essere coinvolto in tweet di gruppo che verranno propagati a tutti i seguaci. Per mandare un tweet di gruppo, basta semplicemente mandare un messaggio diretto a reactos e GroupTweet penserà al resto. Un possibile impiego in futuro sarà la possibilità di fornire aggiornamenti mentre si è in convenzioni.