Projekte

Wieder nix in 2018, neuer Versuch in 2019

2018 neigt sich dem Ende, und im Jahresendspurt passiert erfahrungsgemäß vor lauter anderen Verpflichtungen eher wenig. Nachfolgend die Liste der Softwareprojekte, die ich “eigentlich” in 2018 erledigen wollte, die aber weiter ihrer Finalisierung harren. Oft fehlen nur Kleinigkeiten, oder “nur noch das letzte Feature”, oder etwas Feinschliff.

CDVDBurn

Der Klassiker gleich zu Anfang. Das letzte offizielle Release, Version 2.02b (auch wenn als Beta gelabeled), war Feburar 2007. Seither plane ich ein neues Release. Was ist seither passiert? DVD-RAM kann geschrieben werden. Blu-Ray kann als BD-R und BD-RE geschrieben werden. Ein Extraktor ist nun integriert, mit dem man unabhängig von CD(ROM)FS Daten-CDs/DVDs/BDs anschauen kann und Dateien extrahieren kann, inklusive Unterstützung für Joliet und ein Subset der Rockridge-Extensions (soweit unter RISC OS sinnvoll). Dazu wurde die Lauffähigkeit unter ARMv7 und ARMv8 sichergestellt (ein echtes Abenteuer mit dem uralten Ada-Compiler). USB-Unterstützung für RISC OS 5 ist an Bord, ebenfalls S-ATA-Unterstützung fürs neue ADFS (z.B. auf Titanium und IGEPv5).

Ich hatte die Hoffnung, auf zumindest einem gängigen USB- und S-ATA-Laufwerk das DVD-R-Schreiben hinzukriegen, bin aber gescheitert. Einen Versuch habe ich mir noch vorgenommen (Incremental Writing statt DAO/TAO mit reserved track), und dann wird endgültig released, egal ob mit oder ohne DVD-R-Unterstützung. Dual-Layer-Unterstützung für BD-R und BD-RE wäre auch noch schön. Das Update wird kostenpflichtig werden, ich hatte einige Investitionen in Laufwerke und andere Hardware.

TapirMail

David Llewellyn-Jones hat 2018 den Sourcecode für TapirMail auf GitHub freigegeben. Mein Plan war, den Sourcecode etwas aufzuräumen, mit aktueller OSLib und aktuellem GCC und DDE baubar zu machen (so richtig mit Makefile und so…) und dann per Pull-Requests die weitere Entwicklung voranzutreiben. Beispielsweise die Unterstützung für Secure POP3/SMTP, und ggf. auch IMAPS. Da bin ich mittendrin steckengeblieben – bauen tut alles, aber Weiterentwicklung ist nicht geschehen, und ich stecke noch in den Überlegungen, wie so ein RISC OS-Projekt unter GitHub anständig strukturiert sein sollte. Jetzt, mit Jeffreys Git-Client (oh, darüber wollte ich ja auch noch bloggen…), ergeben sich da neue Möglichkeiten.

Isofier

Aus der Reihe “Java-basierte Software für RISC OS, aber nicht unter RISC OS”: ein ISO9660/Joliet-Image-Erzeuger. Die Kommandozeilenvariante funktioniert prächtig, das grafische UI nicht so wirklich. Die Besonderheit ist die volle Unterstützung für die HostFS-Implementierungen von RPCEmu und VirtualRPC, es werden also die Filetype-Extensions automatisch in CDFS-Extensions gewandelt, unter Berücksichtigung der VRPC-extensions-Konfiguration und einer MimeMap-Datei.

ImageTransformer

Aus der Reihe “Java-basierte Software für RISC OS, aber nicht unter RISC OS”: ein Konverter für das CDVDBurn-Fake-Image-größer-als-2-GiB-Format. In beide Richtungen natürlich. Nützlich, um unter RISC OS erzeugte Images dann auf dem PC brennen zu können, oder auf dem PC erzeugte Images (z.B. mit oben genanntem Isofier) unter RISC OS brennen zu können.

SpriteConverter/SpriteViewer

Aus der Reihe “Java-basierte Software für RISC OS, aber nicht unter RISC OS”: SpriteConverter ist ein Kommandozeilentool zur Konvertierung einer Sprite-Datei (also allen oder einzelnen Sprites darin) in PNG, JPEG, GIF oder was auch immer als Java ImageIO-Plugin zur Verfügung steht. SpriteViewer setzt auf demselben Code auf und zeigt in einer grafischen Oberfläche den Inhalt einer Sprite-Datei an, einmal in einer !Paint-artigen Übersicht, dann aber auch per Doppelclick in Originalgröße mit Zoommöglichkeit und Palette. Man kann einzelne Sprites daraus auch direkt als PNG, JPEG oder GIF exportieren. Geplant als kostenlose Software.

