Ein Haufen Software (im Quellcode!) von David Pilling

2015-08-05 20:10

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.

Neuigkeiten zum BeagleBoard-X15

2015-07-29 20:12

Es gibt Neuigkeiten zum BeagleBoard-X15 – und zwar zur Verfügbarkeit und zum Preis.

Auf der offiziellen Support-Seite kann man nun lesen, dass die “Unverbindliche Preisempfehlung” bei 199 US$ liegt. Der erste Probefertigungslauf mit zunächst 50 Exemplaren läuft im Moment, die Testboards sollen dann Ende August soweit sein. Für die große Masse soll das Board dann über Distributoren wie Digi-Key und Mouser ab November verfügbar sein. Den Preis in Euro kann man auf den Seiten schon begutachten: 194,82€ genau.

Wer meine früheren Artikel zum Thema nicht gelesen hat, das Wichtigste zum BeagleBoard-X15 in aller Kürze:

  • TI OMAP5 Sitara AM5728 1,5 GHz (Dual-Core Cortex-A15)
  • 2 GB DDR3-RAM
  • USB 3.0 Host
  • Gigabit Ethernet
  • eSATA
  • 4 GB Flash on board

Gegenüber der einzigen echten Konkurrenz (ISEE IGEPv5) dürfte vor allem der niedrige Preis interessant sein.

GAG-Treffen 2015

2015-07-22 00:08

Vergangenes Wochenende war mal wieder GAG-Treffen in Siek, und traditionell war ich wieder mit dabei. Inzwischen ist das GAG-Treffen beinahe die einzige Möglichkeit in Deutschland, Gleichgesinnte in Sachen RISC OS persönlich zu treffen – dies auch ein Hinweis auf die Jungs von der Arche e.V., mal wieder ein Treffen im Unperfekthaus zu organisieren. Und vielleicht sogar einen Hinweis an mich selbst, ein allerletztes Treffen im wilden Süden zu veranstalten?

Jedenfalls ist das GAG-Treffen für mich immer eine Chance, lange aufgeschobene Dinge in Angriff zu nehmen. Diesmal auf der Tagesordnung stand z.B. der Otter-Browser (eine Qt-WebKit-Portierung), den ich einer intensiven Prüfung unterzog. Performance ist hier das große Thema, denn für RISC OS-Verhältnisse ist die Software riesig – der Startup dauert ewig (Raspberry Pi 2 mit schneller SD-Karte: knapp 30s), was nicht zuletzt an der neuen Welt der Shared Libraries liegt – viele kleine Dateien dauern eben länger als eine große Datei. Hier kann der Einsatz der RAM-Disc Wunder bewirken, was wieder mal zeigt, dass das ganze File-IO-Thema unter RISC OS dringend einer grundlegenden Überarbeitung bedarf – anständiges Buffering und Cacheing wären ein guter Anfang. Etwas frustrierend war die Tatsache, dass wir den Otter nur auf dem RPi 2 zum Laufen bekommen haben, nicht jedoch auf PandaBoard und IGEPv5. Grund weiterhin unklar.

Prinzipiell halte ich den Otter-Browser für einen großen Schritt in die richtige Richtung, auch wenn die derzeitige Lösung noch stark holpert. Die Frage ist, ob man auf der Qt-Basis eine performante und anständig in RISC OS integrierte Lösung ans Laufen bringt, oder ob man das große Rad drehen und WebKit direkt an RISC OS anflanschen muss.

Genug von der Browser-Geschichte. Ein Highlight war die Kurzdemo der neuen Khronos-Library, die von Lee Noar entwickelt wurde und die praktisch ein Wrapper-Modul um Linux-Code ist, der diverse Hardware-Features des Raspberry Pi (alle Varianten) zur Verfügung stellt, darunter Video-Overlays und Open GL. Die verfügbaren Beispiele sind noch sehr rudimentär und durchaus absturzwillig (wobei dann das Overlay erhalten bleibt und nur ein Reset hilft), aber die Software ist noch jung, gerade mal seit etwa einer Woche in der mehr oder weniger freien Wildbahn.

