Montag, 5. Oktober 2009

Blogging-Pause

Wie ihr sicherlich schon bemerkt habt, habe ich schon länger nicht mehr hier gebloggt.
Ich bin seit dem 3. September 09 für 9 Monate hier in den USA als HighSchool-Student.
Dadurch habe ich nicht mehr so viel Freizeit wie ich in Deutschland hatte.

Ich werde auch weiterhin noch die wichtigen neuerungen im englischen React-OS-Blog posten (http://reactos-blog.blogspot.com) außerdem erscheinen ab und zu auf der Reactos-Website neue Newsletter.

Hier eine Zusammenfassung, der News der letzten Wochen:
  • neue Kompatibilitäts-Datenbank (Link)
  • seit Revision 43009 funktionieren nun zusätzlich auch neuere Versionen des VLC-Media-Players
  • ReactOS hat nun ein neues Programm zur Verwaltung von Software: ReactosApplicationManager (rapps.exe)
  • Daniel Reimer hat einiges an RosBE verändert (Bugfixes,...) - weiter Infos hier und RosBE 1.5 Beta 1 kann nun hier gedownloadet werden (Achtung: Beta!! Stable ist 1.4.4!)
  • Neue Screenshots findet ihr hier und hier.

Falls einer von euch Lust und Zeit hat, die nächsten 2-3 Monat hier das Blog weiter zu machen, dann kontaktiere mich bitte per mail (hp.stefan @ gmail [antispam].com)

Sonntag, 23. August 2009

Neu: ReactOS Application Manager

Vor etwa einer Woche wurde in ReactOS das Programm "Download!" durch "ReactOS Application-Manager" ersetzt.

Ihr kennt sicherlich den Satz: "Ein Video oder Bild sagt mehr als tausend Worte":


(genaueres dazu im ReactOS-Forum)

Sonntag, 16. August 2009

NT-Architektur: Was ist … User- und Kernel-Mode?

Die meisten Betriebssysteme haben Programme zum Anzeigen der CPU-Ausnutzung. In Windows heist dieses Program Task Manager.

Die CPU-Auslastung wird generell einfach als Prozentzahl für die CPU-Zeit, welche für nicht-Leerlauf-Tasks verwendet wird, angegeben. Aber das ist nur eine vereinfachte Darstellung. In jedem modernen Betriebssystem arbeitet die CPU eigentlich in zwei sehr unterschiedlichen Modi:

  1. Kernel Modus

Im Kernel-Modus hat jeder auszuführende Code vollständigen und uneingeschrenkten Zugriff auf die Hardware des gesamten Systems. Es kann beliebige CPU-Anweisungen ausführen und auf jede Speicheradresse zugreifen. Der Kernel-Modus ist generell nur für sehr hardwarenahe Anwendungen, den SystemKernel und die kritischen Treiber reserviert. Crashs in Kernel-Modus sind katastrophal, da der System-Kernel die Systemfunktionalität danach nicht mehr gewährleisten kann und sich das System automatisch abschaltet (bzw. Anzeige des Bluescreens bei Windows).

  1. User Modus

Im User-Modus hat der auszuführende Code keine Möglichkeit, direkt auf Hardware oder Speicheradressen von anderen Programmen, zu zugreifen. Code, der im User-Modus läuft, muss System-APIs benutzen, um auf Hardware oder Speicher zugreifen zu können. Durch diese Art von Isolation, sind Crashs im User-Modus-Code immer abfangbar und gefährden somit meistens nicht die Integrität des Kernels. Programmcode läuft meistens im User-Modus.

Es ist möglich, im TaskManager die Anzeige von “Kernel-Zeit” zu aktivieren (wie z.B. oben im Bild). Die grüne Linie zeigt die totale CPU-Zeit und die rote Linie zeigt die Kernel-Modus-Zeit an. Die Differenz zwichen diesen beiden Linien zeigt die User-Modus-Zeit an.

Diese zwei Modis sind nicht nur “Etiketten”; sie werden von der CPU-Hardware direkt durchgesetzt. Wenn Code im User-Modus versucht, z.B. eine priviligierte CPU-Anweisung zu nutzen, löst dies eine vom Kernel abgefangene Ausnahme aus. Anstelle dass das gesamte System abstürzt, wird dann nur die Teilanwendung beendet. Das ist der Vorteil des User-Modes.

x86-CPU-Hardware hat 4 “protection rings“: 0, 1, 2, und 3. Nur die Ringe 0 (Kernel) und 3 (User) werden standardmäßig benutzt.

Wenn wir nur 2 Isolierungsringe verwenden, ist es etwas unklar, wo Geräte-Treiber sein sollen (Der Code, welcher uns erlaubt, unsere Grafikkarten, Tastaturen, Mäuse, Drucker und so weiter zu nutzen).Sollen diese Treiber für maximale Performance im Kernel-Modus oder für maximale Stabilität im User-Modus laufen? In Windows ist die Antwort: Es kommt immer auf den Verwendungszweck an. Laufwerk-Treiber können in beiden, User- und Kernel-Modus laufen. Heutzutage laufen die meisten Treiber im User-Modus – außer z.B. Grafikkartentreiber, welche aus Geschwindigkeitsgründen direkten Zugriff auf das System brauchen. Aber selbst das änderte sich mit Windows Vista: Dort sind Video-Treiber für User- und Kernel-Modus geteilt. Vielleicht ist das der Grund, weshalb Spieler sagen, dass Vista etwa 10% langsamer in Spielen ist als Windows XP.

Die genaue Grenze zwischen diesen Modi ist hier noch etwas unklar: Welcher Code sollte im User-Modus laufen? Und: welcher Code sollte im Kernel-Modus laufen? Oder sollen wir vielleicht den Boden als das Fundament nehmen – ein Ring unter allen anderen, Ring -1, welchen wir als x86 Hardware-Virtualisierung kennen.

Der User-Modus ist sicher nützlich, aber nicht ohne Nachteile. Der Wechsel zwischen User- und Kernel-Mous ist sehr langsam.

Die strikte Trennung der CPU zwischen User- und Kernel-Modus ist für die meisten User völlig unsichtbar, aber es ist der Unterschied, ob der komplette Computer abstürzt, oder ob meistens nur die Programme.

[ros-dev] Some upcoming changes + Website Design Contest

Colin Finck an [ros-dev]:
Hello all,

I just wanted to announce some upcoming changes. Comments are appreciated.

Official removal of i486 support
------------------------------

The Mingw-w64 project held an internal meeting today. One of the decisions was to remove support for architectures older than i586 from their code. As we already use some of their runtime code and loosely planned to switch to a mingw-w64 x86/x64 multilib toolchain once that is released and stable (which should be the case in gcc 4.5.x), we will be affected by this change, too.

Of course, the Mingw-w64 code would just add another problem to the pot of i486 incompatibilities. For example, some of our assembly code makes use of the CMPXCHG8B
instruction (introduced in the Pentium).

Though I don't know anybody, who tried a recent ReactOS build on an i486 machine, I also never found a statement about the official removal of i486 support. So as long as nobody objects, let's officially declare i486 support abandoned now.

ISO cleaning on iso.reactos.org
------------------------------

As we were right before running out of space on the ISO storage server (in fact, that would have happened when Aleksey was on his planned holiday trip :D), I've installed a script to clean old ISOs automatically now. The script will remove bootcd-dbg ISOs older than 2 years and all other ISOs older than half a year. This should free enough space while keeping enough important ISOs for tracking down old regressions.

Testman log cleaning
---------------------
Another service that takes more space than you might think is Testman. Logs for ~1300 revisions currently take around 2 GB. My plan would be to delete logs (not the actual test result numbers) older than half a year to keep the used space for them on an almost constant level. If nobody objects, such a script will be installed in the upcoming days.

Best regards,
Colin
______________________________

Ros-dev mailing list
Hinweis: Außerdem läuft zur Zeit ein "Website Design Contest" (>Link<) bis zum 20.August 09 und ein "ReactOS-Logon Sound Wettbewerb" (>Link<).

Dienstag, 11. August 2009

News: Nexuiz ist in ReactOS spielbar!

Seit folgendem Commit vom 7. August 2009 ist Nexuiz (auf der DarkPlaces-Engine basierender OpenSource-Ego-Shooter) in ReactOS spielbar:


http://svn.reactos.org/svn/reactos?view=rev&revision=42467
Author: cgutman
Log Message:
- Call IoCompleteRequest to free IRPs created by IoBuildDeviceIoControlRequest
- Fixes bug 4770

Allerdings kann man zur Zeit noch nicht online auf anderen Servern spielen, da Nexuiz in ReactOS die Serverliste nicht abruft.
Außerdem stockt das Spiel auch bei niedriger Grafikeinstellung extrem, wenn nur SoftwareRendering benutzt wird. Installiert man einen Grafiktreiber mit OpenGL-Support, kann man auch die Grafikbeschleunigung der Grafikkarten nutzen.

Hier ein paar Screenshots:


Viel Spaß beim Spielen ;-)

