Community > ReactOS Newsletter Archive > ReactOS Newsletter: Biuletyn 67

Biuletyn 67

by Z98 on 2009-12-09
translated by Haos on 2009-12-20

Debugowanie

O wsparciu WinDBG wspominaliśmy ostatnio prawie rok temu. Pierwszym krokiem na tej drodze było stworzenie kernela, kompatybilnego z WinDBG, co udało się osiągnąć ponad dwa lata temu, przepisując kernel prawie od podstaw. Do wymaganych funkcjonalności możemy zaliczyć chociażby wykonywanie kontekstu danego wątku czy też odczyt pamięci wirtualnej. Mimo, że nowy kernel otworzył drogę do WinDBG, liczne błędy nadal uniemożliwiały użycie tego narzędzia. Debugowanie wymaga przerywania wykonywanego wątku w określonym momencie a później jego wznowienia - w tym samym miejscu, w którym zostało przerwane. Jeden z istotnych błędów uszkadzał treść kontekstu wykonywania wątku (czyli zestawu informacji o tym co, w jakiej sytuacji i z jakim poziomem bezpieczeństwa wywołało dany wątek) i w rezultacie powodował awaryjne zamknięcie debugowanej aplikacji, bądź zawieszenie systemu. Innym, jeszcze bardziej skomplikowanym problemem, były próby mapowania przez HAL pierwszej rzeczywistej strony pamięci przy użyciu menedżera pamięci. Próby te kończyły się niepowodzeniem, jako że odpowiedzialna za to funkcja w menedżerze pamięci próbowała dodatkowej synchronizacji, a taka nie mogła się udać, gdy HAL działał w kontekście debugowania. W tymże kontekście bowiem nie dość, że żadne synchronizacje nie są już potrzebne, to istnieje ryzyko, ze wspomniane synchronizowane blokady są już ustawione przez inny komponent. Próba synchronizacji w takim scenariuszu skończyłaby się kompletną blokadą systemu. Dzięki naprawie tych i wielu innych błędów, Stefanowi udało się podłączyć do kernela ReactOS przy użyciu WinDBG i wykonać takie operacje jak ustawianie i usuwanie breakpointów czy odczyt pamięci. By to osiągnąć, Stefan musiał użyć biblioteki KDCOM z Windows 2003.

W tym czasie KDCOM ReactOSa nie funkcjonował na tyle poprawnie by można go było użyć. Pomimo wysiłków Timo, nie dało się również stwierdzić, czy wina leżała wyłącznie po stronie KDCOM, czy też gdzieś na styku KDCOM<>Kernel. Gdy Stefan zainteresował się wsparciem dla WinDBG i również dzięki jego poprawkom w kernelu, Timo wznowił prace nad KDCOM w gałęzi ReactOS x64. Mimo początkowych sukcesów, istotnym problemem były delikatne różnice synchronizacji czasu, powodujące błędy wyświetlanych treści jak i gubienie całych pakietów, szczególnie tych o dużym rozmiarze. Timo rozwiązał je za pomocą dodatkowych warunków i rygorystycznej kontroli błędów. Jednym z dziwniejszych problemów był związany z synchronizacją czasu błąd, który przy próbie zapisu do portu szeregowego powodował zwrot informacji o niepowodzeniu, ze wskazaniem na brak gotowości portu do przesyłania danych, mimo, iż sprawdzenie stanu portu w tym samym czasie dawało informacje o jego pełnej gotowości. Timo zastosował najprostsze rozwiązanie, w postaci dodatkowego opóźnienia, które mimo iż naprawia problem, to dalekie jest od ideału. Za odrębną grupę problemów odpowiedzialna była użytkowana przez Timo platforma - VirtualBox, mająca długą historię niestabilnej i niepoprawnej obsługi wirtualnych portów szeregowych. Już samo uzyskanie poprawnego zapisu logowania jest dla wielu osób, związanych z naszym projektem, drogą przez mękę - pomimo stosowania egzotycznych rozwiązań, takich jak com0com, normalnością są dziury w zwracanych logach, często z brakującymi całymi liniami tekstu. Zdaje się, iż ekipa projektu VirtualBox planuje zastąpienie obecnej implementacji portów szeregowych zupełnie nową, która miejmy nadzieję rozwiąże nasze problemy i pozwoli na izolację błędów KDCOM czy naszego kernela przy pracy z WinDBG.

