Bits frickeln mit Java

Gerade bin ich dabei – zum besseren Kennenlernen von Filecore-basierten Dateisystemen (man muss den Feind kennen) – in Java ein kleines Tool zu entwickeln, das Disc-Images im Filecore-Format versteht und Dateien und Verzeichnisse daraus extrahieren kann. Nur lesend, um weitere Komplexitäten erst mal zu vermeiden.

Etwas Hintergrund: Filecore ist das native Dateisystem unter RISC OS. Oft wird es auch als „ADFS“ bezeichnet, weil das „Advanced Disc Filing System“ quasi die erste Implementierung von Filecore war (damals, Floppy-Zeit, zur Archimedes-Ära 800 KiB auf einer 3,5″-DD-Diskette), bevor es abstrahiert und generalisiert als Basis für Disketten- und Festplattenformate in RISC OS Einzug hielt. Es gab über die Jahre reichlich Varianten, um die diversen Einschränkungen und Limits in den besser nutzbaren Bereich zu schieben – das E-Format ist das Übliche für DD-Disketten (800 KiB) und man findet es heute in den Weiten des Internets als .adf-Disc-Images der klassischen Archimedes-Software. Später kam das F-Format für die HD-Floppies (1600 KiB). Schließlich wurde mit RISC OS 4 das E+/F+-Format eingeführt („Big Map“), um die lächerlich niedrige Grenze solcher Dinge wie „maximale Anzahl von Einträgen in einem Verzeichnis“ auf ein halbwegs erträgliches Niveau zu heben.

Wie auch immer – beim Hantieren mit Emulatoren und natürlich dem MIST(er) hat man häufig mit diesen .adf- (Floppy-Images) und .hdf- (Harddisc-Images) Dateien zu tun. Oftmals will man „nur kurz“ einen Blick reinwerfen und dazu nicht gleich den Emulator hochfahren. Zumal die Emulatoren auch nicht alle so richtig nutzerfreundlich sind was das „Mounten“ des Images angeht.

Also: ein Tool muss her. Systemunabhängig und natürlich mit anständigem UI. Also Java. Das Problem: Filecore wurde von echten Bitfuchsern entwickelt. Da wimmelt es nur so von Bitleisten, unsigned values mit allem zwischen 8 und 64 bit und sonstigem, was unter Java nicht so richtig „nativ“ unterstützt wird. Übrigens gibt es Spezialisten, die es auch noch gut finden, dass Java keine „unsigned types“ hat – für mich ist dieser Artikel ein Beispiel dafür, wie eine limitierte Erfahrung auf nur wenige Programmiersprachen den Blick aufs wesentliche vernebeln kann, denn die allermeisten der genannten Probleme sind nur inhärent im Java- und C-Typsystem, aber in vernünftigen Sprachen wie Ada elegant gelöst. Dumm, dass die Java-Erfinder vermutlich einen genauso eingeschränkten Blickwinkel hatten – C, C++, Smalltalk, Ende der Geschichte. Aber ich schweife ab.

Jedenfalls habe ich nach Bibliotheken gesucht, die unter Java die Bitfrickelei und unsigned types im Handling etwas angenehmer machen. Leider bin ich bis auf Lukas Eders jOOU-Bibliothek auf nix gescheites gestoßen. Klar, im Apache-Commons-Universum gibt es ein paar Dinge, in Guava ebenso, und sogar Oracle hat das Licht gesehen und ein paar nützliche Dinge in Java 8 nachgerüstet. Also: selbst ist der Mann. „Not invented here“ ist schließlich eine der grundsätzlichen Triebfedern der IT.

