Community > ReactOS Newsletter Archive > ReactOS Newsletter: Newsletter 67

Newsletter 67

by Z98 on 2009-12-09
translated by Daniel Reimer on 2009-12-09

Debugging

Das letzte Mal, wann WinDBG Support diskutiert wurde, war vor etwa einem Jahr. Der erste nötige Schritt war ein WinDBG kompatibler Kernel, was ein Resultat des Neuschreibens des Kernels war, dass größtenteils vor zwei Jahren stattfand. Die benötigten Features bewegten sich hauptsächlich um das Arbeiten mit dem Kontext eines ausgeführten Threads und dem Lesen von virtuellen Speicher. Auch wenn das Neuschreiben des Kernels dies alles ermöglichte, verhinderten einige Bugs die Nutzung. Debugging muss ausgeführte Threads unterbrechen können, aber muss sie auch wiederherstellen können, damit das Programm fortgesetzt werden kann. Einer der erwähnten Bugs korrumpierte den Execution Context und lies alles, was Debugged wird, als Resultat crashen. Ein weiteres Problem war, dass HAL versuchte die erste physikalische Seite über den Memory Manager zu mappen. Dies schlug fehl, weil die Funktion im Memory Manager einige zusätzliche Synchronisation durchführte, die aber nicht funktionierte, wenn HAL nach einem Neustart im Debugging Kontext lief. Wenn es in einem solchen Debugging Kontext lief, wurde keine dieser ausgeführten Synchronisationen benötigt und es bestand noch das Risiko, dass die fraglichen Locks schon von etwas anderes belegt wurden. Dies wiederum konnte zu einem Deadlock führen und das System einfrieren. Mit diesen und anderen Fixes gelang es Stefan mit WinDBG eine Verbindung zum ReactOS Kernel aufzubauen und Aktionen wie das Setzen und Entfernen von Breakpoints oder das Lesen von I/O oder Speicher auszuführen. Aber das Verbinden zu ReactOS verlangte die Verwendung des Windows 2003 KDCOM Treibers.

Der Grund, warum Stefan den KDCOM Treiber von Windows 2003 verwendete war, weil der ReactOS KDCOM Treiber ganz einfach nicht korrekt arbeitete als Stefan mit seiner Arbeit begann. Trotz Timo Kreuzers Bemühungen ihn kompatibel zu machen, hatte er noch nicht den Stand erreicht, um auf ihm aufzubauen, ohne ständig analysieren zu müssen, wo der Fehler nun zwischen seinem Kernel und KDCOM lag. Etwa zur selben Zeit in der Stefan Interesse an WinDBG bekam, setzte Timo seine Arbeit an ReactOS KDCOM im x64 Branch fort. Eine Mischung aus Timing Fehlern sorgte für fehlende Characters und verlorene Pakete, besonders wenn diese größer waren und machte den Treiber eher unzuverlässig. Timo fügte zusätzliche Fehlerkorrekturen und Handlers hinzu, um dies zu kompensieren. Ein seltsames Timingproblem war, dass das Schreiben aus dem Seriellen Port fehlschlug, weil das Gerät behauptete noch nicht bereit zum Senden zu sein, trotz der Tatsache, dass es nach Überprüfen des Status eigentlich bereit sein sollte. Timos derzeitiger Fix fügt einfach einen Delay hinzu, der dem Seriellen Port scheinbar genug Zeit lässt, um Daten zu akzeptieren, aber diese Lösung ist alles andere als ideal. Timos derzeitige Test Plattform ist VirtualBox, welches eine Geschichte in Sachen problematischer Serieller Port mit sich führt. Tester brauchten einige Zeit, um herauszufinden wie sie einfach nur eine Debugausgabe über Virtual Box erhalten. Und selbst danach war die Formatierung der Nachrichten teilweise sehr abenteuerlich. Das Virtual Box Team scheint eine komplette Neuimplementierung ihrer Seriellen Implementierung ins Auge zu fassen, die hoffentlich die Probleme beseitigen wird, die unser Projekt erfahren musste und ermöglicht hoffentlich besseres testen von KDCOM und WinDBG.

