Auszug aus dem IRC-Chat-Protokoll

Thema: Releasetermin für 0.3.9 und Unterschiede zwichen 0.3.8 und 0.3.9
----------------------
----------------------
(20:02:05) aicom|ros: Fireball: when do you plan on releasing 0.3.9?
(20:02:16) Fireball: in 2 months after 0.3.8 was released
(20:02:27) aicom|ros: heh
(20:02:32) Caemyr: Fireball!!
(20:02:34) Caemyr: hiya
(20:02:46) elhoir: so, April
(20:02:59) elhoir: (6 days to go? :-P )
(20:03:03) Caemyr: :>
(20:03:04) Caemyr: in
(20:03:07) Caemyr: not at the begining of
(20:03:20) elhoir: ah.. :D
(20:03:20) Geoz: put a serial key check in setup
(20:03:50) Geoz: although only if it can be released for the 1st
(20:03:56) Fireball: hi Caemyr
(20:04:07) Fireball: elhoir - yes, beginning of april preferably
(20:04:16) d0g: 1st
(20:04:18) elhoir: uhh.. i was joking, you know
(20:04:24) Fireball: heh
(20:04:28) Caemyr: ummm
(20:04:31) Caemyr: are we ready?
(20:04:48) Caemyr: there are some... commits... to be... tested extensively
(20:05:13) d0g: what are the major improvements since 0.3.8 so far ?
(20:05:27) elhoir: audio of course!!!
(20:05:29) aicom|ros: SSL pages work in firefox
(20:05:30) Colin_Finck: oh, talking about 0.3.9...
(20:05:40) aicom|ros: and SSL connections work in thunderbird
(20:05:43) elhoir: also, usb mice and kb
(20:05:47) Geoz: stability / audio / initial USB
(20:05:50) aicom|ros: and the loopback adapter works properly
(20:06:03) Geoz: and network fixes of course
(20:06:09) Colin_Finck: and ROS is less memory hungry :)
(20:06:18) Colin_Finck: = more support for older PCs
(20:06:22) aicom|ros: the network stack doesn't crash very much anymore
(20:06:24) elhoir: yup
(20:06:26) Colin_Finck: I can run it on my CrapTop again :)
(20:06:29) Geoz: ah yeah, Alex_Ionescu's stage 1 patch
(20:06:34) Fireball: Caemyr - no we aren't, yet
(20:06:44) Fireball: but there is enough of progress for a release
(20:06:49) ***aicom|ros hasn't had a network crash since he fixed the TdiReceiveDatagram bug
(20:07:05) elhoir: Colin_Finck: will it be a 0.3.10 release?
(20:07:34) elhoir: (or Fireball)
(20:08:03) Geoz: that is an idea if 0.4 is quite "0.4" enough ;)
(20:08:17) Geoz: but w/e, it's all good
(20:08:25) elhoir: yeah
(20:08:39) Caemyr: Geoz: it depends on USB status
(20:08:45) elhoir: its just to know what i have to type when updating the web page :)
(20:08:53) ***aicom|ros 's last network related crash was fixed by 40183
(20:08:55) Fireball: elhoir - I hope not
(20:08:59) aicom|ros: and I haven't had one since :D
(20:09:11) elhoir: Fireball - great!!!

Links: ReactOS-Wiki: 1. Version_Status, 2. CFI

Hier noch 2 interessante Links zu Artikeln aus dem ROS-Wiki, die jeder mal gesehen haben sollte...:

• http://www.reactos.org/wiki/index.php/Version_Status
• http://www.reactos.org/wiki/index.php/CFI

Ros-Dev-Mailings:: Google Summer of Code

Hier eine Mail aus der Ros-dev mailing list:

Hi,

I'd like to let you know our application has not been accepted into Google Summer of Code, for the third time in a row. I attached an (autogenerated) reply, which encourages us to reapply for future instances of the program. I would not find a better way to express sarcasm than asking us to reapply in future.

Amongst accepted organizations there are:

WinLibre - a distribution of opensource software for Windows platform.

Battle for Wesnoth - a free turn based strategy game.

Umit - a frontend for a network scanner (one of their GSoC ideas is to create a "Umit Assistant" which would look like a Clippit - the animated assistant that features Microsoft Office).

TurboGears - a web framework written in Python.

Thousand Parsec - a bunch of games based on a common framework for building turn based space empire building games.

Systers: Woman in computing - a community of women in computing. For some strange reason the founding person is "Robin".

Singularity Institute for Artificial Intelligence - non-profit org founded to develop safe artificial intelligence software and to raise awareness of dangers of AI technologies.