Es sei denn, jemand hat einen Hinweis auf eine vernünftige, umfassende Bibliothek um meine Bedürfnisse zu erfüllen. Unter ebenso vernünftiger Open-Source-Lizenz natürlich. UAwg! Nebenbei: die eigentliche Implementierung ist nun nicht das große Problem, das Finden geeigneter Doku und fehlerarme Interpretation derselben nebst Erkennen gewünschter und unerwünschter Abweichungen davon in der Praxis hingegen schon. Hat man das Problem erst mal in einer Sprache geknackt, sollte eine Portierung in andere Sprachen kein großes Problem sein. Es wäre eine interessante Fallstudie, den Ada-Code neben dem Java-Code zu sehen.

Und falls jemand ein anständiges (nicht jedoch komplexes!) Dateisystem kennt mit einer simplen Implementierung in einer freien Lizenz – mail me. Filecore hat einen Nachfolger schon seit etwa 30 Jahren verdient.

Die Windows 10-Netzwerk-Misere

Man sollte ja immer offen sein für Neues. Und so hatte ich es Ende letzten Jahres gewagt, einen Windows 7-Rechner des Haushalts auf Windows 10 umzustellen (ich vermeide hier mal das eher positiv belegte Wort „Upgrade“). Das Upgrade dauerte ewig, aber am Ende schien alles in Ordnung. System lief prima, ob besser oder schlechter als mit Windows 7 wage ich nicht zu beurteilen. Aber viele Dinge sahen schon schicker aus, und Nachteile waren auf den ersten Blick nicht zu erkennen. Alle Treiber hatten das Upgrade auch überlebt, also alles im grünen Bereich.

Dann, vor wenigen Tagen, passierte es. Keine Internet-Verbindung mehr. Wie sich nach kurzer Analyse herausstellte: überhaupt keine Netzwerkverbindung mehr. Weder WLAN noch LAN ging – das System schaffte nicht mal den DHCP-Request, ein kurzes Umkonfigurieren auf eine statische IP half auch nicht.

Erster Versuch: Problem mit Hardware erschlagen. WLAN-Repeater mit LAN-Anschluss. Verschiedene WLAN-USB-Sticks (mit verschiedenen Chipsätzen, so dass neue Treiber installiert wurden). Der Versuch, mit einem LTE-Router eine Verbindung ins Internet zu bekommen. Nix ging. Kurz gegoogelt. Aber welche Problemlösungen bekommt man mit einem derart generischen Problem? Router resetten, Treiber und Firmware aktualisieren, BIOS-Update, und natürlich das klassische „Windows neu installieren“.

Was tun? Mal die Windows-eigene Netzwerk-Analyse laufen lassen. Und tatsächlich gab es ein Analyse-Ergebnis: „Es fehlen die für die Netzwerkkonnektivität erforderlichen Windows Sockets-Registrierungseinträge“. Unnötig zu erwähnen, dass die angebotene automatische Lösung gar nichts geändert hat. Aber: endlich hatte ich einen Text, den man in Google füttern kann. Wenige Sekunden später war klar: immerhin bin ich nicht allein. Das Windows-Update KB3120677 war schuld. Mögliche Lösungen beinhalteten z.B. das Löschen aller Netzwerkgeräte (inklusive der ausgeblendeten) im Geräte-Manager, gefolgt von einem Neustart, gefolgt von „netsh winsock reset“, gefolgt von einem Neustart. Half leider auch nicht. Es war auch nicht möglich, das fragliche Update einzeln zu deinstallieren. Also: Systemwiederherstellung auf den Zustand vor diesem Update. Danach die Geräte-Manager-Prozedur, und endlich war wieder Netzwerk im Haus.

Auch andere Windows-Versionen hatten in der Vergangenheit ja so ihre Probleme mit einzelnen Updates. Komischerweise wurde ich bisher von derartigem Unbill verschont. War wohl Pech diesmal. Persönliches Pech macht aus Windows 10 nun kein schlechtes Betriebssystem. Aber das ungute Gefühl bei jedem zukünftigen Update wird bleiben.

„Danke“ an meine Freunde in Redmond für die vielen Stunden verschwendete Lebenszeit. Echter Dank gebührt den fleißigen Bloggern, die diverse Lösungsansätze publiziert haben, besonders Günter Born.