Shell

Die Shell, mit der Nutzer interagieren sind an sich mehrere Komponenten, die alle zusammengefügt sind, was dafür sorgt, dass das Neuschreiben alles andere als Trivial ist. Neben der Explorer Shell an sich sind da noch die shell32, browseui, comctl32 und shlwapi Bibliotheken, um nur ein Paar zu nennen. In ReactOS wurde viel der Funktionalität dieser Bibliotheken in die Explorer Shell gestopft, weil diese Bibliotheken zu dieser Zeit noch nicht wirklich existierten. Dies ist so, weil viele der Komponenten von Wine stammen und Wine an sich keine shell32 Implementierung benötigt. Ein solches Beispiel wäre das Startmenü an sich. An sich ist es nicht im Explorer implementiert, sondern wird nur von diesem ausgeführt. Ein anderes ist das Menü System. Aus Tradition werden Menüs in Windows Anwendungen von user32 verwaltet, aber die shell hat eine eigene Menüs, die getrennt verwaltet werden. Nur wenige Anwendungen neben der Shell würden diese speziellen Menüs jemals verwenden, so dass ihr Fehlen erst sehr spät aufgefallen ist, aber wenn irgendjemand einmal eine andere Shell ausprobieren wollte, sind ihm diese fehlenden Funktionen sofort aufgefallen.

Andrew Hill hat die letzten Monate damit verbracht das Shell System von Windows zu untersuchen und was davon in ReactOS noch fehlt. Er schaffte es mehrere zur Shell gehörige Bibliotheken als auch explorer_new, der angedachte Ersatz für die derzeitige Shell von ReactOS, in Visual Studio zu kompilieren und unter Windows XP zu verwenden. Dies ermöglichte es ihm spezifische fehlende Funktionen als auch Fehler in existierenden Funktionen zu finden. Ein solches Beispiel ist das fehlende Start Menü, eines der speziellen Menüs, die nicht von user32 verwaltet werden. Seine derzeitige Planung ist es explorer_new sich so verhalten zu lassen, wie die Shell von XP und dann seine Arbeit in ReactOS zu reintegrieren.

Neue Programmierer

Andrew Hill wurde bereits erwähnt und ist an sich auch schon mehrere Monate beim Projekt, aber wollte nicht im Rampenlicht stehen solange er seine Untersuchungen durchführt. Er arbeitete erst mit Ged Murphy, um Fuß zu fassen und fing jetzt an die ersten Früchte seiner Arbeit zu comitten. Sein IRC nick ist ash77, wobei sehr oft ein |away angeheftet ist, ungeachtet davon ob er nun wirklich anwesend ist oder nicht.

Ein anderer neuer Programmierer, der dem Team beigetreten ist, ist Giannis Adamopoulos, bekannt als smiley_ im IRC Chat. Giannis ist jetzt schon eine Weile im IRC vertreten. Sein Hauptinteresse liegt in der Kernel Seite des Win32 Subsystems und er wird beim Implementieren fehlender Funktionen helfen.

Der aktuelle Zuwachs von neuen Talenten wird ReactOS sicher helfen voranzukommen, aber es gibt immer noch sehr viel zu tun, wobei das Projekt Hilfe brauchen könnte. Wir sind jetzt an einem Punkt angekommen, wo das Neuschreiben von alten, fehlerhaften Komponenten nahezu abgeschlossen ist, was es ermöglicht auch neue Funktionen hinzuzufügen. Dies würde ReactOS helfen noch kompatibler zu werden, aber mit der begrenzten Anzahl an Leuten, kann nicht so viel auf einmal getan werden. Hoffentlich wird die Anzahl an Programmierern mit dem Verbessern des Projekts auch weiterhin steigen.