Ich widmete mich auch noch intensiv einer anderen Front: Emulation. ADFFS, ArchiEmu und ArcEm standen auf dem Programm. ADFFS war ein kompletter Fehlschlag – ich konnte keines der angeblich auf dem Pi unterstützten Spiele zum Laufen bringen, und finde das Handling zum Starten der Spiele sehr unergonomisch. Ich werde mich dieser Tage mal ins JASPP-Forum begeben, um die Probleme aufzuarbeiten. ArchiEmu habe ich nur kurz angetestet, hier erntete ich nur direkte Abstürze. ArcEm war etwas vielversprechender, aber die Ergonomie ist stark suboptimal – so muss man z.B. zu verwendende Floppies und Harddiscs nach einer bestimmten Konvention benennen, um sie verwenden zu können. Und es ist mir nicht gelungen, den selbstextrahierenden SparkPlug unfallfrei auf die emulierte MFM-Platte zu bekommen. Immerhin hat der Boot sowohl nach RISC OS 2 als auch RISC OS 3.10 geklappt. Ich denke, darüber gibt es mal einen eigenen Blog-Artikel.

Den ARMX6 (i.MX6-Basis) gab es ebenfalls zu sehen. Sauschnell (vor allem in Sachen Platte – S-ATA statt USB zahlt sich aus), aber eben leider mit dem üblichen üblen R-Comp-Preisaufschlag. Und wie sich rausgestellt hat gibt es doch an der einen oder anderen Stelle noch Kompatibilitätsprobleme zu beheben, aktuell macht Photodesk Probleme.

Neues vom JASPP – ADFFS 2.50beta und neue Spiele

2015-07-02 13:44

Jon Abbott hat wieder zugeschlagen. ADFFS 2.50beta 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

2015-06-06 17:29

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.

Geschichten vom Dateisystem

2015-06-06 01:39

RISC OS macht bekanntlich vieles anders als andere Betriebssysteme. Besonders augenfällig ist das im Bereich Dateisysteme, was regelmäßig für Verwirrung sorgt. Dieser Artikel soll helfen, den Überblick zu bewahren.

Beteiligt am bunten Filesystem-Treiben unter RISC OS sind beispielsweise folgende Kandidaten:

  • Fileswitch
  • Filecore
  • SCSIFS, ADFS, SDFS, IDEFS…
  • CDFS, CDROMFS
  • DOSFS, Fat32FS, Win95FS
  • SparkFS, TBAFS, X-Files…
  • Sunfish, ImageNFS, NFSClient, LanManFS, LanMan98…
  • HostFS
  • PipeFS

Vorabinfo: Image-Filing-Systeme

Eine Besonderheit von RISC OS ist die Unterstützung von Image-Filing-Systemen. Darunter versteht man die Möglichkeit, eine einzelne Datei (oder auch ein ganzes Medium wie eine Festplatte, ein USB-Stick oder eine Diskette) als Verzeichnis zu behandeln. Bekannte Implementierungen sind z.B. DOSFS (Zugriff auf FAT-Medien) oder SparkFS (Zugriff auf Archive wie ARC, ZIP und ARJ). Für viele Operationen sind solche Images nicht von normalen Verzeichnissen zu unterscheiden – von der Kommandozeile aus z.B. kann problemlos in den Innereien einer ZIP-Datei herumgefuhrwerkt werden, wenn SparkFS aktiv ist. Alles funktioniert völlig transparent. Nur auf SWI-Ebene kann man herausfinden, ob ein Objekt ein “File” ist, ein “Directory” oder ein “Image” – wobei das “Image” auf dieser Ebene dann entweder als File oder als Directory bearbeitet werden kann.

Die Basis: Fileswitch

Basis aller Dateisystem-Dinge ist Fileswitch. Hier registrieren sich alle tatsächlichen Dateisysteme (egal ob “echte” oder “Image-Filing-Systeme” mit ihren “Entry points”). Hier sind die SWIs definiert, die in RISC OS die Schnittstelle zum Dateisystem bilden, von OS_Args über OS_File bis OS_GBPB.

