Community > ReactOS Newsletter Archive > ReactOS Newsletter: Biuletyn 63

Biuletyn 63

by Z98 on 2009-07-31
translated by Haos on 2009-08-22

Zakłócenia testów

Przez wiele dni automatyczny mechanizm testowy, który ma za zadanie sprawdzenie każdej rewizji ReactOS, zacinał się w nieskończonej pętli, gdy tylko trafiał na moduł msi_winetest. Problem został szybko zauważony przez śledzących wyniki testów, a Jeffrey Morlan w końcu opublikował poprawki, wydające się naprawiać problem. Jego sedno zdawało się tkwić w funkcji LoadLibraryExW, w specyficznym przypadku, gdzie występuje flaga LOAD_LIBRARY_AS_DATAFILE. Funkcja, jako jeden z parametrów ma podany DllName, czyli nazwę biblioteki, którą ma załadować. Gdyby nazwa ta zawierała spacje, funkcja zaalokowałaby dodatkową jej kopię, w której spacje zostałyby usunięte. Po zakończeniu przebiegu, ta dodatkowa kopia powinna zostać zwolniona. Jednakże, kod funkcji napisany przez Dimitriego Chapysheva usiłował dokonać zwolnienia, bez względu na to czy kopia była użyta czy nie. Gdy ciąg nazwy biblioteki nie zawierał spacji, próba zwolnienia pamięci kończyła się jej korupcją i to właśnie zdawało się wywoływać ową nieskończoną pętlę. Poprawka Jeffreya sprawiła, iż mechanizm testowy przestał się wieszać. Mimo problemów, jakie to sprawiło, zdał egzamin, wykrywając bardzo istotny błąd, który niezauważony mógł sprawiać rozliczne kłopoty przez długi czas.

Poprawki dla MSVC

Stefan Ginsberg od jakiegoś już czasu przegląda kod ReactOS moduł po module, naprawiają liczne przypadki składniowych i formalnych błędów, uniemożliwiających kompilację przy użyciu MSVC. GCC jest przy tym o wiele mniej rygorystyczne i kod, którego składnia jest zupełnie wystarczająca dla używanego przez nas kompilatora, pod MSVC zostanie odrzucony z pokaźną listą błędów. Przykładem może być chociażby definicja prototypów funkcji, gdy kolejność i grupowanie zmiennych zwracanych istotnie się różni. MSVC wymaga by konwencja nazywania i nazwa funkcji były oddzielone nawiasami, podczas gdy GCC działa i bez tego. Ten akurat problem, mimo, że licznie występujący w kodzie, jest akurat względnie łatwy do znalezienia i poprawienia.

Znacznie bardziej paskudnym problemem są przypadki, gdy GCC nie ostrzega o wywoływaniu funkcji przez siebie samą. Pomimo istnienia zastosowań dla takich rekurentnych wywołań, istnieje ryzyko nieskończonego zapętlenia się przebiegu. Taka sytuacja została wykryta w plikach nagłówkowych w32api, używanych w MINGW. W nagłówkach, bowiem, funkcja ExAllocatePoolWithQuotaTag została zdefiniowana, jako ExAllocatePoolWithQuota. Tyle, że ExAllocatePoolWithQuota zawiera głównie… wywołanie funkcji ExAllocatePoolWithQuotaTag. Kod skompilowany przy pomocy tych nagłówków i próbujący wywołania funkcji ExAllocatePoolWithQuotaTag, zapewne skończyłby w nieskończonej pętli wywołań, w końcu zapełniając stos i wywołując niebieski ekran. MSVC zauważył powyższy problem i zwrócił stosowne ostrzeżenie, podczas gdy GCC nawet na najwyższej czułości zdawał się nie przejmować tym problemem.

ARWINSS w pigułce

W dalszym ciągu wokół ARWINSS zdaje unosić się zasłona niepewności, po części z powodu braku wystarczających informacji. Wielu wyobraża go sobie, jako zastępstwo dla dotychczasowego podsystemu Win32, niesłusznie. Aleksiej Bragin zaznaczył, iż ARWINSS jest projektem tymczasowym, mającym skorzystać z postępów WINE i jego kompatybilności z rozlicznymi aplikacjami, w celu poprawienia funkcjonalności ReactOS. Ludzie pamiętający czasy sprzed wersji 0.3.1 zdają sobie sprawę z tego jak problematyczne było wówczas korzystanie z niego. Projekt przepisania kernela pozwalał na eliminację licznych prowizorek i skrótów w kodzie, na których to niestety, inni deweloperzy opierali swoje rozwiązania. W efekcie – po dokonaniu prawidłowych implementacji, wszystko się sypało. Konieczne były dodatkowe testy regresji, co w efekcie poważnie spowalniało postęp prac. Doprowadzenie podsystemu Win32 na podobny poziom poprawności, spowodowałoby podobne, jeśli nie poważniejsze problemy. Zarówno Jim Tabor jak Timo Kreuzer robią co w ich mocy by ograniczyć regresje do minimum, ale jest to walka skazana z góry na przegraną. ARWINSS służyłby, zatem jako tymczasowe zastępstwo, podczas gdy prace nad przepisaniem podsystemu Win32 weszłyby w krytyczną fazę. Pozwalałby również na eksperymenty, które nie byłyby z oryginalną architekturą możliwe.

Mimo to, nie wszyscy zgadzają się z Aleksiejem co do przydatności ARWINSS. Nawet po wyjaśnieniach, co do przeznaczenia ARWINSS i po pierwszej, bardzo emocjonalnej reakcji, niektórzy deweloperzy uważają, to za marnowanie zasobów i odwracanie uwagi od projektu naprawy podsystemu Win32. Jak będzie w rzeczywistości? Jedynie czas pokaże