Was ist eigentlich dieses RISC OS

Auf meinem Nachbarblog hubersn.RISCOS geht es um dieses exotische Randgruppenbetriebssystem namens „RISC OS“, das eigentlich nur in britischen Landen und mit Abstrichen in einigen Ländern des Commonwealth eine gewisse Bedeutung erlangt hat. Wobei „gewisse Bedeutung“ schon recht hoch gegriffen ist.

Nichtsdestotrotz hat RISC OS eine interessante Geschichte und wird auch heute noch von einigen wenigen Nutzern eingesetzt und von noch weniger Entwicklern vorangetrieben. Irgendwas muss also dran sein an diesem Betriebssystem. Was das ist, soll im Folgenden genauer beleuchtet werden. Ich bin hier quasi die dreifache Randgruppe – RISC OS-Nutzer, RISC OS-Entwickler, Nichtbrite.

Es war Mitte der 80er, als die Firma Acorn – auf der Insel wohlbekannt für ihre 8Bit-Rechner wie den BBC Model B oder den Electron, die hauptsächlich im Bildungswesen ihr Unwesen trieben – sich mit der nächsten Generation Computer beschäftigte und dafür einen 32bit-RISC-Prozessor entwickelte, der folgerichtig ARM (Acorn RISC Machine) genannt wurde. Man war knapp bei Kasse, Software hatte noch nie die höchste Priorität, und so schusterte man mehr schlecht als recht ein Betriebssystem mit dem Namen Arthur (angeblich steht das für „A Risc operating system by THURsday, was auf ziemlichen Zeitdruck bei der Entwicklung schließen lässt) zusammen, im Prinzip eine 32bit-Version des alten 8bit-MOS des BBC Model B. Da die Entwicklung des eigentlich vorgesehenen Betriebssystems ARX nicht in die Gänge kam (über den Grad der Fertigstellung ranken sich verschiedenste Gerüchte), entschied man sich für eine stark aufgebohrte Version von Arthur, die man RISC OS 2 taufte. Für die damalige Zeit – man schrieb das Jahr 1988 – gar kein schlechter Wurf. Vernünftige grafische Oberfläche, konsequente Mausbedienung, multitaskingfähig, das freut den Benutzer.

Acorn war Zeit seiner Existenz nicht besonders vom Erfolg seiner Computer verwöhnt, aber ARM (1990 ausgegründet und umbenannt in „Advanced RISC Machine“) war der große Wurf. Die von Acorn gehaltenen Anteile an ARM waren 1997 der Grund für die Zerschlagung von Acorn, aber der Erfolg von ARM ist letztlich der Grund dafür, dass RISC OS in den letzten Jahren wieder so etwas wie einen zweiten Frühling erlebt – eine besondere Ironie der Geschichte.

Zurück zu RISC OS. Ein Meilenstein war RISC OS 3, das 1992 in der Version 3.1 die neue „Baseline“ für Archimedes & Nachfolger (A5000, A30x0, A4000, A4) darstellte. Immer noch schnell, schlank, elegant – aber deutlich abgerundet gegenüber seinem Vorgänger. 1994 leicht aufgehübscht als Version 3.5 für den Risc PC veröffentlicht, war der nächste (und gleichzeitig letzte unter Acorn-Ägide) Meilenstein die Version 3.7, die an den StrongARM angepasst war.

