Community > ReactOS Newsletter Archive > ReactOS Newsletter: Biuletyn 62

Biuletyn 62

byon 2009-07-21
translated by Maciej Bialas on 2009-07-26

Korupcja w PSEH

W systemach operacyjnych z rodziny NT, używa się SEH (structured exception handling) w celu zabezpieczenia poprawności próbkowania buforów pamięci trybu użytkownika oraz pamięci stronicowanej, będąc w trybie kernela. Ta właśnie funkcjonalność skłoniła włoskiego hackera o nicku KJK:Hyperion do stworzenia biblioteki PSEH (pseudo SEH) dla GCC, pozbawione wsparcia SEH. Jako, że ostatnia próba dodania tegoż wsparcia do GCC spaliła na panewce, ReactOS może liczyć jedynie na PSEH. Nie tak dawno, ekipa ARM dodała pewien kod, ujawniający bardzo paskudny błąd w bibliotece PSEH, a zbadanie, którego przyniosło KJK odkrycie jeszcze innego błędu podczas analizy kodu. Oba były poważnej natury i mogły wywołać problemy podczas obsługi wyjątków krytycznych.

Pierwszy z nich związany był z zagnieżdżonymi blokami try/catch, w sytuacji gdy wyjątki pojawiły by się zarówno w bloku zagnieżdżonym, jak i w bloku na zewnątrz zagnieżdżonego – wykonywanie kodu byłoby wówczas przeniesione do wyrażenia catch nie w bloku zewnętrznym lecz w zagnieżdżonym. Kod przeszedłby wówczas ponownie do bloku zewnętrznego i byłby zapętlił się, ponownie przeskakując do wyrażenia catch w bloku zagnieżdżonym. Przyczyną tego błędu był fakt pozostawienia trylevel z zagnieżdżonego bloku na stosie, pomimo, iż wykonanie kodu już ten blok opuściło. To sprawiło, że PSEH dalej uważał iż wykonywany jest kod z bloku zagnieżdżonego. Błąd oczywiście powodował zablokowanie się systemu, co też miało miejsce po dodaniu kodu przez ekipę ARM, gdy ReactOS przychodził automatyczne testy, a jeden z nich był w stanie ów błąd wywołać. Z pomocą Stefana Ginsberga (stefan100), KJK odkrył przyczynę tego pierwszego błędu i automatyczne testowanie ReactOS znów działa poprawnie.

Drugi błąd był podobnej natury. Tym razem na stosie była pozostawiana ramka wykonawcza (execution frame), co z kolei prowadziło do całkowicie losowych problemów. Co gorsze, ten błąd dało się wywołać nawet bez zagnieżdżonych bloków try/catch, więc mimo iż nie powodował on pętli a więc i blokady systemu, to i tak wywoływał korupcję stosu, co z kolei mogło wpłynąć na inne części systemu oraz doprowadzić do trudnych do wykrycia korupcji danych, a miało miejsce za każdym razem gdy w SEH wywoływany był wyjątek. Nikogo nie zdziwiłoby więc, gdyby ten właśnie błąd był przyczyną choć części z licznych losowych problemów i zawieszeń ReactOS. Ironią losu nazwać można fakt, iż identyczny problem występował w pierwszej wersji PSEH, w której jednak został już dawno naprawiony. Pomocny okazał się również zestaw testów PSEH autorstwa KJK, który natychmiast po dodaniu odpowiedniego sprawdzenia poprawności wykazał miejsca występowania tego błędu.

XLATEOBJ

XLATEOBJ to struktura danych, z kilkoma powiązanymi funkcjami, których zadaniem jest translacja kolorów pomiędzy odmiennymi powierzchniami, jak na przykład z bitmapy na format koloru ekranu. Ze względu na częstość używania, taka operacja musi być możliwie najszybsza. Implementacja do tej pory używana w ReactOS wcale taka nie była, chociażby, dlatego, że jedna z powiązanych funkcji wykorzystywała serie warunków IF/ELSE, aby określić sposób przeprowadzenia translacji. Timo Kreuzer zastąpił to wywołaniem zwrotnym, które wykonuje jedynie wymagane operacje, i dodał kilka zoptymalizowanych funkcji dla formatów specjalnych. Kolejną, planowaną zmianą Tima będzie zamiana dynamicznej alokacji XLATEOBJ z puli stronicowania, na alokowaną ze stosu. Taka alokacja ma miejsce przy każdej operacji bitblt.

