Heute ist zwar der erste April, aber es ist kein Scherz: soeben habe ich Version 2 eines Programms hochgeladen, dessen letzte Version zwanzig Jahre zurückliegt.

Das ursprüngliche VFD-Studio-Programm hatte ich 2004 in die Welt gesetzt, weil ich ein cooles VFD (Vacuum Fluorescent Display) hatte und es unbedingt an den PC anschließen wollte. Warum man so was wollen würde? Nun einfach, weil Anfang des Jahrtausends Case Modding ein cooler Trend war und der junge Herr Cypax da mit seinem coolen Display mitmischen wollte. Weil es aber damals kein passendes PC-Programm gab, um auf dem Display dann auch Inhalte anzuzeigen, hatte ich kurzerhand selbst eines geschrieben. - Was schließlich derart ausuferte, dass daraus eine Studienarbeit wurde. Und weil der nicht mehr so ganz junge Herr Cypax anno 2024 Case Modding und Displays immer noch cool findet, und wieder ein VFD ohne passende Software zur Hand war und weil solche Geschichten immer noch zum völligen Ausufern neigen, ist in den letzten Wochen VFD-Studio 2 entstanden:

• moderner, vielseitiger und viel umfangreicher,
• mit eigener GitHub-Seite,
• umfangreicher Dokumentation,
• mit Installer und Uninstaller,
• mit Live-Vorschau des Displayinhalts,
• fancy Editor mit Syntaxhighlighting und -kontrolle,
• fancy Arduino-Neben-Projekt,
• und natürlich mit einer Projektseite hier auf cypax.net

An PCs herumzuschrauben oder da mit Displays irgendwas zu machen ist inzwischen längst wieder out - insofern ist das also wieder mal ein richtiges Cypax-Projekt zu einem Randthema, welches vielleicht für drei Leute außer mir noch interessant ist. Indes, was für ein Spaß es mir gemacht hat! Ein schöner Mix aus GUI programmieren und hardware-nahem C++ (Arduino). Die Pascal-Skills konnte ich wieder auffrischen und nebenbei Lazarus3 sowie diverse Bibliotheken kennenlernen. Habe mal ein richtiges GitHub-Projekt aufgesetzt und mir Gedanken dazu gemacht, wie man so ein Projekt nachbaubar dokumentiert. Habe mich außerdem nach Jahren mal wieder mit dem NSIS-Installer beschäftigt, unzählige Programmierproblemchen gelöst, und, und, und ... 😊 Es war überdies auch das erste Programmierprojekt, bei dem ich gelegentlich ChatGPT konsultiert habe. - Mit ambivalenten Resultaten. So hatte der Chatbot einmal eine mir noch unbekannte aber sehr hilfreiche Bibliothek genannt, während er beispielsweise ein anderes mal ein Code-Snippet generierte, welches schon auf den ersten Blick völliger Unsinn war. Auf meinen Hinweis und Bitte um Korrektur folgte die übliche überschwängliche Entschuldigung und das gleiche Code-Beispiel erneut - mit nun anderen Variablennamen. 🤣 Es bleibt ein immer wieder unterhaltsames und spannendes Thema... Und wenn er irgendwann fertig ist, dann bekommt auch der Retro-Gaming-PC, für den das Display gedacht ist und für den VFD-Studio 2 überhaupt so eskaliert ist, natürlich dann auch noch seine Erwähnung hier im Blog. Hier schon mal ein klitzekleiner Ausblick:

Weil mir die gebräuchlich gewordene penetrante Kommerzialisierung selbst der banalsten Smartphone-Spielchen zuwider ist und ich nicht mag, dass der Nachwuchs beim Handydaddeln ständig Werbung und Tracking ausgesetzt ist, hatte ich mir überlegt, einfach mal ein Programm für Android-Smartphones selbst zu schreiben. Ein kleines Spielchen für zwischendurch. Statt immer nur für den PC oder für Mikrocontroller zu entwickeln. Kann ja nicht sooo schwer sein - Apps gibt es ja inzwischen wie Sand am Meer und völlig fremd ist mir die Handy-Welt ja auch nicht. Also mal schnell schlau machen, wie das heute so läuft - und erst mal entsetzt Resignieren: da hat sich technisch ja überhaupt nix zum Besseren entwickelt! Das ist auf modernen Smartphones im Kern immer noch der gleiche Java-Ranz von vor zwanzig Jahren. Nur jetzt halt mit hippen Namen und weiteren Bloat-Schichten drumherum. Gewachsene Strukturen wie ein verwahrloster Unkrautgarten. Bah. Da hätte ich eigentlich mehr erwartet. Da wundert es nun auch nicht, was das alles für ein Security-Totaldesaster ist. Nun ja, zum Glück will ich ja keine Banking-App machen, sondern bloß ein Spiel. Also rein in den Sumpf. Zuerst habe ich die harte Tour gewählt, dicke Bücher über Android und App-Entwicklung studiert, Android-Studio installiert und mich eine ganze Weile soweit damit beschäftigt, dass ich nun schöne Apps schreiben kann, die irgendwelche Daten entgegennehmen, verarbeiten, abspeichern, wieder laden, und so weiter und so fort. Für die persönliche Entwicklung als Programmierer ist das ja ganz nett und früher oder später werde ich sicher auch wieder davon Gebrauch machen, aber um ein Spiel zu erstellen war mir das alles zu zäh und zu aufgeblasen. Auf der Suche nach etwas Besserem fiel mir Clickteam Fusion ein, mit dessen Urgroßvater-Version "Klick&Play" von 1994 ich schon anno dazumal kleine Windows-Spiele erstellt hatte. Hach, die gute alte Zeit! 😍 Inzwischen ist das natürlich sehr viel weiter entwickelt und kann auch nach Android exportieren. Prima. Nehm' ich. Mit so einem Spiele-Baukasten geht das Ganze freilich viel leichter von der Hand und man kann sich auf das Wesentliche konzentrieren. Trotzdem kann man auch mit probaten Mitteln reichlich Zeit damit verbringen so ein "kleines Spielchen" zu erstellen. Zumal ich nur hin und wieder mal abends oder am Wochenende daran gearbeitet habe - man hat ja schließlich noch reichlich anderes zu tun. So hat sich das letztlich über die ganze Corona-Zeit hingezogen, bis ich nun heute sagen kann: ist fertig genug.

Das Resultat ist ein Android-Game namens Eierschleuder, bei dem man eine Schleuder spannt und Eier auf kleine gelbe Männchen katapultiert. Weil's Spaß gemacht hat und mir bei solchen Projekten dann schnell mal der eigene Anspruch durchgeht, ist es letzten Endes durchaus vorzeigbar geworden mit netter Grafik, dutzenden Levels in verschiedenen Welten, unterschiedlichen Wurf-Geschossen und haufenweise Special Effects 😂 Und natürlich alles als kostenlose App, ohne Werbung, Tracking oder sonstigen Schrott. In den Google-Playstore habe ich es allerdings nicht hochgeladen, weil ich dazu erst für 25,- € eine Entwicklerlizenz erwerben müsste und das ist es mir im Augenblick schlicht nicht wert. Wer also mag, kann Eierschleuder hier direkt auf's Android-Smartphone herunterladen (ca. 32 MB) und ausprobieren oder sich auf der Projektseite erst mal noch ein paar Screenshots ansehen. Viel Spaß!

Nehmt euch doch auch ein Glas Wein, heute philosophiert Herr Cypax mal ein bisschen vorm Kaminfeuer... Wir haben einen Pkw, der ist 11 Jahre alt. Eine Waschmaschine, die ist 15 Jahre alt. Meine Nähmaschine ist über 30. Und im Keller ist noch ein Bakelittelefon aus den 1950ern angeschlossen. All diese technischen Dinge sind immer noch in Betrieb, sehen nicht groß anders aus als ein Neugerät (ok, ja, das Telefon schon etwas) und funktionieren auch anno 2021 nicht grundsätzlich schlechter, als es ein Neugerät würde. Deutlich anders sieht das schon bei den Computern aus. Und extrem auffällig ist der Technikwandel bei Handys. Das ist mir letztens wieder so richtig gewahr geworden, als ich für den neuen Bombenwecker ein Nokia von 2007 wieder in Betrieb genommen habe, um dafür eine Anwendung zu programmieren. 2007 steckten Android und iOS noch in den Babywindeln und es war noch nix groß mit Smartphones, Apps und derlei. Die Handys hatten mickrige Grafikdisplays, wenig Speicher und "Apps" waren im Wesentlichen kleine Java-Programme, die in einer sehr rudimentären Laufzeitumgebung liefen. Und normalerweise findet man im Netz ja zu jedem beliebigen Thema Informationen in unbewältigbarem Überfluss - um aber herauszufinden, wie und womit ich genau dieses Handy programmiere, wo man noch eine Entwicklungsumgebung herbekommt, wo eine Laufzeitumgebung und so weiter, musste ich erstmal richtig ausgiebig graben. Und ja, gefunden habe ich dann letzten Endes schon noch irgendwie alles. Aber es stellte sich dabei auch dieser Eindruck ein, sich auf nahezu völlig ausgestorbenem Gebiet zu bewegen. Fast wie ein Archäologe. Klar, von all den Bibliotheken, Konzepten und Quelltexten aus dieser Zeit ist natürlich auch einiges in Neuentwicklungen eingeflossen und lebt damit bis heute in gewisser Form weiter. Auch heutige Android-Apps beispielsweise basieren letztlich alle auf Java. Und manche IT-Themen überleben sogar dauerhaft in kleinen ökologischen Nischen. So wie manche Bankenanwendung noch in Fortran geschrieben ist oder es immer noch Geldautomaten mit Windows XP gibt. Und folglich gibt es dazu auch noch entsprechende Nischen-Communities, wo auch heute noch zumindest geringe Aktivität besteht. Bei der Handy-Anwendung á la 2007 hingegen stellte sich so ein richtiges Friedhofsgefühl ein. Die Art, wie noch vor wenigen Jahren Handyprogramme entwickelt wurden, all die Forenbeiträge, Diskussionen, Tools und Tutorials sind mausetot und kommen auch nie wieder. Da kommt man schon mal ins Grübeln, was das für eine bizarr kurzlebige Branche ist.