Montag, 10. August 2009

NT-Architectur: Was ist ... eine Architektur?

Aus der Sicht der Benutzer ist Windows ein bekanntes Betriebssystem (Das erste Spiel, welches Sie am Computer spielten war sicherlich Minesweeper oder Solitär in einer der WindowsVersionen). Auch dank einigen interessanten und informativen Büchern wie z.B. „Windows Internals 4. oder 5. Edition“ kann man nun anfangen, die internen Systemmechanismen von Windows kennen zu lernen.

Reactos ist ein Betriebssystem das sich zum Ziel setzt sich genauso zu verhalten wie Windows. Dieses Ziel anstrebend wird Reactos auch in der Lage sein Treiber und Programme die für Windows geschrieben wurden zu starten und zu laden. Windows, Gnu-Linux, ReactOS oder jedes anderes OS haben aus der Sicht des Benutzers nur ein Ziel: Programme ausführen. Vom Entwickler standpunkt aus gesehen: Erschaffe die schnellste zuverlässigste Verbdindung zwischen Anwendung und Hardware beim gleichzeitigen Bearbeiten und Auswerten des Ergebnisses.



Aber "Windows" ist ein einfach zu merkender Name. Die Art, wie sich ein OS verhällt, die Art wie ein OS informationen verarbeitet, wie eine Anwendung arbeitet und wie sie mit der Hardware (um das ergebniss auf einem Bidschirm anzuzeigen) verbunden ist, wird Architektur genannt - bevor ich es vergesse: Windows besaß in der Vergangenheit verschiedene Architekturen. Die Aktuellste wird "NT Architektur" genannt.


Was ist eine Architektur?


Ich mag die Idee, irgend eine OS-Architektur mit der Architektur von Gebäuden zu vergleichen. Stelle dir vor du bist ein Architekt, stell dir vor du kannst dein Gebäude frei bestimmen, wie es aussieht, aber: das einzige was du beachten musst ist das 100 Menschen reinpassen. Du kannst frei entscheiden ob du 10 Stockwerke mit je 10 Apartments machst, oder du entscheidest dich für einen 100-Stockwerke-Wolkenkratzer mit nur einem Apartment auf jedem Stockwerk zu machen. Es gibt verschiedene Architekturen, aber alle sind eine korrekte Lösungen. Aber im gleichen Maße kannst du auch verschiedene OS Architekturen haben, die alle dazu dienen zu Arbeiten und die Hardware mit der Software zu verbinden. Deswegen gibt es: Nt-Architektur, Mac OS X-Architektur, Linux kernel,...

Und die beste Architektur ist...


Lass uns zur Idee des Gebäudes zurückkehren. Egal ob wir den Wolkenkratzer oder das 10 Stockwerke Gebäude wählen, wir werden verschiedene Probleme lösen müssen.

Schauen wir uns den Wolkenkratzer an: Du hast einen Nachbar auf jedem Stockwerk, das heist das jeder Nachbar eine direkte beziehung zu dem unter seinen Füßen und zu dem über seinem Kopf hat. Daher sind die Apartments sehr leise. Das ist eine nette Sache, wenn du der Architekt bist und auch zugleich der Besitzer der ein "leises-Stockwerkausfüllendes Arpartment" hat (auch Loft genannt): nette Werbung. aber mit sicherheit hat das auch Nachteile, und die erste: Wenn der Bewohner vom Erdgeschoss auf das Dach will sollte er sich ein paar Sandwiches mitnehemen damit er nicht verhungert bis er auf dem Dach ist, so lange es keinen Direkten Aufzug zum Dach gibt.

Die 10 Stockwerke Architektur ist ein nettes Ziel, viel billiger zu konstruieren, aber es ist auch sehr viel mehr Lärm auf jedem Stockwerk und ein Haufen Relationen (welche in einer nachbarschaft zu problemen führen können) werden erzeugt. Lass uns doch einmal die Relationen zählen: Jede Person auf der 5 Etage wird 9 Nachbarn auf seiner Etage haben, plus 10 weitere Nachbarn über seinem Kopf und 10 weitere unter seinen Füßen. Gesamt: 29 direkte Relationen, die jede Person hat. Versuch mal die anzahl der gesamten relativen Verbindungen zu zählen und vergleiche die Anzahl mit der Anzahl der gesamten Relationen des Wolkenkratzers den wir vorhin hatten.


