Community > ReactOS Newsletter Archive > ReactOS Newsletter: Newsletter 56

Newsletter 56

by Z98 on 2009-04-09
translated by Haos on 2010-08-08

Tłumaczenie: Caemyr

USB

Obsługa USB ma w ReactOS pokręconą historię. Pierwszą próbą była adaptacja stosu Cromwell USB z Linuksa, która to zajęła Aleksiejowi Braginowi dość dużo czasu, a w końcu została porzucona. Następcą i bezpośrednim sprawcą tegoż porzucenia był inny projekt, pewnego programisty z Chin, który usiłował stworzyć stos USB zgodny z NT4. Tenże stos był jednak mocno niekompletny i zawierał liczne błędy, a co gorsze, sam projekt został zarzucony przez autora. Po długich pracach nad poprawkami udało się Aleksiejowi doprowadzić go do jako takiego stanu, dającego systemowi ReactOS podstawowe wsparcie USB tyle, że bardzo kapryśne co do sprzętu i zawodne. Sterownik myszki USB został bowiem prowizorycznie dostosowany do współpracy z tymże stosem, co wcale nie poprawiło niezawodności, wręcz przeciwnie. Ostatnimi czasy Aleksiej postanowił zastosować podobną strategię co do sterownika klawiatury USB, celem uzyskania równie podstawowej funkcjonalności. Po początkowym sukcesie, ruszył krok dalej, próbując wprowadzić sterowanie diodami LED na swojej klawiaturze, co z kolei wymagało bardziej skomplikowanej funkcjonalności stosu, niż proste przesyłanie danych o naciśniętych klawiszach, czy ruchach myszki. To wówczas udało mu się dostrzec, iż sterownik USB nieprawidłowo przetwarza dane konfiguracji, przesyłane przez urządzenie. Po konsultacji z jednym z deweloperów – specjalistów od USB w projekcie Haiku, był w stanie ów błąd naprawić. Zupełnie przypadkowo, umożliwiło to również powrót do poprawnej, oryginalnej wersji sterownika myszki USB. Sterowniki USB jako takie, opierają się o standardowe sterowniki klawiatury i myszki, co oznacza że te muszą zostać załadowane przez system przed sterownikami USB. Wsparcie dla urządzeń USB w standardowych sterownikach istniało już od pewnego czasu, dzięki pracy Hervé Poussineau. Aleksie po prostu poskładał bardzo różniące się od siebie elementy w jeden, działający jako tako system.

Pomimo, iż ReactOS posiada już sterowniki USB zarówno do klawiatury jak i myszki, należy nadmienić, że są one nada dalekie od tych, zawartych w systemach Windows. USB w NT5 i nowszych jest zorganizowane w dwa stosy – PnP i HID (Human Interface Device – przyp. tłum). Nim pokusimy się o zaimplementowanie sterowników USB, kompatybilnych z NT5+, musimy wpierw stworzyć stos USB, który odpowiadałby architekturze stosów USB w NT5+. Tylko wówczas moglibyśmy liczyć na kompatybilność ze sterownikami USB innych firm do swoich urządzeń, chociaż podstawową funkcjonalność teoretycznie można by uzyskać nawet przy obecnym stosie USB.

Sieć

Art Yerkes i Cameron Gutman od dłuższego czasu wkładają wiele pracy w doprowadzenie stosu sieci do poprawnego stanu, a także starają się uzupełniać brakujące funkcje. Jednym z istotnych problemów były problemy z dostępem do stron, oczekujących połączenia przez SSL, które to na ReactOS wywoływało korupcję pamięci. Szereg adresów IP jest utrzymywany i wykorzystywany przez dwie funkcje: AfdGetPeerName i AfdGetSockName. Art uważa, iż strony wykorzystujące SSL, mogą odwoływać się do obydwu funkcji wielokrotnie, w celu weryfikacji poprawności certyfikatu, i właśnie te odwołania wywołują błędy. Naprawienie tegoż umożliwia obecnie wczytywanie się takich stron jak logowanie do Gmail, czy też działanie aplikacji opierających o SSL zabezpieczenia, jak na przykład Thunderbird.

Art i Cameron, pracując nad stosem sieci, stoją przed innymi problemami, niż reszta zespołu ReactOS. Interfejs sieciowy znany jest ze swojej przekomplikowanej konstrukcji, z licznymi strukturami o bardzo zbliżonych nazwach i funkcjonalności. Mamy więc dla przykładu TDI_ADDRESS_INFO, TDI_ADDRESS_INFORMATION i TRANSPORT_ADDRESS. W tym przypadku zakłada się, iż protokół może zwrócić więcej niż jeden adres przy zapytaniu, co nie jest normą dla systemu w sieci. Jako, iż wszystkie to jest częścią zdefiniowanego interfejsu, nie można go zmienić. Trzeba sprawdzić, czy logika kodu zapewnia przeprowadzenie operacji zgodnie z oczekiwanym standardem, czy użyte są właściwe struktury danych i wchodzące w ich skład części. Co gorsze, zdarza się iż różnice między strukturami danych bywają minimalne, lecz nadal przełożyć się to może na poprawne działanie w jednym przypadku a poważny błąd w innym. Ta dwójka znalazła sobie zadanie godne ich osób.

Platforma testów

Christoph von Wittich jakiś czas temu zdołał uruchomić automatyczną platformę do przeprowadzania Testów Wine (pakiet aplikacji testujących API, w celu porównania bibliotek Wine do referencyjnych bibliotek Windows NT – przyp. tłum) a Alwyn Tan, jeden z członków zespołu ReactOS, stworzył prowizoryczne GUI do przeglądania i porównywania wyników testów z różnych rewizji (inaczej wersja, każda zmiana w kodzie systemu jest zapisywana pod kolejnym numerem, system jest po takiej zmianie kompilowany od zera, testowany i zapisywany w postaci obrazów ISO, dostępnych do ściągnięcia – przyp. tłum.). Colin Finck z kolei pracował nad bardziej funkcjonalnym i trwalszym rozwiązaniem. Stworzony przez niego nowy interfejs, oparty o stronę WWW, umożliwia porównywanie naraz aż do pięciu różnych rewizji, lub jedynie wyników które uległy zmianie. Dodatkowo, Buildbot (system automatycznie kompilujący kolejne rewizje systemu, przeprowadza on również testy i zapisuje stworzone obrazy ISO do repozytorium – przyp. tłum.) także został uaktualniony. Colin przepisał program zarządzający testowaniem rosautotest, by restartował testy w przypadku zawieszenia się systemu. W połączeniu z poprawkami Stefana Ginsberga, mającymi na celu pomijanie testów skutkujących awarią, możemy być teraz pewni, że ROS przejdzie przez cały zestaw testowy, zamiast przerywać procedurę po awarii. Dla tych, którzy chcieliby zapoznać się bliżej z naszą Platformą testów informujemy, że znajduje się ona na serwerze testowym pod tym adresem.