Firefox Timer-Bug umgehen

Im IRC-Channel habe ich gerade erfahren, dass man den Timer-Bug leicht umgehen kann (damit Firefox die Websiten und Downloads fertig lädt, muss man eigentlich eine Taste drücken oder die Maus bewegen).

Lösung: Man öffnet den Task-Manager und stellt die Aktualisierungsrate auf Hoch. Nun den TaskManager nicht schließen!, sondern Firefox benutzen. Dadurch fällt das ewige Maus-Bewegen weg....

Anwendungen, die auf ReactOS laufen

Ich habe heute morgen einige Programme in ReactOS Trunk vom 23.Februar 09 getestet.
Hier die Ergebnisse:
Firefox 2.0.20 für Windows funktioniert sehr gut in ReactOS. Es hat nur ein paar kleinere Fehler: z.B. werden die Werkzeug-Buttons manchmal nicht richtig angezeigt. Außerdem hat Firefox einen Timer-Bug, durch den die Webseiten nicht vollständig geladen werden. Hier hilft allerdings schon eine einfache Mausbewegung, damit Firefox die Website komplett anzeigt.


Während meinem Test hat Opera 9.63 Fehlerfrei funktioniert!
Sogar das Zoomen hat funktioniert!






Code::Blocks ist zwar nutzbar und kompiliert auch, aber es hat einige "Drawing-Bugs". (Bild: Hello-World Beispiel)






Mit Hilfe von SumatraPDF konnte ich all meine PDF-Dateien Problemlos in ReactOS anzeigen lassen.






Foxit-Reader hatte schon während der Installation Probleme: In einer Fehlermeldung kurz nach Starten des normales Installers hat er angezeigt, dass die Datei Setup.exe keine PDF-Datei ist....(irgendwie logisch...)
Die Installation mit dem MSI-Installer lief allerdings Problemlos.
Außerdem hat das Programm (ähnlich wie Firefox) Probleme beim anzeigen der Werkzeug-Buttons, konnte mir aber trotzdem meine PDF-Dateien Fehlerlos anzeigen.

Der FreeCommander lässt sich in ReactOS Fehlerfrei installieren. Aber leider kann man diese gute Explorer-Alternative nicht verwenden. Nach einem Doppelcklick auf das FreeCommander-Icon zeigt er eine Fehlermeldung an (siehe Bild rechts).

(Den TotalCommander habe ich auch getestet: Er ist installier und Startbar. Allerdings zeigt er fast keine Icons an und man kann in keinen anderen Ordner wechseln - In ReactOS 0.3.8 hat dies alles noch funktioniert....)

Notepad 2 Funktioniert PERFEKT in ReactOS!








Und auch Notepad++ lief in meinem Test Fehlerfrei. Ich habe zum testen auch ein 900MB großes Archiv geöffnet....Nach langer Zeit hat er auch dies geöffnet...




Ich habe PhotoFiltre eine Stunde lang getestet. Es ist nicht ein mal abgestürzt. Alle von mir getesteten Funktionen haben Funktioniert. Auch die Masken. (siehe Bild)




Firefox 3 und OpenOffice 3 waren in ReactOS während meinem Test nicht benuzbar. OO konnte man noch nicht mals komplett installieren :-\

Winamp und Sound

Momentan wird in ReactOS an der Sound-Unterstützung gearbeitet.

Mitlerweile ist dies so weit, dass Winamp in ReactOS läuft und: Wenn man den Treiber von NT4 benutzt, hört man sogar Sound !


Edit:
Der Commit 39702 hat auch was interessantes drin :
"ReactOS can now play a wave tone"

ReactOS läuft auch auf 32 MB-Ram-Rechnern!

Vielleicht kennt ihr die als sehr ressourcensparend geltende Linux-Distribution "DeliLinux".
Diese (meiner Meinung nach zu extrem abgespeckte) Distri läuft 'erst' ab 64MB RAM vernünftig im GUI-Modus....

