Software

Anwendungen und Tools rund um RISC OS

Zum Otter der QupZilla

Chris Gransden, Meister der tausend Portierungen, hat wieder zugeschlagen. Basierend auf der Qt5-Portierung von Lee Noar hat er einen weiteren Browser zum Laufen gebracht: QupZilla. Auch dieser basiert letztlich auf WebKit bzw. der Qt-Integration davon namens QtWebKit, genau wie der Otter-Browser.

Download der Testversion hier.

Allerdings wird QupZilla ab Version 2.0.0 auf QtWebEngine umsatteln, die auf Chromium basiert. Da wird eine RISC OS-Portierung deutlich herausfordernder aufgrund der asynchronen Multi-Prozess-Architektur von Chromium. Da wird es sinnvoller sein, die Optimierungsbemühungen in die Qt-Portierung zu stecken und ggf. die WebKit-Innereien zu separieren und ein echtes RISC OS-Frontend drumrum zu bauen.

JPEG-Bounty: Testversion verfügbar

RISCOS Open Ltd. hat die Verfügbarkeit einer neuen Testversion des SpriteExtend-Updates zur Verbesserung des JPEG-Supports verkündet. Die Entwicklung erfolgt im Rahmen des Bounties „Update JPEG support“.

Worum geht es? RISC OS unterstützt nativ seit Anbeginn der Zeit nur ein einziges Bitmap-Format: das hauseigene „Sprite“-Format. Also das Äquivalent zu BMPs unter Windows. Mit RISC OS 3.6 änderte sich das: JPEG wurde ab da ebenfalls unterstützt. Und zwar mittels „on-the-fly-decoding“, also nicht wie frühere Tools wie ImageFS(2) per einmaliger Umwandlung ins Sprite-Format. Das hat besonderen Charme, weil es den Speicherverbrauch niedrig hält – das JPEG bleibt halt als JPEG im Speicher, und wann immer ein Redraw verlangt wird, wird dieser Bildschirmausschnitt aus den Originaldaten bepixelt. Man kann diesen Effekt schön sehen, wenn man in Draw einmal das JPEG reinzieht und einmal das in ein Sprite konvertierte JPEG verwendet – am Speicherverbrauch von Draw erkennt man sofort den Unterschied. Und auch bei der Redraw-Geschwindigkeit – da ist die native JPEG-Variante naturgemäß im Nachteil.

Wie so vieles in RISC OS (man denke an den Netzwerk-Stack) ist auch der JPEG-Support in die Jahre gekommen. Der Code basiert auf Version 4 der Library der Independent JPEG Group von 1993, also Steinzeit. Die neueste Version 9b dieser Bibliothek wurde gestern veröffentlicht. Nun ist alt nicht gleich schlecht, aber in diesem Falle sind eben alle JPEG-Weiterentwicklungen an RISC OS spurlos vorüber gegangen, z.B. die Unterstützung für andere Farbräume als YUV (RGB, CMYK), die progressive Codierung anstatt der normalen linearen (häufig genutzt auf Webseiten, so kann man schon während des Herunterladens eines Bildes dieses in zunehmend besserer Qualität darstellen), Interlace-Codierung, die neue arithmetische Codierung zur Verbesserung der Kompressionsrate, die neue lossless-Kompressionsvariante, vergrößerte Farbräume.

Die veraltete Unterstützung sorgte so für seltsame Blüten bei der Anwendungssoftware. In den allermeisten Fällen wurde entweder zuerst die JPEG-Decodierung dem Betriebssystem überlassen, und wenn das Format inkompatibel war, wurde auf eine eigene Implementierung zurückgegriffen. Oder es wurde gleich eine neuere Version der Referenzimplementierung verwendet. Irgendwann sind dann JPEGs aufgetaucht, die die OS-Implementierung in eine Endlosschleife geschickt haben statt einen Fehler zu produzieren. Kurz: die OS-Implementierung wurde eher hinderlich als nützlich.

Höchste Zeit also für den Frühjahrsputz. Den ersten Aktivitätsnachweis gab es Ende November letzten Jahres, gestern nun das Update. Viele Ziele des Updates sind bereits erreicht: Unterstützung für die Progressive- und Interlace-Codierung, andere Farbräume von RGB bis CMYK, die Arithmetic-Codierung. Das bereitgestellte Modul ist „softloadable“ auf allen Maschinen ab ARMv4, also im Prinzip für alles ab Risc PC.

tl;dr: Neues SpriteExtend-Modul, viel besser als das alte. Runterladen und ausprobieren.

Übrigens: nach dem Update ist vor dem Update. JPEG XT, JPEP-LS, JPEG 2000, JPEG XR, JBIG…

