ReactOS Newsletter #54

Hier der aktuelle Newsletter von reactos.org:

Speichernutzung

Die Mindestanforderungen an Arbeitsspeicher von ReactOS sind seit einiger Zeit langsam angestiegen, hauptsächlich wegen des Installers. Eigentlich war den Entwicklern bekannt, dass der Speicherverbrauch von ReactOS nie so hoch war wie während der Installation. Die meisten vermuteten, dass irgendwo ein Speicherfehler auftrat, entweder im Installer selbst oder sogar in der Speicherverwaltung. Es war ein Fehler, von dem viele wollten dass er behoben würde, es aber erst wurde, als sich Alex Ionescu des Fehlers annahm. Es stellte sich heraus, dass das Problem nicht nur den Speicher betraf, sondern auch das automatische Laden von Debugging-Symbolen. Dieses Problem war gelöst indem man ReactOS dazu brachte, die /LOADSYMBOLS Flag zu akzeptieren, das Problem mit dem Speicher zu beheben war etwas aufwändiger. Um die Herkunft des Speicherfehlers ausmachen zu können, änderte Alex zunächst die Anzeige im Installer, so dass sie nicht mehr ausgelagerten und nicht ausgelagerten Speicher sondern den Kernel-Cache und den Kernel-Pool anzeigte. Er entfernte auch einen Hack, der bisher dazu geführt hatte, dass der Installer bei mehr als 40% Speichernutzung angehalten wurde. Er machte weiter mit der Reperatur der Speicherverwaltung und des gemeinsamen Caches, was die Anforderungen an den Speicher auf 24 MB reduzierte. Bei dem Problem ging es um in den Kernelspeicher gecachte Daten, die nie freigegeben wurden und so die verfügbaren Ressourcen verbrauchten. Auch die sonstige Installation von Programmen sollte nun weniger Speicher verbrauchen. Dazu ging die Mindestspeichernutzung des Betriebssystems nach dem Bootvorgang herunter auf 20 MB. Ich bin sicherlich nicht der Einzige, der diese Arbeiten mehr als zu schätzen weiß.

CSR

Die Komponente CSRSS verwaltet die Konsole und ist noch ein Überbleibsel aus früheren Zeiten, als der Code von ReactOS noch ein einziges Chaos war. Timo Kreuzer verbrachte einige Tage damit, den entsprechenden Code durchzusehen und die CSR_API_MESSAGE Datenstruktur zu reparieren. Sie wird für CsrConnectToServer und die korrekte Initialisierung von User32 gebraucht, das wiederum Nachrichtenweiterleitung, Fenster und andere für die Funktion von Windows notwendige Dinge erledigt. Die originale Version in ReactOS war fehlehaft und wurde deshalb auch von CsrClientConnectToServer nicht richtig benutzt.
Allerdings benutzt eine Komponente irgendwo in der ReactOS Code-Datenbank eine fest programmierte Größe für diese Datenstruktur, also enden alle Versuche Benutzer hinzuzufügen oder zu entfernen mit einem Absturz. Timo versuchte zwar das zurückzuverfolgen, aber vergeblich. Er hat die Komponente momentan aufgegeben für die Zeit in der er durch den Code schauen muss. Dafür kann ich ihm wirklich keinen Vorwurf machen. Es gibt Codezeilen, in welchen jemand mehrfache Typumwandlungen durchführte, zuerst zu einem allgemeinen Zeigertyp, dann wurde der Zeigeradresse von der Größe einer Datenstruktur inkrementiert und dann wiederum in einen anderen Zeigertyp umgewandelt, je nach Bestimmung des Zeigers. Jeder mit auch nur einem Minimum an C-Kenntnissen würde bei solchem Code erschaudern, da solcher Code sowohl unschön aussieht als auch fehleranfällig ist.

Netzwerk

