Stopp-Seite schlieen und weiter - Close and continue
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, 23. August 2009
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:
- 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).
- 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,Hinweis: Außerdem läuft zur Zeit ein "Website Design Contest" (>Link<) bis zum 20.August 09 und ein "ReactOS-Logon Sound Wettbewerb" (>Link<).
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
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=42467Allerdings kann man zur Zeit noch nicht online auf anderen Servern spielen, da Nexuiz in ReactOS die Serverliste nicht abruft.
Author: cgutman
Log Message:
- Call IoCompleteRequest to free IRPs created by IoBuildDeviceIoControlRequest
- Fixes bug 4770
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 :)
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.:
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...
Hoffen wir, dass diese neue Implementation bald nutzbar ist, und viel besser als der jetzige Treiber wird.
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.
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.
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
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.
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.
Abonnieren
Posts (Atom)