Fireworkz 2 veröffentlicht

Stuart Swales hat Fireworkz 2 zum freien Download veröffentlicht. Sowohl in der Geschmacksrichtung Windows als auch natürlich RISC OS. Hier kann man detailliert die Versionshistorie nachlesen.

Ursprünglich war Fireworkz als Triumvirat aus Textverarbeitung, Tabellenkalkulation und Datenbank angelegt, die sowohl einzeln (Wordz, Resultz und Recordz) als auch integriert (eben Fireworkz) verkauft werden sollten. In der Neuzeit splittet sich das nun in die freie Variante Fireworkz (Textverarbeitung und Tabellenkalkulation) und die kommerzielle Version Fireworkz Pro (R-Comp, 39 UKP, Textverarbeitung und Tabellenkalkulation zusätzlich mit DataPower als Datenbanksystem).

Wer nun allerdings versucht herauszufinden, inwieweit Fireworkz Pro sich von der kostenlosen Variante wirklich unterscheidet, und auf welche Art und Weise die Datenbank denn nun in das Gesamtsystem integriert ist, läuft gegen die bekannte R-Comp-Geheimniskrämerwand. In Form einer der schlechtesten Webpräsenzen aller Zeiten. Vermutlich am aussagekräftigsten ist noch das Announcement im Usenet von 2011. Es ist ein Trauerspiel.

Was ist nun neu in Fireworkz 2? Hauptaugenmerk lag auf der Implementierung vieler neuer Spreadsheet-Funktionen, um eine gescheite Kompatibilitätsbasis für ODF- und Excel-Im- und -Export zu haben. Erste zarte Versuche beim Unicode-Support sind ebenfalls zu verzeichnen. Der verbesserte RTF-Import ist wohl momentan der Pro-Version vorbehalten.

Zero Page Relocation – Gedanken zur Rückwärtskompatibilität

RISC OS steht (zumindest auf den modernen post-Risc PC-Plattformen) vor einem erneuten Schritt, der potenziell Schmerzen bei der Rückwärtskompatibilität verursachen wird. Hier kann man die Gründe, die RISC OS Open Ltd. dafür anführt, nachlesen. In der GAG-News 141 wurde ebenfalls ein Artikel dazu veröffentlicht.

Kurz zusammengefasst geht es um den Speicherbereich der ersten paar KB, der traditionell „Zero Page“ genannt wird und z.B. „Kernel Scratch Space“ beinhaltet und die Prozessorvektoren. Und natürlich die Adresse 0, beliebtes Ziel aller nicht initialisierter Pointer der systemunabhängigen Assemblersprachen (vulgo C und Konsorten).

Die Development-Builds seit dem 5.Juli haben die Zero Page nun in den hohen Speicherbereich verschoben und für Userspace-Code unzugänglich gemacht. Alle Software, die absichtlich oder unabsichtlich auf die Zero Page, wir sich mit einem Data Abort verabschieden. Bzw. das wäre der Fall, wenn nicht gleichzeitig eine Analyse- und Logging-Modul namens „ZeroPain“ aktiv ist. Dieses beantwortet Lesezugriffe in einer kompatiblen Art und Weise und loggt gleichzeitig diese Zugriffe, um dem Softwareentwickler eine Analysemöglichkeit an die Hand zu geben. Wenn es nach dem veröffentlichten Fahrplan geht, wird ZeroPain ab 1.1.2016 nicht mehr zur Verfügung stehen.

Historisch betrachtet gab es bei RISC OS schon einige Zäsuren bezüglich der Rückwärtskompatibilität, und einige Utilities, die versuchten die Rückwärtskompatibilität wieder zu verbessern oder gar vollständig wiederherzustellen. Von RISC OS 2 nach RISC OS 3 gab es einige Verwerfungen, zum einen aufgrund der althergebrachten Home-Computer-Entwicklungsidee „direkt auf die Hardware“, die an einem großflächigen Wechsel der Peripherie-Chips zerschellte (6551 nach 8250, ST506 nach IDE, 1772 nach 82C710/11). Dann diverse Unterschiede zwischen den Betriebssystemversionen selbst – einige APIs erfuhren subtile Änderungen, und wer nicht genau nach Spec implementiert hatte, wurde kalt erwischt.

Dann kam der Risc PC. Wieder gravierende Änderungen in der Chipsatzlandschaft, dazu ein umgekrempeltes Videosystem um die neuen Grafikfähigkeiten abzubilden. Zig Spiele scheiterten aufgrund der Änderungen des VIDC20 gegenüber dem VIDC1. Game On!, eine Software des ARM Club, stellte einen VIDC1-Kompatibilitätslayer zur Verfügung.

