News #48: Przegląd Całoroczny

2009-01-16, Z98
Przegląd Całoroczny
translated by Adam Stachowicz on 2010-07-19
Spojrzenie na 2008

Przegląd Całoroczny

2008 odnotował w sumie cztery odsłony serii, wydane przez projekt ReactOS, z czego wszystkie powstały po zakończeniu przepisywania rdzenia. Na skutek tego niestabilności, których ludzie byli świadkami w wersji 0.3.1, zostały znacząco zredukowane. Odnotowano także częstsze sukcesy w uruchomieniu ROSa na rzeczywistym sprzęcie, a nie tylko maszynach wirtualnych. Nie oznacza to że system działa sprawnie, ale bliżej nam do celu. Liczba wydań jest z pewnością większa niż w poprzednich latach, gdyż projekt stał przez pewien czas w miejscu za sprawą niestabilności w rdzeniu.

Jak wielu było świadkiem, 2008 był dla nas pracowity, z ciągłym postępem w rozwoju i stawianiem fundamentów pod nowe przedsięwzięcia, które mamy nadzieję zaowocują w przyszłości. W dodatku prace rozpoczęte lata temu również zaczynają przynosić rezultat, zwiększając funkcjonalność i stabilność ReactOSa. Przypomnimy tu pewne osiągnięcia i starania, które mogą zainteresować naszą społeczność.

Stara i Nowa Krew

Całkiem sporo osób dołączyło do projektu tego roku jako programiści. Wielu z nich jest w społeczności od dłuższego czasu, a co najmniej jedna osoba wróciła po przerwie. Łącznie 10 nowych osób i jedna wracająca znacznie wsparły teraz prace. Pierwsza para przyszła do nas na początku roku, Andrey Korotaev i Dmitry Chapyshev. Wrócił wtedy też do nas Steven Edwards, na pewien czas nasz łącznik z Wine. Za nim podążył Matthias Kupfer, weteran w społeczności, a także Jeffrey Morlan, który usłyszał o projekcie całkiem niedawno zanim został deweloperem. Następnie dołączył Stefan Ginsberg, przez pewien czas wyróżniając się jako najmłodszy deweloper ReactOS. To wyróżnienie przeszło później na Camerona Gutmana, kolejnego forumowicza który w końcu wszedł na IRC by porozumieć się bezpośrednio z deweloperami po czym otrzymał dostęp do SVN. W tym czasie Samuel Serapion, teoretycznie inny autor newslettera, również dostał pełny dostęp. Od tamtej pory ma jeszcze napisać owego newslettera. Ostatnimi trzema byli Michael Martin, Gregor Schneider i Kamil Hornicek, z czego wszyscy dołączyli w przeciągu miesiąca. Z dodatkową siłą roboczą przyszłość ROSa z pewnością wygląda obiecująco.

Grafika

Odkąd rdzeń niejako się ustabilizował, uwagę przeniesiono na podsystem graficzny. Kod jest dość stary i zawiera masę hacków, ale naprawienie go jest kluczem do uruchomienia większej ilości aplikacji. W tym celu kilku deweloperów rozpoczęło w zasadzie przepisanie Podsystemu Win32. Głównym celem jest zrobienie porządku w implementacji, wewnętrznej architekturze i strukturach danych, z których część nie istnieje w implementacji Windows. Nie jest to dopuszczalne jeśli na prawdę chcemy być kompatybilni, w związku z czym Timo Kreuzer zaczął je rozdzielać. Niektóre ze struktur danych to właściwie kombinacje lub połączenia już istniejących. Timo zdołał wyciągnąć już jedną specyficzną dla ROSa strukturę i zastąpić kod który z niej korzysta poprawną implementacją, jednak dużo więcej nadal istnieje i to w wielu różnych miejscach. By faktycznie zastąpić je wszystkie potrzeba trochę czasu, szczególnie gdy kod wyewoluował by teraz na tych błędnych strukturach danych się opierać.