Fileswitch definiert die “special characters” von RISC OS-Dateisystemen wie “$”, “:”, “&” und “%” und die Wildcards “*” und “%”, legt fest dass der Verzeichnistrenner “.” ist und beschäftigt sich mit den berühmten 8 Bytes, die entweder 5 Byte Datestamp + 12 Bit Filetype repräsentieren oder 4 Byte Load address + 4 Byte Exec address. Dazu gibt es noch ein volles Word Attribute.

Fileswitch ist ansonsten weitestgehend agnostisch gegenüber Implementierungsdetails. Zeichensatz? Physikalische Abbildung der logischen Verzeichnisstruktur auf dem Datenträger? Maximale Länge eines Dateinamens? All das bestimmt die Implementierung des Fileswitch-Clients. Die API ist leider nur 32bittig, d.h. die maximale Dateigröße ist auf 4 GiB begrenzt (lange Zeit (vor RISC OS 5.22) konnte Filecore sogar nur 2 GiB-Dateien verwalten). Wichtig zu wissen: Fileswitch ist inhärent case-insensitiv.

An dieser Stelle sollte aber beachtet werden, dass zwar Fileswitch gegenüber vielen Details agnostisch ist, aber leider nicht jede Software, die Fileswitch verwendet. Denn die meisten Entwickler testen ja mit real existierenden Dateisystemen, und oft nur mit einem – Filecore. Wenn sich dann andere Dateisysteme zwar API-konform, aber nicht gleich wie Filecore verhalten, führt das oft zu Verdruss. Beispiele in der Vergangenheit waren das Enumerationsverhalten von Verzeichnissinhalten bei Fat32FS, HostFS oder Sunfish.

Übrigens ist das Dateigrößenlimit von 4 GiB ein größeres Problem, als es zunächst scheint. Denn es limitiert nicht nur (logischerweise) die Größe einer Datei, sondern auch die Größe des Mediums, das ein Image-Filing-System verwalten kann. Deshalb ist DOSFS nicht in der Lage, mit FAT-formatierten USB-Sticks umzugehen und man benötigt Fat32FS, das als “echtes” Dateisystem implementiert ist und daher nicht an das 4 GiB-Limit der Image-Filing-Systeme gebunden ist.

Das native Dateisystem: Filecore

Filecore hat eine lange Historie bis zurück in die Zeit der 8-Bitter. Von Anbeginn der RISC OS-Zeit war das “Filecore E”-Format das native Dateisystem auf Disketten und Festplatten. Lange Zeit (bis RISC OS 4) ein Ärgernis, da limitiert auf maximal 10 Zeichen pro Dateiname und 77 Objekte in einem Verzeichnis. Aber ziemlich clever, was die Platzausnutzung des Mediums angeht (über “shared fragments” erreicht man eine feinere Granularität als die Blockgröße) und die Optimierung mit automatischer Defragmentierung.

Verschiedene RISC OS-Versionen haben unterschiedliche Limitierungen bezüglich Filecore. Alles bis einschließlich RISC OS 3.5 hatte eine maximale Partitionsgröße von 512 MiB (nicht zu verwechseln mit dem alten BIOS-PC-Limit von 504 MiB), alles bis einschließlich RISC OS 3.7x konnte nur 10 Zeichen pro Dateiname und 77 Objekte pro Verzeichnis.

Aktuelle Limits bei RISC OS 5 sind 256 GiB pro Partition bei einer Blockgröße von 512 Bytes. Theoretisch kann Filecore auch andere Blockgrößen (traditionell 1024 Bytes, inzwischen auch 2048 und 4096 Bytes), aber das wird meines Wissens derzeit von keinem Filecore-Client unterstützt.

Jede Filecore-Instanz kann maximal 8 Geräte verwalten, 4 Festplatten und 4 Wechselmedienlaufwerke. In der Theorie wurde das RISC OS 5-Filecore durch einen neuen Aufruf erweitert, um theoretisch bis zu 256 Geräte mit jeweils bis zu 16 EiB (also 16 Milliarden GiB) zu verwalten. Meines Wissens ist das aber nicht ausimplementiert. Insbesondere größere Medien wären schlecht zu handhaben, weil die Größe der Filecore-Map linear mit der Größe des Mediums wächst und vollständig im Hauptspeicher liegen muss.