Version 4 war eigentlich für die nächste Acorn-Hardware-Generation vorgesehen, „Phoebe“ hätte der Rechner heißen sollen. Dazu kam es „dank“ der Zerschlagung von Acorn nicht, stattdessen übernahm RISCOS Ltd. (kurz „ROL“ genannt) den Staffelstab und brachte 1999 RISC OS 4 auf den Markt. In den Folgejahren kam es zum „RISC OS Split“ – ROL entwickelte weiter für die vorhandene (Risc PC, A7000(+)) sowie erhoffte neue Hardware (RiscStation, MicroDigital, Millipede, STD) und später vor allem für Emulatoren (VirtualAcorn) den RISC OS 4-Strang in Form von „RISC OS Select“ und „RISC OS Adjust“, Castle Technology hingegen verwendete den RISC OS-Strang von Pace Technologies (die hatten sich die Reste von Acorn einverleibt, die kein anderer haben wollte) für den IYONIX pc und nannte ihn RISC OS 5. So kam es zur für Außenstehende verwirrenden Situation, dass „RISC OS 4“ teilweise mehr oder andere Features hatte wie „RISC OS 5“. Vollends chaotisch wurde es dann durch „RISC OS SIX“, einer Weiterentwicklung von ROL aus RISC OS 4.39 (genannt „Adjust“). 2006 machte dann wiederum der „RISC OS 5“-Zweig von sich reden, welcher über RISC OS Open Ltd. (kurz ROOL genannt) nach und nach als Open Source (manche bestehen auch auf der Bezeichnung „Shared Source“, um die non-OSI-ness der Lizenz zu betonen) der Community bereitgestellt wurde. Daraus speist sich auch der neue Schwung in Sachen RISC OS, der dem RISC OS 5-Zweig auf allerlei ARM-Hardware wie BeagleBoard, BeagleBoard-xM, PandaBoard und Raspberry Pi Präsenz verschafft.

Soviel zur historischen Vorrede. Was außer historischem Interesse mag es heute noch für Gründe geben, sich mit RISC OS zu beschäftigen?

RISC OS ist, was viele Konzepte angeht, so etwas wie das „Anti-Linux“. RISC OS steht unter einer GPL-inkompatiblem Shared-Source-Lizenz. RISC OS ist sehr mausbedienzentriert. RISC OS zeigt, wie Datei-Drag&Drop wirklich funktionieren sollte. RISC OS hatte von Anfang an einen strengen Style Guide, so dass die Anwendungen sich alle sehr ähnlich bedienen. RISC OS hatte von Anfang an genau einen Desktop. RISC OS ist ein Single-User-Betriebssystem, das nur eine schwache Idee eines „Prozesses“ und eines „Task-Schedulers“ hat. RISC OS-Anwendungen müssen sich kooperativ verhalten, damit das Multitasking funktioniert. RISC OS hat keinen virtuellen Speicher. RISC OS hat keinen Datencache für Dateisysteme. RISC OS lässt dem Benutzer fast alle Freiheiten, wie er sein Dateisystem organisiert. Die RISC OS-Kommandozeile ist extrem leistungsschwach. Der RISC OS-Desktop erlaubt einen überaus eleganten, dateisystemzentrierten Umgang mit Anwendungen und ihren Daten. RISC OS hat bis heute einen semi-kommerziellen Softwaremarkt, wo kleine Anwendungen für kleine Beträge (und wenige große Anwendungen für relativ große Beträge) verkauft werden. RISC OS wird mit dem proprietären DDE assembliert und compiliert. RISC OS besteht hauptsächlich aus Assembler und nur ein wenig C. Es gibt genau eine „RISC OS-Distribution“, und zwar die von ROOL. RISC OS ist klein, kompakt und schnell. Während der Raspberry Pi für Linux lahmarschige Hardware mit knappen Speicher ist, ist es für RISC OS eine superperformante Plattform mit unendlichen Speicherweiten. RISC OS ist verhältnismäßig einfach gestrickt – vermutlich ist es das einzige wirklich nützliche Betriebssystem, das noch von einer einzigen Person in Gänze verstanden werden kann.