ArchiveViewer

Aus der Reihe “Java-basierte Software für RISC OS, aber nicht unter RISC OS”: eine grafische Oberfläche zur Anzeige der Inhalte typischer RISC OS-Archivdateien wie Spark, ArcFS, PackDir, Squash und ZIP, mit voller Filetype-Unterstützung. Basiert hauptsächlich auf der großartigen Vorarbeit namens riscosarc von James Woodcock. Geplant als kostenlose Software.

BBC BASIC Detokenizer

Aus der Reihe “Java-basierte Software für RISC OS, aber nicht unter RISC OS”: ein kleines Tool, um tokenisiertes BBC BASIC V/VI in plain text umzuwandeln. Mit oder ohne Zeilennummern. Geplant als kostenlose Software.

FilecoreImageReader

Software, um Sprites zu lesen, um Archive zu lesen, um BBC BASIC zu lesen…wofür das alles? Auslöser war der vorerst letzte Teil aus der Reihe “Java-basierte Software für RISC OS, aber nicht unter RISC OS”: ein mächtiges Werkzeug, um Filecore-Images (.adf, .hdf) anzuschauen und Dateien und/oder Verzeichnisse daraus zu extrahieren. Unterstützt D, E(+) und F(+)-Format, minimaler Speicherverbrauch auch bei riesigen Images. Anzeige des Verzeichnisbaumes mit den “echten” RISC OS-Icons. Anzeige der Inhalte von Sprite-Dateien, Archiv-Dateien, Plain-Text-Dateien und BASIC-Dateien (andere Dateitypen werden in einer Hexdump-View angezeigt). Im Moment baue ich gerade echte Acorn Latin 1 Codepage-Unterstützung, um sowohl die Plain-Text-Anzeige als auch die Konvertierung der Dateinamen besser hinzukriegen. Und ich hätte gerne eine Filer-like-Ansicht für einige Inhalte, damit das eleganter aussieht. Und es gibt noch irgendwo einen Bug, der bei einem Disc-Image das mir vorliegt bei, Scannen der Verzeichnisstruktur in eine Endlosschleife gerät. Mindestens das Erkennen der Endlosschleife mit sauberem Abbruch des Lesevorgangs wäre Voraussetzung für ein baldiges Release. Außerdem würde ich gerne automatisch die !Sprites-Dateien von Apps direkt zur Visualisierung verwenden.

Ein Projekt wie FilecoreImageReader ist natürlich in ständiger Gefahr, dem “Feature Creep” zu erliegen. Man könnte doch bekannte Filetypes aus der PC-Welt auch noch direkt als Inhalt anzeigen (Grafikformate, PDF, PostScript…). Und generell die UI Filer-like machen. Und noch ein RISC OS-artiges Look&Feel für Swing bauen. Und eine Anzeige von Draw-Files ermöglichen. Und Templates. Und Impression…und Artworks…

Auf jeden Fall wird es eine kostenpflichtige Version mit all den coolen Features geben, und eine freie Version wo man nur den nackten Verzeichnisbaum mit Extraktionsmöglichkeit hat, möglicherweise auch limitiert auf Floppy-Images.

RISC OS-Wünsche zum neuen Jahr 2017

Zu Weihnachten 2015 hatte ich neben den Weihnachtsgrüßen einen kleinen Wunschzettel verfasst. Diese Tradition will ich hier fortsetzen. Nebenbei: meinen Lesern alles Gute fürs Jahr 2017. Here we go again.

Unglücklicherweise sind die 5 Punkte von letztem Jahr noch offen, deshalb wiederhole ich sie hier:

  • neues CDVDBurn-Release
  • Basis-Multicoreunterstützung in RISC OS
  • die Vervollständigung der 32bit-ung von Impression-X
  • Runderneuerung der Filesystem-Architektur in RISC OS
  • BeagleBoard-X15 mit RISC OS-Port

Ersteres ist besonders ärgerlich, aber es gibt zwei “must haves”, die noch nicht fertig sind: Unterstützung für S-ATA auf dem Titanium-Board, und verbesserte Medienkompatibilität auf zumindest einem noch aktuell erhältlichen Laufwerk (BD-R, BD-RE, DVD-RAM, DVD+RW und DVD+R und/oder DVD-R).