Seit kurzem ist ReactOS auch auf Systemen installierbar, welche nur 32 MB RAM haben!

Im ReactOS-IRC Channel habe ich gerade gelesen:
Net.Framework 2.0 sei in ReactOS mit einem Hack INSTALLIERBAR!!! :D

ReactOS wird immer besser und besser!

PS: Ich habe einen WEB-IRC-Clienten in dieses Blog eingebaut. Mit diesem kann man auch bei gesperrten Ports (z.B. Arbeitsplatz, ...) im Channel #reactos mitlesen/schreiben!

PPS: Nun kann man auch als nicht-Registrierter einen Kommentar in diesem Blog posten. Einfach unter dem jeweiligen Beitrag auch Kommentar klicken.

Mein weg zum ReactOS-Entwickler

Hallo,

ich möchte bald am ReactOS-Projekt als Entwickler helfen.
Als Unterstützung für all diejenigen, die auch ein ReactOS-Entwickler werden möchten, protokolliere ich hier mein vorgehen.

Was sollte man machen, um das ReactOS-Projekt zu unterstützen und dabei :

• ReactOS-Website durchlesen
• so oft wie möglich im ReactOS-IRC-Channel mitlesen
• (die Website des Projekts mit übersetzen)
• einige ReactOS-Mailing-Listen abonnieren
  