Was meint ihr, gelingt es mir als Programmierer von BoeseFunktion() dass die Ausgabe in der zweiten Zeile Der Wert von Variable 'a' ist jetzt 0. lautet? Selbst wenn 'a' nur lokal der Main-Funktion bekannt ist? Ich sage ja: Das funktioniert eigentlich ganz einfach. Mit pointer = &tmp - 1; hole mich mir einen Zeiger auf den ersten Funktionsparameter und reduziere die Adresse um 1. Auf x86-Systemen bin ich nun an der Rücksprungadresse von BoeseFunktion() auf dem Stack. So sieht das im Speicher aus: Und mit *pointer = *pointer + 8; erhöhe ich anschließend die Rücksprungadresse um 8 Byte, was gerade soviel ist um das a = 1; in main() zu überspringen. Solches Gehacke mit Pointer-Arithmetik ist natürlich sowieso pfui. Aber was uns dieses Beispiel eigentlich lehren soll ist, dass man fremden Funktionen nicht trauen soll. Es könnte schließlich sein, dass ich sie geschrieben habe... 😉

Schadensabwehr

Aber wie bekommt man nun das Problem in den Griff, dass Fremdcode, den man in so gut wie jedem Projekt findet, unbeabsichtigt oder beabsichtigt Unfug anstellt und Daten oder die Programmausführung beeinträchtigt? Da gibt es mehrere Möglichkeiten. Unter anderem:

• Logische Programmablaufkontrolle Man stelle sich vor, jede eigene Funktion meldet sich bei ihrem Aufruf an einer zentralen Instanz mit einem eindeutigen Key. Die zentrale Instanz überprüft dann anhand einer Tabelle ob es in Ordnung ist, dass Funktion3 nun auf Funktion2 folgt oder nicht. Bringt fremder Code - zum Beispiel eine defekte DLL - den Ablauf durcheinander so wird dies schnell aufgedeckt. Voraussetzung für ein solches System ist natürlich eine deterministische Reihenfolge der Funktionsaufrufe.
• Datenredundanz Zuerst einmal sollten alle Daten, die irgendwie wichtig sind, redundant vorliegen; am besten redundant-invers. Das heißt, es gibt nicht eine Variable 'a', sondern z.B. 'unsigned char u8VentilSollwert' und 'unsigned char u8VentilSollwertInvers'. Das hat nicht nur einen eingängigeren Namen als 'a' sondern informiert uns auch gleich noch über das Präfix u8, dass es eine unsigned 8-Bit-Variable ist mit Wertebereich von 0..255. In der einen steht dann z.B. 1 (binär 0000 0001) und in der anderen das Gegenteil, also 254 (1111 1110). Vor Verwendung wird jedes Mal geprüft, ob die beiden Variablen noch Bit-invers sind und falls nicht mit Fehlermeldung abgebrochen.
• Datensicherung Wenn die Daten umfangreicher sind, gibt es die Möglichkeit sie mit einer Checksumme zu sichern. Wird die Checksumme oder die Daten beschädigt, so fällt dies auf, sobald man die Checksumme nachrechnet und mit dem Prüfwert vergleicht.