Oktober 2019

You are browsing the site archives by month.

RPCEmu 0.9.2 ist da – mit vereinfachter Netzwerkunterstützung!

Gestern wurde die neue Version von RPCEmu veröffentlicht, namentlich 0.9.2. Aus meiner Sicht als Windows-Benutzer ein riesiger Fortschritt.

Wie schon in meinem Artikel zu Version 0.9.1 angekündigt und sehnlichst erhofft, ist die Hauptneuigkeit ein Modus zur vereinfachten Netzwerkanbindung zur Host-Maschine. Bisher war das – zumindest unter Windows – eine sehr komplexe bis fehlerträchtige Angelegenheit, wo man von Hand nach der Installation einer bestimmten Version von OpenVPN (bzw. dessen TAP-Treiber) eine Netzwerk-Bridge im Windows anlegen musste. Die dann manchmal verschwand, manchmal auch das restliche Netzwerken von Windows beeinflusste, und generell sehr unpopulär war. Unter Linux war das Tunneling, das eigentlich einfacher sein sollte, seit neuestem faktisch unmöglich weil die Root-Elevation nicht mehr korrekt mit Qt funktionierte. Ein sehr unbefriedigender Zustand.

Jetzt ist alles neu und besser und hört auf den Namen “NAT networking”. Noch immer nicht ganz so problemlos und elegant integriert wie bei V-RPC, aber deutlich einfacher als vorher. Aber ein wichtiger Hinweis: man sollte nicht “wie gewohnt” das RISC OS-Netzwerk konfigurieren (wie ich es zunächst erfolglos versucht habe), da es sich tatsächlich um echte NAT handelt – intern bekommt das emulierte RISC OS also eine eigene IP-Adresse, die immer 10.10.10.10 ist, und RPCEmu faked drumrum einen Router (10.10.10.2) und einen DNS-Server (10.10.10.3) dazu, und die Host-Maschine bekommt im Prinzip nichts davon mit. Also unbedingt die (sehr gute) Anleitung lesen. Hat man ein RISC OS, das DHCP unterstützt (also RISC OS 4.29 aka “Select 1” aufwärts), ist es wirklich sehr einfach.

Wichtige Einschränkungen: ping funktioniert nicht, ShareFS funktioniert nicht (weil nicht auf routebarem IP basierend), und die RISC OS-Maschine ist von außerhalb z.B. als Server nicht ansprechbar, weil kein Port-Forwarding implementiert ist. Die Abwesenheit von ShareFS ist natürlich bitter, weil oft die mit Abstand einfachste Möglichkeit, zwischen RISC OS-Rechnern Dateien zu sharen. Aber es braucht ja noch Luft für die 0.9.3.

Eine kleine Verbesserung wartet im Bereich “Diskettenlaufwerk” – hier kann jetzt neben dem bekannten .adf auch .img, also gewöhnliche DOS-Images, als virtuelles Diskettenlaufwerk gemountet werden.

Ein kleiner Wermutstropfen ist die Tatsache, dass aufgrund der verwendeten neuen Qt-Version nun nur noch Windows ab Version 7 aufwärts offiziell unterstützt wird. Für Retro-Zwecke leicht suboptimal, weil die PCs, die noch eine “echte” Floppy intus haben (und damit Filecore-formatierte Disketten vernünftig ansprechen können), oft unter Windows XP laufen. Aber es gibt ja Alternativen (wenn schon Retro, dann Arculator oder VA5000).

Erste Anzeichen für GCC 8.2.0

Bekanntlich ist die neueste für RISC OS verfügbare GCC-Version die 4.7.4. So alt, so gut. Normalerweise ist das auch kein größeres Problem, RISC OS ist ja eher so retro und verfolgt nicht gerade den Ansatz, alles was nicht bei drei auf den Bäumen ist aus der Linux-Ecke zu portieren. Aufgrund der Unterschiedlichkeit der Ansätze von RISC OS und Linux macht das sowieso nur Ärger und Aufwand (vom Dateisystem bis zu so profanen Dingen wie Forken neuer Prozesse), und das Resultat ist oft auch gerade performancetechnisch unbefriedigend. Aber gerade bei C++ ist die Zeit nicht stehen geblieben, und da wäre ein aktueller Compiler schon von Vorteil. Ganz zu schweigen von neuen hippen Sprachen wie D oder Go, die von neuen GCC-Versionen unterstützt werden.

Ich vermute aufgrund der beteiligten Personen, dass die aktuellen Browser-Projekte (WebKit-Portierung und OWB-WebKit-Portierung) aufgrund der C++-Problematik nun Bemühungen getriggert haben, eine aktuellere GCC-Version an den Start zu bringen. Lee Noar, seines Zeichens Mastermind hinter dem RISC OS-ELF-Support, hat aktuell im riscos.info-GCCSDK-Repo eine ganze Menge Änderungen einfließen lassen, die auf eine baldige Verfügbarkeit von GCC 8.2.0 für unser aller Lieblingsbetriebssystem hoffen lassen. Hier die Details. Wie immer erst die GCCSDK-Version zum Crosscompile, dann hoffentlich auch eine native Version.

Was sind die Fortschritte zwischen 4.7.x und 8.x.x? Für eine Einschätzung des Versionssprunges ist zunächst wichtig zu wissen, dass das GCC-Projekt irgendwann mal das System der Versionsvergabe umgestellt hat. Früher wurde nur alle Schaltjahre mal die Major-Version erhöht – 2.x erblickte 1992 das Licht der Welt (die gängigen Versionen für RISC OS waren 2.3.3, 2.4.5, 2.7.2 und 2.95), 3.x dann ab 2001, 4.x ab 2005, und ab 5.x (2015) gab es dann die Major-Versionen in schnellerer Folge, ungefähr jährlich. Von 4.7.x ist es also nicht ganz so weit bis zur aktuellsten 9.x-Version wie es zunächst den Anschein haben könnte. Auch C++ hat bei der Standardisierung von neuen Versionen ja einen Zahn zugelegt, da passt beides recht gut zusammen. Beispielsweise die Variante C++11 wurde experimentell seit GCC 4.8 unterstützt, GCC 5.x enthielt erste Unterstützung für C++14, GCC 6.x hatte dann C++14 schon als Default und enthielt erste Features von C++17. GCC 8.x beginnt schon mit Draft-Features aus C++2X, das vermutlich 2020 als Standard C++20 verabschiedet werden wird.

Also: Daumen drücken, dass das RISC OS-GCC-Ein-Mann-Team bald Erfolge vermelden kann. Eine aktuelle C++-Toolchain wird immer gebraucht. Wenn jetzt noch jemand sich an LLVM und Clang versuchen würde…und dem aktuellen GCC wieder die Erzeugung von ARMv2-Code nahebringen könnte…aber wer mal das ARM-Backend des GCC angeschaut hat, das ist eine 30000-Zeilen-Codewüste…