Nun können wir aber auch in der tat eine neue Architektur erntwickeln, genannt: Erstes-Stockwerk. Ein seltsames "Bauwerk" mit nur einem enormen Stockwerk und 100 Nachbarn. Nun kannst du das Dach sehr leicht erreichen, ohne einen Aufzug zu verwenden!! wowww...(*ehem*) Wie ist hier wohl die Anzahl direkter möglicher Relationen? Jap, viele. Aber hey, sie können alle das Dach erreichen.

OK, OK. Warum rede ich über Dächer, Nachbarn und Stockwerke?

Lasst es mich übersetzen:

Man kann sich eine Architektur als eine Anzahl übereinander liegender Schichten vorstellen, genauso wie man sich ein Gebäude wie eine Anzahl übereinanderliegender Stockwerke vorstellen kann. Das heißt, wir können eine Architektur mit 100 Schichten oder mit nur 1 Schicht haben. Das sagt nicht viel aus, aber lasst uns weitermachen. Jede Schicht für sich ist auch in unterschiedliche Strukturen unterteilt, so wie ein Stockwerk in 10 Wohnungen unterteilt sein kann. Jede Wohnung (verzeihung Struktur) hat Ihre eigene Aufgabe in der Architektur. Eine Wohnung (verzeihung Struktur) verarbeitet die Grafik, die nächste Wohnung kommuniziert mit der Hardware, die nächste Wohnung kommuniziert mit der Anwendung, die nächste Wohnung kommuniziert mit der Zweiten, weil die Dritte sauer auf die Letztere ist...

Lasst uns wieder das Hochhausbeispiel nehmen:
Ganz oben (auf dem Dach) des Hochhauses ist eine Anwendung, im Keller des Gebäudes befindet sich die Hardware, und die Wohnungen haben die Aufgabe einen "Weg" für die Anwendung zu schffen, damit diese mit der Hardware kommunizieren kann. (Alles endet beim Prozessor, richtig? Oder mit Festplatten Zugriffen oder durch die Ausgabe von Information am Bildschirm)


Das Hochhaus ist ein typisches Beispiel eines zu stark geschichteten Betriebssystems. Ein zu stark geschichtetes Betriebssystem hat einige Kostenvorteile, man muss als Programmierer nicht so viele direkte Verbindungen zwischen den Strukturen (Nachbarn) im Hochhaus herstellen, nur Zwei. Dadurch ist es dem Anschein nach leichter zu kontrollieren, aber... man erkennt ein Hauptproblem: Langsamkeit. Der "Aufruf" muss über 100 Stockwerke erfolgen. Nein, es gibt keinen superschnellen Fahrstuhl. Vielleicht muss der "Aufruf" im Stockwerk 63 überhaupt nicht verarbeitet werden, aber dennoch muss er dieses passieren um zum Stockwerk 62 zu gelangen.

Was geschieht in einer 1-Stockwerk Architektur? Das ist eine vollkommen Schichtenlose Architektur. Schichten sind toll, da sie die Anzahl der direkten Verbindungen verringern (Falls Ihr noch nicht gerechnet habt, wäre jetzt der passende Zeitpunkt dafür :3. Das Ausmaß ist gewaltig) aber sie benötigen zusätzliche Zeit, falls die Architektur zu stark geschichtet wurde. Eine ungeschichtete Architektur setzt unmengen an Direktverbindungen voraus, und es ist ein riesiges Chaos, da man beobachten wird, wie der Aufruf zur Wohnung 1 dann zur 35 dann zurück zur 12 und schließlich zur 98 geht; und alles geschieht in EINEM Stockwerk.

Natürlich macht eine Anwendung unterschiedliche Aufrufe (geht unterschiedliche Wege). Ein Aufruf, der 2+2 errechnet ist nicht das selbe, wie der Aufruf, der Musik wiedergibt. Das heißt, dass ein Aufruf, der 2+2 errechnet durch manche Wohnungen gehen muss, aber wahrscheinlich andere (manche könnten gemeinschaftlich genutzt sein) als der Soundaufruf durchläuft. Dank dessen, dass sich alle Wohnungen im selben Stockwerk befinden muss der Aufruf nur hinein dann hinaus aus den beliebigen Wohnungen und in den Keller. Nun stellen wir uns wieder das Hochhaus vor: Beide Aufrufe müssen durch 100 Wohnungen (weil im Hochhaus Wohnung und Stockwerk das selbe sind)!


"Dann ist eine 1-Stockwerk Architektur besser..."

Nun ja, Nicht wirklich. Stellen wir uns vor, dass 100% der Zeit die wir benötigen nur zum betreten zweier Wohnungen verwendet wird (Aufruf1: Wohnung 1, 13; Aufruf2: Wohnung 3, 11, 7; Aufruf3: Wohnung 1, 7, 14... und noch 2 oder mehr Wohnungskombinationen). Dann ist es es offensichtlich, dass wenn wir eine 2-Stöckige Architektur erschaffen (denkt daran: Wir können die Wohnungen anordnen, wie wir es wünschen; wir sind schließlich die Architekten!) verlieren wir keine Zeit!
Also ja, man muss ein Gleichgewicht zwischen den direkten Verbindungen (leichter, klarer und so sauberer Quelltext wie möglich) und der Leistungsfähigkeit des Betriebssystems (nicht zu viele Schichten) schaffen. Genauso spielt das Ziel eines Betriebssystems eine Rolle, ein Echtzeit-Betriebssystem kann nicht vollständig geschichtet sein, sonst "verliert es eine Menge Zeit" aus der sicht eines Echtzeit-Betriebssystems (jede Nanosekunde zählt)

Also versucht jedes OS seine eigene Lösung zu diesem balanzierten System zu finden, und das ist auch der Grund, weshalb es verschiedene Architekturen gibt. ReactOS folgt der NT Architektur und dessen Schichten sind genauso positioniert wie die von NT.

Und ja: Wir werden nächste Woche versuchen, euch die ReactOS (NT) Architektur zu erklären..Seit Ihr bereit? ;)

Bis zum nächsten Post :)

Montag, 3. August 2009

FullFAT, ein neues Projekt

ReactOS ist nicht nur ein Betriebssystem, sondern es zeigt auch einen Treffpunkt, bei welchem verschiedene OpenSource-Projekte ein neues Ziel oder überhaupt einen Existensgrund "finden".

