ReactOS: Freie Windows-XP-Alternative weiter in Entwicklung
Von ReactOS hört man kaum noch etwas, dennoch geht die Entwicklung an dem freien Windows-XP-Klon weiter.
(Bild: heise online / dmk)
Die ReactOS-Entwickler haben sich mit einem Zwischenstand des derzeitigen Entwicklungsstands gemeldet. Die Entwicklung der Version 0.4.15 schreitet stetig voran, wenn auch langsam. Ursache sind ausstehende Regressionen und Bugs sowie die begrenzten Entwicklungsressourcen und Arbeitskraft.
Im aktuellen Newsletter schreiben die Entwickler, sie wollen deren Frequenz mit Statusinformationen auf mindestens drei im Jahr erhöhen, sofern der Entwicklungsfortschritt das rechtfertigt. Die Fortschritte des Projekts sind dennoch signifikant. Für Entwickler wichtig, wurde etwa der Kernel-Debugger überarbeitet. Der arbeitet nun auch mit den MSVC-Compilern und WinDbg zusammen und hat einige Fehlerkorrekturen erfahren.
ReactOS mit experimenteller UEFI-Unterstützung
Die AMD64-Builds laufen auf immer mehr Hardware. Arbeiten an der Unterstützung von UEFI Klasse 3-Firmware sei im Gange. Der Standard-Bootloader für ReactOS soll FreeLoader werden, der UEFI nicht nur auf x86- und AMD64-Prozessorarchitekturen, sondern auch unter ARM32 und ARM64 unterstützen soll. Neben dem Start von ReactOS arbeiten die Programmierer etwa auch an der Unterstützung von EFI-Chainloading und einem bootmgfw-kompatiblen Build von Freeloader.
Mit Screenhots belegen die Entwickler, dass ReactOS nativ, ohne etwaige Emulatoren, etwa auf einem Steam Deck, einem HTC HD2, einem Lumia 950XL, startbar als Eintrag im Windows Bootmanager eines Framework-Laptops sowie auf einem iPhone 5c läuft. Das Projekt schränkt ein, dass die UEFI-Unterstützung noch stark in Entwicklung und noch nicht alltagstauglich ist. Daher steht sie auch bislang nicht im Haupt-Repository bereit.
Optische Korrekturen gab es ebenfalls. So wurde die Shell optimiert, was etwa zu einer verbesserten Anzeige etwa der Toolbar-Icons von Microsoft Office 2000 und bei anderen Programmen führt. Das Packen und Entpacken von ZIP-Archiven gelingt nun auch mit UTF-8-Zeichen in Datei- und Ordnernamen. Eine Verknüpfung "Internet Browser", die den Standard-Webbrowser im System starten soll, liegt jetzt auf dem Desktop; sie lässt sich mit den Shell-Einstellungen verstecken. Ballon-Tooltips sind optisch nun deutlich konsistenter an Windows angepasst.
Auch bei der DirectX-Unterstützung gibt es Fortschritte. So wurde DirectX aufgrund einiger Probleme im Win32-Subsystem win32k.sys nicht geladen, wodurch Programme und Spiele die DirectX-APIs nicht korrekt zugreifen konnten. Jetzt können mehr davon das DirectX-Kernel-Subsystem dxg.sys nutzen. Außerdem klappt durch die Korrekturen jetzt auch die Änderung des Anzeigemodus in VMware. Zudem haben die Programmierer die DirectX-Bibliotheken auf den aktuellen Wine-Code-Stand gehievt.
Unterstützung für höhere Windows-API-Level
ReactOS hat zum Ziel, Kompatibilität mit Windows Server 2003 herzustellen, das die NT-Version 5.2 darstellte – die letzte aus der NT-5-Familie. Viele Anwendungen von Spielen über Browser und E-Mail-Clients hin zu Utilities setzen jedoch auf neuere Windows-APIs. Ab Windows Vista bis hin zu Windows 11 ist die API-Version NT6+ aktuell, auf die viele moderne Programme setzen. Und die dadurch nicht auf ReactOS laufen. Daher arbeiten erste Entwickler an den APIs und Versionierungssystemen für DLLs, die Routinen anhand von Kompatibilitätseinstellungen exportieren. Der Build-Bot wirft nun erste neue Builds mit NT6-Exports aus, die Experimente mit NT6+-API-Anwendungskompatibilität erlauben.
Auch die NT6+-API-Unterstützung ist experimentell und beschränkt sich bislang auf den Usermode. Kernelmode und damit Support für Treiber und Ähnliches seien ein gänzlich anderes Thema. Zwar sei auch das in Planung, da aber dafür noch sehr viel Arbeit nötig sei, können die ReactOS-Maintainer keine Einschätzung zu einem Zeitplan diesbezüglich abgeben.
Da ReactOS 0.4.15 noch nicht final ist, verweist das ReactOS-Projekt auf die Nightly Builds. Damit lassen sich weitere Tests vornehmen. In der Anfangsphase des Projekts gab es mal Vorwürfe, dass einige Mitwirkende Windows-Code abgeschrieben hätten. Die Entwicklung wurde zwischenzeitlich gestoppt und am Projekt Interessierte hatten schließlich fragwürdigen Code markiert, damit dieser neu nachprogrammiert werden konnte.
(dmk)