Es ist schon eine Weile her, seit Art Yerkes zum ersten Mal den Netzwerk-Stack zum Laufen gebracht hat. Seitdem hat Cameron Gutman ihn weiter vorangebracht, wobei er versuchte, den Code zu Verbessern und neue Funktionen zu implementieren. Viel davon fand in einem Programmzweig statt, das meiste wurde allerdings in den Programmstamm übernommen. In letzter Zeit hat sich Art nun die Zeit genommen, um sich um einige sehr lange bestehenden Bugs zu kümmern, da er mittlerweile ein besseres Verständnis von Netzwerkstack und -protokollen hat.

Außerdem hat Art noch einiges anderes am Code gearbeitet, vor kurzem hat er ein Problem mit Prüfschleifen behoben. Um sich mit einem Empfangssockel verbinden zu können, muss die Zugriffsadresse entweder 0 sein oder mit der Adresse eines Adapters übereinstimmen, auf den die Anwendung zugreifen kann. Programme, die eine Prüfschleife empfangen müssen, brauchen entweder die Adresse 0 oder 127.0.0.1. Im ersten Fall kann die Anwendung Daten von allen Adaptern empfangen, während im zweiten Fall nur der Empfang lokaler Daten möglich ist. Jedoch wurde unter ReactOS Anwendungen, die auf die Adresse 0 zugreifen wollten, stattdessen nur Zugriff auf die Adresse des ersten gefundenen Adapters gewährt. Das bedeutete in den meisten Fällen, dass diese nicht mehr länger die lokalen Daten empfangen konnten, und Anwendungen, die aus diesem Grund von der Adresse 0 abhingen, abstürzten. Art fand und behob das Problem, so dass der Zugriff auf die Adresse 0 wieder funktioniert.

Eine andere Sache die Art behob, war die falsche Behandlung von IRP_MJ_CLEANUP und IRP_MJ_CLOSE. Am Anfang wusste Art nicht, was diese zwei wirklich taten. Die Aufgabe von IRP_MJ_CLEANUP ist es, alle laufenden IRPs für das aktuelle Objekt anzuhalten, die von IRP_MJ_CLOSE ist es, das Objekt an sich freizugeben. Allerdings behandelte ReactOS die beiden IRPs als gleich, und gab das Objekt frei, wann immer eines davon aufgerufen wurde. Da aber ReactOS nach dem Aufruf von CLEANUP ein laufendes Objekt erwartete, gab es Probleme mit fehlenden Ressourcen.

Sound

Die Arbeiten am Sound sind schon soweit fortgeschritten, dass Andrew Greenwood Winamp zum Abspielen von Musik verwenden kann. Dies funktionierte zwar theoretisch schon früher, aber nur mit sndblst.dll aus NT 4. Nun ist es auch möglich die von Andrew geschriebene sndblst.dll zu verwenden. Bisher kann allerdings nur eine Datei auf einmal abgespielt werden, da Andrew noch nicht untersucht hat, wie sie sich mit mehreren Streams verhält. Theoretisch müsste die DLL eine Warnung ausgeben, dass das Gerät schon benutzt wird. Kernel Streaming funktioniert noch nicht, zumindst nicht für Andrew. Wdmaud.drv zur Kommunikation mit Johannes Anderwald's Code zu bewegen, würde mehr Zeit verbrauchen als sndblst.sys, das Gegenstück zu sndblst.dll auf der Seite des Kernels, zu schreiben.

Zielplattform

Die Version von Windows, die ReactOS anstrebt, hat seit einiger Zeit für Verwirrung gesorgt. Es gibt nämlich zwei spezifizierte Ziele, den NT-Kernel und das Win32 Subsystem. Offiziell hat der Kernel von ReactOS immer noch den Kernel von Server 2003 (NT 5.2) als Ziel. Dieses Ziel ändert sich nicht sehr häufig. Andererseits orientiert sich das Ziel des Win32 Subsystems an der jeweils aktuellsten veröffentlichten Windows-Version, zur Zeit also Vista. Deshalb gibt es des öfteren Updates und Implementierungen, die Vista-basiert sind. Wenn Windows 7 veröffentlicht wird, wird sich das Ziel des Win32 Subsystems wiederum ändern, was aber nicht unbedingt auf das Ziel des Kernels zutrifft.