Oft werden interessante Projekte für Windows von den Entwicklern nicht mehr weiterentwickelt, weil viele User fürchten, Windowsmodule (Programme, Treiber,...) mit freier und/oder Opensource-Software zu verändern oder zu ersetzen.

Zur Zeit nutzt ROS viele (kleine und große) OpenSource Projekte wie z.B.:
  • USB
  • UNIATA
  • Paint.exe (wurde extra für ReactOS entwickelt)
  • Netzwerk-Stack (teilweise von BSD portiert)
  • (teilweise)Wine
  • viele andere....

Was ist FullFAT?

FullFAT ist eine komplette Bibliothek von James Walmsley, welche Support für FAT 12/16/32 bietet. Es hat außerdem LFN-support, und einige andere Features. Zusätzlich beabsichtigt FullFAT, (sobald es Stabil wird) ein Journaling-System zu nutzen. (wie bei modernen Dateisystemen)

Der Entwickler von FullFAT begann es zu schreiben, da er mit der Geschwindigkeit von existierenden Treibern (wie z.b. der Treiber von FreeDOS) nicht zu frieden war.

Allerdings ist FullFAT nur eine Bibliothek, welche FAT-Support bietet, und Windows macht dies mit Hilfe von Treibern :(
Fireball hat bemerkt, dass es dank dem win32-Interface (auch von James entwickelt) nicht zu schwer ist, aus dem jetzigen FullFAT einen Treiber für Windows/ReactOS zu machen.

Da der jetzige FAT-Treiber sehr Fehlerhaft ist, braucht ReactOS einen neuen ordentlichen FAT-treiber. Deshalb hat das ReactOS-Entwickler-Team James Walmsley angeschrieben.

Seine antwort überraschte uns: Er hatte noch nie etwas von ReactOS gehört...
Hi Everyone,

I just thought I'd introduce myself. I am the author of a new FAT implementation that was really designed for embedded systems. As such it provides very good performance. (See www.fullfat-fs.co.uk).

Fireball contacted me a few days ago to discuss the current development of FullFAT, and since I have agreed to implement an IFS driver based on FullFAT with a view to replacing the current fastfat.sys implementation. During the conversation we also discussed implementing a special journaling extension to FullFAT via the windows driver.

I hope to start work on this project in the next few weeks, and further to this I would also like to help in some other areas of ReactOS. I shall be taking a closer look at the ReactOS code over the coming weeks, and will probably post some questions about various aspects. I have just bought the Windows Internals, fifth edition co-authored by Alex Ionescu, hopefully this will provide me with a good overview of the Windows architecture etc.

For complete Windows XP compatibility, just how much of the implementation is currently missing from ReactOS?

Nice to meet you all, and I hope to provide some good contributions to ReactOS in the near future.

James

Hoffen wir, dass diese neue Implementation bald nutzbar ist, und viel besser als der jetzige Treiber wird.

ReactOS Newsletter #64

Das ReactOS Team hat am 31.07.2009 einen neuen Newsletter veröffentlicht.

Die Themen des Newsletters sind:

Den kompletten Newsletter finden Sie auf der ReactOS-Website.

Dienstag, 28. Juli 2009

Ergebnisse der Community-Choice-Awards

Die Gewinner des Community-Choice-Awards stehen fest!

Leider gehört ReactOS nicht zu den 12 Gewinnern :-(

Die einzelnen Ergebnisse mit den genauen Prozentsätzen findet man hier.

PS: Microsoft ist ein Sponsor von Sourceforge :-\

Dienstag, 21. Juli 2009

ReactOS Newsletter #62

Das ReactOS Team hat am 21.07.2009 einen neuen Newsletter veröffentlicht.

Die Themen des Newsletters sind:

Den kompletten Newsletter finden Sie auf der ReactOS-Website.

Montag, 20. Juli 2009

Aleksey Bragin an [ros-dev]

Wie man hier sehen kann, wird zur Zeit viel an ReactOS in "Arwinss" verändert.
Heute hat Aleskey Braign dazu eine Mail geschrieben:

Betreff: [ros-dev] Arwinss

Hello,
I've heard many question about a branch I was working on recently, arwinss, so I'd like to write some explanation (you may skip the boring history part of the message)

Arwinss is a rewrite (the most advanced so far out of all previous attempts) of some parts of the Win32 subsystem, namely the USER32 and GDI32 API interfaces, along with the kernel counterpart win32k.sys. The kernel32.dll, csrss, and other parts remain in their present condition, and getting bugfixes if they come in the way of a rewrite.

[History and reasoning part starts here]
Why rewrite and not fix an existing Win32 subsystem? Timo, James and all our other great developers were and are doing a great work. I put a considerable amount of time in it to fix problems too. But, since our project is a volunteer-driven one, everyone has a real life, real work to do, and is not able to sit 24 hrs researching Windows internal structures, inventing new algorithms, trying out thousands of applications, not to say about graphics drivers. Time is ticking, Win32 is improving, but most annoying bugs are there for years - e.g. vmware installer hang, Firefox move the mouse bug, drawing glitches, concurrency hacks in the code ("if (!a) /* someone else was faster than us and already freed it */"), probable heap misusage (relying on our heap implementation for desktop heaps) and heap memory corruptions (I kept trying to update rtl/heaps to the newest Wine code - and always failed without any obvious reason), inability to change video mode on the fly, and the list can go on.

So I thought, that something should be done with it. I would even want to trade off some speed gain in favor of stability (optimizing is an enjoyable task which could be done later).

After teaming up with Stefan, we created an nwin32 branch - a totally stubbed out win23k, user32 and gdi32. They had exactly matched exports, and win32k had exactly same system calls and Windows 2003 SP1's win32k.sys. However, due to really huge amount of work, the branch didn't went farther than trying to boot Windows 2003 with it and see a few stubbed functions being called.

Since then I started thinking on an alternative design of a Win32 subsystem. The idea turned out to be very simple, and is based on the following questions:
- Why put so much effort into keeping the internal win32k system calls interface the same as in Windows, why put so much effort in converting to internal Windows structures, if we don't have something working first?
- Why base on a stoneage Wine's code which James and Christoph occasionally sync, and all my attempts to get more people into this boring task failed?
- Why not use achievements of our closest project - Wine?

[End of reasoning, fancy stuff starts]

The result came by itself: Try to build up a win32 subsystem based as much on Wine code as possible, and using Wine's modular design. Before publicly announcing it, I have spent a month actually trying all that stuff, and surprisingly it went very well, and a nice byproduct: support of remote sessions via X Windows.

Proof of concept screenshots are here:
http://www.reactos.org/media/screenshots/2009/arw_xlog1.jpg
http://www.reactos.org/media/screenshots/2009/arw_xlog1.jpg

Noone has ever done this before: This is Windows 2003 inside VMware, running my custom Win32 subsystem, with an X graphics driver module, communicating with an X Server running in the host OS (Windows XP, XMing X windows server), and with ReactOS's winlogon.exe and msgina.dll (for ease of debugging and source code availability)!

Let's go straight to the architecture:

GDI32.dll and USER32.dll are ported Wine usermode code, with very few modifications. GDI32 and USER32 depend on two things: Gdi and User driver, and a server.

Gdi and User driver is a loadable DLL, which provides an abstraction of a graphics driver in the system through a certain set of APIs. A typical example of such a driver is winex11.drv, which routes all drawing to the X Windows "client". However, this is not very useful for a local system which has a Windows NT architecture, where there is no need for remote windows displaying.

The server. GDI32 and USER32 rely on the server for managing all global information. In Wine, the server is run as a usermode wineserver.exe process, which communicates with gdi32/user32 via custom RPC, and emulates quite a lof of stuff which Windows NT kernel provides by default. My decision was to convert the RPC protocol from a slow interprocess filedescriptors-based unix-specific invocations to a fast system calls to win32k module. This way, win32k contains small part (~300 kb vs 1.5Mb+) of wineserver's source code, which deals with windows, window classes, atoms, windows stations, desktops and other totally platform/implementation independent stuff. It will be reduced further, because I even ported their own object manager for win32 objects, which will be exchange to our native ntoskrnl's object manager soon, when the testing phase is over.

The graphics driver, kernelmode part. As I said above, it's not very convinient to fully rely on X Windows for graphics output, because it's just not possible to run it in an NT-based OS which has no Win32 subsystem. Thus, I decided to create a totally native gdi/user driver ("winent.drv"), which would rely on win32k module to actually perform all drawing. However, compared to our current implementation, the drawing would be way more simple. For example, if currently LineTo operation in win32k involves complex PATHOBJ, maintaining graphics cursor -- all of that in a strictly windows compatible way because apps depend on it, in this alternative win32k, LineTo is a simple line drawing function: RosGdiLineTo(pDc, x1, y1, x2, y2). Same applies to other functions, including e.g. text output, where all rendering happens using a usermode freetype.dll, and win32k just needs to display bitmap glyphs got from gdi32.

Don't be scared if you don't understand all that right away. I will put up a good short summary, along with a TODO and FIXME lists, and a HACKING guide.

Just a few cool facts about the new win32 subsystem:
- Based on a solid, very well maintained codebase, used by commercial vendors.
- Ease of updating from upstream (vendor importing)
- Tested against more than 12 000 Windows applications (http://
appdb.winehq.org)
- ...

I think it's enough for the first introduction.

WBR,
Aleksey Bragin.



Außerdem unterstützt ReactOS seit kurzem auch mehrere Netzwerkkarten in einem System (DHCP zur Zeit nur für die 1. Karte), so dass ReactOS langsam etwas Servertauglicher wird.

Wichtige Mail von Colin Finck an [ros-dev]

Betreff: [ros-dev] Web and Mail system migration

Hello,

We're planning to migrate the Web and Mail system to a new server and upgrade these components in the next 24 hours. This affects the whole Website at www.reactos.org plus all @reactos.org mail addresses including the mailing lists. During the migration, these services may be temporarily unavailable.

The Web server migration includes upgrading the server components (e.g. Apache, MySQL, PHP) and applications (e.g. RosCMS, phpBB) to newer versions. Besides, the configuration of the server components was tuned for a better overall performance. The mail boxes, mail relays and mailing lists will be moved to a dedicated virtual machine, which will also offer a groupware system for official ReactOS developers and testers.

Our plan is to do this upgrade in two big steps, namely first the Website and afterwards the mail stuff, to keep the downtime as low as possible. Minor problems are expected after the migration and will be fixed shortly. In case of major unforeseen problems, the downtime of particular components might be extended to the next 48 hours.

Best regards,
Colin Finck
______________________________

Freitag, 10. Juli 2009

Neue Bilder von Gabriel Ilardi

Mittwoch, 8. Juli 2009

Offtopic: Neues Betriebsystem in Planung

Zuerst die Suchmaschine, dann der Browser und jetzt auch noch ein Betriebsystem.

Geschwindigkeit, Einfachheit und Sicherheit sind die Schlüsselaspekte von Google Chrome OS

konnte man auf dem offiziellen Google-Blog nachlesen.

Google möchte mit dem Chrome OS in den direkten Konkurrenzkampf mit Microsoft gehen und ein eigenständiges Betriebsystem entwickeln.
Das OS soll überwigent auf Netbooks zum Einsatz kommen und eine Einheit aus Browser und Betriebsystem darstellen.

Dienstag, 7. Juli 2009

ReactOS im Netz


1.290.000 Suchergebisse auf Google. Wer hätte das gedacht?
ReactOS wird immer beliebter!

Wer immernoch denkt, ReactOS sei niemanden bekannt und ist ein Insider Projekt, der liegt eindeutig falsch.
Nicht nur die größtenteils
englischsprachige offizielle Community Seite mit dem offiziellen Forum, represetiert das ReactOS Projekt.

Auch sehr bekannt Seiten wie:
haben wie es scheint, eine kleine Schwäche für das Opensource Windows endeckt.


Mittlerweile gibt es auch schon einen Hauseingenen Youtubechannel, der Videos wie z.B. den ReactOS 0.3.10 Preview beinhaltet.
Wer nach dem Stichwort "reactos" bei Youtube sucht, wird sicher schnell feststellen, das man dort auch jede menge Videos von anderen Usern des ReactOS Projektes finden kann.
Dazu zählen unter anderen Videos wie: ReactOS @ FOSDEM '09 - Part 1 of 2, ReactOS boot with UniATA (Real Hardware - 41179) oder andere Fanprojekte wie Mac vs. PC vs. ReactOS - South Park Style und ReactOS Commercial - free Windows alternative.
Schaut einfach mal vorbei, guckt euch neue und ältere Videos an oder erstellt selber das eine oder andere Video und ladet es bei Youtube hoch.

Helft mit, werbt in Foren, stellt eure Videos online oder erzählt euren Bekannten und Freunden von diesem großartigen Projekt.
ReactOS ist groß im kommen!

Montag, 6. Juli 2009

ReactOS 0.3.10 veröffentlicht!

Gestern hat das ReactOS-Team die Version 0.3.10 des gleichnamigen freien OpenSource Windowsähnlichen Betriebssystems "ReactOS" veröffentlicht.

Hier die offizielle Newsmeldung von dem Entwicklerteam: http://www.reactos.org/de/news_page_53.html

Seit 0.3.9 wurde sehr viel am System-Kernel sowie auch am HardwareSupport verändert. (siehe Newsbericht und Changelog) Außerdem hat ReactOS nun guten OpenGL-Support (Software- und Hardware-seitig), so dass einige Spiele und auch Google Earth ( http://react-blog.blogspot.com/2009/06/google-earth-und-qip.html ) in reactos nun gut spielbar sind.

Die InstallationsCD kann unter http://downloads.sourceforge.net/reactos/ReactOS-0.3.10-REL-iso.zip und die LiveCD kann unter http://downloads.sourceforge.net/reactos/ReactOS-0.3.10-REL-live.zip gedownloadet werden.

Samstag, 4. Juli 2009

Releaseschwierigkeiten

Gestern den 03.07.2009 um 12:42Uhr konnte man im ReactOS CIA
ReactOS 0.3.10 is ready!

nachlesen. Doch leider folgte dieser Nachricht eine sehr unerfreuliche von ReactOS auf Twitter.
Dort wurde beschrieben, das es Probleme gibt, die Finale 0.3.10 Version von ReactOs auf Sourceforge hochzuladen.
Auch heute gab es einen Eintrag auf Twitter, der besagt, das es weiterhin Probleme mit dem Upload gibt.

Hoffen wir, das Sourcforge die Probleme so schnell wie möglich in den Griff bekommt.

Autor: rexty

Sonntag, 28. Juni 2009

Google Earth und Qip

GoogleEarth 4.3 läuft in Reactos:



Außerdem läuft seit kurzem auch die ICQ-Client-Alternative QIP in ReactOS:

Freitag, 26. Juni 2009

Vote for ReactOS

Das ReactOS-Projekt nimmt wieder einmal am "Sourceforge Community Choice Awards" teil und wir haben es in die Finalrunde geschafft!

ReactOS ist im Moment in drei Kategorien vertreten:
  • Bestes Projekt
  • Bestes Projekt für Regierungen
  • und "Mal einen anderen Weg gehen etwas zu tun".
Bitte stimmt für uns und folgt hier dem Link und helft uns bekannter zu werden.

Zusätzlich hat Victor Martinez ein Video mit verschiedenen Erklärungen der Reactos-Entwickler zum Projekt erstellt; es zeigt einige Späßchen( youtube-video ).

Und jetzt stimmt ab! ;-)

Donnerstag, 25. Juni 2009

PowerpointViewer in ReactOS

Hier noch 2 interessante screenshots:


Christoph hat es geschafft, den PowerpointViewer in ReactOS zum laufen zu bringen und hat seinen geänderten Code schon in ReactOS integriert....

PS: Bitte helft alle, die Softwaretests für 0.3.10 möglichst schnell zu vervollständigen.

Dienstag, 23. Juni 2009

Sourceforge: Community Choice Awards

Bitte helft ReactOS, indem ihr hier in den Kategorien "Best Project", "Best Project for Government" und in "Most Likely to Change the Way You Do Everything" ReactOS als bestes Projekt auswählt.

Hier das Video des ReactOS-Developer-Teams für den Wettbewerb:

Samstag, 13. Juni 2009

xoblite in ReactOS

Heute habe ich xoblite (Blackbox für Windows) in ReactOS r41401 getestet.

Hier das Ergebniss:


Xoblite läuft auf anhieb fast Fehlerfrei!
Auch die meisten Plugins funktionieren Fehlerfrei :D

Ich nutze xoblite auch auf meinen eigenen Windows-Rechnern und finde es viel besser als den Windows explorer.

Freitag, 12. Juni 2009

ReactOS Newsletter #60

Das ReactOS Team hat am 12.06.2009 einen neuen Newsletter veröffentlicht.
(noch nicht übersetzt)

Die Themen des Newsletters sind:
Den kompletten Newsletter finden Sie auf der ReactOS-Website.

Samstag, 6. Juni 2009

ReactOS Newsletter #59

Das ReactOS Team hat am 04.06.2009 einen neuen Newsletter veröffentlicht.
Dieser wurde von xpert, Paul Schuster und Daniel Kraut übersetzt.

Die Themen des Newsletters sind:
  • ReactOS Foundation
  • UniATA die Dritte
  • Grafiktreiber
  • RosBE
Den kompletten Newsletter finden Sie auf der ReactOS-Website.

Für alle Tester: in den letzten Tagen wurden einige Bugs von ReactosDBG gefixt.
Weitere Infos über den ReactOS Remote Debugger sind hier.

Donnerstag, 21. Mai 2009

Reale Hardware testen

Bitte testet alle ReactOS (Download von reactos.org/getbuilds) auf realer Hardware und versucht auch, die Treiber für die Hardware zu installieren.

Die Ergebnisse könnt ihr anschließend in den jeweiligen Seiten des ReactOS-Wiki eintragen:
Bitte beachtet, dass ReactOS zur Zeit noch kein SATA und nur max 8 GB große Partitionen unterstützt, da uniATA noch nicht Standartmäßig dafür genutzt wird. Dies wird sich aber ändern, sobald noch ein paar wichtige Bugs behoben wurden (siehe aktueller Newsletter).

PS: Unter waxdragon.homeip.net/... findet ihr eine TestVersion von RosBE 1.4.3. Bugs bitte hier posten!

ReactOS Newsletter #58

Das ReactOS Team hat am 16.05.2009 einen neuen Newsletter veröffentlicht.
Dieser wurde bis zum 19.05 von Daniel Kraut übersetzt.

Die Themen des Newsletters sind:
  • UniATA
  • Pool
  • Mehr Speicher
Den kompletten Newsletter finden Sie auf der ReactOS-Website.

Dienstag, 12. Mai 2009

Daniel Reimer an die ReactOS Development List

Betreff: [ros-dev] RosBE 1.4.2 and its problems

Hi,

as many ppl already found out, we have some problems with RosBE 1.4.2
for Windows on some machines. Most problems are a result of the idea to
keep the Original Path Variable + extending it. Before that we fully
replaced it. Well If there are () in the Paths, we have a problem. Batch
thinks the ) is for it to interpret and closes the right now open block.
This is really bad as you might imagine. Well. Colin ran through the
scripts these days and heavily cleaned up the mess we had resulting from
being modified by several ppl over the last years. He reduced the code
lines of some scripts by ~60%. But before I release anything, I want it
to be tested FULLY and by MORE than one person (me). I got some not that
nice and partially insulting EMails because RosBE failed for the ppl.
The consequence is that 1.4.2 will be the latest Version until ~10 ppl
tested the FULL functionality of the Scripts and report bugs and
requests. Here or in the Forums, I don't care.

I post all news in the Forums and paste the Reports written in here to
there too. http://www.reactos.org/forum/viewtopic.php?f=2&t=6898

Thx for reading.
______________________________

Sonntag, 10. Mai 2009

gulli.de: Colin Finck im Interview

Wenn dieses Team mit ihrer Arbeit fertig ist, könnte das Ergebnis geradezu himmlisch ausfallen. Am Ende aller Bemühungen steht ein kostenloses, quelloffenes und vor allem freies Betriebssystem. Die eigenen Treiber sollen so viel exotische Hardware wie möglich unterstützen. Zudem wird jegliches Ausführen von Windows-Programmen ermöglicht. Quasi Windows-Feeling ganz ohne Microsoft, ganz ohne Beschränkungen. Geht das überhaupt? Und juristisch betrachtet: Darf dieses Projekt via Reverse-Engineering überhaupt umgesetzt werden? Der Weg bis zur finalen Version von ReactOS ist noch lang. Wir haben Colin Finck, einen der deutschen Programmierer, auf der Fosdem 2009 getroffen und ihn ein paar Meter bis zur Ziellinie begleitet.

......
Das komplette Interview und Kommentare dazu ist auf der Gulli-Website.

Samstag, 9. Mai 2009

Colin Finck an die ReactOS Development List

Betreff: [ros-dev] RosBE 1.4.2 available, update highly recommended!

Hi everybody,

Daniel and I just released the new version 1.4.2 of the ReactOS Build
Environment for Windows and Unix.

The most important part of this release is the addition of some environment
variables containing the include directories of the host and target
compilers as compiler flags.
These variables might be required by rbuild in the near future, so the
update to the new version is highly recommended.

Besides, the GCC in RosBE-Windows 1.4.2 is now compiled for i686 or later
CPUs, decreasing the compilation time by 5 minutes for Daniel. Hopefully
another reason to make the update more attractive ;-)

