Jahresrückblick auf 2008 #48

Hallo ReactOS Fans,

hier die ReactOS News #48 übersetzt von Phlox am 2009-01-26
(Quelle: http://www.reactos.de/de/news_page_48.html )

Jahresrückblick

Im Jahr 2008 sind vier Point-Releases von ReactOS veröffentlicht worden, alle nach der Neufassung des Kernels. Deshalb ist ReactOS lange nicht mehr so instabil wie noch im Release 0.3.1, außerdem stieg die Zahl der erfolgreichen Anwendungen von ReactOS auf echter Hardware, statt auf virtuellen Maschinen. Das heißt nicht, dass das System stabil läuft, aber dass wir diesem Zustand ein ganzes Stück näher gekommen sind. Die Zahl der Releases ist viel höher als in den vergangenen Jahren, als das Projekt wegen des instabilen Kernels für einige Zeit still stand.

Wie jeder sehen kann, war das Jahr 2008 für uns ein sehr arbeitsreiches, mit vielen Fortschritten in der Entwicklung und den Anlagen für neue Ansätze, die sich hoffentlich in der Zukunft auszahlen werden. Auch Ansätze, die schon vor Jahren begonnen wurden, fangen an Auswirkungen zu zeigen, wodurch ReactOS stabiler und funktionaler wird. Hier werden wir einige Fortschritte und Ansätze hervorheben, die für die Community von Interesse sein könnten.

Altes und neues Blut

Einige sind dieses Jahr als Entwickler neu zu ReactOS gestoßen, auch einige die lange Zeit in der Community aktiv waren, und eine Person ist sogar aus dem Hiatus zurückgekehrt. Insgesamt zehn Neueinsteiger und ein Rückkehrer sind nun dabei und haben schon viel zur Entwicklungsarbeit beigetragen. Die ersten zwei kamen Anfang dieses Jahres zu uns, nämlich Andrey Korotaev Dmitry Chapyshev. Steven Edwards, welcher für eine Weile unser Verbindungsmann zu Wine war, kehrte dann auch zurück. Er wurde gefolgt von Matthias Kupfer, der schon sehr lange in der Community ist, und Jeffrey Morlan, der das Projekt erst kurz bevor er als Entwickler aufgenommen wurde, entdeckt hatte. Danach kam Stefan Ginsberg dazu, der momentan den Titel als jüngster ReactOS-Entwickler innehat, zusammen mit Cameron Gutman, noch ein Forenmitglied, der irgendwann in den IRC-Channel ging, um direkt mit den Entwicklern kommunizieren zu können. Zu diesem Zeitpunkt bekam auch Samuel Serapion, der bisher der zweite Schreiber für Newsletter war, Zugang zum Stammcode. Seitdem muss er noch einen anderen Newsletter schreiben. Die letzten drei waren Michael Martin, Gregor Schneider und Kamil Hornicek, welche jeweils einen Monat voneinander entfernt dazu stießen. Mit den zusätzlichen Mitarbeitern sieht die Zukunft von ReactOS auf jeden Fall vielversprechend aus.

Grafik

Da der Kernel sich etwas stabilisiert hat, kommt dem Untersystem für die Grafik mehr Aufmerksamkeit zu. Der Code ist schon ziemlich alt und beinhaltet einige Hacks, den Code zu reparieren ist jedoch der Schlüssel, um mehr Programme zum Laufen zu bringen. Dafür haben einige Entwickler mit etwas begonnen, was im Grunde eine Neuschreibung des Win32 Subsystems ist. Das primäre Ziel ist, bei der Implementierung der internen Architektur und der Datenstrukturen aufzuräumen, da einige davon nicht in der Implementierung von Windows existieren. So etwas geht natürlich nicht, wenn wir wirklich kompatibel sein wollen, also hat Timo Kreuzer damit angefangen, diese Strukturen aus dem Code zu entfernen. Einige dieser Strukturen sind eigentlich nur Kombinationen oder Verschmelzungen von existierenden Strukturen. Timo hat schon eine dieser ReactOS spezifischen Strukturen aus dem Code entfernt und Code der diese Struktur benutzte mit einer besseren Implementierung ersetzt, aber viele davon existieren immer noch, verteilt auf viele verschiedene Stellen. Alle davon zu ersetzen wird etwas Zeit in Anspruch nehmen, erst Recht dann, wenn der Code sich auf diese falschen Datenstrukturen gestützt weiterentwickelt hat.

Ein anderes internes Problem, das dieses Jahr viel Aufmerksamkeit bekommen hat, waren die Abhängigkeiten im Win32 Untersystem. Da die Entwicklung daran begonnen wurde, als noch nicht viele Informationen darüber öffentlich verfügbar waren, konnten über die Zusammenhänge nur Vermutungen angestellt werden. Das führte zu Schleifen in den Abhängigkeiten, also Module die auf den jeweils anderen aufbauen, statt einer top-to-bottom Struktur. Eric Kohl hat einige Zeit darin investiert, so etwas aus dem Code zu entfernen. Einer seiner Erfolge war, CSRSS dazu gebracht zu haben während der Initialisierung nicht mehr Shell32 zu benutzen, eine Komponente die bei der Initialisierung von CSRSS noch nicht geladen ist. Damit sind leider noch nicht alle Probleme mit Abhängigkeiten gelöst, aber Jim setzt seine Suche fort.

Ein drittes Problem mit der Architektur und dem Win32 Subsystem ist die Implementierung von ReactX, unserem DirectX-Ersatz. Magnus Olsen musste über das Jahr feststellen, dass dieses Unternehmen wohl länger dauern wird als zunächst gedacht, vor allem die Unterstützung für 3D-Hardwarebeschleunigung. Deswegen wurden zwei Übergangslösungen entwickelt. Die erste war Wine-Code zu benutzen, der DirectX Befehle in ihre jeweiligen OpenGL Gegenstücke übersetzt, die das gleiche auf ReactOS machen. Hardwarebeschleunigung unter OpenGL wird von ReactOS unterstützt, also kann dieser Trick dabei helfen die Leistung zu verbessern. Allerdings hat Magnus immer noch vor, eine bessere Implementierung ohne Umweg über OpenGL zu entwickeln. Die zweite Lösung war, das Win32 Subsystem soweit zu verbessern, das auch das originale DirectX von Microsoft damit arbeiten kann. Das würde bedeuten, die internen Strukturen auf denen DirectX aufbaut soweit zu verändern, dass sie identisch zu den Windows-Strukturen werden. Die Arbeiten um DirectX auf ReactOS zum laufen zu bringen, haben schon 2004 begonnen und beginnen sichtbaren Fortschritt zu zeigen. Der DirectX-Treiber lädt und einfache 2D-Hardwarebeschleunigung funktioniert, aber funktionierende 3D-Hardwarebeschleunigung ist noch etwas entfernt. Diese Arbeit entstand in Zusammenarbeit von Magnus Olsen, Timo Kreuzer, Jim Tabor, Maarten Bosma, Alex Ionescu und seit kurzem auch Kamil Hornicek. Natürlich gibt es noch viel zu tun, aber wir sind nun an dem Punkt angelangt, an dem es auch äußerliche Fortschritte gibt.

Letztlich sollte noch erwähnt werden, dass zu schwerwiegenden Veränderungen auch immer die entsprechende Fehlerbehebung gehört. Die Darstellung von einfacher Grafik wurde verbessert, jetzt da sie richtig dar gestellt werden, können auch mehr Programme benutzt werden. Einiges davon liegt an Code den wir von Wine entliehen haben, anderes haben wir unseren eigenen Entwicklern zu verdanken. Das war keine kleine Leistung, da das Beheben von Architekturfehlern im Win32 Untersystem Hacks auflöst, die benutzt werden damit Dinge korrekt dargestellt werden, also müssen die Win32 Entwickler sowohl lange existierende Probleme, als auch die Hacks die durch eine bessere Implementierung unbrauchbar werden, reparieren.

Dateisysteme und Speicher

Die Arbeiten an beiden Komponenten wurden gleichzeitig durchgeführt, da die Treiber für Dateisysteme erheblich von Diensten abhängen, für die die Speicherverwaltung zuständig ist. 2008 begannen die Arbeiten die Lücken zu füllen, die uns daran hinderten ein anderes Dateisystem als FAT32 zu benutzen. Die beiden größten Hintergründe sind die extrem unvollständige Laufzeitbibliotheken für Dateisysteme und die extrem fehlerhafte Implementierung des Gemeinsamen Caches.

Das Problem mit dem Gemeinsamen Cache ist schon länger bekannt, und es gab einige Ansätze ihn neu zu schreiben. Eigentlich ist der Gemeinsame Cache keine eigenständige Komponente, sondern bezieht die meisten Funktionen aus der Speicherverwaltung. Das heißt, dass wir für einen guten Gemeinsamen Cache eine gute Speicherverwaltung brauchen. Leider war das nicht der Fall. Der Gemeinsame Cache und die Speicherverwaltung müssen zu einem gewissen Grad getrennt werden, aber unsere Implementierung hat sie im Wesentlichen vermischt. Also war der erste Schritt sie auseinander zu bringen, was das Ziel des von NoCC war, womit Aleksey Bragin anfing und was zwischenzeitlich von Art Yerkes übernommen wurde. Aleksey sah für NoCC vor, die Funktionen herauszunehmen die die Speicherverwaltung liefern soll, damit wir die zugrundeliegenden Speicheroperationen reparieren können, um uns dann damit zu beschäftigen, was die Speicherverwaltung tun soll und was nicht. Als wir dann sicher waren, dass die Speicherverwaltung korrekt funktionierte, konnten wir anfangen Algorithmen für das Caching für die Speicherverwaltung zu implementieren. Art hat es tatsächlich geschafft, die beiden zu trennen, dabei entfernte er gemeinsame Dateistrukturen, mit denen man gar nicht erst hätte beginnen sollen. Dann implementierte er einen einfachen Caching Algorithmus und brachte ReactOS zum booten bis zur Grafischen Benutzeroberfläche, wo es dann abstürtzte. Wenn man bedenkt, dass die Speicherverwaltung am Anfang praktisch nicht existierte, wurde schon viel fertiggestellt, aber dieses Jahr muss noch einiges getan werden.

Die andere Komponente von der die Dateisystemtreiber stark abhängen ist die Laufzeitbibliothek für die Dateisysteme (FsRtl). Allerdings existierte diese nur im Ansatz, da FAT32 einfach genug ist, um mit wenig davon zum Laufen gebracht zu werden. Pierre Schweitzer kam eigentlich zu ReactOS um an der Entwicklungsumgebung mitzuarbeiten, ging aber 2008 zu FsRtl über. Er hat schon etwas Arbeit in einem seperaten Zweig gesteckt und sowohl in FsRtl selbst, als auch in Komponenten auf denen FsRtl aufbaut, fehlende Funktionen implementiert. Das ist eine weitere Sache die sich noch eine Weile hinziehen wird, aber wenn sie fertig ist, können wir ernsthaft damit anfangen, Unterstützung für neuere Dateisysteme einzubauen.

Portierungen

Zwei Projekte wurden 2008 gestartet, um ReactOS auf x64 und ARM zu portieren. Beide Projekte schreiten beachtlich voran. Die ARM Portierung ist nun am Punkt, wo die Initialisierung der User Mode Components im Bootvorgang integriert wird. Die x64 Portierung kommt etwas langsamer voran, hat aber auch Partial Boot. Beide Portierungen haben Probleme bei der Speicherverwaltung, der Arbeiten auch auf x86 Plattformen erleichtert. Einige Fortschritte des x64-Teils wurden noch nicht vollständig in den Trunk eingefügt, ARM allerdings schon. Trotzdem bieten die Fortschritte eine solide Grundlage für zukünftige Entwicklungen. Eine erfolgreiche Portierung würde viele neue Möglichkeiten für ReactOS eröffnen.

Infrastruktur

Während des letzten Jahres wurde einiges unternommen, um den Entwicklern dabei zu helfen produktiver zu sein. Neben des Serverupgrades wurde an einem automatischen System zur Überprüfung jeder Revision gearbeitet. Der erste Schritt wurde von Johannes Anderwald und Christoph von Wittich durch die Fertigstellung des Sysregprogramms vollzogen. Momentan läuft Sysreg auf den Buildmaschinen und unternimmt Winetests. Diese Tests werden nach dem ersten Crash unterbrochen. Letztendlich soll es alle Tests im ReactOStestmodul abschließen und die potentiell auftretenden Fehler außer Acht lassen, aber mitschneiden. Der Report, der von Sysreg generiert wird, ist sehr detailliert und wird in einer HTML-Version präsentiert. Colin Finck und andere Communitymitglieder haben daran gearbeitet dieses Webinterface weiterhin zu optimieren. Hoffentlich können wir an dieser Errungenschaft noch dieses Jahr teilhaben.

Ein weiterer wichtiger Beitrag waren die Updates für die Doxygenseiten des ReactOS Quellcodes. Ein Bug in vorherigen Versionen verursachte eine Endlosschleife, sodass niemand sich darum kümmerte Dokumentationen für neuere Revisionen zur Verfügung zu stellen. Dies hatte zur Folge, dass alle Dokumentationen hoffnungslos veraltet waren. Das System ist nun wieder voll funktionstüchtig und kann dafür verwendet werden, den Entwicklungsfortschritt zu begutachten. Außerdem liefert es eine gute Referenz für alle, die den Quellcode unter die Lupe nehmen möchten.

Bugzilla wurde auch einiger Verbesserungen unterzogen. Dank eines Debugartikels im Wiki können nun Leute, die Bugs melden möchten, ihren Bugreports detaillierte Informationen beilegen und erhöhen somit die Qualität dieser Beiträge. Bugzilla wurde außerdem entschlackt und besser in Stand gehalten. Die Änderungen reichen von der Markierung bereits ausgebesserter Schwachstellen, über die Entfernung doppelter Reports, bis hin zur Analyse eingereichter Patches, sodass die Entwickler diese schneller begutachten können.

Coverity Scanner

Urias McCullough, ein Mitglied der Haiku Community, machte uns mit Coverity vertraut und reichte bei ihnen unseren Quellcode für eine eingehende Analyse ein. Coverity nahm unser Open Source Projekt auf und wird mit ihrer Arbeit bedeutende Vorteile hinsichtlich der Qualitätskontrolle und der Vermeidung bestimmter Bugs erwirken.

Compiler

Die Abhängigkeit vom Standardcompiler GCC bereitete größere Probleme. Dieser Compiler unterstützt kein Structured Exception Handling, weshalb KJK::Hyperion eigens die PSEH Library entwickeln musste, um diese Schwäche auszugleichen. Die Library wurde Ende letzten Jahres auf Version 2.0 upgedatet, hat allerdings noch einige Kinderkrankheiten, an denen KJK arbeitet. Trotzdem sollte sie es uns ermöglichen eine Exception Handling Scheme zu benutzen, die sich im Quellcode für GCC und MSVC gleicht. Diese Kompatibilität zu erreichen wäre sehr nützlich, weil KJK auch schon Versuche unternommen hat, ReactOS auf MSVC (Microsoft Compiler) zu kompilieren. Diese beiden werden uns dabei helfen, die Qualität des Codes spürbar zu verbessern.

Community und finanziell unterstützte Konzepte

Oft vorgeschlagen, jedoch bis Mitte 2008 nicht realisiert: Die schnellere Bearbeitung der durch den Spender gewählten Programmkomponenten. Das Ganze wird durch die CFI (Community Funded Ideas) gestützt, um es den Programmierern zu erlauben die nötige Zeit ins Programmieren zu investieren, ohne sich dabei um finanzielle Engpässe im Privatleben zu sorgen. Einige Projekte wurden bereits erfolgreich mit nennenswerten Spendenbeträgen unterstützt und wir hoffen natürlich, dass sich CFI auch insgesamt als erfolgreich erweisen wird. Das Projekt wird weiterhin noch geplant und organisiert, aber einige Entwickler haben schon damit angefangen, an den vorgeschlagenen Komponenten zu arbeiten.

Also, wie man sieht, hat sich letztes Jahr viel verändert und ReactOS ist seinem Ziel, Windows-kompatibel zu sein, ein Stückchen näher gekommen ;-)