Hi Michael,
i made a german FAQ for your website, tonight.
I've post it here. Maybe some of the german capable readers have still
some comments or suggestions to it.
Werden alle Windowsprogramme laufen?
ReactOS implementiert das Win32-API. Theoretisch sollten dann alle Programme laufen.
Doch unterscheidet sich die Theorie mal wieder von der Praxis und einige Programme werden
nicht laufen. Das sind dann solche Programme, die sich auf irgendwelche (meist undokumentierten)
Besonderheiten der Microsoftsysteme verlassen bzw. die Betriebssystemversion prüfen.
Im Moment sieht es mit funktionierenden Programmen naturgemäß schlecht aus. Doch
über die Zeit werden immer mehr Programme laufen. Da es sich um ein Quelloffenes
System handelt dürften über die Zeit vielleicht sogar alle win32-Programme laufen.
Wieso macht ihr das?
Wir hassen Microsoft und seine Art Windows zu implementieren. Wir können uns aber auch nicht mit
Linux auf dem Desktop anfreunden und diesem Flickwerk zwischen Millionen Dateien, Wine, X,
Windowmanagern, Toolkits und Drucksystemen. Da das technische Konzept hinter WindowsNT und Nachfolger gar
nicht so schlecht ist, wie viele immer glauben, deshalb tun wir das.
Windows ist doch so Sch* wieso baut ihr das nach?
Windows war Mist und ist es wieder geworden -- Zugegeben.
Insbesondere die DOS-Versionen. Hier geht es aber um die NT-Versionen.
Und die sind gar nicht mal so schlecht, wie viele immer glauben. Insbesondere
wenn man mal den NT-Kernel verstanden hat, wird einem klar, dass der von jemandem
entworfen wurde, der sein Handwerk wirklich verstand. Es war Dave Cutler von Digital,
der zu diesem Zweck von Microsoft mitsamt seinem Team gekauft wurde. Insofern ist
der NT-Kernel keine Microsoftentwicklung. In diesem Kernel stecken viele tolle Konzepte
drin. Auch das Konzept des eigentlichen Betriebsystems (Durchgehende Sicherheit, Subsysteme,
Dateisystemtreiber, Dienste, Registry) ist ausgezeichnet. Nur was Microsoft
daraus gemacht hat, das ist wahrlich nicht mehr das gelbe vom Ei.
Dies lässt sich ändern, wenn man an die Quelltexte von Windows dran käme.
Da das jedoch nicht möglich ist, außer wenn man es nachbaut, haben wir diese Projekt
in Angriff genommen.
Warum helft ihr nicht dem Wine-Projekt?
Wir arbeiten doch mit dem Wine-Projekt zusammen. Wine hat vermutlich mehr mit
ReactOS gemeinsam als mit Linux. Das Wine-Projekt hat sich zur Aufgabe gestellt,
neben dem winserver und den Kern-DLLs alle APIs von Windows nachzuprogrammieren.
ReactOS und sein Win32-Subsystem besteht im Wesentlichen aus dem Kernel und den
Kern-DLLs (NTDLL.DLL, USER32.DLL, KERNEL32.DLL, GDI32.DLL und ADVAPI.DLL). Diese
zu Implementieren ist unsere eigene Aufgabe. Alles Weitere (z.B. COMDLG32.DLL)
können wir jedoch mit dem Wine-Projekt teilen. Unsere gemeinsame Aufgabe ist es,
die Wine-DLLs über beide Systeme portabel zu gestalten, und die unter WINE nicht
relevanten und somit fehlenden Funktionen für ReactOS nachzurüsten.
Wieso nehmt ihr nicht den Linux-Kernel und Wine?
Wir sind überzeugt, Linux+Wine nie eine echte Windows-Alternative sein kann.
Das ist wohl nur mit einem "windowsartigen" Betriebssystem möglich.
Der Knackpunkt rund um Wine ist doch der:
Wer jetzt Linux auf dem Desktop hat, der verwendet Linux-Programme und wer
im kritischen Bereich / ernsthaft unterschiedliche Windowsprogramme einsetzen
muss/will, der geht zu Microsoft. Und das bringt Wine nicht voran.
Darüber hinaus haben wir mit einem Kernel, der WindowsNT-Treiber laden kann,
doch die ideal unterstützte Plattform. Das Problem Treiber existiert quasi nicht.
Wird ReactOS auch so instabil?
Welch eine Frage... Ernsthaft gesehen war Windows NT und folgende eigentlich nie
instabil. Abstürze bzw. die berühmten blauen Bildschirme hatten in aller Regel
zwei Ursachen: Treiber, die unsauber programmiert wurden und Hardwarefehler
bzw. Ressourcenkonflikte.
ReactOS hat momentan naturgemäß noch ziemlich Absturzfreudig. Doch das wird sich
mit der Zeit ändern. So schnell wie bei Linux wird es allerdings nicht gehen. Immerhin
implementieren wir von Anfang an Merkmale, die zum Teil Linux erst mit Version 2.6
bekommt. Aber dann, wenn ReactOS stabil ist, sind es nur die Treiber, die das Gebäude zum
Einsturz bringen können.
Warum ist die Grafik nicht auf Ring 3 sondern auf Ring 0?
Kurz: Weil Microsoft es genauso macht, und wir nur so dieselben Treiber
verwenden können.
Und warum macht es Microsoft so? Weil
sich daraus Geschwindigkeitsvorteile ergeben. Im Gegensatz zu einem Grafikserver,
der in einem eigenen Prozess läuft, sind hier keine Kontextwechsel bei Grafikausgaben
nötig. Das macht natürlich die Architektur unsauberer und wenn die Grafik abstürzt,
dann ist das ganze System weg. Außerdem wird dadurch der Kernel aufgebläht.
Dieselbe Diskussion hat es in Redmond auch gegeben, als die Grafik bei WinNT 4.0
in den Kernel wanderte. Dabei ist man zu dem Schluss gekommen, dass die Grafik inzwischen
so ausgereift ist, dass nichts mehr passiert und wenn im Benutzermodus etwas schief
geht, dann sind die Konsequenzen ähnlich. Die meisten Prozesse werden abgewürgt.
Insofern muss man die ReactOS Grafik einfach mit der Linuxkonsole vergleichen. Wenn dort
ein Fehler drin ist, dann ist auch der Teufel los. Aber wenn man stabile Grafiktreiber hat
und das Grafiksystem ausgereift ist, dann passiert dort auch nichts.
Hat ReactOS die gleichen Sicherheitsmängel?
Windows NT und Nachfolger sind an sich eigentlich keine inhärent unsicheren Systeme.
Es ist nur so, dass Microsoft ein an sich sicheres System durch fehlgeleitete Entwicklung
unsicher gemacht hat. So richtet z.B. WinXP jeden Benutzer als Administrator ein.
Der Internet Explorer ist ein Scheunentor. Dienste sind Schlampig implementiert.
Der Benutzerkomfort geht vor Sicherheit. Dies erkannt können wir es anders machen.
Problematisch wird dabei jedoch sein, dass Microsoft zu wenig
Druck auf die Softwarehersteller ausgeübt hat, ihre Produkte auch unter normalen
Benutzerkennungen lauffähig zu machen.
Welche Oberfläche kann ich verwenden?
Dazu muss man erst einmal verstehen, wie in ReactOS / WinNT die Oberfläche funktioniert.
-Die Win32-Kernelgrafik mit Grafiktreibern. Diese Komponente bietet Grafikprimitive wie Rechtecke, Linien und BitBlit-Operationen.
-Das Win32-Subsystem (CSRSS.EXE). Dieses Stellt Fensterrahmen und Konsolenfenster zur Verfügung.
-Die Biliothek USER32.DLL. Diese stellt die Grafischen Kontrollelemente etc. zur Verfügung
-Die Shell (z.B. Explorer). Das ist ein normales Programm, das nur als erstes gestartet wird und evtl. den kompletten Bildschirm einnimmt.
Technisch wäre es möglich XFree86 laufen zu lasen. Für OS/2 gibt es z.B. einen derartigen
Port. Dann laufen allerdings keine Win32-Anwendungen mehr auf ReactOS, denn das Win32-Subsystem
basiert auf der Win32-Kernelgrafik. Es müsste daher umprogrammiert werden. Doch das macht nicht
wirklich Sinn, denn ReactOS soll als Basis für viele Subsysteme dienen und da macht es sich
gut, wenn nur eine Grafikschnittstelle existiert. Außerdem erschließt man sich so die vielen
guten und schnellen Grafiktreiber die es so gibt.
Man kann also technisch X, Y, Fresco oder picoGUI laufen lassen, doch wird man dann auf das
win32-Subsystem und die Grafiktreiber verzichten müssen.
Welche Shell läuft?
Das ReactOS-App-Team programmiert einen eigenen Explorer, der dem "original" ähnlich sieht.
Es steht allerdings jedem frei, das Shellprogramm seiner Wahl zu verwenden. Auch bei WinNT und
Nachfolgern ist es nur ein Registry-Eintrag, um z.B. CMD als Shell zu verwenden. Wenn das OS/2-
Subsystem fertig ist, kann man auch die WPS als Shell verwenden...alles ist erlaubt.
Zu diesem Zweck wird unser Winlogon ein entsprechendes Kombinationsfeld enthalten.
Was passiert wenn Microsoft ReactOS findet?
Vermutlich hat Microsoft RectOS schon längst entdeckt. Um gegen Klagen
gefeit zu sein, wurde die ReactOS-Foundation gegündet. Dabei handelt es sich um
so etwas Ähnliches wie einen gemeinnützigen Verein. Kommt eine Klage, geht die ROS-F
pleite und eine neue wird gegründet. Aber warum sollte Microsoft überhaupt etwas machen?
Überlegt mal, was wohl passiert, wenn Microsoft einen Prozess gegen die ReactOS-Foundation
anstrengt. ReactOS wird vermutlich noch bekannter als Linux (wer erinnert sich noch an
Mike Rowe Soft?). Dies kann nicht im Interesse von Microsoft sein, denn dann heißt es
in der Industrie noch mehr ReactOS als jetzt schon Linux.
Und selbst in den USA ist ein ausforschen von Schnittstellen erlaubt, um eine eigene
Implementierung zu erstellen.
Gibt es immer noch Laufwerksbuchstaben?
Ja, leider. Laufwerksbuchstaben sind eine Semantik, die zu Win32 dazugehört. Theoretisch sollte
heute eigentlich keine Anwendung mehr vollqualifizierte Dateinamen auf Gültigkeit überprüfen,
denn dazu gibt es Systemeigene Routinen. Doch man glaubt nicht wie viel schlecht programmierte
Software in der Welt ist.
Denkbar wäre jedenfalls eine abwärtskompatible Erweiterung des Laufwerkskonzepts -- wir arbeiten
dran.
Laufen DirectX-Spiele auf ReactOS?
Momentan: Nein. Aber es ist geplant. Momentan gibt es jedoch noch Millionen anderer wichtiger Dinge.
Laufen DOS-Programme?
Momentan: Nein. Sobald allerdings Bochs läuft funktionieren DOS-Programme. Ein dediziertes
DOS-Subsystem im v86-Mode wie bei WinNT ist nicht geplant bzw. noch nicht. Denkbar wäre
jedoch, Bochs derart zu modifizieren, dass ein transparenter Dateizugriff möglich ist und
alle Programme Interpretiert werden. So, wie es auch auf den nicht x86-Portierungen von NT der Fall war.
Laufen Linux-Programme?
Momentan: Nein. Ziel ist es jedoch. Es existiert die Basis eines POSIX-Subsystems. Da
Linux-Programme zumeist eh im Quelltext vorliegen wäre das eine Möglichkeit.
Anfang 2004 ist coLinux herausgekommen. coLinux ist ein Linuxkernel, der unter WinNT läuft.
Die Leute vom coLinux-Projekt haben zugesagt, ihn auch auf ReactOS zum laufen zu bringen und
daraus irgendwie geartet ein Linux-Subsystem zu machen -- Lassen wir uns überraschen.
Laufen FreeBSD-Programme?
Nein. Bislang ist auch nichts Derartiges geplant. Wobei es allerdings nicht
abwegig ist, z.B. die FreeBSD-Peronality von Darwin (die Grundlage von MacOS X)
zu portieren.
Gibt es ein POSIX-Subsytem?
Es existiert eine Basis eines POSIX-Subsystems.
Laufen OS/2-Programme?
Momentan: Nein. Es ist jedoch in Planung und eine Materialsammlung existiert bereits.
Die Truppe von OSfree, die ein freies OS/2 implementieren will, wird vermutlich den
Kernel von ReactOS als Basis verwenden und es wird somit ein OS/2-Subsystem entstehen.
Ziel ist es 32-Bit OS/2-Anwendungen inklusive Presentation Manager laufen zu lassen.
Läuft Java auf ReactOS?
Ja. Solange sie im Textmodus laufen -- doch werden die ersten Swing und SWT-Programme
nicht mehr lange auf sich warten lassen.
Daneben gibt es noch das Projekt JOS, dessen Ziel es ist, ein Java-Subsystem für ReactOS
zu bauen, und ein JavaOS auf ReactOS-Basis herauszubringen.
Laufen .NET-Anwendungen?
Keine Ahnung. Aber früher oder später bestimmt. Es kommen dazu sowohl Mono als auch Microsofts
.NET-Framework als Laufzeitumgebung in betracht.
Hat ReactOS einen X-Server?
Ein X-Server ist primär kein Bestandteil des Betriebssystems, so auch nicht von Reactos.
Für ein Linux- /Posix- /BSD-Subsystem macht er aber durchaus Sinn. Dennoch bleibt es jedem
selbst überlassen, einen X-Server zu installieren.
Funktioniert meine Hardware mit ReactOS?
Wenn sie WDM-Treiber (Windows Driver Model Treiber) mitbringt, und diese sich
nicht gegen ReactOS wenden, Ja. Momentan (1/04) sieht es aber mit funktionierenden
Treibern noch ziemlich Mau aus. Das liegt einfach daran, dass die Infrastruktur im
Kernel noch nicht so weit ist.
Funktionieren die Treiber von Windows?
Theoretisch Ja. Momentan (1/04) sieht es aber mit funktionierenden
Treibern noch ziemlich Mau aus. Das liegt einfach daran, dass die Infrastruktur im
Kernel noch nicht so weit ist.
Läuft das Netzwerk?
Nein. Mit einer Realtec-Karte kann man eine ReactOS-Kiste anpingen. Das war's.
Aber die Zeit wird auch das bringen.
Kann man ReactOS im Textmodus betreiben?
Ja. Die ersten Versionen waren nur im Textmodus. ReactOS schaltet in den Grafikmodus, sobald
eine Anwendung ein Fenster öffnen will. Es ist geplant, dass man ReactOS auch weiterhin
ohne grafische Oberfläche verwenden kann.
Welche Dateisysteme werden Unterstützt?
Im Moment gibt es nur (V)FAT in all seinen Varianten mit 12, 16 und 32 Bit.
Es wird an einem NTFS-Treiber gearbeitet, doch wie man am Beispiel Linux-NTFS
sieht handelt es sich dabei nicht um ein geringes Vorhaben. Es wird daher
noch eine Weile dauern, bis NTFS voll unterstützt wird.
Von dritter Seite existieren inzwischen einfache Dateisystemtreiber für
ext2/3 und ReiserFS.
Das Dateisystem JFS ist in Planung.
Irgendwann wird es dann wohl auch BFS, UFS und FFS-Treiber geben.
Werdet ihr Samba einsetzen?
Nein. Zumindest nicht in der Form. Samba ist ein unix-Programm und auf dessen Semantik
angepasst. Es erfordert umfangreiche Änderungen, damit es sich in das Rechte- und
Dienstesystem von ReactOS einfügt. Daher wird wahrscheinlich der Kern von Samba, die
Protokolle, in einen eigens entwickelten Dienst eingebaut.
Kann mit ReactOS ein eigenes Betriebsystem machen?
Ja. Der Kernel mitsamt seinen Stadardtreibern steht unter der GPL und jeder kann daraus
etwas machen. Für ein "neues Betriebssytem" auf Basis des ReactOS-Kernels muss man
lediglich ein neues Subsystem schreiben.
Unterstützt die grafische Oberfläche TrueType-Schriften?
Ja. Wir verwenden für die GUI die FreeType2-Bibliothek zum Rendern der Schriften.
Was also FreeType2 kann kann auch die GUI. Mitgeliefert werden die von Bitstream
frei gegebenen TrueType-Schriften.
Für welche Plattformen / Prozessoren gibt es ReactOS?
Im Moment gibt es ReactOS nur für x86 bzw. IA-32 -Prozessoren.
Da ReactOS auf Portabilität ausgelegt ist, wird es wohl in nicht all zu ferner Zeit
auch auf anderen Prozessoren laufen. Angedacht sind auf jeden Fall nebst PowerPC,
Alpha und AMD64 auch ARM und die RS-Familie für den Embedded-Bereich.
Unter welcher Lizenz steht ReactOS?
Unter der GPL. Die Kern-DLLs und Headerdateien diverser Subsysteme stehen unter der LGPL, so
dass es gefahrlos möglich ist kommerzielle Anwendungen dafür zu entwickeln.
Hat ReactOS auch eine Registry?
Ja. Sie ist sogar bis auf Formatebene kompatibel.
Warum benutzt ihr diese fürchterliche Registrierung und nicht Textdateien?
Aus Kompatibilität, und weil eine Textdatei gnadenlos langsam würde. Wir können die Reg-APIs nicht derart umbiegen, dass sie fortan auf Textdateien arbeiten, denn sie beziehen sich auf die Registrierung als Ganzes und das würde dann nicht mehr gehen. Viele führen ja an, die Registrierung sei die Ursache für große Undurchsichtigkeit der Konfiguration. Doch das stimmt so nicht. Wie so oft ist das Konzept gut, nur nicht gut umgesetzt. Bei vielen Programmen herrscht einfach nicht genug Disziplin, was das benutzen der Registrierung angeht. Viele Programme sind ja noch nicht einmal Mehrbenutzerfähig und speichern eine globale Konfiguration, was dann zumeist auch die Ausführung als Administrator impliziert. Es spricht übrigens nichts dagegen, dass ein Programm auch heute noch alles über INI-Dateien löst. Es ist nur eine Frage des Wollens. Zur Beruhigung sei gesagt, dass wir die Registrierung mehr oder weniger neu aufbauen und mithin ausmisten - bis sich eben auch dort keiner mehr auskennt.