Innym problemem wewnętrznym któremu w tym roku poświęcono dużo uwagi są wzajemne zależności wewnątrz podsystemu Win32. Ponieważ prace nad nim rozpoczęto zanim znaczna część informacji na jego temat była dostępna publicznie, dokonano pewnych założeń co do tego w jaki sposób są ze sobą związane. W rezultacie skończyło się na kołowych zależnościach, gdzie każdy moduł był zależny od innego, zamiast ustalonego podziału na warstwy z góry do dołu. Eric Kohl poświęcił sporo czasu próbując to rozwiązać, a jednym z jego sukcesów była naprawa CSRSS by nie używał shell32 podczas swojej inicjalizacji, komponentu który przy starcie CSRSS nie był nawet załadowany. Niestety nie rozwiązuje to wszystkich problemów współzależności, ale Jim prowadzi dalsze poszukiwania.

Trzecią sprawą architektoniczną związaną z Podsystemem Win32 jest implementacja ReactX, naszego zastępcy DirectX. Magnus Olsen w ciągu roku zdał sobie sprawę, że te starania potrwają znacznie dłużej niż myślał, szczególnie wsparcie renderowania 3D przyspieszanego sprzętowo. W związku z tym podjęto dwa rozwiązania. Pierwsze wymagało użycia kodu Wine, który tłumaczy wywołania Direct3D do ich zbliżonych odpowiedników OpenGL, by robił to samo na ReactOS. Wspieramy przyspieszenie sprzętowe dla OpenGL, więc ten trik może pomóc zwiększyć wydajność. Mimo to Magnus nadal zamierza dokonać poprawnej implementacji, której nie trzeba kierować przez OpenGL. Drugim rozwiązaniem było usprawnienie podsystemu Win32 do tego stopnia, by oficjalny komponent DirectX Microsoftu mógł działać również na ReactOS. Wymagałoby to naprawy wewnętrznych struktur na których polega DirectX i zrobienia ich identycznymi z tymi w Windows. Prace nad uruchomieniem komponentu DirectX Microsoftu na ReactOS rozpoczęły się już w 2004 i zaczynają pokazywać widoczne oznaki postępu. Sterownik DirectX ładuje się a proste renderowanie 2D z przyspieszeniem sprzętowym działa, jednakże 3D zajmie znacznie więcej czasu. Dzieło to jest efektem wspólnych starań Magnusa Olsena, Timo Kreuzera, Jima Tabora, Maartena Bosma i Aleksa Ionescu, a niedawno dołączył do nich Kamil Hornicek. Oczywiście wiele jest jeszcze do zrobienia, ale jesteśmy na etapie gdzie postęp jest widoczny, nie tylko wewnętrzny.

Na koniec warto wspomnieć, że razem z poważnymi pracami nad infrastrukturą prowadziliśmy też solidne odpluskwianie. Renderowanie prostej grafiki w ciągu roku znacząco się poprawiło, dzięki czemu więcej aplikacji jest teraz zdatnych do użytku za sprawą poprawnego wyświetlania. Po części jest to zasługa aktualizacji kodu który czerpiemy z Wine, ale również i pracy naszych deweloperów. Nie był to mały wyczyn, ponieważ naprawianie problemów architektonicznych w podsystemie Win32 rozplotło hacki użyte w celu prawidłowego rysowania, zatem deweloperzy Win32 musieli naprawić zarówno długotrwałe problemy jak i hacki które rozleciały się za sprawą poprawniejszej implementacji.

Systemy plików i Pamięć

Prace nad tymi dwoma komponentami przebiegały równocześnie, gdyż sterowniki systemu plików polegają w dużej mierze na usługach menadżera pamięci. Wypełnianie luk które uniemożliwiają nam użycie systemu plików innego niż FAT32 rozpoczęto tak naprawdę w 2008. Dwoma największymi blokerami są tu: niezwykle niekompletna Biblioteka Systemu plików oraz niezmiernie niepoprawna implementacja Wspólnego Cache’u (ang. Common Cache).