Bis zu diesem Zeitpunkt konnte man mit Fug und Recht behaupten, dass Kompatibilitätsprobleme halt durch unfähige Programmierer zustande kamen – die Doku nicht richtig gelesen, die Hardware direkt angesprochen – selber schuld.

Und dann wurde alles anders. Der StrongARM kam. Harvard- statt von-Neumann-Architektur beim 1st level cache und Writeback- statt Writethrough-Konfiguration, was selbstmodifizierenden Code aus der Bahn warf. 5-stufige statt 3-stufige Pipeline mit subtilen Änderungen beim Verhalten des PC. Und dazu der dramatische Geschwindigkeitsboost, der so manche Software aus dem Takt brachte. Dagegen war dann der Schritt RISC OS 3.7 nach RISC OS 4 ein Kindergeburtstag. Viele Softwarehersteller nutzten die Gelegenheit und machten mit Minimalupdates zur Herstellung der StrongARM-Kompatibilität zum letzten Mal Kasse. Mit StrongGuard des ARM Club stand eine Lösung für Spiele zur Verfügung, für Anwendungen gab es so etwas nie.

Aber die größte Zäsur kam erst danach. Von 26bit nach 32bit. Der IYONIX kam, dazu RISC OS 5, und das Ende des „legacy“ 26bit-Adressmodus. Im Prinzip lief danach – außer den reinen BASIC-Erzeugnissen – keine Software mehr. Der geniale Aemulor linderte den Schmerz etwas, aber die Kompatibilität war begrenzt und die Anwesenheit von Aemulor im System hat diverse Nachteile für den regulären Betrieb.

Dann kam das BeagleBoard, und mit ihm die ARMv7-Architektur, wo ARM mal wieder das „nicht-ganz-rückwärtskompatibel“-Spiel spielte. Da das aber nur die relativ selten auftretenden „unaligned loads“ betraf, hielt sich der Schaden in Grenzen – solange der Benutzer die „Alignment Exceptions“ abschaltete. Was uns wieder zur „ZeroPain“ führt, das ja letztlich denselben Ansatz fährt: Verstöße stillschweigend dulden.

Nun also „Zero Page Relocation“. Die Frage lautet wie immer: ist der Gewinn (durch höhere Systemstabilität, für mehr Freiheitsgrade für zukünftige Entwicklung) größer als der Verlust (Software läuft nicht mehr)? Die Antwort liegt vermutlich im Auge des Betrachters – setzt man unersetzliche Software ein, die dann nicht mehr läuft? Es gibt ja nun nicht besonders viele aktive RISC OS-Nutzer (geschweige denn -Entwickler), kann es sich die RISC OS-Welt leisten auch nur einen davon zu verlieren?

Ich muss gestehen: ich habe keine klare Meinung dazu. Endlose Rückwärtskompatibilität führt zu endlos steigenden Aufwänden, was sich ein System wie RISC OS, das nur wenige Entwickler hat, nicht leisten kann. Aber die Anwendersicht hat natürlich erhebliches Gewicht: was soll man mit einem System, das keine Nutzer mehr hat?

Aus meiner Sicht kann es nur einen Ausweg geben: wir brauchen in Zukunft eine wasserdichte Emulationslösung, die solche rückwärtskompatibilitätsbrechende Änderungen abfedert. Im Moment haben wir einen ganzen Zoo von Lösungen: ArcEm, ArchiEmu, ADFFS und Aemulor. Alle haben ihre Nischen und spezifischen Vorteile, sind aber allesamt für den Otto-Normalanwender viel zu kompliziert zu benutzen, bzw. dadurch ausgelöste Effekte sind nicht zu durchschauen. Es bräuchte eine modulare Lösung, zu der auch „normale“ Entwickler beitragen können. Mir schwebt eine Art Hypervisor vor, in den man anwendungsspezifisch Kompatibilitäts-Handler einbauen kann, die z.B. bei SWI-Aufrufen wieder Kompatibilität herstellen können. Dazu muss pro Anwendung entschieden werden, ob sie codetechnisch nativ oder emuliert ausgeführt werden soll. Vollständige Emulation mit einer beliebigen RISC OS-Version muss möglich sein, die Fenster der Anwendung der Emulation müssen in das Host-Betriebssystem „seamless“ eingebunden werden können. An der Prozessorkompatibilitätsfront könnte sowas wie LLVM durchaus helfen.

Was natürlich auch helfen würden: Open Source allüberall. Wird wohl nicht passieren, und braucht dann ja auch eine Menge Kümmerer, die die Software dann pflegen.