Als erfahrener RISC OS-Benutzer geht man niemals davon aus, dass ein Gerät unter RISC OS „einfach so“ funktioniert – die Lücken in der Hardwareunterstützung sind riesig. Erst kürzlich lernte der RISC OS-USB-Stack, den isochronen Übertragungsmodus zu unterstützen – die meisten Computerbenutzer haben davon vermutlich noch nie etwas gehört, da die Mainstream-Betriebssysteme diesen selbstverständlich unterstützen. RISC OS-Benutzer hingegen haben erst seit kurzer Zeit das Vergnügen, USB-Audio-Geräte verwenden zu können. Anderes Beispiel: bis heute gibt es keine Unterstützung für WLAN-Sticks, RISC OS-Nutzer behelfen sich mit LAN-WLAN-Bridges. Dafür gibt es wiederum ganz anständige Unterstützung für UMTS-Sticks. In Verbindung mit dem Motorola Lapdock ergibt RISC OS so eine ganz passable portable Plattform – zum ersten Mal seit 1992, als der A4 veröffentlicht wurde.

Manchmal muss man unter RISC OS für Dinge bezahlen, die es anderswo wie selbstverständlich kostenlos gibt. Anständige Textverarbeitung zum Beispiel. Da muss man schon ein paar Euro bei meinem Freund Martin Würthner hinterlegen, um EasiWriter oder TechWriter zu kaufen, während auf anderen Systemen OpenOffice und LibreOffice zur Verfügung stehen. Oder Druckertreiber mit Qualitätsanspruch – auch hier ist Martin Würthner mit Gutenprint und dem PostScript3-Treiber erster Ansprechpartner. Will man Email und News lesen und schreiben, empfiehlt sich Messenger Pro von R-Comp (nicht erschrecken beim Besuch dieser Website – es hat keine Zeitreise stattgefunden!). Für Pixelbildbearbeiter ist Photodesk von CJE erste Wahl. Und obwohl eine recht moderne GCC-Version zur Verfügung steht, ist der Kauf des DDE dennoch empfehlenswert – und sei es nur als Unterstützung für die Arbeit von ROOL. Die gute Nachricht: einen Gutteil der genannten Software kann man als Raspberry Pi-Nutzer im NutPi-Bundle für kleines Geld erwerben.

Dass RISC OS das Anti-Linux ist, hat leider teilweise ungünstige Auswirkungen. So ist die Portierung von Anwendungen aus der Linux-Welt – vor allem bei denen mit grafischer Oberfläche – eher schwierig. So gibt es z.B. nur eine Uralt-Portierung von Firefox, keine von Thunderbird und OpenOffice/LibreOffice, es gibt kein Java, kein GIMP, keinen Emacs. Audio/Video-Codec-Unterstützung ist Glücksache. Die Unterstützung für Dateisysteme jenseits von FAT ist nicht vorhanden.

Das Geheimnis des zufriedenen RISC OS-Benutzers ist, dass er RISC OS nur für das benutzt, wo es gescheite Software gibt. Und dann ist die Benutzung ein Traum. Illustrationen mit ArtWorks, Textverarbeitung mit TechWriter, DTP mit OvationPro, Emails und News mit Messenger Pro. Dazu kleine feine Tools wie SparkFS, PrintPDF, StrongEd, Zap, DigitalCD und Sunfish. Zum Surfen tut es auch ein Windows-Rechner, den man per UniPrint und UniScan prima zum Treiber-Knecht degradieren kann. Und der bei Softwarenot per RDP komfortabel auf dem RISC OS-Rechner zur Verfügung steht.

Wer nun Lust bekommen hat, RISC OS mal auszuprobieren, hat zwei relativ einfache Möglichkeiten: wenn man schon einen Raspberry Pi hat, einfach NOOBS verwenden und RISC OS auswählen. Wenn man einen gewöhnlichen PC hat, RPCEmu als RISC OS-Emulationsplattform verwenden – wenn was komisch ist, liegt es dann am PC und dem Emulator und niemals an RISC OS. Man kann „ready-to-run“-USB-Sticks mit RPCEmu für Windows und Mac bei RISC OS Open Ltd. kaufen, aber der wahre Fan baut natürlich selbst.