ReactOS Newsletter #55

Das ReactOS Tam hat am 18.03.2009 einen neuen Newsletter veröffentlicht.
Dieser wurde von Phlox übersetzt.

Font Engine

Es gibt einen Unterschied zwischen korrekter Funktion und korrekter Implementierung, was man im Hinterkopf behalten muss wenn man sagt, dass etwas unter ReactOS funktioniert. Im Falle von Textrendering sieht das Ergebnis zwar fast korrekt aus, aber die darunterliegende Implementierung ist alles andere als wie sie sein sollte. Der verkürzte Funktionsaufrufsvorgang für die Anzeige von Text ist TextOutA/W, NtGdiExtTextOutW und GreExtTextOutW. Es gibt einige Varianten, aber das Beispiel vermittelt schon einen guten Einblick in den Weg zur Gre Funktion. Nun hatte aber ReactOS GreExtTextOutW nicht, und das Win32k Modul rief eigentlich NtGdiExtTextOutW auf. Da NtGdiExtTextOutW die Systemfunktion ist, welche auf Speicher des Benutzermodus zugreift und daher sicherstellt, dass die Puffer aus dem Benutzermodus stammen, sollte die Funktion im Kernel-Modus mit Kernel-Modus Puffern überhaupt nicht funktionieren. Dass es trotzdem funktionierte, lag an einem Fehler in MmCopyFromCaller, das benutzt wird vom Usermode Puffer in den Kernel Mode zu kopieren. Diese Funktion sollte einen Usermode Puffer überprüfen und die Daten in einen KernelMode Buffer kopieren. Die Überprüfung funktionierte aber nicht und erlaubte so Win32k NtGdiTextOutW zu benutzen. Zu allem überfluss sollte MmCopyFromCaller eigentlich gar nicht existieren. Es handelt sich um eine Spezialität von ReactOS und NtGdiExtTextOutW sollte eigentlich SEH zur Überprüfung der empfangenen Puffer benutzen. Win32k soll GreExtTextOutW benutzen, da es die Kernel Mode Puffer verarbeitet und GreExtTextOutW auch erwartet Kernel Mode Puffer zu erhalten. Also vertraut es ohne Überprüfung was auch immer weitergegeben wird. Das tritt häufig bei Funktionen auf, die nur für Aufrufe vom Kernel Mode aus entworfen sind.

Die andere Sache bei der sich ReactOS weigerte, war die Benutzung der STROBJ/ESTROBJ Datenstruktur, welche dazu genutzt wird eine Gruppe von Zeichen und deren Positionen darzustellen, also das was einen Text ausmacht, den man angezeigt haben will. GreExtTextOutW ruft ESTROBJ::vInit auf um die Struktur zu initialisieren, wobei auch die nötigen Daten zum Ausfüllen und Erledigen der Koordinaten-Übersetzung übergeben werden. Die STROBJ::vInit Funktion verwendet auch Informationen der RFONTOBJ Struktur über die Zeichen einer Schriftart. Am Ende wird die STROBJ Struktur entweder an EngTextOut oder an die DrvTextOut Funktion weitergeleitet. Das Eng Präfix bezieht sich auf Funktionen in Win32k die sich als Reserve verhalten für den Fall, dass der Bildschirmtreiber keine spezifischen Funktionen implementiert hat, welche in diesem Fall die DrvTextOut Funktion ist. Das Problem in ReactOS ist allerdings, dass weder die STROBJ noch die RFONTOBJ Datenstruktur existiert, was somit auch auf den gesamten oben beschriebenen Vorgang zutrifft. Zudem ist in der ReactOS Version von Win32k EngTextOut nicht implementiert und es ignoriert eine bestehende DrvTextOut Funktion.

Timo Kreuzer arbeitet daran, diese Situation zu korrigieren und sitzt bereits eine Weile an einem Font Treiber. Die oben erwähnte RFONTOBJ Datenstruktur agiert auch als Cache für die bereits gerenderten Glyphen. Wenn ein Glyph jedoch das erste Mal gerendert wird, wird ein mit der RFONTOBJ Struktur verbundener Font Treiber angesprochen. Der Font Treiber hat eine Funktion namens DrvQueryFontData, welche das Rendern des Glyphen erledigt und entweder eine Bitmap oder einen Outline zurückgibt. Der nächste Schritt ist die eigentlichen RFONTOBJ und STROBJ Datenstrukturen zu implementieren und dann die für Text Rendering zuständigen Funktionen neuzuschreiben, um sie zu nutzen. Das sollte sie für das nächste Jahr beschäftigen.

Nachdem wir alles erklärt haben, was ReactOS gerade nicht tut, wäre es nachlässig nicht zumindest zu erwähnen was es tut, egal wie falsch es ist. Statt für Glyph Informationen durch den Font Treiber zu agieren, wird alles oben erwähnte umgangen und die Freetype DLL direkt aufgerufen. Und da die EngTextOut und DrvTextOut Funktionen keine Rolle beim Text Rendering spielen, ruft GreExtTextOut einfach Freetype auf, um die Glyphen zu rendern und nutzt dann entweder EngBitBlt oder DrvBitBlt, um sie anzuzeigen. Ein weiteres gutes Beispiel, dass den verqueren Zustand innerhalb der ReactOS win32k zeigt.

Netzwerk

Wie schon im vorigen Newsletter erwähnt, hat Cameron Gutman sich mit dem Netzwerkstack beschäftigt, seitdem Art Yerkes die erste Implementierung fertiggestellt hat. Er hat hauptsächlich Fehler ausgemerzt, wie z.B. Irp(I/O request packets) Abbrüche, die den Ping Befehl abstürzen ließen. Viel von seiner Arbeit, die sich über den gesamten Netzwerkstack verteilt, ist schon in den Versionen 0.3.6 und 0.3.7 eingebracht worden. Die Probleme reichten von richtiger Ressourcenzuweisung und Freigabe bis zur Rückgabe von Statusmeldungen in Abhängigkeit vom erfolgreichen abschließen einer Operation.

Twitter

Ged Murphy hat letztens einen öffentliche Twitter Gruppenaccount erstellt, über den interessierte Entwickler Updates/ Tweets (Neuigkeiten) verkündigen können. Diese Updates werden mit der Tweet Methode gesendet und von jedem der dem Account "folgt"(die Nachrichten abonniert) erhalten. Jeder der sich als ein ReactOS "follower"(abonnent) registriert, wird automatisch vom ReactOS Account gefollowed. Das bedeutet, dass sie berechtigt sind in Gruppen Tweets involviert zu werden, die sich über alle Followers erstrecken. Um einen Gruppern-"Tweet" zu senden, sendet man einfach eine Nachricht direkt an ReactOS anstatt einer @replay und der GruppenTweet kümmert sich um den Rest. Möglicher zukünftiger Nutzen umfasst Updates/ Neuigkeiten während Zusammenkünften(z.B. FOSDEM).