Community > ReactOS Newsletter Archive > ReactOS Newsletter: Newsletter 74
Newsletter 74
by Z98 on 2010-07-09
translated by Daniel Reimer on 2010-07-14
Allgemeine Entwicklungen
Amine Khaldis Bemühungen, die Treiber-Header aufzuräumen, fangen an Früchte zu tragen. Es wurden nicht nur einige Treiber-Header aussortiert, sondern auch nötige Überprüfungen eingebaut, um sie in MSVC und GCC nutzen zu können. Jeder, der schon einmal plattformübergreifend programmieren musste, weiß, dass die beiden Compiler manchmal gewisse Unterschiede in ihrer erlaubten Syntax haben, was das Erstellen von Code, der mit beiden Compilern läuft, schnell nicht so trivial werden lässt. Amines Arbeit hat es bereits ermöglicht, einige neue Treiber zu integrieren sowie den ARM-Kernel wesentlich weiter kompilieren zu lassen.
Das ReactOS-Web-Team untersucht die Probleme mit dem BuildBot und dem DNS der Seite. Bisher scheinen die DNS-Probleme gelöst zu sein und die Seite ist somit wieder über ihre Domain erreichbar. Der Buildserver andererseits fiel einem Ausfall seiner Prozessoren zum Opfer und wird somit wohl eine Weile brauchen, bis er wieder laufen wird. Die Tester haben ein temporäres System für ihre Zwecke zusammengewürfelt, so dass Regressionstests immer noch laufen. Der Serverausfall ermöglichte es Olaf Siejka, einem der Haupttester, ein Ersatz-Benachrichtigungssystem für Builds und allgemeine Hilfe im ReactOS-IRC-Channel auszuprobieren.
topYarotows
“Yet Another Rewrite of the Old Win32 Subsystem“ ist ein sehr passender Name für den Branch, an dem Jérôme Gardou und Timo Kreuzer die letzten Monate gearbeitet haben. Was als Neuschreiben der Art, wie Display Treiber vom Win32-Subsystem geladen werden, begonnen hatte, entwickelte sich dann zu einem bemerkenswerten Projekt, welches große Probleme in der Win32-Subsystem-Implementierung behebt. Diese Probleme waren direkt verantwortlich dafür, dass ReactOS nicht im Stande war, simple Dinge wie das Ändern der Auflösung zu realisieren. In vielen Punkten ist Yarotows die Antwort einiger Programmierer, die skeptisch gegenüber dem Arwinss-Ansatz sind, aber die Schwierigkeit, Probleme in win32k zu fixen, ohne erhebliche Regressionen zu erzeugen, resultierte in ein gewisses Widerstreben, der Überarbeitung größere Aufmerksamkeit zu schenken. Aber mit einem Branch haben die Programmierer die Möglichkeit, alle Regressionen der Welt einzubauen, bis sie endlich einige von ReactOS architektonischen Problemen gelöst haben.
In Windows wird die GRAPHICS_DEVICE-Datenstruktur verwendet, um jeden vorhandenen Hardwareadapter zu repräsentieren. Die Adapter selbst sind womöglich fähig, eine Vielzahl von Modi zu verwenden, um Dinge über verschiedene Wege zu zeichnen, welche von Grafiktreibern, die in der GRAPHICS_DEVICE-Struktur aufgelistet sind, zur Verfügung gestellt werden. Die Treiber selbst werden vom Logical Device Object (LDEVOBJ) repräsentiert, welches alle Modi beinhaltet, die der Treiber unterstützt. Es gibt auch ein Physical Device Object (PDEVOBJ), welches den aktuellen Modus repräsentiert und für den Treiber die Oberfläche zum Zeichnen liefert. Wenn das Win32-Subsystem geladen wird, prüft es in der Registry nach verfügbaren Geräten und erstellt ein GRAPHICS_DEVICE-Objekt für jedes. Dann wird ein Modus ausgewählt und das passende LDEVOBJ und PDEVOBJ wird geladen. Das Win32-Subsystem im Trunk hatte aber kein LDEVOBJ implementiert, was seinen Lademechanismus architektonisch vollständig falsch arbeiten ließ, und machte es auch völlig unmöglich, zwischen verschiedenen Displaymodi zu wechseln, ohne neu zu starten, da über die verfügbaren Modi an sich LDEVOBJ den Überblick behalten sollte. Das gesamte Ladesystem musste implementiert werden, eine nicht wirklich leichte Aufgabe, die während der Entwicklung zu großen Regressionen führte. Aber nun, mit allen Objekten implementiert, sind Modusänderungen einen Schritt näher.
Während die korrekte Treiberinitialisierungs-Architektur implementiert wurde, wurden viele Bugs aufgedeckt, die nie aufgefallen waren, da Modusänderungen zuvor niemals funktionierten. Glücklicherweise lieferte MSDN eine detaillierte Erklärung, die der Mechanismus funktionieren sollte, und diente als nützliche Referenz zum Füllen der Lücken. Der erste stand im Zusammenhang mit dem Zugriff auf die Oberfläche, auf der gezeichnet wird. Dieser Zugriff muss kontrolliert werden, da das Zeichnen von mehreren Dingen auf die Oberfläche zur selben Zeit Probleme verursachen kann. Das Ändern des Modus, während jemand auf die Oberfläche zeichnet, konnte auch schlimme Dinge nach sich ziehen, da die Eigenschaften der Oberfläche nicht mehr dieselben sein mussten. Zuvor wurden zwei Locks verwendet, einer, der die Oberfläche schützt, und einer, der den Gerätekontext schützt. Auch wenn dies vor gleichzeitigem Zeichnen schützte, würden die Locks aber versagen, wenn der Modus verändert würde. Der Lock der Oberfläche schützt nun das PDEVOBJ, so dass keiner darauf oder auf die zugehörige Oberfläche zugreifen kann, wenn der Modus gerade geändert wird. Dass dies vorher niemals Probleme bereitete, ist vermutlich dadurch zu erklären, dass niemand jemals nahe genug an eine Modusänderung herankam, um die Deadlocks greifen zu lassen, und selbst wenn doch, hätte etwas anderes das System zuvor hängen lassen. Der Lock an der Oberfläche wurde entfernt und einer am PDEVOBJ schützt vor simultanem Zeichnen.
Ein anderes Problem, das auftauchte, hatte mit den Paletten zu tun. Paletten werden verwendet, um die Bits auf der Oberfläche zu interpretieren, besonders, welche Farben die Werte repräsentieren. Deren Implementierung in ReactOS ist auch sehr sporadisch, was heißt, dass auch hier die Funktionen, die für eine Modusänderung nötig sind, fehlten. Die größten Probleme entstanden, wenn die Modusänderung auch die Farbtiefe änderte, was die Palette, die PDEVOBJ verwendete, ungültig wurde. Unglücklicherweise bezogen sich immer noch Oberflächen auf diese Palette und endeten mit komplett falschen Farben. Um dies zu lösen wurde die Palette mit der Oberfläche verknüpft, die sich mit der Modusänderung auch ändern würde und die richtigen Informationen liefern könnte.
Neben den Fixes, um Modusänderung zu unterstützen, wurden auch viele andere Probleme gelöst. Unter speziellen Bedingungen konnte sich Win32k in einer Situation wiederfinden in der mehrere Threads versuchen exklusive Locks auf mehrere Objekte in unterschiedlicher Reihenfolge zu erhalten. Dieser Fall würde sofort zu einem Deadlock führen, da niemand die Locks lösen würde, die sie bereits halten. So unwahrscheinlich dieser Fall auch war, locken sollte niemals auf solch einer Unsicherheit aufbauen, da das ganze System sich zerschießt, wenn sie doch jemals auftreten. Der Fix, der hier angewendet wurde, war einer spezifischen Reihenfolge nach Locks zu verteilen, die so designet war, dass diese Situationen von vornherein unmöglich waren. Eine weitere Änderung im Branch war eine Performanzverbesserung. Bitmaps wurden zuvor vom Paged Pool zugeteilt, der entgegen seines Namens eine knappe Ressource darstellt und nicht verschwendet werden sollte. Im Branch wurden Bitmapzuteilungen in den normalen Systemspeicher verschoben. Windows teilt sie an sich dem Sitzungs-spezifischen Speicher zu, aber ReactOS hat bisher noch nicht genug Support hierfür implementiert. Dennoch entfernt es einen weiteren Anwärter auf den Paged Speicher.
topSpeicherkorruption
Vor nicht allzu langer Zeit implementierte Aleksey Bragin einen Pool Integrity Checker, um die Datenbeschädigungen in ReactOS zu suchen und zu finden. Dieser Checker arbeitete über Padding-Pool-Zuweisungen und überprüfte, ob ein Schreibvorgang auf den zusätzlichen Seiten vorgenommen wurde. Allerdings wird Alekseys Checker aufgrund erheblicher Änderungen am Pool-Manager nicht mehr funktionieren. Michael Martin hat jetzt zumindest ein System für die Überprüfung des ausgelagerten Pools entworfen. Michaels Technik nutzt ein Feature, das in QEMU GDB ermöglicht, eine Verbindung zu ihm aufzubauen und den Speicherzugriff zu beobachten. Michael schrieb dann in seine Version von QEMU, eine Speicherposition in ReactOS zu überprüfen, die auf die Adresse des Blocks verweist, der vom Pool aus abgefragt wird. Jedes Mal, wenn der ausgelagerte Pool von ReactOS angerührt wurde, ließe Michael QEMU eine Liste mit gespeicherten Adressen abarbeiten, um sicherzustellen, dass diese Operation tatsächlich an einem Block geschieht. Unnötig zu sagen, dass dies das System stark verlangsamte, und so dauerte es etwa fünf Minuten ReactOS bis in das GUI zu booten. Bei einem fehlerhaften Speicherzugriff, ließ Michael QEMU das Betriebssystem abstürzen und den Benutzer in die Debug-Schnittstelle werfen, mit der er die Quelle des Zugriffs nachprüfen konnte.
Bisher ist Michael über vier Fehler gestolpert, die durch Korruption des Pools entstehen, von denen drei in seinem eigenen Code sind. Die erste war ein Überbleibsel von seinem Fix für die Nonqueued Message Pump, die im Newsletter 72 angesprochen wurde, wo noch Buchhaltung über Nachrichten geführt wurde, die nicht durch die Queued Message Pump liefen. Die beiden anderen Probleme waren im neuen USB-Code von Michael, zum einen ein einfacher Tippfehler und eine Offset-Fehlberechnung. Alle drei wurden behoben. Der letzte Fehler, der noch bearbeitet wird, ist dass UniATA eine Pool-Korruption verursacht. Das wird noch untersucht, aber hoffentlich wird Michael mit seinem neuen Tool auch das bald lösen.
Ein weiterer Bereich, der an Speicherfehlern leidet, versucht Sound auf echter Hardware abzuspielen. Die Tester versuchten Treiber zum Laufen zu bringen, aber stolperten immer wieder über Abstürze, entstanden, weil irgendwo der Kernel-Speicher beschädigt wird. Die bisherigen Arbeiten vom ARM-Team am Non-Paged Pool scheinen das zu sein, was die Korruption freilegte, aber bisher ist es Johannes Anderwald nicht gelungen, ihre Ursache zu finden. Leider wird Michaels Tool nicht in der Lage sein beim Testen zu helfen, da dies QEMU spezifisch ist. Allerdings, jede Korruption, die es findet könnte die sein, auf die die Tester stoßen.
topDateisystem-Benachrichtigungen
Obwohl es um Pierre Schweitzer schon länger ziemlich ruhig ist, hat er fleißig Dateisystem-Benachrichtigungen studiert und für ReactOS implementiert. Der Mangel an Benachrichtigungen ist direkt verantwortlich für mehrere Probleme in ReactOS, vor allem in der Shell. Eines der deutlichsten Beispiele ist, wenn ein Programm deinstalliert wird, sollte man in der Lage sein zu sehen, dass das Programm-Verzeichnis gelöscht wurde. Dies geschieht, weil das Dateisystem die Shell benachrichtigt, dass es ein Verzeichnis löscht, aber ohne diese Benachrichtigungen ist dies nicht möglich. Andere Probleme wären offensichtlich außer andere Fehler und fehlende Funktionalität verschleiern sie. Es gibt zwei Arten von Benachrichtigungen: eine, die durch die Plug-and-Play-Pfade geht, um das System über Änderungen am Zustand eines Datenträgers zu informieren, wie z.B. Mounten und Unmounten eines USB-Laufwerks, eine andere, die Benachrichtigungen über Änderungen am Inhalt eines Verzeichnisses sendet.
Von den beiden hat Pierre teilweise die Zustandsänderungen implementiert. Sein Bemühen war deutlich von dem schlechten Zustand behindert, den das ReactOS-PnP-System derzeit noch hat. Dies ist darauf zurückzuführen, dass alle ausgegebenen Meldungen, die interessierte Programme und Benutzer über Statusänderungen informieren, über den PnP-Manager weitergeleitet werden. Wenn ein Programm das Betriebssystem informiert, dass es über Statusänderungen informiert werden möchte, ist es der PnP-Manager, der diese Registrierung erhält und eine Liste aller interessierten Parteien unterhält.
Dateianmeldungen benötigen noch einiges an Arbeit, aber Pierre hat wenigstens die Grundlagen herausgefunden. Vor einer Weile wurde die FileSystem Runtime Library erwähnt, auch ein Projekt von Pierre. Einer der Zwecke der FsRtl ist als Anlaufstelle für Meldungen zu dienen, für Datei und Status. Die tatsächliche Versendung von Benachrichtigungen hängt von der Art ab, mit dem PnP-Manager, der wie oben erwähnt mit Statusbenachrichtigungen umgeht und der FsRtl die Datei Benachrichtigungen handhabt. Wenn Programme verlangen über Änderungen unterrichtet zu werden, wird dem Dateisystem-Treiber ein I/O-Request-Paket geschickt, welches beinhaltet, über was das Programm benachrichtigt werden möchte. Der Treiber wird diese Benachrichtigung dann in einer Liste registrieren, die von der FsRtl verwaltet wird und die verwendet wird, um nach interessierten Parteien zu suchen wann immer eine Datei geändert wird. Wird eine Übereinstimmung gefunden, füllt die FsRtl in die notwendigen Details ein und komplettiert das IRP. Pierre hat zumindest die Benachrichtigungs-Registrierung umgesetzt und in einem Patch wartend und ist immer noch dabei, die tatsächliche Versendung von Benachrichtigungen zu implementieren. Sobald Sie fertig ist, kann Pierre zu den anderen Dateisystemsproblemen übergehen, die ReactOS hat.
(Danke an gyROS und TuX fürs kontrollieren)top
