ReactOS Newsletter: Newsletter 55

Newsletter 55

Silnik czcionek
Sieć
Twitter

Newsletter Archive

by Z98 on 2009-03-16
translated by Adam Stachowicz on 2010-07-19

top

Silnik czcionek

Istnieje znacząca różnica pomiędzy funkcjonalną i prawidłową implementacją, różnica na którą zawsze trzeba zważać, gdy mowa jest o funkcjonowaniu tej czy innej części systemu ReactOS. W przypadku renderowania tekstu, mimo, że rezultat często jest poprawny, algorytmy do tego prowadzące już tak poprawne nie są. Skrócony ciąg wywołań funkcji do wyświetlenia tekstu to: TextOutA/W, NtGdiExtTextOutW, oraz GreExtTextOutW. Istnieje kilka odmian, ale ciąg tu przedstawiony stanowi ogólny wzór ścieżki aż do funkcji GRE. ReactOS jednakże w ogóle funkcji GreExtTextOutW nie posiadał, a moduł Win32k musiał wywoływać bezpośrednio NtGdiExtTextOutW. Jako, że NtGdiExtTextOutW jest wywołaniem systemowym, które współpracuje z pamięcią trybu użytkownika, przez co musi sprawdzać czy bufory mu podawane są w tym samym trybie, wywoływanie tej funkcji z trybu kernela, z buforami w tymże trybie (Win32k jest modułem tryby kernela - przyp. tłum) nie powinno w ogóle działać. Działało tylko z powodu zupełnie innego błędu w funkcji MmCopyFromCaller, której używa się do kopiowania danych z buforów trybu użytkownika do trybu kernela. To właśnie ta funkcja winna sprawdzać, czy bufor jest w trybie użytkownika i kopiować dane do buforu trybu kernela. Błąd w algorytmie sprawdzającym umożliwiał modułowi Win32k wywoływanie funkcji NtGdiExtTextOutW. Najciekawszy jest fakt, iż taka funkcja jak MmCopyFromCaller nie powinna istnieć. Jest to typowe dla ReactOS obejście problemów z prawidłową implementacją jako, że NtGdiExtTextOutW powinien sprawdzać bufory, jakie są podawane do tej funkcji, z pomocą SEH. Na koniec, Win32k powinien otrzymywać dane z funkcji GreExtTextOutW, która ma za zadanie przetwarzać bufory w trybie kernela, i takich buforów właśnie oczekuje. Dlatego też automatycznie ufa ona zawartości buforów, bez sprawdzania ich zawartości. Takie zaufanie jest typowe dla funkcji zaprojektowanych do pracy wyłącznie w trybie kernela.

ReactOS również nie korzysta ze struktur STROBJ/ESTROBJ, opisujących zestawy glifów oraz ich pozycje, które mają w efekcie złożyć się w wyświetlany tekst. GreExtTextOutW wywołuje ESTROBJ::vInit w celu inicjalizacji tej struktury, przy okazji przesyłając do niej dane i dokonując koniecznych translacji koordynatów. Funkcja ESTROBJ::vInit odwołuje się do struktury RFONTOBJ w celu pobrania informacji o glifach danej czcionki. Następnie, STROBJ jest przesyłany do funkcji EngTextOut albo DrvTextOut. Przedimek Eng oznacza wbudowane w Win32k funkcje wyświetlania obrazu, które używane są w przypadku gdy sterownik grafiki nie wspiera danej funkcjonalności (którą w tym przypadku jest funkcja DrvTextOut). Problemem ReactOS był więc brak zarówno STROBJ jak i RFONTOBJ a więc i brak opisanego wyżej, poprawnego ciągu wywołań. Gdyby tego było mało, Win32k nie posiadał również zaimplementowanej funkcji EngTextOut i ignorował zupełnie DrvTextOut, jeśli nawet była ona wspierana przez sterownik grafiki.

Timo Kreuzer od dłuższego już czasu pracował nad wyprostowaniem tej sytuacji. Wspomniana powyżej struktura RFONTOBJ działa również jak podręczna pamięć na już wyrenderowane glify. Jeśli jednak glif ma zostać wyrenderowany po raz pierwszy, wywoływany jest związany z RFONTOBJ sterownik czcionek. Ten sterownik zawiera funkcję DrvQueryFontData, dokonującą renderowania glifów i zwracającą bitmapę lub obrys. Następnym krokiem będzie implementacja struktur RFONTOBJ i STROBJ oraz przepisanie funkcji odpowiedzialnych za renderowanie tekstu, tak by zaczęły z tych struktur korzystać. To powinno dać Timo dość rozrywki na najbliższy rok albo dwa.

Po wyjaśnieniu wszystkiego tego, czego ReactOS w chwili obecnej nie robi, zaniedbaniem byłoby nie wspomnieć o tym co właściwie robi, nie ważne jak bardzo nie jest to prawidłowe. Zamiast pobierać informacje o glifach poprzez sterownik czcionek, cała opisana wyżej procedura jest pominięta. ReactOS wywołuje bezpośrednio bibliotekę Freetype. Jako, że zarówno EngTextOut jak i DrvTextOut nie biorą udziału w renderowaniu tekstu, GreExtTextOut po prostu wywołuje Freetype by wyrenderować glify a następnie używa EngBitBlt albo DrvBitBlt by je wyświetlić. Oto kolejny, świetny przykład tego, jak pogmatwany jest obecnie Win32k.

top

Sieć

Jak wspominałem już wcześniej, Cameron Gutman pracuje od dłuższego czasu nad stosem sieci, po tym jak Art Yerkes ukończył jego podstawową implementację. Głównie poprawiał błędy, takie chociażby jak anulowanie IRP, które powodowało zawieszenie się systemu przy użyciu komendy Ping, ale również dotyczące alokacji/dealokacji zasobów, implementacji funkcji NDIS czy też właściwego zwracania informacji o stanie operacji. Większość jego pracy dostało się do wydań 0.3.6 i 0.3.7 i dotyczyło wszystkich elementów stosu sieci ale Cameron cały czas pracuje nad doskonaleniem funkcjonalności jak i poprawności.

top

Twitter

Ged Murphy ostatnio stworzył publiczną grupę na Twitterze, gdzie zainteresowani deweloperzy mogą aktualizować swoje informacje na temat projektu. Te uaktualnienia będą wysłane normalnie poprzez Twitter i dostarczane każdemu kto obserwuje to konto. Ktokolwiek kto zarejestruje się jako subskrybent tego konta będzie automatycznie powiadamiany. Oznacza to, że informacje będą rozpowszechniane pomiędzy wszystkich zainteresowanych. By wysłać grupowego Tweet'a po prostu wyślij wiadomość do grupy reactos zamiast do @reply, a GroupTweet zajmie się resztą. Możliwe, że w przyszłości tą drogą będą dostarczane informacje z konwentów

top