• C und/oder C++ lernen... ( http://tutorials.at/c/ oder GalileoComputing C von A bis Z )
  
• regelmäßig das neueste Trunk-Build downloaden und in einer VM oder auf realer Hardware Testen + Bugs in Bugzilla melden
• ...

Ich habe mich heute in die ROS-Diffs-Mailingliste (Liste für übertragene Änderungen) eingetragen.
Außerdem untersuche ich jetzt den Quellcode von manchen Programmen und versuche, z.B. ein anderes Hintergrundbild beim Starten des Systems anzeigen zu lassen. Dadurch lerne ich den Aufbau des ReactOS-Systems kennen....

(Bald kommt mehr.....)
PS: Wenn jemand Tipps für mich hat, kann er diesen als Kommentar posten.

FOSDEM 2009!

Auch ReactOS war auf der FOSDEM 2009 in Brüssel!

Was FOSDEM ist?

Die FOSDEM (Free and Open source Software Developers' European Meeting), ursprünglich nur OSDEM (Open Source Developers' European Meeting), ist eine Konferenz zum Thema Freie Software, die seit 2001 jährlich in Brüssel, Belgien abgehalten wird. Die zweitägige Konferenz wird von Freiwilligen organisiert und findet Ende Februar statt. Im Jahr 2004 nahmen 2500 Leute daran teil. Der Eintritt zu allen Teilen der FOSDEM ist frei, Spender und Sponsoren werden jedoch gebeten, bei der Finanzierung des Treffens zu helfen.

Das Video von den ReactOS Entwicklern, die dort waren, kann man sich hier online ansehen oder runterladen:
http://stuff.silverblade.co.uk/reactos/

Was ich im ReactOS IRC-Channel gelesen habe:

Hallo,
folgendes habe ich heute Mittag (09.02.09) im IRC Chat gelesen:
Opera läuft in ReactOS!

Außerdem hat gyROS (ReactOS-Forum-Member) eine alternative zu Microsoft Paint ( ReactOS Forum ) geschrieben, die nun zur Fehlersuche von Grafikproblemen genutzt werden soll und später evtl. in ReactOS integriert wird.

Wine DirectX ist mittlerweile so weit,
dass selbst neuere Spiele, wie z.B. GTA Vice City in ReactOS spielbar sind. Es wurde allerdings nicht in ReactOS 0.3.8 integriert.



Der ReactOS Entwickler MindChild arbeitet im Moment an einem neuen VB-Runtime-Ersatz. Dieser wird von einigen Business-Anwendungen benötigt.

Außerdem wurde darüber diskutiert, ob und wie Dosbox zum ausführen von Win16 Programmen genutzt werden soll. Dabei haben die Entwickler einen Fehler in ReactOS gefunden, der anscheinend von Pigglesworth für ReactOS 0.3.8 mit einem Hack umgangen wurde. Durch diesen Bug stürzt/-e DosBox nach dem öffnen ab.

RosBE 1.4 Veröffentlicht!

Am 03.02.2009 wurde eine neue Version von RosBE, das Build Environment für ReactOS, veröffentlich.

Dokumentationen dazu sind hier: http://danielreimer.5x.to/documentation/index.html

Und hier der Download: sourceforge

Mehr Informationen dazu in Reimi's Blog.

Neue Version von ReactOS verfügbar!

Die Entwickler von ReactOS haben am 04.02.2009 die neue Version 0.3.8 veröffentlicht.
Es wurden viele Teile des Systems verbessert.
Die neue Version enthält verschiedene Fehlerkorrekturen und Verbesserungen für Systeminterna wie die Registry und die I/O-Funktionen im Kernel. Speziell dem Betriebssystemkern wollen sich die Entwickler jetzt widmen, um die verbleibenden instabilen Teile zu verbessern. Dazu zählen z.B. die Speicherverwaltung und der Caching-Code für das Dateisystem.

Die neue Version verbessert außerdem die Bibliotheken CRT und RTL und verschiedene GDI-Probleme wurden beseitigt. Außerdem arbeitet der Grafiktreiber nun besser. Die ReactOS-Teile, die aus Wine stammen, haben die Entwickler aktualisiert.

Allerdings sollten Sie folgendes Entwicklerzitat bedenken:

Bitte beachten Sie, dass es sich zusammen mit der restlichen 0.3.x-Serie lediglich um Alpha-Versionen handelt, weshalb einige Applikationen unzureichend beziehungsweise gar nicht auf Ihrer Hardware laufen werden.

Die Änderungen zusammengefasst:

• Behebung verschiedener Fehler und Einbau von Erweiterungen in den Diensten des Kernelkerns (z.B. Registry, Systeminformationsroutinen, Sync Elemente wie Guarded Mutex, I/O Unterstützung...)
• Es wurde damit angefangen, die verbleibenden instabilen Teile des Kernels fertigzustellen: Speicherverwaltung, Caching Code und die APIs der Dateisystemtreiber und andere mit der Speicherverwaltung zusammenhängende Dinge
• Einführung einer neuen "Portable Structured Exeption Handling" Vorrichtung (PSEH 2.0), welche sich viel mehr an dem nativen SEH Syntax des Compilers orientiert
• Beseitigung einiger Altlasten (wie die Unterstützung von Festplatten mit mehreren Partitionen durch die LiveCD, die Auslastungskurve der CPU im Taskmanager)
• Behebung verschiedener Darstellungsprobleme der GDI
• Implementierung einer Open Source Minimalversion des KernelDebugger Protokolls, das Grundfunktionen von WinDbg ermöglicht
• Verbesserung der CRT und RTL Libraries
• Behebung einer Reihe von Problemen in den Treibern des Grundsystems (NPFS, CDFS, FASTFAT, FS_REC und SCSIPORT)
• Verbesserung der Anzeigentreiber für bessere Unterstützung von echter Hardware
• Die Arbeiten am Win32 Subsystem wurden fortgeführt
• An der Unterstützung für MSVC wurde weitergearbeitet
• Entwicklung von Fehlerbehebungen und Verbesserungen für die Tool Chains (auch als Teil der Arbeiten zur MSVC Unterstützung)
• Aktualisierung der von Wine entnommenen Grundtools und Komponenten auf die neueste Version

Eine detailliertere Liste der Änderungen findet sich im Changelog auf der Website des ReactOS-Projekts.
(Quelle: http://www.reactos.de/de/news_page_49.html )

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 ;-)