Community > ReactOS Newsletter Archive > ReactOS Newsletter: Nieuwsbrief 63

Nieuwsbrief 63

by Z98 on 2009-07-31
translated by Peter Budts on 2009-10-23

Test Onderbrekingen

De automatische test suite die bij elke ReactOS revisie gelanceerd wordt zit al verscheidene dagen vast in een oneindige lus vanaf het bereiken van de msi_winetest. Verschillende mensen die de testen volgen merkten dit probleem op en stelden mogelijke oorzaken voor. Jeffrey Morlan zond uiteindelijk een patch in die een oplossing biedt. Het probleem scheen in de LoadLibraryExW functie te zitten, in een specifiek geval waar de LOAD_LIBRARY_AS_DATAFILE flag gezet was. Deze functie ontving als één van de inputs DllName, de naam van de bibliotheek die het moest laden. Als er spaties in die naam waren, zou de functie een privé-copy bewaren die ze trimde. Eens de functie klaar was met zijn werk werd deze privé-copy gewist. De code die door Dmitry Chapysev was toegevoegd probeerde echter de privé-copy te wissen losstaand van het feit of ze al dan niet gebruikt was. Als de string niet getrimd moest worden, veroorzaakte de poging om de copy te wissen een corruptie in het geheugen die de oorzaak van de oneindige lus bleek te zijn. Jeffrey's commit corrigeert dit en de test suite ondervindt dus dit probleem niet meer. Hoewel de test suite oneindig scheen vast te zitten, deed ze wel goed werk door deze bug vlug bloot te leggen. Anders had de fout misschien onopgemerkt lange tijd blijven bestaan voor ze ons op een serieuzer blok aan het been werd.

MSVC Fixes

Stefan Ginsberg gaat module voor module door ReactOS om de verschillende syntax problemen op te lossen die MSVC ervan weerhouden ReactOS te compileren. GCC is veel vergevingsgezinder dan MSVC wat betreft de code syntax en daardoor doen bepaalde conventies in de ReactOS code MSVC zich verslikken hoewel ze door GCC geaccepteerd worden. Eén van die gevallen was de definitievan functie prototypes, waarbij de plaatsing en groepering van het return-type en de calling conventie verschilden. MSVC verwacht dat de calling conventie en functienaam expliciet gescheiden worden door ronde haken, terwijl dit voor GCC niet nodig is. Dit geval wordt hier en daar in de code gebruikt maar is gelukkig redelijk makkelijk te vinden en verhelpen.

Een veel smeriger probleem stak de kop op omdat GCC je niet waarschuwt wanneer een functie zichzelf aanroept. Toegegeven, zulke recursieve calls kunnen soms handig zijn maar in dit geval waren de resultaten minder wenselijk omdat ze tot oneindige recursieve calls leidden. Het probleem ontstond eigenlijk in de w32api headers die met mingw worden gebruikt voor ontwikkeling in Windows. In de header is de functie ExAllocatePoolWithQuotaTag gedefiniëerd als ExAllocatePoolWithQuota. Hierdoor ontstond de vreemde situatie dat ExAllocatePoolWithQuota enkel bestond uit het oproepen van ExAllocatePoolWithQuotaTag omdat de omdat de eerste functie zich gedraagd als een wrapper rond de andere. Code die gecompileerd was met deze headers en de functie ExAllocatePoolWithQuotaTag probeerden te gebruiken kwamen waarschijnlijk in een oneindige lus terecht, eventueel met een stack overflow die een blue screen veroorzaakte. MSVC merkte dit probleem op en gaf een waarschuwing, zelfs bij het laagste waarschuwingsniveau, terwijl GCC het niet opmerkte of er niet om gaf.

ARWINSS Redux

Er schijnt nog heel wat verwarring te bestaan rond de bedoelingen van ARWINSS doordat hier maar weinig over verteld wordt. Veel mensen interpreteren het als een vervanging voor het Win32 subsysteem, maar dat is het niet. Dit was eerder nog niet expliciet duidelijk gemaakt en dat leidde tot nogal frappante speculaties. In dit licht heeft Aleksey Bragin verklaard dat ARWINSS bedoeld is als een tijdelijke maatregel, die gebruik maakt van Wine's vooruitgang bij het uitvoeren van Windows applicaties, om ReactOS meer functioneel te maken. Er zijn wel mensen die zich de periode herinneren rond de 0.3.1 release toen ReactOS ongelooflijk labiel was. De kernel rewrite die plaatsvond verving stap voor stap alle hacks die eerder het systeem lieten functioneren en toen alles uit elkaar viel, werden developers die aan andere componenten werkten hevig gehinderd totdat de hacks verwijderd waren en de ontwikkeling stabiliseerde. Om het Win32 subsysteem echt te herstellen zouden op verschillende niveaus verstoringen plaatsvinden door grote problemen in kritische componenten. Zowel Jim Tabor als Timo Kreuzer hebben geworsteld om de regressies tot een minimum te beperken terwijl ze het systeem herschrijven, maar het is een gevecht met hoogtes en laagtes. Er moet iets op wacht staan terwijl de grote refactoring en het herschrijven plaatsvindt en dat is waarvoor ARWINSS kan gebruikt worden. Of het een plaats kan vinden op de langere termijn valt af te wachten, vermits de verschillen experimenten kunnen toelaten die met het huidige Win32 subsysteem niet mogelijk zijn.

Zelfs met dat in het achterhoofd is niet iedereen het eens over de noodzaak van ARWINSS. Oorspronkelijk dachten verschillende developers dat Aleksey het Win32 subsysteem in trunk probeerde te vervangen en reageerden ze daar niet positief op. Zelfs met de verduidelijkingen maken ze zich zorgen dat ARWINSS de aandacht van de huidige rewrite zou afleiden. Dat gezegd vertoond ARWINSS enkele interessante problemen binnen het besturingssysteem als geheel. Het is zeker te hopen dat ARWINSS een positieve bijdrage zal brengen bij het project, maar dat kan alleen de tijd ons vertellen.