Geht bei Filecore etwas schief, sind die Bordmittel um etwas zu retten sehr begrenzt. Der *CheckMap-Befehl kann zwar die Map auf Konsistenz prüfen, aber wenn sie inkonsistent ist, gibt es keine Lösungsmöglichkeit. *Verify prüft im Prinzip nur, ob die einzelnen Sektoren bzw. Blocks lesbar sind. Man muss kaputte Sektoren dann von Hand per *Defect als kaputt markieren.

Deshalb sollte jeder RISC OS-Benutzer auf jeden Fall DiscKnight von David J. Ruck in seiner Werkzeugkiste haben. Und zwar auf jedem Medium – besonders auf Netzwerkmedien, auf die man auch im Falle des Falles zugreifen kann, wenn die Platte oder der USB-Stick nicht mehr wollen. Schmale 10 UKP sollte das jedem wert sein.

Besondere Vorsicht ist auch beim Löschen geboten. Es gibt hier keinen (sicheren) Weg zurück, schon der nächste Schreibvorgang kann die soeben gelöschten Daten unwiederbringlich überschreiben. DiscKnight hat deshalb ein Feature, den freien Speicherplatz einer Filecore-Partition in eine Datei zu verwandeln, so kann man ggf. gelöschte Daten wiederherstellen.

Die Brücke zur Hardware: ADFS, SCSIFS, SDFS, IDEFS

Jeder RISC OS-Nutzer kennt ADFS. Ursprünglich (RISC OS 2, Archimedes, als Festplatten noch unsäglich teuer waren) als ADFS::0 der Zugang zum einzigen Diskettenlaufwerk, wird es später um ST506-basierte Festplatten (MFM) und noch später um IDE-basierte Festplatten erweitert. Eines blieb immer gleich: ADFS unterstützt nur eine Partition. Von Drittherstellern gibt es BDFS und EADFS mit Multi-Partition-Support.

ADFS ist, genau wie SCSIFS, SDFS und IDEFS, ein Filecore-Client. In anderen Worten: ADFS kümmert sich darum, Zugriffsroutinen bereitzustellen, um Blöcke von Geräten zu lesen und auf sie zu schreiben. Das logische Dateisystemformat steuert also Filecore, den Zugriff auf die physischen Geräte ADFS.

Selbiges gilt für SCSIFS, das aber nicht nur für die weitestgehend ausgestorbenen SCSI-Geräte zuständig ist, sondern auch für USB-Geräte vom Typ “Mass Storage” – dazu wird über SCSISoftUSB ein Low-Level-Treiber in den SCSIDriver integriert, der USB-Geräte als SCSI-Devices bereitstellt, damit SCSIFS darauf zugreifen kann.

SDFS und IDEFS schlagen in dieselbe Kerbe, nur eben für Zugriff auf SD-Karten und IDE-Geräte, wobei IDEFS von Drittherstellern von IDE-Podules bereitgestellt wurde und meistens mehrere Partitionen unterstützt.

Durch die Konstruktion “xxFS ist das Dateisystem das ein Filecore-Client ist, Filecore ist ein Fileswitch-Client, aber der eigentliche Hardware-Treiber sitzt wieder in xxFS” wurde der Filesystem-Stack von RISC OS oft als “upside-down”  charakterisiert.

Scheibenversteher: CDFS, CDROMFS

Mit CDFS und CDROMFS verlassen wir die Welt der Filecore-Clients und nehmen die ersten Dateisysteme, die direkt an Fileswitch andocken, unter die Lupe.

CDFS war anfangs eine “SCSI-only”-Veranstaltung und konzentrierte sich ganz auf das ISO9660-Format, dem Standard für Daten-CDs. Mitte der 90er, als CDROM-Laufwerke langsam gebräuchlich wurden, führte CDFS die Technik des “softloadable drivers” ein – man konnte nun Module bauen (typische Namen: CDFSSoftSCSI2, CDFSSoftATAPI), die die Verbindung zur Hardware übernahmen. Praktisch jeder Anbieter von SCSI- und IDE-Podules hatte seinen eigenen Treiber, dazu kamen generische Treiber von EESOX und IOC (später Pulse Computer) für SCSI sowie Power-tec und EESOX für ATAPI.