I just stated a few examples. I highly value those projects, however I just can't understand that yet another framework in python, or a game engine for a turnbased strategies, or a collection of FOSS software for Windows with a package manager (which we already have, and which could have been improved), or an institution which believes that AI takes over the world and tries to stop that are way more important than supporting an organization whose product would be of use for millions of people, and would create a real alternative operating system compatible with the vast majority of existing software and hardware.

Our friendly OS project Haiku gets accepted every year, so being an OS is not a problem.

Wine is certainly accepted every year from the beginning, and this year is not an exception. So it's definately not a problem of "legal fear" of Microsoft.

What is the problem then? I leave it to you to decide what's the problem. However, as for me, I see Google Summer of Code is nothing close to supporting free software world, but rather an expensive way of advertising.

I want to hope I am wrong.

With the best regards,

Aleksey Bragin

ReactOS Foundation President.

---------- Forwarded message ----------

From: <socghop.noreply@gmail.com>

Date: Thu, Mar 19, 2009 at 12:48 AM

Subject: Thank you for your application

To: xxx@reactos.org

Hi Aleksey Bragin,

Thank you for submitting "ReactOS" organization application to Google Summer of Code 2009. Unfortunately, we were unable to accept your organization's application at this time. We received many more applications for the program than we are able to accommodate, and we would encourage you to reapply for future instances of the program.

Best regards,
Google Open Source Programs

______________________________

_________________
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

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

ReactOS Newsletter #54

Hier der aktuelle Newsletter von reactos.org:

Speichernutzung

Die Mindestanforderungen an Arbeitsspeicher von ReactOS sind seit einiger Zeit langsam angestiegen, hauptsächlich wegen des Installers. Eigentlich war den Entwicklern bekannt, dass der Speicherverbrauch von ReactOS nie so hoch war wie während der Installation. Die meisten vermuteten, dass irgendwo ein Speicherfehler auftrat, entweder im Installer selbst oder sogar in der Speicherverwaltung. Es war ein Fehler, von dem viele wollten dass er behoben würde, es aber erst wurde, als sich Alex Ionescu des Fehlers annahm. Es stellte sich heraus, dass das Problem nicht nur den Speicher betraf, sondern auch das automatische Laden von Debugging-Symbolen. Dieses Problem war gelöst indem man ReactOS dazu brachte, die /LOADSYMBOLS Flag zu akzeptieren, das Problem mit dem Speicher zu beheben war etwas aufwändiger. Um die Herkunft des Speicherfehlers ausmachen zu können, änderte Alex zunächst die Anzeige im Installer, so dass sie nicht mehr ausgelagerten und nicht ausgelagerten Speicher sondern den Kernel-Cache und den Kernel-Pool anzeigte. Er entfernte auch einen Hack, der bisher dazu geführt hatte, dass der Installer bei mehr als 40% Speichernutzung angehalten wurde. Er machte weiter mit der Reperatur der Speicherverwaltung und des gemeinsamen Caches, was die Anforderungen an den Speicher auf 24 MB reduzierte. Bei dem Problem ging es um in den Kernelspeicher gecachte Daten, die nie freigegeben wurden und so die verfügbaren Ressourcen verbrauchten. Auch die sonstige Installation von Programmen sollte nun weniger Speicher verbrauchen. Dazu ging die Mindestspeichernutzung des Betriebssystems nach dem Bootvorgang herunter auf 20 MB. Ich bin sicherlich nicht der Einzige, der diese Arbeiten mehr als zu schätzen weiß.

CSR

Die Komponente CSRSS verwaltet die Konsole und ist noch ein Überbleibsel aus früheren Zeiten, als der Code von ReactOS noch ein einziges Chaos war. Timo Kreuzer verbrachte einige Tage damit, den entsprechenden Code durchzusehen und die CSR_API_MESSAGE Datenstruktur zu reparieren. Sie wird für CsrConnectToServer und die korrekte Initialisierung von User32 gebraucht, das wiederum Nachrichtenweiterleitung, Fenster und andere für die Funktion von Windows notwendige Dinge erledigt. Die originale Version in ReactOS war fehlehaft und wurde deshalb auch von CsrClientConnectToServer nicht richtig benutzt.
Allerdings benutzt eine Komponente irgendwo in der ReactOS Code-Datenbank eine fest programmierte Größe für diese Datenstruktur, also enden alle Versuche Benutzer hinzuzufügen oder zu entfernen mit einem Absturz. Timo versuchte zwar das zurückzuverfolgen, aber vergeblich. Er hat die Komponente momentan aufgegeben für die Zeit in der er durch den Code schauen muss. Dafür kann ich ihm wirklich keinen Vorwurf machen. Es gibt Codezeilen, in welchen jemand mehrfache Typumwandlungen durchführte, zuerst zu einem allgemeinen Zeigertyp, dann wurde der Zeigeradresse von der Größe einer Datenstruktur inkrementiert und dann wiederum in einen anderen Zeigertyp umgewandelt, je nach Bestimmung des Zeigers. Jeder mit auch nur einem Minimum an C-Kenntnissen würde bei solchem Code erschaudern, da solcher Code sowohl unschön aussieht als auch fehleranfällig ist.

