- Spis treści
- Zespół ReactOS
- Forum
- Wiki
- Listy dyskusyjne
- Kanały IRC
- Newslettery
- Blogi
- Najczęstsze pytania
Community > ReactOS Newsletter Archive > ReactOS Newsletter: Biuletyn 73
Biuletyn 73
by Z98 on 2010-06-23
translated by Haos on 2010-06-25
Na początek dobra rada dla wszystkich, pragnąc odbyć podróż przez kawał świata i 6 różnych miast, musisz ostrożnie wyważyć ilość zabranych ubrań w stosunku do ciężaru bagażu, przy uwzględnieniu niechęci własnej do prania ręcznego.
topTimers i powiadomienia
Wiele lat temu, kiedy dołączyłem do tego projektu, jako osoba odpowiedzialna za proces wypuszczania nowych wersji systemu, które to stanowisko właściwie zajmuję po dziś dzień, ekipa natrafiła na dziwny błąd w przeglądarce Firefox. Zarówno otwieranie stron jak i ściąganie pliku działało wyłącznie, gdy użytkownik poruszał myszką. Jim Tabor później już doszedł do wniosku, iż odpowiada za to implementacja timers w ReactOS, a co za tym idzie, że rozwiązanie tego problemu wcale nie będzie łatwe. Przygotowania niezbędnych partii kodu w tym przypadku (Jim zajmował się równolegle innymi problemami) zajęło całe lata a ostatnie, wieńczące dzieło poprawki dodał Michael Martin.
Poprzednio, jedynym przypadkiem, w którym system sprawdzałby wygaśnięcie timera Win32k, było odebranie przez aplikację wiadomości, z kolejki wiadomości. Te wiadomości to nic innego jak powiadomienia, które system operacyjny wysyła do aplikacji, by te zareagowały na określone zdarzenia: na przykład kliknięcie bądź ruch myszą. Zatem, jeśli takie wiadomości nie dotrą do aplikacji, system nie będzie sprawdzał czy timer już wygasł. Firefox ujawnił ten błąd głównie ze względu na swój sprytny mechanizm: zamiast ciągłego sprawdzania stanu, w bardzo krótkich odstępach czasu, przeglądarka była usypiana na czas określony timerem. Jim rozwiązał ten problem przy pomocy timera w kernelu, którego wygaśnięcie wymusza teraz sprawdzenie przez system czy istniejące timery Win32k nie wygasły.
topKonsole i niebieski ekran
Niewielu zdaje sobie sprawę z tego, że konsola, w Windows, może używać naraz więcej niż jednego bufora ekranowego, jednak niewiele aplikacji potrafi z tego skorzystać. W podobny sposób jak na systemach z rodziny UNIX, aplikacja może wczytać zawartość pliku do nowego bufora, a po zakończeniu pracy wrócić do miejsca, z którego została uruchomiona. W ReactOS jednak, konsole i bufory ekranowe były rejestrowane osobno a nic nie łączyło nieaktywnego bufora ekranowego z jego macierzystą konsolą. W tej, dziwnej zresztą sytuacji korzystanie z wielu buforów ekranowych przez jedną konsolę/aplikację nie miało żadnego sensu, nie mówiąc nawet o przełączaniu między nimi. Co gorsze, w przypadku zamknięcia konsoli przy użyciu funkcji FreeConsole utworzone dlań bufory ekranowe nie były czyszczone, więc nowa konsola, uruchomiona przez funkcję AllocConsole mogła zostać do nich podłączona. Poza oczywistym wyciekiem zasobów było to również zagrożenie dla bezpieczeństwa systemu, gdyby zostało użyte z dostateczną wyobraźnią.
Jeffrey Morlan zmienił gruntownie sposób zarządzania buforami, implementując wspólną listę dla obiektów konsolowych, dzięki której można śledzić bufory im przypisane. Dodał też odniesienia w samych buforach, przypisujące je do określonych konsol źródłowych. Dzięki tym zmianom, funkcja FreeConsole może teraz odszukać bufory przypisane do zamykanej konsoli i wyczyścić je. Przy okazji prac nad tym problemem Jeffrey odkrył też błąd w samym systemie Windows, gdzie po skasowaniu ostatniego bufora we wciąż aktywnej konsoli i zmuszeniu jej do przełączenia się na nieistniejący już bufor w efekcie powoduje kraksę systemu i BSOD. Tego zachowania Jeffrey jednak nie ma zamiaru implementować, zadowalając się w zupełności tym, że w konsola, aż do jej zamknięcia ma posiadać przynajmniej jeden poprawny bufor.
topZarządzanie gniazdami
W ostatnim miesiącu Cameron Gutman powrócił do prac nad stosem sieci. Jednym z egregrious błędów, na jaki się natknął, dotyczył sposobu zarządzania danymi o gniazdach przez msafd. Do tej pory dane te były przechowywane w statycznej tabeli o wielkości 1024 elementów, co gwarantowało błąd przepełnienia bufora w chwili, gdy jakakolwiek aplikacja otworzyłaby więcej niż 1024 gniazd. Co gorsze struktura, w której przechowywane były informacje o gniazdach, nie była czyszczona nawet, gdy aplikacja otwierająca te gniazda była już zamknięta. Oba te problemy stanowiły istotną przeszkodę dla wielu aplikacji sieciowych.
Zamiast statycznej tabeli, Cameron poprawnie użył listy łączonej, umożliwiającej dynamiczny rozrost struktury w miarę przybywania elementów. Przy rozsądnym założeniu, iż najczęściej używane są gniazda najnowsze, nowe wpisy dodawane są zawsze na początku listy. Czy to założenie okaże się prawdziwe podczas normalnego użytkowania? W teorii, przynajmniej, nie powinno zmniejszyć wydajności system.
topARWINSS – raz na wozie, raz pod podwoziem
ARWINSS w ostatnim miesiącu zaliczył trzy istotne wydarzenia, które ujawniły wzrastający stopień komplikacji, wynikły z tak dużych zależności od WINE. Pierwszy z nich dotyczył wysiłku, jaki podjął WINE w celu oczyszczenia implementacji ikon kursora z zaległych fragmentów 16 bitowej implementacji i zwiększenia jego ogólnej kompatybilności. W tym miejscu należy wspomnieć, że WINE powstał, jako projekt sklonowania WINDOWS API jeszcze w wersji 16 bitowej, przez co do tej pory w jego kodzie widać fragmenty tej przeszłości. Gdy Aleksiej wraz ze współpracownikami zsynchronizowali ARWINSS z ostatnimi zmianami WINE, kursor w efekcie zmienił się w czarny kwadrat. Co ciekawe, przesunięcie takiego kursora nad granicą okna zmieniało go na zupełnie normalny, w wersji dla zmiany rozmiaru okna. Dzięki pomocy Giannisa Adampulosa, Aleksiej doszedł do wniosku, iż jest to błąd po stronie WINE, wywołany przez uprzednie zajęcie bitmapy kursora przez inne urządzenie, w tegoż urządzenia kontekście. Ten błąd uniemożliwiał duplikację bitmap wszystkich kursorów, poza tym do zmiany rozmiaru okna. Aleksiej zorientował się, iż podobny problem wystąpił jeszcze w innej części WINE, ale tam został już tam rozwiązany. Pozostało mu jedynie zastosować taką samą łatkę w funkcji GetIconInfo i wysłać ją do projektu źródłowego. Nadal jednak nie wiadomo, dlaczego kontekst innego urządzenia przejmował ikony kursorów, może to, bowiem świadczyć o wycieku zasobów.
Drugi z listy dotyczył rozbudowy ograniczonego w WINE wsparcia powłoki. Większość użytkowników WINE radzi sobie bez tego, ograniczając się wyłącznie do samych aplikacji Win32. Wersja rozwojowa drzewa posiada pewną funkcjonalność w tym zakresie, lecz w projekcie brakuje większego zainteresowania tą dziedziną. Istotnym brakiem w niej jest na przykład brak wsparcia dla tzw. hooks w powłoce, przez co na przykład uruchamiane z niej aplikacje nie pojawiają się na pasku zadań. Obecna powłoka w ReactOS miała ten sam problem, który udało się obejść poprzez sprawdzanie listy procesów pod kątem posiadania przez nie widocznych okien, dodawania i kasowania takowych. Poprawnym rozwiązaniem byłaby implementacja powiadomień z hooks powłoki przy starcie i zamknięciu aplikacji. Tego zadania podjął się Maarten Kroese, który nie jest jeszcze członkiem ekipy ReactOS, lecz na najlepszej drodze do tego. Po zaimplementowaniu i wysłaniu kodu do WINE, ta funkcjonalność z pewnością trafi też do ARWINSS.
Ostatnie wydarzenie związane jest z paskudnym błędem, trapiącym testerów ARWINSS. Jeśli po uruchomieniu aplikacji, użytkownik kliknie na pulpit, wówczas wszystkie otwarte do tej pory aplikacje znikają, mimo, że z technicznego punktu widzenia są nadal uruchomione i działają. Przyczyną nie jest jak się z początku wydawało, minimalizowanie okien aplikacji, lecz przeciwnie, przestawienie pulpitu na samą górę. Szybka łatka, nad którą pracuje Giannis spowoduje, że menedżer okien ARWINSS będzie ignorować wszelkie polecenia przestawienia pulpitu na najwyższą widoczną warstwę. Nie rozwiąże to w żadnej mierze przyczyny problemu, zbadanie, której na pewno zajmie sporo czasu i wysiłku, ale znacznie poprawi wrażenia użytkowe ARWINSS.
topWięcej starego niż nowego
Amine Khaldi to już stary weteran ekipy ReactOS, sprawujący się dotąd wyśmienicie, jako opiekun bugzilli, dręczący od dawna deweloperów otwartymi błędami czy nadesłanymi poprawkami. Od pewnego czasu przemienił się sam w developera, pracując nad plikami nagłówkowymi w ReactOS, co w żadnej mierze nie wyczerpało jego ambicji czy też zainteresowań, liczymy na jeszcze więcej. Jérôme Gardou z drugiej strony, to całkiem nowy nabytek, który jednakże pokazał sie z bardzo dobrej strony podczas współpracy z Timo nad gałęzią YAROTOWS (Yet Another Rewrite Of The Old Windows Subsystem). Zainteresowani tym podprojektem winni koniecznie zapoznać się z następnym wydaniem biuletynu, gdzie poświęcony mu będzie osobny rozdział. Na razie musi wystarczyć wam informacja, iż jest to próba przepisania istotnej części Win32, która ze sporej łatki zamieniła się w bardzo kompleksowy zestaw zmian, potencjalnie atrakcyjny dla użytkowników.
top