CDROMFS von Warm Silence Software (geschrieben von Ian Fry) ist ein Ersatz für CDFS. Und zwar nur für das CDFS-Modul, CDROMFS benutzt die Treiberinfrastruktur von CDFS einfach weiter. CDROMFS versteht mehr Varianten von ISO9660, versteht Joliet und Teile von RockRidge sowie ein Subset von UDF. Außerdem ist CDROMFS ein Image-Filing-System, kann also ISO-Images direkt öffnen – CDFS kann das nur in Verbindung mit CDFaker.

CDFS wurde inzwischen auch weiterentwickelt und versteht seit RISC OS Select und RISC OS 5.20 ebenfalls Joliet.

Ausblick

Im nächsten Teil geht es um die “FAT-Versteher” DOSFS, Fat32FS und Win95FS. Um ein paar interessante Image-Filing-Systeme wie DOSFS, Win95FS, SparkFS, TBAFS und X-Files. Um Netzwerk-Clients wie Sunfish, ImageNFS, NFSClient, LanManFS und LanMan98. Dazu ein kurzer Blick auf HostFS, dem Dateisystem der Emulatoren. Und eventuell PipeFS, das u.a. für den Zugriff auf USB genutzt werden kann.

Ein weiterer zukünftiger Artikel soll skizzieren, was im Bereich Dateisysteme in RISC OS geändert werden sollte. Bei RISC OS Open Ltd. gibt es ein offenes “Filesystem bounty”, das sich mit der Problematik der Partitionierung beschäftigt. Ein erster Schritt ist bereits getan. Die gesamte Roadmap ist hier und hier skizziert.

Nein, liebe c’t, RISC iX war nie im ROM

2015-05-24 01:04

Über merkwürdige Wege bin ich neulich auf einen Artikel über die ARM-Historie in der c’t gestoßen – schon sehr alt, von 2002 um es genauer zu sagen. Aber Fehler veralten ja nie, und so ist es mir ein Bedürfnis, der Welt mitzuteilen, dass die Idee, dass der R140 mit RISC iX im ROM ausgeliefert wurde, natürlich komplett absurd ist. RISC iX war schon immer nur auf der Platte, es wurde schon immer über RISC OS gestartet, welches das OS im ROM war.

Die Unschärfe beim Thema Lander und Zarch ist man inzwischen fast schon gewohnt, genauso wie kreative Schreibweisen wie RISC-PC oder RISC-OS. Und nein, es war nicht der “Cambridge Ring”, der von Acorn primär als Netzwerk bei den 6502-basierten Modellen verwendet wurde, sondern das gute alte Econet. Auch wenn es mal eine Broschüre von Acorn zum Cambridge Ring gab.

Bei dieser Gelegenheit habe ich auch den bisher einzigen Kommentar (von 2014) zum Artikel gelesen und mit einigen korrigierenden Hinweisen  versehen. Leute kommen ja auf Ideen…und die Amiga-Fraktion war bezüglich ihrer Brillen-Rosafärbung schon immer ganz vorne dabei.

RISC OS 5.22 im Schnelldurchlauf

2015-04-26 04:00

Rechtzeitig zur Wakefield Show wurde RISC OS 5.22 veröffentlicht. Bekanntlich folgt RISC OS 5 dem “ungerade-gerade”-Versionsnummernschema, wo die geraden Nummern die stabilen Releases repräsentieren und die ungeraden die Entwicklungsversionen.