Powłoka

Powłoka, na której użytkownik pracuje w systemie, tak na prawdę składa się z licznych, powiązanych ze sobą komponentów, co sprawia, że jakiekolwiek prace przy nich dalekie są od trywialności. Poza powłoką samego explorera, mamy takie biblioteki jak shell32, browseui, comctl32 i shlwapi, by wymienić jedynie najistotniejsze. W ReactOS, odmiennie, wiele z funkcjonalności tychże bibliotek, wciśnięte zostało na siłę do samego explorera, jako że owe biblioteki po prostu nie istniały. Wszystko to spowodowane jest dziedzictwem explorera, wywodzącego się z projektu WINE i faktu, iż WINE jako taki nie potrzebował osobnej implementacji shell32. Spójrzmy dla przykładu na Menu Start jako takie. W Windows nie jest ono zaimplementowane w explorerze, a jedynie wywoływane przezeń, tak samo menu System. Tradycyjnie już w Windows, menu są zarządzane przez bibliotekę user32 a z tej zasady wyłamuje się jedynie kilka z nich, dość specyficznych. Poza explorerem, jedynie garść aplikacji będzie z nich korzystać, więc ich brak ma szanse pozostać niezauważony. Próba użycia jednakowoż innej powłoki niż explorer od razu ujawni braki w funkcjonalności.

Andrew Hill spędził ostatnie kilka miesięcy badając powłokę w systemie Windows i próbując oszacować braki w ReactOS. Udało mu się skompilować w Visual Studio i uruchomić na Windows XP wiele wyżej wymienionych bibliotek, jak również i explorer_new - następcę obecnej powłoki ReactOS. Dzięki temu był w stanie zlokalizować z dużą dokładnością różnice i braki w funkcjonalności, jak również i ich domyślną lokalizację w systemie Windows. Najciekawszym przypadkiem byłoby właśnie Menu Start, jedno z tych specyficznych menu, niezlokalizowanych w user32. Obecnym celem Andrew jest sprawienie, by explorer_new wyglądał i działał identycznie, jak własna powłoka XP a następnie przeniesienie koniecznych zmian i nowych funkcjonalności do kodu ReactOS.

Nowi Deweloperzy

Jednym z nowoprzybyłych do naszego projektu jest Andrew Hill, o którym mowa w tekście powyżej, a który współpracuje już z projektem od kilku miesięcy, lecz w czasie wstępnych badań nad zagadnieniami powłoki wolał pozostać w cieniu. Od początku współpracował blisko z Gedem Murphy i od niedawna zaczął dodawać do drzewa kodu efekty swoich wielomiesięcznych wysiłków. Jego pseudonim na ircu to ash77 (aczkolwiek proszę nie oczekiwać jego częstej obecności, nawet pomimo braku dopisku |afk przy pseudonimie.

Kolejnym nowym deweloperem, który właśnie co dołączył do ekipy, jest Giannis Adamopoulos, znany na IRCu jako smiley_, gdzie towarzyszył nam już od dość dawna. Obszarem jego zainteresowania jest podsystem Win32 po stronie kernela, w którym postara się zaimplementować brakujące funkcjonalności.

Ten przypływ świeżej krwi z pewnością zwiększy tempo prac nad projektem, lecz musicie być świadomi ogromu prac jaki pozostaje przed nami, a z którym z najmilszą chęcią oczekiwać będziemy waszej pomocy. Znajdujemy się obecnie na etapie, w którym prócz przepisywania obecnych, często błędnych z samych założeń, komponentów, będziemy wreszcie mogli zająć się dodawaniem nowych funkcjonalności. To z kolei zwiększy jeszcze kompatybilność ReactOS zarówno ze sprzętem jak i oprogramowaniem, ale pracować możemy jedynie tak szybko, jak pozwolą nam na to nasze ograniczone zasoby. Miejmy nadzieję, iż przypływ nowych programistów do projektu nie wyschnie, a przeciwnie - zmieni się w potok w miarę jak projekt będzie dojrzewał.