Problem ze Wspólnym Cache był znany od jakiegoś już czasu, z wieloma próbami przepisania podjętymi w przeszłości. Tak naprawdę sam CC nie jest odrębnym komponentem, ale zwyczajnie eksponuje funkcjonalność Menadżera Pamięci. Dla nas znaczy to, że aby mieć prawidłowy CC musimy mieć porządny MM (ang. skrót od Memory Manager). Niestety, nie w tym wypadku. CC i MM w zamierzeniu mają mieć pewien stopień abstrakcji, ale nasza implementacja właściwie je wymieszała. W związku z tym, pierwszym krokiem było wydzielenie ich, co na celu miała inicjatywa NoCc rozpoczęta przez Alekseya Bragina, następnie podjęta przez Arta Yerkesa. Aleksey zamierzał dla NoCc rozebrać funkcjonalność jaką udostępniał CC, abyśmy mogli skupić się najpierw na naprawianiu podstawowych operacji pamięciowych, przed próbą wyjaśnienia co CC powinien robić. Gdy byliśmy pewni, że menadżer pamięci funkcjonuje prawidłowo, mogliśmy spróbować zaimplementować algorytmy cache’ujące dla CC. Art zdołał oba rozdzielić, eliminując współdzielone struktury danych które nigdy nie powinny istnieć. Zaimplementował wtedy prosty najmniej ostatnio użyty algorytm cache’ujący i udało mu się skłonić ReactOSa do rozruchu po same GUI zanim uległ awarii. Zważywszy, że CC praktycznie nie istniał zanim rozpoczęto te prace, osiągnęliśmy wiele, jednak dużo więcej trzeba będzie zrobić tego roku.

Innym komponentem na którym bardzo polegają sterowniki systemu plików jest biblioteka systemu plików (ang. filesystem runtime library). Wiele z FsRtl właściwie nie istniało, gdyż FAT32 był na tyle prosty, że dał się zhakować do działania praktycznie bez tego. Pierre Schweitzer początkowo dołączył by pomóc przy Środowisku Konstrukcyjnym ReactOS (ang. ReactOS Build Environment), ale przeniósł się do prac nad FsRtl w 2008. Wykonał sporo pracy w swojej własnej gałęzi (ang. branch), implementując zarówno brakującą funkcjonalność wewnątrz FsRtl jak i usługi w innych komponentach na których opiera się FsRtl. Jest to kolejna inicjatywa która trochę potrwa zanim się ułoży, ale gdy to się stanie, będziemy mogli rozpocząć poważniejsze prace nad wsparciem nowszych systemów plików.

Porty

W 2008 rozpoczęto dwie próby przeniesienia ReactOSa na inne architektury, x64 i ARM. Obie odnotowały znaczny postęp, z portem ARM na etapie w którym rozpoczęto prace nad inicjalizacją komponentów trybu użytkownika w procesie rozruchu. Port x64 idzie wolniej ale również notuje częściowy rozruch. Oba starania w rezultacie ujawniły wiele błędów w menadżerze pamięci, z czego korzyści czerpie również platforma x86. Spora część prac x64 nie została w pełni wdrożona do trunka, podczas gdy efekty ARM mają tam już miejsce. Mimo wszystko prace jakie wykonano do tej pory oferują solidne fundamenty dla dalszego rozwoju, a pomyślny port stworzy nowe możliwości dla ReactOSa.

Infrastruktura

Zrobiono całkiem sporo by pomóc zwiększyć produktywność deweloperów w ciągu ostatniego roku. Poza przeniesieniem i unowocześnieniem serwera, projekt rozpoczął pracę nad automatycznym systemem testującym dla każdej rewizji. Pierwszym krokiem tego procesu było ukończenie programu Sysreg przez Johannesa Anderwalda i Christopha von Witticha. Działając teraz na maszynach konstrukcyjnych, Sysreg uruchamia obecnie wyłącznie Winetesty i kończy przy pierwszym niepowodzeniu lub awarii systemu. W zamierzeniu ma on uruchamiać wszystkie testy modułu Rostests i zakończyć je niezależnie od niepowodzeń. Raport jaki Sysreg obecnie generuje jest bardzo rozwlekły i Colin Finck oraz inni członkowie społeczności pracowali nad udostępnieniem lepszego, sieciowego interfejsu. Miejmy nadzieję, że zobaczymy owoce tych prac tego roku.