Software-Klassiker zum Nachlesen: Ovation

David Pilling hat heute verkündet, dass er den Source-Code eines seiner Frühwerke – dem DTP-Programm „Ovation“ – veröffentlicht hat.

Hier geht es zur entsprechenden Seite mit Download-Möglichkeit. Nur für den Source-Code wohlgemerkt, denn die Rechte für die Software liegen derzeit bei APDL. Nach dem Tod von David Holden soll die dort vertriebene Software irgendwann zum freien Download bereitgestellt werden – ich vermute, dass deshalb David die Zeit gekommen sah, den Source-Code freizugeben.

Ich finde vor allem den Text, den David zu Ovation geschrieben hat, sehr interessant. Denn er enthält ein paar ewig gültige Weisheiten der Softwareentwicklung, die ich folgendermaßen zusammenfassen würde:

  • Software, die gut aussieht, verkauft sich besser
  • Nur Wahnsinnige schreiben einigermaßen komplexe Software in Assembler
  • Wofür man in Assembler ein ganzes Team benötigt, kann selbst in einer assemblerartigen Hochsprache wie C ein einziger Entwickler leisten
  • Auf lange Sicht ist Assembler-Code praktisch unwartbar (siehe auch: Impression-X)
  • Nur weil etwas auf lange bis sehr lange Sicht die richtige Entscheidung war, heißt das nicht, dass man langfristig auch den Erfolg dafür erntet
  • die Software-Entwicklung früher – langsame Maschinen, noch langsamere Massenspeicher, wenig Speicher, kein vernünftiges Tooling – war eine echte Qual (meine Programmierkarriere begann auf einem Schneider CPC 464 – zeilenbasierter Editor, BASIC mit Zeilennummer und GOSUB als einzigem Merkmal strukturierter Programmierung, Speichermedium Datasette)

Manchmal hat man das Gefühl, dass die Software-Entwicklung unter RISC OS immer noch auf dem Stand Ende der 80er Jahre verharrt. Dazu muss man nur mal Diskussionen in diversen Foren verfolgen, wo immer noch das Hohelied auf den Norcroft C-Compiler oder Acorn BBC BASIC gesungen wird. Wirklich professionelle Software-Entwicklung mit den heute gängigen Tools – moderne Versionsverwaltung mit Git oder Mercurial, Continuous Integration, Cross-Compilation auf leistungsfähigen Rechnern, echte Hochsprachen – findet unter RISC OS kaum statt. Stattdessen typische 1-Mann-Projekte in BASIC und C. Was natürlich trotzdem gute Software hervorbringen kann. Aber unter deutlich erhöhtem Aufwand und nicht nachhaltig. Und erhöhter Aufwand ist der Tod für eine Plattform, deren aktive Programmierer man an zwei Händen abzählen kann.

Aber das wäre ein Thema für einen anderen Blog-Beitrag. Oder auch hunderte.

Der Otter ist gelandet

Seit einiger Zeit zirkulieren in kleinem Kreis verschiedene Versionen des WebKit-basierten Browsers namens Otter, wie schon früher berichtet. Jetzt hat Chris Gransden, Meister der hundert Portierungen, den Otter in den Autobuilder gesteckt, was einem offiziellen Release gleichkommt. Siehe auch der entsprechende Thread im ROOL-Forum.

Der Otter-Browser nutzt als UI-Tookit Qt5, das vor einiger Zeit von Lee Noar auf RISC OS portiert wurde. Das führt leider dazu, dass Performance und Desktop-Integration sich leicht suboptimal gestalten. Aber lieber ein langsamer Browser als gar kein Browser. Schwierigkeiten gibt es vor allem noch auf der Javascript-Seite – hier ist nur der Interpreter und nicht der JIT aktiv, weil letzterer noch extrem absturzfreudig ist. Dadurch ist komplexes Javascript eher langsam. Aber um den heimischen Router zu konfigurieren, sollte es reichen.

Um nicht einzuschlafen, ist ein PandaBoard, ARMX6 oder IGEPv5 anzuraten. Ein Raspberry Pi 2 ist grenzwertig.

Jetzt, wo nachgewiesen ist, dass ein WebKit-basierter Browser durchaus brauchbar unter RISC OS auf existierender Hardware funktionieren kann, braucht es nur noch ein motiviertes Individuum, um eine etwas nativere RISC OS-Portierung von WebKit auf den Weg zu bringen.

Kleines Update für OpenVector, OpenGridPro und DrawPlus

Das Triumvirat der ex-4Mation-Anwendungen hat ein Update auf Version 3.46 erhalten, hauptsächlich Bugfixes. Vor allem OpenVector ist ein echtes Kleinod, eine Art Super-Draw.

Runterladen kostet nix, und ARMv7-kompatibel sind die Dinger auch noch. Sourcecode ist verfügbar unter der GPL.

Ein Haufen Software (im Quellcode!) von David Pilling

David Pilling, einer der bekanntesten Programmierer im RISC OS-Universum, hat sein Schatzkästchen geöffnet und ein wenig Quellcode zum Download bereitgestellt.

Besonders interessant: die Bibliothek namens XL. Langjährige RISC OS-Entwickler haben ja alle ihre eigene WIMP-Bibliothek von mehr oder weniger großem Umfang am Start, und David Pilling macht da keine Ausnahme. Kein Wunder, waren die Acorn-Angebote von RISCOS_Lib bis zur Toolbox doch mit großen Problemen behaftet. Ich schaue mir gerne Fremdbibliotheken an – API-Design ist hochinteressant und ein schwieriges Geschäft, da kann man von anderen viel lernen. Und sei es nur, wie man es nicht macht.

Ansonsten für mich interessant sind die Sourcen zu den TWAIN-Scannertreibern, zu SPrinter (für alle, die schon immer unter RISC OS einen Druckertreiber entwickeln wollten) und zu Snapper. Exoten-Bonus gibt es für CSFS, einer Auftragsentwicklung aus den NC-Zeiten.

Danke, David.

Neues vom JASPP – ADFFS 2.50beta und neue Spiele

Jon Abbott hat wieder zugeschlagen. ADFFS 2.50beta http://forums.jaspp.org.uk:9000/forum/viewtopic.php?f=9&t=228 heißt die neu freigegebene öffentliche Beta-Version der ursprünglich-mal-Floppy-Emulator-jetzt-universeller-Spiele-Emulator-Software, die in diesem Blog schon öfter Thema war. Der jetzt erreichte Meilenstein ist ein weitestgehend vollständiger Support der im Rahmen des Projekts bisher freigegebenen Spiele für die Plattform „Raspberry Pi“. Und hier kommt es auf die Feinheiten an, denn tatsächlich wird nur der Ur-Pi (also Model A, Model B und Model B+) unterstützt, nicht der neue Pi 2. Das liegt einfach daran, dass der Ur-Pi noch ARMv5-kompatibel ist, während der Pi 2 ARMv7 ist und das leider bei der Emulation der alten Welt einen riesigen Unterschied macht. Ich sage nur unaligned memory access.

Weitere gute Nachricht vom JASPP: es gibt nun eine Vereinbarung mit Artex Software, Eterna, Minerva und VOTI dahingehend, dass die alten Archimedes-Software-Schätzchen im Rahmen des Projekts veröffentlicht werden können. Wir dürfen uns also auf Klassiker wie Exodus, Rockfall, Ballarena oder Sunburst freuen.

Und Jon macht unermüdlich weiter: sein nächstes Projekt ist die Unterstützung von 26bit-Modulen in ADFFS. Bisher wurden zentrale Module immer als 32bit-Varianten bereitgestellt, meist waren das einfache Dinge wie Voice-Module oder Tracker-Player. Jetzt kommt also die generische Lösung, die einen ganzen Schwung von Spielen auf dem Raspberry Pi dann spielbar machen wird. Darunter alte Favoriten wie Sensible Soccer oder PipeMania.

Nut Pi für Raspberry Pi 2 verfügbar

Bekanntlich basiert der Raspberry Pi 2 auf einer neueren ARM-Microarchitektur – ARMv7 statt ARMv6 mit v5-Kompatibilitätsmodus, Cortex-A7 statt ARM11. Das führte unter anderem dazu, dass das „Nut Pi“-Bundle von RISC OS Open Ltd nur auf dem Original-Pi lief.

Das hat sich nun geändert – ab sofort ist eine Neuauflage der Nut Pi SD-Karte am Start, bei der alle Programme sowohl auf dem RPi(+) als auch dem RPi 2 lauffähig sind.

Am Umfang hat sich nichts geändert – viele Programme sind im Bundle dabei, von einer Spezialversion von Messenger Pro über SparkFS bis PhotoDesk, Luafox und Writer+. Eine schöne Erstausstattung, aber dank des niedrigen Preises von 35 UKP zuzüglich MwSt und Versand auch für die alten Hasen interessant. Das ebenfalls enthaltene DDE – unverzichtbar, wenn man an RISC OS mitentwickeln will – kostet schließlich einzeln schon mehr.

Also meine Kaufempfehlung hat es.