Community > ReactOS Newsletter Archive > ReactOS Newsletter: Biuletyn 59

Biuletyn 59

by Z98 on 2009-06-04
translated by Mariusz Przybylski on 2009-06-07

Tłumaczenie: Olaf Siejka

Fundacja ReactOS

Fundacja ReactOS jest organizacją, która dba o prawne aspekty Projektu, będąc jednocześnie właścicielem znaków handlowych i loga Projektu ReactOS. Założona kilka lat temu, z siedzibą w Moskwie, w ciągu dwóch ostatnich lat nabrała szerszego znaczenia. Pierwszym, znaczącym, jej posunięciem było zarejstrowanie ReactOS jako marki handlowej, należącej do Fundacji w Rosji. Dzięki temu mamy silniejszą pozycję gdyby musiało dojść do przeciwdziałania nieautoryzowanym użyciom słowa ReactOS. Ci, którzy są z Projektem związani od dawna, pamiętają jak może to być istotne.

Kolejnym ważnym krokiem było uzyskanie od VeriSign certyfikatu do podpisywania, co umożliwi Fundacji cyfrowe sygnowanie publikowanych wersji systemu, umożliwiając ich autorytatywną identyfikację jako autentycznych. Powinno to wyeliminować wszelkie niepewności co do pochodzenia i autentyczności pobieranych plików. Przy okazji, jak wielu wiadomo, 64bitowe wersje systemu Windows stawiają wszelkim używanym w systemie sterownikom wymóg certyfikacji. Dla projektów OpenSource, może to stanowić poważny problem, eliminujący ich kompletnie z rynku aplikacji 64bitowych dla Windows. Fundacja zatem rozważa stworzenie systemu, dzięki któremu projekty mogłyby uzyskać certyfikacje i podpis cyfrowy dla swojego kodu przy użyciu certyfikatu Fundacji. Oczywiście, taki kod musiałby uprzednio zostać poddany audytowi, dla sprawdzenia jego zgodnosci z wymaganiami stawianymi przed sterownikami certyfikowanymi. W dalszym ciągu stanowiłoby to poważną oszczędność czasu i pieniędzy.

UniATA, akt trzeci

Aleksiej Bragin naprawił błąd, który uniemożliwiał korzystanie z napędu CD w VirtualBox. Maszyna wirtualna zgłaszała bowiem brak napędu i wyrzucała niebieski ekran zaraz na starcie. Pierwotna teoria głosiła, iż kontroler nie znajdował napędu CD. Dzięki porównaniu logów z Vmware, na którym UniATA chodzia poprawnie, do tych z VirtualBox, mimo trudności z tymi drugimi (jeden ze znanych błędów Vbox w wersji 2.x.x związany jest z ucinaniem treści przesyłanych przez wirtualny port szeregowy), udało się stwierdzić, iż tak na prawdę napęd CD jest wykrywany, tak więc problem musiał leżeć gdzie indziej.

Na szczęście błąd okazał się jasny gdy tylko przeanalizowano komendy wysyłane do napędu. Wszystkie okazały się zwracać ten sam błąd – przekroczony czas oczekiwania. To z kolei spowodowało znaczące opóźnienia przy starcie systemu, zanim jeszcze pojawiał się komunikat o błędzie.

Problem udało się ostatecznie zlokalizować w funkcji AtapiSendCommand, w której Aleksiej uprzednio przeczyścił nieco kod związany z włączaniem i wyłączaniem wywołań, co w rezultacie nie spodobało się kontrolerowi Vboxa. Po poprawkach sterownik mógł wreszcie poprawnie nawiązać komunikacje z napędem CD, jednak wciąż kończyła się ona niepowodzeniem. Ten, już na szczęscie ostatni problem, związany był tym razem z kodem DMA w UniATA. Ze względu na jego wysoką specjalizację i czułość na wszelkie zmiany, Aleksiej po prostu go wyłączył. W przyszłości oczywiście będzie to kolejny problem do rozwiązania, gdyż brak wsparcia DMA w sterowniku oznacza istotne zmniejszenie jego wydajności. Mimo to, nawet bez DMA, sterownik UniATA jest o wiele szybszy od swojego poprzednika, a jego o wiele wieksza kompatybilność jak i fakt likwidacji wielu problemów (m.in. wsparcie SATA, brak ograniczenia wielkości partycji do 8GB) nie pozwala wątpić w słuszność decyzji Aleksieja. Tak więc UniATA jest już oficjalnie domyślną częscią naszego systemu.

Sterowniki grafiki

Znany wam już z testów kart sieciowych, Olaf Siejka zabrał się jednocześnie za kompletowanie i testy rozmaitych kart graficznych, aby sprawdzić ich kompatybilność z ReactOS. Ze względu na wiek komputera użytego do testów, musiał się ograniczyć do kart PCI i AGP (te ostanie do AGPx4, działające na wyższym napięciu, niż nowsze AGPx4/x8). Jako, że sam system utrudnia instalację nowych i praktycznie uniemożliwia podmianę już zainstalowanych sterowników, Olaf użył metody zwanej slipstreaming – dołączył pliki sterownika do bootcd tak, by instalator sam kopiował je do właściwych katalogów, a system sam je wynajdywał i instalował. Jak dotąd najlepiej wypadły karty Matrox (G100 i G400), i ATI RAGE II+, nieco gorzej S3 Trio64V. Nie najnowszy sprzęt, ale zawsze cos.

Ciekawy może być fakt, iż najlepiej działały sterowniki XP, o wiele lepiej niż te z Windows 2000, co dobrze świadczy o stanie interface kernela. Jak dotąd nie udało się na Matrox G400 użyć sprzętowego wspomagania 3D, co nie może dziwić, gdy jedynym do tej pory testowanym sterownikiem ICD OpeGL były nasza własna MESA (sterownik programowy) i ten z VirtualBOX.

RosBE

Przy okazji testów RosBE na systemie 64bitowym wykryto dość poważny błąd. Skrypty RosBE miały problem z katalogami Windows, zawierającymi nawiasy, jak na przykład Program Files (x86). Daniel Reimer zdołał je naprawić, zatem osobom korzystającym z 64bitowych Windows zalecamy aktualizacje RosBE do najnowszej wersji.