Neue (zusätzliche) Wünsche habe ich auch noch:

  • Lösung des RISC OS-Browser-Problems (entweder durch Weiterentwicklung von Netsurf oder Verbesserung der WebKit-basierten Otter und QupZilla)
  • Verfügbarkeit einer Ready-to-run-VM für GCCSDK und Portierungen
  • WLAN-Unterstützung und IP-Stack-Update
  • Portierung aktueller VCS wie Git und Mercurial

Aus meiner Sicht ist die mangelnde Verfügbarkeit von WLAN-Unterstützung und gescheitem Browser genau das, was RISC OS von einer “allgemein nützlichen Lösung” jenseits der Legacy-User trennt. Gerade mit Verfügbarkeit des On-Board-WLANs beim RPi 3 wird dieser Mangel noch ärgerlicher.

RISC OS-Projekte: Ein kompetenter BASIC-Compiler

Im RISC OS Open-Forum läuft gerade eine Diskussion zum Thema BBC BASIC und der Verfügbarkeit von BASIC-Compilern. Eigentlich trage ich mich schon länger mit dem Gedanken, einen Blog-Eintrag mit dem Thema “BBC BASIC – Fluch und Segen für RISC OS” zu verfassen. Die Diskussion hat mich nun dazu motiviert, weniger negativ (“Fluch”) über die Sache zu denken, sondern die Chancen darin zu sehen.

In der RISC OS-Welt hat BBC BASIC eine besondere Stellung. Vom BBC Micro über den Acorn Archimedes bis zum neuesten Titanium oder Raspberry Pi steckt der BBC BASIC-Interpreter überall standardmäßig drin. Die Handbücher früher beschrieben ausführlich den Einstieg in die Programmierung mit BBC BASIC. Letztlich war also BBC BASIC für viele RISC OS-Benutzer der erste Kontakt mit Softwareentwicklung. Jemand, der für RISC OS programmiert und nicht BBC BASIC kennt, ist quasi undenkbar.

Regelmäßig auftauchende Fragen sind: Ich habe BBC BASIC nun gemeistert, wohin als nächstes? Ich will ein komplexes Stück Software entwickeln, BBC BASIC erscheint mir dafür nur begrenzt geeignet, was verwende ich stattdessen? Unglücklicherweise gibt es unter RISC OS mehr oder weniger nur eine Antwort: C. Mit Einschränkungen auch C++. Alternativen mit Exoten-Status sind Lua und Charm. Das war’s dann aber.

Nach meiner Erfahrung gibt es nur wenige, die den Sprung von BBC BASIC nach C vollziehen – zu unterschiedlich die Konzepte, die Syntax, dazu die Umstellung vom Interpreter zum Compiler. Man profitiert eben kaum von seiner gesammelten Erfahrung mit BBC BASIC.

Nun ist es leider so, dass der BBC BASIC-Interpreter noch stark in den 80ern verhaftet ist. Der leistungsfähigste unterstützte Datentyp ist das Array. Strings sind auf 255 Zeichen Länge limitiert (und single byte encoding natürlich). Records kann man nur quasi-händisch über Speicherblocks simulieren. Die Abstraktionsmöglichkeiten enden bei den Konstrukten Prozedur und Funktion. Die Verwendung von C-Bibliotheken ist faktisch nur möglich, wenn diese in ein Modul mit SWI-Interface überführt werden. Unnötig zu erwähnen, dass man keine RISC OS-Module in BASIC schreiben kann. Dazu die typischen Interpreter-Probleme wie suboptimale Performance und fehlender globaler Syntaxcheck – besonders lustig, wenn man im Error-Handler einen Syntaxfehler eingebaut hat.

Könnte man den BBC BASIC-Interpreter denn erweitern? Bisherige Erfahrungen zeigen: sehr schwierig, vor allem wenn man die Rückwärtskompatibilität erhalten will. Basalt von Steve Drain versucht sich an diversen Erweiterungen, m.E. aber mit syntaktisch schwer verdaulichem Ergebnis.

Ausgehend von diesen Überlegungen rege ich (nach dem großen Erfolg der Ideen “Ein kompetenter Browser” und “Qt portieren”) die Entwicklung eines BASIC-Compilers an. Das Potenzial der vielen kundigen BBC BASIC-Codern wird im Moment verschleudert durch die vielen Einschränkungen des Interpreters.