Aus meiner Sicht relevante Verbesserungen:

  • Filecore kann jetzt nativ mit 2k- und 4k-Sektoren umgehen. Vor 20 Jahren wäre das obercool gewesen, weil man dann direkt PhaseChange- und MO-Laufwerke mit Filecore verwenden hätte können. Ist aber immer noch cool, weil es uns etwas Luft im Kampf mit den großen Festplatten verschafft – bisher gingen 256 GiB einigermaßen problemlos, mit 4k-Sektoren verschiebt sich das Limit damit auf 2 TiB
  • CDFS kann jetzt Joliet
  • LanManFS ist jetzt schneller (die Änderungen von Colin Granville, um die neueren Passwort-Varianten ab Windows Vista zu unterstützen, haben es leider nicht ins 5.22-Release geschafft)
  • wenn die Grafikhardware es kann, werden jetzt auch 4k- und 64k-Farben-Modi unterstützt
  • Verbesserung der DHCP-Unterstützung (Timeout, Hostname)
  • Sort-by-number im Filter (RISC OS Select/Adjust lässt grüßen)
  • Unterstützung für Alpha-Channel-Sprites, Drags werden jetzt mit Transparenz angezeigt
  • GraphicsV vorbereitet für zukünftige Erweiterungen (z.B. Multihead-Unterstützung)
  • EtherUSB-Verbesserungen von Colin Granville

Das stabile Release gibt es in den Geschmacksrichtungen IOMD (Risc PC, A7000(+), RPCEmu), Tungsten (IYONIX pc), OMAP3 (BeagleBoard(-xM), BIK, ARMini, Pandora, Touchbook, IGEPv2) und OMAP4 (PandaBoard (ES), ARMiniX, PandaRO).

ARMX6 und OMAP5 (IGEPv5) sind naturgemäß noch zu frisch, um schon im “normalen” Release-Zyklus mitzumischen.

Weitere Infos bei RISC OS Open Ltd.

WebKit-Portierung rückt näher

2015-04-26 03:11

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: Qt portieren

2015-04-06 22:37

Der zweite Teil der Reihe “RISC OS-Projekte” sollte ursprünglich von Oberflächenbibliotheken und deren Portierung handeln. Qt, GTK+, FLTK und wxWidgets sind da die interessantesten Kandidaten. Zur Portierung interessanter Software vornehmlich aus der Linux-Ecke wäre das eine wichtige Voraussetzung. Auch eine Portierung von WebKit wäre dadurch deutlich erleichtert.

Aus aktuellen Gründen will ich das Projekt etwas kleiner schneidern und nur eine Portierung von Qt kurz anreißen. Qt hat eine lange und bewegte Geschichte, die mit Trolltech begann und durch die Verwendung als Basis für den KDE-Desktop der breiten Masse bekannt wurde. Später wurde Trolltech von Nokia übernommen und Qt 2009 unter der LGPL veröffentlicht, nachdem jahrelang die Lizenzierungsfrage breitgetreten wurde. Qt ist in C++ geschrieben und gilt als einer der wenigen kompetenten Cross-Plattform-GUI-Toolkits. Qt zeichnet sich durch eine verhältnismäßig saubere API aus und wurde auf viele auch eher esoterische Systeme portiert, von Symbian bis Windows CE, von SailfishOS bis BlackBerry OS (QNX-basiert).

Qt ist inzwischen mehr als ein reines GUI-Toolkit, es gibt Module rund um Netzwerkzugriff (Qt Network) oder auch Datenbankanbindung (Qt Sql).

Viele Programmiersprachen wurden mit Anbindungen versehen, darunter z.B. Ada, Perl, Python und Haskell – auch hier also durchaus exotenfreundlich.

Und jetzt kommt der Gag: seit heute ist im GCCSDK-Repository im Autobuilder die Portierung von Qt 5.3.0 durch Lee Noar verfügbar.

Vielleicht hätte ich deshalb den Blogbeitragstitel in “Wunder geschehn” umbenennen sollen.

Ich hatte noch keine Gelegenheit, ein paar einfache Tests damit durchzuführen, um herauszufinden, welchen Stand die Portierung hat und welche der vielen Qt-Module bereits portiert sind. Vielleicht ist es also verfrühter Optimismus, denn Qt ist groß und es ist kaum anzunehmen, dass ein initialer Port direkt alle Module mitportiert. Die Inhalte im Autobuilder legen aber nahe, dass Qt Core und Qt Gui die ersten beiden Module sind.

Bisher in der Reihe “RISC OS-Projekte” veröffentlicht: