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.
Abonnieren
Posts (Atom)