Wie könnte man dieses Projekt angehen? Am besten nicht nach der typischen RISC OS-Art, unter Vermeidung aller “not-invented-here”-Komponenten eine 100% hausgemachte Lösung zu brauen. Ziel muss es sein, eine dauerhafte Lösung zu bauen, die ohne größere Schmerzen es erlaubt, auch die nächsten paar ARM-Generationen zu überleben (man erinnere sich an die bisherigen Herausforderungen: StrongARM, 32bit, ARMv7). Also sollte man bestrebt sein, die Komplexität der eigentlichen ARM-Code-Erzeugung den Tools zu überlassen, die sowas schon seit langem beherrschen und aller Wahrscheinlichkeit nach das auch in Zukunft können werden.

Dazu gibt es prinzipiell zwei denkbare Wege: entweder, man übersetzt den BASIC-Code in C-Code und ruft dann einen C-Compiler auf, oder man implementiert ein neues Frontend für GCC. Für ersteres gibt es Beispiele für andere BASIC-Dialekte – BCX oder BaCon. Sogar in der RISC OS-Welt gibt es einen solchen Ansatz mit BBC_C32. Für letzteres gibt es meines Wissens keine frei verfügbaren Beispiele, aber jede Menge Dokumentation wie man derartige Frontends baut.

Was sollten die ersten Ziele sein? Die Unterstützung von etwas, was ich “well-formed BBC BASIC” nennen würde. Also für das, was vernünftige Menschen in BBC BASIC programmieren würden, nicht für Code, der aussieht, wie wenn er durch einen zu intelligenten BASIC-Cruncher gelaufen wäre. Sogar das Nachdenken über Unterstützung von EVAL sollte unter Strafe gestellt werden. Der ARM-Inline-Assembler ist IMHO zu Anfang ebenso verzichtbar. Über eine stringentere Fassung des Typsystems sollte man nachdenken. Unterstützung für beliebig lange Strings sollte automatisch abfallen. Konstanten sollten möglich sein. Also kurz: alles, was “programming in the small” ausmacht. Schleifen, Entscheidungen, Prozeduren, Funktionen.

Was stünde langfristig auf dem Plan? Unterstützung für Record-Strukturen, anständiges Speichermanagement (dynamische Allokation und auch Freigabe statt des statischen DIM-Zeugs), Unterstützung für weitergehende Abstraktion möglicherweise sogar objektorientierter Natur, sinnvolle Erweiterungen in punkto Sichtbarkeits- und Gültigkeitsregeln, Unterstützung für Modularisierung (Erweiterung des LIBRARY-Konzepts), Unterstützung zum Bau von RISC OS-Modulen, Integrationsmöglichkeit von C-Bibliotheken. Vielleicht sogar eigene Schlüsselwörter zur WIMP-Programmierung?

Also, die Vorarbeit ist geleistet, die Finalisierung überlasse ich wie immer gerne anderen. Für Syntaxvorschläge stehe ich gerne zur Verfügung.

Übrigens gab es über die Jahrzehnte durchaus bereits Versuche, BASIC-Compiler am Markt zu etablieren. ABC (“Archimedes BASIC Compiler”, bis heute Teil des RISC OS DDE), RiscBASIC, HelixBasic, WimpBasic. Die Ergebnisse waren wenig überzeugend – zu gering der Performance-Vorsprung, und der Versuch, BBC BASIC möglichst präzise zu emulieren, verurteilte die Versuche zum Scheitern. Mit Blick auf die Microsoft-Welt könnte man sagen: VisualBasic wurde nicht deshalb so erfolgreich, weil es möglichst weitgehend QBasic-kompatibel war.

WebKit-Portierung rückt näher

Aktuell ist mal wieder viel Bewegung im GCCSDK-Repository, Abteilung Autobuilder. Qt 5.4.1, Qt5Webkit, QtTestBrowser, Arora. Lee Noar committed wie der Wilde. Auch Chris Gransden, Meister der hundert Portierungen, mischt mit, wie man hier nachlesen kann.

Erfahrungsgemäß ist es ab hier noch ein gutes Stück Arbeit, bevor ein schnieker schneller stabiler Browser zur Verfügung steht. Aber der Anfang ist gemacht. Danke John, Lee, Chris, Alan, Theo und alle die sich rund um GCCSDK und das Tooling drumrum verdient gemacht haben.

RISC OS-Projekte: ein kompetenter Browser