As always, you can get the latest release from
https://sourceforge.net/project/showfiles.php?group_id=6553

Best regards,

Colin

______________________________

Dienstag, 28. April 2009

[ros-dev] Development plans for May

Hier noch eine interessante Mail aus der ReactOS-Dev-Mailing-list:

Hi,
as we earlier discussed, there is an idea to make 0.3.10 a "hardware-
compatibility" release.

There is a full list of 0.3.10 milestones bugs linked from our
roadmap page, but here are some possible directions for work:
- USB support for keyboard and mouse devices. Right now, it needs
fixing the rare crash during booting (bug is bugzilled, comment
explaining how to solve the problem is attached, some investigation
remains), and more testing on real hardware.
- Uniata support: it solves many problems at once, such as a stupid
8Gb limit which is a nonsense for a 2009-year operating system, and
Serial ATA support, which greatly enhances possible ReactOS usability
(along with the first item of this list). I use it in my builds
everyday for more than a month, it works very good. Problems:
VirtualBox CDROM support (it doesn't recognize it), on my
realhardware it also experiences similar problems. Bug is also
bugzilled, a lot of debug logs attached, so everyone can participate.
- Common NICs support: Cameron is doing great work, testers too.
There are some outstanding problems, which you can see from http://
www.reactos.org/wiki/index.php/Supported_Hardware/Network_cards
- Sound support: Johannes knows best, but getting any progress with
sound by 0.3.10 release date is greatly appreciated.
- Videocards support: Olaf performs some tesitng and bugreporting.
Third party drivers support is rather weak, http://www.reactos.org/
wiki/index.php/Supported_
Hardware/Video_cards , and usually is
limited by VMWare's video driver which is being one of the most
supported through the ReactOS development history.

Besides of that, Olaf is organizing the Golden Apps testing, so that
we won't discover regressions occasionally or by the time the release
is branched and everyone is awaiting, but instead that's going to
happen on a periodical basis, and he's going to manage this process
with help of our fellow testers.

Target 0.3.10 release date is month from now on - that means,
somewhere in the end of May. Certainly, if our goals aren't met, the
release is going to be rescheduled and that's it, but, I'd like to
ask to concentrate on the above problems first. They are hard to
solve when every problem is being approached by one person, but with
a common effort they aren't going to be a problem.

Any new developers - welcome! There are very definite goals, enough
of information, so please feel free to join and help.


With the best regards,
Aleksey Bragin.
_______________________________________________
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Montag, 27. April 2009

Neue Version von ReactOS verfügbar!

Gestern, am 26.April 2009, haben die Entwickler von ReactOS eine neue Version veröffentlicht.
Die neue Versionsnummer lautet 0.3.9 .
Genaue Infos dazu findet man unter http://www.reactos.org/de/news_page_51.html .

Eine detailliertere Liste der Änderungen findet sich im Changelog auf der Website des ReactOS-Projekts.

Die Ergebnisse der Software-Tests in der Testphase sind im ReactOS-Wiki unter Tests for 0.3.9 gelistet.
Eine Liste mit getesteten Netzwerkkarten findet man hier .

Den Status der einzelnen 'Teile' von ReactOS sieht man relativ gut in dieser Grafik: Version_Status

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 nächsten Release von ReactOS werden nun wahrscheinlich monatlich veröffentlicht werden (wird allerdings noch diskutiert). (Neue Roadmap: http://www.reactos.org/wiki/index.php/Roadmap)

Montag, 20. April 2009

Offtopic: Bot-Trap :: ANTI-Spam und ANTI-Bot

Seit kurzem schütze ich einige meiner Seiten (besonders Foren) mit Hilfe von Bot-Trap ( http://www.bot-trap.de ) vor Spam und Bots.
Gerade Foren haben oft das Problem, dass sich einige Bots in diesen Registrieren und dann Links posten.
Mithilfe von Bot-Trap (+Auto-Updater) werden diese Bots einfach von den Websiten ausgeschlossen.
Bevor ich Bot-Trap genutzt habe, musste ich täglich etliche SPAM-Accounts löschen / bannen. Seit ich Bot-Trap allerdings nutze, habe ich höchstens noch einen Spam-Account pro Woche :)

Design von ReactOS veränderbar

Mittlerweile kann man das Design von ReactOS schon stark verändern:

Für weitere Infos siehe Dreimer's Blog

Dienstag, 14. April 2009

Firefox 3 in ReactOS

Firefox 3 läuft mitlerweile etwas besser:
  • Firefox 3 in ReactOS-Trunk 40271:
  • Firefox 3 in ReactOS-Trunk 40496:

Außerdem tritt der Timer-Bug nicht in Firefox 3 auf.

Download! ist nun in jeder Trunk-Version enthalten!

Das Programm Download! ist nun standardmäßig in jedem ReactOS-Trunk integriert. Zuvor war dieses Programm nur in rosapps.
In Windows kann man den InternetExplorer benutzen, um nach einer NeuInstallation Programme zu downloaden.
Mit "Download!" kann man dies auch in ReactOS.
(Ja, man kann auch über den ROS-Explorer Dateien downloaden, aber über Download geht dies einfacher und schneller)

Sonntag, 12. April 2009

Hardware-OpenGL-Unterstützung

Hier noch etwas interessantes:
Since 2.1.x, VirtualBox allows passthrough to your host GPU, virtualising its 3d acceleration capabilities. You need to install Vbox video driver, guest driver and opengl libs.

Dieses Zitat stammt aus dem ReactOS-Forum (Link: http://www.reactos.org/forum/viewtopic.php?f=2&t=6730 )

Samstag, 11. April 2009

ReactOS Newsletter #56

Das ReactOS Tam hat am 09.04.2009 einen neuen Newsletter veröffentlicht.
Dieser wurde wieder von Xpert übersetzt.

USB

Der USB-Support hat eine ungewöhnliche Geschichte bei ReactOS. Das ursprüngliche Ziel, den Cromwell USB-Stack zu portieren, wurde abgebrochen und von einem NT4 USB-Stack eines Programmierers aus China ersetzt. Aleksey Bragin versuchte zwar den Linuxstack zu integrieren, aber die Idee wurde verworfen und nun verbesserte er den bestehenden NT4-Stack, der ein paar Mängel aufwies. Ein USB-Maustreiber wurde gehackt, lief allerdings nicht zuverlässig. Jene, die ihn auf ROS getestet haben, können dies bestätigen. Vor kurzem versuchte Aleksey die gleiche Prozedur bei einem USB-Tastatur Treiber und wollte auch gleich noch die LEDs der Tastatur mitsteuern. Diese spezielle Handhabung bedarf auch spezieller Kommunikation zwischen USB-Port und Tastatur und funktioniert anders, als simples Senden von Tastenanschlägen oder Mausbewegungen. Aleksey bemerkte letztendlich, dass der Treiber den Configuration Descriptor des Geräts falsch parste und bemühte ein Haiku Teammitglied, dieses Problem zu beheben. Diese Aktion machte auch das >Hacken<>

Da ReactOS nun über USB-Maus- und USB-Tastaturtreiber verfügt sollte angemerkt werden, dass diese beiden Treiber für den aktuellen USB-Stackt von ReactOS entworfen wurden. USB auf NT5 und aufwärts haben 2 Stacks: PnP und HID. ReactOS unterscheidet sich hiervon grundlegend. Bevor wir einen NT5+ USB Treiber integrieren können, brauchen wir erstmal einen USB-Stack der sich am NT5+ Design orientiert. Diese Methode würde die größtmöglichste Kompatibilität mit externen Treibern sorgen und die Funktionalität gewährleisten, die man von USB gewohnt ist

Netzwerk

Art Yerkes und Cameron Gutman haben sich angestrengt den Netzwerk-Stack besser in Form zu bringen und fehlende Funktionen nachzurüsten. Das Problem war, dass SSL wegen Speicherkorruption nicht benutzt werden konnte. Ein Array von IP-Adressen wird von zwei Funktionen verwaltet und benutzt, AfdGetPeerName und AfdGetSockName. Art glaubte, dass Webseiten die SSL-Funktion zweimal aufrufen um das Zertifikat zu prüfen, was den Fehler erzeugte. Nun ist es möglich auf Webseiten wie die Gmail Loginseite zuzugreifen, wie z. B. Thunderbird, dass auf SSL vertraut.

Art und Cameron erkannten, dass der Programmcode zur Netzwerkschnittstelle in vieler Hinsicht zu komplex war, mit vielen Strukturen, die sehr ähnliche Namen und nur wenig andere Inhalte hatten. Ein typisches Beispiel sind die TDI_ADDRESS_INFO, TDI_ADDRESS_INFORMATION und TRANSPORT_ADDRESS Datenstrukturen. Die Annahme war, dass ein Protokoll mehrere Adressen bei einem Aufruf zurückgeben würde, welches aber nicht normal ist für typische Netzwerksysteme. Alles das sind Teile der definierten Schnittstelle, die nicht geändert werden kann und man muss durch den Code gehen, um sicherzustellen, dass die passende Datenstruktur und das passende Strukturfeld benutzt werden. Manchmal sind die Unterschiede zwischen den Strukturen geringfügig und es kann funktionieren und in bestimmten Situation schwerwiegende Probleme verursachen. Wie auch immer, die beiden müssen sich ordentlich ranhalten.

Testumgebung

Vor einer Weile brachte Christoph von Wittich automatisierte Wine-Tests zum laufen und Alwyn Tan, ein Mitglied der Community, hatte eine vorläufige grafische Oberfläche zum Anzeigen und Vergleichen von Testergebnissen verschiedener Überarbeitungsstufen erstellt. Colin Finck hat an einer dauerhafterern Version mit mehr Funktionen gearbeitet. Die neue webbasierte Oberfläche erlaubt das Vergleichen der Ergebnisse von bis zu fünf verschiedenen Builds sowie nur die dazwischen veränderten Ergebnisse zu betrachten. Außerdem wurde der Buildbot, der benutzt wird um die Tests zu kompilieren und durchzuführen, aktualisiert. Das Programm rosautotest wurde von Colin so umgeschrieben, dass es die Tests neu starten kann wenn ReactOS abgestürzt ist. Kombiniert mit dem Aufwand , den Stefan Ginsberg hatte um die Tests zu umgehen, die dafür bekannt sind ReactOS zum Absturz zu bringen, können wir ziemlich sicher sein, dass ReactOS durch die gesamte Testreihe gehen wird anstatt nach einem Absturz aufzuhören. Falls einige von euch mit dem Test Manager spielen wollen, befindet er sich auf dem Test Server unter dieser Addresse.

Mittwoch, 25. März 2009

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!!!

Dienstag, 24. März 2009

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

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 ----------
Date: Thu, Mar 19, 2009 at 12:48 AM
Subject: Thank you for your application


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


______________________________