Kolejnym ważnym dodatkiem były uaktualnione strony doxygen dla kodu źródłowego ReactOS. Błąd we wcześniejszych wersjach doxygen powodował nieskończoną pętlę w naszym kodzie, więc nikt nie trudził się, by generować dokumentację dla nowszych rewizji.. Oznaczało to, że dokumentacja która istniała była beznadziejnie nieaktualna dla każdego kto chciał z niej skorzystać. Teraz, gdy system działa, możemy również korzystać z innych możliwości doxygen w celu śledzenia postępu rozwoju i dostarczania lepszych materiałów źródłowych dla ludzi chcących studiować kod źródłowy.

Bugzilla również odnotowała parę ulepszeń. Dzięki nowemu artykułowi na wiki nt. debugowania, zgłaszający błędy mogą teraz dostarczać użyteczne informacje i logi, tym samym podnosząc jakość samych zgłoszeń. Bugzilla odnotowała też większe porządki i ulepszoną konserwację, od śledzenia i oznaczania rozwiązanych problemów, do usuwania duplikatów raportów i zajmowania się zgłoszonymi poprawkami w celu szybszego przeglądu przez deweloperów.

Skanowanie Coverity

Zostaliśmy skontaktowani z Coverity przez Uriasa McCullougha, członka społeczności Haiku, po czym wysłaliśmy nasz kod źródłowy do analizy. Stając się jednym z projektów open source które Coverity analizuje będzie dla nas dużym pożytkiem w dłuższej perspektywie, pomagając nam uniknąć pewnych rodzajów błędów i oferując ogólną ocenę jakości.

Kompilatory

Jednym z największych problemów z jakimi projekt musiał się uporać używając GCC jako głównego kompilatora jest brak wsparcia dla Złożonej Obsługi Wyjątków (ang. Structured Exception Handling). KJK::Hyperion stworzył bibliotekę PSEH aby to zrównoważyć, a pod koniec zeszłego roku zmodernizował ją do wersji 2.0. Ma ona wciąż pewne trudności nad którymi KJK pracuje, ale dzięki niej będziemy o krok bliżej od korzystania ze schematu obsługi wyjątków który jest kodowo identyczny zarówno dla GCC jak i MSVC. Będzie to bardzo przydatne, gdyż KJK podjął również starania mające umożliwić kompilację ReactOSa na MSVC, kompilatorze Microsoftu. Obie te cechy razem powinny pomóc nam znacząco podnieść jakość kodu w trakcie swojego rozwoju.

Pomysły Finansowane przez Społeczność

Proponowano to już wcześniej wielokrotnie, ale dopiero w połowie 2008 podjęto gruntowne starania by to zorganizować. CFI (ang. skrót tego przedsięwzięcia – dop. tłum.) ma na celu umożliwić członkom społeczności dokonanie darowizny na wybrany przez nich z listy aspekt projektu, którego ukończenia oczekują. W zamierzeniu ma to zapewnić deweloperom potrzebne fundusze, tak by mogli poświęcić swój czas wymagany do zrealizowania danego zamierzenia bez obaw o zobowiązania finansowe w życiu prywatnym. Kilka projektów otrzymało już skromną liczbę datków i mamy nadzieję, że CFI jako całość okaże się sukcesem w przyszłości. Inicjatywa ta nadal podlega pewnym zmianom w planowaniu i organizacji, ale deweloperzy podjęli już wstępne prace nad niektórymi z proponowanych projektów.

News Archive