Netzwerk

Es ist schon eine Weile her, seit Art Yerkes zum ersten Mal den Netzwerk-Stack zum Laufen gebracht hat. Seitdem hat Cameron Gutman ihn weiter vorangebracht, wobei er versuchte, den Code zu Verbessern und neue Funktionen zu implementieren. Viel davon fand in einem Programmzweig statt, das meiste wurde allerdings in den Programmstamm übernommen. In letzter Zeit hat sich Art nun die Zeit genommen, um sich um einige sehr lange bestehenden Bugs zu kümmern, da er mittlerweile ein besseres Verständnis von Netzwerkstack und -protokollen hat.

Außerdem hat Art noch einiges anderes am Code gearbeitet, vor kurzem hat er ein Problem mit Prüfschleifen behoben. Um sich mit einem Empfangssockel verbinden zu können, muss die Zugriffsadresse entweder 0 sein oder mit der Adresse eines Adapters übereinstimmen, auf den die Anwendung zugreifen kann. Programme, die eine Prüfschleife empfangen müssen, brauchen entweder die Adresse 0 oder 127.0.0.1. Im ersten Fall kann die Anwendung Daten von allen Adaptern empfangen, während im zweiten Fall nur der Empfang lokaler Daten möglich ist. Jedoch wurde unter ReactOS Anwendungen, die auf die Adresse 0 zugreifen wollten, stattdessen nur Zugriff auf die Adresse des ersten gefundenen Adapters gewährt. Das bedeutete in den meisten Fällen, dass diese nicht mehr länger die lokalen Daten empfangen konnten, und Anwendungen, die aus diesem Grund von der Adresse 0 abhingen, abstürzten. Art fand und behob das Problem, so dass der Zugriff auf die Adresse 0 wieder funktioniert.

Eine andere Sache die Art behob, war die falsche Behandlung von IRP_MJ_CLEANUP und IRP_MJ_CLOSE. Am Anfang wusste Art nicht, was diese zwei wirklich taten. Die Aufgabe von IRP_MJ_CLEANUP ist es, alle laufenden IRPs für das aktuelle Objekt anzuhalten, die von IRP_MJ_CLOSE ist es, das Objekt an sich freizugeben. Allerdings behandelte ReactOS die beiden IRPs als gleich, und gab das Objekt frei, wann immer eines davon aufgerufen wurde. Da aber ReactOS nach dem Aufruf von CLEANUP ein laufendes Objekt erwartete, gab es Probleme mit fehlenden Ressourcen.

Sound

Die Arbeiten am Sound sind schon soweit fortgeschritten, dass Andrew Greenwood Winamp zum Abspielen von Musik verwenden kann. Dies funktionierte zwar theoretisch schon früher, aber nur mit sndblst.dll aus NT 4. Nun ist es auch möglich die von Andrew geschriebene sndblst.dll zu verwenden. Bisher kann allerdings nur eine Datei auf einmal abgespielt werden, da Andrew noch nicht untersucht hat, wie sie sich mit mehreren Streams verhält. Theoretisch müsste die DLL eine Warnung ausgeben, dass das Gerät schon benutzt wird. Kernel Streaming funktioniert noch nicht, zumindst nicht für Andrew. Wdmaud.drv zur Kommunikation mit Johannes Anderwald's Code zu bewegen, würde mehr Zeit verbrauchen als sndblst.sys, das Gegenstück zu sndblst.dll auf der Seite des Kernels, zu schreiben.

Zielplattform

Die Version von Windows, die ReactOS anstrebt, hat seit einiger Zeit für Verwirrung gesorgt. Es gibt nämlich zwei spezifizierte Ziele, den NT-Kernel und das Win32 Subsystem. Offiziell hat der Kernel von ReactOS immer noch den Kernel von Server 2003 (NT 5.2) als Ziel. Dieses Ziel ändert sich nicht sehr häufig. Andererseits orientiert sich das Ziel des Win32 Subsystems an der jeweils aktuellsten veröffentlichten Windows-Version, zur Zeit also Vista. Deshalb gibt es des öfteren Updates und Implementierungen, die Vista-basiert sind. Wenn Windows 7 veröffentlicht wird, wird sich das Ziel des Win32 Subsystems wiederum ändern, was aber nicht unbedingt auf das Ziel des Kernels zutrifft.