In der Reihe “RISC OS-Projekte” soll es um Anregungen gehen für Menschen mit zu viel Freizeit. Es sollen Projekte beschrieben werden, die sowohl interessant sind, technisch anspruchsvoll und mit hohem Mehrwert für die RISC OS-Community. Den Anfang macht quasi eines der größten denkbaren Projekte überhaupt.

Die Geschichte der Browser für RISC OS ist lang. Es begann mit ArcWeb und Webster im Bereich Freeware. Dann kam die lange Reihe an Versuchen, Browser zu verkaufen: Fresco (immer nur erhältlich im Gesamtpaket der ANT Internet Suite), Webite (als Teil von Termite Internet), WebsterXL, Acorn Browse, Oregano, Oregano 2. Ein kurzes Zwischenspiel gab es mit einer Portierung von Firefox 2, die aber recht langsam und instabil war und nicht wirklich in RISC OS integriert war. Aktuell ist nur einer übrig geblieben: NetSurf, der unter der GPL steht und ständig weiterentwickelt wird.

Das Problem: das Internet entwickelt sich weiterhin rasant weiter. HTML5 und CSS3 sind aktuell die Standards, dazu tiefe JavaScript-Integration zur DOM-Manipulation. Die ständig zunehmende Verwendung von komplexem JavaScript erfordert außerdem ausgefeilte Optimierungsmechanismen bei der JavaScript-Interpretation. NetSurf hinkt schon heute dem Stand der Technik weit hinterher und hat bis heute keine anständige JavaScript-Unterstützung. Die Ziele der NetSurf-Entwickler sind sicher weitgehend passend für RISC OS-Zwecke (speicherplatzsparend, schnell, kompakt, gutes schlankes UI), aber was hilft das, wenn moderne Webseiten schlicht nicht zugänglich sind? Das sollte nicht als Kritik an NetSurf missverstanden werden – die Entwicklerkapazitäten sind dort begrenzt, und der Wettlauf gegen die Aktualisierung der Standards ist kaum zu gewinnen ohne ein großes Vollzeit-Entwicklerteam.

Im RISCOSOpen-Forum gibt es dazu einen Thread mit einer recht interessanten Diskussion dazu.

Unterm Strich bleibt meines Erachtens nur eine sinnvolle Option: die Portierung von Firefox/Gecko oder WebKit/Blinks. Nur damit ist garantiert, dass der Browser anständig kompatibel ist und bleibt mit den aktuellen Inhalten des Webs. WebKit scheint rein vom Portierungsaufwand her die bessere Wahl zu sein – es ist die deutlich jüngere Codebasis, wurde schon auf viele auch spärlich ausgestattete Plattformen portiert, und scheint generell besser modularisiert zu sein als Firefox bzw. Gecko.

Also, frisch ans Werk. Es braucht jemand, der sowohl unter RISC OS als auch unter Linux zuhause ist. Jemand, der die UI-Toolkits unter Linux kennt und natürlich WIMP-Experte ist. Jemand, der C und C++ im Schlaf beherrscht. Jemand, der die notwendige Entwicklungsinfrastruktur aufsetzen kann und dann natürlich auch betreibt. Und jemand, der reichlich Freizeit hat, um das Projekt voranzutreiben. Mit anderen Worten: einer allein wird das wohl kaum schaffen.

Grobe Vorgehensweise: einen ausreichend leistungsfähigen Linux-Server anmieten. Die heutzutage notwendige Infrastruktur aufsetzen (Gerrit/Git, Jenkins, GCCSDK). Das WebKit-Git-Repo clonen. Die WebKit-Portierung finden, die RISC OS technisch am nächsten ist. Code branchen und anfangen, den technischen Minimaldurchstich zu implementieren (hier gibt es Hinweise dazu). Nach und nach die Lücken füllen – vermutlich wird es sinnvoll sein, einige der Mainstream-Libs zu portieren wie Cairo und Freetype. Die notwendigen Anpassungen für die RISC OS-Portierung als Patches upstream zur Verfügung stellen. Eine anständige RISC OS-GUI drumrumstricken. Herausfinden, dass WebKit inzwischen von Blink abgelöst wurde. Gehe zurück auf Los. Froh sein, dass man die Basislibs schon portiert hat.

Ein ironisch-sarkastischer Beitrag zum Browser-Thema findet sich hier. “Because there are four of you” könnte zum geflügelten RISC OS-Ausspruch werden. Das Original von Peter Naulls ist auch immer noch von gewisser Aktualität und zeigt, wie alt das “Browser-Problem” schon ist.