Zwykle, translacja piksel do piksela ma miejsce przy zmianie formatu kolorów. Używając pędzla wzorcowego, jak sugeruje jego nazwa, w rzeczywistości używany jest określony wzór o niewielkich wymiarach, który zostaje rozprowadzony po wyznaczonej powierzchni. Zanim to nastąpi, wywoływany jest sterownik grafiki, poprzez GDI a za pośrednictwem funkcji DrvRealizeBrush, co umożliwia dostosowanie pędzla wzorcowego na format koloru powierzchni. Ta operacja nazywana jest „Realization”. Jednocześnie, GDI jest w stanie samodzielnie wykonać taką operację na danym pędzlu, w przypadku gdyby sterownik nie udostępniał tej funkcji. ReactOS nie był w stanie tego wcześniej dokonać, ale dzięki Timo implementacja jest już gotowa i zostanie dodana do źródeł o ile tylko okaże się działać poprawnie.

Arwinss

Aleksiej Bragin stworzył niedawno nowe odgałęzienie kodu ReactOS, nazwane ARWINSS, które jak głosi plotka, jest próbą przeprojektowania od podstaw podsystemu Win32. W opublikowanym przez siebie na listach mailu, wymienia on powody, które skłoniły go do tego nieoczekiwanego przedsięwzięcia. Obecną implementację Win32 i prześladujące ją liczne (a niektóre już dość stare) błędy, Aleksiej opisuje jako „frustrujące”. Mimo trwających od dłuższego czasu wysiłków, ciężkiej pracy wielu deweloperów, obecny podsystem Win32 nadal nie spełnia stawianych mu oczekiwań. Sytuacji nie poprawiają tym bardziej liczne prowizoryczne łaty i poprawki a także, mówiąc wprost, niepoprawnie funkcjonujące implementacje, które często wymagają już nie łatania, ale nawet przepisywania od podstaw. Zdaniem Aleksieja, równie dobrze można spróbować zacząć jeszcze raz od podstaw.

W nowym odgałęzieniu znajduje się znaczna część kodu prosto z WINE, zaimportowanego z najnowszej jego wersji. Tym razem jednak pozostawiono także rozplanowanie i większość oryginalnej architektury kodu. Hierarchia wywołań w Windows jest zaskakująco skomplikowana, i większości nie jest w WINE zduplikowana. Aleksiej zatem spróbował uproszczonej i skomasowanej implementacji. Uformował znacząco zmniejszony moduł win32k (zawierający normalnie kod podsystemu Win32 w trybie kernela), ponownie, pożyczając część kodu z WINE, łączącą ten moduł z bibliotekami WINE trybu użytkownika i tak przerobiony, by pasował do architektury NT. Właśnie te zmiany mogą wywołać najwięcej kontrowersji w naszym projekcie. Według Kamila Hornicka, ReactOS w tym odgałęzienia przypomina siebie samego z czasów wersji 0.1.0. Wyświetlany tekst jest zupełnie niesformatowany i nachodzi na siebie a problemy z translacją kolorów sprawiają, że paski tytułowe wyświetlane są na brązowo. Stan ma się znacząco poprawić, gdy więcej elementów trafi na swoje miejsce w tej układance, ale do tego czasu nie należy spodziewać się jakiejkolwiek funkcjonalności.

Na temat nowego podejścia Aleksieja wypowiedzieli się już inni deweloperzy, I jak można było przewidywać, nie wszyscy byli zadowoleni. Timo Kreuzer zwrócił uwagę na potencjalną groźbę spowolnienia (a może nawet i zawieszenia) prac nad istniejącym (i działającym jako tako już) podsystemem Win32. Jest on również zwolennikiem implementacji jak najbardziej zgodnej z oryginalną i duplikującą ją w najdrobniejszych, możliwych szczegółach. Pomimo, że takie podejście wymaga o wiele większego zakresu prac Timo wierzy, iż w rezultacie otrzymamy podsystem o wiele bardziej zgodny z oryginałem, w stopniu niemożliwym do osiągnięcia przez WINE.

Nowa gałąź jest zatem jak dotąd głównie źródłem sporego zamieszania, przynajmniej do czasu wyjaśnienia wszelkich wątpliwości z nią związanych. Z drugiej strony umożliwia ona nowe podejście, pozbawione dotychczasowych problemów czy ograniczeń. Jedynie czas pokaże jaki przyniesie ze sobą pożytek.