Community > ReactOS Newsletter Archive > ReactOS Newsletter: Biuletyn 72

Biuletyn 72

by Z98 on 2010-05-15
translated by Haos on 2010-05-15

Ze względu na wyjazd Z98 nie należy spodziewać się kolejnych wydań Biuletynu wcześniej, niż pod koniec lipca.

Rozmaitości

Kilka tygodni temu, Aleksiej Bragin zwrócił uwagę deweloperów na wciąż rozrastającą się listę regresji. Patrząc na każdy z osobna, żaden nie został uznany za poważny problem, chociaż kilka z nich były bliskie takiego statusu. Czysta ich liczba jednakowoż stanowiła powód do niepokoju i znacząco umacniała negatywny wizerunek systemu. Od tamtego czasu, wspólnym wysiłkiem programistów ReactOS, udało się wiele z nich naprawić i wreszcie liczba regresji zaczęła spadać. Jednocześnie Aleksiej poprosił o wstrzymanie się od wprowadzania zmian lub dodawania funkcjonalności, w stopniu który mógłby w danej chwili liczbę regresji zwiększyć.

Serwery ReactOS przeszły w ostatnich dniach przenosiny i aktualizacje ich systemów, co wywołało przerwy w ich funkcjonowaniu. Aktualizacja PHP do nowej wersji spowodowała nawet nieprawidłowe funkcjonowanie części stron, co na szczęście dało się szybko naprawić. Najwięcej problemów wywołała przeciągająca się w czasie aktualizacja systemu na głównym serwerze, przez co strona www, listy mailingowe i serwer SVN musiały na parę dni w środku tygodnia zostać wyłączone.
Większość prac jest już za nami i możemy cieszyć się większą sprawnością funkcjonowania BuildBota, indeksera Doxygen czy repozytorium obrazów ISO. Wymiernym efektem przenosin jest też możliwość dodania nowej maszyny kompilującej dla BuildBota, co zostanie zrealizowane już w najbliższej przyszłości.

Kolejka wiadomości

Michael Martin zdołał naprawić grupę błędów za pomocą poprawki w systemie obsługi wiadomości. Aplikacje Win32 działają w pętli odbierającej i obsługującej wiadomości, przesłane doń przez system operacyjny w reakcji na działania użytkownika czy zdarzenia systemowe. Wiadomości te są zasadniczo obsługiwane przez obieg wiadomości (message pump), przesyłający je następnie do odpowiadających im procedur w danej aplikacji. Istnieje jeszcze druga grupa wiadomości - niekolejkowane, która jest przesyłana z pominięciem zarówno globalnej, systemowej kolejki wiadomości, jak i kolejki specyficznej dla danego wątku, bezpośrednio do procedur w aplikacji. W ReactOS, do tej pory, wiadomości niekolejkowane były traktowane w zły sposób, przesyłane przez obieg wiadomości, miast bezpośrednio. Dzięki poprawkom Michaela udało się za jednym razem zamknąć sześć błędów.

Uchwyty nieuchwycone

Podczas testowania Adobe Acrobat 6, Timo Kreuzer natknął się na interesujący a zarazem bardzo poważny błąd. Aby zoptymalizować pracę podsystem Win32 będzie próbował ograniczać liczbę kosztownych w sensie wydajności przejść w tryb kernela, poprzez grupowanie poleceń rysowania i przesyłania ich w większej grupie, zamiast dokonywać przejść pojedynczo, dla każdego z nich. Niestety, w kodzie tej procedury grupowania znalazła się niepoprawnie indeksowana tabela wskaźników do regionów GDI. Wartością użytą do indeksowania było bowiem przesunięcie bajtu a nie indeksu. W rezultacie system tracił kontrolę nad grupowanymi regionami i gubił uchwyty im przypisane. To z kolei wywoływało potężny ubytek zasobów systemowych i prowadziło do kraksy systemu spowodowanej innymi nieprawidłowościami w podsystemie Win32. Wykrycie tego problemu samo w sobie było poważnie utrudnione, gdyż ten kod w całości dotyczy trybu użytkownika. Kraksa systemu następuje natomiast wówczas gdy problem wystąpi w kodzie wykonywanym w trybie kernela, tak więc któryś z komponentów w łańcuchu wywołań nie poradził sobie z gubieniem zasobów.

Gdy Timo poradził już sobie z tym błędem, na zawołanie pojawił się następny. Jak system uprzednio gubił uchwyty i w końcu regiony GDI, tak teraz zbyt wcześnie je kasuje. Ponownie błąd ujawnił się w Adobe Acrobat 6 i tym razem uniemożliwił zupełnie korzystanie z tej aplikacji z powodu nieprawidłowego rysowania jej elementów. Pozostaje pytanie, dlaczego tak poważne błędy nie wypłynęły już wcześniej przy innej okazji. Do czasu odkrycia przyczyny i rozwiązania problemu, Timo wyłączył po prostu kod grupowania.

PnP a UniATA

Gdy UNIATA stała się domyślnym sterownikiem dla napędów SATA i PATA, przydarzył się drobny błąd podczas omijania procedury wykrywania kanałów, przy okazji pozbycia się sterownika PCIIDE. Z jego powodu moduł Plug&Play nie był już powiadamiany o obecności tych kanałów, zatem nie mógł załadować dlań sterowników. Jako, że to właśnie kanały łączą dyski twarde z systemem, brak sterowników dla nich oznaczałby zupełny brak możliwości komunikacji z dyskami twardymi. Oznaczał, gdyby tylko moduł PnP w ReactOS pracował poprawnie. Jak na ironię niezgodność stosu pamięci masowych z PnP, spowodowała, iż system po prostu ten fakt ignorował. ReactOS bowiem jak gdyby nic się nie stało, instalował sterownik UNIATA domyślnie, zarówno dla kontrolera dysków jak i kanałów, bez względu czy moduł PnP o to wnosił, czy nie. Cameron Gutman, dostrzegłszy ten problem, naprawił go, chociaż nie przyniosło to żadnych, widocznych efektów. Przejście na sterownie stosem przez PnP w przyszłości będzie jednak już trochę łatwiejsze.