GoTo RetroCode BLOG

Pinebook Pro Akku manuell laden

2025-04-27T13:00:00+02:00

Ich besitze zu viel Hardware, und auch zu viele Laptops. Folglich liegt ein Gerät auch gerne mal ein Jahr unbenutzt im Kasten.

Und als ich vorhin mein PineBook von Pine64 wieder in Betrieb nehmen wollte blieb der Bildschirm einfach schwarz.

Dass der Akku von unbenutzten Laptops auch entlädt ist bekannt. Man schließt das Ladegerät an, wartet etwas und startet die Maschine ganz normal.

Doch das funktionierte diesmal nicht.
Mir fiel die blinkende Lade-LED auf und so fand ich im Netz heraus, dass ein Blinken im Sekundentakt auf einen “Hardwareschaden” hinweist.
Kurz gesagt: Der Akku lädt nicht … und hochfahren lät sich das System so auch nicht.
Weder das Herstellernetzteil noch der alternative USB-C-Port funktionierte.

Tiefentladung vermutet

Nach ein paar Tränen, schraubte ich den Laptop auf und koppelte den Akku ab. Mein Multimeter zeigte 2.7 Volt zwischen den roten und schwarzen Adern an, was auf einen zu tiefen Ladestand hinwies, der aber noch nicht tödlich sein musste.

Darauf hin schaltete ich mein Labornetzteil auf 4 Volt, und leitete für einige Minuten wieder etwas Strom in den Akku zurück. Eine erneute Messung zeigte dann wieder 3.4 Volt an. Somit schloss ich den Akku wieder an und versuchte eine reguläre Aufladung.

Das Herstellernetzteil ließ leider wieder die LED im Fehlermodus blinken, doch eine Aufladung per USB-C klappte plötzlich. Die Lade-LED leuchtete durchgehend und schon konnte ich das System starten.

Ladevorgang

Nach dem Boot von Armbian checkte ich den Status per Linux sysfs.
cat /sys/class/power_supply/cw2015-battery/capacity zeigt die Ladekapazität in Prozent und dieser Wert stieg alle paar Minuten. … das Aufladen funktionierte also wieder.

/sys/class/power_supply/cw2015-battery/voltage_now zeigt auch die aktuelle Akkuspannung an und auch dieser Wert stieg im Minutentakt an.

Interessant ist der Wert in /sys/class/power_supply/cw2015-battery/voltage_min_design, denn dieser liegt fest bei 3000000 uV, also genau 3 Volt.
Es macht also Sinn, dass auch die verbaute Hardware einen Akku unter 3V nicht mehr akzeptiert.

Fazit

Mit der Entladung habe ich den Akku sicher geschädigt und seine Kapazität wie auch Lebensdauer reduziert.
Doch durch die Wiederbelebung mit ein bisschen Extrastrom kann mein PineBook wieder booten und ich kann wieder ein bisschen experimentieren.

Ein neuer Nachbau Akku kommt auf 30 Euro, ist also leistbar. Doch … wie gesagt, ich besitze zu viele Laptops … es zahlt sich nicht wirklich aus jedes Jahr einen neuen Akku zu kaufen, denn dafür nutze ich die Maschine leider nicht oft genug.

Zumindest werde ich jetzt häufiger mal das Ladekabel anschließen um weitere Tiefentladungen zu vermeiden.

CMAKE v4.0 Update

2025-04-20T13:00:00+02:00

Frisch aus der Build-Fabrik wird weiter CMake Version 4.0 ins Netz verteilt.

Nun stellt sich die Frage:

Wird mein Code weiter damit gebaut werden können?

Antwort:

aber nicht immer.

Ich habe nicht so ganz verstanden, warum nach 3.31 Version 4.0 folgte. Denn ich sehe keine wirklich “großen” Features. Es fühlt sich - wie schon oft gesagt - eher an wie ein Sprung von 3.31 auf 3.40.

Eine wichtige Änderung gibt es aber: Die Mindest-Version in CMake Scripts muss jetzt größer gleich 3.10 sein.

Ich hatte schon beim Wechsel von 3.26 auf 3.27 feststellen müssen, dass ein CMake-Minimum-Requirement jetzt 3.5 ist und ältere Angaben einfach nicht mehr gebaut werden können.
Mit der Erhöhung auf 3.10 ist nun auch ein Update meine GATE Quellcodes notwendig, um dynamisch auf den Versionszwang reagieren zu können.

Problem: Alte Plattformen

Ich brauch in Wahrheit nur selten Features, die über v3.1 liegen. Für Builds auf Windows 2000 ist v3.4 die jüngste Version, die auf diesem System noch ausführbar ist.
Folglich hatte ich ursprünglich:

1cmake_minimum_required(VERSION 3.4)

in meiner CMakeLists.txt.

Nach der Veröffentlichung von 3.27, hatte ich das auf 3.5 erhöht, um zumindest auf “allen” Folgesystemen baubar zu sein.
Die alten Debian Varianten wie Debian-9 kamen schließlich mit CMake v3.7 heraus, womit mein Build direkt auf solchen Plattformen lauffähig ist.

Mit der erneuten Erhöhung beschloss ich das ganze “flexibel” zu gestalten:

1if(CMAKE_VERSION VERSION_GREATER "3.14.99")
2  cmake_minimum_required(VERSION 3.15)
3elseif(CMAKE_VERSION VERSION_GREATER "3.4.99")
4  cmake_minimum_required(VERSION 3.5)
5else()
6  cmake_minimum_required(VERSION 3.1)
7endif()

Tja, CMake-Macher … ihr dachtet wohl, ihr erkönnt mich zum Upgrade zwingen.
Falsch gedacht! Denn ich weiß mit IF umzugehen.

Fazit

Ja, CMake Erweiterungen sind gut … aber dieser v4 Sprung kommt mir doch etwas seltsam vor.

Dass die älteren Minimum-Requirements mal erhöht werden, war mir klar. Dass das aber so schnell passieren würde, überraschte mich doch etwas.

Wie auch immer … die flexible Lösung passt sich jetzt an die installierte CMake Version an und somit kann ich weiter die alte mit der neuen Welt “verbinden”.

C64 Keyboard Upgrade

2025-04-13T13:00:00+02:00

Die alte leider nicht mehr so ganz gut funktionierende Tastatur meines Commodore 64 Models hindert mich noch irgend etwas mit dem Gerät anstellen zu können.

Frage:

Kann man das C64 Keyboard ersetzen?

Antwort:

Ja. Kaufen oder selber machen.

Tatsächlich hat sich ein Tüftler das MechBoard64 einfallen lassen. Dabei handelt es sich um eine Platinenblaupause, die moderne mechanische Tasten im Layout des C64 einfügen lässt, die mit dem Board-Anschluss des C64 kompatibel ist.

Kurz gesagt:

Man lässt sich eine Mechboard-Platine anfertigen
Man kauft mechanische Tastatur-Schalter (Key-Switches), die auf die Platine gelötet werden.
Man kauft Tastenkappen (Key-Caps), die auf die Schalter gesetzt werden.
Man schraubt die Platine auf die Halterung, die im C64 eingesetzt wird.

Und tatsächlich klappt das auch so.
Mein 3D-Drucker konnte ein ungefähres Ersatzstück für die Metall-Halterung nachbilden. Diese bestand aus 3 Teilen und musste zu einem Rahmen zusammengeklebt werden.

Und mit “kleben” verstand ich per “Heißluft zusammenschmelzen”.
Das sieht in Videos immer so leicht aus, aber ich hab’s leider ziemlich versaut. Man kann nicht sagen, dass es stabil war, aber es war offenbar “stabil genug”.

Am Mechboard wäre auch Platz für eine Schaltung des C64 Capslock gewesen, doch da mir das nicht so wichtig war, habe ich das weggelassen. Capslock funktioniert dann zwar nicht, aber damit kann ich leben.

Mein Pech war am Ende, dass ich keine C64-Tastenkappen hatte, sondern nur die eines regulären PCs. Folglich passten einige Sonderformate nicht und ich musste andere Bezeichnungen für C64-exklusive Tasten hernehmen.

Fazit

Am Ende war ich dann aber schon überrascht, dass die “neue” Tastatur wieder (fast) perfekt funktionierte.

Ich hätte mir die Sache auch leichter machen können und bei einem Händler eine “professionelle” Ersatztastatur für den C64 einkaufen können.

Doch das selbst-machen ist eben interessanter.

Die defekte originale Tastatur behalte ich natürlich, denn mein Ersatz sieht auch nicht wirklich gut aus. Vielleicht kaufe ich in der Zukunft doch noch ein besseres Keyboard, aber vorerst bin ich zufrieden, dass ich das Gerät wieder in Betrieb nehmen kann.

Doxygen per CMake

2025-04-06T13:00:00+02:00

Doxygen ist im GATE Projekt ein “alter Hut”. Das Programm ist im CI Docker und Script integriert und wartet nur auf seinen Aufruf.
Aber …

Wäre es nicht besser alle Tools (und auch Doxygen) über CMake anzusteuern?

In der Entwicklung haben wir unterschiedliche Tools, die wir unterschiedlich kombinieren und in Scripts unterschiedlich zusammenwürfeln.
Jetzt ist es aber oft ärgerlich, wenn man immer wieder mal aus der IDE zur Konsole wechseln muss, um wieder eines der Tools anzuwerfen.

VSCode bietet in seinem CMake Plugin immer eine Übersicht über alle ausführbaren Targets. Ein Klick auf ein solches baut es und ein anderer Klick im Test-Fenster startet die Tests.

Idee: Doxygen wird per CMake als Utility ausgeführt

CMake bietet mit add_custom_target() eine einfache Möglichkeit jedes beliebige Programm als Target zu registrieren. Beim “Bauen” des Targets wird das registrierte Programm mit einstellbaren Parametern gestartet.

Ich habe meine CMakeLists.txt daher um folgende Zeilen erweitert:

 1function(gate_add_doxygen_target)
 2  find_package(Doxygen REQUIRED)
 3
 4  add_custom_target(util_doxygen_run
 5    COMMAND ${DOXYGEN_EXECUTABLE} "${CMAKE_SOURCE_DIR}/Doxyfile"
 6    WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}
 7    COMMENT "Executing doxygen documentation generation"
 8  )
 9endfunction()
10
11find_package(Doxygen QUIET)
12option(GATE_BUILD_DOXYGEN "Build doxygen docu" ${DOXYGEN_FOUND})
13
14if(GATE_BUILD_DOXYGEN)
15  gate_add_doxygen_target()
16endif()

Wird das Program doxygen im System gefunden, wird die CMake Option GATE_BUILD_DOXYGEN aktiviert und dann die Funktion zum Hinzufügen des Targets aufgerufen. Über die Option kann man das dann auch manuell aus/einschalten.

Da ein Doxyfile ohne schon im Projekt ist, fehlt nur die Aufruf von doxygen mit der Datei als Parameter.

Und mit dem nächsten Configure Klick in der VSCode CMake UI, finde ich schon das neue Target util_doxygen_run in meiner Liste.
Ab sofort kann ich also einfach per Klick die Doku bauen lassen und im Browser parallel überprüfen.

Fazit

Oft sind es die kleinen Dinge, die viel bewirken.

Man kann doxygen natürlich weiter manuell starten, aber der einfache Klick im VSCode Fenster spart Zeit.

Ganz besonders wenn ich immer wieder Änderungen mache und das Ergebnis sofort sehen will, öffne ich im Browser die HTML-Datei und brauche dann nur einen VSCode-Klick und einen F5-Refresh im Browser um die neu-generierte Doku gegenlesen zu können.

CMake 4.0 (ist zuuu neu)

2025-03-30T13:00:00+02:00

Mit dem Erscheinen von CMake Version 4 geht das defacto Standard C/C++ Build-System in eine neue Runde.

Es fühlt sich aber eher wie ein CMake 3.40 an, das auf die letzte 3er-Version 3.31 folgt.

Ich kenne CMake nun seit fast 10 Jahren und nutze es privat wie beruflich in den letzten 6 Jahren täglich.
Eigentlich stellt sich für mich immer wieder die Frage, warum ich es nicht schon seit 16 Jahren durchgehend nutze … naja … eine andere Geschichte.

Version 4.0 bringt für mich keine wichtigen Neuerungen mit, leider beschert uns allen der Umstieg eher Probleme, weil Dinge fehlen.

Ab v4.0 wird der Minimum-Standard auf v3.10 gehoben. Das ist formal kein großes Thema, weil alles weiter funktioniert, was bis v3.9 da war, wenn man von ein paar Sonderfällen und Spezial-Policies und -Defaults absieht.

Doch wer in seinem Script ein

1cmake_minimum_required(VERSION 3.9)

oder generell < 3.10 drinnen hat, bekommt jetzt einen Fehler mit Abbruch, wo in den letzten Versionen nur eine Deprecation-Warning stand.

Viele kleinere Projekte wie z.B.: zlib nutzen nur Basis-Funktionen in CMake, die alle schon in v3.0 oder 3.1 enthalten waren. Folglich ist deren Minimum-Requirement auch für diese alten Versionen gesetzt.

Mit CMake 4.0 lässt sich dieser Code dann nicht mehr verwalten. Das trifft mich vor allem bei Conan Projekten, denn dort sind alle fertigen Pakete und Rezepte fixiert und werden nicht fortlaufend geändert.
Um sie kompilieren zu können ist also in Zukunft ein älteres CMake zwingend erforderlich.

Version 3.26 ist das jüngste “alte CMake-3”, welches von v3.0 bis 3.26 alle Varianten ohne Deprecation-Warning behandeln kann.

GATE Anpassungen

Ich werde mir jetzt wohl etwas einfallen lassen müssen, damit GATE unter CMake 4 genau so bauen kann wie unter CMake 3. Mein altes Test-Ubuntu 16.04 kommt noch mit CMake 3.7 um die Ecke und ich nutze kaum Funktionen über 3.5.

Vermutlich lässt sich cmake_minimum_required variabel gestalten, je nachdem, was wirklich installiert wird. Dummerweise gibt es ohne diese required Zeile auch Warnungen und Fehler, dass das Minimum nicht festgelegt ist.

Fazit

CMake ist grundsätzlich genial … obwohl es uns eine scheußliche Scriptsprache aufzwingt. Da würde mir xmake mit LUA schon besser gefallen … doch wenn es um den Support älterer wie neuerer Compiler und alle Arten von exotischen Plattformen geht, kommt man an diesem Universalwerkzeug einfach nicht vorbei.

Vorläufig musste ich CMake 4.0 wieder deinstallieren und durch 3.31 ersetzen. Gespannt bin ich, wie Conan Projekte auf die Änderung reagieren werden. Conan selbst setzt ja 3.15 voraus, aber wie gesagt: Die CMakeLists.txt Dateien vieler Projekte nutzen oft Werte kleiner 3.10.

Ich rieche Patches, die auf uns zukommen.

Pinball: Bally Air Aces

2025-03-23T12:00:00+01:00

Das letzte Erinnerungsstück an das Wirtshaus meiner Großeltern wurde gefunden:

Hinter einem Kasten verbarg sich seit den 90er Jahren die Anzeige Glasplatte des Flipperautomaten, der damals die Gäste bespaßte.

An den Flipper Automaten Bally Air Aces habe ich immer noch so manche Erinnerungen.

Er muss wohl Ende der 70er oder Anfang der 80er Jahre angeschafft worden sein und wurde dann Mitte der 80er mit Verkauf des Lokal außer Dienst gestellt.

Das alles war vor meiner Zeit … doch weil niemand etwas mit dem Gerät anfangen konnte, wanderte es in den Keller meiner Mutter und so fand ich die Maschine Anfang der 90er als kleiner Junge begeistert vor.

Man konnte ihn zwar bestromen und ein tolles Lichterspiel bewundern, doch leider reagierten die Flügel nicht mehr womit ein echtes Spiel unmöglich wurde.
Aber da das Schutzglas über der Spielfläche entfernt war, ging ich immer wieder mal in der Keller und ließ die Kugel manuell von oben nach unten rollen. Und immer wenn wo eine Lampe blinkte, funkelten meine Augen.

Doch Platz im Keller war rar und so wurde bald ein befreundeter Mechaniker eingeladen, der den Apparat demontierte, Schrauben und Lämpchen für den Eigenbedarf sicherte und die große Kiste entsorgte.

An diesem Tag versündigte sich meine Familie schwer … denn einen der immer weniger werdenden Flipper zu zerstören ist aus heutiger Sicht eine Schandtat … damals war es “normal” so mehr Platz zu schaffen.

Offenbar wurde jedoch das Display-Glas mit den typischen Motiven dieser Zeit nicht entsorgt und landete hinter einem Kasten, wo es ungestört bis ins Jahr 2025 überdauerte.

Ein guter Bekannter, mit dem ich zufällig darüber sprach, war sofort Feuer und Flamme für das alte Erbstück und so freue ich mich, dass ich dem letzten Teil des Flippers ein neues Zuhause verschaffen konnte.

Fazit

Bitte passt auf die alten Flipper auf!

Wie gesagt: Hardwarezerstörung ist eine Todsünde.

Mit heutigen Mitteln und vielen Interessenten im Internet hätte das alte Modell immer noch Freude und vor allem Geld einbringen können.

Ich bezweifle, dass die ausgebauten Schrauben und Blinklampen je den Wert oder Nutzen erreicht haben, den das Gesamtmodell heute hätte erzielen können.

Tja … was soll man machen.

Leb wohl, Flipper!

VBScript mit mehr Rechten

2025-03-16T12:00:00+01:00

Wenn man alte Scripts durchsieht, findet man die eine oder andere “Krampe”, die einen schmunzeln lässt.

Und eine davon schrieb ich vor 15 Jahren zum Setup von Windows-Embedded Terminals in VBScript.
Der Zweck: Das Script soll mit Admin-Rechten laufen und diese einfordern, wenn sie noch nicht vorhanden sind.

Mein Code sah so aus:

 1Public Function RunElevated()
 2  Const ElevationFlag = "E_L_E_V_A_T_E_D"
 3
 4  Dim i
 5  Dim strArgs
 6  strArgs = ""
 7  For i = 0 To WScript.Arguments.Length - 1
 8    If (WScript.Arguments(i) = ElevationFlag) Then
 9      RunElevated = True
10      Exit Function
11    End If
12    strArgs = strArgs & " """ & WScript.Arguments(i) & """"
13  Next
14
15  Dim sysShell
16  Set sysShell = CreateObject("Shell.Application")
17  Call sysShell.ShellExecute("wscript.exe", """" & _
18    WScript.ScriptFullName & """" & strArgs & " " & _
19    ElevationFlag, "", "runas", 1)    
20  RunElevated = False
21End Function
22
23Public Sub Main()
24  ......
25End Sub
26
27If RunElevated() Then
28  Call Main()
29End If

Weil ein Script nicht weiß, ob es mit “erhöhten (=Admin-) Rechten” oder ohne gestartet wurde, startet es sich selbst mit einem “geheimen” Parameter neu und diesmal mit den notwendigen Rechten.

Wird die Funktion
ShellExecute(file, arguments, directory, operation, show) mit dem operation Parameter runas aufgerufen, übernimmt die Shell die Anzeige des üblichen Dialogs für erhöhte Rechte, oder startet das Programm direkt, wenn die notwendigen Rechte schon vorhanden waren.

Beim ersten Aufruf startet sich das Script somit selbst mit erhöhten Rechten und fügt den geheimen Parameter an.
Der zweite Aufruf (mit den höheren Rechten) erkennt den geheimen Parameter und springt dann zum eigentlich gewünschten Scriptcode.

Apropos runas

Dass das Execute-Verb runas die UAC auffordert, den Zielprozess mit erhöhten Rechten zu starten, ist heute unter der ShellExecute Funktion dokumentiert.
Im Jahr 2010 mit den Platform-SDKs von 2008 fehlte diese Info jedoch und so war eine lange Suche im Netz notwendig, bis ich den Hinweis gefunden hatte.

Wenn man den neuen Prozess nicht per Pipes fernsteuern können muss, ist ShellExecute(runas) die übliche Methode mehr Recht zu erhalten. Die Alternative mit den Login-APIs ist recht kompliziert und funktioniert auch nicht in jedem Kontext.

Hier hat mir also ein Script vorgezeigt, wie meine nachfolgenden C++ Implementierungen auszusehen hatten und haben.

Fazit

Hier lobe ich mir sudo und doas aus der POSIX Welt.
Man kann jedes Programm und jedes Script einfach mit root Rechten starten und braucht keine Umwege.

Das Script entstand um sowohl von der Konsole mit Parametern oder direkt per Doppelklick vom Explorer gestartet werden zu können und funktionierte bei allen damaligen Installationen.

Den Code hätte man etwas einfacher gestalten können … aber hey, es funktioniert.

GIF Animationen

2025-03-09T12:00:00+01:00

Wir alle mögen bewegte Bilder. Doch fette Medien-Inhalte kann ich im GATE Projekte jetzt nicht einarbeiten … dafür war das Projekt nicht gedacht.

Aber im kleinen Stil kann man schon ein bisschen was bewegen, daher lautet die Frage heute:

Wie lädt man eigentlich animierte GIF Dateien mit giflib ?

Die giflib ist - woher kenne ich das bloß - eine Low+High-level Bibliothek. Sie bietet primitive Funktionen zum Laden und Speichern einzelner Blöcke an, und hat dann noch ein paar einfache Alleskönner-Funktionen, die einem die Kleinarbeit wieder abnehmen.

Animierte GIFs sind einfach mehrere GIF-Bilder in einer Datei, die noch mit einer Wartelänge verknüpft sind. Und die giflib lädt das alles problemlos in den Speicher.

Auf den freien Speicher kommt es an

Jetzt wäre die Sache recht einfach, wenn mein einfach nur DGifSlurp() aufruft und dann auf alle Bilder über das SavedImages Array in der GifFileType Instanz zugreifen würde.

DOS kann aber nur 64 KB in einem Segment allokieren und nach 9 Segmenten (Bildern) ist dann Schluss.

Es macht also Sinn, den GIF-Datenstrom selbst zu verwalten und die fertigen Bilder gleich auszugeben und nicht zu speichern.

GIFs Stück für Stück lesen

DGifOpen() liest bereits den Header aus dem GIF Stream und gibt uns Infos über die Auflösung des Gesamtbildes. Nun wird per DGifGetRecordType() festgestellt, welcher Block folgt.

Das ist entweder ein EXTENSION_RECORD_TYPE den man dann per DGifGetExtension() und DGifExtensionToGCB() ausliest um an Infos wie die transparente Farbe oder die Frame-Delay-Time zu kommen.
Oder man bekommt einen IMAGE_DESC_RECORD_TYPE, wo man per DGifGetImageDesc() Infos zum Frame einholt und dann für jede Pixelzeile ein DGifGetLine() ausführt um an die Pixels zu kommen.
Der letzte Recordtype wäre dann ein TERMINATE_RECORD_TYPE mit dem die Datei endet.

Das heißt also, man führt das Record-Lesen in einer Schleife aus, kombiniert immer einen EXTENSION_RECORD mit einem IMAGE_DESC_RECORD zu einem Frame und “zeichnet” ihn auf das Ausgabegerät. Dann wartet man die gewünschte Delay-Time ab und setzt so lange fort, bis kein Frame mehr kommt.

Fazit

Die gesamte Prozedur lernt man, wenn man sich die Codes von der Highlevel Funktion DGifSlurp() ansieht, die das gleiche macht und alle Daten in allokierte Speicherblöcke schreibt.

Mit der Eigenentwicklung schafft man nun die Möglichkeiten kleine Animationen auch unter DOS direkt von der Datei ins Video-RAM zu laden. (Die entsprechende Farbraumkonvertierung kommt natürlich auch noch hinzu.)

Ich habe das Beispiel mal als Demo-Tool mit Namen aniplay gespeichert.

Für die Zukunft sehe ich aber ein viel interessanteres Projekt:
Das Erstellen von animierten GIFs z.B. von kürzeren Bildschirmaufnahmen, denn Textfenster ändern sich recht wenig (wenn kein echtes Video läuft), und das kann ein GIF vernünftig einfangen.

Radxa Rock 5 ITX

2025-03-02T12:00:00+01:00

Ich besitze viele ARM-basierte Boards. Raspberry Pi Modelle, aber auch viele OrangePi und andere *Pi Alternativen.

Doch all dieser Kleinkram lässt sich nicht für den täglich Gebrauch nutzen.

Und dann kam endlich ein richtiges Mainboard mit dem Rock 5 ITX.

Auf die Größe kommt es an.

Und mit der Größe verbunden ist auch die weitere Peripherie.
Denn eine richtige Festplatte konnte man beim Raspberry PI lange Zeit nur über holprige Umwege ansprechen. Booten konnte man davon sowieso nicht.

Und dann ist da noch die Platzfrage. Die Chipkarten-SoCs sehen zwar kompakt aus, jedoch haben sie gar nicht den nötigen Platz um Steckplätze und Standardschnittstellen zu etablieren.

Am Ende fällt dann das Gerät permanent um oder wird per Kabel versehentlich durch das Zimmer gezogen, weil es eben nicht die nötige “Größe” eines echten PC’s hat.

Ein ITX-Board mit ARM Prozessor

Radxa hat es richtig gemacht. Sie haben ihr Wissen und die Chips von ihren kleinen SoCs genommen und auf ein Standard-ITX Board verfrachtet.
Hier passen neben einem Standard-ATX-Anschluss auch ein ordentlicher Kühlkörper, mehrere SATA-Ports, zwei “richtige” HDMI Ausgänge (also kein Mini/Micro) und alle möglichen Front-Panel-Anschlüsse, wie wir sie von jedem üblichen PC-Mainboard kennen.

Erstmals konnte ich also ein ARM-Mainboard in ein richtiges PC-Gehäuse einbauen, unter den Schreibtisch stellen und als tägliches Arbeitsgerät einsetzen.

… und soetwas liebe ich einfach nur!

Besonders wichtig ist der Preis: Schon ab 120 Euro erhält man eine 4 GB Variante und mein Board mit 16 GB kam auf etwa 180 Euro. (Tatsächlich ist der fest verbaute RAM der einzige Nachteil, denn ein Nachrüsten gibt es hier leider nicht.)

Dafür erhält man aber mit 8 Kernen (4x 1.8 und 4x 2.4 GHz) eine Power, die einen ebenso günstigen Intel NM100 übertrifft.

Das Board lässt sich mit einem 24-poligen ATX-Anschluss bestromen, unterstützt aber auch eine 12 Volt Buchse und kann direkt von einem handelsüblichen Netzteil gespeist werden.

2 Gigabit-Ethernet Ports, 2 USB-2, 4 USB-3 Ports und 1 USB-C Port, sowie eine Audio In- und Out- Klinkenbuchse runden das Back-Panel neben den bereits erwähnten HDMI-Ports ab.

Ein Passiv-Betrieb ist laut Hersteller zwar möglich, dennoch ist für Rechenintensive Aufgaben ein Kühlung vorgesehen und so nahm ich auch gleich den von Radxa angebotenen Kühler dazu, der über dem CPU-Block auf dem Mainboard angeschraubt werden kann.

Software

Ein vorbereitetes Debian-12 Image steht zum Download bereit und kann direkt auf eine SD-Karte für den ersten Boot übertragen werden.

Der Standard Bootloader auf dem Board liegt im SPI Speicher und unterstützt bereits den Boot von SD-Karten und SATA.
Ich konnte also das Linux Image von der SD-Karte auch einfach auf eine Festplatte übertragen, anschließen und davon booten.

Aber wenn das nicht zum Erfolg führt, bietet Radxa ihr eigenes Tool
rsetup im Linux Image an, welches den Bootloader aktualisieren und neu auf das Board flashen kann.
Sollte auch das gebrochen sein, gibt es noch die Möglichkeit die Firmware remote über USB aufzuspielen, was aber bei mir nicht nötig war.

Raxda hat das Debian Image so angepasst, dass apt auch Updates von den Raxda Servern beziehen kann, wo angepasste Versionen von Kernel und Treiber vorliegen. Ein apt update && apt upgrade erledigt also bereits alles Notwendige um das System aktuell zu halten.

Fazit

Von all den ARM Boards, die ich bisher besessen hatte ist das Rock5-ITX schon alleine deshalb das beste, weil es endlich ein “richtiger PC” ist. Darauf habe ich viele Jahre gewartet und ich hoffe, dass noch viele weitere Hersteller den Schritt in Richtung Standard-PC-Board gehen.
(Unter der Marke Milk gibt es das ja auch schon, allerdings teurer.)

Software-Entwicklung mit allen Sprachen unter VSCode, Webbrowsing mit Chromium und Firefox, Dokumente schreiben mit LibreOffice … all das läuft hoch performant und flüssig und macht dieses Board zur ersten richtigen Alternative zu einem X86 System.

Einen Mangel muss ich leider noch anmerken: Content-Protection. Leider gibt es bisher keine fertigen Bibliotheken für geschützten Content in Web-Browsern für ARM64.
Und genau deshalb laufen dann Netflix, Disney+ und andere Streaming-Dienste nicht auf dieser Plattform. Freie Dienste von YouTube bis PeerTube sind aber in bester Qualität zu genießen.

Ich hoffe, dass die wenigen Mankos bei ARM64 Bibliotheken schnell behoben sind und freue mich nun auf das Arbeiten mit meinem neuen Entwickler-PC unter Linux.

cppcheck

2025-02-23T12:00:00+01:00

Der Compiler ist nicht genug!

Nicht erst seit der Rust Bedrohung braucht C++ Code jedes Codereview, das es kriegen kann.

cppcheck war und ist “das” Standard-Tool, dass hier den Anfang macht.

Statische Code-Analyse hilft Fehler zu erkennen, die Entwicklung und Compiler nicht als solche ansehen.
Es macht also Sinn den eigenen Code durch möglichst viele Tests zu jagen und Fehlermeldung und Hinweise einzusammeln.

cppcheck erkennt viele Formfehler wie uninitialisierte Variablen, oder “seltsam” aussehende Blockverzweigungen und noch vieles mehr.
Ich habe das Tool daher als CMake-Custom-Target eingebaut, womit ich es während der Entwicklung immer wieder direkt per VSCode-Klick ausführen kann um Verbesserungen oder Verschlechterungen in neuem Code zu erkennen.

cppcheck als CMake Target

Ein Code sagt mehr als tausend Worte:

 1
 2if(CMAKE_HOST_WIN32)
 3  find_program(CPPCHECK_APP
 4    NAMES "cppcheck"
 5    PATHS "C:\\Program Files\\Cppcheck" "C:\\Program Files (x86)\\Cppcheck" "C:\\Cppcheck")
 6else()
 7  find_program(CPPCHECK_APP cppcheck)
 8endif()
 9
10if(CPPCHECK_APP)
11
12  option(CPPCHECK_CMAKE_TARGETS "Adds a CPPCHECK targets to analyze code quality" ON)
13  set(CPPCHECK_SOURCE_DIR "${CMAKE_SOURCE_DIR}" CACHE FILEPATH "CPPCHECK source scan directory")
14  set(CPPCHECK_RESULTS_XML_FILE "${CMAKE_BINARY_DIR}/cppcheck_results.xml" CACHE FILEPATH "CPPCHECK results output file")
15  set(CPPCHECK_RESULTS_HTML_DIR "${CMAKE_BINARY_DIR}/cppcheck_report"  CACHE PATH "CPPCHECK HTML report output directory")
16
17  if(CPPCHECK_CMAKE_TARGETS)
18
19    set(CPPCHECK_CMD "${CPPCHECK_APP}" 
20      --enable=all --language=c++ --std=c++11
21      --suppress=cstyleCast
22      --xml --xml-version=2 -j 8 . 2> "${CPPCHECK_RESULTS_XML_FILE}"
23    )
24
25    ## add CPPCHECK process execution target
26    add_custom_target(cppcheck_execute
27      COMMAND ${CPPCHECK_CMD}
28      WORKING_DIRECTORY "${CPPCHECK_SOURCE_DIR}"
29      COMMENT "Running cppcheck..."
30    )
31
32    file(MAKE_DIRECTORY "${CPPCHECK_RESULTS_HTML_DIR}")
33
34    set(CPPCHECK_REPORT_CMD cppcheck-htmlreport 
35      "--title=${PROJECT_NAME}" 
36      --source-dir=. 
37      "--file=${CPPCHECK_RESULTS_XML_FILE}" 
38      "--report-dir=${CPPCHECK_RESULTS_HTML_DIR}"
39    )
40
41    ## add CPPCHECK HTML report generation target
42    add_custom_target(cppcheck_generate_report
43      COMMAND ${CPPCHECK_REPORT_CMD}
44      WORKING_DIRECTORY "${CPPCHECK_SOURCE_DIR}"
45      COMMENT "Generating cppcheck html report"
46    )
47  endif(CPPCHECK_CMAKE_TARGETS)
48endif()

Hier werden zwei zusätzlich Targets angelegt:

cppcheck_execute führt cppcheck aus und generiert die XML-Datei mit gefundenen Problemen.
cppcheck_generate_report lässt über das Tool cppcheck-htmlreport aus der XML Datei eine HTML Seite generieren.

Natürlich müssen beide Tools im Vorfeld im System installiert sein, damit sie auch gefunden und ausgeführt werden können.

In Visual Studio Code erscheinen die beiden Targets im CMake Fenster im Project Outline und können jeweils per Klick gestartet werden.

Fazit

Natürlich könnte man die beiden Tool-Ausführungen in ein Custom-Target zusammenfassen, um nur noch einen Klick zu brauchen.
Der Hintergrund für Trennung war Windows, denn die Standard-Installation von cppcheck führt dort html-report Tool nicht mit. Linux Paketmanager installieren aber immer beide Tools.

So konnte ich dann entscheiden, ob ich nur den ersten oder beide Schritte ausführen wollte.

Die Ergebnisse auf der HTML Seite haben mir schon oft Grund für kleine Änderungen und Verbesserungen gegeben.
Folglich sollte eine cppcheck Auswertung in keinem Projekt mehr fehlen.

PinePhone PostmarketOS Update

2025-02-16T12:00:00+01:00

Um mein PinePhone mit einem neuen postmarketOS Image auszustatten lud ich mir früher ein Installer-Image auf eine SD-Karte, legte diese ein, dann startete beim Boot ein Setup welches das Image auf die eMMC des Telefons übertrug, und fertig.

Aber jetzt ist alles anders.

Mein letztes Images aus dem Jahr 2023 ist schon etwas angestaubt und weil ich letztens selten zum Linux-Telefon gegriffen habe, fiel mir das gar nicht auf.

Es ist Zeit das System zu aktualisieren.

Kein Installer-Image mehr vorhanden

Die neuen postmarketOS Images lassen sich weiter problemlos auf die SD-Karte übertragen und beim Boot erscheint sofort das neue OS.
Doch es gibt keinen Installer, der es von der SD-Karte zur eingebauten eMMC überträgt und somit bootet man immer von der langsamen SD-Karte.

Die Recherche ergab, dass mit Ende 2023 diese alten Installer-Images eingestellt wurden und vorläufig nicht mehr angeboten werden.

Doch eine Alternative ist die Installation via JumpDrive.

Per JumpDrive über USB zum EMMC Medium

Ein JumpDrive Image ist ein kleines bootfähiges SD-Karten Image für PinePhones (aber nicht PinePhone PRO), welches nur einen USB-Dienst hochfährt, der alle Medien per USB als Laufwerk anbietet.

Man überträgt also die pine64-pinephone.img.xz mit Tools wie rufus unter Windows oder dd unter Linux auf eine SD-Karte, schiebt diese dann ins PinePhone und startet es.

Sobald das Bild mit dem verbundenen USB-Kabel erscheint, schließt man sein Telefon an den PC via USB-Kabel an und schon erkennt dieser zwei neue Laufwerke.
Das eine ist die eingelegte SD-Karte selbst, das andere ist das eMMC Modul.

Nun kann man erneut sein Flash-Tool (also wieder rufus oder dd) einsetzen um das postmarketOS-Image direkt auf die eMMC zu übertragen.

Ist das erledigt, kann man das Telefon abschalten, die SD-Karte entfernen und anschließend das PinePhone neu starten.

Und schon hat man die neueste OS-Version vor sich.

Fazit

Ich gebe zu, ich mochte die Installer-Variante mehr. Es ist für mich logisch ein Installations-Medium anzulegen und von diesem zu installieren.
Oder man hat im von SD gebooteten Livesystem ein “Copy-To-eMMC” Tool.

Dass man JumpDrive braucht um dann das richtige Image zu übertragen, funktioniert zwar wunderbar, fühlt sich aber dennoch ungewohnt an.

Wie auch immer … am Ende habe ich frische Software am Linux-Telefon und nach etwas Suchen fand ich auch das Standard-Passwort mit der Zahlen-Kombi 147147, um den Lockscreen überwinden zu können.

Alles in allem gefällt mir aber sehr, dass das PinePhone, welches inzwischen nicht mehr produziert wird immer noch brav mit Software-Updates versorgt wird.

Es gibt auch eine Prozedur um ein Update vom Telefon aus herunterzuladen und auszurollen … doch da hier Tipparbeit an der Konsole notwendig ist, ist die SD-Karte-Methode aus meiner Sicht praktischer.

Odroid X2

2025-02-09T12:00:00+01:00

Vor 12 Jahren wollte meine damalige Firma weg von X86 und Windows Embedded hin zu ARM und Linux.
Und zufällig habe ich heute in meiner Rumpelkiste genau das Development-Board gefunden, welches fast zum Produkt geworden wäre:
Ein Odroid X2

Im Jahr 2013 war der Raspberry PI 1 mit seinem einen Kern mit 700 MHz zwar toll um “ein bisschen” Linux “zu machen” … aber für richtige Rechenoperationen war er deutlich zu schwach.

Das galt besonders für Bildverarbeitung welche damals von Interesse war. Also machten sich Kollegen auf die Suche nach anderen kleinen SoC Boards und stießen auf die Odroid Serie des Koreanischen Unternehmens Hardkernel

Der ODROID X2

Die 4x 1.7 GHz ARM Cortex-A9 CPU ließ den RasPi klar hinter sich und konnte auch mit 2 GB RAM und einem Mali-400 3D Grafikchip punkten.

Nicht ganz unerheblich war auch die Möglichkeit mit einem eMMC Chip zu arbeiten, die in Sachen Performance die üblichen MicroSD Karten überholten, was bei häufigen Zugriffen durchaus ein Thema war.

Wir nutzten damals ein angepasstes Ubuntu und ich erinnere mich, dass dieses aus dem Hause linaro.org stammte.

Heute ist das Board bereits lange “Geschichte”, doch vielleicht findet man in den Archiven der Hersteller sogar noch die Basis, die wir damals nutzten:
releases.linaro.org/archive

Software Update

Um zu sehen, ob das Board noch einsatztauglich ist, habe ich im Archiv von wiki.odroid.com gesucht und fand sogar ein aktualisiertes Ubuntu 14.04 Image, doch die Downloads waren alle nicht mehr verfügbar.

Doch über den Dateinamen fand ich das Image-Verzeichnis odroid.in/ubuntu_14.04lts und lud mir unmittelbar das ubuntu-14.04.2lts-lubuntu-odroid-x2-20150224.img Image herunter.

Das 5 GB große Abbild beinhaltet eine vollständige X11-Umgebung mit Standard Software. Der interne Name von Ubuntu 14 ist Trusty und als Compiler wird die alte GCC 4.8 eingesetzt.

Nach dem üblich apt-get update && apt-get upgrade wollte ich auf die nächste LTS-Version von Ubuntu wechseln. Ubuntu 16.04 ist auch bekannt als Xenial und so musste ich nur int /etc/apt/sources.list und in den Unterverzeichnissen mit weiteren Download-Listen den Token trusty durch xenial ersetzen.

Danach startete ein apt-get update gefolgt von apt-get dist-upgrade die Installation der nächsten OS-Version.

Doch leider war das ein totaler Fehlschlag und das System war nicht mehr startbar. Dieses Schicksal erleiden viele ARM-Boards, die keinen neuen Kernel erhalten und Upgrades auf neue Distributionen daher versagen.

Fazit

Ein weiteres Stück Geschichte wird hiermit ein meine Sammlung aufgenommen. Ich finde es echt schade, dass Linux-Kernel und Distributionen so schnell das Ende einer Hardware einläuten können.

Hier sehen wir erst wie unglaublich wertvoll das Raspberry-PI Projekt ist, welches auch heute noch aktualisierte Software für Hardware von vor über 10 Jahren herausbringt.

Odroid produziert bis heute neue SoC Boards und stellt damit eine Alternative zu anderen Herstellern wie Radxa oder der Orange PI Familie dar.

C++ CGI-Plugins am Webserver debuggen

2025-02-02T12:00:00+01:00

Man konnte doch schon in den 80er Jahren C-Programme auf Webservern ausführen, die Webseiten und anderen Schnick-Schnack generierten.

Heute scheint das vergessen, aber es klappt immer noch … mit etwas Hilfe.

Unter CGI verstehen heute alle nur noch Computer Generated Imagery, also Computer-Grafiken.
Doch die ersten Webentwickler verstanden darunter das Common Gateway Interface, also eine Schnittstelle, wie ein Webserver externe Programme aufrufen konnte, um dort Inhalte dynamisch generieren zu lassen.

CGI

Die Idee war simpel: Ein Prozess wurde mit einer Reihe spezieller Umgebungsvariablen gestartet, die als Input dienen sollten und der Prozess schrieb auf STDOUT, was als HTTP-Content zurückgegeben werden sollte.

Der Webserver übernahm also das Parsen der HTTP-Anfrage, startete den Prozess mit den Parametern und leitete dessen Output mit geringen Protokollzusätzen an die Clients weiter.
Die Prozesse konnten - wie auf POSIX Systemen üblich - echte native Programme oder Shell-Scripts sein, die ja mit dem Interpret auch wie native Programme nach außen wirkten.

So entstand die erste große Reihe von dynamischen Web-Content durch Sprachen wie Perl oder PHP.

Im Laufe der Zeit wurde das Konzept der separaten Prozesse aber als veraltet angesehen und durch neuere Verfahren wie FastCGI ersetzt.
Mit FastCGI wird ein Prozess nur einmal gestartet und kommuniziert mit dem HTTP-Server über Sockets. Somit können Zustände im RAM bleiben und ein Prozess kann auch mehrere Anfragen parallel (multithreaded) bearbeiten.

Einsatz mit C++

Ich setzte CGI mit C++ schon vor 12 Jahren ein, um ferige Datensätze aus Auswertungen und graphische Darstellung aus einer Desktop-UI ins Web zu verlagern.
Weil CGI-Parameter einfach per getenv() gelesen und der HTTP Output per std::cout geschrieben werden kann, konnte ich Datensätze mit wenigen Zeilen Code als JSON Objekte ausgeben und an den Client zurücksenden lassen.

Das Thema Authentifizierung übernahm der WebServer (IIS unter Windows, Apache unter Linux) und ich schrieb noch schnell ein paar Zeilen mit statischem HTML-Code um die per JSON gelieferten Daten “bunt” anzeigen zu können.

In Sachen Deployment is “das Web” natürlich jeder Desktop-App überlegen, und somit konnte ich die Vorteile zweier Welten nutzen:

Fertige C++ Libs lieferten bereits die gewünschten Ergebnisse und mussten nur als JSON Datensatz formatiert werden
HTML Seiten schreiben sich schneller als native Desktop-Apps. Jeder geänderte Buchstabe um UI kann mit einem F5 sofort angezeigt werden … das spart viel Zeit, wenn man nicht dauernd was neu kompilieren muss.

Fazit

Meine Webserver unterstützen alle (mit ein paar Config-Anpassungen) CGI-Programme.
Folglich könnte ich auch hier wieder GATE Plugins schreiben, die Features für das Web offenlegen.

Das könnte eine hervorragende Ergänzung zu WASM sein, denn während WASM moderne Browser voraussetzt, kann ein simples CGI-Tool auch klassischen HTML-Code generieren, der auf Browsern von vor 20 Jahren lauffähig ist.

Super Mario Armbanduhr

2025-01-26T12:00:00+01:00

Meine Mutter ist nicht nur ein Schatz, sie hortet auch einen.

Und so fand ich neulich in ihrer “Alte-Uhren-Lade” den Begleiter meiner Kindheit:
Eine Super-Mario-Bros-3 Armbanduhr von Nintendo.

In den 90er Jahren bekam ich von Super Mario nur zwei Formen mit, nämlich Super Mario Land und Super Mario Land 2.

An den beiden Spielen gab es am originalen Gameboy kein Vorbeikommen und ich glaube, jeder in meiner Klasse mit einem Gameboy hatte die beiden Titel.
Das ging sogar so weit, dass die hiesige Bank einen Speedrun Wettbewerb mit Super Mario Land veranstaltete und kleine Preise für die Gewinner stiftete.

Vermutlich war es die starke Präsenz von “Mario” in allen Medien, die mir dann unerwartet die Super Mario Bros.3 Armbanduhr als Geburtstagsgeschenk verschaffte.

Neben der üblichen Digitaluhr-Anzeige und einer einstellbaren Wecker-Zeit, konnte man eine Mario Figur durch geschicktes Timing auf fixe Positionen steuern, Hindernissen ausweichen und am Ende Bowser anstupsen um zur Prinzessin zu gelangen.

Die Herausforderung war dabei, diese eigentlich kurze Sequenz von etwa 20 Sekunden möglichst oft schadfrei zu Wiederholen.
Ich erinnere mich daran, dass es mir in den Ferien mal durch ein stundenlanges Spiel gelungen war, die Punktezähler zum Überlauf zu bekommen … doch das enttäuschende Ergebnis war, dass er wieder bei Null startete.

In Summe war die Uhr aber ein kleiner Schatz, denn dieses Teil besaß nur ich allein … und wir wissen, wie sehr sich Kinder wünschen “einzigartig” zu sein.

Super Mario Bros. und andere Titel

Dass es parallel auch eine Konsole für den Fernseher gab, wo es andere Mario Titel gab als am Gameboy, war mir gar nicht bewusst. Vielleicht hatte man mal in der Werbung davon gehört, aber vorstellen konnte ich mir das nicht.
Ich wusste auch nicht, was das “Bros. 3” bedeutete, denn dass Mario noch einen Bruder hatte und schon 3 andere große Abenteuer erlebt hatte, hat mir der Gameboy nicht verraten.

Tatsächlich habe ich Mario Bros. Teile bis heute nie durchgespielt, bestenfalls ein paar Level mal angespielt.
Das ist vielleicht eine Bildungslücke, die ich nachholen sollte.

Für mich begann Mario auf der Konsole durch “Super Mario World” auf dem SNES. Zwar habe ich ein solches nie besessen, aber auf diversen “Veranstaltungen” war für Kinder ein solches Gerät bereitgestellt worden.
Konkret fällt mir da die Landesausstellung im Schloss Riegersburg ein, an die ich mich heute nur deshalb erinnere, weil ich dort durch Super Mario World durchgehüpft bin, während die Verwandtschaft altklug über die schöne Ausstellung beim Kaffeestand plauderte.

Fazit

Mit einer üblichen Knopfzelle, die in jedem Supermarkt erwerbbar ist, konnte ich meine alte Uhr aus der Schulzeit wieder reaktivieren.

Seither spielt sie das Mario-Thema als Weckruf ab und ich denke dabei immer wieder gerne zurück, wie sehr man sich als Kind über so ein einfaches Stück Technik gefreut hatte.

Damals war eben alles besser, … ausgenommen die Reaktionszeit der Tasten.

WinCE 4.x mit RTTI

2025-01-19T12:00:00+01:00

Wenn ich von Windows CE Builds spreche, dann handelt es sich um CE 5.0 oder neuer, denn das war die Basis für das alte Windows Mobile und Industrie-Geräte aus meiner Arbeitswelt.

Doch beim Test mit CE 4.2 (2003) Builds erhielt ich Fehler dieser Art:

1error LNK2001: unresolved external symbol "const type_info::`vftable'" (??_7type_info@@6B@)

Visual Studio 2005 kam aus der Schachtel mit Support für alte Organizer unter dem Titel PocketPC2003. Alte CMake Varianten bis v3.11 ermöglichten das Erstellen von Solutions für diese Plattform mit dem Generator:
Visual Studio 8 2005 Pocket PC 2003 (ARMV4)

Doch beim Bauen von C++ Code tauchen dann beim Linken zahlreiche Fehler zur type_info VTable und auch fehlende std::exception Implementierungen auf.

Beim Öffnen des Ordners
C:\Program Files\Microsoft Visual Studio 8\SmartDevices\SDK\PocketPC2003\Lib\armv4
fiel mir spontan die Bibliothek ccrtrtti.lib auf, die sich nach RTTI anhörte und so fügte ich sie manuell zu den Link-Libraries hinzu, und … siehe da … die Build lief fehlerfrei durch.

Es reicht also nicht die Option Enable Runtime Type Information (also den /GR Switch) zu setzen, sondern man brauch auch noch ccrtrtti.lib mit der Implementierung.

In CMake lautet die magische Formel auf:

1if(WINCE)
2  if(MSVC)
3    target_link_libraries(${PROJECT_NAME} "ccrtrtti.lib")
4  endif()
5endif()

Fazit

Die Pocket-PC-Reihe kenne ich nur vom Sehen und war für mich nie relevant. Es schadet aber nicht auf diese Plattform vorbereitet zu sein … selbst wenn sie heute als ausgestorben gilt.

Sobald meine Zeitmaschine fertig ist und ich ins Jahr 2005 zurückreise, bin ich froh, wenn ich die notwendigen Patches bereits parat habe. ;)

Mit HTML zur WASM UI

2025-01-12T12:00:00+01:00

Ich liebe WASM, WebAssemblies und Emscripten. Aber wie bzw. was soll ich mit meinen Desktop-Programmen im Web machen?

Antwort: Was man im Browser immer macht: Ein UI

Meine Diagnose steht seit vielen Jahren fest:

Ein “produktives” UI braucht nur folgende Controls: Labels, Textboxes, Buttons, Checkboxes, Comboboxes, Listviews und Treeviews.

Ein Framework, das diese Elemente anbietet, kann alles bereitstellen, was man zum täglichen Arbeiten braucht.

Und tatsächlich stellt HTML die ersten 5 direkt bereit, und sowohl Listviews als auch Treeviews lassen sich sogar mit HTML 4 leicht nachbauen.

Meine Idee ist daher: WASM erzeugt UIs per Javascript, welches das DOM einer Seite manipuliert.

Erste Experimente

Der größte Aufwand bei dieser Idee entsteht beim Mapping und der Vermittlung zwischen der WASM- und der Browser-Welt.

Emscripten lässt uns per emscripten_run_script_string() einen jeden Javascript Block als C-String zum Browser schicken. Folglich braucht man nur noch den richtigen Code zusammenbauen der per document.createElement() neue HTML Element erzeugt und dann Eigenschaften zuweist.

Die Praxis sieht aber viel komplizierter aus, da wir solche Scripts sowohl aus dem Browser-UI-Thread, als auch aus einem WASM-Worker senden können müssen.
Im zweiten Fall muss der String am Heap liegen und zum UI-Thread geschickt werden, welcher dann die Verarbeitung und Deallokierung übernimmt.

Genau hier schleichen sich gerne Bugs und Leaks ein, was oft schwer abzutesten ist.

Fazit

Mein erste Prototyp ist gebaut und beweist, dass man ein Label und eine Textbox per WASM im Browser generieren lassen kann.

Ein nächstes Problem wird nun die “Idee eines Fensters” sein, denn im Browser (und besonders am Smartphone) sind Popup-Fenster heute ein Fremdkörper.

Es zeigt sich also, dass nicht jedes Desktop-Feature leicht übertragbar sein wird.

Trotzdem gefällt mit die Vorstellung, dass man Desktop-UIs “einfach fürs Web kompilieren kann”. Und damit geht diese Analyse in die nächste Runde.

QR-Code Encode

2025-01-05T12:00:00+01:00

Na und wer hat nicht schon mal im Bett eine QR-Code Bibliothek überarbeitet?

Oder: Was man über Weihnachten sonst noch alles machen kann.

Mit dem Projekt quirc kann ich schon seit einiger Zeit QR-Codes aus Bildern lesen und ihren Inhalt extrahieren. Doch eigene QR-Codes erzeugen konnte ich mit diese Bibliothek nicht.

Neben anderen (teils sehr aufgeblähten) Projekten fiel mir eines ins Auge:
nämlich github.com/ricmoo/QRCode

Es glänzt durch seine Einfachheit und dem Fehlen von malloc oder anderen Heap-Allokationen im Quellcode.
Damit ist es ideal für Mikrokontroller Projekt geeignet und auch ein würdiger Kandidat für das GATE Projekt.

Codebase

Leider fielen mir neben der kompakten Codebase auch ein paar Unschönheiten auf. Der Build liefert zahlreiche Warnungen bezüglich nicht zusammenpassenden Datentypen auf.

Es wird wild zwischen 8, 16 und 32 bit Typen hin und her gecastet, während sich auch Wechsel zwischen signed und unsigned häufen.

Aus diesem Grund habe ich einen Fork angelegt und mir vorgenommen, dieses alte Projekt etwas aufzupolieren.

Codeupdate

Tatsächlich lassen sich viele Warnungen durch die Umstellung auf einheitliche Datentypen bzw. typedefs fixen.
An den Stellen, wo wirklich Casts notwendig sind, werden diese explizit durchgeführt, womit der Typenwechsel auch sichtbar wird.

Da der Code bereits im C99 Stil geschrieben ist, ich jedoch noch ältere Compiler unterstützen möchte, habe ich auch hier einiges verschieben müssen.

Die Deklaration von Variablen kommt C90-like an den Anfang jeder Funktion. Und der einmalige Einsatz von lokalen variablen Arraylängen wurde durch eine feste Arraylänge mit einem Maximumwert ersetzt.

Um vom optionalen stdint.h loszukommen, wurden typedefs nach dem Schema qrcode_intX_t eingeführt.

Und am Ende wird CMake benutzt um festzustellen, ob Header und Features vorhanden sind und um die typedefs auf Standards oder Fallback Werte zu setzen.

Fazit

Am Ende habe ich nun eine überarbeitete Version von QRCode, die auch mit meinen Windows CE Builds oder unter Watcom und MS-DOS kompilierbar ist.

Obwohl fast jede Zeile überarbeitet wurde, ist die Funktionalität gleich geblieben.

Und weil die Resultate nicht nur für das GATE Projekt relevant sind, habe ich ein eigenes Repo auf Codeberg dafür angelegt:

codeberg.org/gatelinker/QRCodeGenPort

Happy New Year 2025

2025-01-01T12:00:00+01:00

Das neue Jahr ist da - Hurra!

Trotz Knallgewitter gegen Mitternacht, steht die Welt noch.

Es wird Zeit für Veränderung.

Prosit Neujahr!

Das Jahr 2024

2024-12-31T12:00:00+01:00

Das Jahr 2024 haben wir jetzt auch geschafft.

Oder man könnte auch sagen:

Es hat uns geschafft.

CMake und CONAN

2024 war “mein CMake und Conan Jahr”. Denn durch meine Erfahrung im GATE Projekt mit diesen beiden Tools konnte ich auch beruflich eine große Umstellaktion vorantreiben, in welcher alle Schmerzpunkte von CONAN v1 entfernt und eine sauberere CONAN v2 Umgebung aufgesetzt werden konnte.

Es ist faszinierend, wie viel Codemüll sich ansammelt, wenn man Workaround über Workaround legt, nur weil man nicht weiß, wie es richtig gemacht werden kann.

Mehr als 50 % an CMake und CONAN Code konnte gestrichen werden, als Kernfunktionen beider Technologien effizienter eingesetzt wurden. Es ist in etwa so, als hätte man das Gewicht eines Autos von 1.8 Tonnen (SUV) auf 0.9 Tonnen (Kleinwagen) reduziert, wobei Platz, Geschwindigkeit und Komfort gleich geblieben sind.

Die Unix Renaissance

Nach vielen Jahren in der Arbeitswelt mit Windows, lässt sich der zunehmende Übergang zu Linux nicht mehr leugnen.
Linux hat sich von dem defekten Bastelhaufen, der es im Jahr 2000 war, zu einem ernstzunehmenden System entwickelt, das heute nicht mehr wegzudenken ist.

Parallel dazu sind meine Fortschritte bei den Builds für NetBSD, OpenBSD und FreeBSD ein weiterer Meilenstein auf dem Weg zum Unix-Horizont.

Und Microsoft hat mit seiner idiotischen KI-Strategie das eigene Betriebssystem in den letzten Jahren mehr als sträflich vernachlässigt, was sich in immer schlechterer Performance und nutzlosen UI Spielereien niederschlägt.

Ich bin gespannt, wie dieser Trend weiterlaufen wird.

Welt(un)ordnung

Jenseits der Technik sieht es schlecht aus.
1000 km von mir entfernt wird weiter Krieg geführt.
Ein seniler Hitzkopf wird gegen alle Vernunft ein weiteres Mal zum Präsidenten der USA gewählt.
Und Konzerne sichern sich überall immer mehr Macht, was von dummen Schafen (genannt Konsumenten) auch noch gefeiert wird.

Dystopische Filmreihen aus den 80er und 90er Jahren des letzten Jahrhunderts, fangen langsam an beängstigende realistische Zukunftsvorhersagen darzustellen.

Fazit

Ja, 2024 war beides, Fluch und Segen.
Aber heute wird gefeiert und das gelobt was gut war.

Und wie schon oft gesagt wurde:

Wenn die Welt untergeht, fahre nach Wien.
Denn bei uns dauert alles einige Monate oder Jahre länger, bis es auch bei uns so weit ist.

Kein Happy-End

2024-12-25T12:00:00+01:00

Als ich vor 22 Jahren nicht wusste, was ich in meinem Leben mit meinem Leben anfangen sollte, tat das Arbeitsmarktservice das, was es immer tut:
Es schickte mich in einen Kurs.

Und dort saß ich dann neben einem Typen, dessen Geschichte heute nur wenige kennen: Rudi.

Nachdem wir ein paar Wochen HTML, PHP und MySQL Beispiele abgetippt hatten, erhielten wir ein Zertifikat mit dem Titel “Internet-Programmierer” und so dachte Vater Staat, würden gestrandete Möchtegern-IT-ler aus den 90ern das neue Jahrtausend beherrschen können.

Dieser AMS-Kurs hat sicher viel gekostet und entsprechend gar nichts gebracht, außer einer Sache: 5 Personen aus dieser 10er Gruppe dachten kurz, sie könnten jetzt eine neue österreichische Microsoft-Variante als Firma gründen.
Rudi und ich waren zwei davon.

Ohne das nötige Wissen und Geschäftskontakte war dieses Unterfangen aber schwer, und so war nach einigen Monaten auch nicht viel mehr drinnen als ein paar inoffizielle Aufträge der Marke:

Einzelunternehmer Handwerker Huber will auf seiner Front-Page Webseite ein paar OnMouseOver-Einfärbungen seiner Links haben.

Und so verdiente man sich eben 100 Euro zum Arbeitslosengehalt hinzu und wartete geduldig auf den Nächsten 30-Minuten Job … bis zu zwei Wochen.

Ich hatte dann doch das Glück über - man glaubt es kaum, per klassischen Bewerbungsschreiben - einen richtigen Job zu bekommen und mein Leben in geordnete Bahnen zu bekommen. Doch was wurde aus Rudi?

Die richtige Wahl im Leben

In Fernseh-Sendungen mit Titel “Die Auswanderer” erfährt man skurrile Details über Wünsche und Ideen im Ausland und dass diese auch scheitern können. Doch man sieht nie, was dann nach 5 Jahren mit solchen Menschen passiert.

Rudi hatte noch bevor ich ihn kennenlernte diese Erfahrung auch gemacht. Alle Ersparnisse wurden in ein Flugticket gesteckt und alle Güter im Heimatland wurden verkauft.

Als er dann gezwungenermaßen wieder in Wien ankam, weil ein fehlendes Sozialsystem im Ausland und “Kosten” für Medizin nicht gedeckt werden konnten, war dieser Traum geplatzt.
Zwar wird “bei uns” keiner leichtfertig dem Tod überlassen, doch auch unser Sozialsystem reduziert alles auf ein Minimum, wenn Lücken in der Beitragszahlung bei Versicherungen dokumentiert sind.

Der AMS-Kurs war dann eine der letzten “großen” Leistungen, die dem Kollegen gegönnt wurden, und die auch bei ihm kein Tor zu einem Arbeitsplatz öffnen konnten.

So blieb nichts weiter übrig als alle möglichen Kleinjobs anzunehmen, und so kamen bei mir gelegentlich Mails an mit der Frage, ob ich “bei einem Javascript” aushelfen konnte.

Die skurrilste Szene war dann jene, als mir Rudi einen Zahnarzt empfahl, der mich gut versorgte, während Rudi mit der Assistenz versuchte einen “Deal” auszuhandeln, da er eine neue Füllung brauchte und deren PC für die Terminplanung offensichtlich ein paar Windows-Updates notwendig hatte.

Fun-Fact-Frage: Wenn Zahnfüllung == Windows-Update, was ist dann eine Wurzelbehandlung wert?

Hier bemerkte ich, wie schwer man es hat, wenn man aus dem Sozialsystem herausgefallen ist und quasi mittellos dasteht. Ich hatte so etwas nie erlebt und konnte es mir auch gar nicht vorstellen, dass medizinische Leistungen einfach nicht erbracht werden.

Nicht meine Angelegenheit

Während ich nun Schritt für Schritt meine Fähigkeiten in Firmen ausbauen konnte, riss der Kontakt zu Rudi mehr und mehr ab, bis er eines Tages ganz aufhörte. Diverse “gemeinsame Projekte” wie Webspaces wurde aufgelöst und ich hatte auch weder Lust noch Zeit, weiter kleine PHP-Scripts in meiner Freizeit zu schreiben, wenn es doch viel spannender war in Unternehmen mit X-tausenden Personen Abläufe zu automatisieren.

Schnell hat man dann Phrasen wie

Ich kann mich nicht am alles kümmern.

vorgefertigt, um Anrufe schnell enden zu lassen, und man fühlt sich voll und ganz im Recht dabei.

Erinnerungen

Trotzdem werde ich den etwas pummeligen Mann nie vergessen, der ein witziger Kerl war, immer einen klassischen Wiener Spruch drauf hatte und ein bisschen wie “Garfield” durchs Leben schlenderte.

Bis heute spreche ich die Speise Gnocci (ital. “Njoki” gesprochen) scherzhaft mit Rudis Betonung “Gnoootschiii” aus, da er sich diese gerne mit diversen Soßen zubereitete.

Auch andere Wortspiele wie “File-Shave” nutze ich noch heute gelegentlich, so wie ich sie damals von ihm gehört hatte.

Und je länger ich darüber nachdenke, wächst mein schlechtes Gewissen, den Kontakt damals einfach so beendet zu haben.

Endstation

Es war im Jahr 2009, als ich spontan auf die Idee kam, nach Rudi per Google zu suchen.
Gefunden wurde nur ein Eintrag einer Pfarre mit dem Laut:
Heilige Messe, für verstorbenen R.

Getriggert fragte ich dann weiter herum und so wurde mir die Geschichte weitergeleitet, dass sich Rudi wegen seiner vielen Probleme und körperlichen Situation das Leben genommen hatte.

Ein Ende, dass sich dieser Mann auch bei all seinen Fehlern wirklich nicht verdient hatte.

Fazit

Es ist Weihnachten.

Es wird wie jedes Jahr Zeit mein Weihnachtsgeld zu überweisen.

Und immer, wenn ich mich kritisch frage, ob Volkshilfe, Caritas und andere Organisationen eine Spende verdienen, dann denke ich mir, ob vielleicht eine weitere Behandlung, ein weiterer Kurs, ein weiteres Gespräch Rudi von seinem letzten Weg hätte abhalten können.

Auch ich hätte damals abstürzen können, als ich wenig hatte und es war eine gute Portion Glück, die mir Arbeit, Einkommen und “Auskommen” beschert hat. Und all das wurde durch soziale Einrichtungen ermöglicht, die es gestatteten schwierige Zeiten zu überstehen.

Manchmal reicht eben ein kleines Ereignis, das alles ins Rollen bringt, zum Guten oder zum Bösen.

Zitat aus Göthe’s Faust:

Erinnrung hält mich nun, mit kindlichem Gefühle,
Vom letzten, ernsten Schritt zurück.
O tönet fort, ihr süßen Himmelslieder!
Die Träne quillt, die Erde hat mich wieder!

Das Öxlein und das Öselein

2024-12-24T12:00:00+01:00

Immer wieder erwähnt meine Mutter in Erzählungen, wie es in ihrer Kindheit zu Weihnachten war, als die kleine Dorfkapelle am heiligen Abend voll mit Mensch war, und wie gemeinsam gesungen wurde.

Und es soll mein Großvater gewesen sein, der damals einen alten Brauch durch einen neueren ersetzt hat.

Österreich ist sich ganz besonders stolz auf seine großen Export-Güter in der Musik:
Stille Nacht, heilige Nacht is wohl das “bekannteste” Lied aus der Alpennation, welches in alle Sprachen übersetzt und in vermutlich jedem Land irgendwo einmal angestimmt wird.

Doch in einem kleinen Dorf im Waldviertel, hinter den sieben Hügeln
bei den Hühnern mit den kurzen Flügeln …
oder so ähnlich, da war alles anders.

In der Kapelle wurde nämlich von Jahr zu Jahr ein anderes Weihnachtslied angestimmt, und zwei alte Herrn machten sich stets einen Spaß daraus, ein paar Laute so zu verzerren, dass die Kinder sich das Lachen nicht verkneifen konnten.

Ein Öxlein und ein Öselein,
das mögen gute Tierlein sein.

Natürlich sollte es “ein Öchslein und ein Eselein” sein, die hier besungen wurden, doch so brannte sich die Zeile ins Gedächtnis der damaligen Kinder.

Einige Jahre später drängte (so die Legende) mein Großvater darauf hin, man möge doch wie alle anderen “zivilisierten” Gemeinden, die “Stille Nacht” besingen und so setzte sich langsam der Wille zur Veränderung bei den “Dorfältesten” durch.

Nur erklingt auch im Waldviertel das Lied aus Oberndorf am

Dezember.

Doch woher stammte eigentlich das “Öselein”.

Was ist das doch ein holdes Kind

Das Internet hilft weiter: Die deutsche Dichterin Luise Hensel erdachte den Text 1871, und irgendwie muss er es auch in den Südosten geschafft haben, wo ihn meine Vorfahren gelernt hatten.
Interessant ist, dass das Lied dem “näheren” Stille-Nacht-Text vorgezogen wurde, bis er vermutlich in den 1960er Jahren aufgegeben wurde.

Die Seite lieder-archiv.de hat das Stück für die Nachwelt konserviert, was mir eine große Freude bereitet.

Trotzdem möchte ich den Text nun hier einfügen, damit er möglichst lange erhalten bleibt … und vielleicht möge sich der eine oder andere Leser bei Strophe 4 zwei alte Bauern vorstellen, die wie Schulkinder aus dem “Eselein” ein “Öselein” beim Durchsingen machten.

Was ist das doch ein holdes Kind
das man hier in der Krippe find’t?
Ach, solch ein süßes Kindelein,
das muss gewiss vom Himmel sein.

Die Frau, die bei der Krippe kniet,
und selig auf das Kindlein sieht,
das ist Maria fromm und rein;
ihr mag recht froh im Herzen sein.

Der Mann, der zu der Seite steht,
und still hinauf zum Himmel fleht,
das muss der fromme Josef sein,
der tut sich auch des Kindleins freun.

Und was dort in der Ecke liegt
und nach dem Kindlein schaut vergnügt,
ein Öchslein und ein Eselein,
das mögen gute Tierlein sein.

Und die dort kommen fromm und gut
mit langem Stab und rundem Hut,
das ist der Hirten fromme Schaar,
die bringen ihre Gaben dar.

Und was den Stall so helle macht,
und was so lieblich singt und lacht,
das sind die lichten Engelein,
die schaun zu Tür und Fenster ein.

Und die da kommen ganz von fern
und gläubig schauen nach dem Stern,
das werden wohl die Weisen sein
mit Weihrauch, Gold und Spezerein.

Und ob dem Stalle flammt der Stern,
der leuchtet nah und leuchtet fern;
er leuchtet auch durch unsre Zeit
und leuchtet bis in Ewigkeit.

Sei hochgelobt, du dunkle Zell!
Durch dich die ganze Welt wird hell.
Klein Kindlein in Mariens Schoß,
wie bist du so unendlich groß.

YouTube hat zumindest die ersten 3 Strophen vertont:

Hermes Phettberg ist tot

2024-12-22T12:00:00+01:00

Er war der Gesprächsstoff in der Schule bei den anderen … und ich hatte seine Sendung stets verpasst.

Erst nach 2000 sah ich den dicken Mann im Fernsehen und YouTube konserviert seit 2010, was in den 90ern geschehen ist.

Josef Fenz, auch bekannt als Hermes Phettberg, ist vor Kurzem gestorben.

Ein (inzwischen ebenfalls verstorbener) Nachbar meinte mal:

Phettberg? Das ist doch dieser gebildete Sandler, oder?

Und … irgendwie passt das.
Die Kunstfigur Phettberg, ein schwer übergewichtiger, verkommen wirkender und bestätigt stinkender Mann, trat in den 90er Jahren im österreichischen Fernsehen mit dem Namen
Phettbergs nette Leit’ Show auf. Er lud Künstler, Politiker und Professoren zu sich auf die Bühne ein und diskutierte auf hohem Niveau und mit unvergleichlichem Witz über das aktuelle Geschehen.

Die (oft von seiner offen belebten Homosexualität untermalten) frechen Statements ließen auch so manchen Teenager verlegen erröten und so wurde Phettbergs’ Show zum Geheimtipp auch an meiner Schule.

Und trotzdem hatte ich nie auch nur eine einzige Episode im Spätabendprogramm mitverfolgt, sondern wunderte mich nur über die “neuen Worte”, die am Nebentisch während des Unterrichts getuschelt wurden.

Erst als der damals “neue” Sender ATV Phettberg mit einer veränderten Neuauflage des Formats auf die Fernseh-Kästen projizierte, konnte ich erstmals die Schlagfertigkeit und den selbstironischen Witz von “Österreichs’ bekanntestem Schwulen” mitverfolgen.

Legendär war für mich das Video “Phettberg kauf sich einen Computer” im Geschäft VDS-Computer in der Gumpendorfer Straße.

Damals schaltete dieser Hardware Händler Inserate in jeder Zeitschrift und war auch für die Reparatur eines meiner Geräte verantwortlich.

Und siehe dar, in meiner Sammelkiste überlebte ein letztes Überbleibsel dieses Unternehmens: Eine Zündholzschachtel mit der Adresse:

Jede Chance etwas “Sexuelles” in die Diskussion einzubringen wurde genutzt. Und seitdem der “Chello-Mann” das UPC Telekabelkabelmodem am neuen PC angeschlossen hatte, war Phettberg “online”.

Auf der Seite phettberg.at wurde stets um Geld gebettelt, welches dem Redekünstler Zeit seines Lebens fehlte. Doch dafür gab es “kostenlos” Auszüge aus seinen Predigten, in denen er gerne den belehrenden Dorfpfarrer oder Bischof nachahmte, welcher immer nach “jungen Buben in engen Jeans” Ausschau hielt.

Doch berühmt wird er immer für die “Nette Leit’ Show” bleiben, in denen jeder Gast nach “Frucade oder Eierlikör” gefragt wurde.

Heute noch auf YouTube konserviert sind Schmankerl wie das Gespräch mit dem Leiter der Lebensmittelanstalt Wiens Alfred Psota.

Fazit

Nach Schlaganfällen und dem allgemeinen körperlichen Verfall, wurde Franz Fenz nur noch selten nach dem Jahr 2010 wahrgenommen. Zwar schrieb er weiter seine Predigten, doch diese hatte nicht mehr die “Fülle” von damals, wie es auch sein abgemagerter Rumpf darstellte.

Die Nachricht von Hermes Phettberg’s Tod Ende 2024 lässt mich erkennen, dass nun 30 Jahre vergangen sind, seit der Koloss die große Bühne erstmals betrat.

Schnell ist es vergangen, das Leben.

erklärte mal ein Hinterbliebener nach einem Begräbnis. Und das stimmt.

Phettberg hat viele Menschen zum Lachen und einige davon auch zum Nachdenken gebracht. Darauf kann er stolz sein.
Wir werden ihn dafür in Erinnerung behalten, mit all den Fehlern, die ihn zu dem “Ungustl” machten, der er immer gewesen ist.

Neue öffentliche Codeberg Runner

2024-12-15T12:00:00+01:00

Seit Neuem werden neue (mir unbekannte) Runner in der Codeberg Action-Runner UI angezeigt.

Es ist also so weit. Bald haben wir “freie” Build-Server.

Codeberg startete mit Woodpecker CI, einer externen CI/CD Lösung, die ich bisher nie benutzt hatte.
Doch parallel implementierte Forgejo (die Software hinter Codeberg) ein zu Github kompatibles “Actions” System.

Seit einem Jahr läuft nun auf einer meiner Privatmaschinen ein Forgejo-Runner und führt Builds bei jedem Commit aus.
Das Codeberg-Team hatte damals diese Technik selbst nicht eingesetzt und konnte daher bei Support-Fragen immer nur an das Forgejo-Team verweisen.

Doch nun hat Codeberg globale Actions-Runner aktiviert und betreibt nun frei verfügbare öffentliche CI/CD Dienste.
Neben meinen eigenen Build-Runnern werden nun folgende Instanzen angezeigt:

tiny@actions-tiny.aburayama.m.codeberg.org
- für max. 2 Minuten Jobs
small@actions-tiny.aburayama.m.codeberg.org
- für max. 5 Minuten Jobs
medium@actions-tiny.aburayama.m.codeberg.org (10 Minuten Jobs)
- für max. 10 Minuten Jobs

Eine genauere Übersicht wird unter codeberg.org/actions/meta bereitgestellt.

Fazit

Ich finde das Angebot super. Mein Builds sprengen diese Limits teilweise, aber ich könnte mir vorstellen über einen freien Runner einen Webrequest an einen Cloud-Dienst zu senden, der eine VM hochfährt, die meinen eigenen Runner ausführt.
So spare ich Betriebskosten und aktiviere meine Ressourcen nur bei Bedarf, und die Belastung auf der Seite von Codeberg ist minimal, da ja nur ein paar HTTP Aufrufe abgesetzt werden.

Codeberg bietet nun alle Features an, die Produkte wie Github oder Gitlab auch im Angebot haben … nur dass Codeberg ein echtes OpenSource-Projekt mit einer nicht-kommerziellen Mission ist.

Ein großes “Danke!” geht an die Codeberg Betreiber und die Community.

CTest Debugging in VSCode

2024-12-08T12:00:00+01:00

Per CTest registrierte Tests aus CMake können in VSCode auf viele unterschiedliche Arten und Weisen gestartet werden.

Und jede hat ihre individuellen Eigenarten.

Ignorieren wir mal die “Problemchen”, die uns CONAN einbrocken kann und sprechen wir nur über CMake.

Natürlich kann man ein Test-Programm-Target auch als normales CMake-Debug Target auswählen und ganz normal zum Debugging starten … doch darum soll es hier nicht gehen.

Wird ein Target als Test per add_test() registriert, erscheint der Test auch in VSCode’s Test Explorer.
Dort kann der Test per Klick gestartet werden, was CMake anwirft und dieses dann den Test regulär startet.

Neben dem Start-Pfeil-Button, gibt es noch den Start-Debugging Button neben jedem Test.
Beim einem Klick darauf braucht VSCode wieder eine Launch-Konfiguration, die in etwa so aussehen kann:

 1// .vscode/launch.json
 2{
 3  "version": "0.2.0",
 4  "configurations": [
 5    {
 6      "name": "(gdb) CTest Launch",
 7      "type": "cppdbg",
 8      "MIMode": "gdb",
 9      "request": "launch",
10      "program": "${cmake.testProgram}",
11      "args": [ "${cmake.testArgs}" ],
12      "cwd": "${cmake.testWorkingDirectory}"
13    },
14    {
15      "name": "(msvc) CTest Launch",
16      "type": "cppvsdbg",
17      "request": "launch",
18      "program": "${cmake.testProgram}",
19      "args": [ "${cmake.testArgs}" ],
20      "cwd": "${cmake.testWorkingDirectory}"
21    }
22  ]
23}

Beim “Start-Debugging” erscheint ein Menüs, das uns die beiden definierten Möglichkeiten anbietet und startet einen Debug-Prozess basierend auf den CTest-Einstellungen, die wir gewählt haben.

Und wenn diese Einstellungen falsch sind, startet gar nichts.

CMake Generator Unterschiede

Ein gravierenden Unterschied zwischen MSVC und den anderen Compilern ist die Visual Studio Solution, und ihre Projekte, die Debug und Release- Konfigurationen beinhalten, während für andere Compiler eine Konfiguration vorausgewählt werden muss.
Das führt dazu, dass ein GCC immer genau ein Ausgabeverzeichnis für Programme und Bibliotheken hat, doch Visual Studio erhält zwei, einmal Debug und einmal Release. Der add_test() Test muss also wissen, wie er Debug und Release-Konfigurationen unterschiedlich verwaltet.

Jetzt kommt noch ein weiterer Fall hinzu: nämlich Ninja.
Ninja-Build kann das Bauen wie MSBuild verwalten, verzichtet aber auf Solutions oder VS-Projekte und setzt das unkompliziertere GCC Schema mit genau einem vorkonfigurierten Build-Type ein.

Aus diesem Grund sieht meine add_my_test() Funktion so aus:

 1set(APP_EXECUTABLE ${PROJECT_NAME})
 2set(TEST_ARGS)
 3get_target_property(OUTPUT_FOLDER ${TARGET_NAME} RUNTIME_OUTPUT_DIRECTORY)
 4if(MSVC AND NOT (${CMAKE_GENERATOR} MATCHES "Ninja"))
 5  set(TEST_WORKING_DIRECTORY "${OUTPUT_FOLDER}/$<CONFIG>")
 6else()
 7  set(TEST_WORKING_DIRECTORY "${OUTPUT_FOLDER}")
 8endif()
 9add_test(NAME "${TEST_NAME}" WORKING_DIRECTORY "${TEST_WORKING_DIRECTORY}" COMMAND "${APP_EXECUTABLE}" ${TEST_ARGS})

Fazit

Mit der Launch-Konfiguration für CTest und ein paar Anpassungen für den Start kann jedes Testprogramm auch aus dem VSCode Testing-Tab zum Debuggen gestartet werden.

Ich wünschte, ich hätte CTest und VSCode schon 10 Jahre früher kennen gelernt und eingesetzt, denn strukturiertes Testen kann die Qualität der Softwareentwicklung nachhaltig verbessern.

CMake project oder project C

2024-12-01T12:00:00+01:00

Es ist zum Durchdrehen.

Mit project(xyz) laufen Standard-Builds (Windows, Linux) aber der Tiny C Compiler (TCC) streikt, weil CMake hier C++ Code-Tests exekutiert.

Mit project(xyz C) streikt wieder Watcom, weil der dann C++ gar nicht mehr nutzen kann.

Fangen wir am Anfang an: Es ist ein philosophisches Problem.

C und C++ sind historisch in fast allen Betriebssystemen stark mit einander verbunden. Und ich sehe das GATE Projekt als eine Brücke zwischen den beiden Sprachen.
Doch in Wahrheit sprechen wir von zwei Sprachen, die wie zwei Länder zwei getrennte Rechtsräume, Gesetzgebung und Kultur beinhalten.
Auch Bjarne Stroustrup hat schon mehrfach verkündet:

Es gibt kein C/C++.

Soll heißen:

Es gibt entweder C oder C++.

TCC ist nur C

Der Tiny-C-Compiler ist im Gegensatz zu “den großen Brüdern” ein reiner C Compiler, während MSVC, GCC, CLANG und WATCOM beide Welten abdecken.

Wer also sein CMake Projekt mit

1project(myproject)

einleitet, lässt CMake nach einem C und einem C++ Compiler suchen, wobei zweiteres mit dem TCC fehlschlägt und CMake abbricht.

Die Lösung lautet:

1project(myproject C)

und alles ist wieder gut.

Optionaler C++ Support

Da im GATE Projekt jedoch C und C++ Targets vorkommen, hätte ich bereits eine NO_CPP Option eingeführt, die C++ Targets nur dann einschließt, wenn die NO_CPP Option NICHT gesetzt ist.
Das funktioniert auch mit MSVC und GCC, doch nun fängt OpenWatcom an zu spinnen.

Ist dort ein Top-Level-Projekt an die Sprache C gebunden, können keine C++ Unterprojekte mehr angefügt werden.

Als “schnelle” Lösung fiel mir am Ende nur folgende Lösung ein:

1option(GATE_NO_CPP "Build C files only, no C++ support" OFF)
2
3if(GATE_NO_CPP)
4  project(gate C)
5else()
6  project(gate)
7endif()

Im Toplevel CMakeLists.txt wird die NO_CPP Option definiert und abhängig davon wird ein reines C oder allgemeines Projekt angelegt.
Die Option wird nur für den TCC of ON geschaltet und im Nachgang können weitere C und optional auch C++ angelegt werden.

Fazit

Auf Details kommt es an.

Ich liebe CMake für seine unglaublichen vielen Anbindungen an unterschiedliche Compiler. Doch hier habe ich einmal ein Problem identifiziert, das CMake nicht selbst löst und mir etwas Nacharbeit beschert.

Toplevel-Projekte sind rein technisch auch gar nicht notwendig, doch sie helfen in IDEs bei der Schaffung einer überordneten Instanz wie “Solutions” bei Visual Studio.
Dass deren (sonst wirkungslose) Konfiguration Arbeitsläufe negativ beeinflussen kann, war mir bisher nicht aufgefallen.

However … wieder was gelernt.

CONAN 2 Tests

2024-11-24T12:00:00+01:00

Das Drama mit CONAN ist oft, dass die Entwicklung in unterschiedlichen Kontexten läuft. Und ein conan create führt Builds und Tests manchmal ganz anders aus, als ein cmake build nach einem conan install.

Auf zur Analyse!

conan build und conan create laden alle Abhängigkeiten und fügen die notewendigen Pfade in die PATH und LD_LIBRARY_PATH Umgebungsvariablen ein, wenn Prozesse wie cmake gestartet werden.
Laufen dann Tests, erben die Test-Prozesse die Umgebung und alles läuft problemlos.

Bei der Entwicklung nutzen wir aber häufig conan install und conan source und danach starten wir cmake oder eine IDE (wie VSCode) manuell, wo diese Umgebung fehlt.
Die Builds laufen dann, aber Tests können die notwendigen Bibliotheken zur Laufzeit nicht finden und schlagen fehl.

Hinweis: Kleine Projekte haben das Problem nicht, denn wenn alles lokal gebaut wird, sind die korrekten Pfade des Build-Prozesses in den Binaries selbst gespeichert. Doch wenn per CI fertige Komponenten auf den eigenen Conan-Remote hochgeladen wurden und das eigene Projekt diese herunterlädt, dann passt das Setup nicht mehr zusammen und PATH bzw. LD_LIBRARY_PATH werden zwingend erforderlich.

CONAN virtual run environment

Die Standard Lösung lautet: Erzeuge ein Run-Environment und starte die IDE oder den Build-Prozess aus diesem heraus.
Conan legt hierfür conanrun Scripts an, die man einfach vor dem Build oder der IDE starten muss:

Windows: CMake und Visual Code mit CONAN run environment

1cd myproject
2conan install .
3build\generators\conanrun.bat
4cmake --preset conan-debug
5cmake --build --preset conan-debug
6code .
7build\generators\deactivate_conanrun.bat

Linux: CMake und Visual Code mit CONAN run environment

1cd myproject
2conan install .
3source build/generators/conanrun.sh
4cmake --preset conan-debug
5cmake --build --preset conan-debug
6code .
7source build/generators/deactivate_conanrun.sh

CONAN und CMake generieren Environment und Launch Dateien

Das wiederholte manuelle Aufrufen von Scripts wird extrem mühsam, wenn man zwischen vielen Conan-Projekten hin und herwechseln muss.

Ich wollte daher eine Variante haben, in der jedes Projekt mit wenigen Zeilen in VSCode geladen werden kann, und zwar mit:

1cd myproject
2conan install .
3code .

Um jetzt das notwendige Environment zu “konservieren”, damit man es beim Debuggen benutzen kann, erzeuge ich in der Conan generate() Methode eine .env Datei im Build-Verzeichnis.
Da Windows und Linux etwas unterschiedlich sind, fällt der Code etwas größer aus und sieht etwa so aus:

 1# conanfile.py
 2
 3class myProject_ConanFile(ConanFile):
 4  ...
 5  def create_env_file(self, env_file_path: str):
 6    is_windows = self.settings.os == "Windows"
 7    path_name = "PATH"
 8    path_var = "%PATH%" if is_windows or "$PATH"
 9    lib_name = "LIB" if is_windows or "LD_LIBRARY_PATH"
10    lib_var = "%LIB%" if is_windows or "$LD_LIBRARY_PATH"
11
12    env_bin_paths = []
13    env_lib_paths = []
14
15    ## add conan dependencies to PATH and LIBS array
16    for dep in self.dependencies.values():
17      env_bin_paths.append(str(bin)) for bin in dep.cpp_info.bindirs
18      env_lib_paths.append(str(lib)) for lib in dep.cpp_info.libdirs
19
20    ## add current PATH entries
21    env_bin_paths.extend(os.getenv(path_name, "").split(os.pathsep))
22    env_lib_paths.extend(os.getenv(lib_name, "").split(os.pathsep))
23
24    ## remove empty entries
25    env_bin_paths = [e for e in env_bin_paths if e]
26    env_lib_paths = [e for e in env_lib_paths if e]
27
28    with open(env_file_path, "w") as f:
29      path_text = os.pathsep.join(env_bin_paths)
30      f.write("{}={}\n".format(path_name, path_text))
31      lib_text = os.pathsep.join(env_lib_paths)
32      f.write("{}={}\n".format(lib_name, lib_text))
33
34  def generate(self):
35    tc = CMakeToolchain(self)
36    tc.generate()
37
38    cmakedeps = CMakeDeps(self)
39    cmakedeps.generate()
40
41    if self.settings.build_type == "Debug":
42      env_file_path = os.path.join(self.build_folder, ".env")
43      self.create_env_file(env_file_path)
44  ...

Anschließend wird in den Launch-Jobs für VSCode die .env Datei referenziert und somit startet jede Debug-Target-Start bzw. jeder Debug-CTest-Start mit den Pfaden, die Conan in seinen Dependencies bereits aufgelöst hat.

 1// .vscode/launch.json
 2{
 3  "version": "0.2.0",
 4  "configurations": [
 5    {
 6      "name": "(gdb) CMake Target",
 7      "type": "cppdbg",
 8      "MIMode": "gdb",
 9      "request": "launch",
10      "program": "${command:cmake.launchTargetPath}",
11      "args": [],
12      "cwd": "${command:cmake.buildDirectory}",
13      "envFile": "${command:cmake.buildDirectory}/.env"
14    },
15    {
16      "name": "(gdb) CTest Launch",
17      "type": "cppdbg",
18      "MIMode": "gdb",
19      "request": "launch",
20      "program": "${cmake.testProgram}",
21      "args": [ "${cmake.testArgs}" ],
22      "cwd": "${cmake.testWorkingDirectory}",
23      "envFile": "${command:cmake.buildDirectory}/.env"
24    },
25    {
26      "name": "(msvc) CMake Target",
27      "type": "cppvsdbg",
28      "request": "launch",
29      "program": "${command:cmake.launchTargetPath}",
30      "args": [],
31      "cwd": "${command:cmake.buildDirectory}",
32      "envFile": "${command:cmake.buildDirectory}/.env"
33    },
34    {
35      "name": "(msvc) CTest Launch",
36      "type": "cppvsdbg",
37      "request": "launch",
38      "program": "${cmake.testProgram}",
39      "args": [ "${cmake.testArgs}" ],
40      "cwd": "${cmake.testWorkingDirectory}",
41      "envFile": "${command:cmake.buildDirectory}/.env"
42    }
43  ]
44}

Wer CTest direkt (also ohne VS-Code Debugger) startet, hat das gleiche Problem, doch hier kann man den Fix in CMake integrieren.
Die .env Datei wird gelesen und ihr Inhalt als Array dem CTest-Property ENVIRONMENT zugeordnet.

 1set(test_name "my_test")
 2set(test_command "${PROJECT_NAME}")
 3set(test_args)
 4
 5add_test(NAME ${test_name} COMMAND "${test_command}" ${test_args})
 6
 7if(EXISTS "${CMAKE_BINARY_DIR}/.env")
 8  file(READ "${CMAKE_BINARY_DIR}/.env" envfile_content)
 9
10  # The Windows "path1;path2" format needs to be escaped 
11  # to avoid conflicts with cmake's array ";" separation
12  string(REPLACE "\r" "" envfile_content "${envfile_content}")
13  string(REPLACE ";" "\\;" envfile_content "${envfile_content}")
14  string(REPLACE "\n" ";" envfile_entries "${envfile_content}")
15
16  set_property(TEST ${test_name} 
17    PROPERTY ENVIRONMENT "${envfile_entries}")
18endif()

Eine andere Option wäre dann noch Conan-Variablen in CMake zu nutzen, was ich aber nicht so gerne mache, schließlich soll CMake nicht von Conan abhängen.
Trotzdem helfen folgende Zeilen manchmal sehr:

1foreach(item ${CONAN_RUNTIME_LIB_DIRS})
2  list(APPEND path_patches "PATH=path_list_append:${item}")
3endforeach()
4
5set_property(TEST ${test_name} 
6  PROPERTY ENVIRONMENT_MODIFICATION ${path_patches})

Fazit

Ein Problem, viele Möglichkeiten, und unnötig viel Komplexität.

Diese Beispiele sind das Ergebnis einer Monate-langen Herumspielerei. Wir haben in der Firma 100+ Conan Projekte, die alle über eine gemeinsame Conan- und CMake- Bibliothek zusammenhängen.

So kann man sicherstellen, dass alle Projekte auf alle Fälle vorbereitet sind. Im Einzelfall sind diese “Patches” oft nicht notwendig, doch wenn viele Ebenen aufeinandertreffen, gibt es immer wieder mal Pfad-Probleme, die so zumindest umgangen werden können.

Ein Problem ist vor allem, dass jeder Developer anders arbeitet. Einer startet alles von der Konsole aus, einer nutzt Visual Studio und andere nehmen VSCode. Die Plattformen sind Windows, Linux, 32-bit und 64-bit für Debug und Release.

Es war echt mühsam immer wieder feststellen zu müssen, dass es genau in einer Variante hakte, während alle anderen liefen.

Aber das ist nun einmal unser Job: Nämlich alles zu meistern.

Motif Explorer

2024-11-17T12:00:00+01:00

Mit der Ausimplementierung von Treeview und Listview Controls mit dem antiken Motif Framework, kann ich jetzt auch meinen File-Browser im Unix-1990 Look-and-Feel schimmern lassen.

Für “einfache” Controls wie Buttons oder Textfelder gibt es im motif Toolkit recht selbst-erklärende WidgetClass Instanzen wie xmPushButtonWidgetClass oder xmTextWidgetClass.

Treeviews und Listviews, wie sie in Win32 seit über 30 Jahren heißen sind aber in der motif Welt zusammengesetzte Widgets und benötigen mehr Aufmerksamkeit um Ihre Entsprechungen zu finden und zusammenzunähen.

Treeviews

xmOutlineWidgetClass bzw. die Funktion XmCreateOutline() stellen uns einen Widget-Container bereit, der seine Kind-Elemente hierarchisch ordnen, sowie dynamisch ein- oder ausblenden kann.

Funfact: Visual Basic 4 hatte damals auch ein selbst-fabriziertes “Outline Control”, bevor mit Win95/NT3.5 das Win32 Treeview Control auf den 32-bit Plattformen eingeführt wurde.

Mit dem Resource-Argument XmNconnectNodes werden Hierarchielinien zu den Kindelementen gezeichnet und XmNindentSpace gibt an, um wie viele Pixel ein Kindelement eingerückt werden soll.

Will man jetzt ein Element einfügen, kann man einen beliebigen Widget erzeugen und diesem die Resource XmNparentNode mit einem Pointer zum Eltern-Widget mitgeben, oder eben NULL für ein Top-Level Element.
Die State-Resource XmNnodeState gibt an, ob die Kinder ausgeklappt sind (XmOpen) oder nicht (XmClosed).

Ich füge hier Push-Button-Widgets ohne sichtbaren Rahmen ein, die einen Click Callback bei mir aufrufen, womit ich den Ein/Ausklapp-Status wechseln kann. Der Text des Elements lässt sich wie üblich per XmNlabelString bearbeiten.

Und schon ist die Treeview-Alternative fertig.

Listview

Listviews (damit meine ich immer die “Detail” Ansicht) sind quasi Tabellen, also Datensatzlisten mit Zeilen und Spalten.

Nach langem erfolglosem Herumexperimentieren konnte ich von einer uralten motif-Demoanwendung lernen, dass sich das am Besten mit der xmContainerWidgetClass umsetzen lässt.
Dem kann man nämlich über XmNlayoutType die Eigenschaft XmDETAIL zuweisen und dann per XmNdetailColumnHeadingCount und XmNdetailColumnHeading die Column-Header definieren und benennen lassen.

Anschließend fügt man pro Zeile eine xmIconGadgetClass Instanz über XmCreateIconGadget() hinzu, bei der Eigenschaften wie XmNlabelString den Text der ersten Spalte definieren, und die restlichen per XmNdetail und XmNdetailCount als String-Array angefügt werden.
(Das ist ja in Win32 ganz ähnlich gelöst.)

Sogar Icons lassen sich mit XmNsmallIconPixmap und XmNsmallIconMask der Datenzeile voranstellen.

Fazit

In Summe ist das Zusammensetzen von Treeviews und Listviews gar nicht so unterschiedlich zu den Win32 Controls.
Das größte Problem liegt in der fehlenden Dokumentation, bzw. den fehlenden (oder schwer findbaren) Beispielen.

Man findet tausende Codezeilen im Netz, wenn man eine Explorer-Ansicht unter Windows selbst mit Win32 Controls ausprogrammieren kann.

Bei motif sehen wir nur lange Listen von Resource-Eigenschaften, aber wie diese zusammenarbeiten und wie man bestimmte Ergebnisse damit produzieren kann bleibt ein Geheimnis.

Funfact: KI ist dumm!

Da über motif wenig Code im Umlauf ist, sind die selbstherrlichen Large-Language-Models nicht in der Lage auch nur irgend etwas sinnvolles darüber herauszufinden.

Doch KIs kennen die Antwort: “Ich habe keine Ahnung!” eben nicht, und erfinden APIs, die nicht existieren und teilen selbstsicher mit, dass sie die Lösung gefunden hätten.

Es kostete mich viel Recherche-Zeit um festzustellen, dass jede zweite Funktion im generierten Code reine Phantasie war.

Merksatz:
Vertraue keiner KI,
denn wenn sie was nicht weiß, dann lügt sie.

Windows Server 2025

2024-11-10T12:00:00+01:00

Das neue Windows 11 24H2 muss natürlich auch als neuer Server herauskommen, der - wie üblich - ein Jahr vordatiert wird.

Früher oder später wird die Software auch bei mir produktiv laufen, aber zur Zeit darf sich mal ein Test-Board mit der neuen Windows Server 2025 Version abmühen.

Es ist ja nur mehr eine Frage der Zeit, bis meine alten ITX Boards mit Atom und Celeron J1xxx und J3xxx CPUs nicht mehr offiziell unterstützt werden.
Doch vorläufig bleiben sie nach wie vor meine “Test-Boards”, die übelst langsam arbeitend ganz deutlich aufzeigen, ob Software gut oder schlecht geschrieben ist.

Also startete ich das Setup Program von Server 2025 auf dem bereits laufenden Server 2022, der nur ein paar Test-VMs aufgesetzt hatte.

Upgrade erfolgreich

Dass eine Neuinstallation auf einem J3455 mit 1.5 GHz nicht in “blitzschnell” fertig sein wird, war klar.
Und so dauerte das Erfassen und Ersetzen der Installation die eine oder andere Stunde.

Doch nach einigen Neustarts und der Hardware-Neuerkennung inklusive Einrichtung fuhr der neue Server 2025 problemlos hoch.

Alle VMs waren noch vorhanden und konnten auch gestartet werden.

Alles wird größer und langsamer

Auch wenn die Installation nicht sonderlich angewachsen ist, das eine oder andere Gigabyte kommt hinzu und bleibt auch, selbst nach einem Aufräumvorgang.

Die Docker Nanoserver-Images zeigen das Wachstum am deutlichsten:

mcr.microsoft.com/windows/nanoserver:ltsc2019: 258 MB
mcr.microsoft.com/windows/nanoserver:ltsc2022: 292 MB
mcr.microsoft.com/windows/nanoserver:ltsc2025: 485 MB

Da kamen knapp 200 MB hinzu, doch ich wüsste jetzt nicht, dass da mehr für mich nützliche Tools hinzugekommen sind.

mcr.microsoft.com/windows/servercore:ltsc2022: 4.01 GB
mcr.microsoft.com/windows/servercore:ltsc2025: 7.67 GB

Und der Core hat sich auch fast verdoppelt!

In Summe ist auch die gesamte Reaktion des Systems zurückgegangen. Ja, es ist noch bedienbar, aber das Öffnen diverser Tools leitet immer wieder Wartezeiten ein.
Nun, das kennen wir schon von Windows 11 wo alleine der Explorer ein paar Sekunden zum Initialisieren braucht, was unter Windows 10 nur eine Sekunde dauerte.

Das “kleine” Anwachsen der Installation schlägt also auf der veralteten Hardware deutlich härter aus, auf modernen Systemen wird das vermutlich aber kaum merk- oder messbar sein.

Langzeit-Probleme

Nachdem ich die Installation des Servers abgehakt hatte und in Summe doch zufrieden war, vergaß ich die Maschine abzuschalten.

Als ich am Folgetag die ON-LED erblickte und eine Remote-Verbindung aufbauen wollte, konnte ich das System allerdings nicht mehr erreichen. Es war vermutlich eingefroren und konnte nicht mehr reaktiviert werden.

Nach einem Reset und Neustart überprüfte ich die Energieeinstellungen und stellte sicher, dass kein Sleep-Mechanismus aktiv war.

Doch leider wiederholte sich diese Art von Blockade immer wieder mal.

Es sieht so aus, also würde das System bei längerem Leerlauf irgendwann einfrieren.
Ob das jetzt ein Treiberproblem meiner alten Hardware ist, oder doch ein neues Sleep-Feature, das ich nicht kenne, weiß ich nicht.

Fazit

Tja … am Ende bin ich etwas unschlüssig. Zwar ist das Upgrade geglückt und alle Daten sind weiter verfügbar, doch das Einfrieren im Dauerbetrieb gefällt mir gar nicht.

Ich werde also warten müssen, bis ich den Server 2025 mal auf einer neueren Maschine ausrollen werde, bevor ich mir ein Urteil zutrauen kann.

TAB vs SPACE beim Dokumentieren

2024-11-03T12:00:00+01:00

Die Debatte über TABs vs SPACEs ist uralt und wird genau so bissig geführt, wie die Frage welcher Gott der richtige ist.

Und nun erschüttert ausgerechnet Doxygen mein Weltbild.

Ich verwende TABs. Schon immer.
Deshalb muss es richtig sein.

Dass wir gerade in “alten” Umgebungen häufig Tabs finden ist vermutlich der Tatsache geschuldet, dass alte Editoren in DOS und Windows vor 30 Jahren keine automatischen Einrückungen für uns gemacht haben und man selbst die nötigen Tasten drücken musste.

Mit TAB war es eben ein Tastendruck “pro Ebene”, die man einrücken wollte und damit hoch effizient.
Ich hätte vermutlich durchgedreht, wenn ich bei jeder Basic-Zeile in einem IF Block immer 4 mal auf SPACE hätte hauen müssen.

(Zugegeben, in Basic waren Einrückungen selten … obwohl QBASIC bereits damals mit seinen SUBs damit anfing.)

Neulich fiel mir auf, dass die automatisch generierte Tooltip-Anzeige mit Funktionsparametern in Visual Studio Code bei meinen Funktionen nicht immer korrekt arbeitete.

Der Text

1/**
2 * @brief This is my function
3 * @param[in] a         the first value
4 * @param[in] something the second value
5 */
6void my_func(int a, int something);

wird absolut korrekt angezeigt, wenn nur SPACEs eingesetzt werden.

Ich nutzte aber nach dem Parameter oft TAB zur Trennung von Parametername und Beschreibung, damit die Beschreibungen “schön” untereinander standen.

Hier verband VSCode den Namen und das erste Wort der Beschreibung zu einem Block und formatierte seine Anzeige entsprechend.

Das ganze ist zwar kein Drama, man kann immer noch alles lesen, doch es zeigt mir auf: Doxygen-Code-Parser wollen SPACEs und haben mit TABs kleine Problemchen.

Fazit

Ich werde das GATE Framework jetzt nicht sofort umschreiben … doch neue Dokus und auch neue Projekte werden in Zukunft mehr SPACE lastig sein.

Ein Kollege meinte mal:

Es gibt Studien, die belegen, dass Programmierer, die SPACE einsetzten, mehr Geld verdienen.

Nun … wie seriös das auch sein mag, es kann nicht schaden dem Trend zu folgen.
Und der baut eben auf der Leertaste auf.

Zum Glück gibt uns VSCode in seiner settings.json die Möglichkeit Tabs entweder zu erzwingen oder durch SPACEs zu ersetzten. Und man kann das für jeden Dateityp auch justieren:

 1{
 2  // global
 3  "editor.tabSize": 4,
 4  "editor.insertSpaces": true,
 5
 6  // individual
 7  "[cmake]": {
 8    "editor.tabSize": 2,
 9    "editor.insertSpaces": true
10  }
11}

Pipe-streaming

2024-10-27T12:00:00+01:00

Individuelle Technologien brauchen individuelle APIs. Doch, wenn es möglich ist, unterschiedliche Technologien unter eine API zu stellen, dann entstehen ungeahnte Möglichkeiten.

Und das gilt auch für Pipes.

Während unter Unix alles eine Datei ist, führt Windows zusätzliche APIs ein, wenn man mit Pipes arbeiten möchte.
Um diese Individualitäten auszugleichen, habe ich neben der gate_pipe Abstraktion nun auch den Pipestream eingeführt, doch wie sich zeigt, gibt es da einige Tücken, auf die man achten muss.

Blockaden und Fehler

Pipes verhalten sich sowohl unter Windows und Linux recht seltsam, wenn sie geschlossen werden, fehlerhaft sind oder gerade nichts anzubieten haben.

Ein read oder write an einem Ende erfordert entweder ein write / read auf der anderen Seite, oder die Funktion blockiert … außer man hat Puffer aktiviert, wo dann ein paar Bytes ohne Blockaden geschrieben werden, ohne dass sie sofort gelesen werden müssen.

Schlimmer ist das Schließen von Pipes, die dann entweder per Signal, oder speziellem Fehlercode die Gegenseite abbrechen lassen.

Da Lesefunktionen quasi für immer blockieren können, ist neben dem klassischen Lesen und Schreiben auch noch eine is_data_available() Funktion notwendig. So kann ein Programm den aktuellen Status prüfen und im Falle eines Leerlaufes etwas anderes tun.

Bei Prozessen, die über “Named Pipes” kommunizieren, ist das besonders wichtig, denn nur so kann man feststellen, ob ein Prozess noch läuft, auf dessen Daten man per Pipe wartet.

Win32 Implementierung

CreatePipe() schafft zwei Enden einer anonymen Pipe. Interessanter sind aber benannte Pipes, die mit CreateNamedPipe() angelegt werden. Sie müssen im Namensraum \\.\Pipe\ liegen und eindeutig sein, z.B.:
\\.\Pipe\my_named_pipe.
Danach kann dieser Pfad beliebig oft mit CreateFile() zum Lesen oder Schreiben geöffnet werden.

Ob Daten zum Lesen verfügbar sind, ermittelt PeekNamedPipe().
Tatsächlich gelesen wird mit ReadFile(), wobei im Fehlerfall ein ERROR_BROKEN_PIPE einem “End-of-stream” entspricht.

Geschrieben werden Daten wie bei Dateien mit WriteFile().

POSIX Implementierung

pipe() erzeugt anonyme Pipes, aber nur mkfifo() lässt uns eine benannte Pipe anlegen. Einmal angelegt kann diese Pipe dann mit open() zum Lesen oder Schreiben geöffnet werden.

Leseaktivitäten lassen sich wie bei Sockets mit select() feststellen.

Zum Lesen und Schreiben sind wie bei Dateien einfach read() und write() zu benutzen. Doch bei write() muss auch auf das Signal SIGPIPE beachtet werden, denn dieses wird gesendet, wenn die Pipe bereits geschlossen ist, während ein write() ausgeführt wird.
Vergisst man darauf, wird der eigene Prozess vom Signal-Händler gekillt.

Auf den Namen kommt es an

Unter Windows gibt es bestimmte Konventionen, wie ein Pipe-Name aussehen soll. Unter Linux muss der Pipe-Pfad ein beliebiger gültiger Dateisystempfad sein, denn genau dort wird die Pipe angelegt.

Um plattformunabhängig zu sein, erstellt das GATE-Framework einen zufälligen, aber eindeutigen Namen bei jedem Erzeugungsaufruf.
Eben diesen Namen kann man dann auch für die Gegenseite benutzen.

Vererbung

Und am Ende braucht man auch noch eine Möglichkeit eine Pipe per “ID” an ein Kind zu vererben. Hierzu wird das Pipe-Handle bzw. der File-Deskriptor dupliziert und sichergestellt, dass er an Kindprozesse vererbt werden kann.
Unter Windows geschieht dies mit DuplicateHandle() mit dem bInheritHandle Parameter und in POSIX-Umgebungen, wo grundsätzlich alles vererbt werden kann, muss das Duplikat vom automatischen Schließen beim fork()/exec() ausgenommen werden.

Fazit

Pipes … diese Dinge erscheinen so einfach und klein, haben mir aber durch ihre unterschiedlichen Eigenschaften auf jeder Plattform jede Menge Steine in den Weg gelegt, als ich eine einheitliche Schnittstelle für die Arbeit mit ihnen aufsetzen wollte.

Zumindest ist jetzt mal ein Prototyp im GATE Framework etabliert. Doch bis dieser in allen Details eingesetzt und getestet werden kann, wird wohl noch etwas Zeit vergehen.

Ninja-Build für VSCode

2024-10-20T13:00:00+02:00

Ohne die explizite Angabe eines “Generators” wählt CMake das nächst beste auf der Plattform. Doch wenn man ein Projekt auf mehreren Plattformen entwickelt und nicht immer mehrere Konfigurationen haben will, dann kann Ninja-Build die Lösung sein.

Und sau-schnell ist das Tool noch obendrein.

Ich finde es grundsätzlich gut, dass CMake das Standard-Buildsystem der Umgebung benutzt. Das wäre MSBUILD auf Windows und Unix Makefiles auf Linux oder BSD.

Wenn man aber in Tests oder Debugsitzungen Pfade benötigt (also Workingdirectory oder Pfad zur EXE oder Projektunterverzeichnisse mit Daten), dann gibt es einen gravierenden Unterschied zwischen MSBUILD und den meisten anderen Systemen:
MSBUILD erzeugt immer Debug und Release Konfigurationen inklusive deren Unterverzeichnisse. Ein Ausgabeverzeichnis für Builds wäre unter Linux
build/out/ und unter Windows
build/out/Debug oder build/out/Release.

Diese “Kleinigkeit” kann sehr schnell lästig werden, wenn man etwa für Tests oder das Kopieren von Bibliotheken immer ein
if(WIN32) ... else() benötigt.

Lösung: Ninja

Konfiguriert man CMake für Ninja, entsteht im Build-Verzeichnis immer eine build.ninja Datei mit allen Instruktionen und das Tool ninja startet dann Compiler und Linker ohne MSBUILD oder make.
Hier gibt es dann auch keine Debug und Release Ordnern womit die Builds auf allen Plattformen das gleich Layout bekommen.

Unter Linux ist ninja meist als ninja-build im Paketsystem.

1apt-get install ninja-build

und Windows stellt es per winget bereit

1winget install --id=Ninja-build.Ninja

Allerdings kann man auch auf die Webseite ninja-build.org gehen und die EXE manuell herunterladen, in ein beliebiges Verzeichnis packen und dann dieses Verzeichnis in den PATH aufnehmen.

VSCode Ninja Konfiguration

Auf der Konsole würde ein cmake -G Ninja .... reichen, um vom Standard-Build zu Ninja zu wechseln.
In VSCode kann man den Ninja-Zwang per .vscode/settings.json bewirken:

 1/// .vscode/settings.json
 2{
 3  "cmake.configureOnOpen": false,
 4  "cmake.configureOnEdit": false,
 5  "cmake.generator": "Ninja",
 6  "cmake.buildDirectory": "${workspaceFolder}/build/ninja",
 7  "cmake.sourceDirectory": "${workspaceFolder}",
 8  "cmake.configureSettings": {
 9    "MY_CMAKE_OPTION": true
10  }
11}

Die Einstellung cmake.generator erzwingt nun bei jedem Aufruf ninja als Generator. Zusätzlich kann man das cmake.buildDirectory auf einen eigenen Wert setzen, wenn einem der Standard ${workspaceFolder}/build nicht gefällt.

Ich benutze und teste ja unterschiedliche Buildsysteme und lasse daher für jede Variante in build/ noch ein zusätzliches Unterverzeichnis anlegen.

Fazit

Ninja ist nicht nur plattformunabhängig sondern auch schnell. Ich würde zwar nicht sagen, dass die Builds doppelt so schnell sind, aber etwas Ersparnis gegenüber MSBUILD und make scheint drinnen zu sein.

Ninja ist daher in meinen VSCode-Debugging-Sessions immer mit dabei.

Einzig, wenn man Spezialanforderungen hat, (etwa C++/CLI) oder andere Systeme wie Conan, dann ziehe ich den OS-Standard einem Ninja-Build vor, nur um sicher zu stellen, dass wir garantiert das richtige Ergebnis bekommen.

CMake Launch durch VSCode

2024-10-13T13:00:00+02:00

Das CMake Plugin in Visual Studio Code ist echt genial zum Bauen von Quellcodes.
Aber die Ausführung im Debugger kommt nicht ohne Konfiguration und ein paar Sonderfälle aus.

Eigentlich lag meine zögerliche Migration von Visual Studio zu VSCode nur an einer Sache: die fehlende CMake-Integration.
Folglich ist dessen Setup vermutlich der wichtigste Schritt in einem modernen Projekt.

Visual Studio Solutions haben den Vorteil, dass sie einem ein vollständiges Debugging-Environment zur Verfügung stellen.
Ich schreibe Code, setzte per Maus einen Breakpoint, drücke F5 und beobachte den Programmablauf.
Braucht ein Programm Kommandozeilenparameter, werden die in den Projekteigenschaften einfach angegeben, dann F5 und alles läuft.

VSCode kennt nur Quelldateien, die es editieren kann. Alles andere muss von Plugins übernommen und über JSON Dateien konfiguriert werden.

CMake Targets starten

Hat man Microsoft’s CMake-Plugin installiert lässt einem der CMake-Tab im Menü folgendes einstellen:

Configure
- Auswahl der Build-Tools (also MSVC x64, oder GCC ARM64)
- Auswahl für Debug oder Release Builds
- Starten des CMake-Configure Schrittes zum Erzeugen aller notwendigen Build-Scripts
Build
- Auswahl entweder eines bestimmten CMake-Targets zum Bauen oder Auswahl von “allen” Targets.
- Starten das Bauens des Projektes für das ausgewählte Target oder alle Targets
Debug
- Auswahl eines Targets, das im Debugger gestartet werden soll
- Start einer Debug-Sitzung.

Nur leider braucht man für das Debuggen immer eine Konfiguration, und die muss vorher erst mal angelegt werden. Wir brauchen für jeden unterstützten Debugger einen Launch Eintrag.

CMake Debug Launch in VSCode

Ein Code sagt mehr als tausend Worte.

Meine .vscode/launch.json Datei sieht in etwas so aus:

 1// .vscode/launch.json
 2{
 3  "version": "0.2.0",
 4  "configurations": [
 5    {
 6      "name": "(gdb) CMake Launch",
 7      "type": "cppdbg",
 8      "request": "launch",
 9      "program": "${command:cmake.launchTargetPath}",
10      "args": [],
11      "cwd": "${workspaceFolder}",
12      "MIMode": "gdb",
13      "setupCommands": [
14        {
15          "description": "Enable pretty-printing for gdb",
16          "text": "-enable-pretty-printing",
17          "ignoreFailures": true
18        }
19      ]
20    },
21    {
22      "name": "(msvc) CMake Launch",
23      "type": "cppvsdbg",
24      "request": "launch",
25      "program": "${command:cmake.launchTargetPath}",
26      "args": [],
27      "cwd": "${workspaceFolder}"
28    }
29  ]
30}

Da ich ja immer zwischen Windows und Linux hin- und her wechsle, sind ein MSVC und GCC Debug-Launcher konfiguriert.

Die magische Zeile lautet auf:
"program": "${command:cmake.launchTargetPath}"
Denn die sorgt dafür, dass in einer Debug-Sitzung genau das Programm gestartet wird, das mit dem aktuell unter Debug eingetragenen CMake Target eingestellt ist.

Da MSVC und GDB unterschiedliche Plugins nutzen, sind auch die Konfigurationen verschieden aber großteils selbsterklärend.

Im Feld args lässt uns Kommandozeilenparameter für das zu startende Programm angeben, allerdings gibt es eben nur diesen einen Eintrag. In Visual Studio könnte man für jedes Projekt eigene Werte eintragen, hier können wir aber nur “den nächsten Lauf” konfigurieren.

Beim Starten der Debug-Sitzung erscheint ein Popup, welches einem immer die beiden Launcher zur Auswahl stellt. Man muss eben selbst wissen, ob man unter MSVC/WinDebug oder GCC/GDB debug-t.

CTest

Noch komplizierter wird das ganze bei CTest. Hat man nämlich Tests definiert, kann man diese im Test-Fenster auch mit einer Debug-Session starten.

Hier braucht man wieder zwei weitere Launcher:

 1{
 2  "version": "0.2.0",
 3  "configurations": [
 4  /// CMake Launch entries from above
 5    {
 6      "name": "(gdb) CTest Launch",
 7      "type": "cppdbg",
 8      "request": "launch",
 9      "cwd": "${cmake.testWorkingDirectory}",
10      "program": "${cmake.testProgram}",
11      "args": [ "${cmake.testArgs}"],
12    },
13    {
14      "name": "(msvc) CTest Launch",
15      "type": "cppvsdbg",
16      "request": "launch",
17      "cwd": "${cmake.testWorkingDirectory}",
18      "program": "${cmake.testProgram}",
19      "args": [ "${cmake.testArgs}"],
20    }
21  ]
22}

Die Token cmake.testProgram und cmake.testArgs sorgen dafür, dass das Testprogramm genau so gestartet wird, wie es in CMake beschrieben wurde.

Fazit

Mit den CMake-Launch und CTest-Launch Einträgen kann ich also das gesamte GATE Projekt auf jeder unterstützten Plattform debuggen. Gesetzte Breakpoints werden der gewählten Debug-Session übergeben und nun kann man in VSCode fast genau so schön arbeiten wie unter Visual Studio selbst.

Der große Vorteil liegt in der Plattformunabhängigkeit. Einziger Nachteil ist die etwas mühsamere Verwaltung über JSON Dateien.

Leider gibt es bei komplexeren Systemen mit Abhängigkeiten auch wieder ein paar Probleme.
z.B. mit Conan.
Aber das ist eine andere Geschichte.

6 Jahre Bloggerei

2024-10-06T13:00:00+02:00

Wieder ein Jahr vorbei und 2018 liegt wieder etwas weiter in der Vergangenheit.

Und ich habe weiter keine Chance auf Frühpensionierung …

Beruflich wie privat ging es im letzten Jahr recht intensiv zu. Und wenn man zu viel zu tun hat, reduziert sich die “freiwillige” Schreibarbeit automatisch.

Wöchentlich 2 Posts zu schreiben war mir zu viel, wodurch sich der Durchsatz auf die Hälfte reduziert hat. Das ist auch der Tatsache geschuldet, dass ich viele Themen, die sich am Anfang des Blogs aufgestaut hatten jetzt abgeflossen sind und somit nur noch richtige “Tagesthemen” übrigbleiben.

Code Statistik

Das GATE Projekt besteht aktuell aus etwa 292 000 Zeilen rein von mir geschriebenem Code.
Um etwas anzugeben: Bei einer Norm-A4-Seite mit 30 Zeilen wären das über 9700 Buchseiten. So erklärt sich mir wie Thomas Brezina in meiner Kindheit 100 Bücher zur Knickerbockerbande schreiben konnte, wo ein Buch etwa 120 Seiten hatte.

Mein größtes kommerzielles C++ Projekt, an dem ich 8 Jahre gearbeitet hatte, kam auf etwa 475 000 Zeilen C/C++ Code.

In absoluten Zahlen mit “beigelegten” (und teilweise überarbeiteten) Fremdcode kommt das GATE Framework auf 1 074 000 Zeilen (Tja SSL und SQLite hauen eben ordentlich rein). Doch mein früheres Projekt endete mit 971 000 Zeilen, was das GATE Framework nun zu meinen größten selbst verwalteten C/C++Projekt macht.

Wenn man bedenkt, dass das ein Freizeit-Abend-Projekt ist, kann sich das schon sehen lassen.

Buildsystem vs Code

Heute ist das automatische Bauen von Projekten, genannt CI/CD oder Continuous Integration / Continous Delivery ein Hauptbestandteil der Softwareentwicklung. Ich sitze also immer länger über Build-Scripts und an dem Hinzufügen neuer Plattformen, als am Schreiben von Protokollen, Formaten oder Infrastruktur … leider.

Wenn ich mich an meine erstes Projekt erinnere, wo die 32-Bit Windows .exe am Nachbar-PC gebaut und gleich so auf den Webspace hochgeladen wurde, läuft die Welt heute ganz anders.
Ohne einen Build-Server, der Windows, Linux für je 3 CPU Architekturen baut, gibt es kein Deployment. Die automatische Ausführung von Unit-Tests ist ebenso Teil dieses Prozesses, wie das Erstellen von Installationspaketen.

Fazit

Somit verschiebt sich auch der Fokus im Blog von reinem Code etwas in Richtung Buildserver, aber das schadet sicher nicht.

Und wenn wieder mal eine neue Technik wie eine Sau durchs Dorf getrieben wird, bleibt sie auch mir nicht erspart und wird früher oder später integriert.

Die Herausforderung geht als weiter.
Mal sehen, was im Jahr 2026 dann alles passieren wird.

UCONTEXT Puffergröße

2024-09-29T13:00:00+02:00

Meine Tests liefen alle super am PC. Doch unter ARM64 krachte es gehörig.

Sieht so aus, als wären (wieder mal) die Koroutinen Schuld.

Aber warum?

Im GATE Projekt herrscht in den öffentlich Headern striktes Include-Verbot für System-spezifische Header.
Bibliotheken wie boost versauen einem schon alleine wegen ihrer Includes von windows.h und unter Linux von allen Posix-, Netzwerk und Kernel-Headern ein performantes Ergebnis.

Doch … wie kann man eine öffentliche Datenstruktur schaffen, die systemspezifische Typen wie jmp_buf oder ucontext beinhaltet ohne dass die Typen definiert sind?

Ein Antwort wären Heap-Allokationen … doch diese fragmentieren den Speicher und erfordern ein zusätzliches Aufräum-Management.

Die Alternative sind Puffer, die als kleinster gemeinsamer Nenner aller möglichen Puffergrößen entsprechend groß sind um “alles” fressen zu können.

Mit der Strategie bin ich bisher gut gefahren, bis sie mich neulich in den Arsch biss.

ARM64 Stack-Status

Ich messe Puffer für native Datenstrukturen gerne in void* Einheiten. Hat eine Struktur 5 Member, sind die selten größer als 5 Pointer, und mit dem Doppelten kann die Obergrenze nicht überschritten werden … so der Gedanke.

Bei meinen X86 Systemen kam ich vermutlich bei der Durchsicht der System- Header auf den Wert 64 und legte damit fest, dass ein Stack-Kontext nie größer als 512 Bytes (bei 64-bit: 8 Bytes * 64 Einheiten) sein wird. Kein Prozessor hat mehr als 32 Register … also warum Speicher verschwenden.

Tja … ARM64 sprengt diese Grenze vielfach, und damit auch alle meine Prozesse mit Koroutinen-Code.
Wer in /usr/include/aarch64-linux-gnu/sys/ucontext.h nachsieht, stellt fest, dass neben den CPU-Registern noch 4 KByte für FP/SIMD Zustände reserviert werden.

Und genau hier haben die ucontext Funktionen in meinen viel zu kleinen Puffer Daten im anliegenden Speicher auf dem Stack überschrieben.

Neue Größenordnung

Die neue Implementierung geht von 1 KByte für “übliche” Prozessoren aus, sowie 4.5 KByte für ARM64. Ab sofort kann für jede Architektur ein Makro gesetzt werden, dass die interne Puffergröße anpasst.

Kaum war der Patch implementiert, liefen auch wieder alle Tests auf der ARM64 Plattform problemlos durch.

Fazit

4.5 KByte … W-T-F ?

Tja, hier merkt man, dass ich ein Kind der 90er Jahre bin. Das Speichern aller CPU-Zustände ging sich damals in wenigen Bytes aus. 64 Bytes waren da schon “viel”.

Doch heute ist ein Prozessor das, was früher 8 unterschiedliche Prozessoren waren. Kein Wunder also, dass Linux “zur Sicherheit” gleich mehrere Kilobyte reserviert.

Also Augen auf bei neuen Plattformen!
Wie viele Bytes mögen die wohl für einen Kontextstatus brauchen?

CONAN Builds mit CTest

2024-09-22T13:00:00+02:00

Tests gehören zum Build-Vorgang fix dazu. Besonders wenn daraus ein Conan Paket werden soll.

Es macht also Sinn einen CTest Lauf nach jedem CMake-Build auszuführen.

Einer der größeren Fehler, die mir und meinen Kollegen beruflich passiert ist, war die fälschliche Nutzung von Conan Test-Packages für Unit-Tests.
Test-Packages sind (wie in der Doku beschreiben) nur dafür da, die Pakete und ihren Inhalt auf Anwesenheit zu testen, und nicht um komplexe interne Funktionstests auszuführen.

Hier wurde viel herumgescriptet um im Endeffekt eine suboptimale Testreihe auszuführen.
Die Lösung wäre so nahe gelegen … aber wir konnten sie alle nicht sehen: cmake bzw ctest

CTest

Der größte Vorteil von CTest ist, dass sich Tests als Targets in den CMake Baum einfügen, eine von außen abrufbare Schnittstelle haben und daher von IDEs direkt oder indirekt unterstützt werden.

Ein Test ist in C/C++ in der Regel ein eigener Prozess, der mitgebaut wird, aber nicht per cmake --install weiterverteilt wird. Jedoch kann er durch den Aufruf von ctest im Build-Verzeichnis ausgeführt werden und sein Ergebnis wird per Exit-Code als Erfolg oder Misserfolg in einen Bericht eingefügt.

So entstehen JUnit XML Dateien, die wiederum das Test-Ergebnis an Kontrollsysteme melden können.

Tests werden aktiviert, wenn man in der Haupt-CMakeLists.txt-Datei die Zeilen

1include(CTest)
2enable_testing()

einfügt.
Für jedes Testprogramm ist dann noch ein eigenes Target notwendig, das als Test registriert wird:

1project(mytest)
2
3file(GLOB my_sources "*.h" "*.c" "*.cpp")
4add_executable(${PROJECT_NAME} ${my_sources})
5
6add_test(NAME ${PROJECT_NAME} COMMAND ${PROJECT_NAME})

Idealerweise nutzt man dann noch ein fertiges Test-Framework wie boost::test oder Google gtest, welch per Standard den Exit-Code auf 0 oder !=0 im Erfolgs- und Fehlerfall setzen.

Das CONAN-Dependency-Problem

Tja, und wenn man jetzt sein CONAN-Paket erstellt, sieht der Build+Test Vorgang etwa so aus:

1def build(self):
2  cmake = CMake(self)
3  cmake.configure()
4  cmake.build()
5  cmake.ctest()

Das bedeutet, dass in einem conan create oder conan build Prozess auch alles funktioniert, da CONAN hier die Umgebungsvariablen so setzt, dass Abhängigkeiten im CONAN-Cache per PATH oder LD_LIBRARY_PATH gefunden werden.

Doch wer nur conan install einsetzt und dann seinen Code z.B. in Visual Studio Code ausführen und debuggen will, dem fehlen nun diverse .dll/.so Pfade.
Bibliotheken die direkt gelinkt werden haben noch eine “gute Chance” gefunden zu werden, aber alles was zur Laufzeit geladen wird wie z.B. Plugins oder optionale Komponenten finden mit LoadLibrary() oder dl_open() ihr Ziel im Conan Cache nicht.

Meine Lösung für dieses Problem war die Erzeugung einer .env Environment Datei, die mit allen Pfaden von bekannten Abhängigkeiten befüllt war. Eine solche Datei konnte dann auch in CMakeLists.txt der Test-Ausführung zugeführt werden um somit die Tests mit dem vollständigen Environment auszuführen.

 1def gen_env_file_with_conan_deps(self, envfile_path: str):
 2  # init with system-defined values
 3  all_bin_paths = os.getenv('PATH', '').split(os.pathsep)
 4  all_lib_paths = os.getenv('LD_LIBRARY_PATH', '').split(os.pathsep)
 5
 6  # add conan dependencies
 7  for dep in self.dependencies.values():
 8    for lib in dep.cpp_info.libdirs:
 9      add_lib_paths.append(str(lib))
10    for bin in dep.cpp_info.bindirs:
11       add_bin_paths.append(str(bin))
12
13  with open(envfile_path, 'w') as f:
14    f.write('PATH={}'.format( os.pathsep.join(add_bin_paths)))
15    f.write('LD_LIBRARY_PATH={}'.format( os.pathsep.join(add_bin_paths)))

Wird diese Methode von Conan’s generate() Methode aus mit
self.gen_env_file_with_conan_deps(os.path.join(self.build_folder, '.env'))
aufgerufen, dann kann diese Datei von Visual-Studio-Code Launch-tasks benutzt oder von CMake ausgelesen werden und mit ein paar Hacks als ENVIRONMENT Eigenschaft des Tests gesetzt werden:

1if(EXISTS "${CMAKE_BINARY_DIR}/.env")
2  file(READ "${CMAKE_BINARY_DIR}/.env" envfile_content)
3  string(REPLACE "\r" "" envfile_content "${envfile_content}")
4  string(REPLACE ";" "\\;" envfile_content "${envfile_content}")
5  string(REPLACE "\n" ";" envfile_entries "${envfile_content}")
6  set_property(TEST ${PROJECT_NAME} PROPERTY ENVIRONMENT "${envfile_entries}")
7endif()

Fazit

Tests sind super, Tests sind gut … aber können bei erhöhter Komplexität auch anstrengend werden.

Ein grobes Problem mit Conan-Builds ist, dass Tests innerhalb der Conan Umgebung immer anders laufen, als während der Entwicklung innerhalb einer IDE.
Und CMake kennt in erster Line nur Build-Details, jedoch keine erweiterten Umgebungs- und Ausführungsparameter.

Tja, so ist das Leben.
Aber es wäre ja langweilig, wenn immer gleich alles auf Anhieb funktioniert.

CMake ALIAS target

2024-09-15T13:00:00+02:00

Wie soll man CMake-Targets eigentlich benennen?

Die Autoren haben “Vorstellungen”, Conan hat “Alternativen” und ich habe meine eigenen Wünsche.

Doch zum Glück lassen sich solche Namen in CMake leicht nachbessern.

Da meine GATE Builds auch mit antiken DOS-Compilern wie OpenWatcom zurecht kommen müssen und deshalb erweiterte Einstellungen notwendig sind, habe ich in den extlibs den Buildvorgang einiger Bibliotheken anpassen bzw. selbst ausimplementieren müssen.

Damit am Ende alles mit CMake läuft, habe ich mir auch ein paar “Target-Namen” einfallen lassen, die vom Original abwichen.

Die zlib ist hier ein etwas seltsames Beispiel, weil sie für Windows und Linux unterschiedliche Bibliotheksnamen vorsieht (zlib und libz, bzw. nur z als Target)

Conan hingegen stülpt über alle Projekte den neuen Standard für Target-Namen drüber, und geht von ZLIB::ZLIB aus.

Da das GATE Projekt sowohl mit der Eigenlösung, als auch mit Conan Varianten zurecht kommen soll, hatte ich ursprünglich jede Menge an if() else() Zeilen im CMake Code.

add_library(ALIAS)

Die Sache lässt sich aber viel einfacher lösen. Anstatt beim Linken auszu-if-fen, ob Target-Name 1 oder 2 gewählt werden soll, füge ich beim Importieren der gewünschten Quellen gleich einen Alias-Namen ein, der alle Implementierungen auf den gleichen Namen umleitet, nämlich den von Conan.

Und so findet man im GATE CMakeLists.txt Passagen wie:

1if(GATE_EXTLIB_ZLIB)
2  if(GATE_HAS_EXTLIB_ZLIB AND NOT GATE_NO_LOCAL_EXTLIB_BUILDS)
3    add_subdirectory("${EXTLIBS_ROOT_PATH}/zlib" "extlibs/zlib")
4    add_library(ZLIB::ZLIB ALIAS "zlib")
5  else()
6    find_package(ZLIB REQUIRED)
7  endif()
8endif(GATE_EXTLIB_ZLIB)

Hier wird dann entweder “mein” lokaler Name auf das gesetzt, was Conan ansonsten erzeugen würde, oder ich benutzte find_package() und erwarte von Anfang an das, was Conan liefert.

Fazit

Die Alias Variante ist somit viel eleganter und vereinfacht den Code im CMake Projekt.

Parallel sollte man nicht vergessen, dass auch der von Conan publizierte Name im Endeffekt ein Alias auf einen internen Build-Namen ist.

Wie auch immer … Conan sollte heute “der” Standard sein, wie Bibliotheken benannt sind, damit wir endlich einheitlich mit C oder C++ programmieren können.

Windows CE Builds im Docker Container

2024-09-08T13:00:00+02:00

Bisher waren für meine Windows CE Experimente immer eine Windows-XP VM mit Visual Studio 2005 notwendig, wo ich per Build-Script einen elend langen Build-Prozess anstarten musste.

Doch neulich fand ich eine GCC Variante, die WinCE-Binaries bauen konnte, und zwar im Linux Docker Container.

Im Github Account enlyze befindet sich still und heimlich die Lösung all meiner Windows-CE Probleme.
Nämlich ein Linux Docker Image mit einer speziellen GCC Variante, die Windows-CE Binaries bauen kann.

Ich habe mir hierfür das Image angepasst und als neues Build-Tag in mein OpenGATE Repository aufgenommen:
hub.docker.com/r/opendockergate/gate-build-env/tags deb.12.cegcc.arm.9.3.1

Dem Image wurde nur git, cmake, nodejs und ein paar Zusatztools hinzugefügt, die zum Bauen unter Forgejo notwendig sind.

Für CMake wurde dem GATE Projekt eine neue Toolchain-Datei hinzugefügt:

 1set(CMAKE_SYSTEM_NAME "WindowsCE")
 2set(CMAKE_SYSTEM_PROCESSOR "arm")
 3set(TOOLCHAIN_PREFIX "arm-mingw32ce")
 4
 5set(CMAKE_C_COMPILER "${TOOLCHAIN_PREFIX}-gcc")
 6set(CMAKE_CXX_COMPILER "${TOOLCHAIN_PREFIX}-g++")
 7
 8set(CMAKE_CROSSCOMPILING TRUE)
 9
10set(MINGW TRUE)
11set(CMAKE_FIND_ROOT_PATH "/opt/cegcc-arm" "/opt/cegcc-arm/arm-mingw32ce")
12set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
13set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
14set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)

Beim Bauen werden so die richtigen Compiler Tools im Docker Container gefunden.

Unterschiede zum MSVC

Tatsächlich brauchte es jede Menge Tests und Anpassungen am Sourcecode und am Buildsystem, bis die ersten Binaries erfolgreich gebaut werden konnten.

Unter MSVC fehlen große Bestandteile der C-Standard-Bibliothek, welche durch meine eigene Implementierung ersetzt wurden. Doch im GCC sind einige dieser Funktionen oder Makros vorhanden, und so musste ich diese Spezialfälle in meiner stdcpatches Bibliothek anpassen.

Früher war ein if(WINCE) gleichbedeutend mit einem if(MSVC), doch nun gibt es die feine Unterscheidung:

1if(WINCE)
2  if(MSVC)
3    # VS2005 patches
4  else()
5    # GCC-WinCE patches
6  endif()
7endif()

Fazit

Am Ende gelang das Experiment und ab sofort erzeugt jeder Commit ins Codeberg GATE Repository auch einen GCC Windows CE Build.

Tatsächlich existiert auch ein i386 Output, den ich aber nie testen konnte. Den handelsüblichen ARM Output habe ich jedoch auf meinen WinCE-Laptop erfolgreich ausgeführt.

An dieser Stelle kann ich wieder nur betonen:

Es ist unglaublich, was wir heute mit Linux und dem GCC erreichen können.
Niemand hätte sich im Jahr 2000 vorstellen können, dass einmal sämtliche Windows Build von Linux-Maschinen kommen würden.
… am wenigsten Steve Ballmer.

Codeberg's Wiki via Markdown

2024-09-01T13:00:00+02:00

Codeberg’s aufgemotztes Gitea UI stellt allen Nutzern ein besonders GIT Repository bereit:
Das Wiki-Repo.

Und mit ein paar Markdown Dateien bildet sich automatisch eine ganze Wiki-Seite im eigenen Projekt-Bereich.

Lange Zeit spielte ich mit Jekyll herum um parallel zu den Postings auch spezielle Seiten verwalten zu können. Im Blog sind das die Suche und alles, was im Bereich Dokus und Infos zu finden ist.

Auf der Projekt-Hautseite wollte ich ursprünglich ein paar konzeptionelle Details zum GATE Framework veröffentlichen … doch weil mir das alles nicht so recht gefiel, blieb auch die Motivation aus hier weiterzumachen.

Und dann fiel mir wieder ein:

Codeberg bietet doch Wiki-Pages an!

Die Wiki-Funktion muss in den Einstellungen eines Projekt aktiviert sein, und wer dann im Bereich namens “MYORG” im Projekt “MYPROJECT” die URL
https://codeberg.org/MYORG/MYPROJECT.wiki.git per git klont, kann sich seine Wiki-Seiten per Markdown zusammenschustern und bekommt das Design von Codeberg verpasst, was besser zum Thema Coding und Doku passt, als experimentelle Eigenerfindungen auf privaten Homepages.

Es gibt 3 besondere Dateinamen, denen eine spezielle Bedeutung zukommt.

Home.md ist die Startseite, was wir im Web als index.md bzw. index.html kennen.
_Sidebar.md wird in erster Line als Navigations-Menü immer in einer Box am Rande der Seite (neben dem eigentlichen Content) eingeblendet.
_Footer.md wird jeder Seite am Ende angefügt und eignet sich hervorragend für Copyright und Impressum-Verweise, oder auch für den “Spruch des Tages”.

Kurz gesagt: Mit Home startet alles, und _Sidebar sowie _Footer werden permanent rechts bzw. unterhalb der eigentlichen Seite eingeblendet.

Weitere Seiten mit Verlinkung

Nun kann man auch neue .md Dateien mit Markdown Content anlegen. Verlinkt werden diese wie üblich über [Link-Text](Linkziel), wobei das Ziel des Links nicht als URL, sondern als reiner Dateinamen (aber ohne .md) angegeben wird.

Eine Datei namens additional_info.md wird per

1[Addition Information](additional_info)

verlinkt.

Fazit

Wer also etwas Text zu seinem Codeberg Projekt schreiben will, ist mit dem internen Wiki an der richtigen Adresse.

Zusätzlich zur “nativen” Bearbeitung über git lässt sich der Text auch online bearbeiten.
Sogar die Freigabe des Wikis ist möglich, damit jeder Benutzer etwas beisteuern oder ändern kann.

In Summe also ein absoluter Daumen-hoch für Codeberg’s Wiki Pages.

Ein Junge rettet Bienen und Vögel

2024-08-25T13:00:00+02:00

Eigentlich ist Youtuber in meinem Vokabular ein Schimpfwort geworden. Denn seit der Corona Pandemie sieht sich jeder Egomane als Content-Creator und glaubt zu jedem Blödsinn seine Meinung preisgeben zu müssen.

… und dann gibt es “den netten Jungen/das nette Mädchen” von Nebenan, der/die ihre Leidenschaft mitteilen will.
Und dabei tun sie vielleicht auch mal etwas sehr sehr Gutes.

Wenn Menschen Projekte aus Leidenschaft starten, entsteht eine ganz andere Souveränität und eine ganz andere Leichtigkeit, wenn sie ihre Ziele vortragen. Das steht im krassen Gegenteil zu den kühlen formalen Vorträgen, die wir aus den Nachrichten oder Business-Meetings kennen.

Jetzt ist dieses Übermaß an Emotionalität nicht immer gut, vor allem nicht, wenn man damit Leute aufhetzt … und das passiert leider viel zu oft.

Doch wenn ich z.B.: den Beesteez Kanal ansehe, wo ein Junge seinen Lebensweg mitfilmt und dokumentiert, wie er zum Imker wurde, weil er Bienen mag und ihr zunehmendes Sterben verhindern möchte, dann berührt einen diese Geschichte.

Marcel Reich Ranciki meinte mal in einer Diskussion, dass Menschen in erster Linie wegen eines “Stars” ins Theater oder ins Konzert gehen, was eigentlich die falsche Motivation sei, denn es sollte um das Stück und nicht um den Darsteller gehen.
Doch im gleichen Atemzug erklärte er, dass die Menschen dann trotzdem den Inhalt des Stückes wahrnehmen und über die Handlung nachdenken und damit den Zweck der Aufführung voll und ganz erfüllen.

Vielleicht muss ich, bzw. müssen wir YouTube auch so begreifen und sehen, dass die komödiantische Selbstdarstellung eines Teenagers oder jungen Erwachsenen trotz der Vermarktungsstrategie von YouTube dazu führt, dass wir etwas über Bienen, Vögel und die Natur lernen.

Protagonist Quentin zeigt nicht nur seine Bienenkästen und wie er Nistkästen für Vögel baut und verschenkt, er führt auch Interviews mit Menschen vom Fach für Ornithologie und so lernt der an “coolen Inhalten” interessierte Follower plötzlich etwas über Biologie, was in der Schule stets verhasst war.

Und wenn es darum geht Motivation weiterzugeben, die Augen zu öffnen, dass wir etwas für unsere Natur tun müssen, damit sie nicht abstirbt, dann ist eben vielleicht genau diese Art von Inhalt eben wesentlich zielführender als kalte Statistikvorträge, wie viele Insekten jedes Jahr aussterben und wie auch Vögelbestände stark zurückgehen.

Fazit

In diesem Sinne muss ich mal einen YouTuber für sein Werk loben, wenn gleich ich immer etwas skeptisch bin, wie viel Selbstvermarktung hinter solchen Videoserien steht.

Doch wenn es um die konstruktive Rettung des Planeten geht … tja, da kann man wohl kaum dagegen sein.
Ich wünschte, dass auch andere Umweltorganisationen vom Demonstrationsmodus in den Aktionsmodus umschalten würden, und so wie Quentin mit dem Beesteez Projekt vorleben, was wir aktiv machen können.

Ich sehe den Garten meiner Mutter, der mir bisher eher als chaotischer Wildwuchs aufgefallen ist, nun mit anderen Augen. Denn dort tummelt sich noch rege Natur, es summt und brummt, und das ist gut so.
Auf den niedergemähten Fussballfeld-Gärten mancher Nachbarn herrscht inzwischen Totenstille.

Von daher kann ich Quentins Aufruf nur zustimmen:

Pflanzt Blumen, möglichst viele unterschiedliche!
Denn dort fühlen sich Bienen und andere Insekten wohl.
Und damit retten wir auch unsere einheimischen Vogelarten.

conan cache save

2024-08-18T13:00:00+02:00

Conan v1 hatte in meiner Firma einen gravierenden Nachteil, wenn es um CI/CD Build Pipelines ging:

Wie kann man Pakete lokal exportieren speichern? Antwort: Gar nicht. Nur Uploads ins Artifactory und anschließend Downloads sind gestattet.

Zum Glück haben die Conan v2 Macher dieses Problem aufgegriffen und gelöst.

Im Internet ist Sache mit CONConanN einfach:
Ein Conan Rezept definiert, wo Quellcodes abgelegt sind, und welche Abhängigkeiten und Einstellungen für das Kompilieren der Codes benötigt werden.

Der Nutzer eines Conan Pakets bekommt mit conan install alles Notwendige heruntergeladen und auch gleich alle Bibliotheken mit dem eigenen Compiler gebaut.

Doch … bei mir sahen die Anforderungen ganz anders aus.

Prebuilt binary packages

Bei großer Enterprise-Software können wir nicht unzählige Pakete jeden Tag neu bauen, wir benötigen fertige getestete Bibliotheken für jeden Compiler und für jede unterstützte Plattform.

Aus diesem Grund wurden CI/CD Pipelines eingerichtet, die alle Varianten eines Lib-Projektes erzeugten, abtesteten und dann für die weitere Verwendung ins lokale jFrog-Artifactory hochluden.

An dieser Stelle musste eine Grenzlinie gezogen werden:
Pakete aller Plattformen durften nur dann gemeinsam hochgeladen werden, wenn alle (und zwar wirklich alle) Builds erfolgreich durchgelaufen waren.

In Conan v1 konnte man ein Paket aber nur per conan upload “abspeichern”, und somit mussten wir für die Builds ein temporäres Repository anlegen, das erst mal alles annehmen sollte.
Wenn alle Builds fertig waren, startete ein weiterer Job, der wieder alle temporären Builds herunterlud und ins eigentliche Zielrepo hochladen sollte. Beim einem Fehler eines Jobs wurden einfach alle temporären Builds gelöscht und der Entwickler durfte das Problem suchen.

Effizient war diese Vorgehensweise nicht … aber sie war besser als alle anderen Alternativen, wo die Conan-Caches manuell in den nächsten Job verschoben wurden, wo es dann zum Zusammenprall mit den anderen Builds kam.

Cache save/restore

Conan 2 führt zum Glück zwei Kommandos ein, mit denen der Conan Cache Inhalt extrahiert werden kann, und zwar auf Paket-Ebene.
So können wir beim Ende eines Build-Prozesses das lokale Paket mit conan cache save -f file.tar.gz extrahiere und als .tar.gz zwischenspeichern.
Dieses “Artefakt” kann nun über die nativen Funktionen der Datenweiterreichung des Build-Systems zu einem Folgejob geschoben werden, der mit conan cache restore -f file.tar.gz alle Build-Resultate importiert und gemeinsam ins Ziel-Repository hochlädt.

Hinweis: Es schadet nicht das Paket im Cache von Source- und Build-Resten zu befreien. Ein conan cache clean "*" erledigt das recht zuverlässig.

Fazit

Es sind oft die kleinen Dinge, die große Erleichterungen bringen. Ein conan upload wirkt nicht viel umständlicher als ein conan cache save, doch in der Praxis braucht man viele weitere Infos wie unterschiedliche Ziel-Repos und zusätzliche Build-Cleanup Jobs.

Mit der conan cache save/restore und der Nutzung von nativen Build-Artifacts für die Weitergabe der Daten vereinfachten sich unsere Build-Scripts um einiges.

In diesem Sinne:

Danke an das Conan 2 Team für dieses wichtige neue Feature!

CMake targets

2024-08-11T13:00:00+02:00

Eine große Last wird in der C/C++ Entwicklung von der Vergangenheit erzeugt. Code, der einmal funktioniert hat, bleibt auf unbestimmte Zeit unverändert.

Doch damit verbaut man sich auch oft viele neue Features und verkompliziert sich unnötig den Alltag.

Als ich 2019 endlich auch alle meine Projekte auf CMake umstellte, tat ich das wie so oft mit dem Hintergedanken den Abwärtskompatibilität.

Ich wollte nur “stabile” Features nutzen, die es schon in CMake 3.4 gab, damit ich stets in der Lage war mit alten CMake Varianten zu arbeiten, die noch Codes aus dem Jahre 2000 bauen konnten.

Und so ergeben sich dann viele Aufrufe nach dem Schema

add_definitions(...)
include_directories(...)
link_directories(...)
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} --something)

die zwar alle toll funktionieren, aber den globalen Namensraum verschmutzen und gleichzeitig in anderen Projekten wiederholt werden müssen, damit es dort auch klappt.

Nur `target_xxx_yyy(target ...)` ist richtig

Modernes CMake sollte auf dem korrekten Ausbau von targets aufbauen. Sobald mit
add_library(my_target ...) oder add_executable(my_target ...)
ein target definiert wurde, sollten ihm öffentliche und private Einstellungen zugewiesen werden.
Die privaten werden nur für das target selbst gebraucht, doch öffentliche vererben sich automatisch an ein Folgeprojekt weiter, das mit
target_link_libraries(other_target my_target)
an seine Abhängigkeit gebunden wird.

target_compile_definitions()

Meiner Erfahrung nach sind 90% aller “Definitions” (also von extern gesetzten Makros) nur für ein einzelnes Projekt relevant. Anstatt add_definition(-DBZ_EXPORT) bei einer bzip2 hineinzuwerfen, sollte es target_compile_defintion(bz2 PRIVATE "BZ_EXPORT") heißen.
Ist ein Makro aber in öffentlichen Headern aktiv, kann es mit einer PUBLIC Definition an alle abhängigen Projekt weitervererbt werden.

target_compile_options()

Das schlimmste, was man tun kann, ist: Wegen einer lästigen Warnung alle Warnungen in allen Projekten abzuschalten. Krebsgeschwüre wie -fpermissive haben so unzählige Opfer infiziert.
Anstatt mit solchen Optionen per add_definition den ganzen Baum zu vergiften, kann man per
target_compile_options(mydirtylib PRIVATE "-fpermissive") nur das eine schlampig geschrieben Projekt anpassen.
Ähnlich verhält es sich auch mit anderen - nicht ganz so bösen - Optionen.

target_include_directories()

include_directories(...) zwingt dem Verzeichnisbaum einen Include-Pfad auf, ganz egal, ob es sich um private Sourcen oder öffentliche Header handelt.
Die richtige Arznei ist: target_include_directories

1target_include_directories(mylib 
2  PRIVATE "${CMAKE_CURRENT_SOURCE_DIR}/include/private"
3)
4
5target_include_directories(mylib 
6  PUBLIC "${CMAKE_CURRENT_SOURCE_DIR}/include/public"
7)

Private Include-Verzeichnisse gelten nur für das Target selbst, während öffentliche Includes an alle Targets “vererbt” werden, die das aktuelle Target linken.
Das spart einiges an Redundanz, denn bisher mussten “Konsumenten” die Include-Directory-Vorlieben ihrer Abhängigkeiten kennen.

Fazit

Meine eigenen externen Bibliotheken sind voll von den “alten” Funktionen, die teils auch von uralten Projekten stammen.

Doch wer ein neues Projekt auf die Beine stellt sollte (von wenigen berechtigten Ausnahmen abgesehen) nur noch Eigenschaften auf CMake Targets anwenden.

Es ist ja auch vollkommen OK, wenn man sich ein öffentliche CMake Funktion schreibt, die einem Projekt bestimmt “Standards” angedeihen lässt, womit viele Targets ähnlich bzw. gleich aufgesetzt sind.

“Das Target” ist der König in CMake, daher muss alles immer erst mit ebendiesem abgestimmt werden.

DSL Internet auf dem Dorfe

2024-08-04T13:00:00+02:00

Natürlich liebe ich meine alte Heimat mitten im Grünen und genieße dort das schöne Wetter und die Umgebung.

… aber das Internet liebe ich in der Stadt um einiges mehr.

Zwar gestalte ich nach Möglichkeit meine Programme so, dass sie mit wenig Platz auskommen und nur geringe Datenmengen übertragen müssen, doch andere Dienste sind ohne Breitbandanbindung gar nicht mehr denkbar.

Und so bin ich entsetzt sehen zu müssen, dass ich monatlich zwischen 30 und 100 GB Daten aus dem Netz ziehe. Der Großteil davon sind natürlich Streaming-Dienste wie Netflix, und die elenden Youtube-Videos.
Aber seit dem Ende von Fernsehen und Radio haben eben diese Dienste die Hintergrundbeschallung übernommen.

Dass Windows ISOs über 4 GB groß sind (die passten mal auf ein 650 MB CD) und auch Linux Images nicht mehr unter 1 GB komprimiert zu bekommen sind, fällt einem da fast nicht mehr auf.
… außer man hat schwache Download-Raten.

Nicht mehr als 7 MBit

Wenn einem die Telekom schon sagt, dass das DSL-Kabel in meiner Gegend einfach nicht mehr als 7 MBit hergibt, dann darf man sich nicht wundern, wenn Downloads nicht schneller als 700 KByte pro Sekunde schaffen.
Das bedeutet dann aber, dass so ein 4GB ISO Download mindestens 1,5 Stunden braucht.

Genau das habe ich unterschätzt als ich am Zweitwohnsitz dachte:

Heute aktualisiere ich meine Systeme.

Wenn dann die restliche Belegschaft im Haus parallel Katzenvideos auf Facebook ansieht, wird die Wartezeit erstaunlicherweise nicht weniger.

Online meetings

Bei den 0,7 MBit/s Upload ist ein Video-Stream oder eine Bildschirmübertragung ebenso kontraproduktiv.
Ein einfaches Audio-Gespräch ist zwar machbar, doch falls parallel Aktivitäten stattfinden (angefangen beim ungewollten Windows-Updates), dürfen die anderen Meeting-Teilnehmer das Rätselraten starten, was das zerhackte Kauderwelsch hätte bedeuten sollen.

Unser Bedarf an Komfort hat die Bitraten hochgeschraubt. Früher wurden Audiocodecs nur auf Sprache ausgelegt und kamen mit 50 KBit/s noch zurecht.

Vorbereitung ist alles

Wenn ich nun einen Ausflug zum Zweitwohnsitz plane, nehme ich so viel wie Möglich am Laptop mit. Mit 100 MBit Download und 20 MBit Upload habe ich zwar kein Netz-Rennpferd in Wien, aber der oben erwähnte Download ist bei mir in 5 bis maximal 10 Minuten fertig.

Alternativ bietet sich heute auch das Smartphone an, denn sowohl 4G und besonders 5G erlauben mir auch auf dem Land mit 30 MBit/s und mehr ins Netz zu gehen.
Da kann der alte DSL Anschluss einfach nicht mithalten.

Fazit

Wir brauchen besseres Internet!

Als Software-Entwickler würde ich gerne auch die Hersteller von Webseiten, Streamingdiensten und Messengern dazu zwingen wieder schlankeren Content und bessere Codecs mit besseren Einstellungen auf den Markt zu bringen.

Doch leider fehlt mir die nötige Macht und Gewalt, die Kollegen zu besserem Output zu bewegen.

Und so bleibt einem heute nur der Weg der guten Vorbereitung vor jeder Reise, dass man nur so wenig wie möglich auf Onlinedaten angewiesen ist.

Ich habe inzwischen sogar wieder angefangen, mir Dokumentationen von Sprachen, APIs und Technologien mir offline zu sichern, damit das tägliche Nachschlagen keinen Traffic mehr produziert.

ZIG Build

2024-07-28T13:00:00+02:00

zig ist nicht nur eine Sprache und ein alternative C/C++ Compiler, es ist auch ein ganzes Build-System und füllt damit auch jene Lücken aus, die andere Compiler mit CMake stopfen müssen.

Mal ehrlich … warum war es in 50 Jahren C und 40 Jahren C++ ums Verrecken nicht möglich, das hinzubekommen, was “ein Junge aus New York” (Andrew Kelley) jetzt einfach an die Tafel bzw. ins Netz schreibt?

zig entwickelt sich in meinen Augen immer mehr zu dem Vorzeigebeispiel, was alle Compiler eigentlich können sollten, egal welcher Sprachfamilie sie angehören.

Die Idee ist einfach: zig kann eine “spezielle” Datei mit Standard-zig Code dazu benutzen, einen Build-Prozess zu beschreiben um andere Sourcen zu einem Projekt zusammenzufassen, Abhängigkeiten herunterzuladen und zu bauen.

Man braucht also kein zusätzliches git oder einen OS-Paketmanager für den Download, keinen Build-Graph-Manager zum Dateien-Herauspicken und keinen externen Prozess, der den Compiler steuert.
Alles das macht die zig.exe selbst.

Abhängigkeiten per .zon

Als Javascript seine Objekt-Syntax als Dateiformat namens JSON (JavaScript Object Notation) neu vermarktete, war das schon echt genial und hat unser Denken reformiert.

zig führt mit ZIG-Object-Notation (ZON) genau das gleiche Konzept ein und stützt sich dabei auf seine Möglichkeit, anonyme Strukturen überall frei definieren zu können.

1const mystruct = .{
2    .a: "hello",
3    .b: 42
4};

Einziger Unterschied zu JSON ist der . vor den Membern.

Wie geil wäre es wohl gewesen, hätten wir das in C schon seit den 90ern?

Und nun stelle man sich noch vor, in einer solchen .zon Datei wären URLs mit ZIP-Dateien hinterlegt, wo Sourcecodes drinnen sind und zig würde diese Inhalte herunterladen und für Build-Prozesse nutzen.
Genial!

build.zig

Statt eine Pseudo-Sprache wie cmake, schreiben wir echten zig Code, der in etwa so aussieht:

 1const std = @import("std");
 2
 3pub fn build(b: *std.Build) void {
 4    const lib = b.addStaticLibrary(....);
 5    lib.addIncludePath(....);
 6    lib.addCSourceFile(....);
 7    lib.linkLibC();
 8    b.installArtifact(lib);
 9
10    const exe = b.addExecutable(....);
11    exe.linkLibrary(lib);
12    b.installArtifact(exe);
13}

Oder anders gesagt: zig kompiliert eine build() Funktion, die wir geschrieben haben, wo zig sein eigenes std.Build Objekt hineinwirft und wir dort Build-Vorgaben machen, wie Projekte zu ihren Dateien und Abhängigkeiten kommen.

Am Ende führt ein zig build einfach den Code in unserer build.zig Datei aus um zu Erfahren, wie der Build ablaufen soll … und macht dann genau das.

Fazit

Ich kann jedem nur empfehlen, ein leeres Verzeichnis anzulegen, dann
zig init darin auszuführen und den generierten Code anzusehen.

Genau das hätte jeder C-Compilerhersteller schon vor Jahrzehnten einführen können … doch leider Nein.

Ich gebe zu, dass nicht alle Objektmethoden des ZIG-Build Objektes perfekt sind … um nicht zu sagen, dass es kompliziert werden kann, wenn man viele unterschiedliche Einstellungen setzen will.

Dennoch ist alleine die Idee, dass der Compiler den gesamten Buildprozess gestaltet und alles in einer Sprache ohne zusätzliches externes Scripting auskommt, einfach nur schön und durchdacht umgesetzt.

Hätte es zig schon vor 10 Jahren auf die große Bühne geschafft, so hätte ich heute das GATE Projekt vermutlich ausschließlich in zig geschrieben. Leider hat mir hier die Zeitlinie dann doch einen Streich gespielt.

… aber die große Zeit von zig kommt … unaufhaltsam.

Deadpool & Wolverine

2024-07-24T13:00:00+02:00

Nach einer laaangen Durststecke konnten Marvel Fans in dieser Woche den neuesten Film in den Kinos genießen, der laut Werbung das Versprechen aufbrachte, dass der Multiversum-Handlungsrahmen nun endlich in die richtige Richtung gedreht wird.

… Naja … die Werbung …

Für mich ist heute die Hoffnung gestorben, dass Marvel nochmals ein Meisterwerk wir Endgame hinbekommen wird. Deadpool liefert eben nur “Deadpool”, also eine Ansammlung an Referenzen, Kritiken und Ironie.
Und genau dieser Teil war verdammt lustig.

Dass der Charakter während der Handlung schon ausspricht, was der Zuschauer denkt bzw. denken soll, ist für Deadpool typisch.
Der Charakter sitzt quasi neben uns Zusehern im Kino und kommentiert seine eigene Handlung gleich mit. Somit musste nicht der Nerd mit Brille in Reihe 1 ausrufen:

Hey, da ist ja ein Cameo Auftritt von XXX, den wir schon Staffel YYY von ZZZ gesehen haben.

Nein, genau diesen Zwischenruf macht Deadpool gleich selbst.

Wer schreibt die User-Story?

Die große Frage war für mich: Wo wird uns der Film hinbringen … im Multiversum? Und die Antwort war (für mich): Nirgends.

Avengers Endgame, Loki, Quantumania und Multiverse of Madness haben jeweils ganz andere Zusammenhänge zwischen Zeitlinien und Universen gezeigt. Am Ende gibt es nichts, auf das man sich verlassen kann.
Und Deadpool setzt hier noch einen drauf, und legt fest, dass jedes Universum jetzt noch eine “Anker”-Person hat, ohne die es zerbricht … hier kommt dann willkürlich ein Wolverine hinzu.

Zwar waren die Charaktere und ihr permanentes Gefluche schon witzig, aber nachvollziehen konnte ich es nicht. Viel mehr standen Kasperl und das Krokodil auf der Bühne und tauschten wie in Final-Fantasy 7 Rundenkämpfen KLeinangriffe aus, bis man kurz vor dem Sieg einfach aus dem Kampf floh.

In diesem Streifen wurden Personen so oft durch Stichwerkzeuge durchbohrt und im Anschluss wieder durch Selbstheilung “gefixt”, dass es schon an sich lächerlich war … aber auf ein lustige Art und Weise.

Und nachdem alle neu eingeführten Charaktere am Ende Tod waren, lohnt es sich gar nicht, weiter über sie zu sprechen.

Fazit

Ja, es war ein “gewöhnlich” lustiger Kinoabend, wie man es von Marvel gewohnt ist und die beiden Hauptcharaktere tragen den Film wirklich gut auf ihren breiten, muskulösen Schultern, denn Homoerotik gab es im Überfluss.

Eigentlich ist dieser Marvel-ige Film gar kein Marvel-Film, weil er kein MCU-Film ist, obwohl er auf alles darin anspielt. Es ist eine Standup-Comedy-Vorführung von Ryan Reynolds und Hugh Jackman mit stets verschwindenden CGI-Zauberblut.
… und damit kann ich gut leben.

Und trotzdem sehne ich mich nach einem neuen MCU-Film, der einfach nicht in die Kinos kommen will.

CMake Install

2024-07-21T13:00:00+02:00

CMake ist “das” Werkzeug zum Bauen von C/C++ Software. Doch danach soll diese auch verteilt werden können.

Und genau hierfür müssen die erzeugten Binärdateien und auch Interface Sourcecodes an die richtige Stelle geschoben werden.

Auf Grund meiner “Windows-Vergangenheit”, sah ich CMake in erster Linie immer als Build-Generator, der nur das Kompilieren kontrollieren soll.

In der Linux Welt ist die “Installation” des fertigen Kompilats an die richtige Stelle im / Dateisystem aber ebenso wichtig. Lässt man CMake auch diesen Schritt übernehmen, ergeben sich gleich mehrere Vorteile.

install(TARGETS)

Wenn man die öffentlichen Header in einem Projekt auch als solche in CMake bekannt gegeben hat, dann können diese parallel zu den Binaries auch gleich mitinstalliert werden.
Ein CMake-Projekt sieht dann beispielsweise so aus:

 1project(MyProject)
 2
 3file(GLOB MY_HEADERS "*.h")
 4file(GLOB MY_SOURCES "*.c" "*.cpp" )
 5
 6add_library(${PROJECT_NAME}
 7  ${MY_HEADERS} ${MY_SOURCES})
 8
 9set_target_properties(${PROJECT_NAME} PROPERTIES
10  PUBLIC_HEADER "${MY_HEADERS}"
11)
12
13target_link_libraries(${PROJECT_NAME}
14  mydependency
15)
16
17install(TARGETS ${PROJECT_NAME}
18  ARCHIVE DESTINATION "lib"
19  LIBRARY DESTINATION "lib"
20  RUNTIME DESTINATION "bin"
21  PUBLIC_HEADER DESTINATION "include"
22)

Wie in make lässt sich auch in cmake ein Prefix-Directory angeben und in diesem werden die Dateien in die Unterverzeichnisse lib, bin und include am Ende installiert.

Der Standard-Prefix-Pfad ist /usr unter Linux, womit wir am Ende bei den Standardverzeichnissen /usr/bin, /usr/lib und /usr/include landen.

Conan Pakete

Tatsächlich haben mich erst Conan Pakete auf die Notwendigkeit einer korrekten Installation aufmerksam gemacht.
Wenn nämlich ein cmake Install-Schritt alle Dateien in die Unterverzeichnisse bin, lib und include eines Zielverzeichnisses verschieben kann, dann ist die Conan package() Methode nichts weiter als ein:

1def package(self):
2    cmake = CMake(self)
3    cmake.install()

Runtime-Pfade

Wenn man komplexere Bibliotheken erstellt, ordnet man diese gerne in Hierarchien von Unterverzeichnissen ein. Die Dateien liegen dann nicht einfach in lib/ sondern z.B.: in lib/component/version/something.so.

Wenn man jetzt ein Projekt mit Bibliotheken und Programmen baut, linken die Programme direkt gegen die Pfade im Build-System.
Das wäre dann z.B.: ein ~/my_project/build/output/mycorp/mylib.so. Doch genau diesen Pfad wird es am Ende nicht mehr geben, weil wir die .so in /usr/lib/mycorp/mylib.so installieren wollen.

Das Programm findet mylib.so somit nicht mehr und verweigert die Ausführung.
Zur Lösung dieses Problems hat jedes Programm das RPATH Feld (Runtime-Path), welches die Verzeichnisse enthält, wo .so Dateien gesucht werden sollen.

cmake --install path/to/build_dir ändert bei einer Installation eines Programms auch diesen Pfad auf das neue Installationsziel um.
Dadurch erspart man sich üble Anpassungen der Library-Loader-Konfiguration oder das Setzen von LD_LIBRARY_PATH auf die eigenen Unterverzeichnisse.

Fazit

install(TARGETS) ist nun in allen meinen Projekten nachgepflegt, wo es bisher fehlte … und einem Tool wie Conan gefällt das sehr.

Bisher war das Thema Runtime-Pfade für mich eher nebensächlich, da ich in erste Linie statisch kompiliere und auf .dll / .so Varianten gerne verzichte.
Ein “ordentliches” Projekt muss aber mit beiden Möglichkeiten umgehen können und somit gehören Shared Libraries und deren korrekte Installation auch zum erwarteten Standard.

Es gibt da noch die interessante Möglichkeit den RPATH “relativ” zu setzen … aber das ist eine andere Geschichte.

WinCE Browser mit PIEDocView

2024-07-14T13:00:00+02:00

Das WebBrowser-Control und WebView2 befähigen Win32 Anwendungen, eine Web-Ansicht ins eigene Programm zu holen.

Doch was war mit Windows CE?
Dort war der Pocket Internet Explorer am Start und auch dieser ist “modular” aufgebaut.

Das Internet vergisst und Nischenprodukte wie Windows CE sind schon fast gänzlich dem Online-Alzheimer zum Opfer gefallen.

Doch so wie das Standard-Windows seit Version 98 und NT 5 (2000) mit dem Internet Explorer (und dem SHDocVwCtl.WebBrowser ActiveX Browser Control) ausgeliefert wurde, so konnte man in ein Windows CE Image den Pocket Internet Explorer integrieren und darüber das Web besuchen.

Die Performance des Pocket-IE war katastrophal, weil die CE-Geräte grundsätzlich schwachbrüstig waren und mit Auflösungen von 320 x 240 Pixel auf den alten “Organizern” erst recht nicht mit üblichen Webseiten umgehen konnten.

Hatte man also keine für WinCE optimierte Webseite (ich frage mich, ob es solche überhaupt gab), quälte man sich mit Scrollbars herum, die mit dem Nachzeichnen der Seitenbruchstücke immer das System überlasteten.

Das Microsoft.PIEDocView Interface

Und trotzdem … auch hier gab es eine ActiveX-Komponente, mit der man eine Webansicht in die eigene Anwendung einbinden konnte.
Sie funktionierte identisch zu SHDocVwCtl und benutzte sogar die gleichen Interface GUIDs, nur ihr “Anfang” war etwas anders.

Das Geheimnis ist in den Windows-CE Beispielen versteckt, die man bei der Installation von Visual Studio 2005 mit “SmartDevices” (also WinCE) finden kann:

Während man im regulären Windows atl.dll lädt und dort die Funktionen
AtlAxWinInit(), AtlAxGetControl(), AtlAxGetHost() einsetzt, braucht man unter Windows CE die atlce300.dll Bibliothek, doch die Funktionsnamen und Signaturen sind identisch.

Und wenn wir dann ein Fenster mit der Klasse AtlAxWin erstellen, wird es unter Windows mit der Prog-ID SHDocVwCtl.WebBrowser gefüttert, doch Windows CE erfordert hier Microsoft.PIEDocView.

Aber das war es dann auch schon. Alles andere (Interfaces, Callbacks) verläuft identisch zum Standard Windows WebBrowser Control.
Es reichen also 2 #if WINCE Zeilen im Code für die Portierung eines Win32 WebBrowsers nach Windows CE. (OK, ein paar HWND-Flags existieren in CE auch nicht und brauchen Nachbearbeitung.)

Fazit

Ich konnte somit meine WebBrowser-Demo-UI mit wenigen Zeilen auf Windows CE portieren, was ich mir nie hätte träumen lassen.

Wäre ich heute wieder im Jahr 2007, als mir Windows CE zum ersten Mal unter die Nase gekommen ist, hätte ich jetzt “coole” Ideen für Webanwendungen auf Industrie-Terminals … was damals undenkbar war.

Naja … in einer anderen Zeitlinie hat das sicher geklappt.
Und ich freue mich eben, dass ich über 15 Jahre später dieses Geheimnis lüften konnte.

Browser mit WebView2

2024-07-07T13:00:00+02:00

Seitdem der Internet Explorer verschwunden und “Edge” die Herrschaft übernommen hat, ist auch die alte SHDocVwCtl.WebBrowser ActiveX Webbrowser-Komponente zum Einbinden in eigene Programme abgekündigt.

An deren Stelle tritt WebView bzw. WebView2, womit man sich einen Chromium-Browser selbst bauen kann.

Microsoft hat Edge (zum Glück) mit einer ähnlichen COM-ActiveX Schnittstelle ausgestattet, wie damals den alten Internet Explorer. Somit kann jede Win32-Anwendung auch ein Fenster erzeugen und darin die Edge-WebView2-Komponente eine HTML Seite rendern lassen.
Genau das wird heute immer wichtiger, wo Content nicht mehr in nativen Controls als Text, Labels und Buttons dargestellt wird, sondern nur noch als HTML Code.

Hat man erst ein WebView2-Interface in seinen Händen, kann man es URLs ansurfen oder direkt HTML Code rendern lassen.
Allerdings muss man dafür zwischen einem “echten Fenster” und dem Interface ein paar Daten austauschen können. z.B.:

Größenänderungen des Fensters dem WebView2-Interface bekannt geben lassen
Events aus der Webseite “von außen” bestätigen lassen
- z.B.: eine neue URL soll geladen werden
- ein neues Fenster soll geöffnet werden

Implementierung

Alles beginnt mit einer .dll, die wir mitliefern müssen und sich um die Kommunikation mit der Edge/WebView2 Installation kümmert.
Sie heißt WebView2Loader.dll und stellt Funktionen wie CreateCoreWebView2EnvironmentWithOptions() bereit. Danach läuft alles über COM-Interfaces, die eine Funktion meist asynchron anstarten und wir müssen ein Callback-Interface gleich mitübergeben, welches über die Fertigstellung eines Ergebnisses wieder in den eigenen Code zurückspringen kann.

Ein WebView2 Fenster anlegen

CreateCoreWebView2EnvironmentWithOptions() wird mit einem selbst implementierten ICoreWebView2CreateCoreWebView2EnvironmentCompletedHandler Pointer aufgerufen um eine Sitzung vorzubereiten.
Wir erhalten einen ICoreWebView2Environment Pointer über die Callback Methode Invoke().
Nun können wir per CreateWindowEx ein beliebiges HWND Fenster erzeugen, in welchem WebView laufen soll.
Über den Environment Pointer rufen wir CreateCoreWebView2Controller() mit auf dem neuen HWND auf um über einen ICoreWebView2CreateCoreWebView2ControllerCompletedHandler Callback an eine neue ICoreWebView2Controller Instanz zu kommen.
Per controller->get_CoreWebView2() erhalten wir nun ein ICoreWebView2 Interface, mit dem wir den Web-Inhalt in unserem Fenster steuern können.
Nun können wir beliebig viele Event-Handler als Callback-COM Objekte registrieren. Hier ein paar Beispiele:
- NavigationStarting
- ContentLoading
- SourceChanged
- HistoryChanged
- FrameNavigationStarging
- FrameNavigationCompleted
- ScriptDialogOpening
- PermissionRequested
- WebMessageReceived
- NewWindowRequested
- DocumentTitleChanged
- ContainsFullScreenElementChanged
- WindowCloseRequested

Wenn man auf diese Events reagiert, kann man ihr Verhalten beeinflussen, ihre Bearbeitung verhindern oder überhaupt erst ermöglichen. Das hängt von der Art der Anwendung ab.

Das WebView2 Fenster ist somit fertig erzeugt.
Über das ICoreWebView2Controller Interface kann man mit Methoden wie put_IsVisible() den Browser sichtbar oder unsichtbar machen oder die Größe des Fensters per put_Bounds() explizit anpassen.

Das ICoreWebView2 Interface lässt uns mit Navigate() eine URL ansurfen oder per NavigateToString gleich HTML Code als String rendern. Zusätzlich helfen Methoden wie GoBack() GoForward() oder Stop() das typische Verhalten eines Webbrowsers auszuführen.

Fazit

Auch wenn die Interfaces etwas anders benannt sind und mehr asynchrone Ausführung mit Callbacks erfordern, so ist die Funktionsweise zum alten IE Code doch recht ähnlich.

Das Öffnen von neuen Fenstern ist am kompliziertesten, weil man hier aus einem Callback heraus wieder im Hintergrund ein neues natives Fenster erzeugen muss, bevor man eine weitere WebView2 Instanz+Controller damit verknüpfen kann.

Ich habe eine Demo-Implementierung in den Win32-UI Teil übernommen und diese wird immer automatisch aktiv, wenn mein Demo-WebBrowser zusammen mit einer WebView2Loader.dll gestartet wird und WebView2 im System vorhanden ist. Falls nicht fällt der Code auf das alte SHDocVwCtl.WebBrowser Interface zurück, das auch im aktuellen Windows 11 trotz fehlendem Internet Explorer immer noch die altes IE-Engine im eignen Prozess ausführt.

WinRM

2024-06-30T13:00:00+02:00

Als ich vor 14 Jahren die Verantwortung für Windows Embedded Standard 7 Installationen übernahm, stellte sich vor allem die Frage:

Wie kann man die Systeme aus der Ferne verwalten.

RDP und VNC mit voller UI ist zwar nett, aber nicht wirklich automatisierbar. Hier kam dann WinRM ins Spiel.

WinRM ist die “kurze” Microsoft-Antwort auf SSH aus der Unix Welt.

Es handelt sich dabei um ein SOAP-über-HTTP Protokoll, welches eine “Aufgabe” auf ein Zielsystem senden kann, und das Ergebnis zurückliefert.

Der kleinste gemeinsame Nenner zwischen SSH und WinRM ist das starten von Prozessen, man kann z.B. cmd.exe auf dem Zielsystem starten und vom lokalen System per Tastatur steuern.

Im restlichen Feature-Set unterscheiden sich die beiden Techniken aber. SSH kann Dateien verwalten (SFTP) und TCP-Ports weiterleiten (tunneln), was WinRM nicht kann.
Dafür gibt WinRM einem Zugriff auf alles, was durch WMI erreichbar ist, was wiederum den Unix-Derivaten fremd ist.

WinRM einrichten

WinRM ist ein Windows Systemdienst, der seit Windows Vista/7 deaktiviert ausgeliefert wird. Für Windows XP und Server 2003 gab es Upgrades um es auch dort nachzusinstallieren.

Aktivieren kann man den Dienst durch folgende Befehl als Administrator auf der Konsole:

1winrm quickconfig -force -q

Diese Befehlszeile ist auf beiden Systemen (also dem lokalen System und dem zu verwaltenden System) auszuführen.

Das -q (quiet) Flag verhindert die Nachfrage, ob man wirklich Änderungen durchführen will.

Lokalen WinRM Client einrichten

Per Standard erfordert WinRM die Kommunikation über HTTPS auf Port 5986, doch da wir hierfür gültige Zertifikate und eine Public-Key Infrastruktur benötigen, richte ich für Tests (oder in anders gesicherten Netzen) WinRM via HTTP ohne Zertifikatzwang auf Standard-Port 5985 ein.

Außerdem muss der Client explizit wissen, welche Server er ansprechen darf. Das lässt sich aber mit dem Wildcard-Eintrag * auf “alle” Systeme ausweiten.

Folgende Kommandos sind also nötig:

1winrm set winrm/config/client @{AllowUnencrypted="true"}
2winrm set winrm/config/client @{TrustedHosts="*"}

WinRM Service auf dem Zielsystem einrichten

Am Zielcomputer ist ebenfalls die Kommunikation auf “UnEncrypted” zu stellen:

1winrm set winrm/config/service @{AllowUnencrypted="true"}

Auf einem Windows Server ohne User-Account-Control wäre man jetzt fertig und könnte sich mit einem Administrator Account+Passwort einloggen.
Doch unsere heutigen Windows Clients entfernen ja die Administrationsrechte beim Login, und somit wird der Zugang zu WinRM verweigert.

Man erhält eine Fehlermeldung wie:

Winrs error:Access is denied.

Hierfür müssen wir einer anderen Gruppe die nötigen Rechte erteilen und unseren Login-Account in diese Gruppe aufnehmen. Die Gruppe “Remote Management Users” bietet sich hierfür perfekt an.

Mit dem Aufruf von

1winrm configSDDL default

öffnet sich der Dialog zum Editieren der Zugriffsrechte und hier kann man die Gruppe Remote Management Users mit Lese- und Ausführungsrechten hinzufügen.

Remote Shell starten

winrs ist das Werkzeug, mit dem die Verbindung zur Konsole des Zielsystems hergestellt wird. Die Befehlszeile lautet:

1winrs -r:http://remote_ip:5985 -u:remote_login -p:remote_password cmd.exe

Lässt man den -p: Eintrag weg, wird man zur Eingabe des Passworts aufgefordert.

Und mit etwas Glück sieht man dann auch schon den Inhalt des entfernten Systems und kann es mit üblichen Windows-Konsolenkommandos bearbeiten.

Sonderfall Domain-Mitgliedschaften

Ist das Zielsystem in einer Domäne, braucht man den Domänennamen vor dem Account, also:

1winrs -r:http://remote_ip:5985 -u:mydomain\my_dom_account cmd.exe

Und wenn man auf einem Domänen-PC einen lokalen Account erreichen will, kann man das mit einem vorangestellten Backslash erreichen (oder man stellt den PC-Namen statt der Domäne vorne an):

1winrs -r:http://remote_ip:5985 -u:\my_local_account cmd.exe

Fazit

Die Aktivierung von WinRM auf Industrie-Terminals hat mir schon ein paar Mal “den Arsch gerettet”, denn so konnten Fehlkonfigurationen im Hintergrund behoben werden, ohne dass man die Arbeit am Terminal per RDP oder VNC unterbrechen musste, was den Anwender oft irritierte.

Die Remote-Shell ist zwar kein gleichwertiger Alternative zu einem SSH Dienst, aber ein wirklich hilfreiches Werkzeug, das bei jeder Standard-Windows Installation vorhanden ist und nur aktiviert werden muss.

Windows Server Backup Cleanup

2024-06-23T13:00:00+02:00

Täglich läuft nachts der Windows-Server Backup-Dienst an und sichert alle Daten auf eine externe Festplatte.
Das Backup läuft zwar inkrementell, aber dennoch sammeln sich unzählige Änderungen und neuere Downloads an, die das Backup-Medium an die Grenzen bringen.

Frage: Wie kann man alte Backup-Zustände löschen?

Bei täglicher Ausführung kommen pro Jahr 365 Backup-Einträge zusammen. Auf meinem Dateiserver kommen monatlich neue Software und OS-Images auf die Platte, die ein älteres Image ablösen.

Im Dateisystem sind diese “Altlasten” schnell gelöscht, doch das Backup behält diese Stände und wächst somit ordentlich an.

Und da ich nicht jede Variante von Debian Installern bis Windows Versionen im Backup brauche, möchte ich gerne die gespeicherten (und unbenutzten) Backup-Zwischenstände löschen.

Mit `wbadmin` alte Backup Stände löschen lassen

Wenn ich bereits weiß, dass ich alle alten Backups, bis auf die letzten 10 Tage löschen möchte, so lautet das Kommando:

1wbadmin delete backup -keepVersion:10

Der Parameter -keepVersion bewahrt die jüngsten 10 Stände (also 10 Tage bei mir) und entfernt den Rest.

Das bringt in meinem Fall oft hunderte Gigabyte an freiem Speicher auf der Sicherungsplatte. Vor allem wenn ich temporär Filme oder andere Daten am Dateiserver ablege, die später auf DVD oder Blu-ray gebrannt oder einfach gelöscht werden, wird ordentlich Overhead im Backup Speicher generiert.

Die Ausgabe des Tools sieht dann etwa so aus:

 1C:\>wbadmin delete backup -keepVersions:10
 2wbadmin 1.0 - Backup command-line tool
 3(C) Copyright Microsoft Corporation. All rights reserved.
 4
 5Enumerating backups...
 6Found 283 backups,
 710 will be left after the delete operation.
 8Do you want to delete the backups?
 9[Y] Yes [N] No y
10
11Deleting backup version 09/13/2023-01:30 (1 out of 273)...
12Deleting backup version 09/14/2023-01:30 (2 out of 273)...

Fazit

Theoretisch könnte ich mir jetzt noch einen automatisch auszuführenden Job setzen, der das Kommando monatlich startet … aber das war bisher noch nicht notwendig.

Ich führe diese manuelle Löschung jedes Jahr an einem freien Wochenende durch, wenn ich generell meine Datenbestände aufräume. So weiß ich dann auch, dass ich die Altlasten sicher nicht mehr brauche.

ISO auf CD/DVD brennen mit Windows 10/11

2024-06-16T13:00:00+02:00

Eigentlich haben wir in Windows seit Jahrzehnten bei ISO Dateien den Kontextmenü Eintrag Burn to disc oder deutsch Auf Datenträger brennen. Und der macht aus der Datei per CD/DVD/Bluray Brenner ein “klassisches” Medium.

Doch dieser Eintrag fehlt bei mir auf fast allen Installationen …

Wenn 7zip das CD/DVD-Brennen versteckt

Tja … wenn man einem 7zip oder einem anderen Tool erlaubt, ISO Dateien öffnen zu lassen, überschreibt man damit auch die Standard-Registrywerte, die festlegen, dass jede ISO-Datei mit dem Windows-internen ISO Brenner verknüpft wird.

Man findet dann den Eintrag Burn to disc beim Rechtsklick auf eine ISO Datei nicht mehr.

isoburn.exe mit .iso verknüpfen

In c:\windows\system32 liegt das Programm isoburn.exe und eben dieses verwaltet den Brennvorgang.

Mit dem Aufruf von isoburn path\to\myimage.iso öffnet sich der gewohnte Dialog, der einen das Ziel-CD/DVD-Laufwerk auswählen und den Vorgang starten lässt.

Der schnellste Fix für den fehlenden Eintrag im Kontextmenü ist also:

Rechtsklick auf eine .iso Datei
Im Kontextmenü: Open with (Öffnen mit)
Choose another app (Andere App auswählen)
Runterscrollen und Choose an app on your PC (Andere App auf diesem PC suchen) wählen.
Dann c:\windows\system32\isoburn.exe suchen und auswählen.
Und dann den neuen Eintrag Windows Disc Image Burner (Windows-Brenner für Datenträgerabbilder) mit Always für immer mit ISO-Dateien verknüpfen.

Ein Doppelklick auf eine .iso Datei öffnet nun isoburn.exe und das Brennen kann beginnen.

Alternativ kann man das auch über den Dialog Default apps oder Default programs (je nach Windows-Version) in der Settings-App oder in der Systemsteuerung durchführen lassen.
Man sucht auch dort nach .iso Dateien und verbindet sie mit dem Windows Disk Image Burner.

Fazit

Bevor Windows mit Version 7 das Brennen endlich selbst in die Hand nahm, sah sich unsereiner bei jedem Laufwerk mit einer anderen Software konfrontiert.

Nero Burning ROM kam da zwar am häufigsten vor, aber ich erinnere mich da noch an anderen, an deren Namen ich mich wiederum nicht mehr erinnere.

Zwar werden CDs und DVDs immer unwichtiger, doch so manche Retro-Hardware- Installation klappt per Scheibe immer noch viel besser, als per USB-Stick. Und deshalb ist die Verfügbarkeit des Windows-Brenn-Tools immer wieder aufs Neue wichtig.

7zip kann eine ISO auch über das 7zip-Kontextmenü öffnen, von daher ist das Umregistrieren der “Default-App” kein Problem.

StarFive VisionFive2

2024-06-15T13:00:00+02:00

Immer mehr RISC-V Development Boards kommen auf den Markt, und das ist gut so. Mit dem VisionFive2 wird auch meine Familie wieder um ein Mitglied reicher.

Mit einem 4x 1.5 GHz JH7110 Prozessor, 8 GB RAM, HDMI Grafik, 4 USB Ports, 2 Ethernet.Ports und Medienunterstützung für SD-Karten, eMMC und NVME M2 SSDs bietet StarFive mit dem Entwickler-Board VisionFive2 einen hervorragendes RISC-V SoC-Computer zum kleinen Preis von etwa 100 Euro.
Die 4 GB Variante ist etwa 20 Euro günstiger.

Einen großen Vorteil gegenüber dem Pine64 Star64 stellen folgenden Faktoren dar:

Die kompaktere Plantine,
der NVME M2 Support,
und eine USB-C Bestromung.

Software Installation

Debian plant in seinem nächsten großen Release (Debian 13 - Trixie) RISC-V 64 und diverse Boards vollständig zu unterstützen, doch bis dahin müssen wir uns mit einem Unstable-Development Stand des Betriebssystems begnügen.

Eine Beschreibung der Installation ist unter rvspace.org abgelegt, welcher ich gefolgt bin.

Ein vorbereitetes Debian-Image ist bereits auf einigen Filehostern vorhanden, darunter eine öffentliche One-Drive Instanz

Das Image muss nur auf eine SD-Karte übertragen werden. Vor dem Boot sollte geprüft werden, dass die beiden DIP-Schalter auf dem Board auch korrekt gesetzt sind. Bei mir klappte es mit der “Flash” Einstellung (beide Schalter zeigen in Richtung des ONKE Textes), denn im internen Speicher des Geräts ist bereits ein uBoot Loader installiert, der danach den SD-Karten Boot durchführt.

Den erfolgreichen Boot erkennt man nach einigen Sekunden Wartezeit an der grün blinkenden LED am Board. Denn in der ersten Minute bleibt der Bildschirm schwarz und man weiß nicht so recht, ob das System nun wirklich bootet oder eben kein Medium erkannt wurde.

Doch letztendlich kann man sich grafisch mit dem Benutzer user und dem Passwort starfive einloggen.
Die Gnome-Wayland Umgebung wirkt allerdings recht träge und erinnert etwas an eine UI-Installation auf einem Raspberry PI Zero oder Model 2.
Es funktioniert zwar, läuft aber nicht, sondern kriecht.

Wenn man aber per
sudo systemctl set-default multi-user.target das System nicht grafisch sondern nur per Konsole betreibt, kann man “normal” damit arbeiten.
Denn nachdem mit apt install notwendige Build Utilities installiert sind, lässt sich mit z.B. neovim Software Entwicklung durchführen.
Und hier steht der VisionFive2 in Sachen GPIO und Library-Support in nichts nach.

Fazit

Ich vermute, dass mit künftigen Software-Updates die aktuelle Trägheit des Systems zurückgehen wird. Denn für 4x 1.5 GHz ist der Betrieb wirklich bedenklich langsam. Das liegt vermutlich auch an den Treibern.

Der Stromverbrauch liegt unbelastet bei 4-5 Watt und steigt bei einer Vollauslastung aller Kerne (beim Kompilieren) auf 8 Watt.
Das ist zwar etwas mehr als diverse schwachbrüstige ARM-SoCs, aber auch nicht wirklich viel. Ein 2A-Netzteil reicht also aus. 3A / 15 Watt sind aber trotzdem zu empfehlen, wenn weitere Peripheriegeräte angeschlossen sind.

Nichts desto trotz haben wir mit dem VisionFive2 ein Stückchen Zukunft in den Händen. RISC-V ist immer noch kein Rennpferd und hinkt einer ARM64 Plattform noch ein paar Jahre hinterher.
Doch die OpenSource-Idee und Patentfreiheit der Hardware macht sie für moderne Unternehmen preiswert und daher interessant.

Workfolders über HTTP

2024-06-09T13:00:00+02:00

Microsoft erklärt uns bei der Einrichtung von Workfolders (deutsch: Arbeitsordner), dass diese nur mit HTTPS funktionieren. Das hat inzwischen auch so manche KI gelernt und versteift sich jetzt darauf.

Das stimmt aber nicht.

Meine Beziehung zum Workfolders-Feature unter Windows ist schwankend. Ich finde es super, dass man seinen eigenen “One-Drive-Service” auf einem Server einrichten und dann Daten von mehreren Clients hin- und her- synchronisieren kann.

Wenn es aber um die SSL-Einrichtung/Aktualisierung geht, hasse ich das Teil!

Ein fehlendes UI und fehlende “gute” Dokumentation sind der Grund dafür, dass man dann stundenlang Konfigurationsdateien editieren und Zertifikate erzeugen, exportieren und importieren muss.

Es geht aber auch einfacher: Man schaltet das HTTPS-Requirement einfach aus und nutzt das ganze unverschlüsselt.
Das sollte man im Unternehmensbereich nicht machen … aber auf meinem internen Netzwerk, das vom Internet durch zwei Router getrennt ist, wollen wir mal nicht so pingelig sein.

Windows Workfolders mit HTTP statt HTTPS betreiben

Man legt einfach auf der Client-Maschine im Registry Key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WorkFolders
einen DWORD Eintrag namens AllowUnsecureConnection an und setzt den Wert auf 1.

Dann beendet man am Besten den Workfolders Dienst (interner Name workfolderssvc) und öffnet dann im Control-Panel das Workfolders Plugin und beginnt mit der Einrichtung.
Dort wählt man aus, dass man eine URL eingeben möchte und setzt nun:
http://myserver.tld.

Ohne AllowUnsecureConnection kommt die Fehlermeldung, dass die URL mit https:// beginnen muss, doch mit der Einstellung startet die Synchronisierung problemlos.

Fazit

Genau für solche “Spielereien” erwartete ich von einem ordentlichen Produkt, dass man in einem Zusatzdialog namens “Erweiterte Konfiguration” einfach einen Haken setzen kann, um den HTTPS Zwang deaktivieren zu können.

Doch leider bleibt die Registry … seit mittlerweile 30 Jahren … immer noch das einzige Tool, mit dem man Windows wirklich konfigurieren kann.

Windows Vista WSUS Update

2024-06-02T13:00:00+02:00

Auch wenn es denkbar unwahrscheinlich ist, dass jemand heute noch Windows Vista hegt und pflegt … ich habe nach wie vor eine Test- VM mit diesem System.

Doch WSUS Updates ließen sich um’s Verrecken nicht einrichten, da der Update-Dienst mit hoher CPU Auslastung einfach hängen bleibt.

So wie bei anderen “historischen” Systemen, habe ich auch für Windows Vista:

eine WSUS Gruppe am Server angelegt und Updates freigegeben
dem Client werden neue Zertifikate eingepflanzt,
die Registry mit Einträgen für den WSUS erweitert
und wuauclt mit /resetauthentication, /reportnow und /detectnow ausgeführt.

Doch nach dem ersten Selbstupdate, läuft der Update-Dienst danach zwar an, sammelt offenbar Daten zusammen und bleibt dann mit einem CPU-Kern auf Vollauslastung für alle Ewigkeiten hängen.
Ich hatte die VM ein Woche “arbeiten” lassen und es brachte nichts, außer viel verbratener CPU Zeit.
Auch das Löschen von C:\Windows\SoftwareDistribution brachte nichts.

An der Stelle möchte man aufgeben und akzeptieren, dass das System einfach nicht mehr zeitgemäß ist. (Obwohl: Windows 2000/XP Updates laufen brav weiter).

Updates manuell einspielen.

Zahlreiche Erklärungen und Hinweise im Web halfen mir nicht, bis ich dann auf eine Microsoft-Forum Antwort stieß.

Hier heißt es, man soll die Updates

einspielen und es nochmals versuchen.

Nach dem Herunterladen der MSU Dateien muss man Windows Updates deaktivieren. Also die Einstellung Never check for updates (not recommended) setzen, weil sonst auch beim manuellen Ausführen der Updates eine endlose Suche startet.

Doch nach der Installation der 5 Updates und einem Reboot, und dem Aktivieren von Updates, konnte der Dienst tatsächlich seine Suche abschließen und fehlende weitere Updates von meiner WSUS Maschine herunterladen und integrieren.

Fazit

Windows Vista lässt sich also genau wie Windows XP auch im Jahr 2024 noch mit WSUS auf den letzten Stand bringen, wenn man helfend eingreift.

Dass sich der Update-Dienst aber selbst zerstört und dann das System mit einer Endlosschleife blockiert, ist aber eigentlich nicht hinnehmbar.

Solche Fehlkonstruktionen passieren leider häufiger, wenn der offizielle Support beendet wird. Dennoch sollte man nicht vergessen, dass der erweiterte Support und die Versorgung mit den letzten Updates 10 bis 15 Jahre weiterläuft und genau diese Funktion muss ein Update-System sicherstellen können.

PowerQuest Partition Magic

2024-05-26T13:00:00+02:00

Es war wieder mal eine Heft-CD, die mich mit einer der wichtigsten Software-Lösungen in den 90ern zusammenbrachte.

PQMagic war der ultimative Partitions-Manager, der mich damals in die Lage versetzte mehrere Betriebssysteme parallel installieren zu können.

Partitionen sind eine “gefährliche” Sache. Verkackt man sie, ist alles weg.

Meinen erster größeren Datenverlust verdanke ich Linux und einer falsch abgetippten Zahl beim manuellen Verändern der Partitionstabelle. Das muss so im Jahr 1998 gewesen sein, als die ersten Linux-Distros auf den berühmten Magazin-Heft-CDs auch mich hinter den 7 Bergen erreichten.

In der DOS und Windows Welt gab es damals eine Regel:
Es kann nur ein OS geben.
Und deshalb konnten Tools wie fdisk unter DOS auch nur genau eine primäre Partition mit Boot-Flag anlegen und alles weitere waren “logische Laufwerke” auf der erweiterten (nicht boot-baren) Partition.

Eine kleine Ausnahme gab es: Wer ein Windows NT 4 auf einer primären Partition installierte und das Dateisystem auf NTFS konvertierte, konnte im NT Festplatten-Tool weitere primäre FAT-Partitionen anlegen und sogar das Boot-Flag auf diese setzen.
So konnte man dann wieder von DOS-Diskette starten und auf der 2. primären Partition DOS oder Windows 3x/9x installieren, denn diese erkannten NTFS nicht und so konnte man auch per fdisk zwischen diesen Systemen per Bootflag hin- und her-schalten.

Aber eigentlich war es erst Linux, das mich auf die Idee brachte, auf einem PC mehr als ein OS zu installieren.
… bis ich es verkackt hatte … und Linux lange dafür hasste.

Und dann kam endlich die Heft-CD mit dem Tool, das alles veränderte: PowerQuest Partition Magic oder kurz pqmagic.exe

PQMagic, ein DOS Tool im Windows Look

Mich fasziniert bis heute, dass sich jemand die Mühe gemacht hat das volle Look&Feel von Windows 95 in einer DOS-Anwendung im 640x480 VGA Modus nachzustellen. Denn das Fenster, das Menü und die Buttons sehen wirklich fast exakt so aus, als wären sie mit der WinAPI gezeichnet worden.

Viel wichtiger war aber, dass PQMagic eine grafische Oberfläche für Partitionen, einige Sicherheits-Checks und bis dato unbekannte Features bereitstellte.

Mehrere primäre Partition

Endlich konnte man auf einer Festplatte mehrere Partition anlegen und sogar FAT16 und FAT32 Dateisystem aufsetzen.
Damit sich mehrere parallele Windows oder DOS Installation nicht gegenseitig störten, wurde die Funktion Versteckte Partition eingeführt, womit eine FAT Partition einfach einen unbekannten Partitions-Typ zugewiesen bekam und damit von DOS und Windows nicht mehr erkannt wurde.

Per PQMagic konnte man dann beim Wechsel des Boot-Flags die versteckte Partition wieder in eine sichtbare umwandeln und die andere dann verstecken.

Anpassung der Größe

Das wichtigste Feature war jedoch die Änderung der Größe einer Partition und des Dateisystems. Und damit ist nicht einfach nur die Anpassung der Grenzen gemeint, sondern eine vollständige Restrukturierung des Dateisystems, wenn dies notwendig war.

FAT nutzt Cluster, die bei größeren Kapazitäten ebenso größer werden müssen, um mit 16-bit Indizes adressiert werden zu können.
Wer eine 500 MB Partition mit einer 8KB Clustergröße um 100 MB vergrößern wollte, war mit der 512MB-Grenze gezwungen auf 16KB Cluster zu wechseln. Dafür musste jede einzelne Datei in neue Cluster zusammengefasst werden, was bei der üblichen Fragmentierung ein vollständiges Neuschreiben von allen Daten notwendig machte.

Und genau diesen Job erledigte PQMagic bei mir immer fehlerfrei und ohne Datenverlust.
Auch heutige Tools in Windows, die Laufwerksgrößen anpassen können, tun dies nur in den Dimensionen, wo sie keine bestehenden Daten verändern müssen. PQMagic konnte also schon damals wesentlich mehr.

Ein Sonderfall war dann hier auch noch die Konvertierung von FAT16 zu FAT32 und umgekehrt. Das neue FAT32, welches mit Windows 95b und Win98 eingeführt wurde konnte wieder von NT4 nicht erkannt werden und anstatt jetzt Daten bei der falschen Dateisystemwahl hin- und herzukopieren, konnte PQMagic mit einer Konvertierung das Problem viel eleganter lösen (so lange die 2GB Grenze nicht überschritten wurde).

Verschiebung, Backups und Spezialfälle

Auch das Verschieben von Partitionen und allen enthaltenen Daten war mit diesem Tool erstmals möglich. Wer bestehende Partitionen in der Größe anpasste, hatte dann auch großes Interesse entstandene Lücken aufzufüllen.

Und wer eine zweite größere Festplatte gekauft hatte, konnte PQMagic für das effiziente Kopieren aller Daten auf das neue Medium einsetzen. Auch dem System unbekannte Dateisysteme wie NTFS oder ext2 konnten so Byte für Byte gespiegelt werden.

Und für die Bit-Hacker gab es dann auch noch Tools zum Anpassen der FAT-Stammverzeichnisgröße. Diese wird beim Formatieren auf einen festen Wert gesetzt und kann beim Erreichen dieser Grenze dann keine neuen Dateien oder Unterverzeichnisse mehr behandeln … außer man nutzt PQMagic.

Die Prüfung auf fehlerhafte Sektoren hört sich neben den anderen genialen Features dann schon fast trivial an.

Fazit

PQMagic ermöglichte mir den Multiboot von allen Microsoft-Betriebssystemen auf einer Festplatte viele Jahre bevor dies von Microsoft vorgesehen war. Und da alle Aktionen per UI “deppensicher” durchgeführt wurden, konnte man auch gar keine falschen Werte eintippen, die eine Partition zerstört hätte, so wie es mir mit Linux erging.
(OK, den Partition-Löschen Befehl mit Sicherheitsfrage mal ausgenommen.)

Es war vermutlich auch dieses Werkzeug und mein zuvor erlittener Fehlschlag, der mich damals lehrte, dass gute Software anwenderfreundlich und fehlerabweisend geschrieben sein muss.
Heute ist diese Erkenntnis auch in Linux angekommen und hat seinen heutigen Erfolg ermöglicht.

PQMagic hat aber weiter einen besonderen Platz in meinem Retro-Herzen und bekommt auf meinen Pocket386-Laptop und in QEMU Images wieder neue Aufgaben.

Pocket386

2024-05-19T13:00:00+02:00

Weil mich mein Book8088 so glücklich gemacht hat, bestellte ich auch gleich sein Brudermodel: Den Pocket386.

Nun kam mein zweiter Minilaptop mit 40 MHz 80386 CPU und 8 MB RAM an. Jetzt habe ich endlich mal ein echtes Windows 95, dass sich genau so verhält, wie es damals vor 30 Jahren der Fall war.

Erneut lässt ein Produkt aus China mein Retro-Herz schneller schlagen.
Der Pocket386 verbaut einen Embedded 386-Prozessor mit einem LCD Screen, 8 MB RAM und einer Compact-Flash Karte in einem kleinen Plastik-Laptop-Gehäuse und lässt mich nun das Abenteuer Windows 95 erstmals seit 25 Jahren wieder neu erleben.

Der Ali M6117 ist mit 40 MHz getaktet was für einen 386er viel, für die Windows 9x aber ein kritisches Minimum darstellt.

Trotz der für diese Verhältnisse schnellen CompactFlash Karte, startet und reagiert das System relativ träge … aber ausreichend, dass man damit arbeiten kann.

Ein 4000 mA LiPo-Akku ermöglicht das Arbeiten für mindestens eine halbe Stunde. (Mehr habe ich noch nicht ausgetestet.) Geladen wird das Gerät über ein 12V 1.5A Netzteil.

Interessant ist vor allem die Maus-Integration.
Diese kann entweder per Tastatur simuliert werden, oder man bedient sich eines PS/2 Adapters und schließt eine echte Maus an dessen Buchse an.
Eine reale Maus ist zu empfehlen, denn die Tastatursteuerung mit den Pfeiltasten ist wahrlich ein Graus.

An der Seite befindet sich wie beim Book8088 der CF-Kartenslot und eine USB-Buchse für einen FAT-formatierten USB-Stick, der per DOS-Treiber eingebunden werden kann.
Auf eine reguläre serielle Schnittstelle wird verzichtet, doch dafür erhalten wir ein PIN-Interface für eine parallele Schnittstelle, wie sie Drucker aus jener Zeit benötigten.

Auf der Rückseite können spezielle Flachbandkabel an einen von 4 Ports angestöpselt werden:

Ein ISA-GPIO Port, der eine serielle Schnittstelle mit TTL (und nicht RS232!) Elektronik bereitstellt.
Der PS2/VGA Port für eine externe Tastatur und Maus, wie auch einen VGA-Monitor
Ein ISA-16-bit Port
Der vom 8088 bekannte ISA-8-bit Port

Betrieb

LCD Display

Der 7 Zoll große (21x12 cm) Display kann nur mit 640 x 480 Pixel betrieben werden, doch über das OSD-Menü per Fn+F4 kann der Screen zwischen 16:9 und 4:3 hin und hergeschaltet werden, wo beim 16:9 Modus die 640 x 480 Pixel einfach auf 800 x 480 gestreckt werden.

Das sieht zwar etwas verzerrt, aber immer noch akzeptabel aus und verbessert die Lesbarkeit von Texten.

Peripheriegeräte

Mit der Tastenkombination Fn+F5 erscheint ein Menü mit Infos zum Akkustand und mit dem Status zu Soundkarte, Parallel Port, VGA und Mouse.

Folgende weiter Tastenkombination sind möglich:

Fn+3 Sound Ausgang ein/ausschalten (also auf laut oder still schalten)
Fn+O OPL3 Soundkarte ganz deaktivieren
Fn+P Parallel Port ein/ausschalten
Fn+1 Zwischen LCD und externem VGA Monitor hin- und herschalten
Fn+5 PS/2 Tastaturmaus ein/ausschalten

Tastaturmaus

Ist diese aktiviert, kann man mit den Tasten rechts-unten auf der Tastatur eine virtuelle Maus steuern.

Der PS/2 Maus Port muss dafür im BIOS aktiviert sein. Hierfür wechselt man per Delete Taste beim Einschalten ins BIOS zum
Advanced CMOS Setup und beim Punkt Mouse Support per
PgDn Taste (also Fn+Pfeil-runter) auf Enabled.
Esc + Save Settings and Exit speichern die Einstellung.

Nach dem Start steuern folgende Tasten die virtuelle Maus:

Pfeiltasten: Bewegen den Mauszeiger nach links/rechts/oben/unten
? führt einen Linksklick durch
Shift führt einen Rechtsklick durch

USB Stick

Der vom Book8088 bekannte USB-Port ist ebenso vorhanden und wird über den gleichen DOS-Treiber aktiviert.
Ist vor dem Start ein FAT16 USB Stick angeschlossen und der Treiber in config.sys registriert, ist der Stick-Inhalt als Laufwerk D: wie eine zusätzliche Festplatte eingebunden.

Plug & Play gibt es nicht. Das System muss heruntergefahren werden, um den Stick zu wechseln und der neue Stick vor dem nächsten Start entsprechend eingesteckt sein.

Fazit

Ah, es fühlt sich an wie damals … also echt langsam. Aber meine alten DOS-Spiele laufen auf dem 40 MHz System doch noch um einiges besser und schneller als am Book8088.

Und der Support für 32-bit Code macht es nun auch möglich eine gesamte FreeDOS Installation auf dem Pocket386 zu installieren. (Einige FreeDOS Tools sind nur für 32-bit kompiliert.)

In Summe ergänzen sich die beiden Brüder perfekt für Retro-Computing Aufgaben. Und besonders die Unterstützung von externen Eingabegeräten und einem Monitor holen diese Museums-Repliken ins aktuelle Jahrhundert zurück.

Arch Linux Keys

2024-05-12T13:00:00+02:00

Da installiere ich mir Arch Linux als WSL Distro und möchte ein Update mit pacman -Syu durchführen.

Schon erscheinen zahlreiche Fehler nach dem Schema:

error: curl: signature from “Someone someone@archlinux.org” is unknown trust
:: File /var/cache/pacman/pkg/something-x86_64.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)).

Lösung: pacman-key

Nach etwas Herumsuchen findet man die Lösung:

1pacman-key --init
2pacman-key --populate
3pacman-key --refresh-keys

Hier läuft dann --refresh-keys recht lange und holt sich, was es kriegen kann (obwohl auch hier noch manchmal Error im Output steht).

Doch danach lässt sich pacman -Syu und auch jedes andere pacman -S PACKNAME problemlos ausführen.

Fazit

Ich hatte ArchLinux schon vor einigen Monaten mal auf WSL bringen wollen und brach demotiviert wegen der fehlerhaften Key-Sache ab.
Reguläre Installationen von offiziellen Medien funktionierten, aber das WSL Image dürfte wohl veraltet sein.

Eigentlich gefällt mir so etwas gar nicht, wenn ein OS so geliefert wird, dass es ohne Fachwissen unbenutzbar ist. Doch zum Glück hat die Community das Problem gelöst … jetzt muss sich das Wissen nur noch überall hin verbreiten.

In diesem Sinne:

Verbreitet die Zeilen:
pacman-key --init
pacman-key --populate
pacman-key --refresh-keys

ZIG und C's undefined-behavior

2024-05-05T13:00:00+02:00

Ich baue meine Win32 App mit MSVC: läuft.
Ich baue meine Win32 App mit MinGW: läuft.
Ich baue meine Win32 App mit CLANG: läuft.
Ich baue meine Win32 App mit ZIG: Prozess weg.

W-T-F? Was macht ZIG, das auf LLVM aufsetzt, anders?

Spoiler: ZIG ist einfach nur genial!

Finde den Fehler:

 1void foo(char const* ptr_chars, size_t slice_offset) {
 2  assert(
 3    ((ptr_chars == NULL) && (slice_offset == 0))
 4    || (ptr_chars != NULL)
 5  );
 6
 7  char const* const ptr_char = ptr_chars + slice_offset;
 8
 9  if(ptr_char != NULL) {
10    do_something_with(*ptr_char);
11  }
12  else {
13    printf("Nothing to do");
14  }
15}

Unser assert() geht immer OK durch, weil entweder beide Funktionsparameter gesetzt sind, oder beide auf NULL bzw 0 verweisen.

Leider führt zig cc in der Folgezeile manchmal ein abort() aus.

Und der Grund lautet auf:

Undefiniertes Verhalten

Setzt man die Zeile
char* ptr_char = ptr_chars + slice_offset; stur in Maschinensprache um, ist auch alles perfekt in Ordnung, denn entweder entsteht ein nicht-NULL-Pointer zu Daten oder ein NULL-Pointer (weil dann ja beide Parameter 0 sind).

Der nachfolgende Code prüft auf den NULL-Pointer und sortiert ihn beim Auftreten aus.

Doch leider darf man mit NULL Pointer nur zwei Dinge machen:

Man darf sie zuweisen
my_ptr = NULL;
Man darf sie mit anderen Pointern vergleichen
if(my_ptr == NULL)

Der Fehler liegt bereits in der Addition, denn wenn ptr_chars schon NULL ist, darf man keinen Wert addieren, subtrahieren oder anders verknüpfen.

Rein logisch ist NULL + 0 wieder NULL, und zur Laufzeit stimmt das auch.

Doch wenn der Compiler schon beim Übersetzen nachvollziehen kann, dass beide Parameter auf NULL bzw. 0 gesetzt werden, dann weiß er, dass es sich bereits um undefiniertes Verhalten handelt und dann darf er auch jeden beliebigen Blödsinn machen.

zig cc bricht dann den Prozess ab, während meine anderen Compiler einen durchlaufenden Prozess ermöglichen.

Lösung

 1void foo(char const* ptr_chars, size_t slice_offset) {
 2  assert(
 3    ((ptr_chars == NULL) && (slice_offset == 0))
 4    || (ptr_chars != NULL)
 5  );
 6
 7  if(ptr_chars == NULL) {
 8    printf("Nothing to do");
 9    return;
10  }
11  else {
12    char const* const ptr_char = ptr_chars + slice_offset;
13    do_something_with(*ptr_char);
14  }
15}

Wenn wir einen NULL-Pointer haben, darf er nicht angefasst werden, nur Vergleiche sind zulässig.

Solche Pointer-Additionen kamen bei mir leider vor, und zwar auch bei “wissentlich” leeren Objekten und diese waren schlicht falsch.
(Liebe Grüße vom Leer-String-Objekt!)

Fazit

zig, ich liebe dich!

Alle Tools und Tests laufen jetzt auch durch, wenn sie von zig cc gebaut wurden.

Natürlich kann man darüber diskutieren, dass manche Compiler den Begriff des UB (Undefined Behavior) überinterpretieren.
Täten sie genau das, was ich ihnen vorschreibe, wäre alles in Ordnung.

Doch so ist es nicht. UB Regeln sind absolut relevant und ich bin echt froh, dass mich zig nun auf ein altes “Denkproblem” aufmerksam gemacht hat.

zig hat damit maßgeblich die Korrektheit und Speichersicherheit im GATE Framework verbessert.

Bildausschnitte per Line-Padding

2024-04-28T13:00:00+02:00

Die Arbeit mit meinem Book8088 inspirierte mich mein Grafik-Konzept zu überdenken:
Ein Rasterimage ist nicht ein Array of Pixels,
es ist ein Array of Pixel-Lines.

Und daraus folgt: Ein Bildausschnitt ist
Originalbild + Offset + Padding

Ich wollte im GATE Framework “ein” generisches Bildformat haben, und das sollte RGBA (32-bit) sein.
Jedes beliebige Format kann man nach RGBA konvertieren und somit wird die Bildmanipulation nur noch auf RGBA durchgeführt.

Doch dann kam DOS.

Über die unterschiedlichen komplizierten Speicherformate von EGA/VGA/SVGA usw. Bildern könnte man Bücher schreiben und es ist ein Segen, dass wir uns in Windows, Linux, X11 oder OpenGL nicht mehr um solche Details kümmern müssen.

Der Mode 13 war der einzige VGA-Modus, in welchem 256 Farben als lineare Paletten-Pixel Werte im Speicher abgelegt werden konnten und so mit einer Auflösung von 320 x 200 Pixel ein bisschen Grafik am DOS-PC ohne Aufwand produziert werden konnte.

Und genau aus diesem Grund sind 8-Bit Farbpaletten Grafik neben RGBA nun ein weiteres “generisches” Format, dass ich unterstütze.
Denn so passt ein Bildschirm-Inhalt in ein einziges 64-KB Segment.

Performance Problem

Doch die Idee, ich könnte einen Framebuffer mit den vollen 320 x 200 Pixeln bearbeiten und dann als ganzes ins Video-RAM (0xa000:0) kopieren, scheitert am 8 MHz Prozessor: Denn das dauert ewig … aus Sicht des Gamers.

Dass das Kopieren von 64000 Bytes messbar lange dauert, kann sich heute kaum jemand mehr vorstellen.
Doch die Lösung ist oft einfach: Man überträgt nur Änderungen.

Bei Spielen ändert sich nicht immer gleich der ganze Bildschirm-Inhalt, es werden meist nur einige wenige Figuren verschoben.
Doch wenn man jetzt ein großes Bild in einzelne separate Teilbilder zerlegt, fragmentiert und vergrößert man den Speicherverbrauch.

Ein besseres Pixel-Layout

Was wäre, wenn man (wie bei Strings und String-Views) den Inhalt eines Speicherblocks mehreren Konsumenten gleichzeitig anbietet?

Man “verkauft” Ausschnitte eines großen Bildes als mehrere Teilbilder, obwohl die nur das Originalbild “mit anderen Abmessungen” benutzen.

Bisher bestand ein Bild bei mir aus einer Breiten- und Höhenangabe und einem Pointer auf die Rohdaten. Pixelpositionen ergaben sich nach der Formel:
pixel_pointer = start_pointer + y * width + x

Führt man aber noch einen line-padding Wert ein und betrachtet ein Bild nicht als fixen Block, sondern als ein Array von Zeilen, dann bekommt man eine Bildzeile per:
pixel_pointer = start_pointer + y * (width + padding) + x

Man muss jetzt zwar bei jedem Zeilenwechsel (y) den Pointer neu berechnen, doch nun können Unterbilder über Pointer und Padding auf das Originalbild verweisen.

Neues altes Interface

Mit diesem Update kann ich nun beliebige Raster-Rahmen-Objekte für die gleichen Bilddaten erstellen und Reference-Counting sichert die korrekte Nutzung und Freigabe der Ressourcen.

Die einzige Änderung ist, dass man nun nicht mehr das Bild als einen fetten Puffer bearbeiten kann, sondern immer nur Zeilenweise.

Das ist tatsächlich auch wieder ein Overhead, aber dieser fällt hier wenig bis gar nicht auf.
Denn anstatt in separate Speicher zu zeichnen und diese dann zusammenkopieren zu müssen, wird alles in einen Block (aber an die richtige Stelle) geschrieben.

Fazit

Und wieder hat mir die “alte Welt” eine Lehre erteilt.
Man muss nicht Megabytes an Daten generieren und dann wieder wegwerfen, sondern man kann durch “Kooperation” mit einem Bruchteil der Ressourcen zum gleichen Ergebnis kommen.

Oder anders formuliert:

Wir brauchen weniger Speicher
Wir nutzen daher Caches besser
Wir reduzieren Kopien drastisch
Wir erhöhen den Durchsatz
Wir reduzieren den Strombedarf

… das bräuchten wir auch bei der Klima- und Umweltdebatte.

Ranish Partition Editor

2024-04-21T13:00:00+02:00

Der Ranish Partition-Manager gehörte vor dem Jahr 2000 zu meiner “Standardinstallation” unter DOS.
Dieses Miniprogramm lässt eine jede MBR Festplatten-Partition und jedes FAT Dateisystem inspizieren und manipulieren.

Dennoch hatte ich immer Angst vor diesem mächtigen Werkzeug.

Mit fdisk hatte MS-DOS zwar seinen eigenen Partition-Manager, aber der taugte nur zum Einrichten einer primären und einigen sekundären (erweiterten) Partitionen.

Ich wollte aber mehrere Betriebssysteme (DOS, Win95, NT4) auf einem PC haben und musste daher recht “perverse” Installations-Methoden durchführen. Denn fdisk konnte nur mit einer primären Partition umgehen, von der man letztendlich booten konnte.

Zuerst Windows NT installieren (erste primäre Partition) auf NTFS Basis
Mit NT 2 weitere primäre Partitionen anlegen. (Unter NT ging das zum Glück.)
Aktive Boot-Partition auf Nr. 2 setzen.
Dann per Diskette DOS auf die neue Boot-Partition installieren.
Per fdisk die 3. Partition auf “Aktiv” setzen.
Nun per Win95-Bootdiskette starten und Windows 95 Installation einleiten.
Am Ende vom DOS-Modus aus vamos installieren, um beim Boot die aktive Partition per Menü auswählen zu können.

Und weil DOS ja nur innerhalb der ersten 2 GB booten kann, durfte die NT-Partition nicht zu groß sein.

Es war eine Katastrophe.

Die Suche nach Partitionverwaltungstools

ranish war damals schon auf diversen CDs von Computer Magazinen und fand so schnell einen Platz bei mir.

Doch weil ranish sooo “Low-Level” gestaltet war, war die Zerstörung einer Installation bei mir quasi vorprogrammiert.

Man kann alle Einträge des Master-Boot-Records frei editieren und damit auch jede Menge Blödsinn einstellen. Das fängt bei falschen Werten für C-H-S (Cylinder-Head-Sector) Werten für den Anfang und das Ende von Partition an und hört bei falschen Partitionstypen auf.

Das merkte man natürlich erst beim nächsten Reboot, wo die Festplatte nicht mehr startbar oder lesbar war und nur noch durch eine “professionelle Nutzung” von ranish von der Bootdiskette mit Glück wiederhergestellt werden konnte.

Merksatz: Immer zuerst eine Diskette oder bootfähige CD mit Reparatur-Tools anlegen, bevor man am System herumspielt.

Kurz danach erhielt ich mit PQMagic (PowerQuest Partition Magic) ein grafisches Werkzeug, mit dem Fehlkonfigurationen ziemlich gut ausgeschlossen werden konnten und nutzte dieses primär.

ranish blieb aber immer als Fail-Safe-Tool bei mir, weil es so herrlich klein war und direkten Einblick in den MBR boot.

Ranish für das Book8088

Neue Freude mit ranish habe ich heute … also 25 Jahre später. Denn es stellte sich heraus, dass CF-Karten für mein book-8088 nicht erkannt werden, wenn sie mit Windows formatiert werden.

Die MBR Einträge von heutigen Tools werden auf größere Lese-/Schreibkopf Werte gesetzt, als das uralte BIOS verkraften kann. Hier dürfen nicht mehr als 16 Köpfe und 1024 Sektoren benutzt werden.

Es scheint auch so zu sein, dass sich der CF-Controller bzw. die Software an den MBR-Einträgen orientiert, wenn aus dem linearen Flash-Speicher eine C-H-S-Adressierung emuliert wird.

Hier konnte ich also mit Ranish eine Partition auf einem 2 GB Modul künstlich anlegen, die von C-H-S (0, 1, 1) bis C-H-S (952, 15, 63) reichte und somit etwa 470 MB groß war und vom alten BIOS erkannt werden konnte.

Ohne diesen Trick hätte ich nur noch 256 MB Karten benutzen können, denn selbst CF Karten mit 512 MB sind bereits um ein paar Bytes zu groß und würden mit einer Kopf-Anzahl jenseits von 16 behandelt werden.

Fazit

ranish ist sogar heute noch als Open-Source Software verfügbar, und wurde vor nicht all zu langer Zeit auch auf Codeberg abgelegt.

Dass mir dieses puritanische Experten-Tool auch heute noch gute Dienste leistet ist faszinierend. Denn wo findet man heute noch Tools kleiner 100 KB, die Zugriff auf “alles” bieten.

Dem/den Macher/n, den Distributoren und Magazin-Autoren von damals spreche ich jedenfalls meinen Dank für dieses Juwel aus.

Book 8088

2024-04-14T13:00:00+02:00

4 bzw. 8 MHz und 640 KB RAM!
China hat es geschafft in den 2020ern einen Laptop aus Bauteilen und Standards der 1980er auf den Markt zu bringen.

Ich bin wieder in den 80ern … also eigentlich noch vor “meiner Zeit”, und damit genau “in meiner Zeit”, denn den ersten PC, den ich in den 90ern in der Schule zu Gesicht bekam war ein IBM PC XT.

Das Book8088 ist seit einigen Monaten auf AliExpress zu finden und schwankt dort ja nach Anbieter, Versandkosten und Zubehör zwischen 180 und 280 Euro.

Ich bin froh die günstigst Variante erstanden zu haben, denn der Zoll ballert dann ohnehin nochmal 80 Euro drauf. Aber dann hatte ich endlich auch wieder einen neuen alten PC mit 8088 kompatiblen Prozessor vor mir.

Hardware

In einem 24,5 cm x 15 cm und 3 cm hohen zusammengeklappten Plastikgehäuse sind ein 7-Zoll Display, eine Tastatur und ein Mainboard mit einem NEC V20 Prozessor verbaut, der Pin- und Instruktionen-kompatibel zum Intel 8088 ist und sogar etwas höher getaktet werden kann.

Unter der Tastatur lässt sich der Prozessor und auch eine OPL3-Soundkarte über 2 Plastikklappen freilegen, und auch noch optional ein 8087 Koprozessor einstecken, falls wer noch einen zu Hause hat.

Auf der Unterseite finden werden ebenfalls zwei Klappen um den Akku und die Grafikkarte austauschen zu können.

Da hat jemand “modular” mitgedacht. Respekt!

Mit 4000 mAh kann man die Maschine schon eine Zeit lang ohne Stromkabel laufen lassen. Wie lange weiß ich nicht, aber die eine oder andere Stunde konnte ich damit schon kabellos “arbeiten”.
Aufgeladen wird der Laptop über ein 12V Ladegerät mit 1.5 Ampere.

Hinweis: Die Plastikklappen sollte man aber nur wenn nötig öffnen, denn das Material sieht nicht so aus, als könnte es zahlreiche Öffnungsvorgänge lange überleben.

Die Rückseite legt einen seriellen COM-Port und einen Parallel-Port frei, womit Kommunikation durchgeführt und auch eine klassische Maus angeschlossen werden kann.

Rechts finden wir einen Pin-Steckplatz um auch noch eine ISA 8-bit Erweiterungsplatine anzukoppeln, über die man dann echte ISA-Karten an das Gerät anschließen kann.

Genial!

Auf der linken Seite lässt sich eine CompactFlash Karte als Festplatte einschieben, und über einen USB-Port erhält man sogar die Möglichkeit einen USB-Stick in Betrieb zu nehmen. Der USB-Port wird aber nicht vom BIOS erkannt, sondern braucht einen eigenen DOS-Treiber, der ihn als zusätzliche Festplatte fest einbindet.
Eine USB-Maus oder -Tastatur lassen sich damit nicht betreiben.

Außerdem zeigen ein paar LEDs den Ladezustand oder CF-Karten Zugriffe an.

Software

Die beigelegt 256 MB große CF-Karte wird vom BIOS erkannt und ist mit MS-DOS 6.22 und Windows 3.0 und einigen alten DOS-Spielen befüllt.

Ein Laufwerk A: gibt es leider nicht, doch durch den DOS-USB-Stick-Treiber lassen sich Programme auch so auf die CF-Karte im Betrieb übertragen.
Da es kein Plug&Play gibt, muss bei jedem Stick-Wechsel neu gestartet werden.

Windows 3.0 im Schwarz-Weiß Modus ist die letzte Variante, die auf einer alten 8088 CPU mit 640 KB RAM lauffähig ist.
Der Start ist allerdings kein Vergnügen und lässt mich an die Zeit zurückdenken, wo es üblich war, dass man nach einem ENTER die Hand von der Tastatur nehmen konnte … denn es dauerte eine Weile, bis Programme vollständig geladen waren.

Turbo Modus

Mit der Tastenkombination Fn + F6 lässt sich der CPU-Turbo aktivieren, womit die CPU auf 8 MHz hochtaktet und damit fast doppelt so schnell läuft, wie die ursprünglich üblichen 4.7 MHz.

Bei Spielen wie Prince of Persia merkt man den Turbo sofort. Während ohne Beschleunigung der Spieler nur träge vorankommt, erreicht man mit 8 MHz einen halbwegs flüssigen Verlauf.

Fazit

Ich liebe dieses Gerät.

Ja, wir haben Emulatoren und können auf 24+ Zoll Monitoren mit DOSBoX “spielen”, aber nichts fühlt sich realistischer an, als ein echter Prozessor mit den Limits von damals.

Software Hersteller waren seinerzeit wahre Künstler und schafften es ihren Code in dieser eingeengten Umgebung lauffähig zu halten. Kein Byte wurde verschwendet, kein Taktzyklus geopfert.

Ein Lob auf die kreativen Köpfe, die sich dieses neue Laptop-Board-Design überlegt haben und dort alte wie neue Chip-Reserven für uns Retro-Fans verbaut haben.

Und dann kamen SystemD Services...

2024-04-07T13:00:00+02:00

systemd ist die Zukunft. Alle neuen Linux Dienste nutzen diesen Standard um sich im System zu registrieren.

Auch falsch! (Langsam zeichnet sich ein Muster ab.)

Mir bleibt wirklich gar nichts erspart, und somit kommen jetzt (beruflich wie privat) auch noch .service Dateien in meine Welt.

Eigentlich ist systemd der ausgereifteste Ansatz, wie man Dienste verwalten kann. Denn hier werden nicht lose Scripts irgendwie ausgeführt, sondern ein verwalteter und definierter Hauptdienst startet und verwaltet alles Andere.

Init-Scripts sind quasi selbstverantwortlich, wie sie ihre zugehörigen Prozesse starten. Ob hier 1x oder 2x gefork()t wird, ob man den Account wechselt, das ist alles ein Script-Geheimnis.

systemd versucht uns alle Optionen als Konfiguration zur Verfügung zu stellen, so dass wir einfach nur noch Variablen (bzw. Einstellungen) setzen und kein selbstgeschriebener Code mehr notwendig ist.

Man legt quasi eine INI-Datei, als “Service-Unit” im Verzeichnis /etc/systemd/system/ an, deren Inhalt beschreibt, wie der Daemon gestartet werden soll.
Beispiel: /etc/systemd/system/myserviced.service

[Unit]
Description=MyService Daemon
Requires=other_daemon1,other_daemon2

[Service]
Type=exec
ExecStart=/usr/bin/myserviced

[Install]
WantedBy=multi-user.target

Der exec Typ

Es gibt mehrere “Typen” von Diensten, und exec ist (neben dem ähnlich Typ simple) der einfachste, weil sich hier systemd um die gesamte Laufzeit kümmert.
Es startet den Prozess im Hintergrund und überwacht ihn. Wird von außen die Beendigung eingefordert, schickt systemd die notwendigen Standard-Signale an den Prozess.

Der oneshot Typ

Manchmal bedeutet “Dienst” auch nur “eine-Aktion-und-fertig”. Genau dafür ist der oneshot-Typ erschaffen worden. Das ausgeführte Programm darf sich nämlich nach seiner “Aktion” beenden, aber systemd behandelt den Dienst weiter als “laufend”, obwohl gar kein Prozess mehr am Arbeiten ist.

Das hilft einem vor allem bei Abhängigkeiten, wenn ein Dienst einen anderen braucht. Wird nämlich ein Dienst beendet, beendet systemd auch alle von ihm abhängigen Dienste.
Mit oneshot lässt sich so eine Kette von Aufgaben bilden, die hintereinander ausgeführt werden, die sich aber nach ihrem Ende nicht gegenseitig abbrechen.

Der forking Typ

Viele alte Init-Script Daemons haben sich selbst verwaltet, also sich selbst gefork()t, und für solche Fälle ist dieser Typ gut geeignet. Hier kann man dann eine PID-Datei und eine Beendigungsroutine konfigurieren, um geforkte Dienste zu beenden:

[Unit]
Description=MyService Daemon
Requires=other_daemon1,other_daemon2

[Service]
Type=forking
ExecStart=/usr/bin/myserviced --start-me
ExecStop=/usr/bin/myserviced --kill-me
PIDFile=/var/run/myserviced.pid

[Install]
WantedBy=multi-user.target

Und vieles mehr

Dann gibt es da noch diverse andere Typen, die über dbus mit ihrem Prozess kommunizieren, aber die sind für meine Zwecke zu komplex.

Außerdem lassen sich in systemd Service Dateien jede Menge Sonderfälle spezifizieren wie:

Wiederhole den Start X mal, wenn sich der Prozess beendet/aufhängt.
Interpretiere/Ignoriere den Exit-Code eines Prozesses anders.
Führe ein anderes Programm/Script vor oder nach dem Daemon-Prozess aus.
Definiere Timeouts, wie lange Einzelschritte dauern dürfen.
Festlegung, ob oder welche Kindprozesse mitüberwacht und mitverwaltet werden sollen.
Wechsele den Account, das Verzeichnis oder das Environment
Definition von Abhängigkeiten, was vor oder nach wem gestartet wird, und was automatisch wieder beendet werden soll, wenn der eigene Dienst terminiert.
usw., siehe: systemd.service

Nutzung von systemctl

Das Zentrale Tool zur Verwaltung ist systemctl.
Ist eine .service Datei angelegt, werden mit systemctl daemon-reload alle Service-Dateien eingelesen und integriert.

systemctl enable myserviced.service aktiviert das Service für den automatischen Start.

Mit systemctl start|stop|status myserviced lässt sich wie mit klassischen Init-Scripts ein Daemon starten, stoppen oder dessen aktueller Status ausgeben.

Fazit

Tja, wie schon mal gesagt:

systemd ist super, aber…

Ich werde also künftig .service Dateien mit Typ forking anlegen, die aber auf meine alten Init-Scripts verweisen.

Der Grund dafür: Docker
Leider ist systemd nicht ohne Workarounds in Docker-Containern nutzbar, Init-Scripts funktionieren dort aber wie gehabt.

Es macht für mich also Sinn, das “neue” System mit meiner “alten” Technik zu verbinden.

Aber gäbe es die Container-Einschränkung nicht, wäre systemd vermutlich genau das, was ich in Linux immer vermisst habe und was in Windows seit NT 4 Standard ist:
Nämlich eine ordentliche Instanz zur zentralen und einheitlichen Verwaltung von System-Diensten.

OpenBSD Daemons registrieren

2024-03-31T13:00:00+02:00

OK, FreeBSD und NetBSD verwalten ihre Daemons fast identisch.
Perfekt! Somit kann ich mit einem Daemon-Script-Skelett alle BSDs behandeln.

Wieder falsch!
Denn OpenBSD setzt auf “leicht andere” Variablennamen.

Und wieder fließen weitere ifdef XXXBSD statements in meine Codebase.

Ich hätte erwartet, dass OpenBSD die “antiksten” Scripts mit dem geringsten Ausbau an gemeinsamen Funktionen bereitstellt.
Doch Fehlanzeige.

OpenBSD setzt auf Funktionen anstatt von Variablen und wirkt damit fast objektorientiert und modern.

Ein Beispiel-Script sieht so aus:

 1#!/bin/sh
 2
 3daemon="/usr/local/bin/myserviced"
 4daemon_flags="--optional_daemon_flag=value"
 5
 6. /etc/rc.d/rc.subr
 7
 8rc_start() {
 9  ${rcexec} ${daemon} ${daemon_flags} &
10}
11rc_check() {
12  get_myserviced_status()
13}
14rc_stop() {
15  kill_or_whatever_myserviced()
16}
17
18rc_cmd $1

Hier schreibt man also rc_* Funktionen um die notwendigen Schritte für’s Starten, Stoppen und Status-Abfragen ausführen zu lassen.
Wenn aber rc_check() und rc_stop() weggelassen werden, so versucht rc_cmd diese Funktionalität “handelsüblich” auszuführen.

Das Tool rcctl erhält in OpenBSD auch noch ein paar Zusatzfunktionen:

rcctl start|stop|status daemon_name verhält sich “wie gewohnt”.
rcctl enable daemon_name aktiviert den automatischen Start beim Boot.
und rcctl disable daemon_name deaktiviert die Ausführung des Scripts.

Fazit

OpenBSD weicht somit vom Verhalten von Free/NetBSD ab, tut dies aber in einer mir sehr sympathischen Art und Weise.

Wenn ein minimales Init-Script nur noch so aussieht:

 1#!/bin/sh
 2
 3daemon="/usr/local/bin/myserviced"
 4daemon_flags="--optional_daemon_flag=value"
 5
 6. /etc/rc.d/rc.subr
 7rc_start() {
 8  ${rcexec} ${daemon} ${daemon_flags} &
 9}
10
11rc_cmd $1

dann hat OpenBSD für mich eindeutig den Init-Script-Contest gewonnen.

Wie auch immer … im GATE Framework sind meine Prozesse ja eigenverantwortlich, somit nutzen die 3 Funktionen meinen Daemon-Prozess selbst um den Status zu ermitteln.

BSD Daemons registrieren

2024-03-24T12:00:00+01:00

BSD und Linux sind beides Unix-Kinder, also sehen die intern recht ähnlich aus…

Falsch!
Ich bin immer wieder überrascht, wie unterschiedlich sich diese beiden Brüder entwickelt haben.

Und mich zwingt das jetzt in die Situation, dass ich alle Daemon-Scripts doppelt schreiben muss.

Die BSD Blutlinie hat sich ja leider auch aufgespalten in OpenBSD, NetBSD und FreeBSD.
Fangen wir mal Net- und FreeBSD an, denn bei deren DNS sieht man noch direkter die Verbindung.

Init Scripts in FreeBSD und NetBSD

BSD Init Scripts liegen in /etc/rc.d/und sehen im Wesentlichen so aus: (Ein Code sagt mehr als 1000 Worte)

 1#!/bin/sh
 2
 3# PROVIDE: myserviced
 4# REQUIRE: dependent_from_daemon
 5
 6
 7#include OS-script functions:
 8. /etc/rc.subr
 9
10#set required variables:
11name=myserviced
12command="/usr/bin/myserviced"
13command_args="--my_additional_arg=value"
14pidfile="/var/run/myserviced.pid"
15start_cmd="/usr/bin/myserviced whatever_start_arg $command_arg"
16stop_cmd="whatever_daemon_stop_function"
17
18#execute OS-daemon start scripts
19load_rc_config $name
20run_rc_command "$1"

Das Geheimnis liegt also darin Variablen zu befüllen, die den System-internen Scripts sagen, wie man den Dienst wirklich startet und dann führt man diese Funktionen (run_rc_command) einfach aus.

Mit den PROVIDE und REQUIRE Meta-Kommentaren lässt sich auch eine einfache Abhängigkeitskette bilden und durch die Variablen sehen BSD Scripts eigentlich immer recht aufgeräumt aus.

Eine separate Registrierung der Scripts ist nicht erforderlich, die bloße Präsenz in /etc/rc.d/ reicht aus.

Beim konkreten Starten und Stoppen gibt es schon Unterschiede:

In FreeBSD nutzt man rcctl start|stop|status daemon_name.
Während in NetBSD die Scripts direkt aufgerufen werden mit:
/etc/rc.d/daemon_name start|stop|status

Fazit

Im GATE Projekt lasse ich ja meine eigenen Daemons selbst forken, womit der Start nur ein Aufruf ist und ein Stoppen durch kill umgesetzt werden kann.

In Summe ist ein solches BSD Init Script auch trotz einiger Unterschiede recht einheitlich aufgebaut.

Linux Daemons registrieren

2024-03-17T12:00:00+01:00

Wer richtet eigentlich Daemons (also Hintergrunddienste) in Linux ein?

Antwort: Die Distributionsmacher scripten sich das zusammen, wie sie es brauchen.

Aber was macht man als “3rd Party Developer?”

Die daemonize() Funktion ist nur der halbe Weg, man muss auch sicherstellen, dass der Daemon beim Start des Systems hochgefahren wird.

Init-Scripts und die LSB

Im klassischen Linux gibt es einen ungeschriebenen Standard für das Verwalten von Daemon-Scripts.

Ein Daemon mit Namen myserviced …

… liegt als Binär-Datei in /usr/bin/myserviced
… hat ein init-Script in /etc/init.d/myserviced
… nutzt eine PID-Datei mit Namen /var/run/myserviced.pid

Aus der Linux-Standard-Base hatte ich dann folgenden Aufbau abgeleitet:

 1#!/bin/sh
 2### BEGIN INIT INFO
 3# Provides:          myserviced
 4# Required-Start:    $local_fs $network $named $remote_fs $syslog
 5# Required-Stop:     $local_fs $network $named $remote_fs $syslog
 6# Default-Start:     3 4 5
 7# Default-Stop:      0 1 2 6
 8# Short-Description: myserviced service process
 9# Description:       myserviced is known best for healing cancer
10### END INIT INFO
11
12PATH=/sbin:/usr/sbin:/bin:/usr/bin
13NAME=myserviced
14DAEMON="/usr/bin/$NAME"
15DAEMON_ARGS=
16PIDFILE="/var/run/$NAME.pid"
17SCRIPTNAME="/etc/init.d/$NAME"
18
19#import init functions
20. /lib/lsb/init-functions
21
22do_start()
23{
24  start_daemon -p $PIDFILE $DAEMON $DAEMON_ARGS
25}
26
27do_stop()
28{
29  killproc -p $PIDFILE $DAEMON
30}
31
32do_statuscheck()
33{
34  pidofproc -p $PIDFILE $DAEMON
35}
36
37case "$1" in
38  start)
39    do_start
40    ;;
41  stop)
42    do_stop
43    ;;
44  force-reload|reload|force-restart|restart)
45    do_stop
46    do_start
47    ;;
48  status)
49    do_statuscheck
50    ;;
51  *)
52    echo "Usage: $SCRIPTNAME {start|stop|restart|status}"
53    exit 1
54    ;;
55esac

Das funktionierte auf manchen Distros, aber nie auf allen, und so musste ich aus-if-en, ob /lib/lsb/init-functions überhaupt vorhanden war und Workarounds für die Sonderfälle schreiben.

Ein paar solcher Alternativen sind:

start-stop-daemon
Das sieht man auf auf Debian
startproc
Dieser non-Standard kam mir in SuSE unter
$DAEMON $DAEMON_ARGS &
So startet man Daemons, wenn man nicht mehr weiter weiß.
read PID < $PIDFILE
ps -p $PID > /dev/null 2>&1
… um zu wissen, ob der Daemon schon läuft

Noch schlimmer: auf etwas warten:

 1COUNTER=0
 2while [ $COUNTER -lt 50 ]; do
 3  if some_check_function;
 4  then
 5    sleep 0.1
 6    COUNTER=$((COUNTER+1))
 7  else
 8    COUNTER=$((COUNTER+50))
 9  fi
10done

Und noch einige andere Schweinereien

Script registrieren

Irgendwo liegt das Tool update-rc.d, z.B. in

/sbin
/usr/sbin
/bin
/usr/bin

und hat man es gefunden, kann man es aufrufen mit

1update-rc.d myserviced defaults
2update-rc.d myserviced enable

Erst jetzt ist das Init-Script im System registriert und wird automatisch ausgeführt, wenn das System startet (bzw. den richtigen Run-Level erreicht).

Teilweise Übergang zu systemd

Dieser ganze Zauber wurde zwischen 2010 und 2020 durch SystemD ersetzt … aber das ist eine andere Geschichte.

Doch weil es bis heute Umgebungen ohne systemd gibt, wie z.B. Docker oder WSL 1, sind Init-Scripts für Daemons immer noch ein Thema und in Debian funktionieren die alten Tools bis heute.

Fazit

Kurz gesagt:

Nichts ist so unsäglich zersplittert wie das Daemon- und Initialisierungs-System von Linux.

(OK, Paket-Manager könnten das noch toppen.)

Jede Distribution wollte ihre Individualität einfließen lassen und so wurden über Jahrzehnte unzählige Arbeitsstunden für die Portierung verbraten.

Am Ende geht es aber immer nur darum:

Starte einen Prozess im Hintergrund.
Setze den Exit-Code so, dass 0 Erfolg und alles andere Misserfolg ausdrückt.

Klingt komisch … ist aber so.

JPEGs aus Minimum runterdrücken

2024-03-10T12:00:00+01:00

Auf Codeberg Pages kann man ja ganz toll Webseiten hosten, die einfach in einem Repository eingecheckt sind.
Für statischen HTML Kram ist das super, aber was macht man mit Bildern?

Um jetzt nicht alles unnötig aufzublähen, setzte ich mir ein Ziel:

Meine JPEGs müssen so klein wie möglich werden!

Als Entwickler wäre meine Antwort jetzt: libjpeg! Hier kann man die Kompressionsstärke per jpeg_set_quality() auf einen Wert zwischen 0 und 100 Prozent setzen.

Doch da die öffentliche API im GATE-Framework nur 4-bit Kompressions-Stufen (also 16 Zustände) zulässt, müsste ich jetzt einen weiteren Finetuning Kanal nach außen legen, und deshalb soll das ganze einfacher funktionieren.

cjpeg kann auch Bilder komprimieren

Das Tool cjpeg hat bereits die erforderliche Funktionalität und kann wie folgt installiert werden:

1apt install libjpeg-progs

Es liest eine unkomprimierte Datei (zB. .bmp), komprimiert die Bilddaten im JPEG Format und gibt das Ergebnis auf der Konsole aus.

Der Aufruf

1cjpeg -quality 4 input.bmp > output.jpeg

lässt den Inhalt von input.bmp mit der Qualität von 4% auf die Konsole schreiben, welche im Beispiel in die Datei output.jpeg umgeleitet wird.

Auf diese Weise kann man sich schnell ein Script schreiben, das alle *.jpeg Dateien durchläuft, per djpeg als Bitmap speichert und diese dann mit der neuen Kompression wieder in eine JPEG verwandelt.

JPEG zu BMP und zu neuer JPEG konvertieren

1djpeg -bmp input.jpeg > temp.bmp
2cjpeg -quality 4 temp.bmp > output.jpeg

JPEG direkt konvertieren per Pipes

1djpeg input.jpeg | cjpeg -quality 4 > output.jpeg

Warum 4% ?

Ich konnte nun etwas experimentieren und stellte fest, dass man ab 3% Qualität auf meinen Fotos ein Minimum an Inhalt erkennen konnte. Bei kleineren Werten wird es wirklich unkenntlich und größere Werte schlagen sich sofort in jeder Menge zusätzlicher Bytes nieder.

Mit 4 % konnte ich so die 45 MB an Bild-Dateien auf etwa MB runterdrücken, womit ich auch mein git Repository mit besserem Gewissen belasten kann.

Vergleich von JPEG Bild-Qualitäten

Original Bild ~75% (167 KB)

Qualität 10% (26 KB)

Qualität 8% (23 KB)

Qualität 6% (19 KB)

Qualität 4% (15 KB)

Qualität 2% (11 KB)

Fazit

Die JPEG Tools sind schon eine feine Beilage und ermöglichen eine schnelle Konvertierung von Fotos.

Ich erinnere mich noch gut an jene Zeiten, als Webspace-Hoster ihre Upload-Größen auf wenige 100 KB reduzierten (um das Jahr 2000). Damals saß ich lange vor Tools wie WebGraphics-Optimizer um alle Bilder “kleiner” zu speichern.

cjpeg hätte mir da viel Klickarbeit abnehmen können.
Erst die Programmierung mit libjpeg hat mich mit dessen erweiterten Tools bekannt gemacht.

SSH Public Key Logins

2024-03-03T12:00:00+01:00

Passwörter sind für mich immer noch das beste … weil ich sie im Gehirn speichern und überall hin mitnehmen kann.

Aber sicherer wären natürlich Zertifikate.
Auch beim Login auf SSH Servern.

Und wie ging das noch?

Die Idee dabei ist:

Ein User myuser generiert sich ein Schlüssel-Paar (Public + Private Key).
Der Public-Key wird auf den SSH-Server kopiert und mit dem dortigen Login-User ssh_user verknüpft.
Beim Login von myuser auf dem Server mit dem ssh_user, erkennt der Server, dass myuser’s Verschlüsselung zum verknüpften Schlüssel von ssh_user pass.
Und schon läuft die SSH Session wie gewohnt.

Einrichtung einer Public-Key Authentifizierung

Das Tool ssh-keygen erzeugt (falls nicht abgeändert) die beiden Dateien ~/.ssh/id_rsa und ~/.ssh/id_rsa.pub.

Der öffentliche Schlüssel muss jetzt “irgendwie” auf den SSH Server kopiert werden, entweder direkt, z.B.: per USB stick oder über eine andere SSH-Verbindung. Dort muss sein Inhalt in die Datei ~/.ssh/authorized_keys eingefügt werden, die im Homeverzeichnis des Ziel-Login-Useraccounts liegt.

Nachdem der Inhalt nur angefügt werden soll, reicht ein:

1mkdir -p ~/.ssh
2touch ~/.ssh/authorized_keys
3cat  /tmp/uploaded_data/id_rsa.pub >> ~/.ssh/authorized_keys

Das war es auch schon.
Ab sofort kann man sich per SSH über das Kommando:

1ssh -i ~/.ssh/id_rsa ssh_user@ssh_server_host_or_ip

einloggen.

Hinweis: Das SSH Tool erfordert, dass der private Schlüssel von keinem anderen User gelesen werden kann.
Ein chmod -c 600 ~/.ssh/id_rsa kann also noch erforderlich sein.

PuTTY

Das Tool putty verwendet ein eigenes Format und folglich muss der private SSH Schlüssel in eine .ppk Datei konvertiert werden.

Das mitgelieferte Programm PuTTY Key Generator erledigt das über seinen Load Button, wonach man nur noch auf Save private key klicken muss, und den Namen der neuen .ppk angeben muss.

In einer neuen PuTTY Sitzung wird unter
Connection - SSH - Auth - Credentials
dann der Pfad zur gespeicherten private-key Datei angegeben, und schon startet beim Connect eine Schlüssel-gesicherte Übertragung.

Fazit

Public-Key Authentifizierung funktioniert eigentlich gegengleich zu Passwörtern.

Bei einer Passwort-Authentifizierung muss ich das Passwort eines Accounts auf dem Server kennen, damit ich mich einloggen kann.

Bei der Public-Key-Authentifizierung muss im Server-Account ein Public-Key bekannt sein, der zu meinem lokalen privaten Schlüssel passt.

Passwörter kann man eher erraten als generierte private Schlüssel, von daher ist diese Methode sicherer und zu bevorzugen.

… aber wie schon gesagt … Passwörter haben die Vorteil, dass man sie im Gehirn speichern und mittragen kann.

LLVM bzw. CLANG

2024-02-25T12:00:00+01:00

MSVC und GCC begleiten mich jetzt bald 20 Jahre beruflich und privat in unterschiedlichen Softwareprojekten. Dann kommt noch ein bisschen Watcom für die Retro-Schiene hinzu.

clang und die LLVM Toolchain waren für mich bisher immer ferne Trabanten, die ich zwar immer wieder mal beobachtete, aber nie aktiv einsetzte.

Nun gut … so ganz stimmt das nicht. Ich setze ja immer mehr und mehr ZIG mit Leidenschaft ein, und da läuft ein LLVM-Derivat drinnen.

Und außerdem baut mein WASM Build mit embscripten auch mit clang im Hintergrund.

Aber: clang nutzt aber auf vielen Plattformen die nativen Compiler des Systems und ist daher ohne diese of unvollständig.

Auf der Ebene können alternative Tools zur Diagnose und eine bessere Optimierung eingefügt werden, aber das Rad wird damit nicht neu erfunden. Und deshalb nutze ich CLANG in der aktiven Entwicklung eher selten.

CLANG Installation

Ein übliches

1apt install clang llvm

oder

1winget install --id LLVM.LLVM

reicht aus, um clang auf dem System nutzen zu können. Hier braucht man dann natürlich noch einen entsprechenden GCC oder MSVC inklusive dessen Umgebungsvariablen, damit das Toolset benutzt werden kann.

CMAKE

Für CMAKE ist es erforderlich, die clang Executables als Compiler einzutragen. Ich mache das in der Regel über eine Toolchain-Datei:

 1set(CMAKE_SYSTEM_NAME Linux)
 2set(CMAKE_SYSTEM_PROCESSOR x86_64)
 3
 4set(target_id x86_64-linux-gnu)
 5
 6set(CMAKE_C_COMPILER clang)
 7set(CMAKE_C_COMPILER_TARGET ${target_id})
 8set(CMAKE_CXX_COMPILER clang++)
 9set(CMAKE_CXX_COMPILER_TARGET ${target_id})

CMake findet dann clang und über die Target-ID werden auch die richtigen Tools (im Fall von Cross-Compiling) benutzt um ein Projekt zu übersetzen.

1cmake -DCMAKE_TOOLCHAIN_FILE=path/to/clang.x86_64-linux-gnu.toolchain.cmake ...

Mit der CMake-Bedingung

1if(CMAKE_C_COMPILER_ID STREQUAL "Clang")
2  # clang-specific stuff
3endif()

lassen sich in CMake auch Sonderfälle für das Compiler-Interface definieren.

Fazit

LLVM und clang werden somit vom GATE Framework unterstützt. Ein paar Problemchen können bei Plattform-Header auftreten, die etwa bei einer GCC oder MSVC Suche in CMake gefunden werden und mit clang eben nicht.
Doch das hat man meist schnell gefunden und ge-patch-t.

Super finde ich die zusätzlichen Warnungen bei schlechtem Code, die mir schon einige Bugs aufgezeigt haben.

Nicht so gut finde ich die längeren Kompilier- und Link-Zeiten … aber für stabileren Code bezahle ich so einen Zusatz gerne.

Ein clang Build sollte also bei keinem Projekt fehlen, obwohl ich für Releases dann doch eher wieder zu den bewährten Standard-Compilern greife.

C structs Ausnullen

2024-02-18T12:00:00+01:00

Seit Ewigkeiten nutze ich
struct structtype instance = {0};
um Strukturen am Stack “generisch” mit Nullen zu initialisieren.

Doch … effizient ist das nicht, wenn man auf den generierten Code schaut.

Watcom’s DOS EXEn

Dass Programme “zu groß” sind fällt mir immer nur in der DOS Welt auf. Schließlich hat keiner mehr einen Überblick, ob die Windows CRT oder Linux GLIBC jetzt 100 oder 200 KB einfach nur so zum Spaß anhängen. Man akzeptiert den digitalen Müll einfach.

Aber wenn das Programm zum Auflisten eines Verzeichnisses plötzlich 50 KByte groß wird, und man weiß, dass es funktional nur wenige KB sein dürften, dann wird man wach.

Das tolle ist, dass Watcom beim Kompilieren immer sein .map Dateien anlegt, wo jede Funktion und jeder Datenblock mit Adresse und Größe in einer lesbaren Tabelle landet.
Und dort sind mir dann einige Blöcke aufgefallen, die mehrere Kilobytes groß waren.

Kopier-Schatten bei der Initialisierung

Wenn ich am Anfang einer C-Funktion die Variablen deklariere, werden die meistens ausgenullt. Bei structs führt ein = { 0 } dazu, dass alle Felder (und nicht nur das erste) ausgenullt werden.

Als ich spaßhalber mal eine der Initialisierungen entfernt hatte, sank sofort die Größe der EXE und auch die Ausdehnung des Datenbereiches in der .map Tabelle.

Offenbar erzeugt der Compiler einen statisch mit Nullen ausgefülltes Feld im Datenbereich und kopiert dieses bei der Initialisierung über die Variable auf dem Stack.
Das fällt natürlich bei Kleinkram niemandem auf, doch ich erzeuge ja gerne Puffer-Strukturen, die dann Member mit mehrere Kilobytes haben.
Wenn diese structs also bei jeder Initialisierung zu einer versteckten Leerkopie im Datensegment führen, bläht sich mein Programm unnötig auf.

Lösung: memset

Ich ging also durch meine Initialisierungszeilen durch und ersetzte diese beiden größeren Objekten durch ein:

1//struct mytype struct_var = {0};
2struct mytype struct_var;
3memset(&struct_var, 0, sizeof(struct_var));

Resultat: Meine DOS EXEen sind wieder um 20 KByte kleiner geworden.
Der größte Zuwachs kam durch meine Koroutinen-Implementierung ins Framework, denn diese wird in DOS jetzt zwingend am Start initialisiert und dort wurde für mehrere potentielle Stacks Verwaltungsbereich vorinitialisiert.

Fazit

Tja … es kann gut sein, dass andere Compiler hier besser optimieren und es gar nicht zu solchen Init-Kopien kommt. Aber nachdem man es nicht ausschließen kann, gilt für mich ab sofort die Regel:

structs größer als 32 Bytes dürfen nicht mehr per { 0 } initialisiert werden.

Und wieder einmal belehrt mich ein Altsystem, dass ich fahrlässig mit Ressourcen umgegangen bin. Und so lernt man aus der Vergangenheit, wie man mit einer Zeile eine bessere Zukunft “aufbauen” kann.

FAT - Dateizuordnungstabelle

2024-02-11T12:00:00+01:00

Das FAT Dateisystem war in den 90igern die absolute Nummer ein am PC und wurde erst nach dem Jahr 2000 mit Windows XP durch NTFS bzw durch Linux mit ext2/3 ersetzt.

Für meine Retro-PC und Disketten Experimente benötige ich ein Tool zum Auslesen der alten Datenträger, also implementiere ich mir eine FAT12/16 Reader schnell selbst.

Ein paar Daten und Fakten zu FAT

Auf Disketten ist FAT12 auch heute noch die Nummer 1. Weder Linux noch WinNT wagten und wagen es, hier ein anderes Dateisystem aufzuspielen.
FAT16 konnte damals Festplattenpartitionen bis knapp 2 GB bedienen und wird heute noch in kleinen SD-Karten z.B. am Mikrokontroller benutzt.
Und FAT32 haben wir fast überall im Einsatz, weil jeder USB Stick und jede übliche SD Karte damit formatiert ist, und die meisten Anwender nutzen bekanntlich genau so, wie es aus der Packung kam.

Die Idee von FAT war, dass der Datenträger in “Cluster” unterteilt wird. Auf Disketten war ein Cluster genau ein Sektor groß, doch auf größeren Medien wurden mehrere Sektoren zu einem Cluster zusammengefasst.
FAT12 hat (Wer errät es?) eine 12-bit breite Cluster-Adressierung und kann etwa 4000 Cluster verwalten (genau 4084, weil ein paar IDs reserviert sind). FAT16 schafft 65000 Cluster (genau 65524) und FAT32 kommt auf 268 000 000 (genau 268435444) weil nur 28 bit und noch die vollen 32 bits benutzt werden.

Ein 1-Sektor-Cluster (512 Bytes) unter FAT16 könnte nur 32 MB große Laufwerke verwalten. Mit 2-Sektor großen Clustern (1024 Bytes) verdoppelt sich das auf 64 MB, bis man mit einer Clustergröße von 64 Sektoren (32 KB) erreicht hat und damit knapp 2 GB adressieren kann.

Windows NT konnte auch 128 Sektoren (64 KB) zusammen-clustern und damit 4 GB ansprechen, doch da spielten DOS und Windows 3x/9x nicht mit. Unter DOS ist das fast logisch, weil man mit einem 64 KB großen Datenblock ein Speichersegment zum Überlaufen gebracht hätte.

FAT12 Implementierung

FAT12 ist für mich deshalb interessant, weil ich ja meine alten Toshiba Disketten auslesen möchte. Daher startete ich in der gate/tech Bibliothek ein Modul für Dateisystemstrukturen.

Im ersten Sektor (Bootsektor) einer Diskette befindet sich im “BIOS Parameter Block” (kurz BPB) eine Auflistung wichtiger Kennzahlen des Dateisystems, wie etwa Anzahl der Sektoren, Sektoren pro Cluster, Länge des Stammverzeichnisses.
Mit diesen Infos kann man später die logischen Sektorpositionen ausrechnen, um zu den Nutzdaten zu kommen.

Grundsätzlich liegen die in den Sektoren so hintereinander:

Reservierte Sektoren
- Bootsektor
- Optional andere unbenutzte Sektoren
FAT Sektoren
- FAT-1 (Primäre FAT)
- FAT-2 (Kopie der FAT als Backup für Reparatur)
Stammverzeichnis Sektoren
Cluster Sektoren
- Dateifragmente

Daraus ergeben sich folgenden Formeln:

first_fat_sector = bpb.reserved_sectors
total_fat_sectors = bpb.sectors_per_fat * bpb.fat_copies
root_dir_sectors = bpb.root_dir_entries / 32
total_cluster_sectors = bpb.total_sectors - (bpb.reserved_sectors + total_fat_sectors + root_dir_sectors)
total_cluster_count = total_cluster_sectors / bpb.sectors_per_cluster
first_cluster_sector = bpb.reserved_sectors + total_fat_sectors + root_dir_sectors

Das Stammverzeichnis hat also unter FAT immer eine feste Länge und kann nicht nachträglich wachsen (außer man strukturiert den ganzen Datenträger neu).

FAT Funktionsweise

Die FAT selbst speichert für jeden Cluster eine Zahl der anzeigt, ob damit ein weiterer Cluster verknüpft ist. Es ist also eine Single-Linked-List.

Ein Dateieintrag im Stammverzeichnis (oder Unterverzeichnis) nennt den ersten Cluster einer Datei. Den kann man mal auslesen. Dann sieht man in der FAT nach, was in dessen Cluster-Liste steht und findet dort entweder die nächste Cluster-Nummer oder eine “Ende-Markierung”.

Die logischen Cluster-IDs 0 und 1 sowie die größten 9 am Ende sind reserviert.

0 bedeutet, dass ein Cluster unbenutzt ist
ffff (also die höchste ID in FAT16) steht für “Ende”, es sind also keine weiteren Cluster mehr mit der Datei (Cluster-Kette) verknüpft.

Index	Inhalt	Bedeutung
#2	3	Cluster 2 verlinkt auf 3
#3	4	Cluster 3 verlinkt auf 4
#4	ffff	Ende erreicht
#5	0	Cluster ist frei
#6	ffff	Ende erreicht
#7	0	Cluster ist frei
#8	0	Cluster ist frei

Spezialfall FAT12

Während FAT16 und FAT32 einfach 16 und 32-bit Werte hintereinander in die FAT schreiben, sind bei FAT12 immer zwei Einträge in 3 Bytes verschränkt.
Die logischen Cluster-Nummern 0x0aaa und 0x0bbb werden in FAT12 als
aa ba bb gespeichert.

Das wirkt auf den ersten Blick komisch, macht aber in der 8-bit Little-Endian-Welt von X86 total Sinn.
Liest man nämlich den 16-bit Wert von Adresse 0 und dann von Adresse 1, erhält man die Werte 0xbaaa und 0xbbba.

Jetzt braucht man den ersten nur noch mit AND 0x0fff verknüpfen und den zweiten um 4 Bits nach links verschieben und schon hat man die gewünschten Werte von 0x0aaa und 0x0bbb.

Fazit

FAT ist gar nicht so schwer.

Gut, ein paar Rechenfehler macht man am Anfang, wenn man die Cluster, die bei 2 zu zählen anfangen, dann auch genau so zum ausrechnen der Sektoren nimmt und man dann daneben liegt … aber mit einer Referenzdiskette findet man das schnell selbst heraus, fügt das -2 in die Formel ein und alles ist gut.

Spannend sind so Sachen wie, dass man Pseudo-Hardlinks erstellen konnte, wenn einfach zwei Dateieinträge auf den gleichen Start-Cluster zeigten. Das ist in FAT eigentlich nicht erlaubt, doch ich hatte sogar noch so ein alte Diskette mit einem manipulierten Inhaltsverzeichnis.

Ein großes Lob geht an Seiten wie wiki.osdev.org, die den Aufbau wunderbar bildlich dargestellt haben. So konnte ich meine selbsterstellte Erstimplementierung gegenprüfen und korrigieren.

Device-Independent-Bitmaps

2024-02-03T12:00:00+01:00

Seit 15 Jahren nutze ich DIBSections der WinAPI um Grafiken in GUI Apps zu verwalten und mit der Zeit hinterfragt man gar nicht mehr, was alles ausimplementiert ist, wie es ist … man kopiert es einfach.

Doch DIBSections gab es in Windows 3.x nicht und auch unter NT 3.5 funktionieren einige meiner Codes nicht.

Frage: Warum?

Das GDI ist vermutlich die älteste API in Windows, die sich bis heute am wenigsten verändert hat … bzw. die heute noch so funktioniert, wie man es in den 80er Jahren für richtig gehalten hat.

Mit den erwähnten DIBSections kam um das Jahr 1995 eine zusätzliche “modernere” Schnittstelle hinzu, die eigentlich bis heute “ausreicht”.
Device-Independent-Bitmaps (DIBs) sind Rastergrafiken, wo der Nutzer entscheidet, wie sie intern aufgebaut sind. Man kann Farbpaletten für 4 oder 8 Bit Grafiken definieren, oder gleich 16- oder 24-bit RGB Farbwerte speichern. (Später kam noch 32-bit RGBA mit Transparenz hinzu.)

Eine solche “unabhängige” Bitmap wurde den WinAPIs übergeben und dieses zeichnete alles passend auf Bildschirme, in den Speicher oder auf den Drucker.

Doch das war nicht immer so …

Am Anfang war das Bit.

Bitmaps waren mal 1-Bit Grafiken, also rein schwarz-weiß. X11 unterscheidet daher folgerichtig Bitmaps für 1-Bit-Bilder und Pixmaps für Farbpixel-Bilder. Und aus dieser Zeit stammt der Standard, dass eine neue Bitmap mit einem Bit pro Pixel erzeugt wird.

DIBs gab es auch schon von Anfang an und sie wurden per CreateDIBitmap() über ein bestehendes Device-Context-Handle (HDC) erzeugt. Danach konnte man sie über den HDC per GetPixel und SetPixel und ein paar andere Linien- und Polygon-Zeichenroutinen befüllen.

Und das war so f*cking langsam, weshalb man per CreateDIBSection() das gleiche nochmal implementierte, und zusätzlich den Pointer zu den Rohdaten im Speicher bekam.
Die Coder erzeugten dann nur noch 32-bit DIB-Sections und manipulierten sich die Pixel selbst so hin, wie sie es brauchten, und umgangen so das langsame umwandeln von Pixel-Operationen in GDI Device-Contexts.

Früher musste man ohne DIB-Section entweder alle Pixel bereits mit CreateDIBBitmap() dem neu entstehenden Objekt eingravieren, oder mit den genannten GDI-Zeichenprimitiven dann drübermalen.

Finde den Fehler:

Und so sah also einer meiner Retro-Codeblöcke für Win3X aus, der auch auf heutigen System noch lauffähig sein muss:

 1HDC desktop = GetDC(NULL); /* get default-DC from Screen */
 2HDC mydc = CreateCompatibleDC(desktop);
 3HBITMAP mybitmap = CreateDIBitmap(mydc, 
 4    &bitmapHeader, CBM_INIT, init_buffer, 
 5    &infoheader, DIB_RGB_COLORS);
 6HGDIOBJ backup = SelectObject(mydc, mybitmap);
 7/* draw into bitmap */
 8SetPixel(mydc, x, y, RGB(r, g, b));
 9/* cleanup */
10SelectObject(mydc, backup);
11DeleteObject(mybitmap);
12DeleteDC(mydc);
13ReleaseDC(NULL, desktop);

Und egal wo ich meine so erstellte mybitmap ausgeben wollte, ich sah immer nur eine Schwarz/Weiß-Grafik.

Der Fehler liegt in mydc.

Wenn man einen “compatible DC” erzeugt, hat der wie vor 40 Jahren eine 1-Bit Bitmap mit 1x1 Pixel drinnen und wenn man dann CreateDIBitmap aufruft, erzeugt das eine Bitmap, die kompatibel mit dem DC ist und konvertiert meine “externen” DIBitmap-Daten in das Zielformat, und so wird ein 1-bit Abbildung daraus.

Lösung:

1HDC desktop = GetDC(NULL); /* get default-DC from Screen */
2HDC mydc = CreateCompatibleDC(desktop);
3HBITMAP mybitmap = CreateDIBitmap(desktop, /* <- use desktop-DC  */
4    &bitmapHeader, CBM_INIT, init_buffer,
5    &infoheader, DIB_RGB_COLORS);
6...

Anstatt mydc in CreateDIBitmap zu nutzen, kann man dort den DC des Bildschirms nutzen. Der sollte nämlich genau die grafischen Eigenschaften haben, wie es gerade in der Grafikkarte eingestellt ist.
Man erhält also eine Bitmap, die genau das Farbschema hat, das gerade angezeigt werden kann und die eigenen Bitmapdaten werden in genau dieses Format konvertiert.

Fazit

Tja, der wahre Unterschied zwischen CreateDIBitmap und CreateDIBSection ist, dass CreateDIBitmap wie CreateCompatibleBitmap ein zum DC kompatible Bitmap erzeugt und CreateDIBSection die Bitmap so herstellt, wie man es angegeben hat.

Die Sache ist sogar noch schlimmer, denn mir ist der Fehler auch mit CreateDIBSection(mydc, ...) unterlaufen.
Es sieht aber so aus, als würden neuere Windows Varianten beim Zeichnen, dann das Format der DIB-Section nutzen, und nicht das Format des DCs, das wegen CreateCompatibleDC nur 1 Bit breit ist.

Ältere Windows Versionen sind da aber strenger … und jetzt erklärt es sich mir auch, warum mein OpenGL-Code unter Windows 95 nur Schwarz-Weiß Ergebnisse im Test lieferte. Ein weiterer Fix steht bevor.

Wichtige Erkenntnis: Windows korrigiert Fehler!
Und deshalb programmieren wir schlampig … weil uns die Fehler nicht als solche auffallen.

Nintendo DS

2024-01-28T12:00:00+01:00

Etwa im Jahr 2010 setzt bei mir die zweite Kindheit in Sachen Spielekonsole ein. Und so kaufte ich mir in den folgenden Jahren die Modelle:
NDS, 3DS, 3DSXL und schließlich noch den New 3DSXL.

Es begann mit Pokemon …

Es beginnt doch eigentlich immer alles mit Pokemon, oder?
Im Jahr 2000 brachte mich No$GMB mit Pokemon-RGB zusammen, und 10 Jahre später war es bisafans.de und seine hoch motivierte Community, die den Hype um die kommende 5. Generation anfachte.

Ursprünglich startete ich auch wieder mit Emulatoren, doch gab es damals noch einige Probleme im für den DS erweiterten No$gba und dem neueren DeSmuMe, womit Spiele gelegentlich einfrieren konnten.
Genau das vermiest einem dann das Spielegefühl.

Und als dann 2011 der 3DS auf den Markt kam, dachte ich mir:

Ach warum nicht … ich kaufe mir einen.

Cheat-Freiheit erhöht den Reiz

Mit dem 3DS lernte ich, dass Emulatoren den Spielreiz zerstören. Schließlich kann man an jeder Stelle per Save-State sichern und wieder neu anfangen. Damit verliert man nicht, aber das Spiel wird damit belanglos.

Doch beim Nachspielen der 4. und 5. Generation auf dem 3DS fühlte ich mich wieder wie ein Kind und war glücklich weil ich mir jeden Orden auch “verdient” hatte.

Und neben Pokemon konnte ich mich dann auch für die DS-Titel der Kingdom Hearts Reihe begeistern, deren Haupttitel ich im PS2 Emulator mal angespielt hatte.

In den 10 Jahren zuvor wurden mir Spiele immer schnell langweilig, doch das lag meist an den Emulatoren. Mit dem 3DS kam endlich die notwendige Zufriedenheit zurück, wenn man was geschafft hatte, oder die Rastlosigkeit, wenn man ein Ziel nicht erreicht hatte.

Bewegung ist gesund!

Für 1000 registrierte Schritte mit dem 3DS erhält man 10 Spielemünzen, die in Nintendos eigener MII-Lobby oder in anderen Spielen eingetauscht werden können. Dafür erhielt man dann Items oder eben eine weitere Minispielchen-Runde.

Das hatte zur Folge, dass der 3DS ein fester Bestandteil in meinem Rucksack wurde. Die tausend Schritte sind zwar nicht viel, aber dennoch oft ein Grund gewesen, die Weg zur Arbeit zu Fuß und nicht per Bus zurückzulegen.

Andere Spieler treffen

Durch sein eigenes abgewandeltes WLAN konnten sich 3DS Geräte gegenseitig erkennen und so wurde die virtuelle Spieler-Identität (MII) ausgetauscht, was ebenso die genannten Minispielchen befeuerte.

Und zwischen 2011 und 2017 konnte man tatsächlich immer wieder neue MIIs am Gerät finden, wenn man ein paar Straßen durch die Stadt wanderte, oder einfach in die U-Bahn einstieg.

Ein echtes MII-Feuerwerk erlebte man mit dem 3DS bei Veranstaltungen, wie bei Anime-Conventions oder Spielemessen wie der Game-City in Wien.
Ich war dort ein paar mal nur um 3 Stunden lang diverse MII-Spiele abzuschließen, weil dort im Minutentakt neue MIIs und damit Spielerunden reinkamen.

3DS-XL

Aus dem Jahr 2013 stammt meine Aussage:

Mein Augenarzt hat unrecht!
Ich brauche keine Brille,
ich brauchte nur einen größeren Monitor.

Und genau das erfüllte der 3DSXL pünktlich zum Release von Pokemon X/Y. Das größere Display zahlte sich wirklich aus, und außerdem war mein erster 3DS schon etwas abgenutzt.

New3DS

Der 3D Effekt des 3DS hatte mich anfangs nicht überzeugt. Im Gegenteil, bei überladenen Spielen wie Kingdom-Hearts Dream-Drop-Distance musste ich es vollkommen abschalten um Kopfschmerzen zu verhindern. Es war also eher was für ruhige Spiele, für Pokemon war es “optional” OK.

Als ich mir Anfang 2016 dann einen New3DS zulegte, war die Verbesserung nicht zu leugnen. Eine eigene Augen-Kamera verfolgt dabei das Gesicht des Spielers und passt den 3D-Effekt an den Sichtwinkel an und so konnte man das Feature tatsächlich genießen.

Doch am Ende muss ich sagen … wirklich gebraucht hat man das nicht. Neue Spieletitel wie Zelda oder Yokai Watch überzeugten durch ihre Story und ihren Stil und nicht durch 3D Effekte.

Fazit

2017 Endete meine DS-Phase dann, als der Wechsel zur Switch stattfand und Pokemon Mond/Sonne auch nicht mehr wirklich “spannend” am 3DS erschienen.

Dennoch hat mich diese Gerätefamilie über 5 Jahre sehr gut unterhalten. Frustration aus Arbeit und Alltag verflogen, wenn man sich am Abend eine Stunde auf ein Spiel konzentrierte.

Tatsächlich brachte mir der DS oft Entspannung nach stressigen Arbeitstagen. Und während andere sich Pillen oder Alkohol einwarfen, brachte mich die Konsole in den Ruhemodus.

Und wie komme ich jetzt zu dem Thema?

Ich habe eine alte Nintendo-eShop Karte mit 25 Euro gefunden, die ich nie eingelöst habe. Und da leider alle 3DS Online Dienste inzwischen abgeschaltet sind, ist die Wertkarte verfallen.

Doch bei der Gelegenheit wurden meine Geräte wieder gestartet und sie funktionieren immer noch einwandfrei.

Bootsektor von Disketten

2024-01-21T12:00:00+01:00

Ja damals, als wir noch unsere eigenen Betriebssystem schreiben wollten …

Da hat alles mit einer Diskette angefangen. Es wird Zeit diese Epoche wieder etwas aufleben zu lassen. Also schreiben wir mal ein paar Bytes in den Bootsektor.

512 Bytes ist ein üblicher Datensektor (also die kleinste als Block lesbare Einheit) einer Diskette groß. Und bis heute ist dieser Standard geblieben. Zwar haben Festplatten um 2010 herum auf 4096 Bytes umgesattelt, doch Schnittstellen von Betriebssystemen legen diese Größe bis heute als virtuellen Grenzwert fest, auch wenn die Hardware dahinter dann was anderes macht.

Und wenn ein PC startete, dann las er früher (vor dem UEFI Standard) den ersten Sektor des Bootmediums und führte den Code darin aus.

BIOS Bootvorgang

Nachdem das BIOS geladen ist und dieses sich ein Bootmedium auserkoren hat, lädt es dessen ersten Sektor in den 16-bit Realmode Speicherbereich 0000:7c00 und springt an diese Adresse.

Dass heißt, dass man den Bootsektor einfach mit Instruktionen füllen kann, und diese werden dann sofort ausgeführt.

Doch für eine ordentliche Plattform benötigt man Standards und Dateisysteme. Damals war das ein FAT Dateisystem bzw. FAT12 für Disketten und der Bootsektor sollte anzeigen, welches Dateisystem genutzt wird, und wie dessen Daten verteilt sind.

Deshalb ist der Bootsektor so aufgebaut, dass die ersten 3 Bytes für eine X86 Jump-Anweisung reserviert sind und danach sofort Datenfelder kommen, die das FAT Dateisystem (oder andere) beschreiben.
Der eigentliche Bootcode wird erst danach gespeichert, und genau dorthin muss die erste JUMP-Anweisung hinspringen.

Will man jetzt seinen eigenen kleinen Bootcode schreiben, sollte man die FAT-Info Daten bestehen lassen und nur den restlichen Codebereich nutzen.

Was ich früher oft vergessen habe: Ein Bootsektor endet mit einer Signatur mit den Bytes 0x55 und 0xaa. Fehlen diese beiden Bytes am Ende, überspringt das BIOS das Medium beim Bootvorgang.

Netwide Assembler

Der nasm Assembler lässt uns einen solchen Bootsektor ganz leicht zubereiten. Und mit ein paar “magischen” Zeichen (siehe emtpy_space) lässt sich auch ein Speicherbereich bis zu einer bestimmten Marke mit Nullen füllen, damit am Ende eine 512 Byte Ausgabedatei entsteht, die man in den Bootsektor übertragen kann.

Das sieht dann als Skelett wie folgt aus kann mit nasm bootsect.asm -f bin -o bootsect.bin kompiliert werden:

 1    ; bootsect.asm
 2    org 7c00h       ; boot sector is loaded and executed in [0000:7c00]
 3
 4                    ; Offset |Description
 5                    ;-------------------------
 6main:               ; 0000: startup code (jump over data fields)
 7    jmp short boot_code
 8    nop
 9
10    ; OEM system name
11    db 'MSDOS5.0'   ; 0003: format name (8 chars)
12
13    ; BPB (BIOS Parameter Block)
14    dw     0200h    ; 000b: bytes per sector
15    db       01h    ; 000d: sectors per cluster
16    dw     0001h    ; 000e: reserved sectors (starting at 0)
17    db       02h    ; 0010: number of FATs on disk
18    dw     00e0h    ; 0011: reserved root directory entries
19    dw     0b40h    ; 0013: total sectors on disk
20    db      0f0h    ; 0015: media descriptor byte
21                    ;       f0: 3.5" 1.44M -or- 3.5" 2.88M
22                    ;       f8: hard-disk
23                    ;       f9: 3.5" 720K -or- 5.25" 1.2M
24                    ;       fc: 5.25" 180K
25                    ;       fd: 5.25" 360K -or- 8" 500K
26                    ;       fe: 5.25" 160K -or- 8" 250K -or- 8" 1.2M
27                    ;       ff: 5.25" 320K
28    dw     0007h    ; 0016: sectors per FAT
29    dw     000fh    ; 0018: sectors per track
30    dw     0002h    ; 001a: heads
31    dd 00000000h    ; 001c: reserved
32    dd 00000000h    ; 0020: reserved
33    dw     0000h    ; 0024: reserved
34    db       29h    ; 0026: extended BPB enabled with 0x29 
35
36    dd 00000000h    ; 0027: volume serial
37    db '0123456789a'; 002b: volume label (11 chars)
38    db 'FAT12   '   ; 0036: file system ID (8 chars)
39
40boot_code:          ; 003e: boot code
41    ...
42empty_space:
43    times 0200h - 2 - ($ - $$)  db 0    ; fill with '0' until position 01fe
44 
45 boot_sector_signature:
46    dw    0aa55h    ; 01fe: boot sector signature

Man kann mit der times N - ($ - $$) db 0 Anweisung aus dem 512 Byte-Bootsektor auch ein ganzes leeres Diskettenimage machen, und das würde dann so enden:

 1   ...
 2empty_space:
 3    times 0200h - 2 - ($ - $$)  db 0    ; fill with '0' until position 01fe
 4 
 5 boot_sector_signature:
 6    dw    0aa55h    ; 01fe: boot sector signature
 7
 8floppy_space:
 9    times 1474560 - ($ - $$)  db 0

Die 1 474 560 Bytes große Datei umspannt eine ganze 1.44MB 3.5” Diskette und kann sofort in einer VM mit BIOS Support gebootet werden (sogar in MS Hyper-V).

Im boot_code kann man sich dann austoben und bis zu 400 Bytes große Programme schreiben. Wer mehr will, muss alles auf weitere Sektoren verteilen und diese mit dem int 13h zusätzlich in den Speicher laden.

Fazit

Vor 25 Jahren war es mein großer Traum per Assembler ein kleines OS bzw. OS-unabhängiges Programm zu schreiben. Und bis heute kann ich von dem damals gelernten Wissen profitieren.

Es ist Schade, dass wir heute auf unseren komplexen Geräten weder Lust noch Laune verspüren oder überhaupt die Möglichkeit haben, ein eigenes System hochzuziehen. UEFI macht es uns zwar möglich, aber Smartphones und Mikrokontroller sind oft so standardfern, dass es wenig bring, sich damit zu befassen und Google versucht überhaupt uns per Codesignaturen davon abzuhalten, auf ihren Geräten etwas eigenes ausführen zu lassen.

Also bleiben uns nur VMs und vielleicht das eine oder andere Altgerät, das immer noch startfähig ist, um “den Kern” unserer Systeme zu verstehen.

Ich freue mich jedenfalls, wenn ich ein paar Boot-Assemblerzeilen sehe und merke dabei, dass die OS-Hersteller damals wie heute auch nur mit Wasser kochen.

Sterbende SSDs und M2s?

2024-01-14T12:00:00+01:00

Die günstigen SSDs und M.2 Chips aus Fernost versprechen beste Qualität und am Anfang stimmt das auch.
Aber nach dem einen oder anderen Jahr bricht das Kartenhaus in sich zusammen.

Die niedrigsten SSD Preise bei AliExpress sehen aktuell etwa so aus:

128 GB: 10 €
256 GB: 15 €
512 GB: 30 €
1 TB: 50 €
2 TB: 100 €

Wenn man das mit diversen Markenprodukten in ortsansässigen Händlern vergleicht, sieht man den Faktor 1.5 bis Faktor 2, besonders bei den größeren Kapazitäten. Vor 2 bis 3 Jahren waren noch Faktor zwischen 2 und 3 ablesbar.

Folglich kaufte ich damals einige SSDs, M.2 und mSATA Speichermedien und verbaute diese in meinen Testrechnern, aber auch in meiner regulären Arbeitsmaschine.

Als dann letztes Jahr mein Windows 10 “manchmal” extrem lange beim Booten brauchte, dachte ich an “dumme Windows-Dienste”, die im Hintergrund Schabernak treiben. Doch dann ging plötzlich der Explorer nicht mehr auf und nicht mal der Taskmanager reagierte.
Wenn man aber 10 Minuten lange wartete, normalisierte sich die Situation.

Ich kaufte einen neuen Marken-M.2-Chip, kopierte erfolgreich alle Daten und alles war wieder gut.

Neulich fing das gleich dann auf meinem sekundären Server an, wo ebenso eine preiswerte SSD verbaut war.

Empfehlung: Nicht mehr als 33% Platz belegen!

Endbenutzer-SSDs sind heute nur deshalb so günstig, weil wir die internen Daten(arbeiter) schlecht behandeln und unzureichend bezahlen.
Natürlich gibt es auch die hoch-stabilen Premiumprodukte, doch da kosten dann 100 Gigabyte 100 €, wo wir heute eine Terabyte zum gleich Preis erwarten.

SLC (Single-Level Cell) heißt die Technik hinter so einem Prämiumprodukt, denn dort wird jedes Bit in einer eigenen Zelle gespeichert, was jedem Bit ein Maximum an Produktionsaufwand aber auch Stabilität zusichert.

Daher hat man schnell die MLC (Multi-Level Cell ) Technik erfunden, wo 2 Bits in einer logischen Zelle gespeichert werden. Damit kann man doppelt so viel Speicher mit der gleichen Zellenanzahl bereitstellen, allerdings sinkt auch die Stabilität und maximale Wiederbeschreibbarkeit, da bei einem Schreibzugriff nicht ein Bit sondern immer beide neu geschrieben werden müssen.

Mit TLC (Triple-Level-Cell) haben wir 3 Bits in einer Zelle, und das ist genau das, was in billigen SSDs eingesetzt wird. Teilweise kommt auch das neuere QLC (Quad-Level-Cell) mit 4 Bits pro Zelle zum Einsatz.

Die wahre Magie stammt vom Kontrollchip, der bei Schreibzugriffen zuerst mal alle neuen Bits auf alle leeren Zellen verteilt. Bei TLC kann man also 33% des Datenträgers mit Hochgeschwindigkeit vollschreiben.
Danach werden weitere Bits zu den bestehenden Zellen hinzugefügt.

Und hier (so wird es jedenfalls im Netz behauptet) kommt dann der “billige” Speicherchip mit der einfacheren (oft auch veralteten) Software ins Wanken. Datenblöcke und Bits müssen umgeordnet werden und dann blockiert das Medium eben so lange, bis es mit der internen Arbeit fertig ist.

Laaaaange Datensicherung

Ich habe also einen zusätzlichen Kühlkörper auf meine bockigen Billig-SSDs und -M.2s gepackt, die im Betrieb deutlich heiß wurden, und alle Daten auf frische neue Marken-SSDs kopiert (die heute zum Glück billiger geworden sind).

Die Aktion dauerte ewig, da die Datenraten auf unter 100 KB/s sanken, doch Datenfehler sind mir bisher keine aufgefallen.

Ich hatte etwa 70% des Speichers benutzt, also so 350 GB von 500 GB. Zum Glück stiegen die Geschwindigkeiten auch teilweise wieder in den 10-MB/s Bereich, denn hätte ich alles mit 100 KB/s kopieren müssen, wäre wohl ein Jahr oder mehr notwendig gewesen.

Fazit

Wer billig kauft, kauft teuer.

meinte mal ein Kollege. Und das stimmt hier wieder … wobei, wenn man die Technik kennt, kann man sie auch zielgerichtet einsetzen. Wenn ich also nur 200 GB von 500 nutze, und immer wieder brav ein TRIM durchlaufen lasse, verteilen sich die Bits ganz gut ohne Blockaden und eine eine 200 GB SLC Platte ist immer noch deutlich teurer als die 500 TLC Variante.

Die scheinbar defekten SSDs wurden nach der Sicherung gelöscht, ge-TRIM-t und scheinen jetzt offenbar wieder super zu laufen.

Ich werde jetzt zwar nicht meine Daily-Business Daten darauf speichern, aber in Testsystemen für eine Quick&Dirty Linux oder Windows-Installation sind die Datenträger allemal gut genug.

SQLITE EXPLAIN

2024-01-07T12:00:00+01:00

Wie baut man SQL Queries und Indexe so, dass sie möglichst einfach und kurz sind und dabei trotzdem hoch effizient sind?

Es ist häufig eine “Glaubensfrage”, was eine Datenbank wirklich durchführt, womit man seine Statements “religiös” motiviert absetzt.

Doch da gibt es so ein Kommando, das den Nebel lichten kann…

Wenn man Tabellen per SQL abfragt und die Abfrage etwas komplizierter wird, und dann auch noch Sortierungen hinzukommen, kann es passieren, dass die Ausführung bei vielen Daten plötzlich extrem lange braucht.

Nun führt man Indexe ein und erhofft sich eine Verbesserung, die dann aber leider ausbleibt.

Tatsächlich kann es je nach Datenbank einen großen Unterschied ausmachen, ob man links mit rechts oder umgekehrt vergleicht, oder ob man zuerst sortiert und dann filtert oder anders herum.

Ein solches Problem quälte mich neulich in der Firma und ich verstand um’s Verrecken nicht, warum die benutzte SQLite Datenbank trotz Index so schlechte Antwortzeiten lieferte.

Wenn man aber ein EXPLAIN QUERY PLAN vor die eigentliche Abfrage packt, gibt einem SQLite (und auch so manche andere Datenbank) eine Liste der durchgeführten Schritte an.

Diese Information ist wahrlich Gold wert, denn nun kann man unterschiedliche Abfrage Varianten lokal testen und sieht sofort, wann und wenn ein Index genutzt wird und wann nicht.

Ohne den Query-Plan musste ich Abfragen mit riesigen Datenmengen quasi am Live-System ausprobieren, um zu sehen, dass etwas nicht OK war.

In meinem Fall musste ich eine “einfache Query”, die den Index ignorierte, durch eine etwas kompliziertere ersetzen um das gleiche Ergebnis aber mit Nutzung eines Index-Boost zu erhalten.

Fazit

Ein Lob auf meinen Kollegen, der mir EXPLAIN QUERY PLAN in Erinnerung rief!

Mir war gar nicht bewusst, dass es dieses Kommando in den erweiterten SQL-Standard geschafft hat und auf vielen Plattformen aushilft.

Zukünftig werde ich bei neuen Queries immer mal “nachsehen”, ob die Datenbank meinen Input auch so versteht, wie ich es sehe.

Happy New Year 2024

2024-01-01T12:00:00+01:00

Die Welt ist wieder nicht untergegangen … auch in Wien nicht.

In diesem Sinne: Prosit Neujahr!

Ich lasse es gleich bleiben irgend welche Vorsätze aufzustellen.
Nachdem ohnehin alle über K.I. sprechen, nur damit die eigene fehlende “N.I.” nicht so hart auffällt, warte ich mal, ob mir ein Algorithmus sagen kann, wie ich mein Leben besser gestalten soll.

Das neue Jahr fängt für mich super an. Ich habe viele Themen, die mich alle interessieren, dass ich gar nicht weiß, wo ich anfangen soll.
Aufgaben gibt es noch und nöcher, egal ob im Beruf oder privat.

Warum soll man da nicht einfach etwas Vertrauen haben, dass das ein gutes Jahr werden wird.

In diesem Sinne nochmal:

Prosit Neujahr!

Das Jahr 2023

2023-12-31T12:00:00+01:00

Das Jahr 2023 haben wir jetzt auch geschafft.

Oder man könnte auch sagen:

Es hat uns geschafft.

Die Seuche ist vorbei

Nachdem die Jahre 2020, 21 und 22 von Covid-19 und der Pandemie geprägt waren, verlief 2023 erstmals wieder “normal”, soweit man das überhaupt so sagen kann.

Öffentliche Veranstaltungen fanden wieder regulär statt, Masken werden nur noch selten (also nur von aktuell Kranken) getragen und die WHO erklärte die Seuche im Mai für beendet.

Während diverse rückwärts gewante Politiker bis heute ihre Opferrolle zelebrieren, sich weiterhin eingesperrt fühlen, obwohl dies nur ihrem beschränkten Verstand geschuldet ist, haben viele leider schon wieder vergessen, dass es nur der respektablen Arbeit aller Menschen in der Medizin und im Gesundheitsbereich zu verdanken ist, dass wir großteils gut überlebt haben.

20 Million Tote und eine Vielzahl von Langzeitgeschädigte machen erst klar, wie anfällig jeder von uns ist. Das Leben von Nachbarn und Bekannten, denen ein geliebter Mensch abhanden kommen ist, sieht weiterhin trist aus, und so kann ich nur mehr als froh sein, dass es in meiner direkten Familie keine Todesfälle auf Grund von Corona gegeben hat.
… die Sache sieht 2 bis 3 Häuser weiter leider schon ganz anders aus.

Neue Welten

In meiner neuen Heimat Codeberg kann das GATE Projekt nun wirklich aufblühen und auch öffentlich eingesehen werden.

Während ich früher primär nur einen Windows-32-bit Build lokal durchgetestet habe und damit fertig war, nimmt die Anzahl der Linux-Plattformen heute weiter zu. Jede Codeänderung und neue Abhängigkeit erhöht die Chance eines Fehlers und so bin ich froh, dass ich automatische CI Builds für x86, ARMv7 und ARMv8, sowie unterschiedliche C-Runtimes wie glibc oder muslibc ausführen lassen kann, um Patzer schneller zu finden.

Ich bin zwar nicht immer glücklich mit dieser zunehmenden Komplexität, nehme die Herausforderung aber genere sportlich an.

Fazit

Das Jahr ist somit abgehagt.
Einiges wurde erledigt, einiges blieb offen.

Auf ein Neues!
Aber erst ab morgen.

Windows 11 Upgrade

2023-12-30T12:00:00+01:00

Etwas widerwillig erfolgt jetzt die Umstellung meines Hauptsystems auf Windows 11. Nicht weil es notwendigt ist, sondern weil es gerade möglich ist.

Und außerdem will man ja mit gutem Beispiel vorangehen.

Das letzte Windows, das ich rein optisch als Bereicherung empfunden habe, war tatsächlich Windows 8. Weder 10 noch 11 können mich mit ihren Designs sonderlich begeistern.

Es gibt aber neben diversen API-Updates und optionalen Features einen Grund, mit dem neuen System zu arbeiten: Nämlich um UI Erfahrung für den Support zu sammeln.

Wie sehr hasse ich es, wenn mir jemand sagt: Ich habe auf “A” und “B” geklickt, und dann ist “C” verschwunden, und wenn ich dann bei mir gar kein “B” mehr vorfinde. Und schon deshalb muss ich mir angewöhnen, mit dem aktuellen System im Alltag zu arbeiten, schließlich will auch meine Firma demnächst darauf umsteigen. (Die haben sich eh recht lange Zeit gelassen.)

Windows 10 vor Windows 11

Da ich auf ein vollständiges Windows 10 vorerst nicht verzichten will, wird beides installiert. Zuerst kommt ein 64-Bit Windows 10 auf den Anfang einer leeren Platte, und danach folgt die Windows 11 Installation in einer neuen Partition.

Mit dieser Vorgehensweise erkennt das neue Windows stets die ältere Parallelinstallation und fügt sie automatisch ins Bootmenü ein.
Diese Prozedur setze ich seit Beginn des UEFI Zeitalters immer ein.

Und so wie bisher ein Windows 8 “hinter” meinem Windows 10 lief, so läuft ab jetzt Windows 10 hinter meinem aktuellen Windows 11.

UI bleibt weiter furchtbar

Meine ARM64 Geräte haben mich ja schon gut auf Win11 vorbereitet und daher weiß ich bereits, welche Registry-Keys zu setzen sind, damit dieses unerträgliche Anfänger-Kontextmenü nicht erscheint.

Doch viele andere Dinge passen mir einfach nicht ins Bild bzw. ins Fenster. Und das fängt mit den abgerundeten Fensterecken mit den dünnen kaum erkennbaren Umrandungen an und endet bei Scrollbars, die fast unbenutzbar werden, weil man sie nicht mehr sehen kann.

Diesen Schwachsinn hatten Linux-Desktops schon vor 10 Jahren eingeführt und ich weiß nicht, was ich verbrochen habe, dass ich jetzt auch noch von einem kommerziellen Produkt eine solche “Behinderung” vorgesetzt bekomme.

Das Startmenü ist für Anfänger sicher OK, für mich ist es aber ein Stop-Menü, weil ich nicht mehr wie in Win10 meine große Anzahl an relevanter Software übersichtlich ordnen kann.
Das fiel mir auf meinem ARM64 System nicht so auf, weil ich dort weniger installiert hatte … doch am Hauptrechner reicht das einfach nicht.

Einiger positiver Aspekt sind die Tabs im Explorer.
Eigentlich dachte ich nicht, dass ich die groß brauch werde, aber es ist wirklich praktisch, wenn im laufenden Betrieb per Klick eine neue Dateiansicht öffnen kann und leicht hin und herschalten kann.

Fazit

Die Installation und der eigentliche Betrieb sind OK. Ich rechne immer mit Problemen, doch hier gab es keine und das muss man lobend erwähnen.

Aber sich mit dem UI anzufreunden, wird noch Zeit brauchen.
Nachdem nun fast alle Entwicklungsumgebungen und VMs auf das neue System übertragen sind, kann ich es voll und ganz nutzen.

Ja, ein bisschen langsamer als Win10 fühlt es sich an … aber der Eindruck kann auch täuschen. Ich bin gespannt, wie performant die Maschine in einem Jahr noch sein wird.

Erinnerungen an Narnia

2023-12-24T12:00:00+01:00

Als in den 90ern die deutsch synchronisierte BBC Serie von Die Chroniken von Narnia auch bei uns im Fernsehen ausgestrahlt wurde, begründete sie vermutlich den Anfang meines Interesses am Fantasy Genre im Allgemeinen.

Heute - in der Spätjugend - erkennt man darin die Nacherzählung von christlichen Werten gepaart mit europäischen Imperialismus.

Zu Weihnachten entsteht förmlich der Druck die Welt wieder mit den Augen vergangener Jahrhunderte zu sehen. Schulklassen studieren Krippenspiele ein, um sie theatralisch vortragen zu können und dann wird wieder die Geschichte des “Christ-Kinds” erzählt, welches die Geschenke brachte, bevor Coca Cola mit Santa Claus quasi das “Apple-Konkurrenzprodukt” besser am Markt durchsetzen konnte.

Über Jahrhunderte haben diese Geschichten besonders die jüngsten unter uns mit Wertgleichnissen versorgt, um aus Ihnen bessere Menschen zu machen. Doch auch Eltern hatten so allen Grund für ihren Nachwuchs einmal im Jahr zwingend eine Zeremonie des Guten abzuhalten.

Doch mit dem Einsetzen der modernen Medien hat sich diese Tradition zumindest in unseren Breiten gewandelt.
Kinder lernen heute mehr von Harry Potter über den Kampf von Gut gegen Böse, als von Jesus Christus und dessen “Abenteuern im Morgenland”.

Die Geschichte von Narnia

C.S. Lewis brachte mit den Büchern rund um das “Zauberland” Narnia eine fiktive Welt hervor, die ich damals immer wieder und wieder auf VHS-Kasette aufgezeichnet ansah.
Ich liebte es, wie vier Kinder durch “ihre reinen Herzen” zu den besseren Königinnen und Königen eines Landes wurden, in dem Tiere sprechen konnten und Magie jede Handlung durchzog.

Es stand für mich im krassen Gegensatz zu den trüben Erzählungen aus dem Religionsunterricht, wo von einem Prädiger die Rede war, der umherzog und Menschen bekehrte.

Dann las ich über C.S. Lewis christliche Überzeugung und dass er diese in seine Werke hatte einfließen lassen.

Und wenn ich heute die alte Serie nochmals ansehe, erkenne ich eine Bibelszene nach der anderen. Am Ende entpuppt sich auch der Löwe Aslan, der König der Tiere, als Jesus in anderer Form, der geheimnisvoll meint:

In eurer Welt habe ich einen anderen Namen.

Und somit erhält jedes Opfer, das in den Handlungen rund um Narnia erbracht wurde, eine Äquivalent aus dem neuen Testament.

Ohne es zu Wissen hatte ich einen Teil Bibel gelesen … nur eben “ein bisschen anders erzählt”.

Das Bedürfnis nach Frieden und Führung

Und heute würde ich mir diese kindliche Sichweise gerne wieder herbeiwünschen. 4 Kinder, die durch ihren guten Willen die Welt retten. Sie entmachten die Übeltäter, die allesamt gierige alte Menschen sind und nur an ihrer Macht interessiert sind.

Es ist beeindruckend, wie schnell in der Welt von Narnia alle von den Kinderkönigen überzeugt sind und sofort für eben diese in die Schlacht ziehen … natürlich nur um Gutes durchzusetzen.

Ja, plötzlich ist man sich sicher: Für das Gute darf, nein, muss man zu den Waffen greifen, denn eine solche Schlacht ist schließlich von Gott gewollt.

An der Stelle bleibt einem dann doch noch der Bissen im Halse stecken, wenn man bisher glaubte eine biblische Geschichte vor sich zu haben. Denn es ist gefährlich Politik mit Religion in dieser Weise zu vermischen. Und es ist falsch die Begehren von Menschen mit Begriffen wie Gut und Böse absolut gleichzusetzen.

Gerne hätte ich gesagt:

Narnia, Harry Potter und vielleicht noch Herr der Ringe sind Bibelgeschichten neu erzählt.

Doch das stimmt nicht. Eher könnte man sagen:

Es sind Bibelgeschichten neu verdreht.

Fazit

Ich glaube, dass WIR beides brauchen:

Modernere Heldengeschichten
Und Klassische Religionsgleichnisse.

Des Rätsels Lösung liegt in der Befassung mit beiden. Man sollte die ersten Bilder dieser Geschichten reißerisch auf sich wirken lassen, und danach darüber nachdenken, was der/die Author/en ausdrücken wollten, welche Werte sie uns vermitteln wollten.

Hat heute vor 2000 Jahren wirklich eine “Jungfrau” den Heiland in einem Stall in Betlehem geboren, der durch Handauflegung Kranke heilen konnte und für alle Sünde am Kreuz gestorben ist? Oder sollen wir uns vielleicht nur daran erinnen, dass anderen zu helfen der höchste Wert im Leben sein sollte?

Wie auch immer … es ist jedenfalls eine schön erzählbare Geschichte.

Frohe Weihnachten an alle!

Am Ende ist C doch am besten

2023-12-17T12:00:00+01:00

So sehr ich meine Ausflüge ins ZIG Land liebe, so sehr freut es mich, wenn ich dann doch wieder in die C/C++ Welt zurück nach Hause kommen kann.

Denn dort ist es eben doch am schönsten, und Code am besten schreibbar.

Es gibt viele semantische und “optische” Gründe, warum moderne Sprachen wie ZIG dem klassischen C überlegen sind.

Doch wenn ich an mein Kernziel des GATE Projektes denke, wo die Unterstützung von möglichst vielen Zielplattformen oberstes Ziel ist, dann stelle ich fest, dass es eben nur in C und C++ möglich ist, hier effiziert voranzukommen.

Beispiel Makros

Ja, Makros waren oft wie eine Seuche in der IT Geschicht. Einmal davon befallen, wird ein Projekt schnell unwartbar. Unleserlich ist es dann sowieso schon.

Aus diesem Grund entschied man sich in ZIG, ohne Makros auszukommen.

Nun sehe ich mir die WinAPI mit ihrer ANSI- und Unicode Variante an und muss feststellen, dass man das nur mit Makros effizient gelöst bekommt, wenn man beide Varianten unterstützen will.

Ob man jetzt 8-bit oder 16-bit Strings erzeugen will, oder automatisch ein “A” oder “W” ans Ende eines Funktionsnamen schreibt, lässt sich über ein Makro “dynamisch” zusammenbauen, während man ohne Makros oft Code doppelt ausimplementieren muss.

(ZIG’s comptime kann das zwar auch lösen, braucht aber mehr Codeaufwand um Ziel zu kommen.)

Beispiel Nullpointer

Nullpointer sind der Grund für jede Menge Probleme und Abstürze. In ZIG sind solche Pointer erst mal verboten, dafür gibt es jedoch Optionals, die man immer explizit prüfen muss.
Das erzeugt wirklich sicheren Code.

Es kann aber auch kontraproduktiv sein, wenn die Sprache keine Möglichkeit bereitstellt, dass man auf einen Zustand vertrauen kann.
Wenn C-Pointer permanent auf Null und Nicht-Null Inhalt geprüft werden müssen, kann daraus kein effizienter Code entstehen. Das kann man zwar innerhalb der eigenen Funktionen gut optimieren, doch wenn es um Schnittstellen wie z.B.: Funktionspointer geht, wird das mühsam.

Wenn eine Schnittstellendefinition einen Pointer aus “Mandatory” definiert, dann darf bzw. muss man auch darauf vertrauen können, dass die Gegenseite es richtig macht.

Ein anderer Punkt wären dann Plattformen, die “Null” nicht als ungültig definieren. In x86-16 und somit auch in DOS liegt an Adresse Null die Interrupt-Vektor-Tabelle, und wer einen Debugger oder Code-Guard schreibt, muss eben auch auf diese Adresse schreiben dürfen.

Fazit

Unabhängig von den tollen Verbesserungen, die neue Sprachen einführen, verbauen sie durch Ihre Architektur aber manchmal auch die Möglichkeit, auf speziellen Systemen korrekt zu funktionieren.
Das bedeutet wir verlieren somit den Support auf diesen Systemen und verringern damit die Bandbreite der Zielplattformen.

C hat daher ganz bewusst viele Bereiche als “undefiniert” eingestuft, damit die Sprache für wirklich “alles” offen ist. Und ja, das bedeutet auch, dass man sich in den Fuß schießen kann.
Aber wir würden ja auch nicht Messer weltweit abschaffen, nur weil es möglich ist, sich damit umzubringen.

Die Flexibilität von C wird heute leider nicht mehr als Vorteil gesehen, sondern bei Fehlern immer als Nachteil ausgelegt.

Tatsächlich brauchen wir jedoch mehr Programmierer, die ihren Code verstehen. Auch wenn ich viele Features aus neuen Sprachen schätze, so kann man nicht alle Probleme lösen, indem man stets neue Programmiersprachen erfindet, die Bandbreiten nur durch Verbote einschränken.

Die Welt braucht mehr CONST

2023-12-16T12:00:00+01:00

Wenn ich von RUST und vor allem von ZIG eines gelernt habe, dann die Notwendigkeit const häufiger einzusetzen.

Denn moderne Sprachen meckern sofort, wenn wir Variablen deklarieren, die dann nur wie Konstanten benutzt werden.

Variablen, die nicht variieren

Wenn wir vom Compiler eine Variable verlangen, dann sollten wir das nur tun, weil wir in dessen “Lagerraum” unterschiedliche Dinge aufbewahren wollen.
Wir erhalten den notwendigen Platz und auch “Logistik”, die den Platz verwaltet und an unsere Bedürfnisse anpasst.

Konstanten hingegen sind wie Verkehrsschilder. Sie werden einmal produziert und aufgestellt und brauchen danach keine “Wartung” mehr.

Ein effizientes Programm weiß also genau, wo es veränderbare Informationen braucht, und wo fixe Daten ausreichen.

In der Praxis sieht das aber anders aus, und so liegt fast alles in Variablen, die dann auch noch “versehentlich” verändert werden und der Grund für Fehlverhalten sind.

ZIG sagt: Konstante Variablen sind ein Fehler

Der ZIG Code

1const std = @import("std"); 
2const builtin = @import("builtin");
3
4pub fn main() void { 
5  var v = 42;
6  std.debug.print("Hello, {}!", .{ v }); 
7}

führt zum Fehler:

error: variable of type ‘comptime_int’ must be const or comptime

Unser v ist keine Variable und ändert sich nie. Es ist eigentlich eine Konstante und ZIG lässt uns den Code nur durchgehen, wenn wir daraus ein
const v = 42; machen.

Jetzt kann der Compiler den Zielcode perfekt optimieren, denn er braucht keinen Speicher für v reservieren und kann somit die CPU Register ausreizen.

In C würden viele Entwickler folgendes hintippen:

1int main() {
2  int v = 42;
3  printf("Hello, %d", v);
4}

Aber auch hier würde ein
const int v = 42 oder noch besser ein
static const int v = 42; zu mehr Optimierungen führen.
Doch da uns der Compiler dazu nicht zwingt, bleibt die Variable bestehen.

Wieso behaupten RUST und ZIG teils besser als C zu sein?

Tja … es ist nicht die Sprache, sondern der Programmierstil, der gut- oder schlecht-optimierten Code zur Folge hat.

Die Unterscheidung von Variablen und Konstanten sollte also auch in C Code von hoher Priorität sein. So erhalten wir dann nämlich Ergebnisse, die keine andere Sprache mehr übertreffen kann.
Es ist natürlich nur ein erster Schritt, auf den viele andere wohlüberlegt folgen müssen.

Fazit: Weitere Sprachen lernen hilft!

Je mehr Sprachen man sich ansieht, um so mehr lernt man auch über die “Muttersprache” (also C).

Ich würde mir wünschen, dass wir mehrere Level der Codeverifizierung in C Compilern hätten. Die Feststellung, dass Variablen als Konstanten genutzt werden, wäre ein solches Feature.

Natürlich könnte man das über “Warnings-as-Errors” Optionen auch umsetzen, aber es ist eben nicht das gleiche, wie eine zwingend per Standard vorgeschrieben Var-Konstanten-Prüfung.

Doch im Gegensatz zu ZIG und RUST sollte C sich immer die Option vorbehalten, dass man ein solches Feature auch abschalten können muss.

Oder wie man gerne sagt:

Ein Feature, das man nicht abschalten kann, ist ein Bug.

Das Ende von 32-bits

2023-12-09T12:00:00+01:00

Mit Windows 95 wurde das 32-bit Zeitalter im PC Bereich eingeläutet, obwohl es schon länger da war. Und mit Windows 11 wird diese Glocke nun schrittweise abmontiert.

Solche Schritte sind logisch, haben aber dennoch einige Konsequenzen.

Der Übergang von 16-bit zu 32-bit war eigentlich relativ schnell abgeschlossen. Während im Jahr 1995 noch weiter Software für die 16-bit Welt entwickelt wurde, war im Jahr 2000 bereits so gut wie alles verschwunden. Außerdem fand in unseren Breiten die Büro-Digitalisierung gefühlt erst kurz vor dem Jahr 2000 statt.

Linux war nie auf 16-bit Systemen lauffähig und musste sich daher auch nie um einen solchen Migrationspfad kümmern.
Und was Windows anbelangt, so war die 16-Bit API eher ein Alptraum und wurde mit dem Wechsel zu 32-Bit besser und stabiler … wenn gleich auch nicht gerade übersichtlicher.

Doch bereits in den Jahren 2003/2004 kam mit AMD64 die echte 64-bit Einführung, die Intel mit IA64 (Itanium) schwer verbockt hatte.
Das war übrigens die große Chance für Linux, dessen Entwicklerteam sofort an der 64-Bit Portierung arbeitete und zügig erste Demos anbot.
Microsoft braucht bis ins Jahr 2005 um mit Windows Server 2003-x64 ein alltagstaugliches Produkt einzuführen und Visual Studio 2005 für die Entwicklung bereitzustellen.

Glaube: 64-Bit braucht keiner

Wenn man von Server-Anwendungen wie großen Datenbanken ansieht, lohnte es sich für Entwickler überhaupt nicht, 64-Bit Kompilate herzustellen.
Denn etwa bis ins Jahr 2014 wurden reine Intel-32 Prozessoren hergestellt, die den 64-Bit-Befehlssatz nicht ausführen konnten und daher zwingend mit 32-Bit Software betrieben werden mussten.

Man musste also entweder zwei Varianten der eigenen Software bereitstellen und pflegen, oder man blieb bei 32-Bits und vertraute auf Microsofts Kompatibilität, die allen 32-Bit Programmen gestattete, auch auf allen X64 Betriebssystemen zu laufen.
Selbst die Tatsache, dass Windows Server seit 2008R2 gar keine 64-bit Variante mehr besaß, konnte den Desktop Markt nur langsam beeinflussen.

Auch alle Linux Distributionen lieferten 32-Bit Bibliotheken in den 64-Bit Varianten mit aus, um die Ausführung älterer Software zu gewährleisten. Gleichsam war Linux durch die Distributoren meist von Anfang an auf dem neuen X64 Stand, da hier nicht die originalen Entwickler, sondern die Distributoren die finalen Programme zusammen kompilierten.

Ich glaube sowohl bei Debian wie auch OpenSuse damals gelesen zu haben, dass man 32-bit Varianten nur dann nehmen soll, wenn man nicht weiß, was die eigene CPU kann … was bei Linux-Fans selten der fall war.

Das Ende der X86 Netbooks und Tablets

Die ersten Windows Tablets nach 2010 waren meist 32-bittig und kamen mit 1 GB RAM auf den Markt, stiegen dann auf 2 GB. Jetzt kann man zwar ein Windows (8 oder 10) noch mit 2 GB RAM betreiben, aber effektiv nutzen kann man es nicht. Besonders Webanwendungen sind dafür heute viel zu komplex.
Und als Intel aufhörte, 32-bit-only-Prozessoren zu bauen, und jedes System mit einem 64-Bit OS ausgestattet war, begann langsam die Erkenntnis umzugreifen, dass neue Apps nur noch 64-Bit sein müssen.

Am Ende war und ist es Windows 11, dass uns jetzt gar keine Möglichkeit mehr lässt, auf einer only-32-bit Plattform laufen zu können.

32-Bit Kompatibilität schwindet.

Windows wird vermutlich noch lange den 32-Bit Layer mitführen und alle alten Programme damit betreiben können, doch bereits seit Windows Embedded 7 kann man das 32-bit WOW (Windows on Windows) Subsystem entfernen. Auch WinPE kennt keine Kompatibilität und führt nur “sein” Binary-Format aus.

Unter Linux sieht die Sache ähnlich aus, wenn man an Docker denkt.
Niemand stellt hier ein 32-Bit Image bereit (außer es ist ein ARM-32-bit Image für den Raspberry PI).

Das führt nun dazu, dass neue Software generell nur noch für 64-Bit Systeme kompiliert wird.
Im Fall von Windows finden wir heute zwar immer noch 32-bit Kompilate vor, doch auch hier setzte die Trendumkehr schon vor Jahren ein.
Bitcoin-Core ist seit 8 Jahren 64-bit-only und Ähnliches ist auch für andere Produkte wahr.

Am Extremsten war das aber bei den Treibern zu beobachten. Die aktuellen Treiber für Intel-Grafik-Chips liegen auch seit 2018 nur noch als 64-Bit Varianten vor. Man könnte die zwar auf 32-Bit portieren, doch das tut einfach niemand mehr.

Fazit

Ich verbinde mit 32-Bits einfach viel Nostalgie und finde es Schade, dass nicht beide Bitbreiten parallel weiterexistieren können. Doch rein rational war der Schritt weg von 32-Bits hin zu 64-bits mehr als überfällig.

Hier haben dotNET und JAVA Entwickler einen riesigen Vorteil, denn dort kümmern sich ihre Laufzeitumgebungen darum, dass Code automatisch zur neuersten Variante hochkompiliert wird.

Doch für die native Entwicklung bedeutet das, dass wir entweder schon umgestellt sind, oder sofort mit der 64-Bit Umstellung starten müssen.

ZIG als C/C++ Toolchain

2023-12-03T12:00:00+01:00

Das beste an der Programmiersprache ZIG ist, dass sein Compiler Toolkit gleichzeitig auch ein C Compiler ist. Das bedeutet, man kann ZIG auch dazu nutzen, das eigene C Projekt vollständig zu kompilieren.

Und mit einer kleinen Toolchain Datei für CMake wird daraus der beste und plattform-unabhängigste Compiler überhaupt.

Machen wir es kurz.
Hier ist sie, meine Toolchain-Datei für ZIG:

 1set(target_id x86_64-linux-gnu)
 2
 3set(CMAKE_C_COMPILER zig cc)
 4set(CMAKE_C_COMPILER_AR zig ar)
 5set(CMAKE_C_COMPILER_RANLIB zig ranlib)
 6set(CMAKE_C_COMPILER_TARGET ${target_id})
 7
 8set(CMAKE_CXX_COMPILER zig c++)
 9set(CMAKE_CXX_COMPILER_AR zig ar)
10set(CMAKE_CXX_COMPILER_RANLIB zig ranlib)
11set(CMAKE_CXX_COMPILER_TARGET ${target_id})

Es bedeutet einfach, dass wenn man die zig EXE mit dem Parameter cc oder c++ aufruft, hat man den C bzw. C++ Compiler-Teil vor sich, und das ist aktuellen eine LLVM (CLang) Variante, die zusammen mit Zig und inklusive vieler Runtime-Implementierungen für alle gängigen Betriebssysteme geliefert wird.

Man braucht also CMake nur beizubringen, dass zig cc der C Compiler ist, und sämtliche anderen Compiler Flags werden dann wie für Clang üblich ermittelt.

Die target-id konfiguriert dann noch die gewünschte Zielplattform und schon läuft der Build durch.

Problem: Bibliotheken

Naja … ganz so perfekt läuft es vielleicht doch nicht immer. Denn wenn man viele Fremdbibliotheken benötigt, dann sind die nicht zwingend an der richtigen Stelle (aus Sicht des ZIG Compilers).

Soll heißen: Wenn ich z.B.: systemweit in Debian einen Cross-Compile Umgebung eingerichtet habe
(z.B. mit dpkg --add-architecture armhf und apt install XXX:armhf), dann findet mein Compiler die Bibliotheken von selbst.
Bei einer lokalen ZIG-Installation sind diese Libs nicht vorhanden, und selbst wenn sie im System vorhanden sind, dann muss man deren Pfade erst mal dem Compiler bzw. Linker explizit mitteilen.

Hier könnten andere Build- und Paketmanager durchaus hilfreich sein, aber da stehe ich selbst auch noch am Anfang.

Fazit

ZIG rulez!

hätte man früher unaufgefordert in jedes Forum gepostet.

Ich bin dezent beeindruckt, dass den ZIGlings gelungen ist, was den anderen Compilerherstellern bisher nicht geglückt ist:
Nämlich einen C Compiler samt Cross-Umgebung für alle Plattform auf allen Plattformen bereitzustellen.

Hier zahlt sich die 100MB+ Installation echt aus, weil eben alle Targets samt unterschiedlichen C-Runtimes enthalten sind.

Wer also im klassischen Unix-Stil kleine effiziente Tools schreiben will, hat paradoxerweise mit ZIG den besten C-Compiler in seinen Händen.

Externer Stack in Watcom

2023-12-02T12:00:00+01:00

Während Windows und Linux interne Funktionen für das Zusammenstellen von Koroutinen anbieten, lässt uns DOS diese Arbeit selber machen.

Zumindest dachte ich das, doch meine Assembler-Künste versagten stets und ließen meine DOSBox Sitzungen sofort einfrieren.

Spoiler: Ich war gar nicht schuld!

Während in einer 64 KByte .com Datei alle 3 Segmente (Code, Data, Stack) in einem zusammenfallen, können .exe Programme im Large-Modus Code und Daten auf mehrere Segmente verteilt werden und die Aufrufe und Zugriffe erfolgen über FAR Calls.

Nur das Stack-Segment bleibt ein und das selbe, weil man sich ohnehin nicht vorstellen konnte, dass jemand mehr als 64 KByte auf den Stack packen wollen würde.

Will ich nun aber ein bisschen kooperatives Multitasking etablieren, so dachte ich, brauche ich einfach nur ein neues Segment von DOS allokieren lassen und über ein paar Assemblerzeilen die Ausführung dort weiterlaufen zu lassen.

Zwar ist es schon etwas schwieriger mit den wenigen 16-bit Registern die notwendigen Daten im Prozessor zu halten um alles korrekt wechseln zu können, doch ich dachte, ich hätte es schon gelöst.
Trotzdem schlugen alle meine Tests mit eingefrorenen Bildschirmen oder Stack-Korruptionen fehl.

Der Compiler muss Bescheid wissen!

Nach langem hin und her suchen, fand ich zum Glück den entscheidenden Eintrag in der OpenWatcom Compiler-Doku.

zu: do not assume that SS contains segment of DGROUP

Im Langtext heißt es:

The zu option relaxes the restriction that the SS register contains the base address of the default data segment, “DGROUP”. Normally, all data items are placed into the group “DGROUP” and the SS register contains the base address of this group. When the “zu” option is selected, the SS register is volatile (assumed to point to another segment) and any global data references require loading a segment register such as DS with the base address of “DGROUP”.
(16-bit only) This option is useful when compiling routines that are to be placed in a Dynamic Link Library (DLL) since the SS register points to the stack segment of the calling application upon entry to the function.
The macro __SW_ZU will be predefined if “zu” is selected.

Das Stack-Segment, das wir vom Compiler am Anfang aufgesetzt bekommen, enthält also “mehr” als nur den Stack und wenn wir uns eigene Stacks schaffen, fehlt das und führt zu Folgefehlern.

In CMake musste ich also noch etwas wie:

1set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -zu")
2set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -zu")

oder moderner

1add_compile_options("-zu")

einfügen und schon funktionierten meine Callstack-Manipulationen wie erwartet.

zu verbessert vermutlich nicht gerade die Performance, aber wenn man dafür ein bisschen Koroutinen-Flair abbekommen kann, bin ich bereit da etwas Leistung herzuschenken.

Fazit

Tja, nicht mal C-Compiler kommen ohne Magie aus.
Man würde sich erwarten, dass C Code unabhängig von der Umgebung arbeitet und einfach seine Daten auf den oder vom Callstack schaufelt ohne zu hinterfragen, wo der Stack genau herkommt.
Doch wenn Optimierungen oder versteckte Werte an bestimmten Stellen liegen, können die nicht so leicht “nachgebaut” werden.

Wie man aber sieht, haben die Macher diesen Spezialfall vorgesehen und durch das genannte Compiler-Flag steuerbar gemacht.

Ein hoch auf OpenWatcom
… wenn auch heute teils mit gekreuzten Fingern.

Das InuYasha-FanProjekt

2023-11-26T12:00:00+01:00

Es war purer Zufall, als ich einen alten Schatz im DVD-Regal wiederfand, den ich vor knapp 20 Jahren erworben hatte.
Zwischen 2006 und 2007 kamen die InuYasha Anime Filme in unseren Breiten auf den Markt und schlossen für mich die damals unvollendete Serie ab, die Anfang der 2000er Jahre auf RTL2 im Nachmittagsprogramm lief.

Und dann erinnerte ich mich an noch etwas …

Aus irgend welchen Gründen hatte ich in jenen Jahren ein gesteigertes Interesse an allen typischen japanischen Rollenspielcharakteren, wie sie mir die Final Fantasy Spiele von SNES bis Playstation vorsetzten.

Fast immer ging es um einen jungen männlichen Helden, der ritterlich umher reiste, Monster besiegte und das Herz von mindestens einer Jungfrau eroberte, die ihn dann zumeist als mächtige Magierin begleitete.

Die InuYasha Animeserie setzte dem ganzen dann die Krone auf, und war für mich der Inbegriff einer Teenage-Hero-Story. Bis heute spreche ich bei ähnlichen Produktionen vom “Cooler-Junge-mit-Schwert-Anime”.

DVDs mit Qualität

Von den 4 Filmen sind die ersten 3 super und den vierten hätte man sich sparen können. Die Nummer 3 mit dem Thema “Höllenschwert” ist für mich zweifellos das beste Anime-Kino aller Zeiten.

Doch ein besonderes Highlight sind neben den stylischen Aluboxen die Booklets, die einem japanische Begriffe, Namen und Eigenheiten beschreiben.
Hier hat offenbar jemand mal Zeit in die Qualität gesteckt und nicht einfach nur Werbematerial für andere DVDs eingestreut.

Und so fand ich auch den Hinweis, dass die InuYasha Movie DVDs für den deutschen Markt durch die inzwischen nicht mehr existierende Firma RedPlanet in Zusammenarbeit mit dem InuYasha FanProjekt produziert wurden.

Das InuYasha FanProjekt

Da haben sich offenbar vor über 20 Jahren ein paar Jungs und Mädchen zusammengefunden, die Fans der Mangas und der nachfolgenden Anime-Serie waren. Und irgendwie kam diese Gruppe auf die Idee, an der Übersetzung des japanischen Materials mitzuwirken und … das wurde dann auch offiziell.

Viele Anime-Serien wurden “kindgerecht” ins Nachmittagsprogramm eingestreut. Und da man dort Tötungen nicht all zu gerne sah, wurde viel Material bis zur Unkenntlichkeit geschnitten und auch der Text inhaltsverändernd entschärft.

Doch für die Filme, die auch fürs Kino geeignet waren, konnte man endlich die Originale heranziehen und dass damals vor 20 Jahren eine Privatinitiative erstmals so direkt und positiv auf eine Produktion einwirkten konnte finde ich einfach nur genial.

Das alte Web-Forum, in welchem sich die Mitglieder des FanProjekts austauschten existiert immer noch und bewahrt somit wie ein alter griechischer Tempel das Andenken an die erbrachten Leistungen vieler freiwilliger Helfer. https://iyfp.eu/

Wie die Zeit vergeht …

Der Titel des Beitrags Wir trauern um unseren guten Freund Olaf blue Boos im Forum ließ mich schon vor 10 Jahren und auch heute wieder nachdenken, wie schnell das Leben an einem vorbeiziehen kann. Der genannte Mann war ein Organisator des IYFP und ich erinnere mich, dass er auch in einigen Podcasts mitwirkte, die sich damals mit der Anime-Szene auseinander setzten. (Ich glaube, das war auf otakutimes.de und bei der heute ebenso obsoleten “Anime-Copyright-Allianz”.)

Ich hatte keine Anknüpfungspunkte zum IYFP, kannt dort auch niemanden und las nur gelegentlich mal ein paar Artikel der Gruppe mit. Dennoch berührt es mich persönlich, dass hier mindestens ein wichtiges Mitglied inzwischen nicht mehr unter uns weilt.
Und gleichsam halte ich immer noch einen Teil seines Werkes in meinen Händen, und freue mich, dass es bei mir und vielen anderen Fans überdauert hat und auch weiter überdauern wird.

Fazit

Das InuYasha FanProjekt ist nur eines von vielen kleineren und größeren Umsetzungen, welches durch viel freiwillige Arbeit etwas bewirkt hat.
Doch für mich ist es ein Ankerpunkt, ein Funke voller Freude, der mich an eine unbeschwerte Zeit zurückdenken lässt, die viel Spaß gemacht hat.

Und diesen Spaß haben mir natürlich die japanische Autorin und ihr Produktionsteam ermöglicht, aber auch die Mitglieder des IYFP.

Eine echt geniale Leistung!

In meinen DVD Booklets stehen die Namen einiger Teammitglieder, die aktiv an den DVDs mitgearbeitet haben:

Olaf “blue” Boos
Lukas “EVA-01” Ruffing
Pierre “pbsaffran” Bancov
Katarina “pekopeko” Conrath
Björn “Liferipper” Schmid
Marcio “Gogeta-X” Fragoso
Christian “Shiero-sensei” Linke
Michael “mi-Ka” Ebersberger
Andreas “Knuckles” Müller
Dennis “Shugana” Felske
Matthias “Kogoro” Helm
Michael “MagDragon” Paff
Kevin “Phytagoras” Wrobel”
Sabina “StephWingSab” Schneider

Und es waren bestimmt noch viele mehr beteiligt.

Euch allen da draußen: DANKE!

SQLITE für Windows 95

2023-11-19T12:00:00+01:00

SQLite ist schon eine tolle Software … weil sie so “kompatibel” ist.

Wenn es darum geht ein Datenformat zu haben, das man über Zeiten hinweg nutzen kann, denkt man nicht gleich an eine SQL-Datenbank.
Aber wie sich zeigt, lässt sich diese Software auch auf 25 Jahre alten Systemen einsetzen.

SQLite ist schon lange ins GATE Framework integriert und von Zeit zu Zeit aktualisiere ich meinen Fork mit dem “latest-greatest” Abkömmling.

Dabei habe ich mir wieder die Frage gestellt, wie weit ich mit SQLite in die Vergangheit reisen könnte. Und zumindest für die Windows Welt, konnte ich das schnell austesten.

SQLite unter NT4 und Win98

Wenn man ein paar Compiler-Flags richtig einstellt, lässt sich SQLite mit Visual Studio 2005 kompilieren und dessen Output läuft dann unter NT4 wie auch unter Windows 98.

Natürlich muss man für Win98 mit der ANSI API arbeiten und auf einige erweiterte Datenzugriffsmöglichkeiten verzichten, doch diesen Weg kann man leicht aus den Originalquellen beschreiten.

Windows 95 ist anders

Wer denkt zwischen Win95 und 98 gäbe es keine funktionalen Unterschiede, der irrt.
Denn eine Funktion fehlt an vielen Enden: InterlockedCompareExchange()

Das Thema hatte ich im GATE-Framework intern schon und leitete damals einen Workaround bei mir ein … doch in Fremdcode geht das nicht so einfach.

Ich konnte jedoch das Ergebnis von InterlockedCompareExchange in einer eigenen Funktion provisorisch nachbauen (mit InterlockedExchange) und dann (per Makro von CMake aus) die originalen Aufrufe von InterlockedCompareExchange auf meine Funktion umleiten.

Zum Kompilieren war Studio 2003 notwendig, wofür auch noch eine kleine Änderung am Buildscript notwendig war … doch am Ende konnte SQLite auch für Windows 95 kompiliert und dort auch ausgeführt werden.

Fazit

Wenn es also ein Datenformat gibt, das ich heute im Jahr 2023 genau so nutzen kann, wie damals im Jahr 1995, dann ist das SQLite.

Ich bin sicher, dass es keine andere freie Datenbanksoftware gibt, die ihr Datenformat und auch ihren Programmcode so gestaltet hat, dass man Jahrzehnte damit überbrücken kann. Im besten Fall bekommt man kompatible Upgrades auf die neueste Version, die nur unter der neuesten Umgebung läuft.

Daher erneut: Ein Hoch auf SQLite!

Hirnlos glücklich

2023-11-18T12:00:00+01:00

Was meinen Schlaganfall von letzter Woche anbelangt … … es war eh keiner … glaube/hoffe ich.

Soooo lustig war das anfangs natürlich nicht.

Denn ich sitze wie fast jeden Abend vor dem Rechner und tippe herum, als ich merke, dass mir das Drücken der Tasten mit der linken Hand immer schwerer fällt.

Gut, das kommt vor, schnell hat man sich einen Nerv wo eingeklämmt oder saß eben blöd schief am Stuhl.
Also einmal aufstehen eine Runde durchs Zimmer laufen und alles ist wieder gut.

Doch an jenem Abend neulich leider nicht. Es fiel mir immer schwerer die linke Hand zu bewegen. Es ging zwar, war aber anstrengend und langsam.

Dann wird man nervös … es könnte ja doch was Ernstes sein … aber wenn nicht, dann blamiert man sich wegen einem eingeschlafenem Arm.

Es dauerte jedenfalls recht lange, bis sich mein Arm wieder normal anfühlte. Eine Stunde war ich auf und abgelaufen, stets in Versuchung vielleicht doch den Notarzt zu rufen.

Letztendlich tat ich es nicht und ging “ganz normal” schlafen. Der Arm war da wieder halbwegs normal.

Nachbehandlung

Am Folgetag war man erster Weg zum Hausarzt … der erst am nächsten Tag für mich Zeit hatte. Nach Schilderung des Vorfalles gab es mehrere Möglichkeiten, die von harmlosen Verspannungen bis zum Schlaganfall reichten und alle ausgeschlossen werden sollten.

So bekam ich jede Menge Überweisungen und Tests zugeordnet. Bluttests, EKG, Ultraschall und Neurologe waren tatsächlich binnen zwei Wochen vereinbar. Nur die wichtigste Sache: ein MRT zum Check, ob mein Hirn noch richtig läuft, da ist der nächste Termin erst im Februar frei.

Ich hätte, wie ich nun weiß, sofort den Notarzt rufen sollen, denn in Notfällen wird sofort ein Gerät für einen frei gemacht.
… aber … bei verabredeten Terminen für einen quasi Vorsorgecheck, da dauert es schon gerne mal 3-4 Monate.

Fazit

Die beste Erklärung für meinen “toten Arm” ist wohl meine verschobene Wirbelsäule, die einige Nerven eingeklemmt hatte … und an dem Abend war es vielleicht die Armsteuerung. Auf einen Schlaganfall deutet nichts hin, auch ein inzwischen ebenfalls gemachtes normales CT nicht … aber wirklich ausschließen kann es offenbar nur ein MRT … und auf diesen Termin bin ich schon gespannt.

Wie auch immer … wenn ich bei einem Kundenproblem mit einer Software den nächsten Diagnosetermin in 3 Monaten einplane, dann kann man den Aufschrei noch am Südpol sehr deutlich hören.

Heißt also:

Unsere medizinischen Einrichtungen bräuchten da auch mal ein System-Update.

Debian UI ein/ausschalten

2023-11-12T12:00:00+01:00

X11 und ein UI Desktop gehören einfachen zu jedem Linux dazu. Warum auch nicht, selbst wenn man sie nicht immer braucht.

… dachte ich, bis ich mir die Speicherauslastung ansah.
Jetzt heißt es: Abschalten!

Am Hyper-V Server gibt es das tolle Feature: Dynamischer Speicher.
Man ordnet dem System ein Minimum garantiert zu, lässt aber einen Spielraum für die maximale Nutzung offen.
Wenn VMs jetzt nicht den vollen Speicher brauchen, bleibt dieser für andere Aufgaben oder andere VMs übrig.
Und genau so kann ich wesentlich mehr VMs gleichzeitig starten.

Meine Debian Server zum Bauen von Software starten daher mit 1 GB RAM, dürfen sich aber bis zu 4 GB krallen, wenn noch so viel frei ist.

Jetzt braucht ein Buildserver natürlich kein UI, doch ich installiere es trotzdem manchmal mit, damit ich im Notfall auch dort ein paar Dinge komfortabler durchführen kann, oder weil ich meine eigenen X11-Apps schnell testen möchte.

Mit aktivierter X11 Desktop Session schwillt der Speicherbedarf aber schnell auf die erlaubten 4 GB an, ohne dass ich die UI überhaupt nutze.
Es macht also durchaus Sinn die grafische Benutzerschnittstelle erst gar nicht zu starten, wenn ich sie nicht brauche.

X11 unter Debian ein und ausschalten

Vor über 20 Jahren lernte ich noch etwas über “Runlevel”:

init 3 startet den Mehrbenutzer-Modus ohne UI (also nur die Text-Konsole)
init 5 startet die volle grafische Oberfläche unter Linux.

Heute hat systemd diese Funktion übernommen und benennt die Runlevels in “Targets” um.

multi-user.target bezeichnet den Konsolenmodus
graphical.target stellt die volle grafische Oberfläche bereit.

Und um beim Start eben nur die Konsole zu starten und auf die UI zu verzichten reicht ein einfaches:

1sudo systemctl set-default multi-user.target

Umgekehrt kann der automatische Start der GUI mit

1sudo systemctl set-default graphical.target

wieder aktiviert werden.

Fazit

Das witzige ist, dass ich mich selten direkt auf solchen Maschinen im UI einlogge, sondern eher xrdp nutze. Auch hier ist der automatische Start der GUI eine reine Speicherverschwendung, den xrdp startet erst dann die grafische Umgebung, wenn die erste Remote-Verbindung angenommen wird.

Das Installieren einer GUI kann also auch auf Servern Sinn machen, doch es lohnt sich dieses “Target” nicht automatisch hochziehen zu lassen.

Mit dem multi-user.target fährt man also am besten und schont vor allem die Ressourcen der Hardware oder des VM-Hosts.

Und wenn man direkt zur GUI wechseln möchte, erledigt das

1systemctl isolate graphical.target

was dem früheren init 5 entsprechen würde.

The Marvels und Loki Season 2

2023-11-11T12:00:00+01:00

Wow! Was für eine Woche. Zum einen endete die zweite Loki Staffel mit einem spektakulärem Ende und zum anderen kam mit The Marvels ein weiterer Film in die Kinos, dessen Ausrichtung schon lange diskutiert wird.

Soll heißen, dieses Woche war eine Medien Woche.

The Marvels

Es ist wirklich zum verrückt werden. Ich liebe jede der drei Frauen, die mit the “Marvels” im großen Kinoformat ankamen … und trotzdem schmerzt es mich, wie wenig mit den Figuren gemacht wurde.

Brie Larson hatte ja bereits ihren Marvel-Soloauftritt im ersten “Captain Marvel” Film. Doch wir alle wissen, dass dieser Film nur “nachgereicht” wurde, um im nahenden Endgame Titel eine geheime Superwaffe zu haben. Genau das war damals das Problem. Man sah den Szenen an, dass sie in größere Handlung “hineinkonstruiert” wurden. Man hätte ähnlich wie bei Ironman, Captain America oder Thor etwa 2 bis 3 Filme für die Charakterentwicklung gebraucht um die Figur zu etablieren.

Und was passiert im zweiten Film … leider wieder das gleiche. Mit Monica Ramow und Kamala Kahn hatte man zwei tolle Protagonisten hinzugewonnen, die Sympathien trugen und besonders Kamala spielte (wie Tom Holland in Spiderman) die Rolle eines Teenagers hervorragen in ihrer Ms. Marvel Serie.

“The Marvels” war lustig, humorvoll und mit gutem Schauspiel vorgetragen, doch die Handlung und der herbeigeschriebene Bösewicht war farb- und konturlos. Wieder einmal findet man ein Artefakt, das Welten zerstören kann, die böse “Dar-Benn”, Anführerin der Kree setzt es ein um ihr Volk zu retten, und ignoriert den Genozid und die Auslöschung anderer.

Am Ende läuft der Frauen-Fight-Club durch, die guten gewinnen, die Böse verliert.
Ja … da hätte ich mehr erwartet.

Und trotzdem wirkt Iman Vellani als Kamala so bezaubernd nett in ihrer Rolle, dass ich dem Film seinen simplen Plott verzeihe. Vielmehr sehe ich den Film als eine Komödie, in der eine Raumstation von “frisch geschlüpften Katzen” (Flerken ) gerettet wird und Brie Larson als Prinzessin vortanzen kann.

Ein Highlight wird für viele die Mid- und Endcredit-Szene sein, den dort werden einerseits die Young Avangers angekündigt und Monica Rambeau hat es inzwischen in die Dimension der X-Men verschlagen … heißt also, die kommen auch bald ins Kino.

Na und so geht man dann mit einem breiten Grinsen aus dem Kinosaal.

Loki Season 2

Ich liebe alles, was mit Zeitreisen zu tun hat, von daher stand die Loki Serie automatisch bei mir auf einem Podest.

Aber - W-T-F - war das ein geniales Finale!

Dass Loki als einer der besten Bösewichte im Marvel Universum bekannt ist, ist einfach erklärt: Er hat einen Grund!
Stets wird er von seinem Bruder Thor daran erinnert, dass er nicht zum herrschen bestimmt ist und selbst wenn er sich mit Gewalt “einen Thron” nimmt, wird ihm der schnell wieder genommen.

Und dann verschlägt es eine Loki-Variante in Time-Variance-Authority und schon in Folge 1 von Staffel 1 lernt Loki, dass es da draußen noch viel mehr gibt, als sein kindisches Wetteifern um Untertanen.

Staffel 2 startet genau dort wo uns das Ende von Staffel 1 mit Fragezeichen zurückgelassen hat. Doch schnell wird klar, dass Loki jetzt ein neues Ziel gefunden hat. Während seine weibliche Variante Sylvi die Zeitstrahlen von der Kontrolle der TVA befreit hat, wandelt sich Tom Hiddleston’s Loki nun zum Beschützer der Zeitlinien um.

Und dann gingen die Gerüchte mit uns allen durch, wer wohl der “wahre” Bösewicht der Staffel sein wird, wenn Loki nun zum Retter wird. Aber Marvels brillianter Schachzug in Sachen Storytelling hat uns alle überrascht und uns ein Ende beschert, dass man sich immer wieder und wieder ansehen kann und sich einfach freuen kann, wie Loki endlich eine Bestimmung (Ein Glorreiches Ansinnen) findet.

Eigentlich wollte er immer schon der Gute sein, er konnte es nur nicht verkraften damit nicht alleine zu sein. Alleine der Gesichtsausdruck in Thor 3 nach seinen Worten “Euer Retter ist hier” sprach Bände, als wiederum Thor auftrat und ihm die Show stahl.

Am Ende von Folge 6 konnten weder Maschinen noch verbesserte Technik das Absterben der Zeitlinien verhindern. Hier konnte nur “ein Gott” einschreiten und sein Leben für alle anderen aufopfern, und so entstand ein neuer Lebensbaum.

So kann man das hervorragende Ende der Loki Serie umschreiben und wenn dann Soundtrack einsetzt, während sich die Mobius quasi von uns verabschiedet, dann ist man gleichsam glücklich wie auch traurig über die Reise, das Schicksal und die Bestimmung des neuen:
Loki, Gott der Geschichten.

Fazit

Wenn man mal von kleinen Begehrlichkeiten absieht, war diese Woche für Marvel Fans ein Fest. The Marvels hat mir “nur” einen empfehlenswerten Kinoabend beschehrt, aber Loki hat unsere Welt gerettet.

Und wenn das Storywriting so weitergeht, wie es Loki gezeigt hat, nämlich unvorhersehbar und trotzdem gut und schlüssig, dann steht Marvel nicht der aktuell gerne herbeigeredete Untergang, sondern ein gutes Comeback bevor.

Die letzten Filme konnten nicht mehr an die Erfolge der Phase 3 und Endgame anschließen … aber es heißt nicht, dass es in den kommenden Jahren nicht wieder solche Titel geben kann.

Ich freue mich jetzt auf jeden Fall schon darauf.

Watcom im Docker

2023-11-05T12:00:00+01:00

Dass wir heute unsere Linux und Windows Binaries auf Buildservern bauen lassen, ist Standard. Doch zu DOS Zeiten war es immer nur der eigene Computer, der das finale Release eine Software anfertigte.

Wäre es nicht faszinierend, wenn wir auch DOS Programme heute im Docker Container bauen lassen könnten?

Und tatsächlich wurden die Open Watcom Compiler für C, C++ und Fortran inzwischen auch auf Linux portiert, womit DOS Programme unter Linux kompiliert werden können.

Bei der

Frage: Läuft das auch in Docker?

wird es leider etwas komplizierter als es sein müsste, und so lautet die

Antwort: Watcom läuft, nur das Setup leider nicht.

Das Watcom Projekt liefert seine Ergebnisse in alter DOS/Win3x Manier als Installer-EXEn aus. In einer solchen über 100 MB großen Programmdatei ist das ganze Setup enthalten und ein UI lässt einen auswählen, was man alles haben möchte.

Das ist super für Benutzer vor dem Bildschirm, aber schlecht für jemanden, der die Installation automatisiert durchlaufen lassen will, und genau das brauchen wir für Docker.
Theoretisch könnte man das interne Script für die Installation zwar abändern, doch mir hat sich nicht erschlossen, wie man das schnell hinbekommen könnte.

Mein nächster Versuch lief dann über expect(1), mit dem man Eingaben an ein laufendes Programm hätte schicken können.
Das funktionierte sogar halbwegs auf der echten Konsole, und ich konnte die nötigen ENTER + Pfeiltasten an das Setup schicken, um bis zur Installation zu kommen … doch leider klappte es wieder nicht im Docker Container.

Lösung: Real installieren und kopieren

Am Ende ging ich den “einfachsten” Weg und war erstaunt, wie erfolgreich das war: Ich installierte OpenWatcom auf einer frischen Linuxumgebung und kopierte einfach alle installierten Dateien dann in ein TAR-Archiv.
Und eben dieses Archiv wurde dann in ein neues Docker-Image importiert. Das war es auch schon.

Das Watcom Setup installiert nämlich seine Dateien in /usr/bin/watcom und verändert sonst nichts am System.
Um die nötigen Environment-Variablen zu setzen, wird im Build-Script einfach der Inhalt von
/usr/bin/watcom/owsetenv.sh importiert:

1#!/bin/sh
2. /usr/bin/watcom/owsetenv.sh
3...
4cmake -G "Watcom WMake" ...
5wmake

Schon läuft der DOS Build in Linux und auch innerhalb eines Docker Containers.

Fazit

Vor 25 Jahren startete ich meine erste Linux-Distro noch von DOS aus (falls sich noch wer an UMSDOS erinnert …).

Und heute starte ich Buildprozesse für DOS aus Linux Docker Containern heraus.

… wer hätte das gedacht, aber es bereitet mir immer wieder Spaß solche scheinbar entfernten Systemgrenzen abzuschreiten.

Am Ende heißt es also:

Frage: Laufen Watcom DOS Builds auch in Docker?
Antwort: Ja natürlich!

Forgejo Runner

2023-11-04T12:00:00+01:00

Wäre es nicht schön zu wissen, ob der zuletzt hochgeladene Code auch korrekt gebaut werden kann?
Dafür haben wir CI/CD Features und Build-Agents auf unterschiedlichen Plattformen.

Codeberg bietet dafür sein Woodpecker CI an … doch etwas versteckt findet man auch Github Actions als forgejo Workflows.

Über Github actions kann der Server bei einem Ereignis (wie: “Neuer Code eingecheckt.”) einem registrierten “Runner” auftragen, ein Script auszuführen.

Und wenn dieses Script dann den neuen Code kompiliert, dann haben wir bereits einen Buildserver aufgesetzt.

Wieder ein neues YAML

Was mich an allen CI/CD Lösungen ankotzt sind deren Uneinigkeit, wie man einen Vorgang einheitlich abbilden kann. Jede f*cking Lösung erkennt, dass YAML super geeignet ist für diesen Job … und jede f*cking Lösung löst es ein bisschen anders.
Gerade so, dass man noch abstrakt erkennt, dass alle Lösungen eigentlich gleich aufgebaut sind, aber unterschiedlich genug, dass man jede Variante separat implementieren muss und ja kein Zeichen von A nach B kopieren kann.

… aber gut … genug gelästert.

Meine action-workflows liegen in der Datei /.gitea/workflows/build-platform.yml und sind etwa so aufgebaut:

 1on: [push]
 2jobs:
 3  build-linux-x64:
 4    runs-on: docker
 5    container: opendockergate/gate-build-env:deb.10.gcc.8.1
 6    steps:
 7      - name: checkout sources
 8        uses: actions/checkout@v3
 9        with:
10          submodules: true
11      - name: run linux GCC X64 build scripts
12        run: |
13          env | sort
14          cd scripts
15          ./build-make.sh
16          cd ..
17          mkdir -p ./dist/linux_x64
18          cp -r ./build/make/deploy/bin/* ./dist/linux_x64
19          ls -l ./dist/linux_x64
20      - name: compress artifacts
21        run: |
22          tar -cJvf artifacts-linux-x64.tar.xz -C ./dist/ .
23      - name: upload artifacts
24        uses: actions/upload-artifact@v3
25        with:
26          name: artifacts-linux-x64.tar.xz
27          path: artifacts-linux-x64.tar.xz
28          retention-days: 7

Man definiert also, dass bei einem push was passieren soll, und zwar wird der Job build-linux-x64 gestartet, der auf einem Runner läuft, den man unter dem Tag docker findet, und der soll den Container opendockergate/gate-build-env:deb.10.gcc.8.1 benutzen (also mein Dockerhub Repo).

Jetzt braucht man etwas Detailwissen. Man könnte sich jetzt gleich ein Shell-Script schreiben, das per GIT alles auscheckt und dann baut, doch dafür gibt es bereits fertigen Code, der das fehlertolerant abwickelt.
Man muss nur wissen, dass unter dem Namen actions/checkout@v3 ein GIT-Clone implementiert ist, und dass sich hinter actions/upload-artifact@v3 die HTTP API zum Hochladen von Build-Ergebnissen zum Forgejo/Codeberg Server verbirgt.

Denn diese Codes werten das Gewirr von Umgebungsvariablen aus und setzen die notwendigen Aktionen um mit wenig Einstellung zum Ziel zu kommen.

In der Mitte befindet sich dann unter run “mein Buildcode”, der im geklonten Repository die nötigen Schritte setzt, damit die Sourcen gebaut werden.

Docker Image brauch nodejs

Damit actions scripts wie checkout oder upload-artifact funktionieren, brauch das Docker image zwingend nodejs installiert.

Ein Basis Build-Image für C++ unter Codeberg Actions fängt bei mir also so im Dockerfile an:

1apt-get install build-essential cmake git nodejs apt-transport-https ca-certificates

Ohne nodejs treten jede Menge Fehler auf, die nicht unmittelbar auf die fehlende Node-Installation hinweisen.

Einen Runner braucht man auch

Der forgejo-runner ist ein kleiner Dienst, den man sich von der Github Release-Seite herunterladen und auf einer gängigen Linux-Distro mit Docker-Setup installieren kann.

Zuerst setze ich also eine neue Debian Maschine auf und installiere Docker darauf:

 1sudo apt update
 2sudo apt upgrade -y
 3sudo apt install -y ca-certificates curl
 4sudo install -m 0755 -d /etc/apt/keyrings
 5sudo curl -fsSL https://download.docker.com/linux/debian/gpg -o /etc/apt/keyrings/docker.asc
 6sudo chmod a+r /etc/apt/keyrings/docker.asc
 7echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/debian $(. /etc/os-release && echo $VERSION_CODENAME) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
 8sudo apt update
 9sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
10sudo systemctl start docker

Den forgejo-runner installiere ich dann in /opt/forgejo:

1sudo mkdir /opt/forgejo
2sudo chown $USER /opt/forgejo
3cd /opt/forgejo
4wget https://code.forgejo.org/forgejo/runner/releases/download/v3.3.0/forgejo-runner-3.3.0-linux-amd64
5chmod +x ./forgejo-runner-3.3.0-linux-amd64
6ln -s ./forgejo-runner-3.3.0-linux-amd64 ./forgejo-runner

Auf Codeberg.org erhält man in den “Actions/Runners” Einstellungen einen Registration-Token.

Diesen TOKEN nutzt man dann auf der Runner Maschine mit dem register Kommando und danach erzeugt man noch eine Standard-Konfiguration:

1./forgejo-runner register --no-interactive --token TOKEN --name my_runner_name --instance https://codeberg.org
2./forgejo-runner generate-config > config.yml

Nun hat man die versteckte Registrierungsdatei .runner und eine einsatzbereite Konfigurationsdatei config.yml im Verzeichnis und kann den neuen Runner auch schon im WebUI auf codeberg.org sehen.
Weitere Infos findet man dann unter docs.codeberg.org/ci/actions/.

Damit der Dienst bei jedem Systemstart ausgeführt wird, hilft einem bei systemd ein Eintrag wie in
/etc/systemd/system/forgejo-runner.service

 1[Unit]
 2Description=forgejo runner
 3After=network.target
 4
 5[Service]
 6ExecStart=/opt/forgejo/forgejo-runner daemon
 7WorkingDirectory=/opt/forgejo
 8Type=simple
 9User=mybuilduser
10Group=mybuildgroup

Die Kommandos:

1sudo systemctl enable forgejo-runner
2sudo systemctl start forgejo-runner

lassen den neuen forgejo-runner Dienst dann im Hintergrund ausführen.

Mein Runner läuft in einer kleinen VM auf meinem Server zu Hause und dieser fragt stets den Codeberg Server, ob neue Jobs anstehen.
Wenn neuer Code per git commited und gepusht wird, springt der Runner an, baut alles und lädt das Ergebnis zum Codeberg Server hoch, wo man es für einige Tage direkt wieder herunterladen kann.

Hinweis: Es dürfte ein Limit von 10 MB pro Upload gesetzt sein, wer mehr hochlädt bekommt HTTP Fehler zurück.
Ich habe meine Binaries vor dem Upload per
tar -cJvf artifacts.tar.xz -C ./output-dir/ . komprimieren lassen, um nicht zu schnell in das Limit hineinzulaufen.

Fazit

CI/CD kostenlos und alles mit Open-Source Software.
Wer hätte sich das vor 15 Jahren gedacht?

Zwar weist das Forgejo-Projekt immer auf seinen Alpha-Status hin und dass noch einige Fixes fehlen, bis man sich traut “produktiv” genannt zu werden, doch seitdem ich verstanden habe, wie das Ding funktioniert, liebe ich es.

Ja … es wäre mir lieber, wenn Gitlab, Bitbucket und Github sich auf ein YAML Format hätten einigen können, doch da das Setup so einfach umzusetzen ist, kann jedes GIT-Projekt schnell in ein CI-Projekt umgewandelt werden.

Codeberg und Forgejo beweisen, dass sie es trotz ihres vergleichsweise kleinen Team mit den großen Anbietern aufnehmen können und alle notwendigen modernen Features für ein Softwareprojekt bereitstellen können.

Monochrome Bitmaps

2023-10-29T12:00:00+01:00

Die ersten Bilder, die ich Mitte der 90er auf Disketten speicherte mussten klein sein. 24-bit Bitmaps waren ein No-Go, weil viel zu groß. 16 Farben mit 4-Bits war aber gerade noch möglich und daher quasi ein Standard.

Und als ich heute mit meiner Eigenimplementierung Probleme feststellte, lag es an einem noch älteren “besseren” Format, nämlich 1-Bit Schwarz-Weiß Bitmaps.

Windows 95 Setup lädt bei der Installation ein blaues Hintergrundbild mit einer den Schirm füllenden Tastatur in den Speicher und eben dieses Bild existiert auch weiter in c:\\Windows.
Als ich die Datei mit meinem eigenen Bildbetrachter öffnen wollte, startete eine längere Debugging Session.

Denn das “blaue” Windows-95 Setup-Bild ist nämlich eine Schwarz/weiß-Grafik. Oder besser gesagt eine 1-Bit Grafik mit einer Farbpalette für die Farben Schwarz und Blau. Das ganze wurde so hinge-dither-t, dass es wie ein Farbverlauf aussieht aber keiner ist.
Und wenn in einem Byte 8 Pixel gespeichert werden können, verringert sich die sonst unkomprimierte Bildgröße auf ein viertel von dem, was eine 4-Bit 16-Farben Grafik brauchen würde.

Mein erstes Problem war, dass ich in meinem Code gar nicht auf die richtige Implementierung umleitete, wenn “1” Bit pro Pixel im Header vermerkt war … denn solche Bilder gibt es heute überhaupt nicht mehr.

Doch dieser Bug war schnell behoben, und erst dann wurde zum ersten Mal sichtbar, dass meine Mono-Bitmap-Implementierung schon immer falsch waren.

Ich ging nämlich davon aus, dass das erste (niederste) Bit im Pixel-Byte auch gleich dem ersten Pixel selbst entsprach. Doch es ist genau umgekehrt: Das höherwertige Bit entspricht dem 1. Pixel, und würde etwa so adressiert werden:

1unsigned char* line_bytes;
2for(x = 0; x < width; ++x)
3{
4  pixel_bit = line_bytes[x / 8] & 1 << (7 - (x % 8));
5}

Ich hatte leider nur ein x % 8 anstatt von das 7 - (x % 8) im Code.

Fazit

Nun gut, wieder wurde ein kleiner Bug gefixt, und ich habe gelernt, wie Schwarz/Weiß Grafiken in der Regel im Speicher ausgerichtet sind.

Tatsächlich sind solche Formate ein wahrere Segen, wenn man wenig Speicher zur Verfügung hat. Echte Kompression würde oft auch noch mehr Speicher sparen doch am Ende muss immer alles einmal im RAM stehen, das wäre dann bei 640x480 Pixel:

24-Bit Bitmap: 921600 Bytes
8-Bit Bitmap: 307200 Bytes
4-Bit Bitmap: 153600 Bytes
1-Bit Bitmaps: 38400 Bytes

Man sieht also, wie viel Platz man verschwendet, wenn man nur 2 echte benutzte Farben auf 24-Bit aufblähen würde.

Windows mit libcrypto

2023-10-28T13:00:00+02:00

Wenn man vergisst die SSL/TSL Bibliotheken ins Zielverzeichnis zu kopieren, sollte das Laden eines davon abhängigen Programms fehlschlagen.
Doch so “zur Hälfte” konnte doch was geladen werden … und das war für mich ein intessantes Rätsel.

Wie sich herausgestellt hat liefert Microsoft sein Windows seit 2018 offenbar mit einer libcrypto Variante aus.

Wer SSL/TLS Features benötigt, ist grundsätzlich von Fremdbibliotheken abhängig. Unter Linux war das schon immer so und Windows … naja dort eigentlich auch. Die alte (wincrypt) und neue (bcrypt) Implementierung in der WinAPI ist immer auf dem Stand, als die Windows Version auf den Markt kam … also immer veraltet.

Zum Glück stehen mit OpenSSL und libreSSL zwei hervorragende Kandidaten parat, die die Lücke problemlos füllen … wenn man sie eingebunden bekommt.

Linkt man die beiden Teilbibliotheken libcrypto und libssl dynamisch, darf man sich beim Deployment ärgern, wenn sie nicht vorhanden sind oder in der falschen Version vorliegen.
Link man sie statisch, hat man garantiert das Richtige dabei, bekommt aber eine 2 MB+ große EXE, die sonst nur 200 KB groß gewesen wäre.

Ich habe daher wie so oft eine duale Strategie für SSL vorgesehen und kann entweder mit der statischen Variante arbeiten, oder lade zur Laufzeit die notwendigen Funktionspointer per Hand nach, womit ich ebenso nicht gegen SSL-Libs linken muss und beim Start einfach die “nächst-greifbare” Variante geladen wird.

Windows 10 and Server 2019 mit libcrypto

Microsoft hat interessanterweise im Jahr 2018 erstmals eine ältere Version der libcrypto.dll aus dem libreSSL Projekt ins Windows\\System32 Verzeichnis gelegt, jedoch nicht den SSL/TLS Teil.
Im Server 2016 und älteren Windows-10 IOT Versionen von 2016 ist die DLL noch nicht vorhanden.

Genau das führte bei mir zu einigen Problemchen beim “dynamischen” Nachladen der Funktionalität. Denn statt wie erwartet nichts zu finden, wenn keine DLLs von mir ausgeliefert werden, wurde plötzlich libcrypto geladen und die nachfolgenden libssl schlug fehl.

Auf diesen Halbstand war ich nicht vorbereitet und somit musste ich die Fehlerbehandlung anpassen.
… doch aus dieser interessanten Erkenntnis leitet sich ein anderer Vorteil ab.

libssh2 mit Boardmitteln betreiben

libssh2 nutzt für den Aufbau von SSH Sitzungen ausschließlich Funktionen der libcrypto aber braucht keinen SSL/TLS Support. Bisher musste ich immer eine vollständige libreSSL oder OpenSSL Schnittstelle bereitstellen, wenn ich SSH einsetzen wollte … doch mit einem aktuellen Windows kann man diese Funktionalität auch vom OS Kern beziehen.

Da Import-Bibliotheken für die libcrypto fehlen, habe ich einfach statische Wrapper um die notwendigen APIs erstellt und nun kann libssh2 gegen meinen statischen Wrapper linken, der im Hintergrund dann nur die libcrypto lädt und die Funktionspointer importiert.

So entsteht dann eine schlanke SSH Implementierung, die vom OS mitverwaltet wird und fette Crypto/SSL Kopien entfallen.

Fazit

Windows wird langsam OpenSource-tauglich.

Ich kann wieder mal nicht nachvollziehen, warum diese freie Bibliothek erst so spät in Windows Einzug gehalten hat und verstehe schon gar nicht, warum der SSL/TLS Teil wieder fehlt.

Im allgemeinen Fall ist es weiter sicher besser die ganze Crypto/SSL Implementierung selbst bereitzustellen … aber für neu entwickelte Tools ist das Vorhandensein von OpenSource-Kryptographie zumindest mal ein guter Start.

NetBSD mit X11

2023-10-22T13:00:00+02:00

Da installiert man sich ein “kleines und feines” NetBSD mit SSH Zugang, damit man schnell mal was drauf kompilieren kann, und dann bekommt man nichts durch den Compiler, was X11 benötigt.

Wieso kann man das nicht nachinstallieren?

NetBSD ohne X11

Nach einer minimalen Installation beginnt bei mir meist das “Nachinstallieren” von Dingen, die man zum Kompilieren und Linken braucht.
Im Fall des GATE Frameworks gehören da auch UI-Bibliotheken wie X11 dazu.

Und für gewöhnlich liefert der Paketmanager des Betriebssystems die gewünschten Binärdateien und Sourcecodes nach.

Startet man unter NetBSD mit pkgin install motif wird ein entsprechendes Paket gefunden … und an der Stelle beachtete ich nicht weiter, was sonst noch auf der Konsole stand.

Doch beim Kompilieren erreichte mich sofort die Meldung Xm/Xm.h würde nicht gefunden werden, gefolgt von allen möglichen anderen X11/* Includes.
Motif und X11 wurden also nicht installiert.

Beim erneuten Aufruf von pkgin sah ich dann schnell, dass “Warnungen” ausgegeben wurden, dass /usr/X11R7 nicht existiert, was eine Voraussetzung für die Installation von Paketen der X11 Familie ist.

1/usr/X11R7/lib/libX11.so.7, needed by libXft-2.3.8nb1 is not present in this system.  
20 to remove, 0 to refresh, 0 to upgrade, 0 to install
30B to download, 0B of additional disk space will be used
4the following packages have unmet requirements:   libXft-2.3.8nb1 motif-2.3.8nb3 emwm-1.1nb1

Lösung: Upgrade Installation mit X11

Unter NetBSD ist X11 eine Kernkomponente, die nur bei der OS Installation auf dem System ausgerollt wird. Man kann sie nicht nachträglich über den Paketmanager installieren lassen.

Man muss also sysinst aufrufen um die lokale Installation zu erneuern und dabei können auch X11 und sämtlichen Sourcen installiert werden.
Das Text-UI lässt einem alles notwendige auswählen und startet danach den Download und die Integration der neuen Komponenten.

Fazit

Ich bin inzwischen schon so an den (Debian-) Linux Ablauf gewöhnt, immer nur das Basissystem zu installieren und UI nur bei Bedarf nachzuladen, dass ich mir gar nicht mehr vorstellen konnte, dass das auch noch anders ablaufen kann.

NetBSD ist eben so ein Fall … und es ist gut, dass ich auch mal wieder “eine andere Sichtweise” wahrnehmen durfte.

Jekyll update

2023-10-21T13:00:00+02:00

Als ich 2018 mit der Blog Software Jekyll anfing und damals mit Ubuntu 18.04 und dem Vorgänger 16.04 arbeitete, sah das Setup komplizierter aus, als es hätte sein müssen.

Auf heutigen Debian Varianten sind die damaligen Kunstgriffe nicht mehr notwendig, teilweise stören sie eher.

Es ist also Zeit, die Doku zu überarbeiten.

Jekyll ohne root-Rechte und Systeminstallation

Wenn man die Ruby GEM-Module mittels sudo installiert, landen sie in Verzeichnissen, wo sie von normalen Accounts zwar gelesen, aber nicht editiert werden können.

Die aktuelle Empfehlung für eine Jekyll Installation sieht also so aus, dass man die GEMs im HOME Verzeichnis ablegt.
Hierfür nutzt man am besten die Umgebungsvariable GEM_HOME, und fügt den bin-Pfad der GEMs der PATH Variable hinzu.

Die Installation sieht dann so aus

1sudo apt-get install ruby-full build-essential zlib1g-dev -y
2echo '# Install Ruby Gems to ~/gems' >> ~/.bashrc
3echo 'export GEM_HOME="$HOME/gems"' >> ~/.bashrc
4echo 'export PATH="$HOME/gems/bin:$PATH"' >> ~/.bashrc
5source ~/.bashrc

Ist der Pfad-Export erst in .bashrc angefügt, stehen die aktualisierten Variablen in jeder neuen Shell-Sitzung zur Verfügung.

Nun reicht ein einfaches

1cd /path/to/my-jekyll-project
2bundler install
3bundler update

um alle notwendigen Abhängigkeiten zu erhalten.

Am Ende kann bundler exec jekyll build oder ... serve beweisen, dass die Webseite neu generiert werden kann.

Fazit

Langsam wird es Zeit, dass ich alle meine Dokus mal verifiziere und schaue, ob sie noch funktionieren. Denn mit jeder neuen OS-Version gibt es Änderungen und schon funktionieren beschriebene Scripts des Vorgängers nicht mehr oder zumindest nicht mehr vollständig.

In Sachen Jekyll hat sich die Prozedur sehr vereinfacht.
Und während damals noch Jekyll v3 im Einsatz war, läuft heute v4 und bringt einige Verbesserungen mit sich.

ZLIB ohne Level 9

2023-10-15T13:00:00+02:00

Viele Probleme meiner Arbeit am GATE Projekt liegen bei den Compilern. Man würde glauben, wenn dieses gelöst sind, also alles kompiliert, wäre man fertig.

Leider nicht ganz, denn plötzlich schlägt z.B.: die Initialisierung der ZLIB zur Laufzeit fehl.

Die ZLIB nutzt beim Komprimieren einige Parameter wie etwas Compression-Level, Memory-Level und Window-Bits. Hierfür existieren Konstanten wie

compression-level: Z_BEST_COMPRESSION (==9)
memory-level: MAX_MEM_LEVEL (==9)
window-bits: MAX_WBITS (==15)

Da ich die besten Ergebnisse haben möchte, nutzte ich diese Werte als Standard in meine Codes, nur das Compression-Level war von außen einstellbar.

Unter DOS kompiliert dieser Code zwar, kann jedoch dann nicht ausgeführt werden, es kommt zum Abbruch der Initialisierung in deflateInit2_().

Mit jeder Menge printf() Debugging kam ich dann zu den Zeilen, die die Parameter umsetzen und hier findet die Allokation eines Puffers statt, die vereinfacht so aussieht:

1Byte* window = malloc((1 << window_size) * 2 * sizeof(Byte));

Bei 2^15 * 2 landen wir bei 2^16 bytes, also 65536. Theoretisch würde das ein vollständiges DOS Segment sein, doch mit malloc können wir kein ganzes Segment in einem kapern.

Etwas ähnliches passiert dann auch noch beim Memory-Level, denn da wird zum Level 7 addiert, womit man auch wieder auf 16 Bits kommt.

Lösung: Kleinere Parameter

Meine Lösung war dann denkbar einfach (und wurde zusätzlich auch gleich auf Windows CE angewendet):

1#if defined(GATE_SYS_WINCE) || defined(GATE_SYS_DOS)
2        int memlevel = MAX_MEM_LEVEL - 2;
3        int window_bits = MAX_WBITS - 1;
4#else
5        int memlevel = MAX_MEM_LEVEL;
6        int window_bits = MAX_WBITS;
7#endif

Mit den gepatchten Parameter läuft die ZLib brav weiter und generiert mit deflate komprimierte Ergebnisse, allerdings sind die jetzt potentiell etwas schlechter, weil die Wörterbücher kleiner sind. Aber damit kann man auf diesen Plattformen leben.

Fazit

Ab sofort kann das arch Tool .gz und .zip Archive erzeugen und auch wieder unter DOS auspacken.
Damit bin ich schon zufrieden.

Ich müsste jetzt noch Tests mit Archiven machen, die unter Windows oder Linux erzeugt wurden und größere Window-Bits hatten und ob die beim Entpacken Probleme machen. Allerdings sehe ich im inflate() Code keine Allokationen, die davon abhängen, zumindest nicht bei der Initialisierung.

DOS ist inzwischen eine wichtige Plattform für mich geworden, um zu verifizieren, ob Code wirklich plattformunabhängig läuft. Die Window-Bits sind ein schönes Beispiel für Einschränkungen, die man einfach nur wissen muss, um sie mit wenig Code überwinden zu können.

AD Server Transfer auf N100

2023-10-14T13:00:00+02:00

Mit meinem neuen N100 basiertem Board, das als neuer Domain-Controller arbeiten darf, endet die 5-Jahres-Mission meines E3940 Systems.

Ein kritischer Punkt ist immer die korrekte Übertragung der Active Directory Rolle, und diesmal geschah das “geordnet” und nicht einfach durch hartes Umschalten.

Ein neuer N100 4-Kern max-3.4 GHz Prozessor löst nun den max-1.8 GHz Intel Atom x5 in meinem Wohn/arbeitszimmer ab. Ich erwarte mir vom Sprung von 14 auf 7nm und von dder Verdoppelung der Maximalleistung schon einiges an Geschwindigkeitzugewinn.
Auch darf der neue Knecht mit 16 GB RAM werken, während sein Vorgänger nur 8 GB vertrug.

Active Directory Server umbenennen

Unter dem Namen SVR01 spreche ich schon lange mein “Primärsystem” an, das rund um die Uhr läuft. Blöd ist nur, wenn man einem neuen System diesen Namen geben will und daher war mein Idee, das alte Gerät im AD Verband umzubenennen, und das neue System mit dem somit wieder freiem Namen frisch als Server aufzunehmen.

Der alte Server SVR01 sollte auf SVR99 umgenannt werden, während mein zweiter Domaincontroller SVR02 “zur Sicherheit” mitlief.

Die vorgeschlagene Prozedur war einen “zusätzlichen” Namen dem Server hinzuzufügen mit:

1netdom computername oldname.domain.tld /add:newname.domain.tld

Dann einen Reboot durchführen und den neuen Namen als Primärnamen zu deklarieren mit:

1netdom computername oldname.domain.tld /makeprimary:newname.domain.tld

Und nach einem weiteren Reboot kann man den alten Namen per:

1netdom computername newname.domain.tld /remove:oldname.domain.tld

entfernen.

Tatsächlich funktionierte das auch so. Allerdings traten gleich nach der netdom Ausführung mehrere Fehler in diversen MMC Modulen auf, die dann ihren Server nicht mehr finden konnten.

Doch aus diese Probleme lassen sich per Reboot “gesundstreicheln”.

FSMO Rollentransfer

Die 5 FSMO-Rollen (Flexible Single Master Operation) können jeweils nur von einem Server ausgeübt werden, alle anderen leiten die Anfragen an den “Master” weiter.
In meinem Fall liegen alle gemeinsam auf einem Server, da alle andere Maschinen nur bei Bedarf eingeschaltet werden.

Ich fand es schon vor 20 Jahren seltsam, dass Microsoft die UIs zur Übertragung einer Rolle an so unterschiedlichen Orten versteckt hat:

Die Rollen für den “RID”, “PDC” und “Infrastructure” Master findet man unter “Users and Computers”
Die “Domain Naming” Rolle ist unter “Domains and Trusts” versteckt.
Und der “Schema” Master Dialog befindet sich im MMC Snap-in “Active Directory Schema”

Doch dieses Schema-Snap-In ist auf Standard-Installationen gar nicht zugänglich. Man muss erst regsvr32 schmmgmt.dll zur Registrierung aufrufen und kann dann in einer leeren mmc.exe Sitzung unter “Add/Remove Snap-in” das Schema-Snap-in einfügen.

Man hätte das auch per ADSI-Edit manuell setzten können, doch wenn möglich, sollte man immer den “offiziellen” Weg gehen. Wer weiß schon, was Microsoft im Hintergrund mit jeder neuen Version verändert.

Workfolder neu einrichten

Mit dem neuen Server waren natürlich auch meine Workfolder weg. Sie waren natürlich noch da, und zwar am alten Server, und als Kopie auf meiner lokalen Maschine, doch eben nicht mehr “synchronisiert”.

Beim Aufsetzen der Workfolder fing wieder das elende Spiel mit den Zertifikaten an. Man musste eines mit dem richtigen Namen erstellen, dann für das HTTPS Protokoll für die Workfolders freigeben und sicherstellen, dass ihm auch am Client vertraut wird.

Meine Umstellung fiel zufällig genau auf die Woche, wo mein altes Zertifikat ausgelaufen war und ich mich wirklich lange wunderte, warum alle Verbindungen abgebrochen wurden.

Wie toll wäre es hierfür ein Testprogramm zu haben, dass einem genau sagt, warum die Synchronisation nicht funktioniert. So musste ich zwei Stunden herumraten, doch am Ende klappte auch das wieder.

Server Backup

Der letzte Schritt war die Neueinrichtung des Server Backups. Das war auf der bestehenden Platte nur möglich, wenn die alten Backups gelöscht wurden, doch da ich ohnehin alles doppelt gesichert hatte, war das auch noch zu verkraften.

Fazit

Mein neuer kleiner ITX Server ist erstmals kein originaler Intel Atom mehr, denn von denen gibt es keinen leistbaren in der neuen Fertigungstechnik. Dennoch überzeugt der N100 auf Anhieb und rechnet dann auch wirklich doppelt so schnell die Windows-Update Hashes durch.

Größter Pluspunkt ist, dass ich jetzt endlich einen funktionierenden Grafikkartentreiber am Server habe.
Ich brauche am Domaincontroller zwar keine UI-Power, aber die Fixierung auf den Microsoft-Basic VGA-Treiber, weil ansonsten Blue-Screens flogen, war schon ziemlich nervig.

Ich bin jedenfalls mit dem Update zufrieden und freue mich, dass der Active Directory Transfer diesmal so problemlos funktioniert hat.

Mal sehen, ob ich in 5 Jahren dann wieder einen solchen Hardwarewechsel durchführe, oder ob das dann schon ein Roboter für mich erledigt.

Serien: Loki 2, Ahsoka, Ragnarök

2023-10-08T13:00:00+02:00

Während ich gespannt auf die neue Loki Serie auf Disney+ gewartet habe, kamen auch andere Titel heraus, in die ich hineinschnuppern wollte. Das Star Wars Franchise kann mit “Ahsoka” aufwarten und bei Netflix entdeckte ich zufällig eine andere “Loki-Variante” in der norwegisch-dänischen Serie Ragnarök

Die Abendunterhaltung ist also gesichert.

Marvels Loki Staffel 2

Es geht weiter mit Loki Laufeyson, dem aus der Zeit gefallenen Variante des Gottes des Schabernaks, und wie er nun mit der neuen TVA umgehen soll.

Am Ende der ersten Staffel sollte eine Entscheidung getroffen werden. Zwei Lokis am Ende der Zeit. “Die eine” (Sophia Di Martino) wild entschlossen die Zeitstrahlen vom Diktat der Time Variance Authority zu befreien und “unser” Loki Tom Hiddleston, der den seltsamen Verwaltungsapparat, der die Zeitstrahlen kontrolliert, zunehmend als notwendiges Übel ansieht.

Ich bin wirklich verdammt gespannt, wie dieses Geschichte nun weitergesponnen wird. Loki selbst springt jetzt offenbar unkontrolliert durch die Zeit und lernt daher jede Situation aus einem anderen Blickwinkel kennen. Dieser Handlungsstrang hat klar meine volle Aufmerksamkeit.

Ich bin also gespannt, wie die Serie am Ende aussehen wird.

Ragnarök

Näher am Original der nordischen Mythologie bewegt sich die Serie Ragnarök, die aktuell auf Netflix ausgestrahlt wird.

Hier findet ein Art Reinkarnation der Götter Thor und Loki in zwei Teenagerbrüdern statt, die in den Mitgliedern eines lokalen Familienunternehmens ihre Feinde finden, nämlich die unsterblichen Riesen (Jötun), gegen welche die Götter früher bereits antreten mussten.

Während die sehr menschlich aussehenden “Riesen” die Welt mit Umweltverschmutzung bedrohen, müssen die Teenager erst ihre göttlichen Kräfte entdecken. Beide Seiten bekommen Hilfe von diversen anderen mythischen Personen und Ritualen, bis es dann immer wieder mal zum Kampf kommt.

Ein bisschen erinnert es mich an die Twilight-Story. Sie hat dem Vampirmythos nicht immer gut getan … aber hat ihn trotzdem auch wieder aufblühen lassen.
Ragnarök könnte das Gleiche auch mit der nordischen Mythologie durchmachen.

Es ist zwar mehr als seltsam, wenn sich ein junger Thor primär über die Chatnachrichten einer Schulkollegin den Kopf zerbricht, und wenn Loki als Transvestit neue Persönlichkeitsformen durchlebt … aber, so ist die Welt heute nun mal.

Und es fällt positiv auf, dass sich die Produzenten viele Gedanken darüber gemacht haben, wie sie Stücke aus den alten Überlieferungen detailreich ins 21. Jahrhundert übersetzen können.

Fazit

Ab in den Norden!

Ich finde, dass wir über die Götter des Nordens vergleichsweise wenig wissen. Griechenland und Rom wie auch alle Stationen des Christen- und Judentums wurden tausendfach verfilmt und neu erzählt.

Jeder kennt die alten Propheten und wer mit Zeus im Bett war, weil wir es schon im Fernsehen gesehen haben. Thor und Loki kennen wir nur in sehr verfremdeter Art aus den Marvel Universum, aber sonst wissen wir recht wenig darüber.

Ich freue mich also, dass nun auch nicht-Marvel-Serien diesen Themenbereich aufgreifen.

Das 5. Blog-Jahr

2023-10-07T13:00:00+02:00

Ich mag ja meine Beiträge hier recht unstet veröffentlichen, aber es sieht so aus, als bleibt mir die Motivation weiter erhalten.

Seit Oktober 2018 sammle ich meine Lebenseindrücke als Entwickler und ich glaube, das bringt auch was.

2018 es mir daran gelegen, einiges niederzuschreiben, was mir “schon lange unter den Nägeln brannte”.
Inzwischen hat sich der Brand gelegt und nun sind es aktuelle Themen wie auch Erinnerungen an manche Ereignisse, die den Blog vorantreiben.

Ich lerne aktuell viel aus der Vergangenheit, wenn ich z.B. für DOS Codes umschreiben muss, damit sie stückweise in 64 KB Segmente passen. Genau das macht dann aber auch Windows und Linux Code besser, wenn nicht immer gleich ein Gigabyte RAM aquiriert wird und dann das Paging anspringt.

Gleichzeitig treiben mich Neuentwicklungen im Web oder auch aus dem Beruf zu Sprachen wie Python, Rust oder ZIG, was mich auch wieder Codes und Interfaces überdenken lässt.

Manchmal denke ich mir, ich könnte nach 20 Jahren eigentlich schon die Nase voll haben von der Softwareentwicklung … doch diese Welt ist so unglaublich groß, unterschiedlich und fordernd, dass ich mir tatsächlich vorstellen kann, dass mich das weitere 20 Jahre voll ausfüllt.

Und in diesem Sinne darf auch der Blog noch möglichst lange hier mitlaufen.

Fazit

Also auf geht’s in die nächste Runde!

Kreta

2023-10-01T13:00:00+02:00

Zuletzt hatte ich mich vor 10 Jahren in ein Flugzeug gesetzt. Nun war es wieder so weit um eine Woche auf der südlichen griechischen Insel Kreta zu verbringen.

Es war nicht nur ein Geburtstagsgeschenk an meine Mutter, sondern auch eine Erinnerung an die 90er. Damals flogen Großmutter, Mutter und ich fast jedes Jahr in den Ferien an irgend einen Strand um dort auszuspannen.

Nach vielen Jahren beschlossen somit meine Mutter und ich, dieser Tradition gedenkend, ebenso nochmal eine Reise gemeinsam anzutreten.

Von der Buchung zum Flug

Nachdem uns täglich Werbeangebote der BILLA Supermarktkette ins Haus fliegen und diese ebenso Urlaubsreisen anbieten, war unser Anbieter schnell gefunden. Schließlich wollten wir keine Action-reiches Programm, sondern einfach nur eine Woche “chillen”, wie man heute sagt.

Vor dem Jahr 2000 fuhren wir entweder 30 km in eine andere Stadt um ein Reisebüro zu finden, oder wir konnten im “Reiseangebot”, des hiesigen Bankschalters etwas finden.

Heute erledigt das der Webshop ganz genau so wie er das für alle anderen Alltagsprodukte abdeckt. Das Reisepaket wird für X Personen gewählt und die Kontaktdaten werden übergeben. 10 Minuten später erhält man die Zahlingsinformationen für die Online-Überweisung.

Ein bisschen Zeit vergeht zwischen der Zahlung und der Bestätigung. Heute erwartet man die Fertigstellung binnen Minuten automatisch, doch bei einer Reise, sitzt noch ein Mensch am anderen Ende und gibt die Bestellung erst 2-3 Tage später frei, wenn die Zahlung eingegangen ist.

Nicht inkludiert war unser Transport zum Flughafen Wien-Schwechat. Eine günstige Option ist entweder mit der Bahn hinzufahren oder das Auto zu nehmen und dort eine Woche am Parkplatz abzustellen.
Interessant waren die Kosten, die beim Flughafenparkplatz selbst bei 120 Euro für eine Woche starteten. Der neben dem Flughafen liegende Mazur Parkplatz kostet nur 75 Euro pro Woche und bietet einen Shuttledienst alle 20 Minuten zum Flughafeneingang. Für dieses günstige Angebot entschieden wir uns dann.

Der Online-Checkin des Fluges war erst genau 24 Stunden vor Abreise durchführbar. Letztendlich tippt man dort nur Namen, Mailadresse und Alter ein und kann dann “Zusatzdienste” wie “mehr Gepäck”, Sitzplatzwahl oder Snacks während des Flugs wählen.
Diese Dienste lassen sich bei der Bestellung nur per Kreditkarte abwickeln, und nachdem ich meine zurückgegeben hatte, konnte ich keine dieser Optionen nutzen.

Meine Befürchtung, wir würden jetzt irgendwo im Flugzeug verteilt sitzen, trat aber nicht ein, und wir bekamen zwei Plätze nebeneinander automatisch zugewiesen.

Da bei den Online-Boardtickets extra dabei stand, man solle sie ausdrucken, tat ich das auch und kam “klassisch” mit Klemmbrett zum Flughafen.
Aber wie erwartet wäre das nicht notwendig gewesen, denn das Scannen des Bar-Codes der digitalen Karte funktionierte auch einfach per Smartphone und so kann man auch papierlos abreisen.
Per Mail geschickt bekommen hatten wir auch PDFs mit Transfer- und Hotel “Voucher”, die ich zur Sicherheit ebenfalls im Handgepäck hatte.

Reif für die Insel

Auch am Zielflughafen in Heraklion klappte alles problemlos. Wir trotteten vom Flugzeug zu den Gepäcksbändern und danach aus dem Flughafengebäude, wo direkt gegenüber kleine Kabinen mit allen möglichen Touristik-Unternehmen aufgestellt waren. Die für uns zuständige Reisehelferin, fand unsere Namen auf ihrer Liste und verwies uns zum nächsten Bus mit Nummer X, der das Gepäck verlud und uns zum Zielhotel brachte.

Auch dort füllten wir nur noch unsere Daten im Hotelformular aus und schon ging es ab auf die Zimmer.

Also kurz gesagt: Alles war unkompliziert und einfach.

In den folgenden Tagen genossen wir schönes Wetter, lange Spaziergänge und vor allem das üppige köstliche Essen.
Nur das Meer war uns schon zu reißerisch. Kretas Küste ist sehr felsenreich und in unserer Gegend in Chersonissos Stadt waren Standstrände eher klein gehalten und immer wieder von scharfen Felsen und Gestein unterbrochen.

Der Wellengang war Ende September/Anfang Oktober zwar noch nicht extrem, doch die mutigen Gäste, die sich ins Wasser wagten, wurden schon ganz schön gefordert. Und als wir dann noch eine ältere Dame sahen, die im Wasser unglücklich gestürzt war, sich eine Krampfader aufgeschlagen hatte und das Blut nur so sprizte, meinten wir:

Hey, wir müssen eigentlich gar nicht zwingend ins Wasser!

Die griechische Touristenkultur ist nett und aufgeschlossen … manchmal vielleicht auch ein bisschen zu sehr aufgeschlossen, wenn einem ein Kleidungsstück 5 mal versucht wird zum Kauf anzutragen, aber in Summe war an jeder Ecke was zu entdecken und sowohl das äußere wie auch das persönliche Klima perfekt.

Dass im August hier bis zu 50 Grad geherrscht haben sollen, will ich mir nicht vorstellen, denn das wäre die Hölle gewesen. Doch Ende September mit 23 bis 28 hat es für uns genau gepasst.

Lediglich die Nächte waren für uns ungewohnt warm, was aber mit der Klimaanlage ausgeglichen werden konnte. Und auch die Verbindung zur Heimat riss nie ab, denn Internet gab es - zu meiner Freude - mit voller Bandbreite kostenlos.
(Das war vor 10 Jahren noch kein Standard in Hotels).

Rückreise

Genau wie vor dem Hinflug war auch der Online-Checkin für die Rückreise 24 Stunden vor dem Flug möglich und wieder genau so unkompliziert. Die Rezeption half beim Ausdrucken von Formularen und bei der Planung von Frühstück und der Busabholung.

Letztlich kamen wir wieder am Flughafen an, mussten nur die Nummer unseres Gepäck-Checkins an einem der Monitore ablesen, das Gepäck aufgeben und hatten noch etwas Zeit bis der Flug nach Wien zum Boarding fertig war.

Und während unsere Reise wirklich perfekt einfach war, taten mir zahlreiche andere Fluggäste leid, die dort seit Stunden auf ihren Flug warteten und einfach nicht wegkamen. Eine andere Perversion war dann, die Ausrufung eines Fluggastes über 90 Minuten hinweg, der immer mit den Worten “Last call for …” eingeleitet wurde.
Ich meine, da sitzen 100e Leute in einem Flieger, warten dass er startet und dann tut sich nichts, weil ein Typ fehlt.

Naja … hier kann ich nur sagen: Was für ein Glück, dass bei uns alles so reibungslos verlief.

In Wien angekommen fiel uns nur eines deutlich auf: der Flughafen muss 10 mal größer sein, als der auf Kreta. Alleine die Gehwege waren der Wahnsinn und offen gesagt für ältere Personen durchaus herausfordernd.

Dennoch bekamen wir unser Gepäck, fanden zur Shuttledienst-Haltestelle, wo uns der Bus zum Auto brachte … und dann … tja dann war die schöne Woche auch leider schon wieder vorbei.

Fazit

Ich bin ja eigentlich ein Flugmuffel und stets besorgt, was da alles schief gehen kann. Doch hier muss ich ganz klar sagen:

Gerne wieder!

Das einzige, was nicht funktioniert hat, war die Zubuchung per Kreditkarte, da ich ja keine hatte. Hier frage ich mich schon, warum alle Shops, und die Reise selbst mehrere Zahlungsoptionen inklusive PayPal bieten, und nur die Fluglinie selbst für die Sitzplatzwahl auf Kreditkarte besteht. Aber naja … notwendig war’s ja nicht, ist also auch egal.

In diesem Sinne geht man Dank an Kreta und die schöne Woche, die wir dort verbringen durften. Und wenn es möglich wäre, dann hätte ich gerne einen Souvlaki Koch hier bei mir. Verdammt, ich vermisse es am Abend im Buffet alles durchprobieren zu können, und am Ende dann noch so einen leckeren Spieß zu verzehren.

Das Essen war echt großartig (wie mein Bauch auch immer noch anzeigt).

GIT Migration

2023-09-30T13:00:00+02:00

Bei einer Migration stellt sich immer die Frage:

Was nehme ich mit? Was lasse ich zurück?

Die GIT History ist so ein Thema, denn die will man meistens behalten, um Entwicklungsschritte nachvollziehen zu können. Aber andere Dinge möchte man gerne vergessen lassen.

Mit meiner geplanten Migration von Bitbucket zu Codeberg kam ich zu dem Schluss, dass ich die History nicht übernehme … oder anders gesagt, ich kopiere einfach die aktuellen Sourcen in ein neues GIT Repository.

Die primäre Grund dafür:

Ich Idiot hatte fette Binärdateien ins alte Repo aufgenommen.

Unter den “externen Bibliotheken” war bekanntlich auch GTK, welches ich eigens für Windows kompiliert hatte. Diese Bibliotheken umfassten viele Megabytes an Binärdateien, die das Repo extrem aufgebläht hatten.

Deshalb erfolgte zuerst die Abspaltung des extlibs Repositories für Fremdbibliotheken und diese durften nur in reiner Source-Form commited werden.
Und dann wurde das gate Projekt nur mit dessen Sourcen separat angelegt.

Anders sieht es beim opengate Repository aus, in dem die Quellen der Webseiten von opengate.at liegen.
Hier klonte ich zuerst das neue leere Repo, fügte dann den Pfad zum alten Repo hinzu, holte die alten Inhalte auf die lokale Maschine und führt dann einen Merge durch, der die alten Inhalte in den Branch des neuen Repos integrierte.

Das sieht dann etwa so aus:

1git clone https://new-server.tld/path_to/my_new_project.git
2cd my_new_project
3
4git remote add old_stuff https://old-server.tld/path_to/my_old_project.git
5git fetch old_stuff
6git merge old_stuff/master
7
8git push

Nun kann ich jede Änderung bis zur Erstellung des ersten Blog-Eintrages in GIT zurückverfolgen.

Im Fall vom gate Projekt wäre das vielleicht auch nicht schlecht gewesen, doch hier war mein Ziel mit einem schlanken Repo zu beginnen.

Außerdem bin ich inzwischen ein Fan von squash Mergerequests geworden, bei denen mehrere Commits zu einem zusammengefasst werden.
Mein künftiger main Branch soll nicht jede kleine Änderung erhalten, sondern nur noch gesammelte fertige Features (oder fertige Blogposts).
Schließlich bringt es nichts, 1000 einzelne Commits zu speichern, bei denen immer nur ein Zeilchen angepasste wurde.

Fazit

Die GIT Migration zu Codeberg geht gut voran, obwohl ich jetzt auch noch viele weitere Kleinigkeiten fixen muss, damit das Gesamtsystem wieder so bauen kann wie vorher … und das auf allen gewünschten Plattformen.

Migrationen sind mühsam, aber bieten immer auch eine gute Gelegenheit um aufzuräumen, denn:

Nur saubere GIT Repos sind gute GIT Repos.

Externe Bibliotheken

2023-09-24T13:00:00+02:00

Wenn es um die Enwicklung von Basis-Strukturen und OS-Anbindungen geht, mache ich natürlich alles selbst. Aber heute braucht man auch Kompression, Verschlüsselung und jede Menge Datenformate um mit der Welt “reden” zu können.

Dies alles erledigen “externe Bibliotheken”, die ich bisher immer im Schlepptau dabei hatte. Nun bekommen sie ihr eigenes Vehikel.

Die Verwaltung von Abhängigkeiten ist in C und C++ leider immer noch ein ungutes Thema. Gleich vorab würde ich sagen: Nutzt CONAN!
Ja, CONAN ist mühsam zu erlernen, aber es bietet tatsächlich genau die Infrastruktur, mit der wirklich jedes Kompilat mit jeder möglichen Einstellung abgebildet wird.

An der Stelle wäre das Thema “Externe Bibliotheken” eigentlich auch schon beendet und das GATE Framework unterstützt auch einen CONAN-basierten Build für alle Abhängigkeiten.

Aber:

Leider erfüllen viele Bibliotheken heute nicht “meine” Anforderungen. Und die handeln alle von Kompatibilität hin zu sehr alten Systemen. Für Windows 95 brauche ich einen MSVC 2003 und für Haiku einen GCC 2.

Daran scheitert vieles … doch meistens nur an wenigen Zeilen.

Und aus diesem Grund pflege ich gepatchte Varianten von Bibliotheken wie OpenSSL, ZLIB, LZMA, JPEG, PNG, GIF oder SQLITE in einem zusätzlichen Repository namens extlibs.

Gleichzeitig führen einige Bibliotheken eine Vielzahl von Einstellungen mit sich, die ich nicht benötige. Hier kann ein angepasstes und verschlanktes Buildsystem die Nutzung erheblich verbessern.

Notwendige Anpassungen

OpenSSL nutzt heute die moderne BCRYPT API unter Windows um Zufallszahlen zu erzeugen. Damit läuft ganz OpenSSL erst ab Windows Vista. Mit der Abänderung von genauer einer Funktion auf die frühere OpenSSL Implementierung mit WinCrypt läuft OpenSSL auch auf Windows 9X und NT 4.
_s und _r sind tolle neue Erweiterungen für bestehende POSIX Funktionen, die ältere Compiler und deren Standard-Libs nicht kennen. Hier hilft meist ein CMAKE Patch, der auf den alten Compilern ein Makro einspeist, welches ein
sprintf_s(buf, sz, fmt, ...) auf sprintf(buf, fmt, ...) umleitet.
Ein gmtime_r kann man aber auch in einer eigenen Funktion implementieren, die ein Mutex-geschütztes gmtime nutzt. Und eine solche Patch-Funktion wird dann einfach mitkompiliert.
Fehlende Platformen wie WINCE oder HAIKU landen gerne mal in einem #error Block. Meist braucht man nur an die #ifdef WIN32 ... #else Zeilen ein weiteres #ifdef anfügen und schon läuft die ganze Lib auf einer offiziell nicht unterstützten Plattform.
Unvollständige Spezialitäten wie Assembler-Support deaktiviere ich gerne im Ganzen. LZMA kommt mit jeder Menge #if Spielereien um auf schnellere Assemblermodule umzuleiten. Das funktioniert aber oft nicht korrekt, und so helfe ich gerne nach, dass immer der #else Block mit der generischen C Implementierung aktiv wird.
WINCE und UEFI Dummies für unbenutzte Features: Die ZLIB ist genial, aber warum sind dort direkte POSIX-Aufrufe für Dateien drinnen? WinCE hat das alles nicht implementiert, und obwohl ich keine Datei-basierte ZLIB Funktionen nutze, werden diese zum Requirement. Also muss ich Dummy-Funktionen für die exotischen Plattformen belegen, die einfach nur da sind, um nicht aufgerufen zu werden.

Es gibt sicher noch ein paar andere Spielereien, aber die genannten Punkte decken die meisten Änderungen ab, die ich bei externen Bibliotheken einfach brauche.

All das ist nun in den extlibs implementiert.

Fazit

Dass ein C++ Projekt seine externen Abhängigkeiten selbst mitführt, war viele Jahre “normal” … und ist heute der Grund warum C++ abgehängt wirkt, weil kein einheitliches Verwaltungssystem hierfür existierte.

Mit der Einführung von CONAN kann jedoch auch jedes C++ Projekt mit jedem Compiler und jedem erdenklichen Buildsystem darauf vertrauen, dass notwendige Sourcen heruntergeladen und passen kompiliert werden.

Und dennoch wird es besonders im C und C++ Bereich immer Nischen geben, die für exotische Aufgaben Anpassungen vornehmen müssen, die einer zentralen Paketverwaltung widersprechen.

Meine “historischen” Plattformen wären ein solchen Beispiel, doch in der Mikrokonroller-Welt lassen sich bestimmt auch ähnliche Nischen finden.

Migration zu Codeberg

2023-09-23T13:00:00+02:00

Es wird Zeit sich voll und ganz der Open Source Welt zu öffnen. Mein bisheriger Git Hoster Bitbucket ist ja ganz toll, aber gehört der Firma Atlassian. Und Github ist in fester Hand von Microsoft.

Alle sitzen in den USA und niemand weiß, wie die morgen so drauf sein werden.

Es ist beschlossen, ich übersiedle “code-technisch” nach Berlin, und zwar nach codeberg.org

Codeberg

Warum ich Codeberg super finde, hatte ich schon mal beschrieben. Jetzt geht es auch darum ein Zeichen zu setzen, und deshalb zahle ich gerne den jährlichen Mitgliedsbeitrag um diesen Dienst zusätzlich auch finanziell zu unterstützen.

Wenn wir der Jugend an den Schulen die Softwareentwicklung näher bringen, dann sollten wir das nicht im Schatten von Konzernen tun, die sich heute als kostenlose Freunde anbieten und morgen unsere Daten an “andere” verfüttern.

Und natürlich freue auch ich mich, wenn ich meinen Code an einer Stelle ablegen kann, die von der Community, also von Enthusiasten verwaltet wird, und nicht von profitgetriebenen Managern.

Kurz gesagt:

Codeberg rulez!

Migration

Das GATE Projekt besteht inzwischen aus mehrere Repositories:

In gate liegt C/C++ Framework
In opengate liegen die Quellen der Webseite(n)
Der gate-blog-classroom sammelt zusätzliche Sourcecodes für den Blog
cpp-build-env enthält die Docker Bauanleitungen
und dann gibt es noch ein paar private Spielereien für Arduino und Co.

Das gate Repository wird bei der Codeberg Migration wieder bei Null anfangen und keine History von Bitbucket übernehmen. Grund dafür ist meine Dummheit, da ich Binaries für GTK3 und EFI miteingecheckt habe, die das Repository nur unnötig aufblähen.

Doch die Blog- und Webquellen sind relativ frei von solchen Geschwüren, also macht es durchaus Sinn, deren History 1:1 zu übernehmen.

Wie das mit CI Funktionen und Buildservices aussieht, weiß ich noch nicht. Im Zweifelsfall läuft das eben bei mir zu Hause. Am wichtigsten ist mir das GIT-Repo selbst, alles andere ist optional.

Pages

Außerdem ist mir das “Pages” Feature ins Auge gefallen. Inhalte solcher Pages-Repos sollen direkt als statische Webseite per URL erreichbar sein.
Oh … das freut mich … und könnte zukünftig das Bauen des Blogs “optimieren”.

Schließlich brauche ich ja immer Monate, bis alles korrigiert und in einem Schwung neu hochgeladen ist. Aber so könnte ich auch die Entwürfe als “Voransicht” automatisiert generieren lassen.
Denn das war mir auf meinem Webspace mit FTP-Passwörtern immer viel zu heikel.

Na mal sehen, was daraus wird.

Fazit

Die nächsten Wochen werden ein Spaß.

Ohne einige Umstellungen in der Projektstruktur wird es wohl nicht gehen, aber früher oder später wird das ganze GATE Projekt auf Codeberg einsehbar sein.

Die ersten Vorbereitungen wurden gesetzt und ich bin total beeindruckt, dass Codeberg ein git-clone 3 mal schneller hinbekommt als ein gleich großes Bitbucket Projekt.

Defekte M2 SSD gerettet

2023-09-17T13:00:00+02:00

Alarmstufe Rot am Server!

Der reagiert einfach nicht mehr … bzw. nur noch seltsam langsam per Ping, aber das UI hängt nur noch.

Und Schuld war die verbaute M2 SSD.

Mein seit 2019 durchgehend zu Hause laufender Intel-Atom Server, hat mir bisher nie wirklich Probleme bereitet (OK, der Grafiktreiber schon …).
Gut, er war nicht schnell, aber was erwartet man von einem mit 13 Watt betriebenem System.

Ich hatte damals auch einige Billig-SSDs aus China bestellt und als Bootplatten verbaut. Bei den Daten setzte ich meist auf die teureren Markenprodukte aus dem lokalen Handel.

Zwar müssen meine Server nicht wirklich viele Daten herumschieben, aber im Laufe der Zeit sammelt sich vieles an und vor allem duplizieren sich oft Videos und Audiodateien in mehreren Verzeichnissen versehentlich, wenn ich mal nicht aufpasse.

Dennoch waren stets mindestens 50% der Laufwerke frei, manchmal auch mehr. Und dann passierte es …

Disketten waren schneller als volle SSD

Es war nicht das erste mal, dass sich eine “günstige” SSD seltsam langsam verhielt. In manchen Testsystemen konnte ich das schonmal beobachten, doch diese werden wieder geplättet und bei der Neuinstallation war wieder alles gut.

Nun hatte es meinen Active Directory Domain Controller getroffen und den wollte ich nicht grundlos wegwerfen.

Offenbar schaltete die SSD in einen extrem langsamen Zugriffsmodus und lieferte nur wenige Kilobytes pro Sekunde aus. Das war früher mal verkraftbar, ist aber auf einem heutigen Windows untragbar, weil da permanent etwas gelesen oder geschrieben wird und sich das System so selbst blockiert.

Ich kaufte sofort ein Ersatzsystem und eine Ersatzplatte, wollte aber das Original Byte für Byte kopieren, damit das neue System mit dem bestehenden AD-Stand hochfahren konnte.

W-T-F! Mehr als 24 Stunden!

Ich konnte die beiden SSDs (512 GB) zwar problemlos in meinem Rechner starten und die Sektor-Direktkopie starten, aber die Lesegeschwindigkeit fiel immer wieder dramatisch ab und so dauerte die Aktion über das Wochenende.
Die Hoffnung, ich könnte schnell Auslesen, nur das Schreiben wäre langsam gewesen, erfüllte sich nicht.

Am Ende ging aber dennoch alles gut und ich hatte keine Daten verloren, doch so wirklich sicher war ich mir da anfangs nicht.
Zwar waren auch meine Backups mitgelaufen, doch auch hier fand ich heraus, dass Backupversuche einige Tage vorher immer wieder fehlgeschlagen waren. Mit einem Restore wäre zwar auch nicht viel verloren gewesen … aber man weiß ja nie, ob das Backup dann korrekt war.

Fazit

Billige SSDs speichern 2, 3 oder mehrere Bits in einer Zelle. Damit ist alles superschnell, wenn nur kleine Teile des Mediums ausgefüllt sind.
Irgendwann findet dann aber das große Umspeichern statt und ich glaube, dass ich in so eine Aktion hineingeraten bin, die alles schlimmer gemacht hat.

Zwar gingen keine Daten verloren, so weit ich weiß … doch womöglich stand ich kurz davor.

Das erinnert mich dann wieder an das Big-Box-Mart Video, in dem es am Ende heißt:

Your every-day low prices have a price, they are not free.

Und das gilt bei SSDs eben auch. Denn meine Markenprodukte haben so ein Verhalten noch nicht gezeigt, obwohl sie viel stärker beschrieben werden. (Und hoffentlich tun sie das auch nicht.)

Docker Windows abgeschaltet

2023-09-16T13:00:00+02:00

Ich wollte einfach nur einen Windows Build Server mit Docker neu aufsetzen. Doch Microsoft hat ihren offiziellen MsftDockerProvider vom Netz genommen.

An dieser Stelle war man Aufschrei in ganz Wien zu hören. Zum Glück ist die Alternative das Moby Projekt, welches Docker für Windows Server weiter unterstützt.

Bisherige Installation von Docker

Bisher wurde Docker auf Windows Servern mit

1Install-Module -Name DockerMsftProvider -Repository PSGallery -Force
2Install-Package -Name docker -ProviderName DockerMsftProvider

eingerichtet. Die Prozedur lud die entsprechenden Pakete aus dem Netz und installierte den Docker Dienst im Windows System. Doch nun sehen wir Fehler wie:

 1WARNING: MSG:UnableToDownload https://go.microsoft.com/fwlink/?LinkID=627338&clcid=0x409  
 2WARNING: Unable to download the list of available providers. Check your internet connection.  
 3WARNING: Cannot find path  
 4'C:\Users\ADMINI~1\AppData\Local\Temp\2\DockerMsftProvider\DockerDefault_DockerSearchIndex.json' 
 5because it does not exist.
 6WARNING: Cannot bind argument to parameter 'downloadURL' because it is an empty string.
 7WARNING: The property 'AbsoluteUri' cannot be found on this object. Verify that the property exists.
 8WARNING: The property 'RequestMessage' cannot be found on this object. Verify that the property exists.
 9Install-Package : No match was found for the specified search criteria and package name 'docker'. 
10Try Get-PackageSource to see all available registered package sources.

Früher lag offenbar unter https://dockermsft.azureedge.net/dockercontainer/DockerMsftIndex.json die notwendige Information, wo die Daten heruntergeladen werden konnte, doch das ist nun abgeschaltet, wie man auf GitHub von MicrosoftDockerProvider nachlesen kann.

Das bedeutet: Ab sofort kann man Docker Enterprise für Windows Server nicht mehr regulär installieren.

Alternative: Das Moby Projekt

Wer Enterprise-Support braucht, kann die Mirantis Container Runtime nutzen … und darf dafür auch extra zahlen.

Und wer einfach nur seine Buildumgebung wieder zum Laufen bekommen will, kann das OpenSource Projekt Moby nutzen, welches die Docker Dienste ohne den Unternehmens-Support zum Download zur Verfügung stellt.

Man hat dann zwar nur eine AS IS Software ohne Garantien, kann sich aber die Quellen sichern und im Notfall den Dienst auch selbst bauen.

Die Sourcen und Releases liegen auf github.com/moby/moby

Installation der Moby Docker Container Runtime

Nachdem das Windows Container Feature aktiviert ist, lädt man sich am einfachsten ein Installationsscript für die Powershell herunter, das die aktuellen Binärdateien herunterlädt und in C:\Windows\System32\ installiert.

1(new-object System.Net.WebClient).DownloadFile("https://raw.githubusercontent.com/microsoft/Windows-Containers/Main/helpful_tools/Install-DockerCE/install-docker-ce.ps1", "install-docker-ce.ps1")
2.\install-docker-ce.ps1

Sonderfall Windows Server 2016

Die aktuellen Moby Builds funktionieren erst ab Server 2019. Unter älteren Windows Version verweigert der aktuelle dockerd.exe seinen Dienst.

Man kann sich allerdings auch unter download.docker.com/win/static/stable/x86_64/ eine ältere Version der Runtime herunterladen, z.B.: v20.10.24. Danach muss man die beiden Programme docker.exe und dockerd.exe aus der ZIP Datei einfach nach C:\Windows\System32 kopieren und hat danach auch unter Server 2016 wieder einen funktionalen Docker Dienst.

Fazit

Pfui Microsoft! Das konntet ihr schon mal besser!

Wenn ich an Windows eines geschätzt habe, dann war das seine zuverlässige Kompatibilität und der lange Support von Software. Selbst heute erhalte ich noch über WSUS alle Windows XP und Windows 2000 Updates, was für Industriemaschinen immer noch notwendig sein kann.

Dass gerade Docker einfach mal so abgedreht wird, ist nicht akzeptabel. Man hätte die alten Binaries liegen lassen können und nur für Neuinstallationen auf die Alternativen verweisen können.

Wenn gleich das Moby Projekt sicher toll ist, so ist der mit dem Server mitgekaufte Enterprise-Support plötzlich weg … und was passiert jetzt, wenn ein Kunde hierfür ein Anliegen hat?
Dann wird es unerwartet teuer.

Ich überlege jetzt trotzdem, ob ich nicht meine laufenden Windows Server mit der “alten” Docker Installation jetzt dupliziere und per SysPrep für spätere Neuinstallationen konserviere.

In jedem Fall kostet mich dieser Umstand jetzt sowohl in der Firma wie auch privat jede Menge wertvolle Zeit.

STAR64: ein RISC-V von PINE64

2023-09-09T13:00:00+02:00

Ein neuer Stern ist am Himmel erschienen. Mit dem STAR64 habe ich nun ein Raspberry-PI 4 ähnliches RISC-V System in meine Familie aufgenommen und freue mich, dass diese CPU Architektur langsam im Endanwendermarkt angekommen ist.

Vor 20 Jahren war es für mich unvorstellbar, dass es noch etwas anderes als X86 PCs zum digitalen Arbeiten geben kann. Exotische Taschenrechner und wenige PDAs mal ausgenommen.

Vor 10 Jahren sah ich, dass ARM Geräte den klassischen X86 PC langsam verdrängten.

Und heute sehe ich, dass mit RISC-V auch ARM einen wachsenden Konkurrenten bekommt.

STAR64 Hardware

Das Star64 Model-A baut auf einer 64-bit RISC-V Quad-Core CPU auf, die es auf 1.5 GHz bringen kann. Ich habe mir das Modell mit 8 GB RAM gegönnt. Bestromt wird das 13x8 cm Board offiziell mit einem 12 V Netzteil über einen üblichen Hohlstecker, wie er auch bei einigen ITX Mainboards zur Anwendung kommt.

Ein solches 12 V Netzteil hatte ich ohnehin zu Hause und musste daher keines mitbestellen. Die geforderten 3.5 Ampere würden somit 45 Watt ergeben. Doch selbst bei CPU Volllast beim Kompilieren, kam das Gerät bei meiner Messung nicht über 8 bis 9 Watt hinaus … also ein echter Stromsparer. Ich habe allerdings auch keine Erweiterungskarten angeschlossen oder USB belastet … von daher sind die 8 Watt also dennoch eine untere Grenze.

WLAN, 2x LAN, HDMI, 3x USB2, 1x USB3 sind vorhanden, allerdings an gegenüberliegenden Enden verbaut.

Für einen Desktop mit “Hinten-Strom” und “Vorne-USB” passt das gut, bei meiner Verkabelung am KVM-Switch war es etwas ungünstig. Cool wäre gewesen, wenn es neben HDMI und LAN Buchse noch einmal USB für Tastatur und Maus gegeben hätte.

Software

Das System kann entweder von SD-Karte oder eMMC Karte booten, was man über kleine Schalter konfigurieren kann:

Ich kopierte ein fertiges Desktop-Linuximage basierend auf dem Yocto Projekt einfach auf eine SD-Karte und schon konnte das Gerät starten.

Ein Armbian Image hätte ich auch ausprobieren wollen, doch dieses wurde nicht erkannt. Nach Anschluss eines seriellen Adapters an den Pins 6, 8 und 10 konnte ich eine Fehlermeldung am COM-Port abfangen.

Was man ebenso am COM-Port bei einem erfolgreichen Boot sehen kann, ist:

 1U-Boot 2021.10 (Jun 05 2023 - 16:23:55 +0000)05062023
 2
 3CPU:   rv64imacu_zba_zbb
 4Model: Pine64 Star64
 5DRAM:  Not a StarFive EEPROM data format - magic error
 64 GiB
 7MMC:   sdio0@16010000: 0, sdio1@16020000: 1
 8Loading Environment from SPIFlash... SF: Detected gd25lq128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB
 9*** Warning - bad CRC, using default environment
10
11Not a StarFive EEPROM data format - magic error

Da wurde also einiges vom StarFive Modell übernommen. Ärgerlich ist dabei allerdings, dass mein 8GB Modell nur mit 4 GB angesprochen wird … und das ändert sich auch später nach dem Laden des Linux Kernels nicht mehr.

Ich vermute mal, ich muss irgendwann den Bootloader ersetzen, damit die vollen 8 GB nutzbar werden … aber vorläufig werde ich damit leben können.

Beim ersten Start wird die Partition auf die gesamte Größe der SD Karte ausgeweitet und dann nochmal neu gestartet.

Am Ende landete ich in einer KDE-Login Maske, die mich mit Benutzer- und Passworteingabe (beide lautend auf pine64) zum üblichen Linux Desktop weiterleitete.

Von dort konnte ich grafisch meinen WLAN-Router einbuchen und schon war das Gerät im Netz. Dort wurden dann zahlreiche Updates nachgeladen und nach einem finalen Reboot war mein STAR64 voll nutzbar.

Performance und Stabilität

Dass ein RISC-V System aktuelle ARM Kerne nicht überholen wird, war mir im Vorfeld klar. Am besten vergleichbar war die Performance mit einem Raspberry-PI 4. Dieser mag vielleicht beim booten etwas schneller sein, doch wenn ich einen Kompiliervorgang startete, dann war die Fortschrittsgeschwindigkeit gefühlt sehr nahe am RPI-4.

Für mich also absolut OK für die Softwareentwicklung.

Die Nutzung des Internet ist … wie auch beim PI … etwas schwierig. Mein Blog lädt natürlich super schnell, doch alleine der Login bei diversen Diensten wie outlook.com oder Bitbucket, sind auf dem STAR64 ähnlich träge wie auch auf dem RPI4. Zwar tauchen die Seitenteile am Ende meist immer auf, aber die Wartezeiten erinnern dann leider doch wieder an die Telefonmodem-Zeiten der späten 90er.

Ein Problem hatte ich konkret mit dem HDMI Anschluss beim Umschalten des KVM-Switches. Eine verlorene Verbindung zum Monitor wird später nicht wiederhergestellt, wenn man zum Gerät zurückschaltet.
Ich musste also per serieller Konsole ein reboot Kommando absetzen, um dann wieder ein schönes Monitorbild zu bekommen.
Tja … so ist das mit brandneuer Hardware. Doch auch hier werden die Patches - so hoffe ich - nicht all zu lange auf sich warten lassen.

Fazit

Ich liebe meinen STAR64 trotz seiner kleinen Fehler, denn mein erster Kontakt mit dem Lichee RV Allwinner D1 war zwar super aus technischer Sicht, doch für die täglich Arbeit tauglich war dieses Gerät nicht.

Der STAR64 kommt da schon eher in Frage und ich gehe davon aus, dass die nächsten RISC-V Varianten noch näher an die ARM-Leistungen herankommen werden.

Und so können wir heute live miterleben, wie die nächste CPU Architektur ihren Platz in der Welt bekommt.

Ich denke nun jedenfalls darüber nach, einen RISC-V Linux Build aller meiner GATE Tools per Cross-Compiling ausgeben zu lassen, denn bald wird das ebenso notwendig sein, so wie wir heute X86, X86_64, ARM und ARM64 Builds von allem Programmen anlegen.

WINGET unter Windows IOT

2023-09-03T13:00:00+02:00

Mit dem kommenden “Aus” für Windows 10 im Jahr 2025, frage ich mich, wie lange ich dieses Plattform weiter nutzen wollen werde.

Windows 10 IOT erhält noch bis 2030 Support, also werde ich wohl darauf wechseln … doch dort fehlt jede Menge Software.

Hinweis: Windows-10-IOT kann man nicht im nächsten Laden kaufen, sondern erhält es durch ein MSDN-ABO oder andere Lizenzvereinbarungen für Unternehmen.

Meine Laptops von 2014 und 2016 laufen noch brav, sind aber nicht Windows 11 tauglich (und würden wohl auch ziemlich lahm damit starten.)

Meine Windows 10 IOT Alternative ist für die Softwareentwicklung super. Win10-IOT unterstützt Win32/64 vollständig und damit auch jede Entwicklungsumgebung.

Was dem Teil aber fehlt ist der Windows Store und auch sonst alle Standard-Apps wie Mail und Kalender, auf die ich nicht verzichten will.

Natürlich kann man die Pakete manuell aus dem Netz extrahieren und nachinstallieren, aber sehr benutzerfreundlich ist das nicht.

Wie cool wäre es, wenn winget verfügbar wäre, das alles einfach nachinstallieren kann?

Doch leider fehlt winget ebenfalls.

winget Installation unter Windows 10 IOT

Zu meiner großen Freude hat Microsoft inzwischen eine Anleitung online gestellt, wie man den modernen App-Installer auf Win10 IOT einrichten kann.

Man holt sich von github.com das neueste .msixbundle und die License .xml Datei
Dann lädt man sich die VCLibs auf die Platte
Und muss noch Microsoft.UI.Xaml.nupkg aus dem Netz gesogen werden.
nupkg ist in Wahrheit eine .zip Datei, und aus dieser muss man sich die Datei Microsoft.UI.XAML.2.7.appx herausziehen.
Jetzt öffnet man die Powershell und führt aus:
- Add-AppxPackage -Path <path to VCLibs .appx file>
- Add-AppxPackage -Path
- Add-AppxPackage -Path <path to .msixbundle file>
- Add-AppxProvisionedPackage -Online -PackagePath <path to .msixbundle file> -LicensePath

Nun ist winget unter %LOCALAPPDATA%\Microsoft\WindowsApps verlinkt und kann zur Installation weiterer Software genutzt werden.

Windows Store Apps per `winget` installieren.

Ein winget search something lässt einen recht schnell auch die üblichen Apps wie Mail oder News finden. Installieren kann man die Apps dann über winget install --id appid. Die Microsoft Apps sind oft nur über ihre kryptischen Hash-IDs erreichbar.

Meine üblichen Verdächtigen sind:

Mail: winget install --id 9WZDNCRFHVQM
Kamera-App: winget install --id 9WZDNCRFJBBG
OneDrive: winget install --id Microsoft.OneDrive
News: winget install --id 9WZDNCRFHVFW
Wetter-App: winget install --id 9WZDNCRFJ3Q2
Movies-und-TV-App: winget install --id 9WZDNCRFJ3P2

Und als Entwickler brauch man dann noch mindestens:

winget install --id "Notepad++.Notepad++"
winget install --id Git.Git
winget install --id Kitware.Cmake
winget install --id Microsoft.VisualStudioCode

Fazit

winget ist und bleibt die sinnvollste Erfindung der letzten 5 Jahre. Und immer noch verstehe ich nicht, warum das so lange gedauert hat, dieses Tool bereitzustellen.

Mit der Installationsprozedur kann man jedenfalls sein profanes Windows IOT in eine lebendige Umgebung verwandeln, die dem üblichen Benutzer-Windows um nichts nachsteht … nur dass es eben 5 Jahre länger supportet wird.

Nochmal ein EOS Update

2023-09-02T13:00:00+02:00

Aus gegebenem Anlass habe ich nochmal mein Sony Xperia mit dem neuesten /e/OS Betriebssystem aktualisiert.

Ich hatte es vor einem Jahr aufgesetzt und dachte, die Prozedur würde sich leicht wiederholen lassen.
Naja … nicht ganz.

Da wir für Android Updates einen Treiber benötigen und dies älteren davon leider nicht immer offiziell auffindbar sind oder nicht signiert sind, ist der übelste Teil Windows dazu zu bekommen, die INF-Treiber zu akzeptieren, damit die Android-Tools auch mit dem Zielgerät kommunizieren können.

Ich verzichte ja nach Möglichkeit auf den Secure-Boot für Windows, doch da dieser Standard ist, sollte dieser zuerst mal im BIOS Setup ausgeschaltet werden. Auf Test-Laptops brachte ich die Treiber nämlich mit aktiviertem Secure-Boot nie zum Laufen.

Danach kann man mit dem Aufruf von

1bcdedit /set testsigning on

als Administrator ab dem nächsten Boot das Laden von nicht-signierten Treibern gestatten. Alternativ lässt sich das auch in den Einstellungen unter Wiederherstellen und Erweiterter Start aktivieren.

Meine alten Links zur Sony Seite funktionieren leider inzwischen nicht mehr. Ich konnte aber im Netz ein paar andere Varianten aufspüren, eine davon lag unter xperiausbdriver.com/sony-xperia-xa2-h3113.
Mit etwas Glück sollte sich dieser Treiber dann installieren lassen, wenn das Smartphone per USB verbunden ist, neu startet und die Tasten + und Power gleichzeitig drückt werden.

Ist das Rufzeichen oder Fragezeichen im Geräte-Manager neben dem Android ADB Gerät verschwunden, kann man (hoffentlich) problemlos das Update durchführen.

Inzwischen können die Android-Tools auch leicht per winget installiert werden, allerdings funktionieren sie nur, wenn man sie im Installationsverzeichnis ausführt:

1winget install Google.PlatformTools
2cd C:\Users\%USERNAME%\AppData\Local\Microsoft\WinGet\Packages\Google.PlatformTools_Microsoft.Winget.Source_8wekyb3d8bbwe\platform-tools

Nun konnte ich das von der /e/os Seite geholte Image auf das Smartphone aufspielen. Und nach einem erfolgreich ausgeführtem adb sideload ... und dem Abwarten der Installationsprozedur, startete am Ende mein Xperia problemlos mit der neuesten Version von /e/os.

Fazit

Das tolle am aktuellen Stand ist, dass /e/os sich nun offenbar besser selbst “on-the-fly” aktualisieren lässt. Weitere manuelle adb Einsätze sollten damit nicht mehr notwendig sein … hoffe ich.

Doch es zeigt sich, dass die Setup Prozedur wegen verschwindender Treiber und immer wieder neueren Sicherheits-Spielereien in Windows einfach nur mühsam ist.
Hier heißt es dann:

Durchhalten und erneut probieren.

Irgendwann findet man schon die richtige Treiber- und Setup-Konstellation, die erfolgreich durchläuft.

Und zum Glück konnten alle meine gescheiterten Image-Installation immer wieder per Neustart des Smartphones von Vorne begonnen werden.

Python-Gitlab

2023-08-27T13:00:00+02:00

Build- und Softwaresysteme wie Gitlab lassen sich durch beliebig viel Geld um beliebig viele Features erweitern.
Und dann sitzt man lange vor dem “Super-duper-Plugin” und weiß erst recht wieder nicht, wie man das bekommt, was man haben möchte.

“Selber machen” ist dann immer die beste Lösung.

Ich bin durch meine Firma mit Gitlab gesegnet und nutze es daher fast täglich.

Neben Quellcode- und Buildagent-Verwaltung existieren rudimentäre Auswertungen für Testfälle und andere Statistiken, die jedoch für jedes Projekt einzeln ermittelt und auch nur separat angezeigt werden können.

Oft sind aber projektübergreifende Details interessant und hier muss man je nach Anwendungsfall entweder zu externen Plugins greifen, oder Auswertungsjobs von kompletten Fremdsystemen durchführen lassen.

Was oft übersehen wird ist:

Gitlab hat für fast alles eine REST oder zumindest RESTartige Webschnittstelle.

Alles, was das Web-UI anzeigt, kann auch separat als JSON Datensatz heruntergeladen werden. Und wenn die Daten schon als JSON da sind, kann man sie in weiteren Scriptsprachen wie etwa Python relativ leicht kombinieren, auswerten oder in andere Formate übertragen.

python-gitlab ist ein Modul, welches die HTTP-Webrequests in einfache Python Objekte verpackt, die ziemlich selbsterklärend benutzt werden können.

Auf zum Script!

Man braucht zuerst mal einen Access-Token zu den Projekten, den man sich im Gitlab WebUI unter seinem Benutzerprofil anlegen kann. Dort wird festgelegt, ob der Token nur Leserechte hat, oder auch etwas verändern darf.

Dann installiert man sich das python-gitlab Modul per pip:

1pip install python-gitlab

und kann mit dem Scripten anfangen.

Ich nutze fixe Gruppen in Gitlab, in denen meine Projekte liegen. Da sich die nie ändern, kann man sie einfach über ihre IDs ansprechen. Die IDs von Gruppen oder Projekten findet man auch in der Gitlab Web-UI im Untertitel, wenn man eine Gruppe oder Projekt öffnet.

1import gitlab 
2
3gl = gitlab.Gitlab(url='https://my.gitlab.server', private_token='abcdefg')
4mygroup = gl.groups.get(12345)
5myprojects = mygroup.projects.list()
6for entry in myprojects:
7  print("ID#{} {}: {}".format(entry.id, entry.name, entry.http_url_to_repo))

Und schon finde ich eine Liste aller Projekte in meiner Gruppe vor. Mit dem http_url_to_repo Feld könnte man sich jetzt gleich ein git clone basteln, das alle Projekte lokal herunterlädt.

Spannender wird es dann aber, wenn man auf die Pipelines der Projekte zugreift und dort den Status der Ausführung ausliest, und die Statistik der JUnit Tests erhält.
Denn so kann man sich als Entwickler mit wenigen Zeilen einen Übersichtsmonitor bauen, der anzeigt, was gerade gut und eher schlecht gelaufen ist und Nacharbeitung benötigt.

Fazit

Mit der Gitlab-Web-API kann man die Buildumgebung automatisieren, überwachen und auswerten lassen.
Zwar langweilen mich solche Scriptereien im Job oft, aber ich habe es zu schätzen gelernt, wie man sich seinen Alltag mit ein paar Zeilen vereinfachen kann.

Das Arbeiten mit Buildsystem gehört heute vor allem in Großprojekten zum Standard, und die Zeiten, wo der Entwickler-Rechner auch gleich die Releases erzeugte sind (leider) lange vorbei.

Folglich sollte “Buildserver-Scripting” in jeder Schule unterrichtet werden, denn wer weiß … bald braucht jeder Handwerker einen Buildserver um seine Maschinen auf den neuesten Stand zu bekommen.

std::unique_ptr

2023-08-26T13:00:00+02:00

Als ich neulich freudig folgendes vor Kollegen verkündete:

Wir können problemlos native Pointer mit unique_ptr ersetzen, da das Layout der Objekte gleich ist.

wurde dagegen argumentiert.
Grund genug, das nochmal aufzurollen.

Memory-Leaks fühlen sich besonders dort wohl, wo RAII nicht angewendet wird. Genau das geschieht auch in Projekten, die ich mitbetreuen darf.

Jetzt herrscht dort leider die Meinung, dass alle erkannten Memory-Leaks nur einmalige Allokierungen sind, weil vieles aus globalen Singletons hervorgeht.

Das stimmt streng genommen auch, und man kann globale Variablen gerne formal ausnehmen … doch Leak-Detektoren tun das nicht von selbst.
Und wenn man dann zahlreiche Unit-Tests ausführt, die alle unzählige Leaks aus solchen Singletons melden, bringt die Erkennung genau gar nichts, weil sie keiner mehr ernst nimmt.

Die Devise sollte also lauten:

Wir beheben diese Leaks so gut wie möglich, damit wir im Bericht am Ende die relevanten Leaks angezeigt bekommen, die wir weiterverfolgen sollen.

Tja und tatsächlich hilft einem da ein Smart-Pointer, der am Prozessende automatisch zerstört wird. std::unique_ptr ist ein perfekter Kandidat solche nativen Pointer zu ersetzen und das Cleanup so dem Compiler zu überlassen.

Spätestens hier meldet sich dann das Deployment Team und fragt, ob eine solche Codeänderung die Binärkompatibilität bricht und ob Patches dann noch möglich sind.

auto_ptr vs unique_ptr

Ein std::auto_ptr besteht genau aus einem Member, nämlich aus dem Pointer zum verwalteten Objekt. Und seine reset() und Destruktorfunktionen führen ein delete auf eben diesen Pointer aus.
Das bedeutet eine int* Variable und ein auto_ptr<int> haben in der Regel das gleiche Speicherlayout.

Diese Behauptung wird zwar nicht durch den Standard gedeckt, aber auf allen unseren üblichen Plattformen ist das durch die Compiler de facto garantiert.

Man kann also durchaus eine .dll oder .so patchen, die original ein Objekt mit einem T* definiert, welches durch einen auto_ptr<T> ersetzt wird. Die Datengröße und das Layout bleiben gleich, nur Codes führen jetzt ein automatisches Cleanup durch.

Bei std::unique_ptr hatte ich anfangs meine Zweifel, ob man hier auch so vorgehen kann. Schließlich bietet unique_ptr an, eine Freigabefunktion dem Objekt beizulegen, die das referenzierte Objekt zerstören können soll. Das ist im Normalfall dann auch wieder ein delete ptr, kann aber durch etwas anderes abgewandelt werden.

Meine Befürchtung war, dass weitere Funktionszeiger in unique_ptr integriert werden und womit das unique_ptr Objekt dann mehr als nur den zu verwaltenden Pointer mitführt.

Compressed Pair

Wie so oft hat Raymond Chen bereits die Lösung publiziert und beschreibt die MSVC Lösung, die auch in anderen STL-Implementierungen angewendet wird:

Der Deleter-Funktor (dessen Default Typ einfach std::default_delete heißt) wird nicht als Member dem unique_ptr angehängt, sonder unique_ptr erbt von diesem Typ. Und so lange dieser Typ selbst keine Datenmember besitzt (was bei std::default_delete der Fall ist), wächst unique_ptr nicht, sondern definiert seine Größe nur nach dem bekannten Pointer zum Objekt.

Beim MSVC gibt es dafür den Typ compressed_pair<K, V> welcher von K erbt und nur V als echten Value-member anhängt.

Konstruktion von Objekten

Die Größen von Klassen und ihren Unterobjekten sind essentiell für das Erzeugen und den Zugriff auf instanziierte Objekte. Wenn also ein Typ in einem Modul (DLL/SO) eingesetzt wird und ich dessen Code neu kompilieren und ausrollen möchte, darf sich das Objektlayout um kein einziges Bit ändern, denn sonst stimmt es mit früheren Kompilaten nicht mehr überein. Code hingegen wird über Namenstabellen beim dynamischen Einbinden neu aufgelöst.

Um also eine Plugin-SO/DLL gefahrlos patchen zu können, muss sichergestellt sein, dass alle Datenstrukturen exakt gleich groß sind und mit identischen Offsets herauskommen.

Und eben genau das ist bei std::unique_ptr dann der Fall, wenn man die Default-Implementierung nutzt.

Beispiel

 1class my_worker_impl;
 2
 3class my_worker
 4{
 5public:
 6  my_worker()
 7  : ptr(new my_worker_impl())
 8  {
 9  }
10
11private:
12  //my_worker_impl* ptr;
13  // PATCH: replace raw ptr with unique_ptr
14  std::unique_ptr<my_worker_impl> ptr;
15};
16
17my_worker singleton_instance;

Durch die Änderung bleiben die Daten exakt an der gleichen Stelle, doch unique_ptr generiert automatisch einen Destruktor-Aufruf, der am Ende des Prozesses das allokierte Objekt wieder freigibt.

Und wenn my_worker jetzt ein Member in einem anderen Objekt sein sollte, das in einem Modul liegt, welches mit dem alten Header kompiliert wurde, so ist ein binärkompatibler Patch ebenso möglich.

Fazit

Man muss natürlich klar darauf hinweisen, dass Binärkompatibilität nicht durch Standards gedeckt wird. Eigentlich handelt es sich hierbei um “undefinied behavior”. Das bedeutet aber nicht, dass auf bestimmten Plattformen das Verhalten dann trotzdem vom Hersteller garantiert ist.

Der Wechsel von raw-Pointern zu unique_ptr wäre also so ein Fall, der unter Windows und Linux durchführbar ist und die Codequalität erhöht, ohne dass man manuell neue Destruktoren oder Ähnliches schreiben müsste.

IBM PS/2 30 Floppy Adapter

2023-08-19T13:00:00+02:00

Bei meinem PS/2 30 sind die originalen Diskettenlaufwerke eingegangen und leider passen neue Floppy-Drives nicht mit den alten Anschlüssen zusammen.

Doch zum Glück bietet die Firma texELEC einen Adapter an, der übliche PC-Diskettenlaufwerke mit dem alten IBM PS/2 verheiraten kann.

Disketten und ihre Laufwerke sind eine kritische Sache. Sie werden etwa seit dem Jahr 2000 nicht mehr produziert, und das heißt, alle Medien und Geräte, die es aktuell gibt, sind die letzten.
Im Falle meines IBM PS/2 aus dem Jahre 1987 sprechen wir von 35 Jahre alter Hardware und der Tod der “beweglichen” Teile ist da ganz natürlich.

Vermutlich könnte man die Laufwerke noch reparieren, wenn nur ein Gummiriemen defekt ist. Bei einem kaputtem Motor, wird es schon komplizierter.

Doch aus den späten 90ern liegen bei mir noch einige handelsübliche 3.5 Zoll Laufwerke herum, warum also nicht diese nutzen?

Die üblichen 34-PIN Flachbandkabel passen jedoch nicht zu den alten Steckanschlüssen des IBM PS/2 M30

Ein Adapter für neue Laufwerke

Und dann fand ich zufällig ein Produkt, das eine Brücke zwischen den Laufwerken der 90er und der 80er Jahre bauen kann:
Den IBM PS/2 to Standard Floppy adapter

Bestellung, Zahlung und Versand funktionierten unkompliziert und schon bald erreicht mich die Sendung mit der begehrten Hardware.

Ich verbaute diese im Gerät und schloss es auf Position von Laufwerk A: an, legte eine alte 720 KB (Double-Density) DOS-Diskette ein und startete das System.

Ich war beeindruckt, als ich am Lesegeräusch des Laufwerks das Laden des Betriebssystem feststellen konnte. Parallel zeigte der Monitor die ersten DOS Zeilen an.

Fazit

Es ist geschafft!

Im Jahr 2023 darf das Gerät das erst Mal seit über 20 Jahren wieder ein Betriebssystem starten, denn seit damals konnte ich das Gerät mangels funktionierender Laufwerke nicht mehr starten.

Ich erinnere mich, dass auch MS-DOS 6.22 auf dem 8088 Prozessor erfolgreich lief. Als nächstes brauche ich also ein größeres Speichermedium als eine 3.5 Diskette.
… mal sehen ob sich da was auftreiben lässt.

Das Ende der '.sln'

2023-08-13T13:00:00+02:00

Seit meinen ersten Entwicklungs-Experimenten in Visual Basic sind sie fix dabei: Die Verwaltungsdateien von Visual Studio. Sie fassen die eigentlichen Source-Code-Dateien zusammen und heißen “Projekte” im Einzelfall (.vcproj, .vcxproj) oder “Solution” (.sln) als Sammlungen.

Jetzt ist Schluss damit. Ab jetzt kümmert sich ausschließlich CMake um diese Details.

Die Geschichte eines Fehlers

Da ich mit Windows aufgewachsen bin, habe ich das “grafische” Hinzufügen und Entfernen von Quellcodes zu einem “Projekt” immer als die beste und stabilste Form angesehen.
Ein neues Projekt wurde damit immer in der IDE erstellt und dann vollständig in das Versionsverwaltungssystem eingespielt.

Und früher war das auch überlegen, denn ein Visual Studio 2005 Solution funktionierte bei rein nativem Code überall ohne Kunstgriffe.

Bei Linux hingegen funktionierte alles grundsätzlich nur auf dem Originalsystem. Wer also unter SUSE gegen 3 Bibliotheken per Makefile linkte konnte nicht wissen, ob die unter Ubuntu auch so heißen und durfte dann das Buildscript anpassen, oder lange aus-if-en, wie die Komponenten heißen.

Und um das “grafisch” besser kontrollieren zu können, nutzte ich lange Zeit Code::Blocks um auch Linux solche Projektdateien aufzuzwingen.

Ich generierte also “irgendwie” für jede Bibliothek ein Visual Studio und ein Code::Blocks Projekt und verwaltete diese dann für unterschiedlichen Plattformen.

Unter Linux war das … naja … immer schon blöd, es funktionierte aber unter Windows super, bis mit Studio 2012 neue Plattformtypen hinzukamen, die man nicht mehr in einer Solution unterbringen konnte.

Windows Phone und die Universal Windows Plattform brauchten eigene Solutions für sich, und so erzeugte ich eine Win32-Solution, eine UWP-Solution und später dann mit VS 2017 eine Android-Solution um immer die gleichen Sourcen zu einem Projekt zusammenzubinden.

CMake löst heute alles

Ich kann es heute ja immer noch nicht nachvollziehen, warum ich CMake so lange verweigert hatte. Grund dafür waren “komplizierte” Querschläger wie OpenSSL, die zwar für Win32 und Linux toll waren, bei WinCE oder UWP aber versagten. Doch das hätte ich auch damals schon angehen können.

Inzwischen hat CMake viele Tricks drauf um wirklich alle meine Wünsche zu erfüllen und daher habe ich nun auch im GATE Projekt mit der Entfernung aller Solution- und Projekt-Dateien begonnen.
Es ist heute auch gar nicht mehr möglich die Buildkonfiguration hart festzulegen, denn jede Studio-Installation kommt mit einem anderen SDK und mit jedem Update ändert sich dann auch noch der Minimum-Support der Zielplattform. Man müsste also in jedem Studio mit der Hin- und Herkonvertierung starten und das ist erst recht wieder Fehleranfällig.

CMake erkennt brav, was auf dem System vorhanden ist und erzeugt die Solutions und Projekte automatisch genau so, damit sie alles Vorhandene finden und nutzen.

Fazit

Good Bye SLN!

Es erzeugt in mir immer ein gewisses Retro-Feeling, wenn in einem Sourcepaket eine .sln Datei oder was Ähnliches drinnen ist. Besonders auf codeproject.com findet man noch viele solcher alten C++ Projekte.

Heute erwarte ich von jedem C/C++ Projekt, dass eine CMakeLists.txt Datei enthalten ist. Denn mit dieser lässt sich dann für wesentlich mehr Plattformen eine Buildprozedur einrichten.

Android mit CMake

2023-08-12T13:00:00+02:00

Mit der Migration zu Visual Studio 2022 gingen mir meine Android Builds verloren. Nun müssen diese neu erdacht werden.

Und eben dafür soll mir nun CMake aus der Patsche helfen.

Als ich das GATE Projekt mit dem Studio 2017 damals startete, legte ich auch eine parallel Solution für Android an, um mit den Standard-Toolkits, die beim Studio dabei waren, Android Apps bauen zu können.

Das funktionierte zwar recht gut, doch so musste ich jede neue Codedatei von Hand in mehrere Solutionzweige aufnehmen und diverse Build-Flags immer doppelt und dreifach warten.

Folglich soll auch diese Konfiguration von CMake übernommen werden:

1cmake -DCMAKE_SYSTEM_NAME=Android -A x64 path_to_src

reicht bei einem heutigen CMake aus, um Visual Studio automatisch zu finden und dort dessen installierte Android Features zu aktivieren.
Das Ergebnis ist eine generierte Visual Studio Solution (.sln), deren Projekte gegen das “Standard” Android NDK kompiliert und linkt.

Fehlende Paketierung

Während also meine Binärdateien schon brav generiert werden können, fehlt leider ein entscheidendes Detail: Das APK Paket.

Im alten VS 2017 wurde das vom Projekt-Template miterzeugt und baute ein APK Paket mit dem NativeActivity Modul aus der C++ Buildtoolchain.
So konnte man die neue App auch gleich im Emulator testen und sogar debuggen.

Noch weiß ich nicht, wie man das in CMake erzeugen lassen kann, also wird das wohl meine nächste Aufgabe werden.
Parallel stellt sich heraus, dass VS 2022 offenbar auch das Buildsystem Ant nicht mehr unterstützt, welches in VS 2017 noch Standard war.
Also ist auch hier noch eine Baustelle offen.

Fazit

Die Umstellung von VS-Solutions auf CMake ist bestimmt der richtige Schritt für die Zukunft. Aktuell ist das aber leider ein Rückschritt, da ich vorerst keine Android-Pakete mehr erstellen und testen kann.

Das ist zwar jetzt keine großes Drama … aber ich fand es schon toll, dass ich meine OpenGL GATE-Programme direkt auch als Android-App am Smartphone sehen konnte.
… aber das wird ja hoffentlich bald auch wieder funktionieren.

Audio am Raspberry PI

2023-08-06T13:00:00+02:00

Da stecke ich mal einen passiven Lautsprecher in die Buchse eines Raspberry PI 2 und erschrecke bei den erklingenden Kratz- und Störgeräuschen.

Der RPI überträgt nämlich auch Videodaten über diesen Stecker … und ich dachte, ich muss diese wegfiltern.

Spoiler: Es lag am Stecker.
Und eigentlich war meine ganze Aktion nur eine Spaßübung.

Unsere 3.5mm Audiostecker sind zwar “meistens” einheitlich aufgebaut wenn es um Audio geht, es gibt aber auch ein paar Ausnahmen.

In der simpelsten Variante gibt es nur zwei Kontakte, wobei die Hälfte der Spitze den Mono-Ton überträgt und am restlichen Schaftkontakt die Masse (Ground) liegt.
Also: <=====mono=====|=====ground=====####------------Device

Dann kann man die Spitze in linken und rechten Kanal unterteilen (links ist ganz vorne) gefolgt vom Ground.
Also: <=left=|=right=|=====ground=====####------------Device

Und schließlich kann man auch einen Ring vom Ground abschotten und “was anderes” wie das Mikrofon oder eben Video darüber übertragen.

Das heißt also vom Steckerplastik bis zur Spitze liegen 4 Ringe, nämlich:

Links (Spitze)
Rechts
Ground
Mikrofon/Video

Also: <=left=|=right=|=ground=|=micro=####------------Device

Wenn man jetzt einen Stecker mit 3 Kontakten (L,R und Ground) hat und dieser in eine 4-polige Buchse gesteckt wird, sollte der Chip die Überbrückung zwischen den beiden Kontaktringen feststellen und die optionale Übertragung ausschalten (bzw. ist die dann sowieso kurzgeschlossen).

Doch da bei meinem alten Lautsprecher furchtbares Kratzen auftrat, dachte ich, dass da was nicht korrekt funktionierte und so beschloss ich, aus ein paar alten Teilen einen “modularen” Stecker zu basteln um ausprobieren zu können, welcher Kontakt was überträgt.

Und somit verlötete ich 4 Litzen mit einem 4-poligen 3.5mm Stecker und am anderen Ende mit Pinsteckern. Dann packte ich noch eine 3-polige Audiobuchse auf eine Protoplatine zusammen mit einer Doppelpinbuchsenreihe.

Die 3.5mm Buchse passte nur verdreht auf die Platine … aber zum Ausprobieren ist das OK.

Kaum hatte ich meinen Adapter zwischen Raspberry PI und Lautsprecher geschaltet und nur die 3 relevanten Pins verbunden, kamen klare Töne aus dem Gerät und meine Mission war damit erfüllt.

Mit den Steckern konnte ich noch ein bisschen herumspielen und feststellen, was ich alles “verdrehen” konnte.

Am Ende stellte ich jedoch mit anderen Kopfhörern und Lautsprechern fest, dass ich diese auch direkt am Raspberry PI nutzen konnte, ohne dass Störungen hörbar wurden.
Der Grund war denkbar einfach: Der Stecker passte offenbar nicht ganz genau in die Buchse und so kam es offenbar auch zu anderen Überbrückungen. (Auch das 3D-gedruckte Gehäuse war daran etwas beteiligt.)
Mit etwas Gewalt konnte ich den Stecker temporär so fest einschieben, dass er auch ohne Adapter direkt klangrein arbeitete.

Fazit

Auch wenn es Alternativen gibt, so ist das kleine Adapterchen gar nicht mal so unpraktisch. Ich fände es generell super, wenn man bei allen Kabeln die einzelnen Kanäle aus- und einschalten bzw. auch umstecken könnte.

Zumindest habe ich gelernt, dass die Audio Pin-Belegung des Raspberry PI doch nicht vom Standard abweicht, was ich anfangs fälschlich annahm.
Nun könnte ich den RPi auch “lautstark” mitteilen lassen, woran er gerade arbeitet.
… doch das ist eine andere Geschichte.

M2 SSD Varianten

2023-08-05T13:00:00+02:00

Als 10 Jahre lang alles über IDE angeschlossen wurde (also zwischen 1995 und 2005), war meine kleine Welt noch in Ordnung. Ja, es gab dann die 40 und 80 poligen Kabel, aber alles war abwärts kompatibel.

SATA hätte diese Tradition als “ein” universeller Steckerstandardübernehmen sollen. Doch dann kamen MSATA und M.2 mit ihren “Keys” …

SATA Festplatten Anschlüsse

Serial-ATA definiert unter anderem auch die Steckkontakte zwischen Festplatten, Verkabelung und dem PC.
Da wäre der etwa 1cm breite Datenkontakt mit 7 Pins und der etwa 2 cm breite Stromkontakt mit 15 Pins. Beide Steckkontakte sind an einer Seite mit einer Erhebung ausgestattet, damit man Stecker nicht falsch einstöpseln kann.

Diese Teil war ein großer Vorsprung zum früheren IDE/ATAPI 40-Pin Flachbandstecker mit dem 4-Pin Molex-Stromanschluss. Denn dort waren zwar die beiden Steckkontakte definiert, nicht aber deren genaue Position auf dem Datenträger. Und so müssen bis heute Festplatten-Docking-Stations mit verschiebbaren Kontakten ausgestattet sein, die man an die Platte anpassen muss.

SATA definiert aber, dass die beiden SATA-Kontakte nebeneinander mit einem festen Abstand liegen müssen.
Und somit kann man de facto alle SATA Platten überall problemlos anhängen, und SATA Controller auf Mainboard und Datenträger einigen sich über die möglichen Geschwindigkeiten.

Doch leider liegt hier das Maximum bei 6 GBit/s mit SATA 3, die Vorgänger SATA 2 und 1 schaffen nur 3 und 1.5 GBit/s, allerdings besteht in der Regel Kompatibilität zwischen allen dreien.

mSATA direkt am Mainboard

Die 2.5 Zoll SSD Festplatten bestehen zu 2/3 aus Luft, tatsächlich wird nur ein kleiner Teil des Gehäuses für die Speicherchips benutzt.
Somit könnte man doch noch kleiner Chips direkt am Mainboard unterbringen; und genau das erreicht mSATA (mini-SATA).

Meine Baytrail Intel-Atom Boards aus um das Jahr 2013 hatten solche Slots verbaut und auch im Embedded und Industriebereich hat der kleinere Formfaktor seine Vorteile.

M.2 als neuer Formfaktor

M.2 definiert einen Form-Faktor, also die Größe einer Steckkarte, damit man diese und die Buchsen genau auf diesen Standard abstimmen kann.
Allerdings können neben Speicherkarten auch andere Geräte wie Modems und WLAN oder beliebige PCIe-Karten über das M.2 Format angebunden werden.

Um was es sich handelt, erkannt man an den Einkerbungen der Buchse bzw. der Steckkarte.
Und hier wird es bei dem inzwischen sehr klein gewordenem Steckkontakt mühsam, denn man erkennt nicht immer mit dem freien Auge, um welches Format es sich handelt. Hier muss man stets nachlesen, welche Buchse man hat und welches Medium dafür erwerben muss.

M.2 SATA SSDs mit zwei Einkerbungen

Die älteren und langsameren M.2 SSDs mit SATA Technologie erkennt man an den zwei Einkerbungen (M-Key und B-Key). Sie schaffen wie SATA-3 etwa 600 MB/s. In eine Buchse mit 2 Einkerbungen passen also nur SATA SSDs und nicht die folgenden NVMe-SSDs mit nur einer Einkerbung.

Umgekehrt kann eine SATA M.2 SSD meist auch in einer NVMe-Buchse betrieben werden.

M.2 NVMe SSDs mit einer Einkerbung

Hat eine M.2 SSD nur eine Einkerbung (nur M-Key), handelt es sich um eine schnellere NVMe SSD (Non-Volatile-Memory-Express) die je nach Modell biss zu 7000 MB/s Daten umschaufeln kann und damit 10x schneller als SATA M.2 SSDs sein können.

Eine NVMe M.2 SSD passt natürlich nicht in eine SATA M.2 Buchse, die für 2 Kerben vorgesehen ist.

Adapter für SATA und USB

Da ich ursprünglich nur ein Mainboard hatte, das NVMe SSDs unterstützte und ich sonst nur SATA-M2 Adapter gekauft hatte, lief ich in ein Problem beim Datenbackup nach einem Crash.

Ich hatte mich nie mit den Details zu M.2 SSDs befasst und dachte immer, dass die Formate ohnehin alle zueinander kompatibel sind. Doch das gilt eben nicht für NVMe bei SATA-Adaptern.

Ich musste mir also einen separaten USB3-NVMe-M2 Adapter besorgen um auch solche Speichermedien extern anzapfen zu können.
Seither liegen in meinem Hardware-Notfallkoffer immer beide Adapter, einer für M.2-SATA nach SATA oder USB und dann noch einer für M.2-NVMe nach USB3.

Fazit

Dass es zwei SSD Format gibt, die optisch ziemlich gleich aussehen, finde ich nach wie vor ungut … aber so ist das eben manchmal.

Auf lange Sicht werden SATA-M.2-SSDs vermutlich durch NVMe ersetzt werden. Das führt bereits zu niedrigen Preisen für die älteren Modelle und ist der Grund, warum ich mit denen recht gut eingedeckt bin.

Dass man aber auf der Fläche eines Daumen oder Zeigefingers heute Datenmengen von mehreren Terabyte unterbringen kann, die mit N-100 MB/s bearbeiten kann, ist eine Meisterleistung unserer Zeit.
Kaum zu glauben, dass ich vor 20 Jahren mit sauschweren 3.5 Zoll-Brocken hantieren musste, um 2 GB mühsamst ans Mainboard anschließen zu können.

Früher war eben doch nicht alles besser …

Marvel's Secret Invasion

2023-07-30T13:00:00+02:00

Nick Fury war mal “echt cool”. Aber ihm fehlte es an Hintergrund. Seinen eigenen Film hat er nie bekommen, doch nun hat ihn Marvel mit einer 6-teiligen Disney+ Serie in den Vordergrund geholt.

Und so habe ich 6 Wochen lang jeden Mittwoch darauf gewartet, wie der Erfinder der Avengers sein Stück vom Kuchen in Secret Invasion abbekommt.

Naja … und … ich weiß nicht.
Da fängt eine Serie so gut an, und endet dann genau wie She-Hulk mit der Intension ein W-T-F? auf die Stirn der Zuseher zu ritzen.

Der Held ohne Superkraft

Der Großteil der Marvel-Helden verfügt über eine übermenschliche Kraft, die er entweder durch Spinnenbiss, ein Wundermittel, kosmische Strahlen, Technik oder durch göttliche Abstammung erlangt hat.

Andere Figuren (die durchaus interessanter sein können) haben sich eine übermenschliche Technik antrainiert. Sei es ein perfektes Bogenschießen, maschinelle Unterstützung oder perfekt athletische Beinarbeit (wobei ich wieder bei “meiner” Scarlett Johansson angekommen wäre).

Nick Fury hingegen war nichts weiter als ein Ermittler, ein Agent, mit einem scharfen Verstand eines überlegenen Schachspielers.
Er brauchte keine Superkräfte, sondern versammelte und überzeugte nur die richtigen Leute zum richtigen Zeitpunkt für “seine Sache” zu kämpfen.

Genau das macht ihn eigentlich zum interessantesten MCU Helden … nämliche seine “überlegene” Normalität.

Secret Invasion

Da kamen also in den 90ern Aliens auf die Erde, die ein Zuhause suchten. Nick Fury wollte ihnen helfen … doch bis 2020 passierte nicht wirklich viel.
Die Lösung der Aliens: Terrorismus und die Erde für sich erobern.

So könnte man den Handlungsbeginn von Secret Invasion kurz zusammenfassen. Und jeder errät auch den Ausgang:
Nick Fury wird diese dunklen Pläne vereiteln.

Die spannende Frage war während der Serie also das “Wie”.

Und hier beginnt das Ganze auch echt gut. Wir sehen einen gealterten gebrochenen Fury, dem man nicht mehr viel zutraut. Man merkt, dass erst langsam wieder Leben in seine scheinbar müden Knochen kommt.
Wir sehen in Rückblenden, wie Hoffnung geschürt wurde, die an der Realität zerbrach und sich fast nachvollziehbar in Hass und Ablehnung auf der Gegenseite wandelte.

Und ich hatte meinen Spaß mitzuverfolgen, wie hin und her intrigiert wurde, falsche Freunde enttarnt und Feinde zu Verbündeten wurden.

Die verfluchte letzte Folge

Vorsicht Spoiler!

Und dann kam der Faustschlag mitten in mein Gesicht, als die vorletzte Folge von einer DNA-Mischung aller Superhelden sprach, die sich in der letzten Folge der Bösewicht einverleibte und quasi zum stärksten Superhelden aller Zeiten werden wollte.

W-T-F? Jetzt kann man sich also Superkräfte einfach einimpfen lassen? Diese Erzählung stört mich derart, dass ich es mir auch bei noch so gutem Willen einfach nicht schönreden kann.

Mit solche Stories gleitet Marvel auf das Niveau von DC’s Justice League hinab. Denn wo dort in den letzten 5 Minuten immer Superman alles wegfegt, weil er eben der Stärkste ist, kommt jetzt Marvel’s Avengers-Spritze. Dann gibt es einen 5 Minuten Boxkampf und “die Gute” gewinnt.

Für dieses Ende hätten wir nicht 6 Folgen gebraucht; das hätten Tom und Jerry auch in 5 Minuten vorspielen können.

Fazit

Es war schön Nick Fury und einige andere Charaktere noch mal in einer Serie zu sehen und auch die Darstellung eines gealterten und deplatzierten Helden war eigentlich gut angedacht.

Aber das Ende hat dem Ansehen der Figuren geschadet, und das ist schade.

Als nächstes werden wir Nick Fury wohl in The Marvels erleben dürfen, und ich hoffe, dass sich bis dahin der Charakter und sein Umfeld von “Secret Invasion” erholt haben werden.

Kurpark Oberlaa

2023-07-29T13:00:00+02:00

Meine Sommerspaziergänge führen mich jedes Jahr einmal durch den Kurpark Oberlaa. Es ist jetzt knapp 20 Jahre her, dass ich dieses kleine Idyll am Rande von Wien zum ersten Mal betreten habe.

Und immer wieder erfreut es einen, dass es in der grauen Stadt auch solche grünen Oasen gibt.

Wenn man vom Reumannplatz aus der Laaer-Berg-Straße nach Süden folgt, kommt man zwangsläufig am Kurpark Oberlaa vorbei. Diese 600 km² große Grünfläche bietet allen Besuchern kostenfrei mehrere Naturbereiche von Teichen, Wiesen, Waldstücken und Gartenanlagen in unterschiedlichsten Varianten.

Es ist also gar nicht notwendig aus der Stadt “raus” zu fahren, wenn man die Natur genießen willen, sondern man fährt einfach zur südlichen Endstation der U-Bahn Linie U1, wandert über einen der vielen Pfade und rastet und genießt die Umgebung auf einer der Bänke.

Und während in den städtischen Betonbauten im Sommer die Temperaturen klettern, spenden die Bäume im Kurpark angenehmen Schatten.

Bereits am Eingang von der Straße aus bekommt man einen Vorgeschmack auf die Pflanzenwelt, die einen erwartet.

Die Hauptwege durch das Areal sind alle asphaltiert und damit auch für ältere Menschen und jene mit Gehbehinderungen leicht nutzbar.

Mehrere Teiche können umrundet werden, und mir ist auch schon der eine oder andere Fischer aufgefallen, der geduldig seine Angel über das blaue Nass hielt.

Seitenpfade führen zu Beeten mit unterschiedlichsten Blumen und Grünanlagen.

Einige Wegstrecken sind grün “überdacht” und trennen so schattige Pfade von sonnigeren Raststätten.

Um die Sommerhitze überstehen zu können werden einige Bereiche immer wieder bewässert. So bleiben die Wiesen auch im Hochsommer grün.

Auch erheben sich immer wieder diverse Kunstwerke aus den Beeten und Terrassen.

Sonnenliege nur am Strand? Nein, auch auf den Wiesen des Kurparks sind verstreut Sonnenliegen aufgestellt um Urlaubsstimmung aufkommen zu lassen.

Platz ist im Grünen jedenfalls genug, und so kann sich jeder einen freien Picknickplatz aussuchen, während sich die Kinder nebenan mit Ballspielen beschäftigen.

Bäume spenden fast auf allen Wegen den begehrten Schatten …

… und runden die Landschaft um die Teiche ab.

Wie man sieht, sind die Anlagen nicht nur für das Naturgefühl sondern auch für das Auge erdacht worden.

Und Enten fühlen sich in den Teichen sichtlich pudelwohl.

Fazit

Kurz gesagt: Er ist einfach schön, unser Kurpark.

X11 mit Motif

2023-07-23T13:00:00+02:00

Mit GTK+ hatte ich ein portables UI Framework gefunden, welches ich sowohl in Windows als auch in Linux zur Entwicklung nutzen konnte.

Doch … wenn es um kleine UIs geht, ist dieses Riesenframework schon ein ziemlicher Overhead.

Und dann fiel mir wieder ein: X11 hat ja seine 30 Jahre alten X-Toolkits integriert.

Vorgeschichte

Es war Ende 2007 als ich mich zum ersten Mal mit UIs unter Linux und X11 auseinandersetzte. Schon damals wollte ich ein Äquivalent zur nativen WinAPI für UIs haben, die auf jedem System vorhanden sind und keine fetten Runtimes brauchten.

Die üblichen Vertreter GTK und QT waren mir damals schon unsympathisch, weil sie viel Eigenaufwand erforderten um kompiliert werden zu können und Tools wie CMake kannte ich damals noch nicht.

Hängen geblieben bin ich bei beim X-Toolkit mit seinen Xt* APIs, welches die Erstellung von “Widgets” ermöglicht, also Usercontrols wie Buttons, Labels und andere übliche UI Elemente.

Schon damals listete Wikipedia Athena, Motif und XView als klassische Implementierungen von solchen UI Widgets auf, doch da die letzten beiden zu dem Zeitpunkt noch nicht Open-Source verträglich waren, versuchte ich mein Glück mit Athena und seinen Xaw* APIs.

Athena’s Widgets sind mit Abstand die altbackensten, schwarz-weiß und mit teils unbenutzbaren UI Verhalten, wie z.B. dass man nur dann in eine Textbox schreiben konnte, wenn der Mauszeiger über dieser thronte. Auch die Scrollbars verdienten ihren Namen nicht.
Und somit war das UI-Experiment schnell beendet.

Heute

Wie gesagt: Ich hätte gerne eine UI Framework, dass möglichst leichtgewichtig ist und welches man leicht in eigene Projekte integrieren kann. Komplexe Sachen brauche ich nicht, ich will nur Buttons, Labels und Textboxen für primitive UI-Dialoge.

Und nachdem Motif gegen 2013 als Open Source Bibliothek neu veröffentlicht wurde und heute in jeder Linux und BSD Distro zu finden ist, dachte ich mir:

Implementieren wir doch einfach mal Motif Apps!

Motif

Bei Motif muss man zwischen den Xt (X-Toolkit) und den Motif Widgets unterscheiden. Man erkennt die Toolkit Funktionen am Xt Prefix, während die Motif Funktionen mit Xm beginnen. Widget-Klassen sind eigentlich nur String-Konstanten (beginnend mit xm) und identifizieren das zu ladende UI Control, bzw. dessen Layout und Verhalten.

Wie oft in UI Frameworks läuft alles in einer Event-Loop, die Benutzerereignisse an die Controls (Widgets) weiterleitet.
Das UI selbst beginnt mit einem Hauptfenster, in dem einer von mehreren Layout-Containern als Kind eingefügt wird.
Innerhalb des Containers werden dann die UI-Controls wie Buttons erzeugt und der Container übernimmt dann deren Ausrichtung und Positionierung.

flowchart LR subgraph XToolkit XTLOOP[[Event Loop]] SHELL[Application
Main
Window] end subgraph Motif Widgets CONTAINER(Control
Layout
Container) CONTROL1([UI Button A]) CONTROL2([UI Textbox B]) end subgraph User/Logic CALLBACK1[[button_pushed
Callback]] CALLBACK2[[text_changed
Callback]] end XTLOOP --- SHELL SHELL --- CONTAINER CONTAINER --- CONTROL1 CONTAINER --- CONTROL2 CONTROL1 --- CALLBACK1 CONTROL2 --- CALLBACK2

An die Widgets können Callbacks angehängt werden, damit ein “Button-Click” zum Aufruf einer Funktion führt.

In Code sieht das etwas so aus:

 1#include <X11/Intrinsic.h>
 2#include <Xm/Xm.h>
 3#include <Xm/Primitive.h>
 4#include <Xm/BulletinB.h>
 5#include <Xm/PushB.h>
 6
 7static void button_pushed_callback(Widget widget, XtPointer client_data, XtPointer call_data)
 8{
 9  XtAppContext app = (XtAppContext)client_data;
10  XtAppSetExitFlag(app);
11}
12
13void create_ui_widgets(XtAppContext app, Display* disp)
14{
15  Widget main_window = XtAppCreateShell(NULL, NULL, applicationShellWidgetClass, disp, NULL, 0);
16  XtManageChild(main_window);
17  XtRealizeWidget(main_window);
18    
19  Widget control_container = XtCreateWidget(NULL, xmBulletinBoardWidgetClass, main_window, NULL, 0);
20  XtManageChild(control_container);
21  XtRealizeWidget(control_container);
22
23  Widget motif_button = XtCreateWidget(NULL, xmPushButtonWidgetClass, control_container, NULL, 0);
24  XtManageChild(motif_button);
25  XtRealizeWidget(motif_button);    
26  XtAddCallback(motif_button, XmNactivateCallback, &button_pushed_callback, (XtPointer)app);
27}
28
29int main(int argc, char **argv) 
30{
31  char* display_name = NULL;
32  char my_app_name[] = "MyMotifApp";
33  char my_app_class[]= "MyMotifClass";
34
35  XtToolkitInitialize();
36  XtAppContext app = XtCreateApplicationContext();
37  Display* disp = XtOpenDisplay(app, display_name, my_app_name, my_app_class, NULL, 0, &argc, argv);
38
39  create_ui_widgets(app);
40
41  XEvent xevt;
42  while(!XtAppGetExitFlag(ctx))
43  {
44    XtAppNextEvent(app, &xevt);
45    XtDispatchEvent(&xevt);
46  }
47
48  XtCloseDisplay(disp);
49  XtDestroyApplicationContext(app);
50  return 0;
51}

Fazit

Meine Herausforderung ist es nun, für alle bereits existierenden GATE UI Controls eine Entsprechung in den Motif Widgets zu finden. Buttons und Labels sind wie üblich leicht. Schwieriger wird es dann vermutlich mit Treeviews und Listviews werden, die viele Daten verwalten müssen.

Aber nachdem mir das mit der WinAPI und GTK gelungen ist, ist es nur eine Frage der Zeit, bis ich das auch auf Motif portiert haben werden.

Das Problem ist heute eher die Dokumentation und Beispiele. Die Technik stammt aus den 90ern und früher und wird heute in neuen Projekten kaum mehr genutzt. Kein Wunder also, dass auch die Dokumentation dünner geworden ist.

In sofern also gut, dass das wieder einmal alles ausgegraben wird.

WinAPI: Win16

2023-07-22T13:00:00+02:00

Windows ist abwärtskompatibel. Alte APIs bleiben bestehen, es kommen nur neue dazu.

So heißt es. Also ist Win95 einfach ein Win3x + Erweiterungen. … zumindest glaubte ich das bisher.

Obwohl mein erstes Windows noch zur 3.x Generation gehörte, habe ich nur ein bisschen Visual Basic darauf ausprogrammiert.
C und C++ programmierte ich erst später und nur gegen das Win32 API.

Doch mein Glaube war stark, dass ich somit auch “Win16” beherrschen würde, weil dieses in Win32 aufgegangen ist, quasi nach der Formel:
Win32 = Win16 + Threads

Ich hätte gar nicht falscher liegen können, wenn man von einigen wenigen Details zur Fenstergestaltung absieht.

OpenWATCOM, “der Compiler” des 20. Jahrhunderts kann auch heute noch Win16 Binaries erzeugen.
Und somit wandert auch diese Plattform langsam ins GATE Projekt

Andere APIs

So wie im POSIX Code häufig ein open() der Anfang von allem ist, so sieht man im WinAPI Code stets ein CreateFile(). Doch Win16 hatte eine solche Funktion nicht, auch kein ReadFile() oder WriteFile() und so stand ich vor der ersten großen Frage:

Soll ich jetzt alle Codestellen per #ifdef WIN16 mit einer zweiten Implementierung beglücken, wenn die Win32 Funktion nicht in Win16 verfügbar ist.

Jein ist die Antwort.

Es gibt schon solche Stellen, die vollständig neu geschrieben werden müssen. Ein Beispiel wären “Prozesse”, die in Win16 nur “Tasks” mit Task-ID waren und technisch mit Win32 Prozessen nichts zu tun haben.

Doch bei häufig genutzten APIs wie beim Dateisystem wählte ich einen anderen Ansatz: Die Win32 API wird einfach mit Win16 Funktionen emuliert.

Win32	Win16
CreateFile	OpenFile
ReadFile	_lread
WriteFile	_lwrite
CloseHandle	_lclose
DeleteFile	OpenFile(OF_DELETE)
FindFirstFile	opendir
SetFilePointer	_llseek
GetFileSize	_llseek

und so weiter.

Dadurch lassen sich dann bereits fertige Codes sofort kompilieren, einzige Herausforderung ist, dass ich das Verhalten auch ausreichend genau nachbauen muss.

Keine Fehler

Viele Win16 APIs haben keine Rückgabewerte, während ihre Win32 Nachfolger diese sehr wohl nutzen um Erfolg von Misserfolg zu unterscheiden. Hier bleibt mir dann doch nur ein #ifdef um den Rückgabewerte in Win16 zu ignorieren.

Außerdem gab es kein GetLastError() und SetLastError().
Zumindest das kann man mit einer globalen Variable selbst leicht nachbauen.

Keine DIBSection

Interessant ist, wie häufig ich in Win32 DIBSections eingesetzt habe um dann direkt auf dem Grafikpuffer Pixel nachzubearbeiten.
Tja, da macht einem Win16 auch einen Strich durch die Rechnung: Man kann dort nicht selbst einen Puffer allokieren und an eine Bitmap ausleihen.

Einzige Alternative ist, einen Pixelpuffer zu befüllen und dann an CreateDIBitmap zu übergeben. Dann kann man zwar nicht mehr direkt auf die Pixel in der Bitmap zugreifen, aber man kann zumindest immer wieder neue Bitmaps mit fertigen Bildern erstellen.

UI Flags

Doch das schlimmste sind fehlende Features bei UI Controls. Das Konzept von Fenstern, Buttons, Labels und Textfeldern ist von Win16 direkt auf Win32 übernommen worden. Doch Win32 hat zahlreiche Flags und Details angefügt, die ich inzwischen aktiv eingesetzt hatte.

Um jetzt daraus wieder Win16-kompatiblen Code machen zu können, muss ich entweder auf einige Features verzichten, oder das Control im Win32 Stil unter Win16 nachimplementieren.

Bei erweiterten Controls wie Treeview und Listview ist das ohnehin notwendig, da es die unter Win16 nicht gab.

Fazit

Alles in allem ist das zwar eine interessante Erfahrung, aber ich habe total unterschätzt wie unterschiedlich Win16 von Win32 war und ist.

Umgekehrt kann man auch sagen, wie sehr ausgereift Win32 im Gegensatz zu Win16 ist, denn hier zeigt sich erst, mit wie wenig seltsamen APIs damals Anfang der 90er gearbeitet werden musste.
(Und trotzdem kamen einige große Apps dabei heraus.)

DOS Framebuffer

2023-07-16T13:00:00+02:00

Das Tool DOSBox startet mit Standard Einstellungen seine Emulation mit nur wenigen CPU Zyklen, und trotzdem lässt sich darin Prince of Persia flüssig spielen.

Warum also läuft mein Code so grottig darin?

Wenn man Code wie ein Anfänger schreibt, dann darf man sich nicht wundern, wenn die CPU den Code auch wie ein Anfänger ausführt.
Also schlecht.

In meiner generischen Implementierung für den Zugriff auf Rastergrafiken werden die Pixel per (x,y) Koordinaten durchgelaufen um die Farben auf die einzelnen Pixel zu übertragen.
Das ist natürlich höchst ineffizient, denn bei jeder Pixel-Operation wird y mit der Bildlänge ausmultipliziert und x addiert um zur richtigen Speicherstelle zu gelangen.
Es ist ineffizient, dafür aber generisch und läuft überall.

Um jetzt aber ordentliche Frame-Raten zu erzielen, habe ich optimierte Funktionen geschrieben, um diverse Operationen direkt per Zeigerarithmetik ohne lange Rechnungen auszuführen.

Vergessen hatte ich das aber bei einer nicht ganz unwichtigen Routine: nämlich clear(), die da Bild löscht, bzw. mit einer bestimmten Hintergrundfarbe vollständig übermalt.

Tja, am Windows PC mit 3 GHz+ fällt der Fehler natürlich nicht auf, denn auch das langsamste clear wird dort in Sekundenbruchteilen umgesetzt.

Startet man das ganze aber im DOS Emulator mit den simulierten Geschwindigkeiten eines 80286 / 80386 dauert es plötzlich mehrere Sekunden, bis der Schirm “frei” wird, wenn der Bildpuffer mit der ineffizienten Codevariante gelöscht wird.

Beste Lösung: memset()

Ich änderte also die Löschroutine von einem

1void clear_image(unsigned char back_color) {
2  for(int y = 0; y < height; ++y) {
3    for(int x = 0; x < width; ++x) {
4      set_pixel(x, y, back_color);
5    }
6  }
7}

in etwa in ein:

1void clear_image(unsigned char back_color) {
2  unsigned char* pixel_ptr = get_pixel_ptr(0, 0);
3  size_t length = width * height;
4  memset(pixel_ptr, back_color, length);
5}

und schon war “das Spiel” 10 mal schneller.

Fazit

Vor 25 Jahren waren solche Optimierungen für mich ein absolutes Muss und auch ein riesigen Spaß bei der Implementierung.
Ich bin heute fast etwas entsetzt, dass mir so eine generische Routine “durchgerutscht” ist, und ich es nicht sofort bemerkt hatte.

In diesem Sinne wieder mal “ein Hoch auf DOS” und den Emulator DOSBox.
Dort lernt man nämlich wirklich gutes Ressourcenmanagement …
… weil man nur so wenig hat.

CONAN 2

2023-07-15T13:00:00+02:00

Das Buildsystem CONAN hatte einige Fehlerchen in seinem Konzept. Doch schon seit Jahren läuft parallel die Entwicklung von CONAN 2. Und dieses Projekt wälzt jetzt quasi alles um.

Vorgeschichte

Ich wurde vor 4 Jahren eigentlich durch ein Migrationsprojekt in der Firma auf CONAN aufmerksam. Ein bestehendes CMake Projekt sollte in CONAN Packages aufgeteilt werden, damit diese versioniert im dortigen jfrog Repository abgelegt werden können.

Der Vorteil von CONAN liegt vor allem im Dependency-Management, wenn es um die Bereitstellung aller notwendigen Drittkomponenten geht.

Niemand befasste sich damals mit den unterschiedlichen “Generatoren” innerhalb von CONAN v1, sondern man nahm den offensichtlich passenden, nämlich den cmake Generator.

Dieser erzeugt aus den aufgelösten Abhängigkeiten eine cmake-include Datei, welche vom Projekt CMakeLists.txt inkludiert wird. Und alle Details der Abhängigkeiten liegen im Form von CMake Variablen vor, die das Projekt nun integrieren kann, also z.B mit:

1include_directories(${CONAN_INCLUDE_DIRS})
2
3target_link_libraries(${PROJECT_NAME} ${CONAN_LIBS})

Daraus ergibt sich leider das Problem, dass diese “magischen” CONAN-CMake Variablen dann nur noch innerhalb einer von CONAN erstellten Umgebung korrekt funktionieren.
CMake hingegen würde normalerweise ohne CONAN per find_package(dependency) Abhängigkeiten suchen …

Und so wurde eine Entscheidung getroffen:

Der CMake-Generator aus CONAN v1.x wurde in CONAN v2 entfernt.

Migration nach CONAN v2

Neue Generatoren

Anstatt also eine zirkuläre Abhängigkeit zwischen CONAN und CMake zu erzeugen, arbeitet CONAN v2 also “Zulieferer” für CMake.

Der CMakeDeps Generator erzeugt nun alle erforderlichen .cmake Dateien, die per find_package dann die Abhängigkeiten im korrekten CMake-Stil in ein Projekt integrieren. Man nutzt also keine CONAN-CMake-Variablen, sondern schreibt die CMakeLists.txt so, als ob CONAN nicht involviert wäre.
Der CMakeDeps Generator aus v2 ähnelt sehr dem cmake_find_package Generator aus v1.

Der CMakeToolchain generator hingegen erzeugt eine Toolchain-Datei, die notwendige Informationen über den zu nutzenden Compiler und die Zielplattform enthält. Man startet also CMake mit dem Verweis zu Toolchain-Datei um den CMake-Build einzurichten. Auch hier haben wir keine magischen Variablen mehr im Hintergrund.

Diese beiden neuen Generatoren sind also der Nachfolger des abgekündigten v1 cmake-Generators.
Das wäre ja alles super, wenn es nicht bedeuten würde, dass jedes Projekt und vor allem alle CMake-Dateien jetzt umgeschrieben werden müssen.

Änderungen in conanfile.py

Eine weitere gravierende Änderung ist, dass CONAN’s Python Framework ebenso geändert wurde. Befanden sich bisher alle Klassen und Hilfswerkzeuge im Python Modul conans, so ist man jetzt zum Namen conan zurückgekehrt. Aus

1from conans import ConanFile

wird

1from conan import ConanFile

Auch andere neue Methoden in einer Conan Klasse wurden geändert. So werden Generatoren nun in der neuen Method generate() geladen und angewendet und die layout() Methode gestattet Änderungen von Attributen, wo Pfade für Quellcodes und Ausgabedateien hinzeigen sollen.

imports() wurde vollständig entfernt, an dessen Stelle treten die neue “Deployer”, mit denen Dateien aus Abhängigkeiten extrahiert werden können. Damit ändert sich auch die Funktion der bestehenden deploy() Methode, die nun mit dem eingesetzten Deployer zusammenspielen muss.

… und vieles mehr.

Fazit

CONAN v2 macht technisch vieles richtig. Es gestattet einem Projekt vor allem nach einer einmaligen Konfiguration durch CONAN, selbständig zu laufen. In v1 waren die engen internen Verflechtungen zwischen CONAN und CMake häufig die Ursache von Problemen, die damit behoben sein sollten.

Doch leider macht dieses Neudesign die Migration von großen Projekten mehr als schwierig.

Ich bin gespannt, wie wir jetzt in der Firma mit dem Thema umgehen. Es steht jedenfalls fest, dass eine Migration auch viele Vorteile und vor allem Zukunftssicherheit bringen wird.

C++ Result T, E

2023-07-09T13:00:00+02:00

Es gibt da diese eine Sache, die von Rust und ZigLang herüberzieht, die mir keine Ruhe mehr lässt: Nämlich die Rückgabe von Ergebnissen und Fehlern in einer eigenen Datenstruktur ohne Exceptions.

Tja … und da C++23 mit std::expected einfach noch zu weit weg ist, habe ich kurzerhand Result<T, E> in mein Framework aufgenommen.

Das Problem mit C++ Exceptions ist nicht das Konzept, sondern dessen Implementierungen in GCC und MSVC, die immer nur eine Ausprägung zulassen. Man könnte Exception auf unterschiedliche Weisen in Binärcode abbilden, doch um modul-übergreifend kompatibel zu sein, muss man bei einer Variante bleiben.

Und somit verhindern C++ Exceptions weiter, dass ich “lesbaren” Code für EFI-Applications schreiben kann, weil ich nur reine C Routinen dort verarbeiten kann.

Andere (EFI-) Projekte haben das auch durchgemacht und propagieren C++ ohne Exceptions und RTTI, womit sie erfolgreich sind.
Doch wie werden dort Fehler behandelt?

Return-value Codes

Tja, man brauch Return-Typen, die sowohl Fehler als auch Erfolgsresultate erhalten können. Rust und ZIG tragen dieses Konzept in der Kernsprache und können es dort (hoffentlich) gut optimieren.

In C++ kann man natürlich ein Template schreiben, dass wie ein std::variant einen von zwei möglichen Typen enthalten kann.
Ein solcher std::expected<succes_type, error_type> Typ wird entweder mit dem einen oder anderen Typen konstruiert und gibt ihn so gekapselt an den Aufrufer zurück.

Dieser kann dann aus-if-en, ob er einen Fehler oder einen Erfolg erhalten hat.

Ein Code sagt mehr als 1000 Worte:

 1
 2struct division_error {};
 3
 4int devide_classic(int a, int b) {
 5  if(b == 0) {
 6    throw division_error();
 7  }
 8  return a / b;
 9}
10
11void do_devide_classic() {
12  try {
13    int result = devide_classic(4, 2);
14    std::cout << "Result=" << result << std::endl; 
15  }
16  catch(devision_error const&) {
17    std::cout << "Error" << std::endl;
18  }
19}
20
21std::expected<int, division_error> devide_new(int a, int b) {
22  if(b == 0) {
23    return division_error();
24  }
25  return a / b;
26}
27
28void do_devide_new() {
29  auto result = devide_new(4, 2);
30  if(result) {
31    std::cout << "Result=" << *result << std::endl; 
32  }
33  else {
34    std::cout << "Error" << std::endl;
35  }
36}

Umsetzung im GATE Projekt

Eigentlich sind Exception ein zentraler Bestandteil der C++ Implementierung des GATE Projektes. Ich kann jetzt nicht auf ein anderes Error-Modell umsteigen ohne alles neu schreiben zu müssen.

Allerdings möchte ich schrittweise die bestehenden C++ Klassen erweitern. Neben den normalen Methoden mit Exception-Support, soll es alternative Funktionen mit dem Präfix try geben die ein gate::Result<T, E> zurückliefern und eben keine Exceptions auslösen.

1class Foo {
2public:
3  int         doSomething();
4  Result<int> tryDoSomething() noexcept;
5};

Meine Hoffnung liegt beim C++ Optimizer, der die als statische Bibliotheken erzeugten C++ Klassen scannt und dann nur die Methoden übersetzt, die tatsächlich benutzt werden.

So kann man Apps schreiben, die nur die Exception-freien C++ Methoden nutzen.

Fazit

Andere Länder - andere Sitten.
Andere Sprachen - andere Fehlerbehandlungen.

Dieser Ansatz ist ungewöhnlich und ich bin mir noch nicht sicher, was ich am Ende davon halten soll. Trotzdem denke ich, dass Exception-frei Apps eine Existenzberechtigung haben und somit werde ich mal sehen, wo mich dieser Weg hinführt.

Szenen, die das Leben schreibt

2023-07-08T13:00:00+02:00

Ich bin ja keiner von diesen geselligen Leuten, die abends mit der Gruppe in ‘ner Kneipe sitzen und saufen. Wenn 10+ Personen kreuz und quer quasseln, nervt mich das eher.

Aber ein gemütliches Abendessen mit ein paar wenigen Freunden oder Kollegen kann schon sehr nett sein.

Und genau an solchen Orten erlebt man dann die lustigsten Dinge.

Im Sommer läuft die Wiener Gastronomie auf Hochtouren, jeder Hof und jeder Gehsteig wird mit Tischen und Bänken zugepflastert.

Man denkt, dass im 21. Jahrhundert die Klischees der Vergangenheit und die eigenartigen Figuren der Wiener Straßen verschwunden sind, und alles nur noch generisch pseudo-professionelle Bedienung ist.

Doch nein, sie sind nicht auszurotten und dafür bin ich dankbar. In 3 Stunden in einem Gasthof konnte ich mehr Sketches für eine Comedy-Show sammeln als im mehrjährigen Studium des Programms des Kabarett Simpl.

Der schwule Kellner

Ich dachte erst: Der spielt das doch nur. Denn ich sah vor mir ein Bild von Winnitouch aus Der Schuh des Manitu, doch das war es nicht ganz. Die Bewegungen waren nicht so plump hopsig, aber hatten trotzdem immer einen Hauch von Balletttanz mit einer Brise Aufmüpfigkeit unterfüttert.

Die beste Szene war ohnehin gleich am Anfang nach der Bestellung als sein Smartphone bimmelte und er genervt meinte:

Huch, das ist wieder der Chef von der SPÖ.

Dann hob er ab und trillerte ein so typisches “Haaaaaallooo” in das Mikro, wie ich es nur von Hape Kerkeling kenne.

Am schlimmsten war, das wir im Unklaren blieben, ob er mit dem SPÖ Chef jetzt Ludwig, Babler oder Doskozil gemeint hat.

Aber auch weitere Gespräche, vor allem bei seiner Alkoholempfehlung waren wie aus dem Bilderbuch.

Der Obdachlose?

Wenn sich jemand plötzlich selbstbewusst an den Tisch setzt und mitdiskutiert, bin ich erst mal verwirrt.
Ich gehe dann meine optische Datenbank durch und stelle fest:

Etwas dicklich, Hipsterbart, oben vier Zähne, unten Drei und schnauzt im Vorbeigehen immer wieder die anderen Kellner an. … hmm, der will hier einfach mitschmarotzen.

Er redet stets von “seinen Köchen” und wie schlecht die Qualität in dem Laden geworden sein, was er auf die Inflation, die Politik und den Preisdruck in der Lebensmittelindustrie zurückführt.
Mit der Zeit denke ich: Naja, vielleicht ist der hier sogar angestellt um die Leute zu unterhalten, denn er schiebt Kommentare, wie ich sie früher nur von Hermes Phettberg kannte.

Als ich nach dem Abendessen nachfragte, stellte sich heraus, es handelte sich um einen der Chefköche des Restaurants, der nur gerade frei hatte.
Alter Schwede … der hat unser Essen gekocht … und das arge war, es war unglaublich gut.

Der Nachbar

Wochentags sind sie am häufigsten am Abend beim Wirt: Die Einzelpersonen. Sie sitzen alleine an den Tischen jeweils links und rechts von Pärchen und Gruppen umgeben.
Zuerst nehmen sie Witterung auf, blicken zaghaft in die Richtung eines Tisches und schnappen ein paar Worte auf. Sind die richtigen Passwörter gefallen, werden die Tischgäste mit den Augen fixiert und wie eine Gazellenherde beobachtet.

Nun ist es nur noch eine Frage der Zeit bis der Einzelkämpfer ins Gespräch einfällt:
Das beste Album von 1985, das letzte Tor beim gestrigen Spiel … schon fliegt das erste Argument und der Dialog am Nachbartisch wird zum Trialog aufgestockt.

Der Wortwechsel dauert dann wie ein kurzer kräftiger Regen, verschwindet dann aber genau so schnell, wie er begonnen hat. Denn der Jäger bereitet sich schon auf den Tisch auf der anderen Seite vor.

Fazit

Weitere Details erfahren Sie von ihrem Wirt!

Es ist schon verrückt, welche Personen man ungeplant in einem Gasthof auffindet, und jede einzelne kann bereichernd wirken. Entweder durch ihre lockere (schwule) Art, durch ihre scheinbar kümmerliches Auftreten oder durch ihre Direktheit.

Diesen Charm haben McDonalds und Burgerking noch nie gehabt und leider auch ein Stück weit vertrieben. Doch an den richtigen Stellen blüht der alte Wiener Schmäh weiter auf und da kann freilich auch jeder Heurige am Land mithalten.

Ich werde zwar nie zum Kneipengeher werden und nie mit einem Wirt befreundet sein, aber von Zeit zu Zeit genieße ich ein solches Spektakel neben einem guten Essen sehr. Und offen gesagt ist das auch günstiger. Für meine 20 bis 40 Euro bekomme ich je nach Ausstattung ein ordentliches Abendessen und ein improvisiertes Liveprogramm dazu. Im Theatersaal mag die Unterhaltung sicher auch stimmen, doch da kommt man mit so wenig Geld nicht hinein.

Hinweis: Und wer gerne weitere Live-Reality-Dokus sehen will, der nimmt den Platz zwischen Küche und Toilette. Dort geht sprichwörtlich alles vorbei, was man gerade noch so verdauen kann.

Haiku OS als Plattform

2023-07-02T13:00:00+02:00

Ein neues Mitglied wird provisorisch in die Familie aufgenommen:
Haiku, die OpenSource-Variante des früheren BeOS Betriebssystems.

Das GATE Projekt wird nun um einen Platform-Support-Layer für BeOS erweitert.

Kompilieren für Haiku/BeOS

BeOS und Haiku basieren (zumindest in der 32-bit Version) auf GCC Kompilaten. Von daher ist die Toolchain dem Linux Build im GATE Projekt ziemlich ähnlich …
… dachte ich.

Und tatsächlich stimmt das auch, denn unter einem frisch installierten Haiku lässt sich der Build-Prozess mit cmake und make ganz regulär starten.

Im ersten Test erstellte ich so Konsolenprogramme, die unter Haiku ausgeführt werden konnten.

Alternativ werden auch Docker Images für Linux angeboten, in denen ein Cross-Compiler für Haiku enthalten ist.
Hier bedurfte es einer CMake-Toolchain Datei um die nötigen Pfade zu setzen. Der Build klappte zwar, doch die Binärdateien waren im Anschluss nicht in Haiku ausführbar.

Das wirft mich jetzt etwas zurück, da die Docker-Entwicklung effizient abgelaufen wäre. So muss ich in der VM mit UIs arbeiten, die sich anders verhalten als gewohnt, was leider immer Zeit kostet.

Aber hey … wir stehen noch ganz am Anfang … das wird schon noch werden.

Die Kernel API

Da das GATE Projekt direkt mit dem OS reden soll, müssen einige GATE-APIs für Prozesse, Threads, Atomics, Zeit und Dateien neu implementiert werden.

Die BeOS APIs basieren großteils auf C++ Klassen, was im GATE Projekt mit meinen C-Vorgaben kollidieren würde. Doch die Kernel-Schnittstellen für die genannten Basisdienste sind zum Glück reine extern C Funktionen und können somit direkt aufgerufen werden:

Bisher kam ich mit folgenden BeOS-spezifischen Headern in Berührung:

1#include <kernel/OS.h>
2#include <support/SupportDefs.h>
3#include <support/TLS.h>

Interessant finde ich, wie “einfach” die Schnittstellen gehalten sind. Natürlich fehlen auch einige Konstrukte, die ich aus den POSIX-Threads kenne, doch diese werden sich alle mit dem bestehenden Grundstock nachbilden lassen.

Beschrieben ist alles im Be Book - Kernel Kit

Offene Frage: C++

Sobald es zu den höheren Funktionen wie IPC oder UIs kommt, ist C++ zwingend erforderlich. Hier käme ich dann in die ungewöhnliche Situation, dass ich einen C-Wrapper um die C++ Klassen schreiben müsste, um sie in die C Bibliotheken integrieren zu können.
Und am Ende würde der GATE C++ Layer wieder C++ daraus machen.

Das ist natürlich reiner Overhead, aber vorerst sehe ich keine Alternative … doch wer weiß, was ich noch alles von dem neuen alten OS lernen kann.

Es wird allerdings noch einiges an Zeit vergehen, bis ich an diese Decke stoßen werde.

Fazit

BeOS/Haiku Interna zu lernen mag mancher als Zeitverschwendung abtun.
Ich sehe es anders.
Jede neue Plattform hat ihre Eigenheiten, die in Ihrer Umgebung absolut legitim sind. Nur durch das “Erleben” aller Facetten lässt sich Code so erarbeiten, dass er wirklich universell einsetzbar wird.

So wie ich von Windows gutes und schlechtes API-Design erlernte,
von Linux gutes Streaming und schlechtes Service-Management,
und von DOS enge Limits und direkte Zugriffe,
so erwarte ich mir auch von BeOS/Haiku eine neue Sicht auf die Welt, aus der ich Gutes übernehmen und Schlechtes umgehen kann.

Services für Win9x

2023-07-01T13:00:00+02:00

Während der Windows 98 und ME Support im Jahr 2003 ablief, hatte ich noch 2008 den Auftrag, Software so zu schreiben, dass sie unter Windows 9x ausführbar ist.

Dabei ging es “nur” um normale UIs.

Dienste wie unter NT gab es nicht … oder vielleicht doch …?

Es ist schon ein bisschen ironisch, dass sich die damals junge Linux Community zu Recht über “das schlechte Windows” aufregte, und dabei fast ausschließlich Probleme mit Windows 95 und 98 nannte.
NT4 und 2000 konnte man dann nur als zu aufgebläht bezeichnen.

Die strukturierte Verwaltung von “Diensten” (Daemons unter Linux) hatte aber nur NT wirklich drauf, während sich das junge Linux mit init-Scripten plagte und interessanterweise nicht viel mehr hinbekam, als eben Windows 9x.

Kein Service Manager

Der Service Control Manager (SCM) definiert unter NT die Infrastruktur eines Dienstes. Eine EXE startet und registriert sich selbst per API als Dienst inklusive Callbacks für diverse Statusänderungen und die Service-Runtime führt diese Callbacks als RPCs dann “kontrolliert” aus.

Win9X kannte einen solchen Dienst nicht, hatte aber einen für damals typischen billigen Trick, um so etwas Ähnliches wie Hintergrunddienste anzustarten.

Registry + Registration = Service

Viele Leute kennen den Registry-Key
HKEY_LOCAL_MACHINE\Software\Microsoft\CurrentVersion\Run, dessen Einträge beim Login durchgelaufen werden und die String-Values einfach als Prozesse gestartet werden.

Für Dienste gab es HKEY_LOCAL_MACHINE\Software\Microsoft\CurrentVersion\RunServices, dessen Einträge schon beim Start des Windows-UI abgearbeitet wurden. So konnte man per Key-Namen jedem Dienst einen Namen zuordnen und der String-Wert war einfach die Kommandozeile, die den Dienst starten sollte.

Da bei der Abmeldung eines Benutzers auch alle laufenden Prozesse gekillt wurden, musste man noch einen Möglichkeit schaffen, die Dienst-Prozesse als ebensolche zu markieren. Und das geschah mit folgender kernel32 API:

1DWORD WINAPI RegisterServiceProcess(DWORD dwProcessId, DWORD dwType);

Diese Funktion existierte nur in Windows 9x und nicht NT, doch man konnte sie per GetProcAddress() laden um zu beiden OS-Typen kompatibel zu bleiben.
Ein Aufruf von RegisterServiceProcess(GetCurrentProcessId(), 1) registrierte einen Prozess als Dienst, und schon wurde er nicht mehr beim Logout beendet.

Anwendung

Manche Netzwerkserver für Windows wie FTP, HTTP oder NTP nutzten diese Methode um im Hintergrund ihre Dienste durchzuführen.
Doch da Windows 9x selten für solche “Dienste” genutzt wurde, ging diese Methode wieder in Vergessenheit.
Man findet sie noch in sehr alten Code-Repositories in Softwareständen vor 2003, doch danach wurde der Win9x-Service Support systematisch überall entfernt.

Die Funktion RegisterServiceProcess selbst findet man “leider” in zahlreichen alten Foren als “Hacker-Funktion” um das eigene Programm vor dem Task-Manager zu verstecken.
Wer also Böses vor hatte und nicht wollte, dass das eigene Programm leicht gekillt werden konnte, registrierte es fälschlich als Dienst.

Fazit

Auch diese Technik wandert nun ins GATE Projekt und tut dort seinen Dienst, wenn die NT-APIs nicht geladen werden können … sprich, wenn ein Prozess unter Windows 9x gestartet wird.

Da diese Funktion aber nur in ANSI-Kompilaten Sinn macht, ist dieser Teil in Unicode- oder x64- Varianten generell per #ifdef deaktiviert.

C++ Erbschafts-Steuer

2023-06-25T13:00:00+02:00

Politisch kann ich mich mit der Idee der Erbschaftssteuer gut identifizieren, vermutlich deshalb weil mich kein Millionenerbe erwartet.

In Sachen C++ sollte jedenfalls jede unnötige Form von Erbschaft rigoros weggesteuert werden. Und im Gegensatz zur Politik mache ich gerne Nägel mit Köpfen und setze diese Ziel einfach um.

Und wieder einmal hat mich der ehrwürdige alte Zen-Meister OpenWatcom auf eine Lebensweisheit aufmerksam gemacht:

code_bloat = exceptions * inheritance

Vorgeschichte: Welche Ausnahmen gibt es überhaupt?

Anfangs dachte ich, dass Exceptions im Java-Style “übersichtlich” wären. Es gibt im GATE Framework daher eine abstrakte Throwable Klasse, von der eine Exception Basisklasse erbt, und dann gibt es im Namensraum exceptions noch für jeden Result-Code eine Template-Variante, wie z.B.:

exceptions::NotImplemented
exceptions::NullPointer
exceptions::Timeout
exceptions::OutOfBounds
usw.

In Wahrheit sind die exceptions:: Varianten nur mit einem Result-Code konstruierte Exception(results::ErrorCode) Instanzen.

Zwar habe ich schon häufiger die “Endknoten” per throw geworfen, doch in den catch Blöcken reagiere ich in erste Linie auf Instanzen der Exception Basisklasse.

Der Grund ist einfach: In fast allen Fällen ist es egal, ob z.B.: ein Dateizugriff, wegen eines AccessDenied oder NotAvailable Fehlers abbricht. Man loggt den Fehler und beendet die Operation. Es bringt mir also im Normalfall nichts zwischen den Fehlern zu unterscheiden und falls doch, tut das ein einfaches if ebenso.

Die eine Exception, die viele ist…

Ich könnte also gleich die Basisklasse mit dem entsprechenden Fehlercode werfen. Und um das umzusetzen, nutze ich eine Funktion namens

1void raiseException(result_t resultCode, char const* msg = 0, char const* src = 0, int32_t errCode = 0);

Die machte bisher nichts anderes als den resultCode Parameter auszuwerten und daraus ein
throw exceptions::Something(msg, src, errCode); auszulösen.

Und seit neuem macht sie nur noch:
throw Exception(resultCode, msg, src, errCode);

Und das alleine reichte, um die DOS Varianten meiner GATE Tools um 70 bis 80 KByte zu verkleinern. So wurden aus 290 KB wieder 215 KB, ohne dass sich funktional was änderte.

RTTI und Catch-Blöcke

Mit jeder neuen abgeleiteten Klasse einer abstrakten Basis, wird ein unsichtbares Netz von Typenverknüpfungen um Hintergrund gesponnen, das dann zum Einsatz kommt, wenn zur Laufzeit eine Exception geworfen und schrittweise als ihr Basistyp zum Catch-Block überführt werden muss.

Je mehr Klassen es gibt um so größer wird der generierte Hintergrundcode, der dann am Ende vielleicht nie benutzt wird, aber trotzdem vorhanden sein muss.

Jetzt könnte man natürlich hoffen, dass ein guter Optimizer den Großteil davon wegbekommt, doch wie sich zeigt, passiert das nicht (bzw. nicht immer).

Am einfachsten kann man den Müllberg also dadurch klein halten, dass man im Vorfeld gar keinen Müll mehr produziert. Und dieser Ansatz funktioniert offenbar zu meiner großen Freude.

Fazit

Ich habe die früheren exceptions::Something Klassen per #ifdef deaktiviert, denn vielleicht finde ich in Zukunft doch noch Verwendung für sie. Aber das DOS Beispiel hat mich bereits davon überzeugt, dass “eine” gute Exceptionklasse viel Effizienter ist, als 20 individuelle.

Ich belasse daher die vereinfache Variante und freue mich, dass der ohnehin große Exceptionoverhead wieder ein Stück erträglicher geworden ist.

CONAN CPUs

2023-06-24T13:00:00+02:00

Buildsysteme wie CMake, XMake oder CONAN sorgen unter anderem auch dafür, dass die Builds so schnell wie möglich durchlaufen.
Und auf unseren heutigen Multikern-CPUs bedeutet das, dass sie so viele CPU Kerne wie möglich parallel einsetzen.

Problematisch wird es nur, wenn das eben “zu viel” ist.

Neulich in der Firma …

Plötzlich schlägt eine Vielzahl an Builds fehl. Der MSVC meldet

Internal compiler errors

und der GCC schreibt:

Out of memory: Kill process (cc1plus)

auf die Konsole.

Die Meldung kannte ich, sie deutete darauf hin, dass ein Compilerprozess vom System terminiert wurde und dahinter steckt oft fehlender RAM (bzw. fehlender virtueller Speicher im Allgemeinen).

Bei der Meldung des Problems an die Buildserver Admins kam zurück, dass wir zu viele Kerne parallel nutzen und das herunter limitieren sollen.

Und das hat mir dann die Woche versaut …

Rechenformeln

Für mich zählte die alte Formeln: RAM = CPU-cores * 2GB
(Das absolute Minimum wäre RAM = CPU-cores * 1GB) Wird sie eingehalten, kann jeder Kern einen Compiler-Prozess erhalten und parallel daran werkeln.

Beim Raspberry PI 2 mit 4 Kernen und 1 GB wird die Regel verletzt, weshalb mir dort öfter der Build abbricht. Vor allem wenn Monster wie BOOST oder SQLite gebaut werden sollen.

Von einem offiziellen Buildserver in der Cloud erwarte ich allerdings, dass diese einfachen Regeln eingehalten werden, denn unser benutztes CONAN ermittelt die Anzahl der CPUs und startet dann eben genau so viele Prozesse wie möglich.

Nun wurde uns aber mitgeteilt, dass im Hintergrund Kubernetes für die Ressourcenverwaltung eingesetzt wird und dieses unsere Dockersitzungen verwaltet. Hier wird dann im virtualisierten Container die reale Anzahl an Kernen des Hosts ausgegeben, nur der nutzbare RAM wurde auf 16 GB reduziert. Das bedeutet laut Formel, dass man nur 8 Kerne und damit 8 Compilerjobs parallel nutzen sollte, CONAN ermittelte jedoch 32 Kerne und überforderte somit das System.

Workarounds als Lösung

Nachdem mir mitgeteilt wurde, dass es nicht möglich sei die aufgezählten CPU-Kerne im virtualisierten OS herunterzusetzen, blieb mir nur der Ausweg eine Methode zu finden, wie man CONAN dazu bringt weniger parallele Jobs zu starten.

Zum Glück wurde mit CONAN_CPU_COUNT bereits eine Umgebungsvariable eingeführt, mit der man exakt definieren kann, wie viele CPUs und damit parallele Jobs ausgeführt werden sollen.

Alternativ kann man auch in conanfile.py beeinflussen, damit nicht automatisch ein -j N an CMake geschickt wird, und anschließend lässt sich ein zusätzlicher Kommandozeilenparameter an CMake senden, der die gewünschte Anzahl an Jobs erzeugt.
Das sieht dann etwa so aus:

1def build(self):
2  job_count = 4
3  cmake = CMake(self)
4  cmake.configure()
5  cmake.parallel = False
6  cmake.build(args=["-j", str(job_count)])

Hartkodierte Limits sind falsch!

Jetzt kann man zwar mit CONAN_CPU_COUNT=8 das Limit hart setzen, womit der Build auf genau diesem Server läuft. Soll der Build aber auch auf anderen Servern laufen, kommt es dort sofort zu Problemen, wenn dieser mit weniger CPUs und RAM ausgestattet ist. Und genau das passierte auch bei uns.

Am Ende wurde eine neue Variable auf den Buildserven etabliert, die die maximal nutzbare Anzahl an CPUs definiert. Die Idee war, dass wir diese Variable dann im CI-Script an CONAN_CPU_COUNT zuweisen.
Auch dieser Schritt führte wieder ein Problem ein, nämlich dass CONAN den Dienst verweigerte, wenn diese externe Variable nicht definiert war. Dann wurde nämlich CONAN_CPU_COUNT auf einen Leerstring gesetzt, was zum Abbruch wegen einer Fehlkonfiguration führte.

Und der wahre Hintergrund war:

Tatsächlich war das Problem auf die Umstellung von CGROUPS v1 auf CGROUPS v2 zurückzuführen, die auf den Kubernetes Servern durchgeführt wurde.
Und wir nutzen die CONAN Version 1.50, welche nur CGROUPS v1 unterstützt.

Das Geheimnis liegt in cpu.py, welches bis v1.50 die beiden Pfade
/sys/fs/cgroup/cpu/cpu.cfs_quota_us und
/sys/fs/cgroup/cpu/cpu.cfs_period_us auslas und das CPU-Limit daraus errechnete, was nur unter CGROUPS v1 funktioniert.

Neuere Versionen von CONAN testen zuerst die CGROUPS v2 Pfade
/sys/fs/cgroup/cgroup.controllers und
/sys/fs/cgroup/cpu.max bevor sie auf die beiden V1 Pfade zurückgreifen.

Tja … nur leider lässt sich das Build-Image erst wieder mit dem nächsten größeren Software-Release auf CONAN 1.51+ upgraden.

Somit bleibt leider vorerst nur der hässliche Workaround mit CONAN_CPU_COUNT.

Fazit

Ich kotz’ gleich im Strahl …

Buildsysteme sollen ihre Umgebung korrekt erkennen können und sich darauf best-möglich einrichten. Und Hostsysteme sollen ihren Containern von außen nur die Ressourcen anzeigen, die sie nutzen dürfen.

Ich verstehe nicht, warum mit CGROUPS v2 die Kompatibilität der sysfs Pfade gebrochen wird, und ich verstehe auch nicht, warum Docker überhaupt erst die reale CPU-Anzahl an Prozesse im Container zurückliefert.

In jedem Fall hat diese unnötige Panne unzählige Stunden gekostet und wird in Zukunft noch weitere Zeit einnehmen.

Ich für meinen Teil habe daraus allerdings gelernt, dass Docker ganz unschöne Seiteneffekte produzieren kann, denn auch meine Codes würden nicht im sysfs nach Dateien suchen, wenn sie die CPU-Anzahl wissen wollen.

Und ganz nebenbei:

Auf meinem Azure Buildserver läuft eine VM mit einer CPU und 512 MB RAM. Eigentlich würden darauf alle Builds fehlschlagen, doch ich habe dort den Swapspace aktiviert. Und schon führt die Verletzung der obigen Formel nicht mehr zum Crash, es dauert nur länger, wenn die Platte rattert.

Soll heißen: Man kann die CPU/RAM/Job Überlastung auch noch anders abfangen.

Laptop mit FreeDOS

2023-06-18T13:00:00+02:00

PCs und Laptops dürfen nicht ohne OS verkauft werden.

So steht das irgendwo.
Und eben deshalb werden auch heute noch Computer mit FreeDOS verkauft.

2005 erwarb ich erstmals einen verbilligten Laptop, der kein Windows, kein Linux, sondern nur DOS installiert hatte.

Dass ich heute im Jahr 2023 wieder auf so ein Gerät stoße, verwunderte mich sehr … denn heutige PCs und Laptops unterstützen den Boot von 32 bit Software eigentlich gar nicht mehr.

Wie soll das also funktionieren?

FreeDOS am X86-64 Laptop

Nach dem Einschalten des HP Laptops erscheint ein Boot Menü, das entweder zu FreeDOS oder zum “Handbuch” umleitet.

Und tatsächlich scheint dann ein FreeDOS zu starten. Warum es sich dabei um eine veraltete Version aus dem Jahr 2006 handelt, erschließt sich mir nicht, denn inzwischen ist v1.3 verfügbar.

Doch außer den Standard-DOS Programmen findet man nichts, womit man arbeiten könnte.

Betriebsanleitung in Browserform

Parallel dazu startet der zweite Eintrag im Bootmenü einen Browser im Vollbild und lässt einen per Maus über Links zu den einzelnen Seiten des Benutzerhandbuches wechseln.

Man hätte auch sagen können: Eine Art PDF-Viewer. Menüs und andere Funktionen konnte ich dort auf die Schnelle nicht entdecken.

Verstecktes Linux

Gelegentlich blitzte beim Starten (egal ob DOS oder Handbuch) dann die Wahrheit durch:
Im Hintergrund wird eine kleine Linux Installation gestartet, die FreeDOS offenbar im Emulator ausführt.

Und das ist auch die einzige Möglichkeit, die mir einfallen würde, um in vertretbarer Zeit DOS auf so einem Gerät auszuführen.

So lange PCs und Laptops mit dem EFI-CSM (Compatibility-Support-Module) ausgestattet waren, konnte man den X86-Prozessor wieder den Real-Mode zurückschalten und im Speicher das klassische BIOS ablegen, mit dem DOS dann die Hardware anspricht.

Das CSM war auch für ein 32-bit Windows notwendig, doch nachdem es heute kaum noch reine 32-bit Prozessoren gibt (die letzten waren alte Intel-Atoms “Z”) und auch Microsoft mit Windows 11 gar kein 32-bit System mehr liefert, entfällt diese Brücke in die 80er Jahr endgültig und es können nur noch Systeme gebootet werden, die native x64-EFI-Bootloader bereitstellen.

FreeDOS gehört nicht dazu.

Fazit

Es wäre ja interessant einen Emulator oder Hyper-Visor als reine EFI App zu schreiben und FreeDOS darüber ausführen zu lassen.
Doch so lange das nicht fertig ist, hat man das Ziel mit Linux am schnellsten erreicht.

Doch hiermit komme ich nicht klar:
Warum installiert man ein lauffähiges Linux um dann DOS anzuzeigen, mit dem man nichts machen kann?
Man hätte dann doch gleich eine rudimentäres Linux mit Kommandozeile einsetzen können und dort wäre ein Support für Netzwerk und Updates gleich inkludiert gewesen.

Naja … wieder so eine Dummheit aus der Vergangenheit. Nur weil man Nicht-Windows-System im Jahr 2005 mit FreeDOS herausbrachte, muss man dieses Verfahren doch nicht künstlich im Jahr 2023 immer noch am Leben erhalten …

Aber 15 Minuten später lief “mein” Windows 11 auf dem Gerät und alles war gut.

Luftfeuchtigkeit abbauen

2023-06-17T13:00:00+02:00

Dicke Luft hat man auch, wenn zu viel Wasser in ihr steckt, was gerne in alten Kellern passieren kann.

Und nachdem ich neulich wieder ein Video sah, wie man sich so einen Luftentfeuchter (auch Dehumidifier genannt) selber basteln kann, dachte ich: OK, das will ich auch!

Peltier Elemente heißen die kleinen Zauberdinger, die entweder aus Wärmeunterschieden Strom erzeugen, oder aus Strom Wärmeunterschiede herstellen. Fließt durch ein solches Element Strom, wird die eine Seite heiß und die andere kalt.

Aus diesem Prinzip entsteht die Idee, dass an der kalten Stelle die Wasseranteile der Luft kondensieren und dort langsam abtropfen. Man braucht also nur zwei Kühlkörper, die die Oberfläche vergrößern und zwei Ventilatoren, die die warme Luft auf der einen Seite zur Kühlung abführen und auf der anderen Seite Umgebungsluft durch den Kühlkörper strömen um dort das Wasser kondensieren zu lassen.

Idee

Die Plastik-Box, in der meine Waschmaschinen Waschmittel-Tabs verkauft werden, erschien mir passend, um am Deckel das Peltier Element mit den beiden Kühlkörpern anzubringen.

Die warme Seite zeigt nach oben, also außerhalb der Box um Wärme abzuleiten. Die kalte nach unten innerhalb der Box.

Durch Löcher in der Seitenwand soll Luft durch die Box strömen können. Und das kondensierte Wasser kann auf den Boden der Box abtropfen.

Auf zur Klebepistole

Ich hatte einige alte CPU und Chipset-Kühlkörper mit und ohne Lüfter herumliegen und von denen nahm ich mir zwei. Aus einer PVC-Platte schnitt ich mir eine Schablone heraus, die den äußeren Umriss des Peltier-Elements vergrößerte.
So konnte ich dann die Kühlkörper, die viel größer als das Peltier-Element waren fest mit der PVC-Schablone verkleben, die das Element in seiner Mitte umschloss.

Aus dem Deckel der Box schnitt ich dann nur die Größe des kleiner Kühlkörpers (oben) aus, verklebte den größeren Kühler mit dem größeren PVC-Teil unten. Hier musste ja mehr Klebefläche herhalten, damit es auch am Deckel befestigt blieb. Oben schob ich dann noch eine dünnere Kartonschablone um den oberen Kühler herum ein, um auch dessen Auflagefläche zu vergrößern und verklebte sie mit dem Deckel.

Nun saßen beiden Kühlkörper direkt am Peltier-Element anliegend in der Mitte umgeben von PVC und viel Klebstoff.

Das Kind in mir hatte viel Spaß mit der Kleberei. Aber so war die Sache auch in wenigen Minuten fertig.

Durchzug mit Ventilation

Damit genug Luft durch die Box durchfegen sollte, verschraubte ich einen weiteren kleinen PC-Lüfter an der Wand, wo ich zuvor ein Loch eingeschnitten hatte.

Hier zeigte sich wieder, dass auf dem dünnen Plastik Schrauben nicht die beste Lösung waren. Doch mit Klebstoff bei den Lüfterblättern herumzuwerken erschien mir genau so falsch.

Erster Testbetrieb

Jetzt wurden die Lüfter und das Element mit dem Labornetzteil verbunden und die Box damit eingeschaltet.

Das Element verhielt sich korrekt und die Rippen des unteren Kühlkörpers fingen langsam an keine Wassertröpfchen einzufangen.

Hier lag mein Fehler:
Ich hätte statt einem langen niedrigen Kühlkörper eher einen kürzeren höheren nutzen sollen.

Die kleinen Wassertropfen sollen sich schließlich zu größeren verbinden und dann abtropfen, doch auf den niedrigen Rippen können keinen besonders großen Tropfen entstehen.

Schieflage

Mein Workaround-Fix war nun, dass ich die Box an einer Seite aufsockelte, damit sie schief dastand.

Das hat ein wenig geholfen, dass die Tröpfchen zur Kannte wanderten, größer wurden und besser abtropften.

Hätte ich nochmals von vorne angefangen, wäre die Wahl auf einen anderen Kühler gefallen, doch so blieb ich bei dem, was ich bereits zusammengeklebt hatte.

Fazit

Nun… es sieht aus wie der Bastelversuch eines Kindes … aber aus eben solchen Erfahrungen lernt man.

Und funktional erfüllt das Teil zumindest die Minimalanforderungen und so war nach einiger Zeit auch der Boden der Box “bewässert”.

Für mich ist damit der Beweis erbracht, dass ich mit Müll und Schrott aus der Kiste, einem Peltier-Element und viele Klebstoff einen Luft-Entfeuchter bauen kann.
Und das geht fast schneller, als den Bestellprozess in einem Webshop abzuschließen … von der Wartezeit der Lieferung ganz zu schweigen.

Ziglang

2023-06-11T13:00:00+02:00

Vergesst RUST!

Die Programmiersprache ZIG (auch als ZIGlang bekannt) wäre die einzige Sprache, die vielleicht mal C ersetzen könnte … weil sie C beinhaltet.

Seit meiner ersten Bekanntschaft mit RUST, stelle ich mir häufiger die Frage, welche Techniken eine Sprache besser oder schlechter für Betriebssysteme geeignet sind.

C++ stellt für mich nach wie vor ein Optimum dar, da es vollständig auf C aufsetzt. Dennoch stehen Exceptions und RTTI als genutzte Features in der STL dem Ziel OSDev leider sehr im Wege.

An RUST hingegen stört mich sehr, dass es C als Fremdkörper behandelt und den zentralen Fehler vieler Sprachen wiederholt: Es bildet kein stabiles ABI ab und integriert das C-ABI nicht direkt sondern nur über foreign-function-calls.

Und dann entdeckte ich ZIG`.

Als Sprache ist ZIG für mich “leider” ähnlich wie RUST zur Visual-Basic Syntax zurückgerutscht und liest sich neben C Code schwer, weil alles verkehrt deklariert wird. Eine C Funktion wie

1int32_t foo(int32_t x, int32_t y) {
2  return x + y;
3}

sieht in ZIG so aus:

1pub fn foo(x: i32, y: i32) i32 {
2  return x + y;
3}

Konkret fehlt eigentlich nur der -> Pfeil zwischen Funktionsparameter und Return-Type, um aus der ZIG-Funktion eine RUST-Funktion zu machen.

In Summe kann ZIG auch um einiges weniger als RUST, es unterstützt keine Klassen, keine Traits und keine Polymorphismen für Objekte.

Doch ZIG kann etwas, woran andere Sprachen scheitern:

Es integriert einen C Compiler, kann selbst als C-Compiler auftreten und C-Code zusammen mit dem eigenen ZIG-Format in einem Programm zusammenfassen.

Diese Eigenschaft hatte bisher nur C++, ab nun gibt es Konkurrenz.

Hochsprache ohne Exceptions

Fehlerbehandlung ist ein großes Thema und Exception sind häufig der Grund warum C++ im Embedded, OS und Hardwarebereich verworfen wird. (Dabei vergisst man leider, dass man C++ auch ohne Exceptions nutzen kann!).

ZIG bietet mit seinen integrierten Optionals und Error-Typen ein Feature auf unterster Sprachebene an, was C++ erst mit C++17 durch std::optional und std::variant nachliefert und dort leider nicht so elegant geschrieben werden kann.

Zusätzlich dürfen ZIG-Pointer nicht NULL werden, an diese Stellen treten leere Optionals oder Error-Types. Man kann dann auf den Inhalt des Pointers gar nicht zugreifen, wenn man ihn nicht prüft oder den Error-Type per try oder catch behandelt.
Der Compiler lässt daher unsicheren Code (ähnlich wie in RUST) erst gar nicht entstehen.

Comptime vs. Makros

ZIG unterstützt keine Makros (außer man kompiliert reinen C Code). Als Alternative erlaubt einem die Sprache aber jede Funktion, Variable oder jeden Parameter als comptime zu markieren.
Das bedeutet, dass das Element schon zur Übersetzungszeit bekannt sein muss und der Code teilweise oder vollständig vom Compiler ausgeführt wird, womit eine neue Form der dynamischen Code-Generierung entstehen kann.

Vergleichbar ist dieses Feature noch am ehesten mit C++ constexpr, welches mit jedem neuen Sprachstandard tiefer in die Sprache vordringt.

Durch comptime lassen sich Typen auswerten und Generics-Features entwerfen, wie auch ganze Datenstrukturen während des Kompilierens zusammengesetzt werden können.

Kurz gesagt: Voll geil!

Fazit

ZIG ist für mich Neuland, jedoch eine Gegend, die ich gerne betrete. Ich weiß nicht, wie lange es dauern wird, bis ich ausreichend darüber weiß, doch jetzt muss ein Schritt nach dem anderen gesetzt werden.

Fall es möglich ist, würde ich gerne ZIG als weitere Anbindung neben C++ in mein GATE Projekt aufnehmen.
… aber ob das so leicht umsetzbar sein wird, das steht noch in den Sternen.

DOS WATCOM Stackoverflow

2023-06-10T13:00:00+02:00

Auf die Frage, warum meine Grafikdemo funktioniert und meine Commandline-Tools auf der DOS Plattform häufig crashen, gibt es eine Antwort:

Der Command Line Parser löst Stack-Overflows aus.

Aber warum?

Das beste am Umstieg von DOS auf Windows NT war, dass man bei Crashes nicht mehr dauernd den Reset-Knopf drücken musste. Ich nannte solche DOS Programme damals einfach: Schlecht programmiert.
Denn sie funktionierten und scheiterten abhängig vom verfügbaren konventionellen Arbeitsspeicher … und der war mit seinem 640 KB Maximum nicht gerade groß.

Als meine eigenen DOS Kompilate scheiterten, obwohl sie unter Windows und Linux durch alle Tests kamen, stürzte mich das fast in eine Krise. Denn was bringt mir die Portierung von Code auf die DOS Plattform, wenn dann am Ende nichts läuft?

Doch ein zufälliger Blick in die von Watcom generierten .map Dateien zeigten auf, dass nur 2 KB Stack im Programm reserviert werden. Und da am gleichen Datensegment auch noch andere Dinge wie globale Variablen liegen können führt es zwangsläufig zu Überschneidungen, wenn der Stack seine engen Grenzen sprengt.

Lösung: Stack vergrößern

Die notwendige Anpassung der Linkerflags war schnell gefunden, als ich wusste, wo das Problem herkam:
opt stack=32768 vergrößert den reservierten Stackbereich auf 32 KB, was im Endeffekt ausreichte.

In CMake hängt man das einfach an die Variable CMAKE_EXE_LINKER_FLAGSan:

1set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} opt stack=32768")

Fazit

Kleiner Fix, große Wirkung.

Da im GATE Projekt Strings bzw. Stringausschnitte nicht zwingend NUL- terminiert sind, müssen Inhalte vor der Übergabe an externe C-Funktionen (zB. Dateipfade) in einen Puffer kopiert werden, der dann mit einem \0 endet, und das passiert meist auf dem Stack, der somit schnell über 2K anwachsen kann.

Ich muss aber eingestehen, dass mir mit diesen Crashes vor Augen geführt wurde, dass einige Design-Entscheidungen nicht ideal für bestimmte Plattformen sind. Denn klassische DOS Anwendungen kamen mit wenigen Bytes auf dem Stack aus.

Ob gleich das Problem nun gelöst ist, werde ich im Hinterkopf mal durchdenken, ob ich nicht vielleicht ganz allgemein zu viel auf dem Stack arbeite.

WinCE Hardware

2023-06-04T13:00:00+02:00

Programme für Windows CE zu bauen ist und bleibt eines meiner Hobbies. Doch Hardware bekommt man für dieses OS nicht einfach so im Laden.

Doch zwei (Nicht-Smartphone-) Geräte mit diesem OS kann ich dennoch mein Eigen nennen.

WonderMedia Laptop

Vor etwas über 10 Jahren startete ich meine erste zaghafte Bestellung aus China. Damals gab es noch kein AliExpress, dafür aber einige schlecht zusammengeschusterte Webseiten mit Angeboten für Laptops und Tablets um die 100 Euro.

Als ich dort meine Bestellung in ein Webformular eintrug und per PayPal bezahlte, rechnete ich mit einer 50:50 Chance, dass mein Geld weg sein konnte, doch ich wollte eben unbedingt ein ARM Gerät mit Windows CE haben und war risikofreudig.

Und es ging gut aus:

Ein Laptop mit WM8650 CPU, 256 MB RAM, 4 GB FlashDrive und einem 7 Zoll LCD Screen kam einige Wochen später per Paketdienst in Wien an.

Die CPU ist mit 800 MHz getaktet und die Bildauflösung schafft 800 x 480 Pixel. Ein kleines Netzteil versorgte das Gerät mit 9V und ~1.5A mit Strom und der eingebaute Akku sorgte für ein bisschen “Freiheit” von der Steckdose.

Ins Netzwerk gelangte man über den 100 MBit LAN Anschluss an der Rückseite oder das integrierte WLAN-Modul. Allerdings war die WLAN-Verbindung mit dem Gerät immer so schlecht, dass ich sie nie produktiv nutzte und immer ein Kabel anschloss.

3 USB Ports (2 rechts, einer hinten) erlaubten den Anschluss von Maus, Tastatur und weiteren Speichermedien.

Während das integrierte Keyboard zwar sehr klein aber dennoch “nutzbar” war, ist eine separate Maus ein absolutes Muss für diesen Laptop. Das integrierte Touchpad gleicht einem Zufallsgenerator, der willkürlich Berührungen ignoriert und dann doch wieder weitergibt. Auch die beiden unsensiblen Maustasten verdienen ihren Namen nicht.

Mit Windows CE 6.0 war dieses Gerät mein erstes vollwertiges CE-Windows, mit dem ich selbstgeschriebene Programme testen konnte. Auf meinen Windows Mobile Telefonen war das theoretisch zwar auch möglich, doch wegen der unguten Bedienung verlor ich stets die Lust nach wenigen Minuten.

Trotz der an Windows 98 angelehnten Oberfläche reichten die 800 MHz der CPU nicht im entferntesten an die Performance eines Intel Pentium mit 300 MHz Ende der 90er heran. Die Bedienung wirkte schwerfällig und so wundert es mich nicht, dass dieses Gerät keine guten Kritiken erhielt und schnell wieder verschwand.

Für mich war es jedoch die perfekte Gelegenheit, Windows-CE mal live auszuprobieren um mit seinen Eigenheiten jenseits von Smartphones vertraut zu werden.

GPS Navi fürs Auto

Vor 2 Jahren fiel mir eines der letzten mit Windows-CE betriebenen Geräte auf, und zwar ein GPS-Navi fürs Auto auf AliExpress.

Solche Modelle gibt es bis heute auf der China-Plattform als billige Navis und Video-Abspieler und sie alle bauen offenbar auf einem alten modifizierten Windows CE 6.0 auf.
Mein Gerät startet ein eigenes UI, dass man aber beenden kann und dann in der normalen Windows-CE-Desktop-Shell landet.

Die Preise variieren von 40 bis 100 Euro je nach Ausstattung.
Und somit leistete ich mir auch eines dieses Billigteile.

Viel Informationen erhält man leider nicht über die verbaute Hardware, aber ich weiß zumindest, dass ich mit 128 MB RAM auf einem 5 Zoll Screen arbeiten kann. Ein einziger USB-Port versorgt das Gerät mit Strom (im Auto über den Zigarettenanzünder) und dieser zieht laut Messung nur 350 Milliampere bei 5V.

Mit der Außenwelt kann das Gerät nur über die Touchscreen kommunizieren. WLAN oder LAN-Anschlüsse fehlen, was bei einem Gerät fürs Auto auch OK ist.

Mitgeliefert wurde auch eine eingelegte SD Karte, auf der offenbar die Navigationskartendaten abgelegt sind, wie auch einige andere Strukturen für den enthaltenen MP3- und Video-Player.

Über den USB Port kann das Navi auch mit dem PC verbunden werden, wo es sich als zwei Laufwerke meldet. Ein Laufwerk stellt den leeren internen Flash Speicher dar, das zweite bildet die eingesteckte SD-Karte ab.
Alternativ kann man die USB-Verbindung auch per Einstellung für das alte ActiveSync Protokoll zur Wartung und Installation von Software nutzen.

Das Navi kann zwar bei weitem nicht so flexibel eingesetzt werden wie der Laptop, aber im Notfall ist es eben auch ein typisches Windows-CE Gerät, dass dafür entwickelte Software hosten kann.

Fazit

Für den Laptop hatte auch einmal ein angepasstes Arch-Linux gefunden, das von der SD-Karte gebootet werden konnte. Es ist also auch möglich, das Gerät auf Linux umzustellen, doch das vermag aus der Hardware auch nicht mehr herauszuholen. Ich erinnere mich auch dort an eine extrem zähe UI-Erfahrung, die dem Alltag nicht gerecht wird.

Und so bleiben meine beiden WinCE-Geräte eben WinCE-Geräte und verifizieren, dass Software, die im Emulator lief, auch in der realen Welt lauffähig ist.

Da diese Hardware heute nicht mehr produziert wird, bin ich froh sie noch rechtzeitig gekauft zu haben. Und obwohl es sich um keine Rennpferde handelt bin ich dennoch beeindruckt, wie das ganze OS fix im RAM laufend mit so wenig Ressourcen auskommt und dennoch ein vollständiges Windows UI darstellen kann.

Nachtrag:

Und wie mein Laptop von Innen aussieht, hat bereits jemand auf YouTube ausgebreitet:

DIY: Crimp

2023-06-03T13:00:00+02:00

So manches Board hat Anschlüsse für diverse Leiterplattensteckverbinder für die Stromzufuhr oder eine serielle Verbindung, doch es gibt kein Gegenstück, das da reinpasst.

An der Stelle muss man zur Crimpzange greifen und sich für die nötige Sockelgröße den richtigen Stecker selbst hinbiegen.

Als ich mir damals vor 4 Jahren die Box mit den Steckkontakten zugelegt hatte, dachte ich noch, ich könnte das mit meiner Adernendhülsenzange hinmurxen. Im Endeffekt habe ich aber nur einige Stücke so verhundst, dass ich sie wegwerfen musste.

Man braucht also eine ordentliche Crimpzange, die mechanisch einrastet, damit man die kleinen Hülsen einspannen kann, um die Ader einführen und fixieren zu können.

Die Rundhülsen, haben an einer Seite zwei Krallenstückpaare, die beim Crimpen die Ader und die Isolation festhalten.
Auf der anderen Seite befindet sich neben dem Pin-Kontakt ein kleiner Zinken, der in dem Plastikstecker einrasten soll.

Die Kunst ist es also, die Hülse so in die Crimpzange einzuspannen, dass nur die beiden Krallen umgebogen werden und das untere Steckteil unverändert bleibt.

Hat man die Hülse korrekt in der Zange, muss nun die Ader genau so tief eingeführt werden, dass die äußere Kralle die Isolierung zu fassen bekommt und die innere Kralle mit den Litzen in Berührung kommt.
Stopft man die Ader zu tief hinein, stören die Litzen den Pin-Kontakt.
Hier gilt:

Übung macht den Meister … und mir fehlt noch viel Übung.

Doch nach ein paar Versuchen hat man zumindest eine brauchbare Verbindung zwischen Ader und Hülse.
Und somit kann diese in den Stecker eingefügt werden.

Sobald der keine Widerhaken am Ende eingerastet ist, sollte der Stecker einigermaßen zugfest sitzen und kann als Stecker seinen Dienst aufnehmen.

Fazit

Nachdem der Akku meines alten Windows-CE Laptops schon vor Jahren kaputtgegangen ist und seither das Board einen unguten Pfeifton abgibt, wenn kein Akku angeschlossen ist, wollte ich mal probieren, ob man den Lademechanismus durch einen Widerstand “zähmen” kann.

Und eben genau dafür brauchte ich nach langem wieder mal einen solche Platinensteckverbindung.

Früher hatte ich extra dafür Stecker und Kabel von Elektroschrott abgetrennt. Doch es ist wesentlich “eleganter”, wenn man sich seinen Stecker selbst zusammenbaut.

Die Box mit je 10 mal 2 bis 5 Pin-Steckern kostete damals in Fernost nur wenige Euro. Heute wird das wohl mehr sein, ist aber immer noch günstig, denn man kann so eine Vielzahl an Steckern herstellen.

getaddrinfo

2023-05-28T13:00:00+02:00

Die Funktion getaddrinfo() löst Funktionen wie gethostbyname() oder gethostbyaddr() ab und ist quasi “die” Schnittstelle zur DNS Auflösung eines Systems im Netzwerk.

Blöd nur, dass Windows 95 davon nichts wusste…

Fehlkonstruktion gethostbyname

gethostbyname() ist auch eine von diesen dummen Funktionen, die C Programmen ihren schlechten Ruf beschert hat. Hier wird nämlich das Ergebnis in einen Puffer im Hintergrund geschrieben, den man nicht unter Kontrolle hat.
Im schlimmsten Fall ist es ein globaler Puffer, was bedeutet, dass nicht zwei Threads die Funktion nicht gleichzeitig benutzen dürfen.

Das kann man jetzt gerne über einen Mutex lösen, durch niemand weiß, ob nicht eine Fremdbibliothek ebenso die Funktion aufruft und dort ohne Mutex den Puffer bearbeitet.

getaddrinfo() ist die flexibler Nachfolger-Funktion und allokiert separaten Speicher für jeden Aufruf. Außerdem erlaubt sie wesentlich mehr Optionen für die Hostnamen-Auflösung.

Warum als nicht immer getaddrinfo?

Tja, heute kein Thema. Jedes OS hat die Funktion integriert. Doch meine (Support-)Welt beginnt in den 90ern, wo getaddrinfo weder in Windows noch in den damaligen Unix-Derivaten garantiert vorhanden war.

Aus diesem Grund findet man in meinen älteren Projekten nur Mutex-geschützte gethostbyname Aufrufe.

Unter Windows wurde getaddrinfo() mit Windows XP in die ws2_32.dll integriert. Windows 2000 und ältere Vertreter meldeten somit immer einen fehlenden Einsprungpunkt, wenn man sein Projekt gegen die Funktion linken ließ.

Es gibt zwar den dokumentierten Verweis zur inline Funktion WspiapiGetAddrInfo, die getaddrinfo dann über andere DLLs zu laden versucht, doch auch die sind nur unter Windows 2000 mit bestimmten Preview-Updates vorhanden und nicht in Standard-Installationen.
Windows 9x fällt übrigens generell flach bei dem Thema.

Fazit

Heute baue ich in der Regel auf ein dynamisch geladenes getaddrinfo().

Ist die Funktion im OS enthalten (also LoadLibrary("ws2_32") oder dlopen(NULL, RTLD_GLOBAL)), wird sie benutzt.
Wenn nicht, dann implementiere ich sie mit gethostbyname provisorisch inklusive Mutex nach.

Auf diese Weise kommen Binaries heraus, die überall gestartet werden können und dann eben das heranziehen, was vorhanden ist.

Windows 2000 Update

2023-05-27T13:00:00+02:00

Dass man Windows 2000 auch noch mit dem aktuellen Windows Server Update Service (WSUS) aktualisieren kann, hatte ich aus der Auflistung des Betriebssystems im WSUS-Menü erschlossen.

Korrekt funktioniert hatte das dann aber nicht, sondern brach ab.

Tatsächlich liegt die Lösung nahe … wenn man sie kennt.

Das einzige was Microsoft heute wirklich noch ein Alleinstellungsmerkmal beschert, ist sein langer Support und die meist vorhandene Abwärtskompatibilität.
Soll heißen:

Was gestern funktioniert hat, soll auch morgen noch funktionieren.

In Sachen Windows-Updates endet das Vergnügen meist nach dem Extended-Support nach 10 Jahren. Doch wer sich einen Windows Server leistet bekommt WSUS gratis dazu, und der synchronisiert sich dann mit den MS-Fileservern, wo Updates für alle Ewigkeiten liegenbleiben … zumindest seit Windows 2000.

Der erste Updateversuch eines älteren OS streikt meist und man muss manuell einen neueren Windows Update Agent einspielen, doch danach finden Windows 7 und 8 brav wieder ihre Aktualisierungen.

Bei Windows XP und Windows 2000 ist das nun aber leider nicht mehr so. Bei XP fiel mir das nicht auf, weil ich ein aktualisiertes Image von 2020 nutze, in dem alles korrekt integriert war, aber meine Windows 2000 ISOs verweilten auf dem Stand von 2010 und da rührte sich nichts mehr.

Jedenfalls benötigte ich für Windows 2000 die Version 6.1.22.4 des Agents (WindowsUpdateAgent30-x86.exe), denn die neueren Varianten verweigerten bei der Erstinstallation die Durchführung des Setups.

Man kann zwar per Registry manuell die Policy zum eigenen WSUS Server setzen:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate
- WUServer = http://my-wsus.domain:8530 (string)
- WUStatusServer = http://my-wsus.domain:8530 (string)
- ElevateNonAdmins = 0x00000001 (DWORD)
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU
- UseWUServer = 0x00000001 (DWORD)

Und danach meldet sich der Dienst sogar beim WSUS an (wird also in der UI als Client sichtbar), kann aber keine Daten mit ihm austauschen.
Den Fehler findet man im Update-Agent Log
C:\WINNT\SoftwareDistribution\ReportingEvents.log

800b0109 SelfUpdate Failure Software Synchronization Windows Update Client failed to detect with error 0x800b0109.

Das Problem liegt an den Root-Zertifikaten die der Verifizierung dienen. Die sind nämlich schon lange abgelaufen und somit ist keine Aktualisierung mehr möglich.

Lösung: Neue Zertifikate einspielen

Was für ein Glück, dass sich ein paar findige Leute im Netz die Mühe gemacht haben und die notwendigen Zertifikatsteile zusammengesucht und erneuert haben. Diese sind auf github.com/JohnTHaller veröffentlicht und müssen am Zielsystem nur noch importiert werden. Also mmc.exe ← Snap-in Certificates ← Computer Account ←
Trusted Root Certification Authorities/Certificates öffnen und die beiden .sst Dateien importieren.

Am Ende wird noch am besten der Update Dienst beendet. Und ein wuauclt /detectnow beginnt nun mit den neuen Zertifikaten mit der WSUS-Kommunikation und dem Self-Update.

Kurze Zeit später poppt auch schon das Update-Symbol in der Taskleiste auf und dann ist die Welt wieder in Ordnung.

Falls das nicht sofort funktioniert, helfen die Kommandos

wuauclt /resetauthentication
wuauclt /reportnow
und auch das Löschen des Ordners c:\WINNT\SoftwareDistribution bei beendetem Update-Dienst kann helfen, damit sich alles neue einrichtet.

Vorsicht: Update-Rollup Bluescreens!

Nach dem SP4 kamen für Windows 2000 noch über 100 weitere Updates heraus, die sich alle per WSUS einspielen lassen. Darunter ist auch das Update KB891861 mit dem Titel
“Update Rollup 1 for Windows 2000 Service Pack 4”. Diese Teil zerstörte mir jede Installation, nachdem es einen Reboot-Bluescreen Zyklus eingerichtet hatte.

Aus eben diesem Grund habe ich das Update KB891861 in WSUS auf “Declined” gesetzt, damit ich es hoffentlich nie wieder sehen muss.

Fazit

Zertifikate hatten für mich immer schon den Nachteil, dass sie ablaufen (und ja ich weiß … das sollte eigentlich ein Vorteil sein).

Denn egal wo man hinkommt, man findet immer nur Software-Scherbenhaufen vor, wenn eine Firma oder ein Projekt aufgegeben wird und keiner mehr neue Zertifikate für die Software anlegen will/kann/darf.

Was meine “Windows-Kindheit” anbelangt freue ich mich, dass es zumindest noch per Workaround eine Möglichkeit gibt, die Zertifikate zu aktualisieren und danach das OS auf den bestmöglichen Letztstand zu bringen.

Ich hoffe, dass diese Möglichkeit noch einige Jahre bestehen bleibt, aber nachdem Windows Server 2022 das Windows 2000 Produkt immer noch im WSUS listet, erwarte ich, dass zumindest bis zum Ende des Standard-Supports so bleiben wird.

Zumindest kann ich nun wieder behaupten, “ein aktuelles Windows 2000” in Betrieb genommen zu haben.

Mutters Reise zum Rudolfsturm

2023-05-21T13:00:00+02:00

In den letzten Jahren wandere ich gerne zu “Orten meiner Vergangenheit”, wo ich vor 10 bis 15 Jahren wohnte oder arbeitete.

Dieses Wochenende durfte ich miterleben, wie es ist nach 50 Jahren einen bekannten Ort wieder zu erleben.
Ich durfte Einblick nehmen, wo meine Mutter einen Teil ihrer Jugend verbrachte.

Durch ein Ferialjob verschlug es meine Mutter vor 50 Jahren nach Hallstatt in den Gastbetrieb am Rudolfsturm. Und seit vielen Jahren hörte ich sie von dieser schönen Jugenderfahrung schwärmen.
Es wurde also höchste Zeit, dass wir dem Turm am Berg hoch über dem Hallstätter See einen Besuch abstatten.

Als Reisemuffel fürchtete ich vor allem die Anfahrt mit dem Auto und mein Talent mich heillos zu verfahren. Doch wenn man es auf die A1 schafft (und zu der findet man in Niederösterreich immer), dann kann man die Abfahrt bei Regau nach Gmunden, Bad Ischl, Bad Goisern und Hallstatt eigentlich gar nicht verfehlen.
Und so gelang die Anreise zielgenau auf Anhieb und ohne Einsatz eines Navigationsgerätes oder Smartphones (und auf so etwas bin ich heutzutage stolz!).

Der geplante Kurzurlaub sollte nur zwei Tage (also eine Übernachtung) dauern. Eine wirklich preiswerte und schöne Unterkunft fanden wir Bad Goisern, das nur wenige Kilometer vor Hallstatt entfernt liegt.

Auf nach Bad Goisern und Hallstatt

Als wir uns nach dem Mittagessen in Bad Goisern gleich zum Ziel aufmachten, konnten wir live miterleben wie unglaublich überlaufen Hallstatt inzwischen ist. Alle großen Parkplätze war voll und gesperrt. Nur gelegentlich wenn andere Touristen aufbrachen und ein Stellplatz frei wurde, öffnete sich kurz die Pforte um den einen freien Platz gleich wieder auszufüllen.

Das Gerücht: “Hallstatt sei in Asien bliebt” ist eine Untertreibung.
Man hatte eher den Eindruck: “In China kann es jetzt keine Chinesen mehr geben”. Tatsächlich waren die Straßen und Gassen voll mit Touristen aus Asien und jede halbe Stunde kam ein neuer Bus an, der weitere Besucher brachte. Doch eines steht auch fest: So fließt jede Menge Geld in die kleine Stadt.

Mutter erkannte den Ort Hallstatt kaum wieder, da (wie in solchen Touristenhochburgen üblich) ein Souveniergeschäft dem anderen folgte. Das war vor 50 Jahren noch ganz anders.

Doch in einer hinteren Seitengasse trafen wir dann auf zwei einheimische ältere Damen und ich konnte mitverfolgen, wie Mutter im Gespräch mit den beiden wieder jung wurde.
Ja … vieles hat sich verändert seit damals und aus der keinen Dorfgemeinschaft wurde ein Tourismuszentrum. Doch auch wenn die Anwohner den extremen Ansturm nicht immer genießen, so haben sie besonders in der Pandemie festgestellt, wie wichtig dieser Zustrom ist und folglich schätzen sie die Gäste auch.

Stets im Blickfeld war die Bergbahn, die zum Rudolfsturm führte, doch diesen wollten wir erst am zweiten Tag besuchen.
So streiften wir noch kurz durch die Straßen und machten uns am Abend auf zur Herberge, wo wir mit Blick auf die umgebenden Berge am Balkon über das Gesehene diskutierten.

Der Rudolfsturm

Nach einem köstlichen Frühstück um 8:00 fuhren wir sogleich von Bad Goisern nach Hallstatt um pünktlich um 9:00 Uhr bei der ersten Bergfahrt dabei zu sein. Die Strategie war gut, denn am Morgen waren noch die Hälfte der Parkplätze frei.

Mutter erzählte von einer Seilbahn mit 4 Plätzen, die permanent gegengleich zwei Kabinen zwischen Berg und Tal hin und herbewegte. Täglich musste sie so mit anderen Dienstmädchen Verpflegung zum hoch gelegenen Rudolfsturm bringen.

Heute fahren zwei Bergbahn-Gondeln auf Schienen den gleichen Weg, können aber wesentlich mehr Personen transportieren. Es finden etwa 15 Personen darin Platz und alle 15 Minuten beginnt eine neue Fahrt.

Direkt neben der Bergbahnstation liegt auch der Rudolfsturm, doch diesen hoben wir uns fürs Mittagessen auf.

Wir folgten dem Wanderweg bergauf, der zur Salzmine führte. Im dortigen Haus (damals als Salinenhaus bekannt) war nämlich das Personal des Rudolfturms untergebracht und so gingen wir genau den Weg entlang, den Mutter mit ihren Kolleginnen täglich hin und herlaufen mussten.
Man merkt, dass die steile Strecke im Alter anstrengender ist … doch die Umgebung mit den blühenden Wiesen und der kühlen Bergluft machten diesen Spaziergang zu einem schönen Nostalgieerlebnis.

Beim Salinenhaus angekommen rasteten wir auf einer der Bänke. Und während andere Touristen in die Salzmine drängten, erfuhr ich manch lustige Geschichte von damals, als diese Gegend nur von einigen Arbeitern aufgesucht wurde.

Beim Rückweg zum Rudolfsturm trafen wir dann unverhofft auf das Highlight des Tages: Einen Archäologen.
Der “Kerl” war mit seinem Team in einem der dort angrenzenden Häusern untergebracht und in einem zufällig gestarteten Gespräch, erzählte er uns, wie er mit seinen Kollegen Grabungen vornahm und welche Schätze im reichen Ort Hallstatt bereits gefunden wurden.

Es war beeindruckend einem Fachmann gegenüberzustehen, dem man die Bewunderung für die Hallstätter Kultur und deren Geschichte in jedem Satz anmerken konnte. Und es ist auch beeindruckend zu erfahren, wie bereits Menschen in der Steinzeit die Orte bewohnten und bebauten, die wir heute zur Sommerfrische nutzen.

Pünktlich zur Mittagszeit waren wir wieder zurück beim Rudolfsturm und nachdem Mutter damals unzählige Gäste dort hatte bewirten dürfen, so wurden wir an diesem Tag ebenso hervorragend verköstigt.

Mutter bemerkte schnell, dass dem Turm ein Gebäudeteil fehlte und so fanden wir im Internet den Bericht, dass um 2007 der hintere Teil unter Schneedruck eingestürzt war und das Anwesen umgebaut wurde. Die heutige hintere offene Terrasse, auf der wir zu Tisch saßen war früher ein geschlossener Speisesaal.

Ein besonderes Highlight war außerdem, dass wir die Erlaubnis erhielten, kurz einen Blick in die oberen Räume werfen zu dürfen.
Damals waren dort Gästezimmer für Besucher vorhanden, heute sind diese offen und eine Erweiterung des Gastronomiebereiches.

Die Möblierung hat sich vollständig geändert … und doch sind einige Teile wie die Holzverkleidung an den Wänden und Ecken offenbar noch im Original erhalten.

Eine schöne Erinnerung

Zu meinen größten Freuden dieses Jahr wird ganz bestimmt dieser Besuch in Hallstatt zählen, denn ich habe meine Mutter schon lange nicht mehr so “jung” lachen gesehen.
Ich konnte in ihren Augen sehen, wie wichtig solche Fixpunkte im Leben sind und wie unglaublich schön es ist, wenn solche alte Erinnerungen wieder lebendig werden.

Aus einem:

Naja, warum nicht mal dorthin, wo du früher schon mal warst.

wurde unerwartet ein Besuch einer der schönsten Flecken unseres Landes und gleichzeitig eine Erinnerung voller Freuden, die ich selbst zwar nicht erlebt habe, aber trotzdem habe ich sie nun gespürt.

Die Heimreise wurde bereichert von einem sonnigen Panorama zwischen Ober- und Niederöstereich und wurde untermalt von einem langen Gespräch über Gott, die Welt, Liebe und Leben … und der schönen Zeit in Hallstatt.

Fazit

Auslöser für diese Reise war eine Mappe mit Erinnerungsfotos und Zeichnungen, die meine Mutter vor 50 Jahren angelegt hat.
Diese Mappe lag die ganze Zeit in einer Lade im Wohnzimmer.

Und vor einigen Wochen, als sie zufällig geöffnet wurde, bildete sie plötzlich einen Anker in die Vergangenheit, die Mutter und mich an diesen Ort und in diese Zeit zurückgeführt hat.

Ich habe daraus gelernt, dass es solche “kleinen Dinge” sind, die später eine ungeahnt große Wirkung haben können. Ein “gutes Foto” kann die Erinnerungen an einen Ort, ein Ereignis, einen Freund aufleben lassen, auch wenn das Original inzwischen verblasst ist.

Wir hätten die teuersten Konzert- oder Theaterkarten haben können, im luxoriösesten Palast dinieren können … aber nichts wäre so schön gewesen, wie auf der Bergbank zu sitzen und einfach nur über die Vergangenheit zu reden.

Und am Ende war es ein Blatt Papier, das ein Portal in diese andere Zeit geöffnet hat, ganz ohne Technik, Kabel und Spezialeffekte.

Windows Downgrade

2023-05-14T13:00:00+02:00

Auf meinen Intel-Atom Boards fällt es mir leider ganz deutlich auf:

Man kann mit Windows 10 einfach nicht arbeiten … alles ist so verdammt langsam.

Doch … komisch … das war vor ein paar Jahren noch ganz anders.

Seit seinem ersten Release im Jahr 2015 hat sich Windows 10 ordentlich weiterentwickelt. Das betrifft auch seine Größe. Anfangs kam man mit einer 2,5 bis max. 3 GB install.wim aus, heute ist das auf 3,9 GB gestiegen und mit den letzten Updates kommt man auch schon über die magische 4 GB Grenze drüber (und muss die .wim aufsplitten).

Ein größeres OS bedeutet längere Ladezeiten, denn Standard-DLLs haben ebenso an Speck zugelegt. Neue Features, die automatisch aktiviert sind fressen ebenso Platz auf Disk und RAM auf.
Und genau das macht meine kleinen Intel-Atom Maschinen träge.

Windows 8 ?

Teilweise habe ich auch wieder die originalen Windows 8/8.1 Installationen ausprobiert, mit denen die Baytrail Boards von 2013 bis 2016 ausgeliefert wurden. Der größte Haken sind die inzwischen defekten Online-Tools wie die Mail-App, ein nicht mehr funktionierender Store und der nicht mehr korrekt laufende Windows-Update-Mechanismus.

Zwar kann man mit WSUS, Offline-Integration und viel Geduld ein Image teilweise hochpatchen, doch da z.B.: keine Zertifikatsupdates mehr durchgeführt werden, degeneriert das System leider mehr und mehr.

Lösung: Windows 10 Enterprise 1607

Als MSDN Abonnent bekommt man auch die Enterprise Versionen beigelegt, die einen relevanten Vorteil haben: Sie werden 10 Jahre voll unterstützt.
Soll heißen, das OS von 2016 bekommt bis 2026 garantiert Support und danach werden vermutlich die Updateserver auch noch (hoffentlich) etwas weiterlaufen.

Ein Nachteil sind fehlende Store-Apps … doch dafür kenne ich ja bereits eine Lösung.

Update Integration

Meine Vorgehensweise ist wie immer:

OS in VM installieren
Standard Windows Update durchführen
KB - Nummern der Updates heraussuchen und diese manuell herunterladen
Updates ins Windows .wim Installationsimage integrieren
Fertig

Natürlich funktioniert das nicht … denn Microsoft schafft es immer mit ihren “späten” Updates, den Integrationsprozess zu versauen.

Soll heißen: Von 5 großen Updates bricht das letzte (nämlich das Rollup 2023) ab und hinterlässt ein defektes Image.

Folglich habe ich eben dieses letzte Update nicht integriert sondern dem Setup-Image separat als .msu beigelegt.
Wird Windows installiert, muss man dieses letzte Update eben am Ende manuell ausführen.

Klingt komisch … ist aber so … und funktioniert dann auch.

Apps und Konfiguration

Windows Update holt am Ende noch die neuesten Defender-Updates und somit hat man ein halbwegs “gepatchtes” Windows, aber eben mit dem API Stand von 2016.

Einen weiteren Performance-Boost bekomme ich dann noch auf einigen Maschinen durch das Deaktivieren des Defender-Dienstes.
(Powershell: Uninstall-WindowsFeature Windows-Defender)

Das tue ich natürlich nur auf Geräten, die mit dem Internet nur spärlich in Berührung kommen, wie z.B.: auf einem alten Tablet, dass sich einfach über der Lötstation an die Wand genagelt habe.
Dort kann mir das Teil Pläne anzeigen, Widerstand-Farbringe aufschlüsseln oder Podcasts abspielen.

Auf solchen Geräten ist ein permanenter Scan der Dateien nach Viren nicht notwendig … und nachdem einige ältere Hardware bei mir solche Teiljobs im “gesicherten Wohnzimmer” ableistet, gestatte ich mir auf eben solchen Geräten die Entfernung einiger Web-Kondome.

Fazit

Ja … das ältere Windows ist schneller, braucht etwas weniger RAM und zuckelt nicht ewig herum, wenn man einfach nur den Explorer öffnen will.

Mein “gefühlter” Eindruck ist also weiter “gefühlt” richtig:

Man sollte Geräte mit dem OS-Stand betreiben, mit dem es ausgeliefert wurde.

Ein Windows 10 22H2 trägt de facto schon ein halbes Windows 11 in sich, dass laut Hardwareanforderungen auf alten Atom-System nicht lauffähig ist. Man kann also nur sagen: Windows funktioniert, aber “laufen” tut es nicht.

Mit dem alten Enterprise 1607 habe ich also für die nächsten 3 Jahre ein Image, mit dem

Kleinigkeiten erledigt werden können,
einige modernere Apps unterstützt sind,
und die Performance trotzdem noch akzeptabel ist.

Kurz gesagt: “Genau, was ich wollte.”

HAIKU, früher ZETA, früher BeOS

2023-05-13T13:00:00+02:00

Ich trauere einem Projekt der 90er sehr hinterher, nämlich dem alternativen Betriebssystem BeOS.

Da wir heute nur noch Windows und Unix Derivate im freien Feld finden (und gelegentlich mal ein RTOS auf ‘ner MCU), ist das kreative Potential bei der OS Entwicklung auf Null gefallen.

Da es um das Jahr 2000 noch kein Internet in meinen Breiten gab (oder nur ein nicht-leistbares), waren Beilage-CDs diverser Computer-Magazine, die einzige Möglichkeit an neue Software zu gelangen.
Neben gefühlt 1000 Varianten von Geld- und Terminplanern, wie diversen Office-Zusätzen erhielt man so primär auch noch Updates für die aktuellen Windows Versionen.

Nach und nach schaffte es dann auch noch Linux auf diese Weise publiziert zu werden, aber dann war auch schon Schluss.

Ein Perle habe ich jedoch neulich wieder gefunden, nämlich eine CD mit dem damals neuen Betriebssystem BeOS.

Das Multimedia-OS BeOS

Mir wurde BeOS von einem Schulkollegen damals so präsentiert:

Das ist wie Windows nur viel besser für Multimedia.

Obgleich ich das Attribut “besser” sofort anzweifelte, musste ich nach der ersten Test-Installation zugestehen, dass in mehreren Fenstern Videodateien abgespielt werden konnten, was unter Windows 98 “gerade mal so” möglich war auf der damaligen Pentium-1 Hardware.

BeOS ist ähnlich wie Windows ein primär grafisches Betriebssystem und optimiert daher seine Schnittstellen auf die Darstellung von UI Elementen. Es ist damit das genaue Gegenteil von Unix und Linux, die primär Datenströme verwalten und wo UIs erst als Beiwagen im Usermode nachgereicht wird.

Doch im Gegensatz von Windows zog BeOS auch schon damals nicht den fetten Rattenschwanz von DOS und Win3x Kompatibilität hinterher, sondern kümmerte sich nur um seine Kernkompetenz.

Da auch damals schon eine TCP/IP Anbindung ans Netz und Tools wie Mailclient und Browser dabei waren, sah es so aus, als könnte sich das neue OS tatsächlich gegen die bestehende Schar beweisen.

Eine Eigenschaft die heute als Nachteil ausgelegt wird, war die Single-User-Strategie. BeOS kannte keine Benutzeraccounts und verzichtete auf ein Berechtigungsmodell für Zugriffe auf Ressourcen und Dateien. Das macht das System natürlich (ähnlich wie DOS) schnell, verhinderte aber den Einsatz im Unternehmensbereich, wo unterschiedliche Nutzerprofile eine wichtige Anforderung darstellen.

C++ als Kernsprache

Damals war es revolutionär: BeOS nutzt C++ als Primärsprache, und nicht reines C. Während Windows und Linux bis heute auf C Funktionen als Schnittstellen aufsetzen, wählte BeOS den rein objektorientierten Ansatz und baute sein UI Framework nur auf C++ Klassen auf.

Daraus ergibt sich einerseits ein wesentlich eleganteres Codedesign, aber leider auch eine Abhängigkeit zum C++ ABI des eingesetzten Compilers. Somit war der Stand des GCC v2.x fix mit BeOS verdrahtet, was damals OK war, im Nachhinein aber Erweiterungen schwer machte.

Fazit

BeOS endete mit dem Ende des Unternehmens, welches es anfangs entwickelt hatte. Und da auch die Stärke einer Linux-Community fehlte, verschwand BeOS wieder von den Heft-CDs und geriet in Vergessenheit.

Ich erinnere mich, dass Anfang der 2000er noch Shopping-Kanäle im Kabelfernsehen den Nachfolger “Zeta-OS” zum Kauf anboten, was dem Ansehen meines Erachtens eher schadete.

Heute existiert zum Glück as HaikuOS Projekt, welches BeOS als Open Source Software nachbaut und bis heute aktiv ist.

Ich würde mir sehr wünschen, dass BeOS bzw. Haiku wieder zu den aktuellen Systemen aufschließt und somit eine Alternative zu unseren Windows und Linux-Monokulturen bereitstellt.

Das Schnittstellendesign ist gut obwohl bzw. weil es sich von der WinAPI und POSIX unterscheidet. Trotzdem existieren viele Portierung von POSIX APIs auf BeOS/Haiku, womit zahlreiche moderne Softwarepakte auch unter BeOS/Haiku angeboten werden können.

Also Leute: Nutzt BeOS!
Wir brauchen mehr Diversität im Betriebssystembereich!

Optionale V-Tables

2023-05-07T13:00:00+02:00

Microsoft führte vor langer Zeit mit __declspec(novtable) eine interessante Erweiterung in den MSVC ein, um dem Problem der aufgeblasenen COM DLLs zu begegnen.

Andere Compiler kennen und brauchen das nicht …
… außer man baut sich seine eigenen COM-artigen Objekte und deren V-Tables zusammen.

Selbst bei bester Optimierung fallen mir in den .map Dateien von Builds viele Funktionen auf, die in einem statische Programm nicht enthalten sein dürften.
Bei genauerem Hinsehen entpuppten sich Aufrufe dieser Funktionen als Teil von C-V-Table-Objekt-Methoden, die selbst nie benutzt wurden.

Besonders in watcom unter DOS ist das lästig, wenn mehrere Kilobytes an Code in der EXE landen, die gar nicht gebraucht werden.

V-Table Initialisierung

C Objekte sahen bei mir (ganz ähnlich zu COM) etwa so aus:

 1static int method_1_impl(void* self, int param);
 2static int method_2_impl(void* self, int param1, int param2);
 3
 4typedef struct 
 5{
 6  int (*method_1)(void* self, int param);
 7  int (*method_2)(void* self, int param1, int param2);
 8
 9} my_vtbl_t;
10
11static my_vtbl_t const my_vtbl = 
12{
13  &method_1_impl,
14  &method_2_impl
15}; /* init V-Table in global scope */
16
17typedef struct 
18{
19  my_vtbl_t const* vtbl;
20
21  int private_member_1;
22  int private_member_2;
23
24} my_object_t;
25
26my_object_t* my_object_constructor()
27{
28  my_object_t* obj = malloc(sizeof(my_object_t));
29
30  obj->vtbl = &my_vtbl;
31  obj->private_member_1 = 0;
32  obj->private_member_2 = 0;
33
34  return obj;
35}

Nachdem die statische my_vtbl Variable mit den beiden Methodenimplementierungen method_1_impl und method_2_impl initialisiert wurde, ist deren Code und Aufruf-Baum vollständig im Programm integriert, auch wenn my_object_constructor nicht aufgerufen wird.

Dieses Problem löste ich nun über einen neuen Ansatz der Initialisierung.

V-Table Konstruktor-Funktion

Anstatt die V-Table statisch initialisieren zu lassen, wird im Konstruktor geprüft, ob der anfangs ausgenullte Speicher schon befüllt ist.
Falls nicht, wird die V-Table auf dem Stack erzeugt und dann in die globale V-Table kopiert:

 1static int method_1_impl(void* self, int param);
 2static int method_2_impl(void* self, int param1, int param2);
 3
 4typedef struct 
 5{
 6  int (*method_1)(void* self, int param);
 7  int (*method_2)(void* self, int param1, int param2);
 8
 9} my_vtbl_t;
10
11static my_vtbl_t const my_vtbl = 
12{
13  &method_1_impl,
14  &method_2_impl
15};
16
17static void init_my_vtbl()
18{
19  if(my_vtbl.method_1 == NULL)
20  {
21    my_vtbl_t local_vtbl = 
22    {
23      &method_1_impl,
24      &method_2_impl
25    };
26    my_vtbl = local_vtbl;
27  }
28}
29
30typedef struct 
31{
32  my_vtbl_t const* vtbl;
33
34  int private_member_1;
35  int private_member_2;
36
37} my_object_t;
38
39my_object_t* my_object_constructor()
40{
41  my_object_t* obj = malloc(sizeof(my_object_t));
42
43  /* init V-Table in first constructor call: */
44  init_my_vtbl(); 
45  obj->vtbl = &my_vtbl;
46  obj->private_member_1 = 0;
47  obj->private_member_2 = 0;
48
49  return obj;
50}

Da die Verknüpfung der V-Table mit den Methoden jetzt in einer Funktion stattfindet und nicht mehr statisch auf globaler Ebene, schaffen es nun alle Compiler, den ganzen Aufrufbaum wegzuoptimieren, wenn my_object_constructor() nie aufgerufen wird.

Optimierungspotential

V-Tables kommen im GATE Projekt vor allem bei Streams und “Runnables” für Threads vor. Jeder Kompressionsalgorithmus ist als Encoder-/Decoder-Stream verfügbar und das bedeutet, dass automatisch immer alle einkompiliert werden, sobald gegen die gateencode Bibliothek gelinkt wird.

Tatsächlich hat sich hier aber keine große Optimierung ergeben, da ich meist immer alle Formen von Features einer Bibliothek nutze. ZLIB, BZIP2 und LZMA treten immer gemeinsam auf, oder gar nicht.

Doch die kleineren Helferchen wie stringstream, memorystream und nullstream fallen jetzt sofort weg, wenn sie nicht benutzt werden und das führte bei DOS-Programmen gleich zu einer Verringerung um 5 bis 10 KByte.

Hätte ich SSL-Streams bisher “optional” im Code drinnen gehabt, würde die Codereduktion im Megabytes-Bereich liegen.

GCC Negativ-Optimierung

Tatsächlich sind mir auch ein paar “Negativ-Optimierungen” mit meiner neuen Initialisierungsstrategie aufgefallen. Denn in einigen Formationen hat der GCC offenbar die V-Tables schon vorher perfekt wegoptimiert.
Mit meiner Umstellung kam also bei den benutzten Objekten jetzt eine Initialisierungsfunktion hinzu, die größer war als die alte statische Initialisierung.

Während also WATCOM und MSVC Binaries zwischen 2 und 10 KB kleiner wurden, wurden einige Outputbinaries des GCC um 1 KByte größer.

Doch da hier der Kosten/Nutzeneffekt bei der DOS Plattform groß und bei Linux vernachlässigbar war, bin ich bei den neuen Funktionen geblieben.

Fazit

Tja … Microsoft hat schon vor über 20 Jahren das V-Table Problem zumindest im C++ Codegenerator angegangen.
Heute komme ich also im C-Nachbau auch dorthin.

Es ist schon spannend zu lernen, wie und vor allem wann Compiler ihre Optimierungen anwenden können und wann nicht.

Ich überlege noch, ob man die Initialisierung mit Makros “besser” abdecken kann, aber vorerst bleibe ich bei der direkten Umsetzung.
Der V-Table Code wird schließlich nur einmal geschrieben bzw. heute eben genau einmal angepasst.

Guardians of the Galaxy - 3

2023-05-06T13:00:00+02:00

Mitte der 90er hatten wir Als die Tiere den Wald verließen, denn diese Serie trieb jedes Kind zum nächsten Tierschutzverein.

Heute setzt Guardians of the Galaxy Vol 3 bei diesem Thema an und zeigt uns ein würdiges Ende der Guardians (und deren möglichen Neubeginn).

Diverse Trailer haben es uns schon ahnen lassen, dass der sprechende
Waschbär Rocket eine zentrale Rolle einnehmen wird.

Wir wussten aus den Filmen bisher nur, dass es sich bei diesem Wesen um ein Experiment an Tieren handelte, welches diese intelligenter und damit auch “menschlicher” werden ließ (… was für ein Widerspruch).

Und tatsächlich spielt ein Drittel des Filmes als Rückblenden in der Vergangenheit und zeigt wie Rocket unter unmenschlichsten Bedingungen zu dem wurde, was er heute ist.

Rettet die Tiere

** Achtung: Spoiler voraus! **

Dieser Marvel Film ist ein einziger Fingerzeig darauf, wie schlecht wir Menschen mit Tieren umgehen. Dass hier auch Marvels Guardians of the Galaxy vorkommen, ist eigentlich belanglos … und trotzdem unglaublich gelungen umgesetzt worden.

In den ersten 10 Minuten wird Rocket lebensgefährlich verletzt und der Film handelt davon, wie seine Freunde, die Guardians, um dessen Leben kämpfen. Und diese Aufgabe führt sie zu Rockets ehemaligen Peiniger, der ihn einst “erschuf”.
Das war es auch schon … und hier könnte man sofort die Kritik loslassen und von einer fehlenden Story sprechen.

Doch auf diesem simplen Handlungsstrang sehen wir einerseits einen Freundeskreis, der ungewohnt ernst die eigenen Fehler eingesteht und andererseits erblicken wir in einer hochmodernen technisierten Zukunft dreckige Käfige, in denen Tiere gequält und ihre Leben nur einen reinen Materialwert hat.

Die Bilder wirken zugegeben oft kitschig, wenn wir Waschbären, Otter oder Hasen mit menschlichen Gesichtszügen leiden oder sich freuen sehen.
Das kennt man nur noch aus dem “Kinderfernsehen”.
Aber vielleicht brauchen wir mal einen “erwachsenen” Unterhaltungsfilm, der uns wieder daran erinnert, dass WIR oft für das Leid auf dieser Welt verantwortlich sind.

Neue und alte Gesichter

Der ehemalige Maze Runner Verlierer Will Poulter hat ordentlich Muskeln antrainiert, damit er zu Adam Warlock werden konnte um die “junge Variante” einer lebendigen Waffen zu spielen.
Bedauerlich ist eher, dass er zur Nebenfigur verkommen ist und nun vermutlich auf seinen großen Auftritt in den kommenden Avengers Filmen warten muss.

Ansonsten laufen viele Figuren der vergangenen Filme einmal vorbei, spielen aber keine Rolle. Es wirkt eher so, als hätte man sie in die Story hinein geschrieben, damit man eben das ganze Guardians-Universum nochmal auflisten kann.

Ende und Neuanfang

Für das Ende sollte man ausreichend Wasser trinken, denn ohne Tränen geht es nicht. Die Guardians trennen sich, und versuchen (so wie Thor in Thor 4 ) einen neuen Sinn im Leben zu finden.
Doch gleichzeitig sammeln sich junge Azubis rund um Rocket und Adam, um ein neues Guardians-Team zu gründen.

Wir haben also das Ende einer Trilogie erreicht, die im Abspann einfach “ausläuft”.
Dennoch lautet der letzte Schriftzug:

The legendary Star-Lord will return.

Fazit

Als Marvel Fan kann ich gar nicht anders, als diesen Film zu empfehlen. Die Guardians sind eine “komische Bande” und produzieren zuverlässig Lacher im Kinosaal.
Diesmal wurde es aber gleichzeitig ernst bei vielen Szenen und der in Infinity Wars zur “Star-Lusche” verkommene Star-Lord hat sich (ähnlich zu Thor) seinen Heldenstatus zurückerkämpft.

Ein Funkfeuer von Comic-haften Kämpfen wechselt sich mit ruhigen wie auch düsteren Rückblenden ab und zeigt alle Charaktere von ihre lustigen, ernsten und heldenhaften Seite.

Tja und alle, die Guardians of the Galaxy vorher noch nicht kannten, die sehen sich am besten den Christmas-Song aus dem Weihnachts-Special an, das ziemlich gut zeigt, was für ein “seltsamer” Haufen die Guardians-Charaktere sind und wie selbstironisch sie mit sich umgehen:

Major's Problem

2023-04-30T13:00:00+02:00

Skandale, Verbrechen und Betrug geschehen rund um die Uhr. Auch die Welt der Stars und Sternchen ist damit konfrontiert.
Bisher ging das stets an mir vorbei, weil mich das wenig interessiert hat.

Mit der Anzeige wegen häuslicher Gewalt gegen Jonathan Majors ändert sich das allerdings. Hier kann man nicht so einfach Partei ergreifen und weitermachen.

Es war allgemeiner Konsens, dass Jonathan Majors eine hervorragende Besetzung als “He-who-remains” und Kang the Conqueror im Marvel Cinematic Universe ist.

Der Schauspieler konnte realistisch die Figur eines Mastermind wie auch eines Bösewichtes der ersten Klasse darstellen. Für 2025 war mit Avengers “Kang-Dynasty” das nächste große Marvel-Kinospektakel geplant, und bis dahin sind noch einige Zwischenprojekte mit dieser Figur eingeplant.

Und dann … im März 2023 … kommt die Meldung von der Verhaftung des Schauspielers in die Medien. Er soll eine Frau geschlagen und verletzt haben.

Wie auch immer sich die Geschichte fortsetzt, können “wir” nicht wissen. Die Verteidigung des Opfers bringt Verletzungen und medizinische Details vor, der Angeklagte liefert Videoaufzeichnungen und Chatprotokolle, dass die Verletzungen nicht von ihm stammen können.

Jetzt ergeben sich folgende Szenarien:

Dem Kläger wurde ein Unrecht angetan:
- Der Beschuldigte legt manipulierte Beweise vor um die Schuld von sich zu weisen.
Der Angeklagte wurde zu Unrecht beschuldigt:
- Der Kläger legt manipulierte Beweise vor um die Schuld auf den Kläger zu legen.
Kläger und Angeklagter legen zum Teil manipulierte Beweise vor
- Jetzt wird es verdammt kompliziert.

Interessant sind jedoch jetzt bereits die Konsequenzen, denn mit Veröffentlichung der Anklage wurden sämtliche Projekte und Partnerschaften mit dem Schauspieler unmittelbar beendet. Nur Marvel hat für seine Projekte bisher noch kein Statement abgegeben … doch im Hintergrund, so munkelt man, wird eine Neubesetzung zumindest angedacht.

Das Schlimme an dieser Dynamik ist, dass egal wie es ausgeht, der Schaden bereits angerichtet ist.

Jonathan Major’s steile Karriere ist aktuell beendet und für ihn geht es nun um die Frage, ob er verurteilt werden wird oder ob er mit beschädigtem Image weiter in der Filmbranche arbeiten können wird.

Das Opfer ist mit einem Prozess konfrontiert, der ebenfalls keine große Karriere mehr zulässt. Stimmen die Vorwürfe, muss gegen eine Horde von Majors-Fans angekämpft werden und man steht für immer als Opfer im Rampenlicht. Handelt es sich um eine böswillige Unterstellung, folgt eine unbezahlbare Wiedergutmachungsforderung und ein Leben in Schande.

Das Schlimme daran ist, dass sich in unserer medialen Welt die Fronten schon gebildet haben und so wird munter darüber diskutiert:

dass Superstars glauben, sich alles ungestraft erlauben zu können.
dass einsame Freaks gerne Superstars die Karriere zerstören wollen.

Auf Youtube treten bereits Verteidiger für beide Seiten auf und Astrologen legen die Karten um den Ausgang vorhersehen zu können.

… und all das ist Schwachsinn.

Fazit

Ich wünsche mir natürlich, dass der charismatische Schauspieler von den Anschuldigungen reingewaschen werden kann … und gleichzeitig will ich, dass Gewalt gerade bei solchen Personen auf gar keinen Fall geduldet werden kann.

Jetzt heißt es mal Klappe halten und die Justiz arbeiten lassen … und das dauert eben. Die Beweise beider Seiten müssen geprüft und vorgetragen werden und am Ende soll ein Richter entscheiden, was weiter geschehen soll.

Hardware und Software in Filmen

2023-04-29T13:00:00+02:00

Es gibt für Insider nichts komischeres, als wenn Outsider so tun, als würden sie sich auskennen.

Und zu den lustigsten Dingen zählen dabei die Darstellung von Hardware und Software in Film und Fernsehen.

Armageddon 1998

In den ersten Minuten des Films schwebt ein Astronaut im Orbit und repariert einen Satelliten.
Spannend ist, dass es ein Intel-Mainboard für Sockel-2 Prozessoren ist, auf dem er mit einem tollen Greifwerkzeug den Prozessor (vermutlich ein Pentium) entfernt.

Ich bin mir nicht sicher, ob man ein PC Mainboard einfach so dem Weltraum aussetzen sollte. (… die überhitzen doch ohne Luftkühlung!)

The Core (Minute 79)

Der innere Kern ist pure SciFi-Comedy, nur wussten das die Macher nicht.

Wenn man schon ein Magma-festes Schiff hat, mit dem man sich zum Mittelpunkt der Erde graben kann, dann hat es auch die beste Technik an Board.
Als der Computer dann einen beschädigten Schiffsteil mit einem Kollegen abtrennen will, versucht der Techniker den Vorgang aufzuhalten.
Dafür muss man einfach schnell viele Kabel umstecken.
Gut das überall Breadboards mit jeder Menge Kabel und Kurzschlüssen in den Wänden verbaut sind, so kann man hoch energisch Kontakte herausziehen und wieder reinstecken.

Batman vs Superman (Minute 38)

Das einzige, was mich in dem Film voll und ganz überzeugt hat, war, als Bruce Wayn mit einem Lumia Windows Phone die Hardware der Lexx-Corp gehackt hat.

Das verstehe ich … diese Smartphone war perfekt und konnte alles. Schade dass die Hacker-App nie im Store erhältlich war.

Der Tag, an dem die Erde stillstand (Minute 30)

Ja, Microsoft hat mal einen Tisch namens Surface bzw. PixelSense entwickelt, den niemand haben wollte. Es war ein übergroßer Touchscreen mit Windows Vista.

Im Film hat des Teil für 10 Sekunden den Zweck ein paar Farbpatzer und virtuelles Papierblatt für die Entscheidungsträger anzuzeigen. Tja … die Regierung kann sich sowas leisten.

Matrix 2 (Minute 103)

Ist doch klar, dass alle, die die Matrix verstehen, absolute Hacker sind. Und Trinity nutzt auch eine bekannte SSH Lücke für ihren Hack aus. … aber … warum sollte bei der Eingabe des root Passworts auf der Konsole nochmal ein eigenes Fenster aufgehen, wo genau die 8 Stellen des zuvor gesetzt Passworts Z10N0101 perfekt für die Kamera ausgerichtet nochmal eingegeben werden müssen.
Da wird es unglaubwürdig, Freunde.
Die 3 Assembler-Zeilen im Hintergrund lassen wir mal als optische Bereichung einfach so stehen.

Digimon Movie

Dass Digimon in zwei überlappenden Windows 98 Fenstern “live” mit Animationen digitieren können und dass alles über eine Modem-Verbindung übertragen wird, ist schon ein bisschen weit hergeholt.

Aber mir gefällt am besten, wie es dort “im Internet” aussieht:
Ein leerer Raum mit Wänden, auf denen Karusselpferde und andere Ringelspiele ihre Runden ziehen.

In Summe enthält der Digimon-Film (leider) mehr Windows 9x-Screenshots als gute Handlung. Aber als Werbefilm hätte Microsoft es nicht besser machen können.

Star Trek Discovery (S1E3 Minute 20)

Im 23. Jahrhundert ist der Windows Kernel immer noch fleißig im Einsatz um die Systeme der U.S.S. Discovery zu betreiben.
Nur manchmal muss Micheal Burnham diesen Patchen um eine Biologie Aufgabe lösen zu können. Auch nicht schlecht. Wer auch immer sich das hat einfallen lassen, wusste nicht, dass LCARS für “Linux CAn Run Starships” steht.

Frequency (Minute 69)

Anlagetipps in die Vergangenheit schicken … das machte sonst nur Biff in Zurück in die Zukunft. Doch Frequency greift das Thema “Daten in die Vergangenheit schicken” ebenso auf.

Die Info, man solle in der Vergangenheit in “Yahoo” Aktien investieren, war im Jahr 1999/2000 vielleicht noch richtig. Und der Nachbarsjunge fuhr dann als Erwachsener ein schönes Auto. Es fehlte aber die Info, dass man die Aktien im neuen Jahrtausend ganz schnell wieder verkaufen sollte.

AntiTrust bzw. “Startup”

Ist es nicht lustig, dass der Film Antitrust bei uns unter dem Titel “Startup” herauskam?

Ich liebe es, wenn sich Programmierer über die genialsten Algorithmen unterhalten und dann Java Code angezeigt wird, der die HTTP-Verben GET und HEAD aus einem Byte-Array zeichenweise heraus-IF-t. Genau so fasziniert wäre wohl auch Bill Gates gewesen. Doch die Sache hatte ihren Preis. Diese Zeilen wurden einem anderen Coder geklaut, der seine Erfindung nicht lange überlebt hat.

Gut, dass unser Hacker-Held das Überwachungssystem findet und auslesen kann. Am Ende werden die Firmensatelliten mit 10.x.x.x IP Addressen einfach heruntergefahren und der Sourcecode im Netz veröffentlicht. Ob die gezeigte Seite skullbocks.com immer noch den Code zeigt?

Fazit

Es gäbe sicher noch viel viel mehr, aber diese Filme (bzw. Serien) kommen mir immer in den Sinn.
Leider nicht mehr gefunden habe ich die Seaquest DSV Folge, wo ich mich an ein “Watchdog-Programm” erinnere und ein digitaler Hund immer “Wau-wau” am Lautsprecher ausgab.

Es ist einfach lustig, was sich Filmemacher alles einfallen lassen um digitale Ereignisse und “Hacken” zu visualisieren.

WSL Special: Debian und Server 2019

2023-04-23T13:00:00+02:00

Für WSL ist Ubuntu die beste Distribution, denn hier hat jede Distro-Version eine eigene ID, und man kann sie alle parallel installieren, z.B.: Ubuntu-18.04, Ubuntu-20.04 usw.

Debian heißt immer nur Debian und man bekommt offiziell immer nur die neueste Variante. Doch wie kann man auf einem älteren Stand seine Software testen?

Microsoft bietet offiziell nur einen Download Link für Debian auf learn.microsoft.com an, und zwar: aka.ms/wsl-debian-gnulinux
Heute erhält man damit nur Debian 11, vor einem Jahr war es Debian 10 und bis vor 2 Jahren war es noch Debian 9.

Die älteren Varianten sind quasi weg.

Ein Hoch auf die fleißigen Bienchen im Internet und auf Github!

Zum Glück hat ein User auf GitHub die früheren Links gepostet:

Download WSL Debian 9
- Für Updates muss man in /etc/apt/sources.list die URLs auf http://archive.debian.org/... umstellen.
Download WSL Debian 11
Download WSL Kali Linux 2019.2
- Für Update müssen neue Keys eingespielt werden mit:
  sudo wget --no-check-certificate https://archive.kali.org/archive-key.asc -O /etc/apt/trusted.gpg.d/kali-archive-keyring.asc
Download WSL Kali Linux 2022.3
Download WSL Ubuntu 14.04
- Nur root filesystem
Download WSL Ubuntu-16.04
Download WSL Ubuntu-18.04 X+5
Download WSL Ubuntu-18.04 ARM64
Download WSL Ubuntu-20.04 X64
Download WSL Ubuntu-20.04 ARM64
Download WSL Ubuntu-22.04 X64
Download WSL Ubuntu-22.04 ARM64
Download WSL OpenSUSE Leap 42.2
Download WSL openSUSE Leap 15.4
Download WSL openSUSE Tumbleweed
Download WSL SUSE Linux Enterprise Server 12
Download WSL SUSE Linux Enterprise Server 15-SP4
Download WSL OracleLinux 8.5
Download WSL OracleLinux 7.9

Die .appx Dateien sind .zip Dateien und lassen sich mit Tools wie 7zip öffnen. Unter den extrahierten Dateien befindet sich meist eine .exe, die die Distribution automatisch einrichtet.

Alternativ kann man auch das enthaltene Dateisystem in der .tar.gz Datei per
wsl --import MyDistroName "C:\WSL\my_distro_storage" "path\to\install.tar"
in die WSL Installation integrieren und mit
wsl -d MyDistroName starten.

Fazit

Ich brauche immer wieder mal alte Linux Distributionen, um mit deren Standard Compiler Debug-Builds anzustoßen, die dann auf gleichartigen Zielsystemen getestet werden sollen.

Parallel dazu sind einige Tools und Bibliotheken aufwärts-kompatibel. Baut ein Programm also auf Ubuntu 16.04, wird es mit hoher Wahrscheinlichkeit auf einem Ubuntu 22.04 laufen. Umgekehrt ist das aber nicht so.

Es bringt also Vorteile, wenn schnell und effizient über unterschiedliche Linux Distributionen verfügt werden kann … und da sind alte WSL-Images echt hilfreich.

RDP klaut ALT-GR

2023-04-22T13:00:00+02:00

Und nun zu den aktuellen Nachrichten:

Während der interaktiven Sitzung zwischen Windows 10 und Server 2019 kam es heute zu einem Unfall im ALT-GR Tastenbereich.

Mehrere Codes wurden korrumpiert, als sämtliche Tastenanschläge für Backslash \ und Pipe | durch scharfe-S ß und Kleinerzeichen < ersetzt wurden.

Die zuständigen Behörden wurden umgehend informiert und erarbeiteten vor Ort eine Lösung.

Der Spruch:

Das Leben ist wie eine Hühnerleiter.
Kurz und beschissen.

hat sich heute wieder bewahrheitet … denn ich hasse es, wenn ich wegen Blödsinn so viel Lebenszeit verliere.

Daher die Lösung zuerst:

Falls plötzlich die ALT-GR Taste nicht mehr die üblichen Zeichen auf einer deutschen Tastatur produziert und parallel eine RDP Sitzung offen ist:
Einfach die RDP-Verbindung trennen!

Ich kenne schon länger das Phänomen, dass RDP-Sessions zu veralteten Clients (Windows XP, 2000) die ALT-GR Taste nicht verstehen. Bei xrdp unter Linux passiert das übrigens auch immer wieder.

Die Lösung ist dann meistens:
AltGr + Taste == Strg + Alt + Taste
Soll heißen: Ein Backslash ist nicht nur mit Alt-Gr + ß, sondern auch Strg + Alt + ß möglich.

Das kümmert mich sonst nicht, weil ich das bestenfalls zur Eingabe von UNC Pfaden brauche.

Heute hatte ich aber eine ungute “Rückkopplung”, dass nämlich die ALT-GR Taste auch in lokalen Programmen nicht mehr funktionierte, unter anderem auch nicht in Visual Studio.

Und so saß ich mit 3 Programmen vor mir: RDP, Netflix und Visual Studio und wechselte ohne genau hinzusehen zwischen den 3 Fenstern und tippt weiter meine Codekorrekturen ein.
Der Compiler verweigerte jedoch diese nach zahlreichen Änderungen und erst da bemerkte ich die häufigen ß und < Zeichen.

Die Tastatureinstellungen waren korrekt (Deutsch) auch ein erneutes Verbinden der USB-Tastatur half nicht.

Als ich den Rechner neu starten wollte und das RDP-Fenster schloss funktionierte plötzlich auch ALT-GR wieder korrekt … W-T-F !

Fazit

Ja … auch so ein Blödsinn kostet Zeit … und erst recht die Spielerei mit der Tastatur, denn ich dachte anfangs, die Taste sei kaputt.

Naja … nun ist es hiermit dokumentiert:

Bei Tastaturfehlern beenden Sie umgehend ihre RDP Sitzungen.
Und bei Risiken und Nebenwirkungen tragen sie ihren Arzt zum Apotheker.

Offline Installationen mit Linux

2023-04-21T13:00:00+02:00

Bei Produktinstallationen für Kunden melden diese oft:

Wir haben ein XYZ Linux Version 9.8.7 ohne Internetanbindung. Senden Sie uns alle notwendigen Installationspakete zu.

Und dann fängt das große Weinen an, wenn man bei Python3 angefangen eine halbe Linux-Distribution “nachliefern” soll.

Windows stammt aus der Offline-Zeit weshalb alles als einzelne Installationsdatei (.msi, .msu, .cab und andere) ausgeliefert werden kann. Heute ist das ein unguter Fluch, weil man die Fülle an Dateifragmenten nicht mehr verwaltet bekommt und erst seit kurzem wird versucht mit winget verspätet ins 21. Jahrhundert zu wechseln.

Linux Distributionen hatten früh erkannt, wie wichtig ein einheitliches Paket-Management ist und nutzten es. Allerdings spalteten sich schnell verfeindete Sekten ab und gründeten ihre eigene Paket-Religion.

Im Embedded-Bereich schmerzt das sehr, wenn man neben dem eigenen Produkt auch noch auf viele Geschmacksrichtungen von Linux-Varianten eingehen muss, denn dort ist ein System “offline” und stets veraltet für 10 Jahre in Betrieb.

Wenn wir Entwickler also ein tolles Feature implementieren, das auf der lib_superduper aufbaut, müssen wir dann auch einen Weg finden, wie diese fehlende lib_superduper beim Kunden integriert wird.

Aber wie findet man jetzt heraus, welche Pakete sonst noch fehlen, und wo kann man die dann herunterladen?

Debian (Kali, Ubuntu, Raspbian)

Wir brauchen also eine Liste der fehlenden .deb Dateien, die apt für uns herunterladen und dann installieren würde.

Folgender Trick hat da bei mir funktioniert:

Eine VM (oder ein Docker Container) wird so aufgesetzt wie das Zielsystem.
Man löscht die Inhalte von Verzeichnis /var/cache/apt/archives.
Anschließend startet man sudo apt install --download-only PACKNAME.
Und schon liegen alle notwendigen .deb Dateien in /var/cache/apt/archives

Von dort kopiert man sie dann zum Zielsystem und führt folgendes Kommando aus:
sudo dpkg -i *.deb, welches die .deb Dateien installiert. Nachdem die Reihenfolge der Installation nicht definiert ist, kann es aber auch zu Problemen oder Scriptfehler kommen, die man dann mit
sudo apt-get install --fix-broken wieder hinbekommen kann.

RedHat, Alma, CentOS

Distributionen, die mit dem dnf Tool ihre .rpm Pakete verwalten, benötigen das Kommando:
dnf download PACKNAME --resolve
und schon liegen alle korrekt aufgelösten Abhängigkeiten als .rpm Dateien im aktuellen Verzeichnis.

Installieren kann man die Softwarepakete aus dem Verzeichnis dann mit
sudo rpm -ihv *.rpm

Fazit

Ich als Entwickler brauche immer wieder mal einen gdb auf einer Zielmaschine. Und wenn ich weiß, dass mein Kunde eine Debian 9 oder Alma 8 Variante im Einsatz hat, dann kann ich bei mir lokal genau die Bibliotheken vorbereiten und dann per SSH installieren, die zur Distribution passen.

Schwerer haben es da meine Dev-Ops Kollegen, die Datenbanken, Monitoring-Tools und Deployment-Werkzeuge auf unterschiedliche Kundenhardware verteilen müssen.

Zumindest gibt es für die gängigen Linux Varianten Hilfsmittel um solche Offline-Updates vorzubereiten.

Mein gutes (Update-) Werk ist für heute getan und somit kann ich beruhigt auf der Konsole exit eintippen.

Keyboard- und Tastencodes

2023-04-15T13:00:00+02:00

A bis Z und 0 bis 9 wird von jedem OS auf ASCII bzw. Unicodezeichen abgebildet. Das gilt auch für die Konsole.

Aber wie bekommt man z.B. Pfeiltasten per read(stdin) geliefert?

Meine uralten Basic-Beispiele machten sich die Sache für kleine Spielchen leicht: Man ging vom Zahlenblock aus und nutzte die Tasten

2 herunter
4 links
6 rechts
8 hinauf

So umging man schon unter DOS die interessante Frage, wie man eigentlich an die “richtigen” Pfeiltasten kommt.

Leider ist das alles andere als einfach … oder anders gesagt, es hängt vom OS ab. Im C Standard sind solche Tastenübersetzungen jedenfalls nicht definiert.

BIOS und DOS

Im PC BIOS und nachfolgend auch unter DOS wurden solche Tastenanschläge in zwei-Bytes-Sequenzen kodiert.
Das erste Byte zeigte an, dass das nachfolgende Byte eine Spezialtaste war.

Und so ergeben sich z.B.: für die Pfeiltasten:

Up: 00 und 72
Down: 00 und 80
Left: 00 und 75
Right: 00 und 77

Windows

Die Windows Konsole reagiert hier “eigen”, denn ein normales ReadFile(STDIN) interpretiert die Tasten nicht, das Konsolenfenster jedoch schon und “verbessert” eigenmächtig das UI, indem es eine History der letzten Eingaben über die Pfeiltasten auslesen lässt.

Man kann jedoch über die Konsolen-API ReadConsoleInput alle Tastenereignisse abfangen und selbst interpretieren. Was sich nach Unicode abbilden lässt, erledigt Windows für uns, doch Sondertasten bekommen den Wert 0.
In dem Fall muss man den VKEY-Code interpretieren, der mitgeliefert wird und dort haben so gut wie alle üblichen Tasten eine Entsprechung.

POSIX (Linux)

Unix Varianten treten das Erbe von VT-100 an und kodieren Sondertasten mit Escape-Sequenzen

Up: 0x1b 0x5b 0x41 = ^[[A
Down: 0x1b 0x5b 0x42 = ^[[B
Right: 0x1b 0x5b 0x43 = ^[[C
Left: 0x1b 0x5b 0x44 = ^[[D

Schlimmer ist hier, dass die Standard-Konsole auf ENTER wartet, bevor ein read(STDIN) Eingaben lasen kann. Um also einzelne Tasten direkt lesen zu können, muss man über termios.h und tcsetattr() die “Line-Discipline” ausschalten. Das wichtigste auszuschaltende Flag heißt ICANON. Danach kann man die Escape-Sequenzen selbst abprüfen.

GATE Implementierung

Einerseits sollte die Konsolen-API genau die Zeichen zurückgeben, die das System liefert. Andererseits sind abstrakte Symbole für z.B. die Pfeiltasten aber sehr notwendig um portable Programme zu schreiben.

Der Kompromiss sieht also so aus, dass es eine native Schnittstelle zum Lesen einzelner Zeichen gibt und einen “Input-Parser”, der aus den nativen Zeichen wieder Tastenanschläge zusammensetzt.

Für DOS und Linux war das relative einfach, weil man direkte Mapping-Tabellen für die Zeichenübersetzung erstellen kann.

Windows hingegen verdoppelte den Aufwand, denn zuerst musste ich mal die VKEYS in Unicode-Zeichen umwandeln, bevor diese dann per Mapping-Tabelle in abstrakte Tasten konvertiert werden können.
Ich entschied mich für die neuen Icon-Zeichen in Unicode, wo die Pfeiltasten-VKeys auf grafische Pfeile abgebildet werden, denn ich glaube nicht, dass es in naher Zukunft Tastaturen geben wird, die diese Zeichencodes direkt antippbar bereitstellen werden.

Fazit

Der kleinste gemeinsame Nenner zwischen mehreren Systemen wird bei solchen Aufgaben unerwartet groß, soll heißen: Die Unterschiede sind sehr groß.

Meine Erwartung, dass es einen übergreifenden Standard gibt, hat sich nicht erfüllt.

Aber mit etwas Aufwand und 4 separaten Implementierungen (Windows, POSIX, DOS und EFI) habe ich nun meine eigene Konsolen- und Tastaturschnittstelle geschaffen, die für mein Vorhaben ausreicht.

Altes Debian für alte Hardware

2023-04-09T13:00:00+02:00

Mein aus dem Jahr 2005 stammende HP NX6310 Laptop lebt noch immer, fristet aber sein Dasein auf der Reservebank.

Und ich dachte mir: Nachdem man nicht mal mit einem Raspberry PI 3 heute vernünftig “ins Internet” gehen kann, klappt das mit einem 1.4 GHz Single-Core Celeron erst recht nicht.

Doch man staune: Debian macht es möglich.

Debian 7.0 (Wheezy) aus dem Jahr 2013 war damals mein erstes Debian Linux für den Raspberry PI, und mich beeindruckte schon damals, wie schnell die X86-Desktop-Variante bei mir auf meinen Intel Atom Maschinen lief.

Zwar ist Debian auch heute noch ein flinkes System, aber dennoch wurde es (wie alle seine Verwandten) mit jedem neuen Kernel und Userland größer und damit schwerfälliger.

Deshalb wollte ich bewusst eine alte Distribution auf dem HP Laptop einsetzen.

Die Standard-Netzwerkinstallation erkannte auch sofort meine Hardware und den verbundenen Ethernet-Port, konnte aber keine Pakete finden.
Die Mirror-URLs, die damals gültig waren, existieren heute nicht mehr.

Mit archive.debian.org hat man jedoch immer noch ein Online Repository, welches die ältesten Distributionsversionen bereitstellt.

Sobald die neue URL manuell eingetragen ist, startet auch schon der Download der gewünschten Software und richtet Debian auf der Festplatte ein.

Verblüffend schnell

Ich gebe zu, ich habe die originale Festplatte durch eine SSD ersetzt, aber nie hätte ich erwartet, wie verdammt schnell das Altgerät hochfahren kann.

In 5 Sekunden ist das OS geladen und wartet auf die Benutzeranmeldung. Die von XFCE verwalteten Fenster reagieren ebenfalls prompt auf Klicks und anderen Aktionen.

Als Webbrowser stehen Chromium 37 und Iceweasel 38 (Ein Debian-fork von Firefox) zur Verfügung. “Meine Seiten” laden beide Browser deutlich schneller als das der aktuelle Chromium am Raspberry PI 4 mit Debian 11 hinbekommt. Hier hilft der kleinere Fußabdruck der Software deutlich die Ausführung zu optimieren.

Andere Seiten wie youtube.com funktionieren leider nicht, was aber an der Darstellung der Seiten liegt. Interessanterweise kann ich aber problemlos Youtube-Videos abspielen, die über den youtube-nocookie.com `` Link aufrufbar sind.

Es ist also sogar “einfaches Multimedia” mit dem Veteran möglich.

Fazit

Hut ab vor Debian!

Erstens bin ich beeindruckt, dass die Installation einer 10 Jahre alten Distro überhaupt noch funktioniert und erst recht “Hut ab” vor der unglaublichen Leistung, die das OS aus einem Celeron von 2005 herausholen kann.

Ein parallel installiertes Windows 2000 und XP kommen da in Sachen Reaktionszeit auf der Hardware bei weitem nicht mit.

Die alte Regel, dass Debian einen hervorragenden Support für ältere Hardware bietet, kann ich hiermit nur bestätigen.

Auch in Sachen Nachhaltigkeit ist diese Erkenntnis wertvoll, denn wir lernen hiermit, wie gut man auch heute noch mit alter Hardware arbeiten kann. Für reine Office-Tätigkeit, wie auch die Programmierung ist das Gerät nämlich immer noch gut geeignet.

Fail: Timeout NEVER = ?

2023-04-08T13:00:00+02:00

Ich mag Funktionen mit Timeouts, denn mit denen kann man “kalkulieren”, während andere ewig blockieren können.

Folglich baue ich auch selbst gerne solche ein.
Doch … was ist, wenn man unendlich auf ein Ereignis warten will?

Die kurze Antwort: Man kann zwei Funktionen für ein Feature implementieren. Eine mit Timeout und eine ohne. Aber das ist lästig.

An der Stelle tauchen dann (in vielen Frameworks) Konstanten auf, die die Unendlichkeit repräsentieren.
Titel wie NOTIMEOUT, INFINITE, NEVER und viele mehr sollen ausdrücken, dass man nicht eine bestimmte Anzahl von Sekunden oder Millisekunden warten soll, sondern so lange “blockieren” darf, bis die gewünschte Operation fertig ist.

Solche Timeout-Konstanten können aber Wertebereiche repräsentieren, die sich mit anderen Zeitangaben überlappen können.

Ein Klassiker unter Windows ist INFINITE welches als DWORD Typ den Wert 0xffffffff trägt.
Die meisten Warteroutinen akzeptieren einen DWORD als Millisekundenwert, somit man maximal maximal 4 294 967 295 Millisekunden (50 Tage) auf ein Ereignis warten kann.
Der INFINITE Wert lässt das System allerdings ewig warten.

Hier kann man dann den Fehler machen und das unendliche Timeout durch eine Subtraktion per Überlauf auf diesen Wert bringen.

Ein anderer Klassiker ist die falsche Portierung dieses Wertes (z.B. auf Linux).

1unsigned wait_infinite_ms = (unsigned)-1;
2struct timespec timeout = { wait_infinite_ms / 1000, wait_infinite_ms * 1000000 };
3select(... &timeout);

Es ist übrigens nicht lustig solche Fehler in anderen Programmen zu suchen, wenn die einzige Info ist:

Das Programm bleibt hängen.

-1 != NEVER

Ich bin dabei in meine eigene Falle getappt, als ich die DOS Keyboard Warteroutinen erstellt habe. Ein leichtfertiges
await_and_read_kbd(ptr_char, -1)
ließ genau (unsigned int)-1 Millisekunden Zeit verstreichen. Und auf einem 16-Bit System sind das 65 Sekunden.

Mein Problem lag in der Erwartungshaltung:
Warte unendlich lange auf Ereignis, brich bei Fehlern ab. “Unendlich” bedeutet ohne Timeout, und der Timeout-Fehler nach 65 Sekunden brach dann unerwartet die Funktion ab.

Wenn man also schon ein NEVER als Zeiteinheit zulässt, dann muss man diesen Spezialfall auch ausprogrammieren.

wait, wait_for, wait_until

C++ löst dieses Problem aus meiner Sicht sehr schön, indem es nicht auf eine API mit magischen Konstanten setzt, sondern in vielen Bereichen 3 Warte-Varianten anbietet.

wait() wartet unendlich
wait_for() wartet eine fixe Zeitspanne ab
wait_until() wartet bis ein übergebener Zeitpunkt erreicht ist.

Eine solche Lösung schwebt mir daher in meinem C++-Layer auch vor.

Fazit

Man spielt nicht mit der Zeit, schon gar nicht mit der Unendlichkeit.

Tatsächlich sind mir Endlosschleifen wegen falscher Zeit und Warteroutinen schon öfter untergekommen. Die Fixes sind dann in wenigen Zeilen durchgeführt, aber das Auffinden solcher Schwachstellen ist mühsam.

Es macht also Sinn, sich vorher über eine “gute API” den Kopf zu zerbrechen und dieses Schema einheitlich projektweit umzusetzen, als auf Bugs und Inkonsistenzen zu warten.

Leider spielen da auch viele Hilfsbibliotheken nicht gut mit, die Warteroutinen auch alle etwas anders ausgestalten.

Parameter per Kommandozeile

2023-04-02T13:00:00+02:00

Wenn Programme andere Programme starten sollen, stellt sich die Frage:

Wie?

Die C Standard Bibliothek beantwortet das leider sehr unzufriedenstellend, doch trotzdem basieren viele Lösungen auf dem alten
system("myprog arg1 arg2") Schema.

Und da kann man leider auch viel falsch machen.

Windows vs. Unix vs. C

Das aus CP/M und DOS geborene Windows verfolgt einen vom C-Standard abweichenden Weg mit “Befehlszeilenargumenten” umzugehen.
Denn während Unix Programme für erfahrene Profis gemacht wurden, die alles über eine Vielzahl von Parameter konfigurieren wollten, waren DOS und Windows Programme für Anfänger in Büros gedacht.

Ein DOS/Windows Programm braucht keine Argumente, sondern startet ein UI, in welchem der Benutzer seine Daten über eine “schöne” Maske findet.
Die “Profis” unter diesen Anfängern lernten dann, dass man den Start und das Laden eines Programmes vereinen konnte, in dem man nach der Programmdatei noch den Pfad zur Datendatei angab, wie:
edit c:\my_diary.txt

Hier unterscheiden sich DOS/Windows und Unix gewaltig, denn Windows leitet diesen String einfach an das Programm weiter, während das Unix Programm von seinem Elternprozess ein Array von Strings für jeden Parameter erhält.
Man könnte auch sagen:

Windows ist auf genau einen Parameter optimiert bzw. eingeschränkt.

Bei DOS/Windows Programmen müssen also die Parameter im Prozess selbst auseinanderdividiert werden, während auf Unix-Systemen bereits der Elternprozess festlegt, wie viele Parameter übergeben werden.

Problematisch wird das dann bei Leerzeichen, die es in DOS ursprünglich in Dateinamen nicht gab, womit man den einen Befehlszeilen-String einfach durch seine Leerzeichen aufspalten konnte.
Im Nachhinein wurde dann mit CommandLineToArgv() eine API eingeführt, damit dieses Parsen auch unter Windows einheitlich wurde und C-Runtime darauf aufsetzen konnte. Hier werden nun nämlich Anführungszeichen (double quotes) benutzt, um einen zusammengehörenden Parameter zu markieren.
z.B.: my_app first_arg "seconds arg" "and a third arg"

Einfaches und doppeltes Anführungszeichen

Die C Funktion system(command_string) ruft die OS-Shell mit dem übergebenen Kommando auf, was unter Windows zu einen CreateProcess() mit cmd.exe /c + command_string wird. Die Linux C-Runtime nutzt ein fork() / exec() Paar mit dem Array
[ "/bin/sh", "-c", command_string ].

Das bedeutet also, wenn man Leerzeichen in Argumenten eines Zielprogramms braucht (z.B.: für das Auflisten des Ordners my folder), dann muss der Aufruf den Leerzeichen-Parameter auch unter Anführungszeichen setzen.

1system("dir \"my folder\"");

wird am Ende zu:

Windows: CreateProcess("cmd.exe /c dir \"my folder\"")
Linux: exec([ "/bin/sh", "-c" "dir \"my folder\"" ] )

Man könnte glauben, doppelte Anführungszeichen lösen somit alle Probleme und sind plattformunabhängig.

Leider falsch!

Jede Shell hat die Eigenschaft, dass sie Umgebungsvariablen expandieren und Escapezeichen umwanden kann. Das trifft sowohl unter Windows wie auch unter Linux zu (wenn auch ganz unterschiedlich).

Linux führte daher die einfachen Anführungszeichen ein (Hochkomma, single quotes), mit denen die Variablen und Zeichenauswertung verhindert wird.

dir "my folder" und dir 'my folder' liefern beide unter Linux das gleiche Ergebnis, doch unter Windows wird der zweite Aufruf fehlschlagen, da die Hochkommata nicht interpretiert werden können.

echo $HOME und echo "$HOME" liefern unter Linux beide Male das tatsächliche Verzeichnis, das in der HOME Variable gespeichert wird.
Doch der Aufruf echo '$HOME' führt zur Ausgabe $HOME, da der Variablenverweis nicht durch den Inhalt ersetzt wird.

An dieser Stelle unterscheidet sich also zusätzlich das Verhalten der Shells von Windows und Linux deutlich, denn um zu verhindern, dass in manche Argumente versehentlich Umgebungsvariablen eingeschleust werden, wird das Hochkomma ' in vielen Anwendungen bevorzugt.

Beispielprogramm `system_cmd`

Ich habe im BLOG Classroom das Beispielprogramm system_cmd hinzugefügt, mit dem system() Aufrufe per Kommandozeile ausgeführt werden können. Hier kann man mitverfolgen, welche Kommandos wie im Prozess ankommen, und was der Prozess selbst wieder an die Shell weitergibt, und was diese am Ende daraus macht.

Hintergrund dieser Analyse war ein Bug in einer Software, wo es um die Weitergabe von Passwort-Token ging. Hier ist die Abschaltung der Variablen- und Sonderzeichenauflösung sehr sinnvoll, denn ein einzelnes Dollarzeichen kann schnell zu falschen Daten führen.

Ich sehe im Besonderen die Notwendigkeit, dass die Parameterverwaltung für Windows und Linux unterschiedlich durchgeführt werden muss und Sonderzeichen manuell so umgestaltet werden müssen, dass die Shell daraus nichts Ungewolltes macht.

Der Aufruf von Programmen, die sowohl unter Windows also auch unter Linux verfügbar sind (z.B.: curl), liefern beim Start durch system() nicht immer die gleichen Ergebnisse.

Fazit

Oh Mann! Lieber nicht system() benutzen!

Es gab schon früher einige Meldungen, dass system() zum Hacken missbraucht werden konnte. Hat man die Möglichkeit Teile des Strings zu manipulieren, kann man Schlimmste Sachen damit anstellen.

Dass aber die Art der Anführungszeichen zu unterschiedlichem Handling in der Shell führen können, hatte ich so deutlich bisher aber auch nicht auf dem Zeiger.

Generell nutze ich selbst wenn möglich direkt die APIs des OS, also exec() oder CreateProcess() und nie system().
Damit bleiben mir “Interpretationsspielräume” der Shell erspart. Leider machen es sich viele Projekte leicht und bauen “mal schnell” einen String zusammen. Der Grund liegt in der Einfachheit des Aufrufs … sicher ist das aber nicht.

Das Gleiche gilt natürlich auch für popen().

Nun geht für mich die Analyse weiter, in welchen anderen Projekten ich noch solche system() Zeitbomben finde.

Defragmentierung

2023-04-01T13:00:00+02:00

Die Defragmentierung von Festplatten war früher eines der schönsten Schauspiele, die ein DOS oder Windows PC mit sich brachte.

Heute ist sie in Vergessenheit geraten, obwohl im Hintergrund immer noch stückweise “optimiert” wird.

Geschichte

Datenträger werden unordentlich, wenn ständig Daten gespeichert und wieder gelöscht werden. Im Idealfall ist eine Datei nämlich in einem zusammenhängenden Block gespeichert, womit das Lesen linear in einem Stück erfolgen kann. Doch beim Löschen von Daten entstehen unregelmäßige Lücken, die nicht mehr von ganzen Dateien befüllt werden können, und somit müssen zusammenhängende Daten quer über den Datenträger verteilt gespeichert werden.

Und weil das damals auf mechanischen Festplatten viel Zeit kostete, wurde mit der “Defragmentierung” ein Werkzeug erschaffen, dass Dateien so lange hin und her verschob, bis wieder alle Stücke lückenlos hintereinander angeordnet waren.

DOS

DOS 6 lieferte das erste grafische defrag.exe Programm mit, welches die Festplatte als Blockmenge am Textbildschirm darstellte und man förmlich zusehen konnte, wie die verstreuten Blöcke wieder zusammengesetzt wurden.

Ein toller Nebeneffekt war übrigens, dass Verzeichnisse alphabetisch sortiert wurden. Der Aufruf von dir lieferte vor der Defragmentierung die Einträge in der Reihe ihre Anlegung, danach konnte man schön von A-Z durchblättern.

Windows 9x

Ähnlich sah die Defragmentierung unter Windows 95/98 aus. Hier konnte man bereits scrollen und sah für jeden logischen Speicherblock ein Kästchen und je größer die Platte wurde um so länger wurde die Liste.

Windows 98 fügte dann noch Optimierungen hinzu, dass häufig genutzte Dateien an den Anfang der Festplatte verschoben wurden, was mit Geschwindigkeitsgewinnen beworben wurde.

Windows NT 4

NT4 hatte kein Defragmentierung-Tool dabei, weil man bereits verkündet hatte, dass das neue NTFS Dateisystem so effizient sei, dass es zu keinen Fragmenten mehr kommen sollte (bzw. dass diese dann egal wären).

Doch so ganz stimmte das auch nicht, und so lieferten Dritthersteller solche Tools nach.
oodefrag war eine kostenlose Variante, die ich damals einsetzte. Sie setzte den Internet-Explorer 5.0 und die MMC voraus, was beides kein Grundbestandteil von NT war und nachinstalliert werden musste.

Windows 2000/XP

Mit NT 5 (also Windows 2000) lieferte Microsoft wieder selbst ein Defragmentierung-Tool mit und ließ es auch automatisch von Zeit zu Zeit im Hintergrund durchlaufen. Die Anzeige wurde stark vereinfacht und zeigte nur noch einen Querbalken an, der ein Laufwerk und seine Daten repräsentierte.

Die Darstellung von einzelnen Blöcken wurde durch die stark gewachsene Speichergröße unmöglich gemacht. Startete man zu Windows NT Zeiten noch mit Festplatten im 1 GB Bereich, musste ein Windows Server 2003 schon mit 100 GB und mehr umgehen können.
Diese Datenmengen kann man nicht mehr sinnvoll durch einzelne Kästchen oder Bildpunkte darstellen.

Ab Vista und Windows 7

Ab NT 6 (Windows Vista) erreicht die Defragmentierung quasi ihr endgültiges Aussehen. Nun sehen wir nur noch eine Prozentzahl in einer Listview, die während der Defragmentierung hochzählt.

Diese Optik wurde leicht angepasst auch in Windows 8, 10 und 11 sowie den entsprechenden Server Varianten übernommen.

Windows unterscheidet seit dieser Zeit aktiv zwischen klassischen Festplatten und neuen SSDs und führt auf der moderneren Hardware keine übliche Defragmentierung mehr durch.

Der als “Optimierung” bezeichnete Vorgang sendet nun das TRIM Kommando an die SSD um freie Sektoren dem SSD-Controller zu melden. Dieser kann deren Speicherzellen dann intelligent wiederverwenden und braucht den Inhalt nicht bewahren.

Mit SSDs ist es egal, ob Dateistücke hintereinander liegen, denn der Zugriff auf die einzelnen Sektoren erfolgt durch den Controller annähernd gleich schnell und außerdem organisiert dieser die Daten intern nach anderen Kriterien. Die Daten des logischen Sektor 2 müssen in der SSD nicht “direkt hinter” dem logischen Sektor 1 liegen.
Eine klassische Defragmentierung ist hier also unnötig und nutzt durch das Umschreiben lediglich die Speicherzellen sinnlos ab.

SSDs trotzdem defragmentieren

Will man aber dennoch alle seine Dateien defragmentiert Sektor für Sektor hintereinander vorliegen haben, lässt sich Windows über das Konsolenkommando
defrag C: /PrintProgress /FreespaceConsolidate dazu bewegen.

Das hilft vor allem, wenn man ein Laufwerk verkleinern möchte und freien Platz am Ende des Datenträgers sicherstellen will. Die “Konsolidierung des freien Speicherplatzes” ist auch sinnvoll, wenn man ein Low-level Image eines Datenträgers anlegt, denn dann liegen die Dateien auch dort in einem Stück hintereinander in der Image Datei.
Ich würde jedoch ein WIM Image einem Sektor-für-Sektor Image vorziehen, und für dism und .wim Dateien ist die Fragmentierung wiederum gleichgültig.

Fazit

Das Defragmentieren der Festplatte gehörte um das Jahr 2000 herum zu den üblichen “Wartungsvorgängen”, die man unwissenden Kunden als notwendigen Service aufschwatzen konnte, und was auch immer eindrucksvoll präsentierbar war.

Heute klicke ich eher zufällig jedes halbe Jahr auf den “Optimieren” Knopf, meist nach einem größeren Cleanup oder Backup.
Geschwindigkeitsvorteile bringt einem das keine mehr ein … doch es bewirkt immer noch den Placebo-Effekt, dass man glaubt, man hätte danach einen saubereren Datenträger vor sich.

In diesem Sinne:

Defragmentiert immer brav eure Festplatten!

QBasic: CALL ABSOLUTE

2023-03-26T13:00:00+02:00

Als ich in den 90ern meine DOS und QBASIC-Babyschritte machte, lernte ich, dass “Systemroutinen” (auch als “Software-Interrupts” bekannt) mit QBasic nicht möglich waren, jedoch in QuickBasic 4.5+ unterstützt wurden.

Es gab jedoch einen dunklen Hack, mit dem auch das kostenlose QBasic “mächtiger” werden konnte … doch mir war das damals leider nicht bewusst.

Die Compiler-Sprachen von damals (wie Turbo-C oder Turbo-Pascal) ließen sowohl inline-Assembler wie auch Interrupt-Aufrufe zu. Doch dem QBasic-Interpreter fehlten solche Mechanismen. Nur das kommerzielle QuickBasic bot eine Interrupt-Bibliothek an, um Systemroutinen aufrufen zu können.

Doch QBasic und mache seiner Vorfahren gestatteten es, Bytes im Speicher direkt zu setzen. Und so konnten kleine Programmteile manuell in den Speicher geschrieben werden.
Und mit der Anweisung CALL ABSOLUTE konnte man eine beliebige Speicheradresse einfach anspringen um den dortigen Code auszuführen.

X86-Assembly Code dynamisch mit QBASIC kompilieren

Wenn man weiß wie, ist es einfach:
Man allokiert ein Array in QBASIC, schreibt den korrektn Maschinencode mit POKE Aufrufen in das Array, holt sich dan mit VARPTR und VARSEG die Adresse und lässt CALL ABSOUTE den Code ausführen.

In meinem Beispiel im Classroom unter
basic/call_absolute/callabs.bas sieht man aber, dass das in QBASIC recht mühsam sein kann.

In Assembler würde das Unterprogramm etwa so aussehen:

 1push bp         ; prolog
 2mov bp, sp
 3
 4mov ax, ds      ; DS segment auf stack sichern
 5push ax
 6mov ax, es      ; ES segment auf stack sichern
 7push ax
 8mov ax, [my_ds] ; neues DS segment laden
 9mov ds, ax
10mov ax, [my_es] ; neues ES segment laden
11mov es, ax
12
13mov ax, [my_ax] ; gewünschtes AX laden
14mov bx, [my_bx] ; gewünschtes BX laden
15mov cx, [my_cx] ; gewünschtes CX laden
16mov dx, [my_dx] ; gewünschtes DX laden
17mov si, [my_si] ; gewünschtes SI laden
18mov di, [my_di] ; gewünschtes DI laden
19
20int intNum      ; interrupt aufrufen
21
22pop ax          ; gesichertes ES segment zurückholen
23mov es, ax
24pop ax          ; gesichertes DS segment zurückholen
25mov ds, ax
26
27pop bp          ; epilog
28ret

Doch in QBASIC ist das Befüllen eines Arrays mit Byte-Werten ein Krampf:

 1DIM op(1 TO 64) AS INTEGER
 2DIM i AS INTEGER
 3
 4i = 1
 5REM ---- jeder Menge Code davor ----
 6
 7REM ---- MOV AX, (regs.ax)
 8op(i) = &HB8: i = i + 1
 9op(i) = regs.ax AND &HFF: i = i + 1
10op(i) = (regs.ax \ 256) AND &HFF: i = i + 1
11
12REM ---- MOV BX, (regs.bx)
13op(i) = &HBB: i = i + 1
14op(i) = regs.bx AND &HFF: i = i + 1
15op(i) = (regs.bx \ 256) AND &HFF: i = i + 1
16
17REM ---- MOV CX, (regs.cx)
18op(i) = &HB9: i = i + 1
19op(i) = regs.bx AND &HFF: i = i + 1
20op(i) = (regs.bx \ 256) AND &HFF: i = i + 1
21
22REM ---- MOV DX, (regs.dx)
23op(i) = &HBA: i = i + 1
24op(i) = regs.dx AND &HFF: i = i + 1
25op(i) = (regs.dx \ 256) AND &HFF: i = i + 1
26
27REM ---- INT num
28op(i) = &HCD: i = i + 1
29op(i) = intNum: i = i + 1
30
31REM ---- jede Menge Code danach ----
32
33DIM asmFunc(1 TO 64) AS INTEGER
34asmFuncAddr = VARPTR(asmFunc(1))
35DEF SEG = VARSEG(asmFunc(1))
36
37REM ---- INT-Array-Werte zu echtem Bytecode übertragen
38FOR n = 0 TO i - 1
39    POKE (asmFuncAddr + n), op(n + 1)
40NEXT n
41
42CALL ABSOLUTE(VARPTR(asmFunc(1)))

Ich setze also einen Eintrag von op(i) auf eine CPU-Instruktion, und dann folgt immer ein i = i + 1 …

Oh Mann, da lernt an C echt wieder lieben, wo es einfach heißt:
op[i++] = 0xab;

Vorsicht beim Hin- und Rücksprung

Es gibt ja mehrere ret Varianten, wir brauchen hier Opcode CB für einen far-return.
Und auch CALL ABSOLUTE funktioniert nur dann, wenn in der Zeile das ganze
CALL ABSOLUTE(VARPTR(asmFunc(1))) steht. Mit dem vorherigen asmFuncAddr klappt es nicht.

Fazit

Genau so eine Funktion hatte mir damals gefehlt, um per DOS das Dateisystem zu durchforsten oder per INT 10h und INT 13h Grafikkarten und Disketten zu kontrollieren.

All das gelang mir am Ende mit Turbo Pascal etwas später.
Aber Schade, dass mir diese Welt nicht gleich in QBASIC offen stand.

Faszinierend:
Eine Programmidee von mir nach über 30 Jahren fertiggestellt.
Das kann nicht mal Duke Nukem toppen.

Spezialfälle in Windows 95

2023-03-25T12:00:00+01:00

Aus API Sicht waren Windows 95, 98 und ME für mich so ziemlich das gleiche, nämlich ein reduziertes Set von NT4. Die Frage war damals also:

Ist etwas kompatibel mit “NT4” oder “nur 9x”.

Doch … Windows 95 war stets “weniger”, der Support wurde schnell fallen gelassen als 98 auf den Markt kam … und heute verstehe ich erst, warum das so war.

Das schöne an Visual Basic 6 Code war: Er lief überall, da er nur Windows 95 als Minimum voraussetzte und selbst dort nur Teile der Windows API nutzte.

In C/C++ musst man sich über diverse Makros entscheiden, ob man bei NT4 startete, oder nur:

das 95er Subset
95 + IE4
98
98 + IE5

usw. einsetzen wollte. Je nach Wahl wurden mehr APIs freigeschaltet, bzw. neue Flags und structs für diese APIs.

Windows 95 (auch als v4.0 bekannt) war das erste 32-bit OS mit “neuem” Design und man mag denken, es wäre der kleine Bruder von NT4 (auch v4.0), doch es liegt in Wahrheit irgendwo zwischen NT 3.5 und NT 4.0.

Fehlende Komponenten

Meine neulichen Compiler-Experimente mit Visual Studio 2003 deckten auf, dass GATE Code zwar auf Windows 98 liefen, unter 95 jedoch mit fehlenden Einsprungpunkten abbrachen.

Interlocked Compare Exchange

InterlockedIncrement(), ...Decrement und ...Exchange gab es bereits, doch InterlockedAdd() und InterlockedCompareExchange() fehlten. Das bedeutet: Reference-Counting-Support ist da, State-Machine-Support nicht.

Ich nutze CompareExchange häufig zum sicheren Umschalten zwischen Zuständen und das tun auch andere Bibliotheken.

Winsock 1

Es gibt de facto keine Software, die nicht gegen ws2_32.dll, also Winsock-2 linkt, wenn sie TCP/IP braucht, doch eben diese DLL fehlte im originalen Win95. Sie wurde zwar mit dem Internet Explorer nachgeliefert … doch der war damals eben noch kein Standard.
Während NT4 und 98 somit “jede” Netzwerk Software ausführen konnte, wurde 95 meist ausgeschlossen.

UTF-8

WideCharToMultiByte() und MultiByteToWideChar() sind die beiden wichtigsten Funktionen, um zwischen NT’s Unicode Strings und alten Win9x ANSI Strings hin und her zu konvertieren. Mit dem Flag CP_UTF8 war auch UTF-8 als char-Output möglich … doch erst ab 98.

Mir flog das als “unerklärbarer” Fehler um die Ohren, denn im GATE Projekt sind alle Strings UTF-8 und müssen entweder nach UTF-16 oder ANSI konvertiert werden, wenn Windows-APIs aufgerufen werden.

Fibers

Die Fiber-APIs kommen ebenso erst mit Windows 98, obwohl sie schon in NT 3.51 implementiert waren.
Zwar sind Fibers im GATE Projekt optional, doch nun weiß ich: OpenSSL und andere Hilfsbibliotheken nutzen ebenso Fibers oder fragen zumindest ab, ob die Ausführung auf einem Thread oder einem Fiber läuft.

Fazit

Meine Lösung zur Umgehung dieser Probleme ist: im ANSI-Modus werden die fehlenden APIs durch Fallbacks ersetzt. Unicode Varianten laufen daher ab NT4 mit Standard APIs, ANSI Varianten implementieren Fallbacks für Windows 95.

Mein größtes Problem sind Fremdbibliotheken, für die habe ich aktuell keine richtige Lösung. Zwar wäre es möglich per Makros die Aufrufe von Fiber- und Interlocked-Code auf selbst implementierte Hilfsfunktionen umzuleiten … aber wer weiß, ob das Ergebnis dann korrekt ist.

Vorerst muss ich leider Tools mit SSL und SQLite von Windows 95 ausschließen. Und das ist deshalb ärgerlich, weil es nur 2 oder 3 Aufrufe innerhalb dieser Bibliotheken gibt.

Doch ich habe nun (20 Jahre zu spät) endlich gelernt, warum einige Projekte damals einfach nicht Win95-kompatibel waren.
Ich dachte damals, dass UI-Spezialitäten daran Schuld wären, doch die Ursache lag teilweise viel tiefer.

Relevanz hat diese Erkenntnis heute keine mehr. Doch sie zeigt die historische Entwicklung und Integration von Funktionen bzw. deren Prioritäten recht gut auf.

Codeberg: das bessere Github

2023-03-19T12:00:00+01:00

Ich bin 2018 nur deshalb zu Bitbucket gegangen, weil man dort kostenlose private Repos anlegen konnte.
Erst ein Jahr später zogen Github und andere nach, doch einen Grund zur Migration gab es für mich keinen.

Mit Codeberg ist in Deutschland ein offener und kostenloser Git-Hoster aufgetaucht, der mich aber über einen Umzug nachdenken lässt:

Der Code liegt auf Servern in der EU … also “bei Freunden”.

Server-Politik

Ich habe bereits im Jahr 2005 gelernt, dass Software auf Servern innerhalb der USA durchaus “problematisch” sein können. Denn wer auch immer es sich mit der US-Regierung verscherzt, bekommt den Zorn in allen Geschäftsbereichen zu spüren.

Und so wird allen US-Unternehmen untersagt in irgend einer Form Handel mit Staaten zu betreiben, die nicht genehm sind. Und das betraf damals viele Länder, die in irgend einer Form mit Afghanistan oder dem Irak zu tun hatten.

Und heute trifft das vor allem die Umgebung von Russland.

Jetzt kann ich das durchaus nachvollziehen, dass ein Staat seinem Kriegsgegner kein “Ressourcen schenken” will, doch leider sind von solchen Sanktionen auch Open Source Projekte betroffen.
Das bedeutet, da wird gerade den Jungs und Mädels, die für eine fortschrittliche freie Gesellschaft stehen und die sich dort beteiligen wollen, der Zugang zu Wissen und der Zugang zur Beteiligungsmöglichkeit entzogen.
Und das darf eigentlich nicht sein.

Codeberg

Der Berliner Verein Codeberg e.V. hat vor ein paar Jahren ein gitea basiertes GIT Hosting gestartet, welches ähnlich zu Github und Konsorten ist, jedoch seinen Sitz innerhalb der EU hat und somit von den üblichen Spielen der “Großmächte” vorerst verschont ist.

Ich will jetzt nicht schlecht über Projekte auf Servern in anderen Staaten sprechen, aber wenn es um Rechtssicherheit und Eigenständigkeit geht, dann kann man sich aktuell auf die EU am ehesten verlassen, dass sie die Rechte der Bürger schützt.

Die Gesinnung des Projektes kann man auch nur positiv hervorheben, denn sie stellt die “Bewahrung freier Inhalte” in den Mittelpunkt. Und da das Projekt nun schon ein paar Jahre online ist, kann man davon ausgehen, dass die Starthürden bezwungen wurden.

Im Netz findet man eine stetig wachsende Gruppe von Anwendern, die mit den Diensten zufrieden sind.
Stand heute: 66000 Projekte von 52000 Benutzern.

Woodpecker CI

GIT ist nicht genug … heute braucht jeder CI (Continuous Integration). Soll heißen: Wird Code commited, muss ein Buildserver anspringen und das Projekt durchbauen.

Codeberg setzt hier auf Woodpecker-CI, welches Docker basierte Agents für Linux, MacOS und Windows anbietet.

Das ganze funktioniert genau so, wie in den meisten anderen CI-Systemen nur eben wieder mal mit einer etwas anderen Syntax: Man legt eine YAML Datei an, die eine Pipeline von Aufgaben definiert, wo man einen Docker-Image Pfad hinterlegt und dann die Build-Kommandos in Script-Form anfügt. Und am Ende kann das Ergebnis per Suchfilter gefunden und als Artefakt hochgeladen werden.

Also eigentlich super … nur eben wieder “ein bisschen” anders, als es Github, Gitlab oder Bitbucket tun.

Weitere Infos

Damit die Community verbunden bleibt, erhält man allgemeine Infos im Projekt-Blog. Oder man folgt dem Newsfeed auf Mastodon.

Einer aktiven Diskussion zu Funktionen oder Problemen kann man auf matrix.org beiwohnen.

Es ist also alles da, was ein modernes Community-basiertes Hosting-Projekt benötigt.

Fazit

Ich habe nun begonnen ein paar Test-Projekte auf der Plattform anzulegen. Ich bin mir noch nicht sicher, ob ich das GATE Projekt von Bitbucket zu Codeberg verschieben sollte, denn eigentlich bin ich mit Bitbucket zufrieden und habe keine “technischen” Grund, von dort abzuziehen.

Dennoch lege ich “mein Lebenswerk” lieber in die Hände der Community, als in die Schatulle eines kommerziellen Software Hauses, wie es bei Atlassian der Fall ist.

Naja … mal sehen, was die Zukunft bringen mag.

Weiter kein Versand mit Aliexpress

2023-03-18T12:00:00+01:00

Aliexpress wurde für mich “attraktiv”, als es von Kreditkartenzahlungen zu PayPal wechselte. (Das muss Ende 2019 passiert sein.)

Doch seit dem 1. Januar 2023 ist Österreich von der größten Handelsplattform für Bauteile für Baster ausgeschlossen … und es wird einfach nicht besser.

Das Thema Verpackung und Umweltschutz ist wichtig, und deshalb wurde ein Gesetzt beschlossen, dass alle Händler im Ausland, die ihre Ware nach Österreich versenden, einige weitere Auflagen erfüllen müssen.

AliExpress hat daher seine Onlineplattform angepasst und lässt Suchanfragen mit Lieferort Österreich nur noch mit jenen Händlern zu, die die neuen Bedingungen erfüllen.
Das heißt also:

Man kann de facto nichts mehr bestellen.

Bei Suchanfragen nach “Arduino” oder “Raspberry PI” erhielt ich vor einigen Monaten noch 10000e Angebote.
Nun sind es wenige dutzend, doch selbst diese melden beim Öffnen des Links sofort:

Dieses Produkt kann nicht an Ihre Adresse versendet werden. Wählen Sie ein anderes Produkt oder eine andere Adresse aus.

Betroffen ist jede Art von Bauteilen oder Werkzeuge, also genau das alles, wofür ich mich interessiere.

Interessanterweise haben z.B. Textil-Anbieter bereits eine Lieferform ausgehandelt und versenden fleißig ihre Artikel.
Produkte wie Unterhosen, Militärjacken oder Sexspielzeug werden also problemlos nach Östereich geliefert … doch beim Atmega328 ist die Lieferkette unterbrochen.

Ich weiß jetzt offen gesagt nicht, was meine Landsleute sonst noch für Sachen in China bestellen, doch die Aufträge der Maker-Szene dürften aktuell alle wegbrechen … und ich glaube nicht, dass das durch Unterhosenkäufe ausgeglichen wird.

In den Statements, die bisher im Netz diskutiert wurden, heißt es, dass AliExpress hier nur als Plattform auftritt und jeder einzelne Shop die Verpackungsbestimmungen selbst umsetzen muss.
Aber das verstehe ich nicht so ganz, denn schließlich bietet AliExpress seine eigenen Versandtarife an und da wäre es doch möglich, dass AliExpress als Dachverband auftritt und für Österreich ein Schema für alle Shops aushandelt.

Fazit

Aktuell habe ich keinen zwingenden Bedarf an neuer Hardware aus China, mir fehlt nur der Zugang zu weiteren RISC-V Dev-Boards. Doch in den vergangenen Jahren habe ich häufig “Spielzeug” mitgekauft, und damit ist nun leider Schluss.

Ich frage mich, ob sich AliExpress doch noch dazu durchringt, uns den Versand wieder zu eröffnen, oder ob sich eine Alternative am Markt breit machen wird.

Banggood bietet zwar mit einem wesentlich geringerem Angebot auch viele Elektronik-Produkte an, doch die Preise und die Auswahl sind mit AliExpress nicht vergleichbar. Hier starten die Preise für RISC-V Boards bei 200 €, welche ich früher schon um 100 € entdeckt hatte … und nun ärgere ich mich, damals nicht sofort zugegriffen zu haben.

In Sachen Verpackung muss man allerdings eines festhalten:
Wer in China Sachen kauft bekommt alles in einem einfach Plastiksäckchen zugestellt, das meistens problemlos in den Briefkasten passt.

Bestelle ich die gleiche Hardware innerhalb der EU (wenn überhaupt möglich), bezahle ich etwa den 5-fachen Preis und bekomme dafür eine Schachtel mit Füllmaterial, eine mit Plastik umspannte Produktbox, in der das Produkt dann nochmals in Plastik versiegelt ist.
… anders gesagt: Der Verpackungsmüll ist nachweislich wesentlich größer.

Ich bin mir also nicht sicher, ob die neue Verordnung das Müllproblem besser behandelt …

Strategiewechsel

2023-03-12T12:00:00+01:00

Bisher habe ich im GATE Projekt versucht, die herauskommenden Programme als größere “Universalwerkzeuge” anzulegen.
Doch das war falsch … oder sagen wir mal: Es ist nicht der beste Weg.

Denn jenseits der Windows und Linux Welt gelten teilweise andere Regeln und die möchte ich auch gerne einhalten.

gatecli ist ein solches Werkzeug, in dem schon viele Funktionen eingefügt wurden. Wann immer ich neue Features implementiere, erhält das Programm ein neues Modul, mit dem man das neue Feature per Konsole ausführen kann.

Doch … nun zeigt sich, dass dieser Ansatz ein Bremsklotz ist. Und dieser manifestiert sich am deutlichsten unter DOS.

Auf die Größe kommt es an

Wenn man Kompression, Grafikformate, Streams und Sockets in eine EXE statisch zusammenkompiliert, so wird diese verständlicherweise immer größer.

Zusammen mit SQLite und libreSSL kommt man da schnell auf 4 MB, was eigentlich klein ist, wenn man es mit DLLs aller Teilkomponenten vergleicht.
Unter DOS ließe sich eine solch große EXE aber gar nicht mehr laden, doch da auf dieser Platform SSL und Datenbanken fehlen, sinkt die Größe drastisch.

Trotzdem bricht der Übersetzungsvorgang seit einiger Zeit ab, da manche Datenstrukturen das 64-KByte Limit brechen.
Da hilft auch das größte Speichermodell nicht mehr weiter.

Mit über 700 KByte sprengt man nämlich deutlich die 640 KByte des konventionellen Speichers und damit ist an der Stelle Schluss.

Erkenntnis:

Wenn man alles in ein Programm packt, wird das für manche Plattformen einfach zu groß.

Aufspaltung in Kleinprogramme

Die Lösung ist der alte Unix-Ansatz, nämlich je ein kleines Programm für genau je ein Feature (oder maximal eine Feature-Familie).
In Summe vergrößert das zwar den Gesamtspeicherverbrauch, weil nun einige Dinge redundant implementiert werden müssen, doch die kleineren Programme können dann auf jeder Plattform geladen werden.

In der Theorie sollte auch die Optimierung von unnötigen Codes besser funktionieren, da der Compiler nun weniger Ausführungspfade nachverfolgen muss.

Es gibt nun aber eine andere Plattform, wo ich bisher mit “einem großen Programm” besser gefahren bin, und das ist UEFI.
Denn mit gatecli hatte ich ein Werkzeug, das wie eine eigene Shell alles verfügbar machte. Ich musste daher nur eine Binärdatei auf einen virtuellen Datenträger packen um Tests unter QEMU zu starten.

Umstellungsplan

gatecli wird nicht aufgelöst, doch ich plane mehrere Funktionen auszulagern. Es soll also eigene Binaries für Kompression und Dateioperationen geben und die bestehenden Features werden dann teilweise aus gatecli verschwinden.

Am Ende wird vermutlich etwas wie eine Mikro Shell zurückbleiben, die andere Prozesse starten können soll.

Ein offene Frage ist für mich der Umgang mit WASM, denn dort gibt es keine Prozesse so wie auf anderen Systemen.

Fazit

Umstellungen sind der letzte Dreck. Aber es ist das beste, was mir passieren konnte.

Wie bei jeder Umstellungen werde ich neue Details darüber lernen, ob Schnittstellen gut oder schlecht (also flexibel oder zu starr) ausdefiniert wurden, und das ist positiv.
Allerdings wird das auch wieder einiges an Zeit auffressen … aber so ist das Leben nun mal.

Die DOS Plattform ist außerdem eine herrliche Vorbereitung für den Einsatz von GATE Code auf Mikrocontrollern oder RTOS Plattformen.

near, far, wherever you are

2023-03-11T12:00:00+01:00

Während Kate rebelliert, Leo stirbt und Céline von “near” und “far” singt (siehe Titanic), überlege ich gerade, wo ich überall “spezielle” Pointer-Attribute unterbringen muss.

Na … da blutet fast das Herz des Ozeans …

Vorgeschichte

Nachdem alle modernen Systeme mit Windows oder Linux ausgestattet sind und mit einem Flat-Memory-Modell arbeiten, versteht heute keiner mehr, wenn ich mich zu folgender Aussage hinreißen lasse:

Pointer ist nicht gleich Pointer.

In C++ finden viele typedefs statt, um Pointer zu kapseln. z.B.: typedef X* X_ptr;
Das ist eigentlich ineffizient, weil X* viel kürzer als X_ptr zu schreiben ist.

Doch früher … viel früher gab es mal mehrere Implementierungen der gleichen Sache abhängig von gewünschten Datenmodell, nämlich: typedef X __near* X_ptr; oder typedef X __far* X_ptr;
Und schon macht es wieder total Sinn, dass man mit dem richtigen X_ptr arbeitet.

Segmentierung

X86-16-bit und DOS arbeiteten mit Segment:Offset Adressierung. Das Datensegment-Register wurde auf einen 64-KByte großen Block gesetzt und man adressierte die Daten über einen relativen Offset.

Wenn ein Programm mit 64 KByte auskam, konnte man ein “kleineres” Speichermodell wählen. Das Segment-Register wurde einmal global gesetzt und alle Adressierung liefen nur über den Offset.
Das nennt man dann einen near Pointer, und der ist nur 16-Bit groß, also klein und damit effizient.

Kommt man 64 KByte nicht aus, kann man weitere 64-KByte Blöcke allokieren und das Datensegment einfach auf den Block zeigen lassen, den man haben möchte. Solche Pointer sind dann 32-Bit breit (weil Segment + Offset) und die werden eben als far Pointer bezeichnet.

Das gewählte Speichermodell entscheidet also, ob
sizeof(void*) == 2 oder sizeof(void*) == 4 gilt. Das könnte dem Programmierer jetzt theoretisch egal sein und er könnte mit dem far Modell immer alles erreichen, doch wenn stets das Segment-Register bei Datenzugriffen neu ausgerichtet werden muss, dann läuft das Programm plötzlich nur noch halb so schnell.

Also Augen auf bei der Wahl des Speichermodells!

Ausnahmen von der Regel

Das GATE Projekt ist leider zu groß, als dass es mit near recht weit kommen würde. Kleine Konsolen-Apps würden sich zwar ausgehen, aber ich mache eben nichts kleines.
Ich nutze daher das large Modell, in dem Code und Daten mehrere Segmente nutzen dürfen, damit sind sowohl Code, als auch Daten-Pointer vom Typ far.

Schließlich geht es mir bei der DOS-Portierung des Projektes nicht um Hocheffizienz sondern um den Beweis, dass man auch heutige Programme noch für DOS kompilieren kann, wenn man sie “richtig” aufsetzt.

Allerdings sind mir einige gebrochene Unit-Tests im Projekt aufgefallen, bei denen ich Pointer für andere Zwecke einsetze, und einer davon heißt “Alignment”.

Weder der C noch C++ Standard garantieren, dass Pointer einem bestimmten Alignment folgen, doch die Praxis lehrte mich:

All Datentypen haben im Zweifelsfall mindestens die Ausrichtung des Pointer-Typs, weil der “am besten” an das Speichermodell angepasst ist.

Soll heißen,
void func(char x, int y);
hat die gleiche ABI-Signatur wie: void func(void* x, void* y);

Denn alle Datentypen kleiner void* werden auf die Größe von void* aufgepumpt, weil void* mit hoher Wahrscheinlichkeit genau die Größe eines normalen CPU Allzweckregisters hat.

Generische Funktionsaufrufe

Im gate/functions Modul werden beliebige C-Funktionsaufrufe über einen Dispatcher geleitet und der arbeitete bisher nach der Idee, dass alle Parameter einer Funktion durch void* repräsentierbar sind (mit ein paar Sonderfällen, die aus mehreren void* Typen zusammengesetzt sein können.)

Das Problem ist, dass void* im Large-Modell 4 Bytes breit ist, doch das Default-Alignment ist auf 16-bit Systemen eben nur 16-bit breit.
Ein void foo(int, int) belegt 4 Bytes (2x int16) am Stack, doch ein
void bar(void*, void*) hätte wegen far bereits 8 Bytes (2x int32) belegt und stimmt nicht mehr mit dem Original überein.

Mein Unit-Test Fehler entstand also durch eine Verschiebung des Speichers.

Lösung: 16-bit Parameter nutzen, anstatt von `void *`

Nun musste also auch ich ein typedef für generische Parameter einsetzen und eben dieses typedef sieht unter DOS nun anders aus, als unter anderen Betriebssystemen.

1#if defined(GATE_COMPILER_WATCOM)
2  typedef short fparam_t;
3#else
4  typedef void* fparam_t;
5#endif

Kaum war die Anpassung vorgenommen, funktionierten auch die Tests wieder erfolgreich.

Andere near/far Pointer erzeugen

Wenn man unter DOS direkt auf die Hardware zugreifen möchte, dann funktioniert das unter anderem auch über feste Speicheradressen.
Ein Beispiel wäre A0000 des VGA Standards.

Pointer zu solchen Segmenten sind ebenso als __far Pointer deklariert. Sie werden über Hilfsmakros wie MK_FP explizit erzeugt:

1static unsigned char __far * vga_screen; 
2vga_screen = (unsigned char __far*)MK_FP(0xA000,0x0000);

Fazit

Ein weiteres Mysterium ist gelöst und eine notwendige Codeanpassung wurde vorgenommen. Anstatt vieler void* Parameter wurde nun ein neuer Typ angelegt, den man an einer Stelle ändern kann.
So kann man auf jeder Plattform den passenden nativen Datentypen über Compiler-spezifische Makros ermitteln.

Ich werde vorerst mit dem LARGE Modell weiterarbeiten, doch es tut sich nun die Frage auf, ob es auch möglich wäre die kleineren Modelle einzusetzen. Spätestens dann müsste ich weitere Anpassungen in vermutlich vielen Modulen vornehmen, denn dann wird die Unterscheidung zwischen near und far explizit umgesetzt werden müssen.

Windows 95 Update ohne Windows 3.x

2023-03-05T12:00:00+01:00

Retro-Time!
Beim Aufräumen meiner Backups ist mir wieder ein altes NT-4 ISO-Image untergekommen, welches neben Windows NT Varianten auch Windows 95 enthielt, und zwar eine englische Version.

Da ich aus meiner Vergangenheit nur deutsche Versionen aufgehoben hatte, startete ich spaßhalber das Setup in einer VM … Doch das brach mit einer Upgrade-Fehlermeldung ab.

Als Windows 95 herauskam, war ich noch lange nicht bereit dafür, und als es so weit war … naja, die Story ist dokumentiert.

Es gab:

die Vollversion “für PCs ohne Windows”
und eine Upgrade Version “für PCs mit Windows 3.x”

Meine gefundene Variante war die originale Upgrade Version und brauchte somit eine Windows 3.x Installation um ausgerollt werden zu können.

Früher nutzte ich eine umständliche Methode und entpackte die Datei mini.cab mit dem extract.exe Tool und editierte die Datei system.ini, von shell=winsetup.bin zu shell=c:\w95setup\path\setup.exe. Danach startete ich dosx und genoss den Start des Windows-Setups ohne 3.x Prüfung.
Der Scherz war, dass Windows 95 sein eigenes kleines Windows 3.x Fragment in mini.cab mitlieferte, welches den grafischen Teil des Setups anzeigte und wenn man setup.exe nicht von DOS sondern von einer laufenden Windows Sitzung aus startete, fand keine weitere Prüfung mehr statt.

Es geht aber auch einfacher…

Win 3.x Fake anlegen

Hacker haben folgendes herausgefunden:

Das Setup prüft nur, ob die Dateien win.com und win386.exe existieren.

Man führt also folgende Zeilen aus:

1mkdir c:\winfake
2dir /s c: > c:\winfake\win.com
3dir /s c: > c:\winfake\win386.exe

und startet das Windows 95 Setup ganz normal, dann werden die Dateien entweder automatisch gefunden, oder man darf sie in einem Laufwerksdialog auch auf anderen Laufwerken manuell auswählen.

Sind die beiden Dateien vorhanden, wird Windows 95 vollständig installiert, denn der Inhalt es identisch zur Vollversion.

Fazit

Tja … ich konnte mich noch dunkel erinnern, dass man nur bestimmte Dateien brauchte und zum Glück konnte ich noch uralte Foreneinträge vom Jahr 2000 finden, wo das dokumentiert war.

Nun ist es auch hier schriftlich festgehalten, damit ich auch in 10 Jahren noch Windows 95 installieren kann. … es mag vielleicht keinen Grund dafür geben, dieses OS zu installieren, aber hey … es ist ein Stück Kindheitserinnerung.

dll_import für Templates

2023-03-04T12:00:00+01:00

Sind in für DLLs exportierten C++ Klassen unter Windows Datentypen enthalten, die auf Templates aufbauen, sieht man schnell den Fehler:

1warning C4251: ... needs to have dll-interface ...

Doch den bekommt man gar nicht so leicht weg, wenn man portabel bleiben möchte.

Vorgeschichte: C++ Templates

C++ Templates kann man nicht exportieren, sie sind in der Regel vollständig im Header implementiert und daher “einfach da”. Wenn sie aber benutzt und damit “instanziiert” werden, erzeugt der Compiler eine Implementierung, gegen die dann gelinkt wird.
Nachdem mehrere Module Templates instanziieren können stellt das eigentlich eine Verletzung der One-Definition-Rule (ODR) dar … doch für Templates wird eine Ausnahme gemacht und der Linker fügt die mehrfachen Varianten entweder in eine zusammen, oder behandelt sie wie private Inline-Codes.

Das Spiel endet aber an der Grenze der erzeugten Ausgabedatei.
Und wenn jetzt ein Projekt eine Bibliothek in ein Programm einbindet und eine Template-basierte Instanz zwischen beiden ausgetauscht werden soll, tja dann müssen wir hoffen und vertrauen, dass es “irgendwie” funktioniert.

Die C++ Sprache kennt keine Windows .dll oder Linux .so Bibliotheken, und somit sind es die Compiler-Hersteller, die den Austausch von Daten zwischen Bibliotheken implementieren, doch einen Standard gibt es nicht.

Aus diesem Grund können auch ein MSVC und ein MinGW GCC problemlos über C-Schnittstellen kommunizieren, denn diese Schnittstelle ist spezifiziert. C++ Codes funktionieren bibliotheksübergreifend jedoch nur mit genau ein und der selben Compiler-Version, ein Compiler-Mischbetrieb ist nicht möglich.

Idee: Template Instanzen exportieren

Will man einen std::vector<int> von einer Bibliothek zum Hauptprogramm weiterreichen, meldet uns die genannte Warnung, dass std::vector<int> kein DLL-Interface eingerichtet hat. Es funktioniert dann aber “magisch” trotzdem, weil der gleiche <vector> Header in beiden Komponenten vorhanden ist, und damit das Binäre Layout auf beiden Seiten identisch bestimmt wird.

Soll heißen, der Inhalt von std::vector<int> wird auf der Zielseite genau so “verstanden”, wie er auf der Erstellerseite angelegt wurde, weil beide Seiten eine Kopie des gleichen Codes enthalten.

Man kann jedoch aus diesem “Zufall” auch einen Standard machen, indem man die explizite Template-Instanziierung mit einem DLL-Interface exportiert und auf der Zielseite importiert.
Nun existiert der Code auf genau einer Seite und die zweite Seite nutzt ihn. Wir haben dann einen binären Standard und können Bugfixes an exakt einer Stelle vornehmen, anstatt sich sorgen zu müssen, dass Templates an jedem Ort anders interpretiert werden.

Beispiel Code

Code sagt mehr als 1000 Worte

 1// mylib.h
 2#include <utility>
 3
 4#if defined(mylib_EXPORTS)
 5#  if defined(_MSC_VER)
 6#    define MYLIB_API __declspec(dllexport)
 7#    define MYLIB_EXTERN
 8#  else
 9#    define MYLIB_API __attribute__((visibility ("default")))
10#    define MYLIB_EXTERN extern
11#  endif
12#else
13#  if defined(_MSC_VER)
14#    define MYLIB_API  __declspec(dllimport)
15#    define MYLIB_EXTERN extern
16#  else
17#    define MYLIB_API
18#    define MYLIB_EXTERN extern
19#  endif
20#endif
21
22// declare export of some std::pair instances
23LIB_EXTERN template struct LIB_API std::pair<int, int>;
24LIB_EXTERN template struct LIB_API std::pair<double, double>;

1// mylib.cpp
2#include "mylib.h"
3
4template struct std::pair<int, int>;
5template struct std::pair<double, double>;

Im Header wird jede gewollte Template-Spezialisierung deklariert, und in der .cpp Datei findet dann die explizite Instanziierung statt.

Der besondere Unterschied zwischen MSVC und GCC ist, dass unter Windows ein mit dllexport exportiertes Symbol nicht zusätzlich noch extern sein darf, während der GCC extern gestattet.

Wir brauchen daher ein zusätzliches “extern” - Makro, welches im Fall von dllexpoprt im Header einfach leer ist.
Unter Linux darf dieses extern nicht fehlen, ansonsten wird die Spezialisierung schon im Header generiert.

Fazit

Für eigene Datentypen ist die Methode also durchaus geeignet, um Templates in der Bibliothek für einige Typen in konkrete Datentypen umzuwandeln.

Die Sache hat nur einen Haken: std::string und alle Container nutzen intern jede Menge weitere private Hilfstypen, die selbst wieder Templates sein können. Und das Problem ist, dass man alle “exportieren” müsste, um alle bekannten MSVC Warnungen wegzubekommen.

Doch dieses Unterfangen ist nicht portabel, und aus diesem Grund setze ich die explizite Instanziierung nur selten für eigene Typen ein.

Trampolin-Springen

2023-02-26T12:00:00+01:00

Bei meinem Rust-Kurs hat mich eine Aussage während des Vortrages gestört:

C++ erzeugt oft schlechten Maschinen-Code mit Trampolines.

Das ist etwas weit hergeholt.

Sprungbretter damals und heute

Wer unter DOS mit X86 16 bit Assembler gearbeitet hat, der kannte das Problem, dass “Conditional-Jumps” (also IF Sprünge) nur +/- 127 Bytes weit reisen konnten.
Oft erhielt man die Fehlermeldung, dass das Ziel für den Sprung zu weit entfernt war.

Jetzt konnte man entweder selbst mitten im Code eine “Zwischensprungstation” einrichten, die zuerst angesprungen wurde um von dort zum richtigen Ziel weiterzuspringen … oder man ließ diese Arbeit dem Assembler selbst per Direktive erledigen.

Dank 32 (und mehr)-Bit Codes sind diese Trampoline weitgehend ausgestorben.

C++ generiert heute jedoch manchmal eigene Hilfsfunktionen, die sich ebenfalls Trampoline nennen, die zuerst “angesprungen” werden und zum eigentlichen Ziel umleiten.

Warum passiert das?

Funktoren

Funktoren und std::function Bindings sind solche “gewollten” Umschlagplätze. Schließlich kapselt man hier einen Funktionsaufruf bewusst in ein “Interface” um es später generisch aufrufen zu können.

flowchart LR STD(std::function
void&#40int,char&#41) F[[function: void target&#40int,char&#41]] O[[method: void obj::target&#40int,char&#41]] L[[lambda: &#91&#93&#40int,char&#41]] STD --trampoline
C call--> F STD --trampoline
this call--> O STD --trampoline
lambda call/inline--> L

Mehrfachvererbung mit virtuellen Methoden

Wenn eine Klasse von einer Basisklasse erbt, dann setzt C++ bei der neuen Klasse die Basis an den Anfang und fügt dahinter die neuen Elemente an. Das gilt auch für die V-Table und man kann immer sagen, dass ein this Pointer gleich dem base-class Pointer ist.

Erbt eine Klasse aber von zwei Basen, dann hat die zweite Basis, das Problem, dass sie nicht am “Anfang” der neuen Klasse stehen kann, weil dort schon die erste steht.
Doch ein von außen kommender Aufruf über einen Pointer zur zweiten Basis würde eben auf den B-Teil von C zeigen.
Hier generiert jetzt der Compiler das B-Interface, das zum C-Interface weiterspringt, wo aber vorher noch der this Pointer angepasst wird, um wieder auf C zu zeigen.

Und das kann man leider auf der Ebene nicht besser machen.

 1struct A
 2{
 3  virtual void foo() { }
 4  int a;
 5};
 6struct B
 7{
 8  virtual void bar() { }
 9  int b;
10};
11struct C : A, B 
12{
13  virtual void foo() override { }
14  virtual void bar() override { }
15};
16
17int main()
18{
19  C c;
20  C* ptr_c = &c;
21
22  A* ptr_a = static_cast<A*>(ptr_c);
23  // result: ptr_a == ptr_c
24
25  B* ptr_b = static_cast<B*>(ptr_c);
26  // result: ptr_b == ptr_c + sizeof(A)
27
28  ptr_a->foo();
29  // no trampoline required, directly call C::foo
30
31  ptr_b->bar();
32  // invokes trampoline, this_ptr = ptr_b - sizeof(A)
33
34  return 0;
35}

flowchart TB subgraph class C : public A, B Aimpl(C impl of foo) Bimpl(C impl of bar) subgraph V-Table class A Afoo[[A::foo]] end subgraph V-Table class B Bbar[[B::bar]] end subgraph V-Table class C Cfoo[[C::foo]] Cbar[[C::bar]] end T[/B to C
trampoline/] end Cfoo --> Aimpl Cbar --> Bimpl Afoo --direct call
A* == C*---> Cfoo Bbar --call
B* --> T --new C*
pointer--> Cbar

Optimierungen des Compilers

Es ist aber ein Irrtum zu glauben, dass wir deshalb immer über Trampolines zur Implementierung springen, denn wenn wir mal beim richtigen Interface-Pointer sind, springen wir stets zum endgültigen Ziel ohne Umwege.

Aus diesem Grund wird Vererbung in C++ immer häufiger über Templates gelöst und virtuelle Funktionen samt Trampolines kommen nicht mehr zum Einsatz.

Zusätzlich haben die Compiler immer weitere Verbesserungen erhalten, um Typeninformationen an Variablen zu binden.
Selbst wenn jemand ein B* ptr = &c ausführt und danach B Aufrufe macht, kann der Compiler sich merken, dass es in Wahrheit ein C* ist und statisch das richtige Ziel ohne Trampolin aufrufen.
Ähnliches gilt für Dispatcher in Functor und Lambda Codes.

Fazit

Ja, Trampoline existieren in C++ als ABI-Sicherheitsgarantie, und der Compiler mag sie als 10-Byte große Bröckchen einstreuen, doch das bedeutet nicht, dass sie immer genutzt werden.

Rust kennt keine Mehrfachvererbung und kompiliert alle Codes statisch, womit das höchste Maß an Optimierung möglich ist. Gleiches passiert, wenn man in C++ ebenso vorgeht. Man kann daher nicht behaupten, Rust wäre hier von Grund auf besser bei der Codegenerierung.

Einen Punkt muss man allerdings Rust zuschreiben: C++ nutzt virtuelle Methoden leider schon häufig in Klassen der Standard-Bibliothek wie iostreams und das bedeutet, dass es hier schon zu Trampolines kommen kann (nicht muss!).
In Rust hingegen sind alle Aufrufe direkt, bis man explizit dyn einsetzt, was von Grund auf Trampoline-frei ist.

Der Nachteil ist jedoch: Wenn man in Rust z.B. COM Interfaces implementieren will oder muss, dann muss man das über unsafe-C-Codes selbst machen …
und das heißt, man darf sich dann quasi Trampolines selbst zusammenschrauben.
Und auf der Ebene verlasse ich mich lieber auf Compiler-generierte Trampolines mit best möglicher Optimierung.

Also bitte keine Anschuldigungen, wenn man Worst-Cases von Sprache A mit Best-Cases von Sprache B vergleicht. Ich weiß, das macht man im Marketing häufig … seriös ist das aber nicht.

Linux auditd und CRLF

2023-02-25T12:00:00+01:00

Bei mir lagen heute zwei Dateien in /etc/audit/rules.d. Wenn in der zweiten alle Regeln auskommentiert wurden, funktionierte auditd zumindest mit den Regeln der ersten Datei.
Kaum wurden die Regeln in der zweiten Datei aktiviert, funktionierte gar nichts mehr.

Und wieder einmal habe ich einen Tag Lebenszeit verloren …

Der Linux-Wächter: auditd

Ich durfte für ein Projekt in der Firma den Einsatz des Linux Daemons auditd ausprobieren. Dieser lädt seine Konfiguration aus .rules Dateien, die in /etc/audit/rules.d liegen.
auditd loggt dann Zugriffe auf Dateien, Programme oder Systemcalls, die man dann für Sicherheitsprüfungen nutzen kann.

So weit, so gut.

CRLF == Error

Natürlich habe ich logische Unterteilungen dieser “Rules” in mehrere Dateien gemacht, die man dann über das selektive Kopieren von Dateien verteilen kann.
Und plötzlich funktionierte nichts mehr.

Ein Aufruf von auditctl -l zeigte, dass keine einzige Regel geladen wurde, obwohl alle Regeln zuvor in einer einzigen Datei perfekt funktioniert hatten.

Immer wieder kopierte ich die Dateien per SSH zwischen meinem Windows System und dem Linux-Testsystem hin und her. Wurden alle Rules in der Datei per # Präfix auskommentiert und die Rules in einer anderen Datei eingebunden, wurden sie geladen und funktionierten.

Nach mehreren Zweifeln an meiner Gesundheit, erkannte ich ganz unten rechts in der Statuszeile von Visual Studio Code den Unterschied zwischen den Dateien:

Die Originale waren mit typischen Linux LF Zeilenenden versehen, nur die eine störrische, die ich unter Windows neu angelegt hatte, zeigte: CRLF an.

Fazit

So ein Fu**!

Naja … ich hätte da auch schon schneller darauf kommen können, aber wenn man die ersten Dateien “zufällig” auf dem richtigen System erstellt hat und einem nur die letzte in die Suppe spuckt, wird man eben blind für die Frage aus der Schreibmaschinenwelt.

Mich ärgert das deshalb, weil ich jetzt seit 20 Jahren in meinen Codes immer beide Line-Ending Fälle brav behandle.
Das hätten die Macher von auditd auch tun können, schließlich braucht man nur das CR vor einem LF wegkürzen und alles ist gut.

However … Gefahr erkannt, Gefahr gebannt.

_bios_disk()

2023-02-19T12:00:00+01:00

Der Zugriff auf Disketten (und die ersten Festplatten) war bereits mit dem originalen IBM BIOS möglich, denn der INT 13h bot einige Dienste, wie etwas das Lesen und Schreiben einzelner Sektoren.
Das brauchte das BIOS auch selbst, um das OS booten zu können.

Watcom (und andere historische Compiler) stellen für diesen Systemaufruf die C-Funktion _bios_disk() zur Verfügung.

Grundsätzlich funktionieren alle BIOS und DOS Systemaufrufe recht ähnlich. Man schreibt in das A Register (AH, AL oder AX) eine Aufrufnummer, setzt weitere Register auf diverse Parameter und springt zu einem der Interrupts:

int 10h für Text- und Grafik
int 13h für Disketten und Festplattenzugriffe
int 21h für MS-DOS Funktionen
und viele mehr

(Hmm … an welchen Unix Klon erinnert uns das jetzt?)

Um das zu vereinfachen, haben die Compiler von damals einige häufig benutzte Assembler Interrupt-Aufrufe in C Funktionen gekapselt.
Watcom stellt auch heute noch in dos.h viele DOS-Aufrufe direkt als
unsigend _dos_*(...); zur Verfügung.

Tatsächlich gibt es auch den Header bios.h, der einige häufig genutzte BIOS Funktionen kapselt:

_bios_disk
_bios_equiplist
_bios_keybrd
_bios_memsize
_bios_printer
_bios_serialcom
_bios_timeofday

Disketten auslesen

Wozu sollte man heute Disketten per BIOS-Aufruf auslesen?

Tja, wenn man einen Toshiba T300 hat, der ein 640 KB-Spezialdiskettenformat unterstützt, das kein anderes 5.25 Zoll Laufwerk lesen kann, und wenn man von einer solchen Diskette ein Image ziehen will … dann braucht man das.

Der T300 kann zum Glück auch normale IBM/DOS 360 KB Diskettenformate lesen und schreiben. Doch Booten kann er offenbar nur von seinem Spezialformat.

Meine Idee war daher die Sektoren der Spuren auszulesen und in Dateien auf dem zweiten Laufwerk zu schreiben. So kann man eine “große” Diskette in zwei kleine teilen, die dann ein neuerer PC wieder lesen kann.

Man befüllt also eine struct _ibm_diskinfo_t mit den Laufwerksparametern und ruft
_bios_disk(_DISK_READ, &diskinfo); auf.

 1struct _ibm_diskinfo_t 
 2{
 3  unsigned drive;
 4  unsigned head;
 5  unsigned track;
 6  unsigned sector;
 7  unsigned nsectors;
 8  void* buffer;
 9};

Ein paar Details über den Aufruf musste ich mir von den alten Interrupt-Listen zusammensuchen, die ich zum Glück online finden konnte.

Dass drive mit 0 Laufwerk A und mit 1 dann B meint, ist logisch.
Der Kopf kann mit 0 und 1 die obere untere Seite ansprechen.
track geht von 0 bis einschließlich 79 auf meiner Spezialdiskette.
Und sector, tja der tanzt mit der Nummerierung von 1 bis 8 aus der Reihe.

Doch so konnte ich dann den ersten 512-Bytes Puffer befüllen und freute mich, dass die Daten auch tatsächlich einem FAT12 Format entsprachen. Zumindest einige der Felder konnte ich klar zuordnen und sie stimmten mit den Laufwerksparametern überein.

Leider schlug mein erster Versuch die Sektoren in einer Schleife auszulesen fehl, denn ich erhielt von den Folgesektoren immer leere Puffer zurück.
Vielleicht hat DOS auch etwas dagegen, wenn man im Hintergrund per int 13h das Laufwerk fernsteuert, oder der Aufruf in der Schleife klappt nicht wie erwartet.

Fazit

Zumindest kann ich eines feststellen:

OpenWATCOM erstellt 16-Bit DOS-EXE Programme, die auch auf dem Toshiba T300 lauffähig sind.

Ich war leider zu kurz am Zweitwohnsitz und konnte keine weiteren Tests machen, warum das weitere Auslesen fehlschlug.

Leider ist von vielen BIOS-Varianten bekannt, dass sie Bugs haben und z.B. Registerwerte zerstören. Wann das hier der Fall ist und die _bios_disk Funktion nicht ausreichend abgesichert ist, dann müsste man den Aufruf in Assembler neu schreiben und alles doppelt und dreifach absichern.

Wie dem auch sei … zumindest ein Teilschritt ist erreicht und beim nächsten Mal komme ich hoffentlich wieder ein Stück weiter.

Ant man 3 - Quantumania

2023-02-18T12:00:00+01:00

Phase 5 ist da!
Mit Ant-Man and the Wasp - Quantumania hat das Marvel Cinematic Universe seine 5. Phase erreicht und deren Prämisse lautet:
Das Multiversum.

Es begann mit der Loki-Serie, an deren Ende der neue Bösewicht Kang angedeutet wurde, doch dann kamen die andere Filme und Serien, die fern ab von der Idee des Multiversums spielten.
In Doctor Strange in the Multiverse of Madness wurde das Multiversum als nebeneinanderliegende Universen dargestellt, die von einander isoliert und völlig unterschiedlich sind … außer man hat die besondere Fähigkeit Tore zwischen diesen Universen zu öffnen.

Doch in der Loki Serie drang eines durch:

Was ist, wenn in einem Universum jemand sitzt, der die anderen Universen kontrollieren möchte.

Hier startet nun Phase 5 durch, die am Ende in einem Multiverse Avengers Film The Kang Dynasty in Phase 6 enden soll.

Achtung Spoiler

Ich hatte es schon befürchtet, als ich die Trailer zum neuen Film sah und es hat sich leider bestätigt:

Janet von Dyne (Michelle Pfeiffer) wurde im zweiten Teil aus der Quantenebene gerettet, in der sie 30 Jahre lange gelebt hat, und es wurde so dargestellt, als wäre das ein öder Raum, in dem nur hausgroße Amöben und Bärtierchen herumschwimmen.
Doch im Quantumania-Film wird der Figur “angedichtet”, sie wolle nicht erzählen, was sie in Wirklichkeit dort unten erlebt hat.
Dort lebt nämlich eine ganze Zivilisation von Menschen und außerirdischen Kreaturen gemeinsam mit (W-T-F) Bill Murray, und alle treffen sich dort in Bars, wo sich sonst nur Luke Skywalker betrinken würde.

Es sah wirklich sehr nach Star Wars aus, nur eben ohne Lichtschwerter.

Aber das eigentlich Schlimme war: Janet hatte dort einen gestrandeten “Kang the Conqueror” getroffen und seine dunklen Pläne gesehen, wie er alle anderen Universen entweder erobern oder zerstören wollte.

Diese Geschehnisse hatte sie einfach verschwiegen, bis es sie nun erneut gemeinsam mit Ant-Man alt (Michael Douglas) und neu (Paul Rudd), der Wespe (Evangeline Lilly) und der rebellischen Tochter Cassie (Kathryn Newton) wieder in die Quantenwelt verschlug.

Diese herbei konstruierte Story ist mein größter Kritikpunkt am ganzen Film.

Denn wenn ein Frau 30 Jahre gegen einen Weltenzerstörer kämpft und eine Rebellengruppe anführt, es dann aber dem Ehemann der Tochter einfach so verschweigt, dann ist das schon recht unglaubwürdig.

Action im Mikrokosmos

Ein verbannter Weltenherrscher, eine Gruppe “Weltenreisende” … na, die Story konnte man sich denken. Es geht nur darum, dass Kang wieder aus der Quantenebene hinaus will und als Leute auftauchen, die das schon mal hinbekommen haben, beginnt das Spiel nach Schema F: Ich entführe/kidnappe, dafür gibst du mir den Schlüssel zum Fluchtwagen, am Ende ruft Gandalf die Adler und Harry Potter entwaffnet Magneto.

So in etwa war Quantumania und es hat Spaß gemacht.
Schließlich sind wir in einer Comic-Welt voller Comic-Superhelden und Schurken, also warum nicht.

Mit Jonathan Majors als Kang hat Marvel eine brilliante Besetzung gefunden, denn während alle anderen Figuren Comic-haft herumalberten, gelang es dem Haudegen sowohl das brutale wie auch das etwas wahnsinnige eines Eroberers glaubhaft darzustellen.

Auch mit Streichelzoo für Kleinkinder

Wenn etwas übertrieben war, dann waren es die kindlichen Pipi-Kacka-Witze. “Humpty Dumpty” Modok bekommt zuerst tödliche Waffen, doch es reicht, dass ihm Cassy gut zuredet, dass er kein Arsch mehr sein soll, und schon kämpft er für das Gute.
Das hätte auch aus einer Folge Doctor Snuggles stammen können. In einem Marvel-Action-Film fand ich es unpassend, aber wenn die Teenies was draus lernen, dann kann ich damit auch leben.

Und das Beste: Die X-Credit Szenen

Es ist für den Film etwas traurig, aber ich gebe zu, dass mich von Anfang an am meisten die Mid- und End-Credit Szenen interessiert haben.
Ich wusste, dass im ersten Film der Phase 5 nicht schon alles “erledigt” sein konnte, und dass wir jetzt wieder 3 Jahre auf “den großen Avengers-Film” hinarbeiten werden.

Und es war so unglaublich geil, als nach dem Ende von Ant-Man und dem Tod “unseres Kangs” in der Quantenwelt, plötzlich ein ganzes Stadion voller Kangs zu sehen war, die sich der neuen Bedrohung widmen mussten, nachdem “einer der ihren” getötet wurde.

Getoppt wurde das dann nur noch durch die End-Credit Szene, die dann Loki Staffel 2 ankündigte. Loki und Mobius lauschten einem “frühen” Kang im 18. Jahrhundert alias Victor Timely, der über die Zeit und ihre Manipulation vor Publikum sprach.

Victor Timely and his Astounding Temporal Marvels.

Fazit

WOW. Phase 5 hat eingeschlagen.
Ich tue dem Film sicher unrecht, wenn ich ihn nur auf sein Ende und die beiden Credit-Szenen reduziere … aber darum ging es doch. Eine typische Comic-Story als Vorspiel für die kommenden Filme.
Quantumania hat es geschafft, dass ich mich total auf die kommenden Filme und die “Entwicklung von Kang” freue.

Denn während uns Phase 4 mit vielen Fragezeichen und ohne Thanos-Ersatz hat stehen lassen, knallt uns Phase 5 einen noch krasseren Bad-Ass hin, dem sprichwörtlich alles zuzutrauen ist.

3 Tage Rust

2023-02-11T12:00:00+01:00

In der Nachbarabteilung meiner Firma wurde festgestellt, dass dotNet Software “nicht ganz so gut performt” und deshalb musste eine schnellere Sprache her. Das wurde dann nicht C++, weil das angeblich zu kompliziert ist, sondern Rust.

Und weil in der bestellten Rust-Schulung für Mitarbeiter noch ein Platz frei war, durfte ich mich da auch hineinsetzen.

Als C und C++ Entwickler sehe ich da eine “Konkurrenz” aufkommen, deren Notwendigkeit sich mir eigentlich nicht erschließt. … aber das ist nicht verwunderlich, genau so ging es mir vor über 10 Jahren schon mit Objective-C.
Wenn man sein Handwerk beherrscht, sieht man nicht die Notwendigkeit es durch etwas anderes zu ersetzen.

Und so fiel mir intensiv auf, dass (wie immer) alles nur anders benannt ist um sich zu unterscheiden, und im Endeffekt auch “nur programmiert” wird.

Beim Längeren Nachdenken versteht man dann aber doch einige Dinge besser und kann ihren (wenn auch seltsam wirkenden) Ursprung nachvollziehen.

Die Vorteile

Formzwang

Als C/C++ Mensch liebt und hasst man die völlige Freiheit im Code gleichzeitig, denn man selbst kann sich frei entfalten, und weil das alle so machen, versteht man den Code des Nachbar nicht mehr.

Der Rust Compiler geht hier so weit, dass er Verletzungen des Codingstyles als Warnung anzeigt. Wer also
fn saySomething() schreibt, bekommt sofort mitgeteilt, dass es besser fn say_something() heißen sollte.

Und ich gebe zu, dass auch ich an mir selbst inzwischen leide, dass ich mich mal darauf festgelegt habe, in C anders zu arbeiten als in C++, damit man die Ebenen besser unterscheiden kann … aber lesbarer wird die Sache im Ganzen dadurch nicht.

Lebensdauer und Konstanten

Dass Instanzen von Variablen eine begrenzte Lebensdauer haben, ist üblich, doch Rust verfolgt jede Variable und Referenz und vermag daher dem Anwender gleich zu melden, wenn dieser auf etwas zugreift, was nicht mehr existiert.

In C++ hingegen dürfen wir sogar lokale Variablen als Referenz aus einer Funktion zurückgeben, was selten eine gute Idee ist.

Auch das transferieren einer Variable in eine andere folgt festen Spielregeln, womit es erst einmal ausgeschlossen ist, dass zwei Threads auf die gleiche Speicherzelle zugreifen dürfen. Erst mit zusätzlichem Aufwand werden solche Zugriffe möglich, was in C++ ohne Warnung oft “als Unfall” passiert.

Dass außerdem erst einmal alles “konstant” ist und explizit als “veränderbar” (mut) markiert werden muss, ist entgegen der Norm. Doch wenn man auch hier wieder an Multithreading denkt, ergeben sich damit enorme Sicherheiten, die man in anderen Sprachen schnell und oft leichtsinnig verliert.

Fehlerbehandlung

Und wer ein Fan von C-Returncodes ist und C++ Exceptions hasst, der wird Rusts enum Result<T, E> richtig lieben.
Mit dem ?-Operator wird nämlich das
if(!ok) return error; in ein Zeichen am Ende eines Aufrufs hineinkodiert. Man programmiert also den Erfolgsfall weiter und darf sich darauf verlassen, dass Rust den Fehler automatisch zurückgibt, bis er irgendwo explizit behandelt wird … und das alles ohne Exception-Overhead.

… und vieles mehr

Natürlich kann man jetzt nicht alle Vorzüge auflisten, die lernt man in jedem Rust-Tutorial. Doch die 3 genannten Punkte gefallen mir persönlich sehr.

Die andere Seite

Wenn eine Sprache aber so andersartig und seltsam ist, dass sie mit wenig vergleichbar ist, dann stellt sich einem schon die Frage, ob das gut, und vor allem ob das sinnvoll ist.

Traits vs. Klassen

Ein Mathematiker mag es anders sehen, doch ich als Embedded-Programmierer schätze das Interface- Objekt- und Vererbungsmodell der Sprachen C++, C#, und Java wirklich sehr.

Rust kennt dieses Konzept nicht, sondern lässt uns Traits für jedes neue Element implementieren. Parallel dazu werden Attribute eingesetzt um “ähnliche” Eigenschaften magisch hinzuzufügen.

Während mir in C++ eine Klasse ganz genau sagt, von wem sie Eigenschaften bekommen (geerbt) hat, kann in Rust jeder Typ im Nachhinein durch ein Trait “erweitert” werden. Übersichtlich ist das nicht.

Keine Trennung von Kernsprache und Bibliothek

Während in C++ Operatoren als Teil der Kernsprache überladen werden können, nutzt Rust (für mich willkürlich definierte) Traits.
Wer für eine Struktur das Trait std::ops::Add implementiert, der kann dann seine Instanzen mit obj1 + obj2 addieren, was ja schön und gut ist.

Doch dass dafür von der Kernsprache in einen Bibliotheksnamensraum hineingegriffen werden muss um das Operatorsymbol + zu “überladen”, ist meiner Erfahrung nach kein guter Designansatz.

Uneinheitliche Typenbestimmung

Der Rust-Compiler rät sehr geschickt herum um den Typ einer Variablen festzustellen. Man könnte diesen explizit festlegen, doch das macht man nur, wenn es sein muss.
Wann man was definieren muss scheint mir recht kompliziert definiert zu sein. Manchmal reicht ein _ als Platzhalter, dass der Compiler später den Typen einfügt, manchmal nicht.

Manchmal braucht man den “Turbofish” (mit Ähnlichkeit zu expliziten C++ Template Instanziierungen, z.B.: foo().bar::<Vec<i32>>::()), um Typen festzulegen, weil es nicht anders geht, und manchmal errät der Compiler alles ohne Typenangaben.

Selbst unser Trainer im Kurs konnte das nicht immer so genau sagen.

… und vieles mehr …

Ich will jetzt gar nicht von der hässlichen Lifetime-Syntax wie
fn foo<'a>(x: &'a i32) anfangen, kurz gesagt: Rust ist so fremdartig, dass es wenig Anknüpfpunkte (und Zusammenarbeit) mit anderen Sprachen gibt.

Fazit

Der für mich größte Nachteil von Rust ist: Es hat kein standardisiertes ABI um seine Features ins System exportieren zu können, schlimmer noch, es will auch gar keines.
Rust kann Bibliotheken und Sourcen nur in ein großes Binary zusammenkompilieren.

Das entspricht reinen statischen Bibliotheken in C++. Und das fände ich eigentlich sogar ganz gut … doch dass man eben gar keine nativen Rust DLLs oder SOs (ohne Kunstgriffe) erzeugen kann, ist eine kritische Einschränkung.

Einzige Option: eine C-API. Man kann Rust Code in C-Funktionen kapseln, damit sie von anderen Modulen benutzt werden können. Doch genau hier gehen dann alle Sicherheitsfeatures von Rust wieder verloren und man muss die sicheren Rust-Strings in Null-terminierte-C-Strings umwandeln, usw.

Als Sprache finde ich Rust allerdings sehr interessant und ich hoffe, dass C++ noch einiges daraus lernen wird.
Für mich wird es jedoch über eine “einfache” C-Anbindung vermutlich wenig Gründe geben, irgend etwas in Rust zu machen.

Dafür habe ich in C/C++ einfach schon 15 Jahre Vorsprung.

Außerdem … inzwischen gibt es ja mit ZIG die nächste Programmiersprache, die besser und performanter als Rust sein soll. Und wenn immer alle von vorne anfangen “ihre eigene” Sprache neu zu entwickeln, gibt es auf lange Sicht auch keinen Fortschritt.

GCC: Statische Optimierungen

2023-02-05T12:00:00+01:00

Statische Bibliotheken gehören bekanntlich zu meinen Lieblingen, und auf Plattformen wie DOS sind sie sowieso eine Notwendigkeit.

Doch trotz Link-Time-Optimization und anderem Schnickschnack sind die fertigen Programme meist größer als unter Windows. Und teilweise sogar verdammt übergroß.

Ein moderner MSVC erzeugt gerne eine 100 KB große EXE für ein einfaches hello_world Programm, wenn die C-Runtime statisch gelinkt wird. Der GCC unter Linux oder OpenWatcom für DOS sind da schon kompakter mit 10 bis 40 KB.
Das ist auch halbwegs “OK”, wenn man an die vielen Patches und System-Call Wrapper denkt.

Trotzdem fällt mir auf, dass MSVC Binaries gerade beim GATE Projekt nicht so rasant anwachsen, wie auf anderen Plattformen.
Sowohl der GCC wie auch OpenWatcom produzieren gleich 200 KB große Binaries, wenn sie gegen die statische GATE-Core Bibliothek linken.

Ein Blick in die Binaries erklärt das auch:

Da waren alle Funktionen der GATE Bibliotheken enthalten.

Während der MSVC nur die benutzten Funktionen in die EXE packt, legen GCC und Watcom auch alle unbenutzten Funktionen bei.

Es wird also Zeit für ein Build-Update.

GCC

Jede nicht statische (also extern) Funktion wird im GCC als “öffentlich” markiert. Das bedeutet in .so Shared Objects, dass sie exportiert wird.
Programme exportieren jedoch nichts, sondern rufen nur jene Ketten von Funktionen auf, die irgendwo in main() anfangen.
Doch da der GCC auch alles unbenutzte beilegt, werden Programme unnötig groß.

Lösung: attribute ((visibility (“hidden”)))

Ich baue Shared-Libs grundsätzlich mit der default-Visibility hidden, doch bei Programmen habe ich das bisher nie benutzt.
Die Alternative ist natürlich, dass man das “Exportier-Makro” aller Funktionen explizit auf __attribute__ ((visibility ("hidden"))) schaltet.

1#if defined(GATE_COMPILER_GCC)
2#  define GATE_API_EXPORT __attribute__((visibility ("default")))
3#  define GATE_API_IMPORT
4#  define GATE_API_LOCAL __attribute__ ((visibility ("hidden")))
5#endif

 1#if defined(GATE_SHARED_LIBS)
 2#  if defined(GATE_CORE_EXPORTS)
 3#    define GATE_CORE_API GATE_API_EXPORT
 4#  else
 5#    define GATE_CORE_API GATE_API_IMPORT
 6#  endif
 7#else
 8#  define GATE_CORE_API GATE_API_LOCAL
 9#endif
10
11GATE_CORE_API int gate_foo(int something);

Watcom

Unter DOS war die Sache noch viel auffälliger. Ich musste das Speicher-Modell auf Medium erhöhen, damit alle Daten in einer GATE-Hello-World EXE Platz hatten. Auch hier zeigte die erstellte .map Datei, dass alle Funktionen der Bibliothek samt Daten und VTBL Strukturen in die EXE gewandert waren.

Lösung: `-zm` und `opt el`

Wenn man das Compiler-Flag -zm anhängt, werden Funktionen in eigene Segmente ausgelagert. Und die Linker-Option ELIMINATE, löscht dann alle diese Fragmente, die nicht vom Programm aus aufgerufen werden.

In CMake für Watcom sieht dass dann so aus:

1set(CMAKE_C_FLAGS_RELEASE "${CMAKE_C_FLAGS_RELEASE} -zm")
2set(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE} -zm")
3set(CMAKE_EXE_LINKER_FLAGS_RELEASE "${CMAKE_EXE_LINKER_FLAGS_RELEASE} opt el")

Fazit

Kleine EXE, große Wirkung!

Gerade, wenn man OpenSSL oder libSSH2 statisch in sein Programm mit aufnimmt, kommen hunderte wenn nicht tausende Funktionen hinzu, die man nie braucht. Alle bekommt man leider nie weg, weil sie oft in Strukturen zusammengefasst werden, aber wenn man zumindest einige “eliminieren” kann, schrumpft das finale Programm dann schon ordentlich.

So wurde meine DOS-EXE von 135 KB auf 35 KB reduziert.
Und der GCC verbuchte für das alte 200 KB Binary nach der Kur nur noch 25 KB.

Damit wurde der MSVC mit seinen 100 KB Babyspeck deutlich geschlagen und die großen 4-MB Programme sind jetzt auf Windows und Linux ziemlich gleich groß.

Wenn also etwas unnatürlich groß aus der Compiler-Fertigung herauskommt, gilt:

Nicht verzagen, Compiler-Handbuch fragen!

Denn dort findet man (nach langem Suchen) meist den Grund und die Lösung.

Nachtrag: Wakanda forever

2023-02-04T12:00:00+01:00

Im November hatte ich Black Panther - Wakanda forever im Kino gesehen.
Ich wusste damals nicht so recht, was ich darüber schreiben soll. Nun ist der Film auf Disney+ erschienen und ich weiß es immer noch nicht.

Aber weglassen darf man den Film auch nicht!

Das schlimmste, was einem in einer Fernsehserie passieren kann, ist, wenn einem der Hauptdarsteller abhanden kommt.
Und da die Marvel-Filme eigentlich eine Langzeit-Serie sind, trifft das dort auch zu.

Chadwick Boseman der Darsteller des Black Panther ist 2020 verstorben … und so wie es mit vielen ikonischen Rollen der Fall ist, wird es meiner Meinung nach nie wieder einen so guten Black Panther geben können.

Trauer und Neustart

Achtung Spoiler!
Ich denke, kein Marvel-Film hatte es so schwer geschaffen zu werden wie dieser. Die gesamte Story musste an die Realität angepasst werden, nämlich an den Tod des Darstellers.
Und somit ist es nicht verwunderlich, dass das Ergebnis irgendwie zusammengewürfelt wirkt, und dass Letitia Wright als Shuri weder als Schauspielerin noch als Filmfigur in die Rolle des neuen Black Panther passt.

“Das Mädchen” war super als kleine Schwester des Black Panther gecastet und wirkte als ein “Geschmacksverstärker” für den Erfolg des ersten Teils.
Doch als neue Superheldin, konnte mich Shuri leider nicht überzeugen, und vielleicht gab ihr auch der beschleunigte Film nicht die notwendige Zeit dafür.

Ich ignoriere mal, dass wieder aus dem Nichts heraus eine neue übermächtige Partei eingeführt wurde, die seit Jahrhunderten unter dem Meeresboden lebt und erst jetzt auf einmal Herrschaftsansprüche stellt und Wakanda vernichten will.

Nein, das schlimme war eigentlich die End-Credit-Szene.
Da wird mit Mühe und Not eine weibliche Black-Panther aufgebaut, die dann doch noch alles gebacken bekommt, doch dann wird ein Geheimnis gelüftet:

Der Black-Panther hatte bereits einen Sohn gezeugt und vor der Welt versteckt, damit ist “der Geist” des Vaters noch in der Welt und alles wird gut.

Ich weiß, die Szene war so nicht gemeint … aber trotzdem bleibt für mich jetzt übrig, dass Frauen es einfach nicht bringen, doch der nächste Mann ist schon da und wird wieder übernehmen, damit alles wieder in Ordnung kommt.

Zugegeben fällt mir auch nichts besseres ein, wie man mit der Ausgangslage den Film noch hätte retten können, doch … hätten wir am Ende eine Tochter und nicht einen Sohn gesehen, wäre die Blutlinie auch bewahrt worden und wir hätten die erste weibliche Superheldin von Wakanda nicht gleich wieder auf die Wartebank geschickt.

Fazit

Wakanda Forever gehört definit ins MCU und jeder sollte ihn gesehen haben. Aber vielleicht nicht wegen seines Inhalts, sondern als Beweis dafür, dass auch unter schwierigsten Bedingungen das Team weitergearbeitet hat um diese Werk fertigzustellen.

Wir lernen daraus, dass man nicht aufgeben darf, sondern stets in Richtung Ziel wandern muss. Manchmal kann man hinsprinten … und manchmal muss man sich hinschleppen. Aufgeben gilt nicht!

Und diese Message war gerade während der Corona-Pandemie (in der der Film entstanden ist) wichtiger als alles andere.

Sound-Karten

2023-01-29T12:00:00+01:00

Verblüffenderweise wäre ich eigentlich “zu jung” für Soundkarten, denn etwa ab dem Jahr 1997 wanderte die Audiofunktion eines PCs auf das Mainboard und war “Standard”.

Doch da ich bis nach 2000 immer 5 Jahre alte Gebrauchtgeräte besaß, durfte ich dieses Phänomen auch noch miterleben.

Naja … stimmt nicht ganz, 1995 erhielt ich meine erste Soundkarte als ISA Erweiterungskarte für meinen 80486. Die Story war eine typisch komische:
Mein Vater kaufte mir gönnerhaft “PC-Lautsprecher” mit der netten Info der Verkäuferin im Discounter:

Die steckt man hinten am Monitor an.

Ja … beim Mac vielleicht, aber nicht an einen PC Monitor von damals.
Und weil ich dann meiner Mutter so leid tat, die mich traurig mit den nutzlosen Boxen herumsitzen sah, wurde dank der Beratung im “Computer-Geschäft” eine Soundkarte nachgekauft.

Die damaligen Preise habe ich nicht mehr im Kopf, doch die Soundkarte war etwa 3x teurer als die Boxen.

WAV, AVI und MIDI

Zwischen 95 und 2000 lief eine heute nicht mehr nachvollziehbare Revolution. PCs waren seit 15 Jahren eigentlich primär Schreibmaschinen mit Monitor und verwalteten Bürodokumente, Listen und einige wenige Bilder.
Doch mit dem Pentium und Windows 95 kam der Wechsel von 16 Farben auf 256, 65000 und 16 Mio. Farben auf den Bildschirmen und langsam verbreiteten sich immer mehr “Videoclips” auf den Heft-CDs von Zeitschriften.

Kleine unkomprimierte AVI Dateien mit anfangs 180 x 120 Pixel zeigten Ausschnitte von Fußballspielen und anderen Ereignissen.
Und ich sah diese vorher immer als Stummfilm.

Mit der neu installierten Soundkarte wurde der PC zum Videoplayer und ich fühlte mich damals wie in einer neuen Welt, in der ich am Schaltpult saß und per Maus “den Film” in Sekundenschnelle vor und rückspulen konnte.
(Wer weiß noch wie lange das Hin- und Herspulen auf VHS-Videorekordern dauerte…)

Doch Ton war teuer, da MP3 noch nicht erfunden und die Hardware gar nicht schnell genug für die Dekompression war.
Um dennoch “Musik” anhören zu können, sammelten Menschen wie ich die wenige Kilobyte große MIDI Dateien, die auf genannten Heft-CDs und Spiele Demos enthalten waren.

MIDI speichert quasi die Notenblätter einer Musikstückes für eine bestimmte Anzahl vordefinierter Instrumente.
Zwar klang ein “Piano” in MIDI nicht immer wie ein Piano, doch die digitalen Instrumentennachahmungen hatten auch ihren eigenen Charm und prägten das “IT Gefühl” der damaligen Zeit.

Das Besondere (ob gut oder schlecht sei dahingestellt) an MIDI Dateien war, dass sie auf jeder Soundkarte etwas anders klangen. Vermutlich war alles am original Soundblaster ausgelegt, und die Nachbauprodukte versagten teils die Töne identisch nachzubilden.
Erst einige Jahre später mit höheren DirectX Versionen hat zumindest Microsoft den Software-Synthesizer eingeführt, womit MIDI-Klänge wieder PC-übergreifend einheitlich waren.

Varianten wie AC’97

In Sachen Programmierung kam ich erst nach 2007 mit “Audio” in Berührung. Damals war die Welt schon durchstandardisiert, wobei Windows bis heute seine klassische Audio-Codec-API mitliefert und in Linux ALSA weite Verbreitung findet.

Einen PCM-Output-Puffer zu den Lautsprechern und einen PCM-Input-Puffer für das Mikrofon gibt es auf beiden Systemen und sie lassen sich damit “ähnlich” programmieren.
Damit der Ton nicht kurz unterbrochen wird und ein Knacken hörbar wird, nutzt man mehrere Puffer, wo immer einer dem System verarbeitet wird, während die anderen vorbereitet werden. Ringpuffer sind da eine Möglichkeit.

Ein interessanter Aspekt war unter Windows der “Mixer”, über den Lautstärken auf der Soundkarte geregelt werden konnten.
Bei der Ausgabe konnte man entweder die einzelnen Ausgabeverbindungen manuell regeln, oder man konnte nur alles gemeinsam lauter oder leiser stellen. Das hing von der Hardware bzw. vom Treiber der Soundkarte ab.

Und so musste man im Code durchprobieren, welche Variante hier wirksam war. Am Ende musste der Code auf mehreren Soundkarten und Treibern getestet werden, damit ein scheinbar so einfaches Feature wie “laut-leise” überall funktionierte.

Fazit

In der heutigen Streaming-Zeit ist es unvorstellbar, dass PCs von sich aus nicht mit Sound umgehen konnten. Und selbst die kleinsten SOCs wagen es nicht, ohne eine 3,5 Klinkenbuchse für den Audioausgange ausgeliefert zu werden.

Im professionellen Bereich gibt es auch heute noch Soundkarten, wenn man zig Ein- und Ausgänge für die Tonabmischung benötigt … doch für das einfach Volk bringt wirklich jedes Gerät vom Rasperry PI bis zum Gaming-PC den Ton bereits mit … im Zweifelsfall wird er dann noch über USB veredelt.
Soll heißen, man steckt einen USB-Soundchip an, der die Ein/Ausgabe regelt oder direkt per Funk an die Kopfhörer sendet.

Irgendwie ist es schade, dass man heute nicht mehr “Herr der Karten” am Mainboard ist. Denn es war schon lustig unter Freunden und Bekannten herauszufinden, was sie für Ton-Macher verbaut hatten.

Aber wenn ich an die Problemchen von damals denke, wo nicht zwei Apps gleichzeitig Töne abspielen konnten und der Windows-Beep-Sound das Abspielen eines Mediums einfach unterbrach … dann muss ich zugeben:

Heute (ohne separate Soundkarten) funktioniert das alles viel besser.

Win32 Netzwerk-Setup

2023-01-28T12:00:00+01:00

Besonders für “Lizenzen” hatte ich schon öfter den Auftrag, Hardware-Infos auszulesen. Sehr beliebt sind dafür MAC-Adressen. Aber auch für manche Server braucht man die Liste der aktuellen IP Adressen, damit man sich daran binden kann.

Leider hat Windows in den letzten 30 Jahren da einiges geändert und somit braucht man oft mehrere Schnittstellen. ————————————————————

Zu Zeiten von WinNT 4 war die Welt noch einfach.
Grundsätzlich sollte der User gar keine Details über das Netzwerk wissen, sondern nur Laufwerke darüber verbinden und dann “transparent” mit anderen Systemen im Netzwerk Daten austauschen.
Ob da jetzt ein NetBEUI, IPX/SPX oder TCP/IP dahinter benutzt wurde, sollte niemanden interessieren.

Und dann kam das Internet und TCP/IP wurde DER Standard.

Und dann wurde es noch komplizierter:

Wir erhielten mehrere IP’s pro physischen Adapter
Dann tauchten virtuelle Netzwerkgeräte auf
IPv6 kam auch noch dazu
Und spätestens mit Hyper-V wurde ein Adapter in mehrere aufgeteilt.

Wir müssen heute also zuerst mal unterscheiden, ob wir Netzwerkgeräte oder Endknoten (wie IP Adressen) auflisten wollen. Und wegen möglicher virtualisieren kann durchaus eine MAC-Adresse auch mehrfach vorkommen.

Die NT APIs

Mit GetIfTable kommt man bis ins Jahr 1998 zurück, als NT4 SP4 und Windows 98 die API eingeführt haben.
Sie liefert alle “Interfaces” als MIB_IFROW zurück, die im System installiert sind. Früher war das mal das eine IP-Interface, das an den einen Netzwerkadapter gebunden war. Heute liefert die Funktion leider eine Vielzahl von virtuellen und deaktivierten Schnittstellen, womit man erst viele Flags und andere Kriterien auswerten muss, bis man die relevanten Schnittstellen ausgefiltert bekommen hat.

Im Feld wszName finden wir heute die Interface-GUID, mit der man bevorzugt arbeiten sollte, wenn man die Infos mit anderen Schnittstellen abgleichen will. Zu NT4 Zeiten gab es die GUID auf der Ebene noch nicht, sondern man musste über den dwIndex (Netzwerk-Interface-Index) das Gerät eindeutig identifizieren.
Das bDescr Feld gibt uns einen anzeigbaren Namen der Netzwerkschnittstelle zurück und bPhysAddr enthält die MAC-Adresse des verbundenen Adapters.

Die API GetIpAddrTable listet alles in einer struct MIB_IPADDRTABLE auf, was eine IP-Adresse hat oder haben könnte.
Hier kann man eine Verbindung zu GetIfTable über dwIndex herstellen und somit einen Eintrag der “Interface-Table” mit der “IP-Addr-Table” verknüpfen.

Windows 2000 (und teils Win98)

Mit GetAdaptersInfo erhalten wir in Win2K und teils Win98 bereits eine Combo aus Adapter und IP Adressen in der IP_ADAPTER_INFO Struktur. Hier sind dann sogar Gateways und DHCP Infos mit dabei, wie auch die gute alte MAC-Adresse.

Fast könnte man glauben, diese wäre die perfekte API, doch leider listet sie nur “aktivierte” Adapter mit IPs auf. Das reicht für Socket-Bindungen, aber MAC-Adressen für Lizenzen sind dann ein Problem. Außerdem fehlt der Support für IPv6, da es dieses Protokoll damals noch nicht gab.

Windows XP

XP brachte uns daher GetAdaptersAddresses, welches uns auch IPv6 Daten in seinen IP_ADAPTER_ADDRESSES Strukturen liefert.
Hier wird es wieder kompliziert, wenn es um die Verknüpfung mit anderen APIs geht. Der Interface-Index liegt hier nämlich entweder im Feld IfIndex oder in Ipv6IfIndex.

Ich nutze die API daher nur für IPv6 Adressen und hole die anderen Daten über GetAdaptersInfo ab.

Von Windows Vista bis heute

Am Ende kam dann mit GetIfTable2 und der MIB_IF_TABLE2 ab Windows Vista eine aktualisierte Variante von GetIfTable auf den Markt, die uns mehr Flags und Details über die Hardware liefert. So wissen wir, ob es ein WLAN oder Ethernet-Gerät ist, oder ob es nur eine virtuelle Verbindungsbrücke zwischen zB. IPv4 und IPv6 ist.

Die klassischen NT-APIs liefern heute im schlimmsten Fall 60 Geräte, wie bei mir, wenn Hyper-V, WSL und Docker läuft, und dann weiß kein Mensch mehr, welches davon ein Adapter ist, über den eine lokale Anwendung ihre Daten hinausschicken würde.

Andere APIs

Eine hervorragende Alternative zu alle dem ist übrigens WMI, denn dort kann man sich die vielen APIs schenken und WMI-Queries absetzen und die Ergebnisse einsammeln.
Ein paar interessante Queries sind:

1SELECT __Path, Name, GUID, PNPDeviceID FROM Win32_NetworkAdapter WHERE NetConnectionID IS NOT NULL;
2SELECT __Path FROM Win32_NetworkAdapter WHERE GUID='{nif-guid}';
3SELECT __Path, SettingID FROM Win32_NetworkAdapterConfiguration WHERE SettingID='{set-guid}";
4

Die WMI Objekte unterstützen Methoden wie Disable, EnableStatic EnableDHCP oder SetGateways und somit kann man auch gleich die Netzwerkeinstellungen nach Belieben abändern.

Die COM API der Internet-Connection-Sharing Umgebung stellt auch ein paar Methoden bereit, um Netzwerkeinstellungen auszulesen. Ich habe allerdings stets nur das Interface INetConnection zum Ein- und Ausschalten eines Netzwerkadapters benutzt.

Fazit

Im GATE Projekt nutze ich alle nativen Win32 APIs, aber optional. Auf einem modernen Host bekomme ich so also IPv6 Details und Infos, welche Adapter zu streichen sind.
Und dann wird bis zur alten NT4-API alles aufgerufen, was da ist, um den Datensatz anzureichern, der dann am Ende ausgegeben wird.

Ja, die Windows Netzwerk APIs sind kompliziert … aber sie bilden eben 30 Jahre Softwaregeschichte ab … und Geschichte ist immer auch ein bisschen kompliziert.

XMake, das LUA-CMake

2023-01-22T12:00:00+01:00

Die CMake Syntax mag zwar zweckdienlich sein, aber schön ist sie nicht. Es ist keine richtige Programmiersprache, auch wenn es versucht, wie eine auszusehen.

Doch nun kommt XMake … ein CMake Ersatz auf Basis der Scriptsprache Lua.

Problem: Scriptsprachen

Scriptsprachen zur Build-Prozess-Steuerung sind so eine Sache.
Conan setzt auf einem komplizierten Python-Modul auf und braucht je nach Projekt Zusatzbibliotheken um ausgeführt werden zu können.
Das stört sich dann oft auf älteren Systemen mit Python-2 Scripts des OS.

Unix-Shell-Scripts sind wiederum nicht portabel, angefangen bei /bin/sh vs. /bin/bash bis zu den BSD-Shells, und Windows-Batch-Dateien und die verkrüppelte Powershell stellen auch eine andere Gattung dar.

Verdammt! Ich will EINE einfache, portable und systemunabhängige Script-Sprache haben!

Diese Sprache heißt Lua … aber das nur nebenbei.

XMake Einführung

Ich bin eher zufällig über XMake gestoßen, und erfuhr, dass sich jemand die Mühe gemacht hat, Lua für Buildscripts einzusetzen.

Meine Assoziation war: Also ein CMake mit Lua-Syntax.
Das ist nicht ganz richtig, aber auch nicht ganz falsch.

Wer in XMake sein Buildsystem aufsetzen will, platziert in jedem Projektverzeichnis eine Datei namens xmake.lua (ganz genau so wie CMakeLists.txt für CMake) und ruft darin XMake Funktionen auf, die die Statemachine des XMake-Prozesses konfigurieren.

 1target("my_lib")
 2  set_kind("static")
 3  add_files("my_lib.c")
 4target_end()
 5
 6target("my_prog")
 7  set_kind("binary")
 8  add_files("my_prog.c")
 9  add_deps("my_lib")
10  add_links("my_lib")
11target_end()

Es hat sich eingebürgert, dass über Einrückungen zusammengehörende Blöcke optisch sichtbar gemacht werden (wie im Beispiel zwischen target() und target_end()). Notwendig wäre das aber nicht.

Ruft man nun in dem Projektverzeichnis xmake auf, wird eine statische Bibliothek my_lib erstellt und danach das Programm my_prog, welches gegen my_lib linkt.

Jetzt braucht man eigentlich nur noch wissen, dass add_files() auch Wildcards anbietet und dass man aus einer xmake.lua Unterverzeichnisse mit anderen xmake.lua Dateien einbinden kann.

1--root/xmake.lua
2includes("src/lib/lib1")
3includes("src/lib/lib2")
4includes("src/bin/my_project")

1--root/src/bin/my_project
2target("my_project")
3  set_kind("binary")
4  add_files("*.c")
5  add_files("*.cpp")

So kann man nämlich schon viele übliche Projekte mit XMake bauen lassen.

Plattformen und Toolsets

Interessant wird es dann, wann man bei Plattformen ankommt und wenn es um Cross-Compiling geht.

Hierfür stehen dem xmake Tool Parameter zur Verfügung, um z.B. Plattform und Architektur zu setzen, die man in xmake.lua Scripts wieder interpretieren kann:

 1target("my_target")
 2  set_kind("static")
 3  add_files("generic/*.c")
 4  if is_plat("windows") then
 5    add_files("windows/*.c")
 6    if is_arch("x64") then
 7      add_files("windows/x64/*.c")
 8    else
 9      add_files("windows/x86/*.c")
10    end
11  elseif is_plat("linux") then
12    add_files("linux/*.c")
13  end
14target_end()

An der Konsole kann dann per
xmake config -plat=windows -arch=x64 konfiguriert werden, welche Einstellung der folgende Aufruf von
xmake am Ende bauen soll.

Fazit

XMake ist eine neue spannende Welt für mich und ich fange gerade erst an, an der Oberfläche zu kratzen. Es gibt noch viele offene Fragen, wie man “Options”, also Schalter für spezielle Einstellungen gut integrieren kann.
Ein anderer Punkt sind Paketabhängigkeiten, denn XMake kann neben eigenen Repos auch Conan Remotes abrufen und Bibliotheken herunterladen und in den Build Prozess integrieren.

Im GATE Projekt konnte ich bereits einige Standard-Builds mit XMake durchführen und das Ergebnis gefällt mir, weil z.B. für Windows kein msbuild eingesetzt wird, sondern direkt der Compiler und Linker aufgerufen werden.

XMake führt die Builds auch wesentlich schneller aus als CMake, was sich in langsamen Docker-Containern positiv auswirkt.

Ich glaube aber nicht, dass XMake bei mir CMake auf die Schnelle ersetzen wird. Denn wenn es um den Support älterer Hardware oder Compiler geht (z.B.: Watcom), ist CMake dem noch jungen XMake eben 15 Jahre voraus.

Trotzdem liegt in diesem schlanken Projekt natürlich ein großes Potential besonders für neue Projekte.

BSD doas und Linux sudo

2023-01-21T12:00:00+01:00

Sich als root in einem Unix System einzuloggen gehört bzw. ist verboten. In SSH gilt das ganz besonders.

Und nachdem das klassische su auch gefährlich bzw. nachteilig ist, wurde sudo für BSD erfunden, mit dem Linux ebenso glücklich wurde.

Doch den BSDlern wurde sudo auch wieder zu unsicher, weshalb sie mit doas das ganze nochmal neu implementierten.

Die Hintergründe für doas vs. sudo sind eine andere Geschichte, ich weiß nur, dass sudo viele Features und damit Codes umfasst, die ein System wieder unsicher machen können, weshalb doas als entschlacktes sudo neugestartet wurde.

Doch nicht jede Distribution bzw. Installation bereitet dieses Hilfsmittel vor und somit ist der erste Schritt nach einer Linux oder BSD Installation die Einrichtung von sudo oder doas.

sudo unter Linux

sudo fehlt zwar selten in einer Linux-Distribution, doch um sicher zu sein, startet man:

Debian: apt install sudo
Alpine: apk add sudo
SUSE: zypper install sudo

Nun folgt die Definition, welcher Account per sudo root-Rechte erhalten soll. Das wird in der Regel über die Datei /etc/sudoers gesteuert.

Will man den eigenen Account namens myuser zu solchen Rechten verhelfen, reicht die zusätzlich Zeile:

1# WER    WO    ALS-WER  WIE       WAS
2myuser   ALL = (ALL)    NOPASSWD: ALL

Der Benutzer myuser
darf auf jedem Host (erstes ALL)
als jeder Benutzer (zweites ALL)
ohne Passwort (NOPASSWD)
jedes Kommando ausführen (drittes ALL)

Lässt man NOPASSWD: weg, muss man beim sudo Aufruf sein Passwort eintippen.

1myuser ALL = (ALL) ALL

Die bessere und vorgeschlagene Variante ist aber eine andere:
Man erteilt einer Gruppe das Recht, mit sudo alles ausführen zu dürfen und fügt den Benutzer dieser Gruppe hinzu.
Je nach Distribution heißt diese Gruppe entweder direkt sudo oder wheel (früher auch noch admin).

In /etc/sudoers steht eine von folgenden Beispielzeilen:

1%sudo ALL = (ALL) NOPASSWD: ALL
2%wheel ALL = (ALL) NOPASSWD: ALL

Denn mit vorgestelltem % lassen sich alle Mitglieder einer Gruppe ansprechen.

Und wie fügt man seinen myuser Account zur sudo Gruppe hinzu?

1usermod --append --groups sudo myuser

bzw. in Kurzform:

1usermod -a -G sudo myuser

Anwendung

Ein cat /etc/sudoers sollte bei nicht-root Benutzern einen Zugriffsfehler auslösen.
Aber sudo cat /etc/sudoers wird den Dateiinhalt ausgeben.

Interessant ist noch sudo -E my_root_comamnd params, wo die Environment Variablen des nicht-privilegierten Accounts an den privilegierten Prozess übergeben werden. Fehlt -E, so startet der Prozess mit Standard env-Variablen von root.

doas in BSD

Ein fehlendes doas wird einfach per

FreeBSD: pkg install doas
NetBSD und OpenBSD: pkg_add doas

nachinstalliert.

Die primäre Konfigurationsdatei heißt /usr/local/etc/doas.conf in FreeBSD bzw. /etc/doas.conf in Net- und OpenBSD.

Um hier den Account myuser zu berechtigen, sollte eine Zeile auf

1permit keepenv nopass myuser

lauten. Lässt man nopass weg, muss das Passwort eingetippt werden. keepenv überträgt die Umgebungsvariablen des eigenen Benutzers auf den Prozess, der als root laufen soll, ohne keepenv startet den Prozess mit Standard env-Variablen.

Natürlich kann man auch hier gleich alle Mitglieder einer Gruppe (wie wheel) berechtigen mit:

1permit keepenv nopass :wheel

Hier kündigt der : eine Gruppe an.

Um den Benutzer myuser in die Gruppe wheel aufzunehmen, ist das Kommando

1pw group mod wheel -m myuser

erforderlich.

Anwendung

Ein cat /etc/master.passwd sollte allen nicht-root Usern verboten sein, doch mit
doas cat /etc/master.passwd werden die Geheimnisse offenbart.

Fazit

Natürlich kann man in beiden Tools noch viele wunderbare Regeln definieren, und z.B.: nur bestimmte Programme zulassen. Doch auf meinen eigenen Systemen (und auch in manchen Embedded Produkten), reicht es aus, einem speziellen Admin-User per sudo/doas quasi alles zu erlauben.
Denn genau das ist es, was Administratoren am Ende brauchen.

Andere Dienste sollten gar nicht in die Verlegenheit kommen, dass sie mehr Rechte für bestimmte Prozesse brauchen.
Doch falls das wirklich notwendig ist, bieten beide Tools die Möglichkeit, viel feingradigere Abstufungen vorzunehmen.

sudo und doas sind nun seit über 15 Jahren meine stetigen Begleiter, und ich vermute, dass das auch so bleiben wird.

PIPO W12 Upgrade auf Windows 11

2023-01-15T12:00:00+01:00

Schon seit Monaten steht ein Update im Raum, doch bisher wurde es immer wieder verzögert. Mein ARM64 Tablet PIPO W12 lief bisher brav mit Windows 10, doch seit Visual Studio 2022 für ARM64 ist Windows 11 attraktiv geworden.

Seit dem Jahreswechsel schlägt Microsoft selbst das Upgrade vor.

Windows Upgrades auf ARM64 sind etwas Neues, denn da Windows 10 das erste ARM64 OS von Microsoft war, gab es bisher kein “neueres” OS.
Doch genau wie auf X64, war die Strategie eine sehr sehr seltsame.

Auch meine anderen PCs machten diese seltsame Phase durch, dass kurz nach dem Erscheinen von Windows 11 der Upgrade Assistent sofort parat war und die Installation anbot.
Damals verweigerte ich und verblieb bei einer einzigen Win11-Test-Installation in einer virtuellen Maschine.

Wochen später änderte sich dann der Assistent und meinte, dass meine Hardware nicht zum Upgrade auf Windows 11 bereit war. (Es handelte sich um einen Core i3, der eigentlich als Minimum reichen sollte).
Beim PIPO Tablet war das ähnlich, es wurde kurz “generisch” angeboten, dann mit einem Inkompatibilitätsverweis verweigert und seit kurzem erstrahlt wieder der grüne Haken, der das Gerät als Windows 11-kompatibel einschätzt.

Natürlich hätte ich (parallel zu meinen dot-1-mini-PC Installationen) einfach selbst eine neue Windows 11 Installation einleiten können, doch einen gravierenden Unterschied gibt es:

Ich besitze nur Windows 11 IoT für ARM64 in meiner MSDN Subscription, das Tablet kam jedoch mit einem Windows 10 Pro.

Ich kann also nicht die üblichen Windows 11 Home oder Pro ISO Images für ARM64 beziehen, sondern nur die etwas anders aufgebauten IoT Varianten.

Mit dem nun vorgeschlagenem Upgrade hoffte ich also die mir sonst nicht zugängliche Windows 11 Home ARM64 Version zu bekommen.

Update Installation

Der Download und die erste Installationsphase verliefen recht zäh und dauerte über eine Stunde.

Doch danach lief die Windows 11-Upgradeinstallation ganze regulär an. Erst lief die Hintergrundinstallation in der aktuellen Sitzung und dann wurde zum Neustart aufgefordert.

Während des Neustarts wurde das System ausgetauscht und nach einigem Warten erschien dann die übliche Windows 11 Login-Maske.
Auch hier dauerte der erste Login wieder recht lange, doch am Ende war die Installation erfolgreich abgeschlossen wurden.

Auf den ersten Blick war das Upgrade ein voller Erfolg. Ich deinstallierte das alte übernommene Visual Studio X64 und ersetzte es doch Studio 2022 ARM64 und an der Stelle hätte alles in perfektem Zustand enden können.

Kein Touchscreen

Allerdings hatte ich die Neuinstallation ausschließlich über die Tastatur und Maus bedient, die einwandfrei funktionierten. Als ich jedoch das Tablet hochhob und über den Touchscreen bedienen wollte, erfolgte keine Reaktion.
Offenbar war der Touchscreen Treiber nicht korrekt übernommen worden.

Und leider konnte ich auch nach mehreren Herumspielereien dieses Feature nicht mehr zum Laufen bekommen.
Das war ein No-Go, denn ein Tablet-PC “muss” auch ohne Peripherie “von Hand” genutzt werden können.

Am Ende traf ich dann doch die Entscheidung, Windows 11 vollständig neu zu installieren, und zwar meine verfügbare “Windows 11 IOT Enterprise” Variante.

Neuinstallation mit IOT 11

Ein “normales” Windows 11 ARM64 Image startet am PIPO Tablet nicht vollständig, da Treiber fehlen. Diese müssen also vorher in das Windows-Setup-Image integriert werden.

PIPO W12 Driver Installation

Ich hatte natürlich per dism /Export-Driver schon vor dem Upgrade alle Treiber exportiert und gesichert.
Nun nutzte ich die Treiber-Integrations-Prozedur, die ich schon am dot-1-mini-PC erprobt hatte und integrierte die Treiber in boot.wim und install.wim des originalen Windows 11 IOT Images.

Am Ende kam alles auf einen FAT32 USB Stick, den das UEFI des PIPO-W12 problemlos erkannte und die Installationsroutine startete.

Ich löschte alle bestehenden Partitionen und ließ das gesamte Betriebssystem neu installieren.
Auch diese Prozedur dauerte wieder recht lange beim ersten Boot mit der Treiber Einrichtung, doch am Ende landete ich in einem jungfräulichem Windows 11 Login-Screen … aber diesmal mit funktionierendem Touchscreen.

Der Rest verlief wie üblich bei mir:

Account einrichten
Windows aktivieren
WSL und Debian installieren
Visual Studio 2022 installieren

Fertig war das aufgefrischte ARM64-Entwickler-Tablet.

Fazit

Also … ein Upgrade von Windows 10 auf 11 ist auf etwas exotischerer ARM64 Hardware doch ein gewisses Risiko. Es wurden alle außer einem Treiber korrekt neu integriert … doch auf eben genau den einen fehlenden kam es bei mir an.

Ich weiß zwar nicht, warum sich dieser nicht im Nachhinein zur Kooperation überreden ließ, doch am Ende bestätigt sich eine alte Regel, die ich schon in der Jugend aufgestellt hatte:

Eine komplette Neuinstallation ist besser als ein Upgrade.

Denn man schleppt immer irgend welche alten Installationsreste mit, die im Zweifelsfall eher stören.

Und nachdem Nutzdaten bei mir sowieso entweder am One-Drive oder im GIT-Repo liegen, und alle Apps online verfügbar sind, ist eine Neuinstallation oft schneller fertig, als ein Upgrade, wo man dann stundenlang die Probleme beheben muss.

Am Ende war die Aktion also erfolgreich … obwohl nicht so wie erwartet.

CONAN NO_OUTPUT_DIRS

2023-01-14T12:00:00+01:00

Beim ersten conan build Aufruf landen alle finalen Dateien im richtigen Verzeichnis. Man debugged ein bisschen und ruft cmake zur Aktualisierung auf … doch die Binärdateien werden nicht aktualisiert.

Anstatt dessen findet man die Dateien in anderen Verzeichnissen. Willkommen in der Conan (v1) Hilfegruppe.

Wenn Conan den CMake Generator benutzt, stellt dieser diverse Pfade für den Buildoutput ein. Denn Conan “wünscht” sich, dass Ausgabepfade wie bin für Binaries und lib für Bibliotheken benutzt werden.
Doch auch CMake interne Scripts können diese Pfade anpassen. Und so kommt es gerne mal zu Konflikten, die nicht immer gleich sichtbar werden.

Ich hatte in der Firma genau das Problem, dass der erste conan install und conan build Aufruf genau zu den Ergebnissen geführt hatte, die auch zu erwarten waren.

Wenn man nun aber während der aktiven Weiterentwicklung cmake oder make erneut aufrief, um Änderungen nachzukompilieren, landeten sie in den von CONAN definierten Verzeichnissen und nicht dort, wo die CMake Scripts sie hätten ablegen sollen.

Lösung: NO_OUTPUT_DIRS

In von Conan v1 addressierteb CMakeLists.txt Dateien befindet sich in der Regel der Aufruf:
conan_basic_setup().
Diese Makro holt alle notwendigen Variablen für den Buildprozess in das CMake-Projekt und ist unter anderem auch für die “ungewollte” Änderung der Pfade verantwortlich.
Doch die Conan Macher haben dem Makro einige Parameter übergeben, darunter auch:
conan_basic_setup(NO_OUTPUT_DIRS). Damit wird das manchmal störende Verhalten von Conan abgeschaltet und die Kontrolle alleine an CMake übergeben.

Fazit

Es gibt noch ein paar andere Optionen für das Basic-Setup, doch NO_OUTPUT_DIRS zeigt, dass die Conan Macher viele Varianten von Builds schon durchgedacht haben.
Im Standard schreibt Conan alles so um, dass es am Ende möglichst einfach wieder Paket erzeugen kann. Doch da viele CMake Scripts hier manuell eingreifen, kann dieses Feature optional ausgeschaltet werden.

Ein einfältiger Kollege meinte auch gleich, es müsse das gesamte Conan Build-System auf den Kopf stellen um Kontrolle über Pfade zu erhalten.
Naja, ein Blick in die Doku und 14 Zeichen lösen das Problem natürlich auch und beschreiten den vorgesehenen Pfad.

Zugegeben, Conan ist auf Grund seiner vielen Möglichkeiten ein komplexer Moloch geworden … doch je länger ich damit arbeite, um so mehr lerne ich, wie flexibel die Software gestaltet ist.

Und ab Conan v2 wird ohnehin die Verantwortung für den Build viel weitreichender an die Generator-Toolsets abgegeben.
Aber das ist eine andere Geschichte.

Ich schau dir in die Augen, ...

2023-01-08T12:00:00+01:00

Das tolle an den Spielzeugen von James Bond war damals (vor Jahrzehnten),dass es Alltagsgegenstände wie Kugelschreiber waren, die hoch technisch ausgestattet waren.

Es war Science-Fiction, weil man so etwas nicht oder nur sehr schwer bauen konnte.
Doch heute passen Chips auf wenige Quadratmillimeter und stellen an ganz neuen Orten ihre Dienste bereit.

Ich bleibe bei meiner Aussage:

Ich brauche keine Brille, ich brauchte nur ein größeres Display.

Und zum Glück leisten mir meine schwer geprüften Augen immer noch gute Dienste … doch das wird vielleicht nicht immer so sein.

Um so lustiger finde ich es, wenn ich mir eine Fake-Brille aufsetze und mitverfolge, wie ich von Arbeitskollegen nicht mehr erkannt werde. (Clark Kent lässt grüßen).

Und es ist auch interessant einmal zu erleben, wie sich ein Brillenträger so fühlt. Denn selbst die mir nun gut vertraute FFP2-Maske, die mir keine Probleme macht, erweist sich als lästig, wenn man im Bus auf das Brillenglas “hinauf atmet”, womit die Brille sofort beschlägt.

Und dann haben diese unter-20-Euro-Gläser noch eine Zusatzfunktion.

X Megapixel Kamera und Mikrofon

Unglaublich aber wahr, doch in dem etwas dickeren Bügel ist ein Kamerachip samt Micro-SD Kartenmodul verbaut. Ich kann also im 007-Stil durch die Straßen schlendern und dabei die Umgebung mitfilmen.

Ein Mikrofon kann parallel zum Videostream auch noch Laute aus der Umgebung aufzeichnen. Die Qualität ist natürlich nicht “berauschend”, aber ausreichend um Gespräche mitaufzeichnen zu können.

Gesteuert wird die kleine Kamera über einen Knopf an der Innenseite des Bügels.

Steuerung

Mit einem längeren Druck auf die Taste (3+ Sekunden) wird das Modul eingeschaltet und eine rote LED erscheint sichtbar im Blickfeld der Brille, um den Stand-By Modus anzudeuten.

Mit einem kurzen Druck auf die Taste können nun Fotos gemacht werden, die auf die eingelegte SD-Karte gespeichert werden.

Hält man die Taste knapp 3 Sekunden gedrückt, wird der Video-Modus aktiviert. Die LED blinkt kurz rot dann blau und erlischt dann. Nun werden Videodateien samt Audio aufgezeichnet und auf die Karte geschrieben.

Ein kurzer Tastendruck beendet die Aufnahme und schaltet wieder in den Stand-By Modus (rote LED leuchtet) zurück.

Hält man die Taste 5 Sekunden gedrückt, wird das Kameramodul wieder ausgeschaltet und die LED erlischt.

Datenspeicherung

Die Videos werden mit einer Auflösung von 1920 x 1080 Pixel bei 30 fps und 8 KHz Audioabtastung gespeichert. Als Format dienen klassische AVI Dateien, wobei die Video-Frames als MJPEG vorliegen und die Tonaufzeichnung im unkomprimierten PCM-Format kodiert ist.

Die Videos werden in festen Intervallen als neue Dateien gespeichert, bei mir sind 5 Minuten konfiguriert. Eine 5-Minuten-Videodatei belegt dabei zwischen 600 und 700 MB.
Und ich konnte mit einer vollen Akkuladung 16 Videodateien aufzeichnen, bevor sich die Brille ausschaltete, womit 80 Minuten erreicht werden konnten.

Auf der Unterseite des Bügels befindet sich auch ein USB-Anschluss, über den der Brillenakku geladen werden kann (Rot blinkende LED während der Ladung, Blaue LED wenn voll). Außerdem wird bei einer Verbindung mit dem PC der Inhalt der SD Karte angezeigt und man kann Videos und Bilder auf den Computer verschieben.

Fazit

Dieses interessante Spielzeug verändert gerade meine Sichtweise auf die Welt. Denn ich lerne hiermit, wie leicht es ist, Menschen unbemerkt zu überwachen und Daten aufzuzeichnen.

Wer weiß wie oft ich nun schon “gefilmt” wurde und wie bzw. wo diese Daten benutzt werden.
Und auch ich muss mir nun die Frage stellen, wann dich die Brille einschalten will, darf und soll.

Eine Busfahrt und eine Autofahrt habe ich schon mal aufgenommen und muss leider feststellen, dass Gehbewegungen die Aufnahme schwer stören. Außerdem filmt die Brille leicht nach oben und man muss den Kopf senken um Menschen in der Umgebung gut einfangen zu können, ansonsten sieht man nur ihre Köpfe oder weniger.

Wenn man aber ruhig sitzt oder steht liefert die Brille verhältnismäßig gute Bilder und Videos. Die können zwar bei weitem mit einem Smartphone nicht mithalten, sind aber für diese minimalistische Hardware scharf und aussagekräftig … solange man eben nicht weitergeht.

Als Fake-Brille werde ich das Teil also noch häufiger tragen. Wie oft ich sie einschalten werde … tja, das muss ich mir noch gut überlegen.

Nachtrag

Alles Wichtige steht natürlich auch in der Produktbeschreibung:

RDP/DNS Versagen

2023-01-07T12:00:00+01:00

Da versuche ich - wie so oft - meinen Windows Server per RDP zu erreichen und sehe ein:

Your computer could not connect to another console session on the remote computer because you already have a console session in progress.

… aber ich hatte gar keine laufende Verbindung.

Lösung bei mir

Ein einfaches

1ipconfig /flushdns

sollte nur zwischengespeicherte DNS Namen und IPs löschen … doch tatsächlich, nach der Ausführung konnte ich mich per RDP wieder zum Server verbinden.

Keine Ahnung, was da im Hintergrund passiert ist, vielleicht hatte mein lokal laufender Hyper-V Dienst was damit zu tun oder mein PC war zu lange online oder überlebte eine VPN Sitzung nicht.

Fazit

Caches zu Löschen ist ein guter Tipp um unerklärbare Probleme zu beheben. Man muss nur leider herausfinden, um welchen Cache es sich handelt.

Dass der DNS-Cache der Grund für die obige Fehlermeldung war, hatte ich so nicht erwartet …

Tja, man lernt eben nie aus!

Mein C64 lebt wieder

2023-01-06T12:00:00+01:00

Vor einiger Zeit wollte ich ihn nochmals starten … doch es klappte nicht. Nun habe ich ihn erneut zu mir geholt, meinen C64, ihn zerlegt, gereinigt und wieder zusammengesetzt.

Und wenn man dann auch noch das richtige Monitor anschließt … dann sieht man: COMMODORE BASIC, wie es sich gehört.

Wenn Hardware 30 Jahre übersteht und dann noch funktioniert, dann nennt man das entweder “Wunder” oder “höchste Qualität”.

Als ich meinen C64 am Zweitwohnsitz am originalen Monitor startet und dieser schwarz blieb, dachte ich, das war es jetzt. Doch nun stellte sich heraus, das Gerät selbst funktioniert (meistens).

C64 von außen und innen

C64 von vorne:

Links:

2 Joystick oder Mouse-Ports
Ein/Aus-Schalter
Stromzufuhr vom Netzteil

Rückseite:

Expansion Port für Erweiterungskarten
TV/Monitor Ausgang
A/V Composite Video bzw. S-Video
Serieller Port für Diskettenlaufwerk
I/O Port für Datasette
User-Port, unterschiedliche I/O Pins für Peripheriegeräte.

An der Unterseite befinden sich die Schrauben die den Tastaturoberteil und den Mainboard-Unterteil zusammenhalten.

Öffnet man den Brotkasten, fällt ein Alufolie auf, die das Keyboard vom Mainboard trennt.

Darunter befindet sich dann das C64 Mainboard:

Die (extrem verdreckte) Tastatur war der spannende Teil, denn alle Tasten saßen auf Sprungfedern über den Druckpunkten. Bei der Entfernung der Tasten war etwas Kraft notwendig, und leider brach mir bei einer Taste der Stift unter der Taste ab. Es empfiehlt sich also behutsam vorzugehen.

Die Unterseite des Keyboards ist nicht so besonders spektakulär. Nur die Shift-Lock Taste unterscheidet sich mit einem speziellen Bauteil von den anderen Tasten.

Reinigung

So viele Wattestäbchen habe ich schon lange nicht mehr verbraucht, denn mit etwas Brennspiritus putzte ich alle Chips der Platine und auch die verdreckte Tastatur.
Die Tasten genossen ein kurzes Seifenbad, nur die Sprungfedern ließ ich unbehandelt, da sie noch relativ gut aussahen und nicht weiter rosten sollen.

Nun sind Tasten und die Mainboard-Bauteile wieder großteils staubfrei.

C64 Monitor im Programm-Fenster

Bei meiner C64 Ausrüstung war auch ein Adapter des C64-A/V Ausgangs nach Composite Cinchstecker enthalten, und da erinnerte ich mich, dass ich vor Jahren mal ein USB-Gerät gekauft hatte, mit dem Filme von VHS-Videorekordern übertragen werden konnten.

Es war quasi eine primitive USB-TV-Capture-Karte mit Cinch-Eingängen und eben diese Verband ich mit dem C64-Teil.

Windows erkannte das Gerät und installierte den generischen USB-Capture Treiber.
Nun startete ich VirtualDUB und fand das neue Capture-Device, mit welchem ich die Videoaufzeichnung startete. Kaum schaltete ich den C64 ein, erschien in Graustufen das übliche C64-BASIC Build. Ich konnte sogar ein kurzes “Hello” Basic-Programm eintippen und ausführen:

Fazit

Wow! Ich bin wieder voll motiviert.
Mein C64 läuft wieder und ist für alle Schandtaten bereit.

Die Tastatur ist leider nicht mehr ausreichen funktionsfähig, da viele Tasten nicht richtig funktionieren oder nur nach vielen Aufwänden ein Zeichen an das System senden.

Trotzdem liebe ich den alten Brotkasten alleine dafür, dass er nach 30 Jahren wieder erfolgreich anspringt.

Ich hoffe, wir beide werden noch viele glückliche Jahre miteinander haben.

Happy New Year 2023

2023-01-01T12:00:00+01:00

Das neue Jahr ist da - Hurra!

Trotz Knallgewitter gegen Mitternacht, steht die Welt noch.

Ich blicke etwas unsicherer in die Zukunft als das die letzten Jahre der Fall war, schließlich tobt immer noch ein Krieg in der Nähe. Wirtschaft und Politik sind auch gerade nicht berauschend, und wie es aussieht hat über Nacht auch noch Aliexpress die Lieferung von Waren nach Österreich eingestellt.

Hmm … nicht gerade die besten Aussichten möchte man meinen.

Aber, dann schaue ich mich um, stelle fest, dass es mir an nichts fehlt, dass auch mehr als genug Arbeit (und Vergnügen) auf mich wartet, und dass es allen wichtigen Menschen gut geht.

Was soll also der Pessimismus?

Für Wirtschaft und Politik kann jeder einzelne mit gutem Beispiel voran gehen und einfach seinen Beitrag leisten.
Einen Krieg kann der einzelne nicht verhindern, aber jeder kann daran arbeiten, dass kein weiterer ausbricht und dass man den Opfern bestmöglichst hilft.

Und Aliexpress dürfte sich gerade wegen neuer Verpackungsgesetze umstellen, das heißt, auch das wird sich nach einiger Zeit lösen.

Ich erwarte nun sehnlichst das neue CMake 3.26 Release, was dieses Monat rauskommen soll und ARM64 Assembler Support (MARMASM) mitbringt und spiele aktuell mit dem Developer-Build herum.

Und nach dem üblichen Weihnachtsfest-Fressen sind jetzt wieder einige Kohlenhydrat-reduzierte Wochen angesagt.

Am Ende ist also doch alles im Rahmen, das Rad kann weiterlaufen und daher wünsche ich allen:

Prosit Neujahr!

The same procedure as every year

2022-12-31T12:00:00+01:00

Das Jahr ist um - na bumm!

Irgendwie ist 2022 ein kurzes, vertanes Jahr für mich gewesen.
Ich weiß nicht warum es so schnell vergangen ist, und ich kann auch nicht wirklich großes davon berichten kann.

Es war wie wenn man zu Mittag im Sessel einschläft und am Abend aufwacht und nicht weiß, wo die Zeit geblieben ist.

Bestimmt war es auch ein Jahr der Umwälzungen, in welchem die Schrecken des Krieges nahe an unserer Haustüre wieder aufgekommen sind. Da habe ich mir zum Spaß Anfang des Jahres noch ein Squid-Game Kostüm und eine Militäruniform bestellt um einen “dummen Streich” damit zu planen, und stelle jetzt fest, dass es plötzlich überhaupt nicht mehr komisch ist, Krieg zu spielen.
Das war bisher so weit weg, dass man es gar nicht mehr ernst genommen hat.

Vielleicht liegt es daran, dass sich “außen” so viel geändert hat, dass man die Innenarbeiten gar nicht mehr wahrnimmt. Die Pandemiejahre 2020 und 2021 waren letztendlich auch nicht lustig, aber schlimm habe ich sie nicht empfunden. Doch mit 2022 weiß ich nicht, was ich so recht damit anfangen soll.

Doch … zumindest ein paar Dinge sind gleich geblieben. Draußen knallt es, die Kinder freuen sich, Hunde und Katzen eher weniger. Aber so ist das eben an Silvester.
Und obwohl sich so vieles geändert hat, freut es mich dann doch, dass sich einige Dinge eben nie ändern.

Und wenn es allen anderen gelingt, gut gelaunt ins neue Jahr zu rutschen, dann will ich mir den Spaß auch nicht nehmen lassen.

Guten Rutsch!

Mac Mini 2009 Upgrade

2022-12-30T12:00:00+01:00

Mit 2 GB RAM und einer 2.5 Zoll HDD ist mein alter Mac Mini nicht gerade zu Spitzenleistungen nach heutigen Kriterien befähigt.

Jeden PC hätte ich längst aufgerüstet … doch ein Apple Gerät zerlegen … das hatte ich mich bisher nicht getraut.

Nun ist die Zeit gekommen das Wagnis einzugehen.

Wie man einen Mac Mini 2009 zerlegt …

Den Mac-Mini zu öffnen ist schwerer als eine Kokosnuss zu knacken. Tatsächlich ist “die Box” schraubenlos zusammengesteckt, doch ich musste unsäglich lange mit hauchdünnen spitzen Werkzeugen herumfuhrwerken, bis sich die “obere Schale” vom unteren Mainboard-Teil löste.

Abnehmen der Ummantelung

Hier die Schale:

Und der Kern:

Witzig sind die diversen Antennen für WLAN und Bluetooth, die an Sprungfedern an der Seite eingeklinkt sind.
Diese muss man nämlich vorsichtig entfernen und vom Mainboard abstecken, um den oberen Teil mit dem DVD-Laufwerk entfernen zu können.

Abkoppelung des Laufwerksrahmen

DVD-Laufwerk und Festplatte sind auf einem eigenen Plastikrahmen angebracht, der mit 4 Schrauben am Mainboard befestigt ist, und die Daten laufen über ein dünnes Flachbandkabel, das man vorsichtig abziehen muss.

Verbindung zwischen Mainboard-Adapter und Laufwerksteil:

Schraubsockel des schwarzen Laufwerksrahmen links unten:

Upgrade von RAM und Festplatte

Hat man aber diese heiklen Absteckaktionen hinter sich, kann der obere Laufwerksteil entfernt werden und das eigentlich Mainboard kommt zum Vorschein.
Hier kann man nun RAM nachrüsten:

Und die Festplatte durch eine SSD ersetzen.

Laufwerksrahmen von unten:

Laufwerksrahmen von oben:

Erneute Zusammensetzung

Beim Anschließenden Zusammensetzen habe ich ganz besonders an den kleinen Steckkontakten für die Antennen gelitten. Einer war nämlich unter dem Laufwerksrahmen angebracht und die Verkabelung war leider zu kurz, als dass ich sie im Vorfeld hätte anbringen können.
Mit Pinzette und viel Weinen bekam ich den Stecker auch von außen wieder angeschlossen:

Upgrade mit Problemen

Mein Plan war es ursprünglich, den RAM zu verdoppeln und die Festplatte durch eine schnellere SSD zu ersetzen.

RAM Upgrade mit Problemen

In den beiden RAM Slots steckten 2x 1 GB DDR3 Module. Mein Plan war es, diese auf 4 GB aufzustocken, indem ich 2x 2 GB Module einsetzen wollte.

Doch der erste Start ließ das Board mit einem Piepton alle 5 Sekunden nicht mehr regulär booten. Nach einigem Herumprobieren fand ich leider die Ursache:
Ich muss wohl einen der RAM-Slots irgendwie beschädigt haben, denn sobald ein RAM-Riegel in den unteren Slot eingeführt wird, startet das Board nicht mehr.

Sowohl die alte RAM-Bestückung, wie auch unterschiedlichste Kombinationen des neuen RAMs führten immer zum Ergebnis, dass beim Einsatz des unteren Slots das Board nicht mehr startet.
Wird nur der obere Slot befüllt, läuft MacOS ganz normal an.

Meine Lösung war daher in den oberen Slot ein 4GB DDR3 Modul einzubauen und den unteren Slot frei zulassen, und so funktionierte es am Ende auch.

Schade eigentlich, denn ich dachte, so könnte ich meine alten 2 GB Module sinnvoll verbauen.

SSD statt HDD

Da ich keine Ahnung hatte, ob und wie ich MacOS auf dem Gerät neu installieren konnte, kopierte ich einfach den gesamten Inhalt der 160 GB Festplatte Sektor für Sektor auf eine neue 256 GB SSD.

Das dauerte zwar eine Zeit lang, war aber am Ende erfolgreich.
Der Start von MacOS funktionierte auf Anhieb und war auch schneller, als ursprünglich am alten Laufwerk.

Fazit

Ich müsste lügen, wenn ich sagen würde, ich hätte meinen Mac-Mini sehr vermisst. Doch es ist gut zu wissen, dass das Gerät nun zumindest ein bisschen aufgefrischt ist.

Mein Software-Update vor zwei Jahren hat dem Modell in Sachen Performance nicht gut getan, doch mit der neuen SSD und mehr RAM läuft es wieder ganz passabel.

Ärgerlich ist nur der nun defekte RAM-Slot.
Ich kann daher nur zu größter Vorsicht aufrufen, wenn dort jemand Hand anlegen will. Vielleicht war es eine elektrostatische Entladung, weil mir sonst kein “Abrutscher” bewusst geworden wäre. Auch konnte ich keine andere physische Beschädigung feststellen.

In Summe war es aber mal eine nette Abwechslung und definitiv ganz anders als bei üblichen PCs oder ITX-Boards.

WinCE Menüs

2022-12-26T12:00:00+01:00

Alle Jahre wieder…
tauchen die gleichen UI Probleme erneut auf.

Ich hatte doch schon mal Menüs in Windows CE angefangen … und wieder abgeändert und wieder noch etwas geändert … und dann lief es nicht mehr.
Oder … hat es überhaupt je richtig funktioniert ?

Es wird Zeit für eine Detailanalyse.

Windows CE ist nicht Windows CE, sondern es ist Windows CE oder (das alte) Windows Mobile. Und im Falle von Windows Mobile ist es ein “Smartphone” von vor 2007 mit Bildschirmauflösungen von 320x240, anders gesagt: Briefmarken-klein.

Jetzt kann man zwar mit CommandBar Controls “echte” Menüzeilen basteln, die dann aber auf diesen Kleingeräten unbenutzbare UIs bedeuten. Und das fällt einem nicht auf bei einem einzigen Menüeintrag, aber bei 3+ wird das schon sehr deutlich.

Die AGYShell von Windows Mobile/CE bringt allerdings ein ähnliches Feature mit, nämlich die beiden “Software-Buttons” am unteren Rand.
Gedacht waren diese “Tasten” für ein schnelles OK oder Cancel, bzw. Zurück und Weiter.
An die beiden schmalen Schaltflächen schmiegt sich in der Mitte auch noch der Keyboard-Button, mit dem man die virtuelle Tastatur ausfahren kann.

Ich dachte mir also, dass das Programm-Menü (Datei, Bearbeiten, usw.) unter Windows Mobile nicht ständig angezeigt werden muss, sondern nur ein Menü Software-Button angezeigt wird, und erst beim Klick darauf, wird das eigentliche Menü als Popup-Menü ausgefahren.
Damit wird kein Platz unnötig belegt und die Programmlogik kann dann genau so aussehen, wie auf einer vollen Desktop App.

Resourcen-Zwang

Die Funktion SHCreateMenuBar erzeugt zwar diese Software-Buttons, doch sie verlangt eine Menü-Ressource in der Programmdatei, und die sieht z.B.: so aus:

1// IDs from shared header
2#define MY_MENU_ID            102
3#define MY_MENU_BUTTON_1_TEXT 103
4#define MY_MENU_BUTTON_2_TEXT 104
5#define MY_MENU_BUTTON_1_MSG  40000
6#define MY_MENU_BUTTON_2_MSG  40001

 1// .rc resource file:
 2STRINGTABLE  
 3BEGIN
 4  MY_MENU_BUTTON_1_TEXT        "OK"
 5  MY_MENU_BUTTON_2_TEXT        "HELP"
 6END
 7
 8MY_MENU_ID SHMENUBAR DISCARDABLE
 9BEGIN
10  MY_MENU_ID, 
11  2,
12
13  I_IMAGENONE, MY_MENU_BUTTON_1_MSG, 
14  TBSTATE_ENABLED, TBSTYLE_BUTTON | TBSTYLE_AUTOSIZE,
15  MY_MENU_BUTTON_1_TEXT, 0, NOMENU,
16    
17  I_IMAGENONE, MY_MENU_BUTTON_2_MSG, 
18  TBSTATE_ENABLED, TBSTYLE_DROPDOWN | TBSTYLE_AUTOSIZE,
19  MY_MENU_BUTTON_2_TEXT, 0, 0,
20END

Im C Code kann man nun auf das MY_MENU_ID Makro verweisen:

 1HWND hwnd_of_windows;
 2SHMENUBARINFO mbi;
 3RECT rc_window, rc_menu;
 4
 5// create menu bar
 6mbi.cbSize = sizeof(mbi);
 7mbi.hwndParent = hwnd_of_window;
 8mbi.dwFlags = 0;
 9mbi.hInstRes = (HINSTANCE)GetModuleHandle(NULL);
10mbi.nToolBarId = MY_MENU_ID;
11SHCreateMenuBar(&mbi);
12
13// resize main window to exclude menu-bar
14GetWindowRect(hwnd_of_window, &rc_window);
15GetWindowRect(mbi.hwndMB, &rc_menu);
16rc_window.bottom -= (rc_menu.bottom - rc_menu.top);
17MoveWindow(hwnd_of_windows, rc_window.left, rc_window.top, 
18    rc_window.right - rc_window.left, rc_window.bottom - rc.top, 
19    FALSE);
20DrawMenuBar(hwnd_of_window);

Anschließend lässt sich in der WM_COMMAND Nachricht die MY_MENU_BUTTON_1_MSG und MY_MENU_BUTTON_2_MSG ID wieder abfangen. An dieser Stelle kann man dann ein übliches Win32 Popup-Menü mit den eigentlichen Menüeinträgen anzeigen lassen.

Fazit

Dieser Workaround funktioniert tatsächlich, zumindest konnte ich im Device-Emulator nun meinen Texteditor laden, der dort sein Menü nur beim Klick auf den Software-Button anzeigt.
Und die gleiche Anwendungslogik erzeugt am herkömmlichen Desktop weiter ein Fenster-Menü.

Mein Anliegen ist damit gelöst … doch man lernt daraus wieder, wie verdammt schwierig es ist, mit “einer API” zwei unterschiedliche Plattformen auf den gleichen Nenner zu bringen.

Das erklärt auch, warum der Trend zu Webanwendungen geht, denn dort ist “Responsive Design” mit ein paar Zeilen CSS erreichbar, während man auf der nativen Seite lange hin und her probieren muss, bis man eine akzeptable Lösung gefunden hat.

Nachtrag: RC in CMAKE

Und wie bindet man jetzt Resource-Dateien .rc in CMake in ein Projekt ein?

Einfach per target_sources:

1if(WIN32)
2  file(GLOB RC_RESOURCE_FILES
3    "*.rc"
4  )
5  target_sources(${PROJECT_NAME} PRIVATE ${RC_RESOURCE_FILES})
6endif(WIN32)

Denn ohne die Resource in der EXE schlägt der Aufruf von SHCreateMenuBar fehl.

Kalter Krieg

2022-12-25T12:00:00+01:00

Wenn es in Wien +5 Grad hat, hat es oben im Waldviertel etwa 5 Grad weniger und vielleicht schneit es dort sogar. Früher hatten wir auch schon mal -15 Grad. Unter +20 Grad lässt meine Heizung die Temperatur in der Wohnung jedenfalls nicht fallen.

Aber … es soll tausende Menschen geben, in deren Häuser Löcher gebombt wurden. Wie warm wird denen jetzt sein?

Ich habe das Privileg in einer Firma zu arbeiten, in der - hier in Wien - ein Russe, ein Weißrusse und ein Ukrainer zusammenarbeiten. Alle sind sie echt “gute Jungs” und halten unsere Controller Hardware und Software am Laufen, finden Fehler und beheben sie.

Und trotz mancher Unterschiede funktioniert das sehr gut.
Es gibt kein physikalisches Gesetz, keine Naturkonstante, die die Menschen zum Krieg zwingt. Und trotzdem vergehen keine 10 Jahre, in denen es auf der Erde einmal “ruhig” zugegangen wäre.

Ich sitze in der gut beheizten Wohnung und kann über den Sinn des Lebens nachdenken … doch 1000 km weiter östlich haben die Menschen ein solches Privileg nicht.

Wie kann es eigentlich sein, dass in einer Welt, in der noch nie so viel kommuniziert wurde wie heute, so effektiv an einander vorbeigeredet wurde, wodurch am Ende die Waffen sprechen müssen?

Vielleicht kommunizieren wir gar nicht, sondern reden nur sinnfrei in den Äther hinein.
In der Technik wäre das Problem schnell gefunden:

Jeder Sender braucht einen Empfänger … und umgekehrt.

Wir haben auf den “Empfänger” vergessen.
Wir hören nicht mehr zu.
Und nichts kann einen wütender machen, als wenn man feststellt, dass einem keiner mehr zuhört.

Es sind nicht nur

die Priester, die von der Kanzel aus predigen, die nicht zuhören.
die Politiker, die nur Reden schwingen und nicht zuhören.
die Youtuber, die sich nur selbst reden hören wollen, die nicht zuhören.
die Twitterer, die nur auffallen wollen und nicht zuhören.

Es sind wir alle.
Auch mich hat es nicht gekümmert, was X km entfernt passiert, obwohl seit 2014 die Krise am Köcheln war.

Was kann man tun?

Tja … Spenden hilft vielleicht das Schlimmste abzuwenden, und wir alle können es uns leisten … wir müssen es nur wollen.

Aber noch wichtiger ist, dass wir den eigenen moralischen Kompass wieder in Gang bekommen und das Gemeinwohl priorisieren, anstatt täglich über eigene Befindlichkeiten zu jammern.

Ich saß neulich im Bus und beobachtete den Alltagsrassismus (ein furchtbarer Begriff). Jederzeit hätte ich aufstehen können und mit wenigen Worten die Situation zu deeskalieren versuchen können.
Aber ich tat es nicht. Schließlich war ich nicht darauf vorbereitet … und es war ja auch nicht meine Angelegenheit, wenn sich zwei Fremde beflegeln.
Und wieder wurde eine weitere giftige Menge CO2 ausgestoßen, die nur Hass erzeugt hat. Und es hätte vielleicht nur so wenig gefehlt, um es verhindern zu können.

Also nehme ich mir das mal als Vorsatz, dass ich mir ein paar Sätze überlege, die man da sagen kann, und beim nächsten Mal tue ich etwas, anstatt nur im Nachhinein halbklug darüber zu berichten.

Und ich hoffe, dass das mehr Menschen versuchen zu tun. Denn wenn jeder “seine Straße sauber hält”, dann können auch die Mächtigen nicht mehr so einfach das Land verdrecken, indem sie Nachbarn bewaffnet auf die Straße hetzen.

Ich wünsche mir für alle Menschen in der Ukraine, genau so wie die unschuldig zum Kriegsdienst gezwungenen Russen, dass sie nächstes Jahr zu Weihnachten in der warmen Stube sitzen und ins lodernde Kaminfeuer schauen können, anstatt einen kalten Krieg befeuern zu müssen.

In diesem Sinne:

Ein frohes Weihnachtsfest …
… hoffentlich nächstes Jahr.

Großvaters Baum

2022-12-24T12:00:00+01:00

Meine Mutter erzählte mir schon so manche interessante Geschichte rund um meinen Großvater, doch eine, die mit dem Weihnachtsbaum, war eine besondere.

Meine Großeltern sind leider früh verstorben, und so habe ich an meinen Großvater so gut wie keine Erinnerung mehr, da ich bei seinem Tod 6 Jahre alt war.
Und obwohl ich noch einige Weihnachtsabende mit Großmutter verbringen konnte, so habe ich überhaupt kein Bild von Weihnachten im Kopf, wo beide dabei waren.

Vor über 60 Jahren

Es gab mal eine Zeit, in der meine Mutter als Kind auf den Weihnachtsabend wartete. Und in jenen Tagen war es Großvaters Aufgabe, im eigenen Wald den richten Baum für das Weihnachtsfest zu finden, zu schlägern und für die Bescherung vorzubereiten.

Und ich finde es lustig zu hören, dass die Wahl des Baumes öfters fast zum Auslöser eines Streites zwischen Großvater und Großmutter geworden wäre.
Denn Großmutter liebte es, die ganze Familie beisammen zu haben und idyllisch unter einem prächtigen Weihnachtsbaum Lieder zu singen.
Großvater hingegen liebte seinen Wald und war stolz auf die schönen Bäume, um die er sich das ganze Jahr gekümmert hatte. Nie hätte er “den besten Baum” nur für eine Woche zu Fall gebracht.

Und so erzählt mir meine Mutter heute noch, wie sie die Worte ihrer Mutter vernahm, die sie vorwurfsvoll an Großvater richtete:

Von allen Leuten im Dorf haben wir den schiefsten und armseligsten Krampen im Zimmer stehen.

Bis zur Bescherung hatte sich der Rauch wieder gelegt und es wurde auch mit dem “nicht-schönsten” Baum stets ein schönes Fest.

Symbole

Ich kann beide Großeltern gut verstehen.

Schließlich verprassen wir wirklich viel zu viele Ressourcen nur für ein paar Tage um ein Bilderbuch-Bild von uns selbst zu malen. Danach fliegen die Bäume auf die Straße und werden zu Müll, anstatt dass sie uns wertvollen Sauerstoff über ihr gesamtes Leben liefern.
Da hatte Opa also recht, wenn er nur den “unschönsten” Baum fällen wollte.

Und dann gibt es da diese vielen Geschichten, von Leid und Armut, und wie ein Ereignis, ein geschmückter Baum wieder Freude in die Gesichter der sonst frustrierten Menschen zeichnen kann. In der Stube sitzt man das ganze Jahr beisammen, doch wenn der Baum im Kerzenlicht erstrahlt, schaffen wir Erinnerungen, über die wir noch Jahrzehnte später sprechen werden.
Da hatte Oma also recht, wenn sie den schönsten Baum haben wollte.

Frohe Weihnachten!

Heute sind meine Großeltern wieder in meinen Gedanken … und vor allem wegen der Geschichte mit dem Weihnachtsbaum.

Obwohl ich viel zu wenig Zeit mit ihnen teilen konnte, weiß ich, dass ich vieles heute nicht hätte, hätten sie nicht so viel Zeit und Arbeit für mich aufgebracht.

Und deshalb teile ich heute die Sprüche, den die beiden meiner Mutter beibrachten, und die sie mich lehrte:

Großvater:

Prahl’ nicht mit dem Erreichten groß! Du stehst auf deiner Ahnen Schultern bloß!
Wie Stein auf Stein empor sich fügt zum First.
Du bist nur Giebel, bis du Sockel wirst!

(Eine freie Fassung von Die Mauer der Menschheit).

Großmutter:

Wenn dich die Menschen auch kränken, weine nicht. Alles kannst du dir denken, sagen nicht. Geh’ immer lachend durchs Leben, hast du auch Kummer und Schmerz Hilfe wird dir niemand geben, denn Menschen von heut’ haben Herz.

Und von meiner Urgroßmutter lernten wir:

Du kannst so jung nicht bleiben, bleib denn so gut und rein. So wirst du stets wie heute, der Liebling aller sein.

Thread oder Fiber

2022-12-18T12:00:00+01:00

Der Aufruf von Sleep() schickt einen Thread schlafen. Aber wenn der Thread ein Fiber ist, wäre es sinnvoller, andere Fibers zu aktivieren, damit die was Sinnvolles tun können.

Doch wie weiß man jetzt, ob man in einem Thread oder in einem Fiber läuft?

Vorgeschichte: Crash auf ARM64

Ich schicke Threads selten schlafen, am ehesten warte ich auf Bedingungen mit Events, Conditions oder anderen Objekten. Eine Ausnahme gibt es allerdings: Bei der Ermittlung der aktuellen CPU Auslastung. Denn hierfür soll der aktuelle Thread wirklich “schlafen gehen”, um danach festzustellen, wie viele CPU Aktionen in der Zwischenzeit außerhalb passiert sind.

Tja und heute sehe ich zufällig einen Crash in meiner Sleep-Implementierung:

In dieser wollte ich nämlich genau diese Unterscheidung machen:

Ist es ein Thread, rufe die OS Sleep() Routine auf.
Ist es ein Fiber, führe ein yield() aus, damit was anderes abgearbeitet werden kann.

Und für die Unterscheidung nutzte ich einfach GetFiberData() und erwartete einen NULL-Pointer, wenn kein Fiber gestartet wurde.

Das ist leider verdammt falsch!

GetFiberData() ist ein Makro, das GetCurrentFiber() und daraus einen Pointer zum Fiber-Datenzeiger ableitet. Dieser wird dereferenziert und genau hier dreht einem der Kernel den Hals um.

GetCurrentFiber() liefert nämlich immer einen Nicht-NULL-Pointer, der aber außerhalb eines Fibers auf “irgendwas” zeigt, nur nicht auf gültige Daten.

Lösung

Windows Vista führte die IsThreadAFiber() Funktion ein, die diese Frage eindeutig klärt. Das heißt, vor einem Get*Fiber*() Aufruf prüft man, ob es sich überhaupt um einen Fiber handelt.

Doch was ist mit Windows XP und älter? Denn hier fehlt diese Schnittstelle.

Meine Lösung ist: IsBadReadPtr(GetCurrentFiber(), sizeof(void*))

Ist dessen Rückgabewert nämlich TRUE laufen wir in einem Thread, ist es FALSE, ist ein Fiber am Werk.

Man könnte natürlich auch per __try/__except/__finally die Dereferenzierung des Pointers gesichert abfangen.

Fazit

Bug fixed.

Hier sieht man wieder mal, wie dumm das ausgehen kann, wenn man einmal Code schreibt, der auf einem anderen aufbaut, und was passiert, wenn man dann 1 Jahr später Koroutinen und Fibers einwebt. Schon ändert sich das Verhalten für einen Fall, den man nicht abgetestet hat.

Mich verwundert, dass IsThreadAFiber() erst 2006 mit Vista eingeführt wurde. Ein solches If-Tool hätte schon im originalen NT 4 1995 drinnen sein müssen.

However … ich habe vorerst einen Workaround und bin glücklich.

WASM: Webassembly mit C/C++

2022-12-17T12:00:00+01:00

Nun finden also meine ersten Ausflüge ins WASM-Land (Web-ASseMbly) statt. Und neben beeindruckender Möglichkeiten sehe ich leider auch eine große Anzahl von Problemen auf mich zukommen.

Denn es wäre doch zu schön, wenn ich einfach meine GATE-Apps für die “Browser-Plattform” kompilieren könnte, und schon läuft alles online.

Vorgeschichte

Heißt das nicht Java-Applet ?

Java ist schon in den 90ern daran gescheitert, als es mit seinen Applets und Midlets jeden Browser infiziert hatte, die dann alle unter Java Sicherheitslücken litten.
Und am Ende wurde die Technologie abgeschaltet.

Seit über 10 Jahren spukt nun der Gedanke im Äther herum, man könne doch native Anwendungen auch “im Web”, also im Browser laufen lassen.
Man müsste Code in eine Metasprache kompilieren, die der Browser dann in nativen Maschinencode umwandelt und abspielt.
… das wäre dann also nochmal dotNet 1.0.

Und daraus entstand asm.js, aus dem sich der heutige WebAssembly Standard entwickelte.

Das heißt also:

Ich schreibe C Code und exportiere C-Funktionen
Ich übersetze den C Code in WASM Dateien
Ich lade Javascript Code im Browser, der meine WASM-Dateien lädt
Ich rufe die in C geschriebenen Funktionen aus JavaScript heraus auf.

(Und natürlich geht das auch mit C++, nur Klassen sind da etwas schwieriger zu verwalten.)

Emscripten + Ninja + CMake

WebAssemblies werden recht einfach mit dem Emscripten EMSDK erstellt. Das ist ein angepasster Compiler mit weiteren Headern und Sourcen, den man herunterladen kann.
Das Setup ist in Tutorials gut beschrieben.

Danach kann man die Environment-Variable EMSDK auf das Installationsverzeichnis setzen und einige weitere Pfade ebenso bedenken:

1set EMSDK=C:\path\to\emsdk
2set EMSDK_NODE=%EMSDK%\node\14.18.2_64bit\bin\node.exe
3set EMSDK_PYTHON=%EMSDK%\python\3.9.2-nuget_64bit\python.exe
4set PATH=%PATH%;%EMSDK%
5SET PATH=%PATH%;%EMSDK%\upstream\emscripten
6SET PATH=%PATH%;%EMSDK%\node\14.18.2_64bit\bin

Jetzt könnte man schon das erste “Hello-World” mit emcc hello.c erzeugen lassen.

Aber interessant wird es erst mit CMake, und dafür brauchen wir unter Windows zuerst das Build-Tool Ninja. Dessen EXE kommt am besten auch in den Pfad:

1SET PATH=%PATH%;C:\path\to\ninja

Und nachdem das EMSDK bereits ein CMake Umgebungstool mitgeliefert hat, braucht man nur noch eine einfache CMakeLists.txt zu seiner C-Datei erstellen und
emcmake cmake path\to\src aufrufen.
Denn emcmake ruft CMake mit den nötigen Parametern auf um Ninja-Buildscripts zu generieren.
Und wenn man am Ende noch ninja im Buildverzeichnis aufruft, startet die Übersetzung und man erhält eine .wasm und eine .js Datei.

Brücke zwischen Browser und WebAssembly

Die Idee ist, dass eine HTML Seite die beim Kompilieren generierte Javascript-Datei lädt, in der zahlreiche Initialisierungsschritte abgearbeitet werden und die WASM-Datei geladen wird.

Hierfür müssen einige Dinge “ausgetauscht” werden:

Der C-Code exportiert Funktionen, in der Regel ist main() die erste Wahl.
Der Javascript-Code definiert selbst ein paar Funktionen, die als Import-Objekte der WebAssembly zur Verfügung stehen (z.B.: Callbacks für das Lesen und Schreiben von stdin / stdout).
Wir erhalten einen Heap-Speicherblock, der von der WebAssembly und Javascript gemeinsam genutzt wird.
Und Javascript importiert C-Funktionen (allen voran main) um diese ausführen zu können.

Jetzt kann man WebAssemblies mit unterschiedlichen “Features” kompilieren lassen und dementsprechend anders sieht dann der Javascript Code aus.
Meine erste Annahme war nämlich, man könnte mit einer “generischen” Javascript-Implementierung alle WebAssembly Features abgreifen, doch dem ist leider nicht so.

Problempunkt: Threading

Wenn ich in Richtung GATE Projekt denke ergibt sich ein gröberes Problem: Ich setze gerne Threads ein, doch diese wiedersprechen dem Javascript async-Gedanken.

Denn in Javascript läuft grundsätzlich nur ein Thread, und wenn etwas system-spezifisches länger dauert, wird es als async Funktion im Hintergrund abgearbeitet. Ein sleep() oder andere Formen von blockierenden Funktionen darf es in dieser Welt nicht geben, weil sonst der Browser einfrieren würde.

Am der Stelle wird es kompliziert und man hat mehrere Möglichkeiten mit unterschiedlichen Seiteneffekten.

Asyncify

Kompiliert man den Code mit der ASYNCIFY Option, wird Code erzeugt, der es erlaubt, laufende C-Funktionen zu unterbrechen … also in etwa etwas wie Koroutinen.
So lassen sich dann sleeps() ohne Störungen ausführen und man könnte auch mehrere Aufgaben “anstoßen”, die schrittweise abgearbeitet werden und “kooperativ” immer wieder den Mainthread weiterarbeiten lassen.

Ein Ersatz für Threads ist das allerdings nichts und die Verwaltung von vielen parallelen Funktionsaufrufen erfordert dann sehr viele Kreuzaufrufe zwischen WASM und dem Javascript-Code im Browser.

Pthreads

Unglaublich, aber wahr: Man kann Webassemblies auch mit POSIX Thread-API Support kompilieren. Hierfür werden die neueren Worker-APIs des Browsers der C-Anwendung verfügbar gemacht, und somit entstehen echte parallele Ausführungsschienen. Diese kommunizieren über SharedArrayBuffer-Instanzen und senden sich so Daten und Zustände zu.

Das Problem daran ist: SharedArrayBuffer ist auf Browsern im Standard gesperrt und kann nur durch spezielle HTTP-Header für “Cross-Origin” Scripting aktiviert werden. Außerdem braucht man dann mehrere Javascript-Dateien, weil Worker Objekte mit unterschiedlichen Dateien funktionieren. Man kann also nicht einfach innerhalb einer Script-Datei einen Worker für eine Funktion anlegen.

Worker API

Man kann aber auch direkt mit Web-Worker Objekten arbeiten und eine riesige Menge an Javascript-Patchcode damit umgehen. Auch hier wird mit SharedArrayBuffer und mehreren Javascript-Dateien gearbeitet und auch dafür muss “Cross-Origin” Scripting am Webserver aktiviert sein.

Zumindest hat man hier aber nur leichtgewichtige Konstrukte vor sich und kann die emscripten-Header nutzen, um neue Worker-Threads zu erzeugen.

Fazit

Puh … wie fügt sich das jetzt in mein Weltbild ein ?

Die bisherige Anbindung von Plattformen an das GATE-Framework verlief so, dass im Framework der Plattform-Support-Layer die Umgebungsdetails wegabstrahiert hat alles auf einen Nenner brachte.

Doch WASM funktioniert im Browser nur in feiner Abstimmung mit externen Javascript-Dateien, die wiederum mit Webseiten abgestimmt sind.

Und dann kommt noch die Threading-Misere hinzu.

Ich bin mir noch nicht sicher, ob und wie ich das mit meinen Vorstellungen vereinen kann, doch eines kann ich bereits sagen:

Das Emscripten SDK ist eine hervorragende Möglichkeit, den Spielraum von C/C++ gewaltig zu erweitern.

Denn bisher waren C/C++ Projekte als reine native System-Binaries abgestempelt. Doch als WASM lassen sie sich über alle Mainstream-Browser auf jedes Gerät übertragen um dort ihr gutes Werk zu vollrichten.

Mastodon, Fosstodon und matrix.org

2022-12-11T12:00:00+01:00

Die sogenannten sozialen Medien, die nachweislich ausschließlich asozial agieren, habe ich nie leiden und nutzen wollen. Vor allem sind sie ungeeignet um intelligente Informationen zu verbreiten, denn die Wahrheit umfasst stets mehr als 500 Zeichen.

Es gab zwar immer schon Open-Source Alternativen auf denen sich die wenigen vernünftigen Techniker herumtrieben, doch Beachtung genossen sie nie.
… bis Elon Musk seine Überheblichkeit öffentlich zur Schau stellte.

Irgendwie beweist sich gerade wieder von selbst, dass Techniker nichts in Wirtschaft und Politik verloren haben und umgekehrt Wirtschaftler und Politiker in der Technik nicht zu Hause sind.

Elon Musk, der (ähnlich zu einem Steve Jobs) in der Technik viele wichtige Innovationen “ertrotzt” hatte, fährt gerade sein frisch eingekauftes Twitter mit reiner Egomanie an die Wand.
Und das gute daran ist, dass durch das Zerbrechen dieses üblen zentralen Zeit-Totschlägers andere weniger schädliche Anbieter ins Rampenlicht kommen.

Mastodon

Seit Jahren wird Mastodon als Open-Source Alternative zu Twitter genannt.
Der größte Vorteil des Systems ist sein “föderierter” Ansatz.
Es gibt nicht “einen” zentralen Server, auf dem sich alle Nutzer tummeln, sondern jeder, der Willens ist, kann seinen eigenen Server aufstellen.
Damit jetzt nicht lauter kleine Inselstaaten entstehen, schließen sich die Server zu einer “Föderation” zusammen, womit jeder im weltweiten Mastodon Netz “suchen”, “folgen” und “teilen” kann.

Richten sich Rechtsradikale, Bombenbauer oder Kinderpornohändler ebenfalls einen solchen Server ein, so kann man das nicht verhindern, doch “die Föderation” kann solche Server ausschließen, womit ihre Inhalte isoliert bleiben und keinen Schaden weltweit verbreiten.

Ich wage jetzt mal den zaghaften Vergleich mit den Inhalten (nicht der Architektur!) von Wikipedia. Dort kann auch jeder Artikel schreiben, doch deren Qualität entscheidet am Ende, ob sie öffentlich bestehen bleiben.

Fosstodon und ich

Das größte Problem bei Mastodon ist, dass man sich jetzt irgend einen Server aussuchen muss, der einem die Mastodon Welt eröffnet und das ist sicher für viele schwierig. Es macht Sinn, sich einen Server mit “Gleichgesinnten” zu suchen, denn von dort wird man mehr relevante “lokale” Infos erhalten.

Bei mir war die Sache vor eineinhalb Jahren einfach: Ich wollte mehr über die Pine64 -Geräte erfahren und deren Community publiziert auf fosstodon.org, wo sich viele Open Source Projekte herumtreiben. Also war klar, dass ich meinen Account dort anlege.

So erhielt ich dann etwa wöchentlich von einigen Community-Accounts Infos zu neuen Releases. Auch Privatpersonen posteten “twitter-like” ihre Tagesmeinung, doch das hielt sich im Verhältnis zu anderen Plapperblasen im Netz sehr in Grenzen.

Seit dem Twitter-Chaos ist die Anzahl der Nutzer und damit das Rauschen und Gerede wesentlich lauter geworden. Mich interessiert das grundsätzlich wenig, doch es hatte auch etwas Positives:
Projekte wie FreeDOS und weitere kamen auch zu fosstodon und veröffentlichten ihre News und so erfuhr ich wieder von neuen Projekten, die ansonsten an mir vorbeigegangen wären.

Es ist also eine Frage des Filterns. 80% der neuen Beiträge sind Geschwafel, doch zwischendurch findet man immer wieder mal Perlen. Und dadurch, dass sich die Vollzeit-Egomanen auf anderen Mastodon-Servern herumtreiben, wo ich sie nicht ständig sehen muss, ist diese “Twitter-Alternative” tatsächlich sogar für mich interessant geworden.

matrix.org

Die Ewig-Gestrigen nutzen den Facebook Messenger, Firmen starten Microsoft Teams, die Möchtegern-Startup-Klugscheißer installieren Slack, die Gamer nerven sich auf Discord … und was sollen Open Source Enthusiasten nehmen?

Ich nenne jetzt mal Matrix, was eher ein Protokollstandard, als ein “Anbieter” ist, doch die Referenzimplementierung auf matrix.org stellt einen freien kostenlosen Kommunikationsdienst bereit, der bereits von vielen Projekten aktiv genutzt wird.

Ich sehe es als eine moderne Alternative zu den früheren Newsgroups und IRC-Chats, die bis Anfang der 2000er verbreitet waren und danach versandeten.

Auch hier kann jeder selbst einen Server aufsetzen und dann mit anderen föderierten Servern in Kommunikation treten. Nutzen kann man die Chat-, Audio- und Videokonferenz-Dienste direkt im Webbrowser, doch mit Apps wie Element erhält man am Smartphone wie auch am Desktop eine angepasstere Oberfläche, die die Produktivität erhöht.

Würde ich also mal einen Live-Support-Channel für irgendetwas aufsetzen wollen, wäre die Einrichtung eines eigenen Channels auf “matrix.org” oder auf einem anderen Server meine Wahl.

Ein kleines Problemchen sind die “kleinen” Server, die von Privatpersonen eingerichtet werden, und manchmal nach einem Jahr wieder verschwinden. Hier empfiehlt sich dann doch ein größerer Server, hinter dem eine Organisation steht, die nicht morgen gleich wieder verschwindet.

Fazit

Das Fedi-verse löst hoffentlich mehr und mehr die fauligen Moloche wie Facebook, Twitter und Instagram ab.

Man kann leider nicht ausschließen, dass auch in föderierten Netzen die Server “verderben” und abgeschaltet werden, doch dank des Protokollaufbaus, gibt es zumindest die Möglichkeit auf andere Server umzuziehen.
Bei kommerziellen Anbietern wird man garantiert keinen Umzugsdienst auf eine Konkurrenzplattform finden und ist auf Gedeih und Verderb an einen Betreiber gebunden.

Und noch etwas zeichnet die “neu-entdeckten” Alternativen aus: Sie wollen uns nicht (so intensiv) das Geld aus der Tasche ziehen. Soll heißen, Werbung sieht man dort noch nicht. Ob das für immer so bleiben wird, steht in den Sternen, aber aktuell bin ich von den Alternativen positiv beeindruckt.

Mal sehen, ob ich auch mal einen selbstgeschriebenen HTTP Request dort hin abschicke…

OpenGL als 2D Framebuffer

2022-12-10T12:00:00+01:00

Wie bekomme ich meine flachen Framebuffer jetzt auf’s Android Smartphone?

Antwort: Über OpenGL Texturen

Der generische Framebuffer ist “die” Lösung im GATE Framework, um Bilder plattformunabhängig überall anzeigen zu können. Dass das unter Windows über die WinAPI und auf Linux über die Xlib läuft, ist nichts besonderes.

Selbst für DOS oder EFI, wo das Ganze direkt in die Video-Hardware geschrieben wird, gibt es eine Implementierung.

Nur Android und UWP/DirectX Apps fehlen mir noch.

Doch an Android wird bereits gearbeitet.

Idee

Wann immer der Framebuffer ein neues Bild erhält, wandelt er dieses in OpenGL Texturen um und legt diese auf rechteckige GL Objekte, die im Vollbild angezeigt wird.

Und tatsächlich funktioniert dieser Ansatz. Ich habe per glOrtho() eine 2D Umgebung aufgesetzt und jedes rechteckige Teilbild wird als TRIANGLE_FAN an die richtige Stelle des Bildschirms gepackt.

Ein bisschen Tricksen musste ich bei der Ereignisverwaltung, denn hier hatte ich für OpenGL eine gekapselte Eventloop vorgesehen, doch bei den Framebuffers werden Ereignisse ge-poll-t und man muss die Eventloop selbst umsetzten.
Doch das lässt sich über Threads und Queues lösen.

Fazit

Die Grafik ist also mit ein bisschen Kopfrechnen machbar.

Zugegeben, es nicht sehr effizient für einen OpenGL Host, wenn ich immer alles per CPU in einen Framebuffer zeichne, diesen dann zerteile und in Texturen umwandle und diese dann auf Flächen projiziert werden, aber es funktioniert.

Und hier geht es um best mögliche Kompatibilität und nicht um höchste Performance.

Mit diesem Ansatz ließe sich auch einige alte (gut designe-te) DOS Spiele für Android oder andere OpenGL-Systeme neu kompilieren, wenn man den Grafikspeicher als virtuellen Framebuffer ansieht und ähnlich auf eine neue Oberfläche abbildet.
Wäre mal interessant um wie viel besser das ist, als alles in einem Emulator laufen zu lassen.

DirectX 11 für UWP

2022-12-04T12:00:00+01:00

O-M-G! Wenn ich mich verschätze, dann ordentlich!

Irgendwie glaubte ich, dass ich in ein paar Stunden die “paar Kernklassen” von DirectX von C++ auf C manuell übersetzen zu können.

Schließlich wollte ich doch nur ein UWP Fenster mit einem Framebuffer erstellen lassen können …

So wie Mönche im Mittelalter die wenigen Bücher Seite für Seite und Buchstabe für Buchstabe händisch abmalten, so investiere ich “gerne” meine Freizeit in die Übersetzung von COM-Klassen von C++ nach C.

Denn Microsofts generierter C++ Code ist nur MSVC treu, bringt aber andere Compiler gerne zum Verzweifeln. Und nachdem Fingerübungen gut für die Feinmotorik sind, weitete ich meine UWP-Spielchen auf DirectX aus.

Übersetzung von COM C++ nach C

Ein in den Headern definiertes Interface, das z.B. so aussieht:

1interface DECLARE_INTERFACE("12345678-abcd-1234-5678-1234567890ab") 
2IMyClass : public IUnknown
3{
4        STDMETHOD(MyFunc1)(DWORD param1) PURE;
5        STDMETHOD(MyFunc2)(INT param1, void* param2) PURE;
6};

wird in etwa so übersetzt:

 1typedef struct IMyClass_interface IMyClass;
 2
 3typedef struct
 4{
 5  wrt_result(WRT_ABI *QueryInterface)(IMyClass* This, wrt_iid const* riid, void** ppvObject);
 6  wrt_ulong(WRT_ABI *AddRef)(IMyClass* This);
 7  wrt_ulong(WRT_ABI *Release)(IMyClass* This);
 8    
 9  wrt_result(WRT_ABI *MyFunc1)(IMyClass* This, wrt_dword param1);
10  wrt_result(WRT_ABI *MyFunc2)(IMyClass* This, wrt_int param1, void* param2);
11} IMyClass_vtbl;
12
13struct IMyClass_interface
14{
15  IMyClass_vtbl const* lpVtbl;
16};

Dabei sind meine eigenen Datentypen wie wrt_result oder wrt_dword nur Hilfsmittel, um weniger Abhängigkeiten zu Microsoft Headern zu schaffen. Man könnte auch die originalen HRESULT oder DWORD Typen nutzen.

Wieviele Klassen hat DirectX ?

Antwort: Fu**ing viele!

In den UWP DirectX Beispielen wird mit D2D1Factory3, DWriteFactory3, D3D11Device3, D3D11DeviceContext3 oder DXGIDevice3 gearbeitet.
Ich Naivling dachte: Das ist schnell erledigt … und stürzte mich ins Verderben.

Denn die Zahl 3 bedeutete schon mal, dass es ein Original, ein 2 und 3 Interface zu jeder Klasse gab und nachdem schon teilweise das Original mit 20+ Methoden ausgestattet war, wurde der Spaß mit den höheren Interface Versionen nicht weniger.

Doch am Schlimmsten war, dass jede der 20 Methoden ein neues Interface einführte, das mit einer Factory zu weiteren Instanzen führen konnte.

Inzwischen habe ich 140 Klassen und mindestens genau so viele struct und enum Typen in mein “kleines” Projekt integriert und ich bin erst bei Interface 2 angekommen. Die Methodenanzahl geht also schon weit über 2000 hinaus, und ich habe bereits über 8000 Zeilen an übersetztem Code abgetippt.

Dem gegenüber steht dann ein OpenGL 1.1, wo ich mit einem Subset von 90 flachen C-Funktionen ganze 3D-Welten und 2D-Framebuffer umsetzen kann.

Lerneffekte

Ein Hintergedanke von dieser “Fingerübung” stammt noch aus meiner Schulzeit:

Repetitio est mater studiorum.
Wiederholung ist der Mutter der Studien.

Denn beim Abtippen merkte ich erst, wie viele weitere Klassen (und damit Möglichkeiten) sich hinter DirectX versteckt. Und durch das wiederholte Niederschreiben der Schnittstellennamen, ergibt sich teilweise ein gewisses “Gefühl” für die Materie.

Das hätte man vermutlich in einem guten Buch auch nachlesen können, doch wenn der Code durch die eigenen Hände geht, bleibt stets mehr hängen.

Fazit

Ich bin noch nicht fertig und weiß auch noch gar nicht, ob meine Bemühungen überhaupt fruchten werden. Denn erst mit allen vollständigen Schnittstellen kann ich das erste Demoprogramm erstellen und versuchen es auszuführen.

Ziel soll jedenfalls sein, dass eine beliebige Rastergrafik auf dem Bildschirm erscheint und dass kein Microsoft-Header zum Einsatz kommen soll, sondern dass nur COM-Aufrufe gegen die binäre Schnittstelle stattfinden.

Pokemon v9: Purpur

2022-12-03T12:00:00+01:00

Mit der Paldea Region ist Pokemon nun in der 9. Generation endgültig zum Open-World Rollenspiel geworden und zeigt, wie sich die 3D Grafik in den letzten Jahren verbessert hat.

Das unglaublichste ist aber, dass das Spiel jetzt seit 25 Jahren Bestand hat und die gleiche Idee immer wieder neu verpacken kann und dabei erfolgreich bleibt.

Ich habe mir Pokemon Purpur zugelegt (oder wie es im Miauz-Genau Podcast bezeichnet wurde: Purr-Purr) und fühle mich (für kurze Zeit) wieder wie ein Kind.

Back to school

Seit den ersten Spielen auf dem Gameboy findet man am Anfang des Spieles meist eine Schule vor, in der “Pokemon unterrichtet wird”. So lernt der Anfänger ein paar Details, wie Typen und Attackenvorteile.

Doch in der neuesten Generation ist man als 10-jähriger Student auf der Akademie eingeschrieben, und das gesamte Spiel dreht sich sprichwörtlich um diese, die Professoren und die anderen Studenten.

So viel “Schule” gab es zuletzt in Final Fantasy VIII in einem Spiel, was für mich als “sehr-sehr-fortgeschrittener Teenager” etwas befremdlich wirkt, für die eigentliche Zielgruppe aber gut passen dürfte.
Nur die Streber-Schuluniform ist aber definitiv zu viel des Guten, wie ich finde.

Spielverlauf

Die Kämpfe sehen in etwa so aus, wie sie schon in Schwert/Schild und der Neuadaption von Diamant/Perle eingeführt wurden.

Interessant ist die neue Art der Fortbewegung und die wirklich schön designete Landschaft auf der Inselwelt Paldea.
Denn gleich am Anfang erhält man das legendäre aber geschwächte Pokemon Miraidon, welches im Laufe der Story stärker wird. Am Anfang reiten wir damit über die Felder (obwohl es eher der Fahrt auf einem Motorrad gleicht). Sobald es springen kann, werden vorher unerreichbare Anhöhen erreichbar. Wenn es Schwimmen kann, können die umgebenden kleinen Inselchen besucht werden, und am Ende kann es sich auch senkrecht an Bergen hinauf “hochkrallen”, von denen man auch wieder durch die Lüfte “hinunter segeln” kann.

Da bekommt man echt Lust stundenlang herumzulaufen, denn alle 100 Meter liegen Items verstreut herum, die es einzusammeln gilt.

Und es wäre nicht Pokemon, gäbe es nicht wieder hoch emotionale Freundschaftsbekundungen, die wie immer niedlichst abgeschlossen werden. Das regelmäßige Picknick mit seinen Lieblingspokemon gehört natürlich auch dazu.

Gab es früher einen festgelegten Weg, den der Trainer einhalten musste, so kann man diesmal die Insel einmal umrunden und an den Kampfstätten unbeschadet vorbeilaufen. Das bringt einen dann gerne auch mal in Gebiete, in denen die Gegner viel zu stark für einen sind und man quasi jedem ausweichen muss.

Das Hauptspiel hat 3 Zielsetzungen, die man völlig frei angehen kann:

Wie immer 8 Arenakämpfe um in der Pokemonliga antreten zu dürfen.
Kämpfe in 5 Team-Star-Verstecken, in denen rebellische Schüler den Unterricht schwänzen.
Sieg gegen 5 Herrscher-Pokemon, wodurch unser Reittier stärker wird.

Hat man das alles durch, öffnet sich der Weg zur Zone-Null, dem tiefen Schlund im Zentrum der neuen Region, wo man die Hauptstory abschließen kann.

Bewertung

Ich sage mal: Daumen hoch.
Anfangs war mir die Welt zu groß und alleine der Weg zum nächsten Pokemoncenter kam mir unnötig lange vor. Doch die schön gestaltete Landschaft schuf mit ihrem Realismus dann das Bedürfnis, hinter jeden Hügel blicken zu wollen, und dann gefiel es mir immer besser.

Technisch muss ich leider sagen, ist Pokemon im Jahr 2022 verspätet dort angekommen, wo ein Xenoblade Chronicles 2 schon im Jahr 2017 war. Wirklich neu war die Grafik für mich also nicht.

Auch die freie Wahl der Spielziele war anfangs ungewohnt für mich und mir sogar zu komplex. Denn bei älteren Spielen waren Dialoge unwichtig, weshalb ich sie selten las und ignorierte, schließlich konnte man sowieso nur in eine Richtung weitergehen.

In Pokemon Karmesin und Purpur hingegen lernt man einige Personen kennen, die einem Dinge erzählen, die man sich schon merken sollte, wenn man weiterkommen will … oder man liest die Schummelzettel auf diversen Pokemonseiten, wenn man sich nicht mehr zurecht findet.

Fazit

Ich merke, dass ich älter werde und nicht mehr die gleiche kindliche Begeisterung habe, wie damals vor über 20 Jahren … aber dieses Spiel schafft es trotzdem immer wieder, dass ich am Ende sage:

Ich hätte etwas verpasst, wenn ich es ausgelassen hätte.

Und so habe ich auch die 9. Generation mit inzwischen 1008 Pokemon in mein Herz geschlossen, von denen 400 innerhalb der Edition fangbar sind.

Den Online-Teil habe ich vorerst weggelassen, denn Nintendo will dafür wieder eine Jahresmitgliedschaft abkassieren … aber das mache ich vielleicht nächstes Jahr. Alle 1000 Tierchen werde ich vermutlich nicht mehr einfangen/eintauschen können.
Und das ist vermutlich der einzige Kritikpunkt:

Es ist einfach viel zu viel für mich.
Diese Aufgabe muss die junge Generation erledigen.

Client-Certificates

2022-11-27T12:00:00+01:00

Für gewöhnlich möchten im Web nur die Clients (also unsere Browser) wissen, ob sie auch mit der richtigen Gegenseite reden, folglich stellen nur Server ihre Zertifikate zur Einsicht bereit.

Doch wenn es um Sicherheit geht, dann muss auch der Server wissen, ob seine Clients “die richtigen” sind. Genau hier kommen Client-Zertifikate ins Spiel.

Wiederholungsstunde: Zertifiakte

Beim üblichen TLS Handshake schickt der Server den öffentlichen Teil seines Zertifikats an den Client und der kann es dann verifizieren oder ignorieren. Das geschieht über die Liste der “vertrauenswürdigen” Zertifikate, die entweder im Betriebssystem oder in der Anwendung selbst hinterlegt sind.

Zertifikate können bekanntlich untereinander verknüpft sein und deshalb existieren “Stamm-Zertifikate” (Root Certificates), die überall bekannt sein sollten, und für jede Anwendung oder Domäne eigene Zertifikate, die mit bestimmten Stamm-Zertifikaten signiert wurden.

Der Client hat also entweder das empfange Zertifikat bereits als “sicher” in seiner Datenbank, oder er erkennt das Stammzertifikat als korrekt an.

Bei Webanwendungen und HTTPS gibt es noch ein Kriterium: Es muss nämlich auch der im Zertifikat enthaltene “Name” korrekt sein.
Wenn man also “https://opengate.at” aufruft, muss das Zertifikat als “vertraut” (trustet) gelten, und außerdem muss das Zertifikat auch den Namen “opengate.at” beinhalten.

Passt das nicht, wird die Verbindung abgelehnt, außer man zwingt den Browser, Zertifikatsfehler zu ignorieren.

Client Zertifikate

Bei Client-Zertifikaten entscheidet der Server, …

ob ihn diese gar nicht interessieren.
ob sie optional mitgeschickt werden dürfen.
ob sie zwingend erforderlich sind.

Der Client kann bzw. muss dann sein Zertifikat an den Server senden, und dieser leitet dann die gleiche Prozedur ein, die ansonsten auch der Client anwendet:

Prüfung, ob das Zertifikat oder sein “Stamm” vertrauenswürdig sind
Prüfung, ob der übermittelte Name auch korrekt ist.

Problem: Namensprüfung

Perfekt funktioniert das nur in einem perfekten Adress- bzw. Namensraum. In einem Active-Directory hätten alle Server und Clients einen im DNS registrierten Hostnamen, womit auch für jeden Client ein Zertifikat mit diesem Namen ausgestellt werden kann.

In IOT Netzen sieht das aber leider ganz anders aus. Oft werden die Clients dort per IP-Adresse konfiguriert und DNS vollkommen ausgespart. Natürlich kann ein Zertifikat auch auf einen IP-Adresse lauten … doch das geht dann nur, wenn diese statisch ist.
Wenn aber die Clients per DHCP bei jedem Start eine neue IP erhalten, müssten sie auch ein neues Zertifikat ausgerollt bekommen, denn der Server würde dann nur die IP des Clients erkennen und keinen Namen ableiten können.

Genau dieses Problem stellt aktuell viele Bereiche vor Probleme. Denn einerseits verlangen immer mehr Endkunden erhöhte Sicherheit mit Zertifikaten, andererseits sind zumindest Clientzertifikate nicht in allen Bereichen einsetzbar.

Zertifikate anlegen

Wer keine fertige Zertifikatsinfrastruktur zur Verfügung hat, dem bleibt dann nur der Griff zum openssl Tool, um selbst-signierte Zertifikate anzulegen.

Erzeugung eines Stamm-Zertifikats (Certificate Authority)
- openssl req -x509 -sha256 -days 3650 -nodes -newkey rsa:2048 -subj "/C=AT/L=Vienna/O=OpenGATE/OU=Carbis" -keyout ca-key.pem -out ca.pem
- Wir erhalten die Datei ca-key.pem und ca.pem
Erzeugung eines Signier-Anfrage für ein neues Zertifikats
- openssl req -newkey rsa:2048 -days 3650 -nodes -subj "/C=AT/L=Vienna/O=OpenGATE/OU=Carbis/CN=127.0.0.1/emailAddress=admin@example.com" -keyout cert-key.pem -out request.csr
- Erzeugt cert-key.pem mit dem Schlüssel und request.csr für die Signieranfrage
Signiert und erstellt ein neues Zertifikat:
- openssl x509 -req -in request.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -days 3650 -sha256 -out cert.pem
- Erzeugt cert.pem mit dem per CA signiertem Zertifikat.
Erzeugung eines Zertifikates ohne CA Signatur
- openssl req -new -x509 -days 3650 -nodes -subj "/C=AT/L=Vienna/O=OpenGATE/OU=Carbis/CN=127.0.0.1/emailAddress=admin@example.com" -keyout cert-key.pem -out cert.pem
- Erzeugt cert-key.pem mit dem privaten Schlüssel und cert.pem mit dem Zertifikat.

Nun kann man am Server entweder das Stammzertifikat (CA) als vertrauenswürdig hinzufügen, womit alle Zertifikate, die damit signiert wurden auch vertrauenswürdig sind (ca.pem).
Oder man fügt jedes einzelne Zertifikat dem Server als vertrauenswürdig hinzu (also die cert.pem Varianten).

Die Clients selbst nutzen dann den privaten Schlüssel (cert-key.pem) um die Kommunikationsdaten zu signieren und der Server kann die Signatur über sein(e) Zertifikat(e) bestätigen.

Fazit

Zertifikate waren für mich immer “kompliziert”, weil meistens etwas nicht richtig funktioniert hatte.
Doch meist lag es an falschen Hostnamen oder anderen Konfigurationsfehlern.

Inzwischen freue ich mich, dass ich zumindest die Grundbegriffe von verschlüsselter Kommunikation auch selbst nachimplementieren kann.
openssl ist hierfür ein mächtiges und gleichsam nützliches Werkzeug.

REST - Representational State Transfer

2022-11-26T12:00:00+01:00

Das witzige ist:

Jeder braucht heute eine REST Schnittstelle, doch leider versteht jeder etwas anderes darunter.

Und das macht mich REST-los unglücklich.

Der Stil der 70er Jahre ist leider auch heute noch weit verbreitet:

Globale Variablen
Singletons
Hart kodierte Pfade
Funktionen mit versteckte Zuständen (wie z.B. strtok())
und vieles mehr.

Und als Netzwerke, das Internet und das Web aufkamen, übersetzte man diese “Denkfehler” teils 1:1 in das neue Medium.

Doch im Netz sind solche Konstrukte viel störungsanfälliger, als im lokalen Prozess auf meiner Maschine.

Exakte Adressierung

Ein Dienst wird gerne mit einem start() begonnen und mit einem stop() zum Beenden gebracht. Das implementiert man auch gerne genau so, mit einem globalen start() und stop() und verlässt sich dann darauf, dass es genau einen Anwender gibt, der “genau weiß”, wann er etwas starten und wieder stoppen will.

Wenn aber ein zweiter Akteur auftritt, der zuerst stop() und dann start() durchführt, nachdem der erste nur start()en wollte, ist dann das finale stop() des ersten genau das, was er wollte? Denn er stoppt nicht das, was er gestartet hatte, sondern etwas, was ein anderer begonnen hatte.

Solche Seiteneffekte sollten durch REST abgeschafft werden, und eine aktualisierte API kann dann z.B. so aussehen:

start(my_token) und stop(my_token)
stop_token = start() und stop(stop_token)
Oder wie man es in HTTP-Request ausdrücken könnte:
- POST /service/my_token und DELTE /service/my_token
- my_token:= POST /service/new und DELETE /service/my_token

(REST != HTTP) && (HTTP != REST)

Viele Leute glauben, REST wäre bereits der Einsatz von GET, POST, PUT und DELETE und jede HTTP-URL wäre bereits eine REST-Schnittstelle.
… Ähm: Nein!

Es kommt darauf an, dass man das, was man auslöst, so parametrisiert, dass im Idealfall keine der beiden Seiten sich merken muss, was die Gegenseite schon getan hat.
Oder anders gesagt: Es müssen alle notwendigen Daten hin- und zurückübertragen werden.

Das geht auch dann, wenn man z.B. nur per POST über HTTP kommuniziert und z.B.: XML-RPC, JSON oder Protobuf Objekte überträgt.
Wichtig ist vor allem, dass der Inhalt der Objekte vollständig ist und keine Seiteneffekte durch gespeicherte Zustände auftreten können.

Der Einsatz von HTTP Methoden macht Aufrufe allerdings “schön” lesbar und kann auch leicht in Funktionsaufrufe übersetzt werden:

HTTP-REST	Pseudo-Funktion
GET /service/data_file	service.ReadContent(data_file)
POST /service/new_data_file	service.AddContent(new_data_file, content)
PUT /service/data_file	service.WriteContent(data_file, content)
DELETE /service/data_file	service.DeleteContent(data_file)

(Und wer REST wirklich ernst nimmt, der nutzt natürlich die URL /service/service_id/data_file)

Versionierung

APIs brauchen Versionen, weil sie sich immer weiterentwickeln und der übliche HTTP-REST-Weg ist, die Version in der URL als Teil des Pfades anzugeben, z.B.:
/v1/service/something

Doch wie genau man das macht, ist nicht vorgeschrieben. Und das führt auch leider zu manch seltsamen Erscheinungen. Erst neulich musste ich so etwas in meiner Firma entdecken:

Endpoint: POST /service/process
- Protobuf content message can be v1 or v2
Endpoint: GET /service/is-v2
- 200 OK: v2 Protobuf messages in /service enabled
- Else: /service must use v1 Protobuf messages.

Naja … hier sehe ich eindeutig, dass jene Kollegen ein anderes Verständnis von REST haben, als ich.

Fazit

Ich kann nur allen Entwicklern anraten, sich die APIs der großen Hersteller im Web anzusehen, wie die ihre Schnittstellen aufgebaut haben. Da ist sicher nicht alles perfekt, aber da wurde schon eher auf Konsistenz geachtet.

Das Problem sind die unzähligen Firmen und Konzerne, die intern ihr eigenes Süppchen kochen, das nicht ins Netz gelangt und daher nie “ordentlich” durchgedacht wurde.

Die Meinung, “irgend einen HTTP Endpoint könne man mit REST gleichsetzen”, ist falsch und dennoch weit verbreitet, und produziert umgebungs-ignorante Schnittstellen die schwer zu warten sind, weil sie keinem logischen Muster folgen.

Und das größte Problem ist, dass auch in neuen Produkten diese falschen Ansätze immer weiter verschleppt werden.
Es liegt also noch viel Arbeit vor mir bzw. vor uns, damit solche Legacy-Schnittstellen möglichst bald durch “echtes REST” abgelöst werden.

Also: Auf ans Werk!

ShFileOperation vs RemoveDirectory und DeleteFile

2022-11-20T12:00:00+01:00

Ein weiterer halb-zerstörter windowsfilters Docker Fall hat mir aufgezeigt, dass APIs wie RemoveDirectory() und DeleteFile() entgegen allen Erwartungen nicht funktionieren.

Doch der Windows Explorer schafft die Löschungen problemlos. Und dafür gibt es eine Erklärung: Er nutzt die Shell-APIs.

Vorgeschichte

Windows unterscheidet sich in einem Punkt sehr von anderen Systemen, weil es nämlich den Aufbau seiner “Shell” als Funktionsschnittstelle offenlegt.

Unter Unix/Linux ist “die Shell” lediglich ein Konsolenverwalter wie bin/ksh oder bin/bash, der über Befehle Prozesse starten und verknüpfen lässt.

Doch in Windows wurde eine “benutzerfreundlichere” Verwaltungsebene erdacht, und diese ist in shell32.dll implementiert und ein explorer.exe zeigt sie uns grafisch an, angefangen bei jeder Dateiauflistung, bis hin zur Vorschau von Webinhalten.

shell32.dll sieht auch das Dateisystem anders, während die kernel32 APIs bei Laufwerken und NT-Root-Pfaden die Hierarchie aufbauen, führt die Shell-API virtuelle Namensräume, wie den “Computer” und den “Desktop” ein, auf dem dann die Laufwerke liegen.

Und das führt dazu, dass viele nativen APIs von kernel32 in irgend einer ähnlichen Form auch in der Shell abgebildet sind, allerdings ein bisschen mehr und etwas andere Pfade verstehen.
Und bisher dachte ich, dass die Shell-API nur ihre virtuellen Spielchen in native Pfade übersetzt und im Hintergrund dann die kernel32 APIs bedient.

RemoveDirectory mit Access Denied

RemoveDirectory() kann Links (SymLinks, Junctions) löschen und tut das auch brav. Doch bei meinen windowsfilters Löschversuchen scheiterten meine Aufrufe, wie auch der cmd Befehl rmdir mit einem Access-Denied, das keinen Sinn machte. Die erforderlichen Rechte waren vorhanden und kein Prozess sperrte den Verzeichnispfad.

Doch wenn man diesen verlinkten Ordner im Explorer zur Löschung auswählte, verschwand dieser auch prompt.

Nach einigem Suchen fand ich Beiträge, die meine Beobachtungen bestätigten:

Bestimmte Links zu Shell-UI-Ordnern erhalten einen besonderen Schutz durch die kernel APIs. Diese können bzw. dürfen nicht gelöscht werden.

Das sind Dokumente, Musik, Videos … und wie sie sonst noch alle heißen.

Man kann sie auch nicht von cmd aus mit rmdir oder del löschen, doch der Explorer schafft es stets ohne Probleme.

`ShFileOperation` löst das Problem

Wirft man aber solche “störrischen” Pfade der API SHFileOperation mit SHFILEOPSTRUCT::wFunc = FO_DELETE vor die Füße, verschwinden die Links genau so wortlos, wie sie es im Explorer tun.

Die Funktion, bzw. die SHFILEOPSTRUCT Struktur hat nur ein paar Besonderheiten bei den Pfaden: Diese müssen doppelt-null-terminiert sein, weil in einem Parameter mehrere null-terminierte Dateipfade vorkommen dürfen.

Deshalb muss SHFILEOPSTRUCT::pFrom = "path/to/link\0\0" derart gesetzt sein.

Und weil ich keine UI-Interaktionen möchte, ist auch noch
fFlags = FOF_NO_UI notwendig.

Fazit

Ich habe also die WinAPI-Implementierung im GATE-Framework angepasst und den RemoveDirectory() und DeleteFile() Aufrufen einen Sonderfall angefügt:

Wenn der Primäraufruf fehlschlägt, wird ShFileOperation() probiert. Ist es ebenso nicht erfolgreich, wird der Fehler des Primäraufrufes weiterbehandelt.

Mit diesem Patch konnte ich nahezu vollständig die Verzeichnisse einer weiteren versauten windowsfilters Installation löschen, ohne dass auf dem Server Probleme auftraten, weil Dateien am Hostsystem mitgelöscht wurden.

Aber seltsam ist das schon!
Dass ausgerechnet die kernel API von etwas abgelenkt wird, was die Shell-API problemlos hinbekommt, ist für mich eine verkehrte Welt.
Denn meine Erwartungshaltung ist, dass Shell-APIs ein paar geheime Schützlinge haben darf, die sie nicht löscht, dass aber die kernel APIs alles dürfen.

However … Gefahr erkannt, Gefahr gebannt.

/e/OS upgrade am SONY Xperia XA2

2022-11-19T12:00:00+01:00

Ich und Android … ein Buchbeispiel für puren Hass.
Und deshalb lag mein (mir vom Mobilbetreiber aufgedrängtes) Sony Xperia von 2018 bis heute unbenutzt in der Lade, nur gelegentliche APK Tests machte ich darauf.

Doch es gibt eine ent-google-te Android-Variante, die meine Abneigung zumindest verringern könnte: nämlich /e/OS

/e/OS ist ein auf dem LineageOS Projekt basiertes Android Betriebssystem, aus dem alle Google-Dienste entfernt wurden und die meist durch OpenSource-Alternativen ersetzt werden.

Das alleine reicht mir, das Projekt zu mögen, doch /e/OS kann noch einen weiteren Pluspunkt verbuchen: Es wird (als OpenSource Projekt) stets erweitert und bietet Support für die neuesten Versionen von Android.

Mein altes SONY Xperia XA2 kam mit Android 8 auf dem Markt und konnte dann über die SONY App auf Android 9 aktualisiert werden, doch dann lief der Support aus und das Gerät verharrte auf dem heute veralteten Stand.

Mit /e/OS liegt für dieses Smartphone eine Android 11 Version vor und eine stabile v12 kommt vielleicht auch bald ins Netz.

Nicht für jede Smartphone Marke ist ein Stabiles /e/OS Image verfügbar, doch ich hatte Glück und konnte mein Gerät auf der Seite doc.e.foundation/devices finden.

Neues Betriebssystem auf Smartphone installieren

Man könnte sagen, unter doc.e.foundation/devices/pioneer findet man die Installationsanleitung und das war es auch schon.
… leider war es dann doch nicht so einfach und ich brauchte einiges an Geduld.

Für die Installation braucht man einige Schritte:

Der Bootloader des Smartphones muss “entsperrt” werden
Man braucht die Tools adb und fastboot
Ein eigener USB-INF-Treiber muss installiert sein, damit adb und fastboot korrekt funktionieren können
Man braucht ein /e/OS “Recovery-Image”, welches das bestehende Android ersetzen kann
Man braucht das finale Android-Image, das installiert werden soll.
Und am Ende richtet man die neue Android-Version dann ein.

Smartphone entsperren

Also diese Prozedur ist echt lustig, und kann bei jedem Smartphone etwas anders sein. Ich musste eine dokumentierte Zahlensequenz in der Telefon-App eintippen, worauf sich das “Service-Menü” öffnet. Dort erfährt man die Geräte IMEI Nummer und ob ein entsperren möglich ist.

Danach musste ich auf eine Entsperr-Seite von developer.sonymobile.com/unlockbootloader/unlock-yourboot-loader/ gehen, wo aus meiner IMEI dann ein Entsperrcode generiert wurde, der im Fastboot-Modus über den Befehl fastboot oem unlock 0x + Code
den Bootloader “überschreibbar” machen sollte.

Bockiger USB-Treiber

Ist das Gerät unter Windows per USB-Kabel verbunden, erkennt adb alles und laut Anweisung soll adb reboot bootloader das Gerät in einen speziellen Modus booten lassen, in dem weitere Änderungen vorgenommen werden können.

Hier versagte allerdings jede weitere Kommunikation und der Test mit dem Aufruf fastboot devices konnte mein Smartphone nie finden.

Grund dafür war, dass in diesem speziellen Boot-Modus ein anderer USB-Treiber hätte geladen werden müssen und dieser fehlte mir.
Ich konnte zwar von developer.sony.com/file/download/fastboot-driver/ eine INF-Datei herunterladen, doch diese ließ sich nicht installieren, und gab stets die Info aus, dass die notwendige winusb.sys Datei nicht gefunden wurde.
Dieser Treiber ist ein Standard-Teil von Windows, der mit den Hardware-IDs in den INF-Dateien angewiesen wird, ein virtuelles Gerät im System anzulegen, zu dem sich Benutzerprogramme verbinden können.

Ich musste erst in den Windows-Test-Modus schalten (bcdedit /set testsigning on) und dort manuell den original INF-Treiber in C:\Windows\System32\DriverStore\FileRepository\winusb.inf_amd64_ced441476847bd1a über das Gerät “darüberinstallieren”, bis dann endlich auch der Android ADB Treiber zu funktionieren begann.

Jetzt konnte ich in den Fastboot-Modus wechseln, und den Entsperrcode über das fastboot Tool zum Gerät senden.

1D:\>fastboot oem unlock 0xaaaaaaaaaaaaaaaa
2OKAY [  6.711s]
3Finished. Total time: 6.711s

Ab nun erscheint bei jedem Neustart die Meldung, dass der Bootloader “unlocked” ist.

Rescue Image installieren

Jetzt beginnt das eigentliche Upgrade im Fastboot-Modus, wo das Recovery Image installiert wird

1D:\>fastboot flash boot D:\apps\android\e-os\recovery-e-1.5-r-20221031230467-dev-pioneer.img
2Sending 'boot_b' (22345 KB)                        OKAY [  0.564s]
3Writing 'boot_b'                                   OKAY [  0.132s]
4Finished. Total time: 0.789s

Wenn man jetzt neu startet:

1D:\>fastboot reboot
2Rebooting                                          OKAY [  0.008s]
3Finished. Total time: 0.010s

und die Tasten Volume-Down + Power drückt, landet man im grafischen Recovery Image, das zuvor installiert wurde.

Dort führt man einen “Factory-reset” durch, der das frühere OS löscht und das Gerät auf die Installation des vollständigen /e/OS Systems vorbereitet.

/e/OS “Sideload”

Mit dem Kommando adb sideload wird in diesem Zustand das Image übertragen

1D:\>adb sideload D:\apps\android\e-os\e-1.5-r-20221031230467-dev-pioneer.zip
2serving: 'D:\apps\android\e-os\e-1.5-r-20221031230467-dev-pioneer.zip'  (~11%)

Das dauert viele Minuten und auch die Fortschrittsanzeige bleibt lange scheinbar hängen. Hier muss man einfach geduldig warten, denn irgendwann sind alle Daten am richtigen Ort und die Installation endet mit einem schlichten:

Install completed with status 0.

Jetzt ist ein finaler Reboot angesagt und dieser führt dann zum neuen Logo während des Starts mit dem e Symbol und einem springenden Punkt.

Android einrichten

Nun folgt die “übliche” Prozedur, wie bei allen Betriebssystemen, wo man nach Ort, Datum, Netzwerk und Logindaten gefragt wird..

Auffällig war dabei, dass der Touchscreen auf eine sehr dunkle Stufe geschaltet war. Damit waren die Texte etwas schwer lesbar, aber es war akzeptabel.

Nach dem setzen einiger Einstellungen, kam ich endlich zum Ende der Installationsprozedur.

Dahinter verbarg sich dann ein recht normales Android-Outfit, dem aber tatsächlich alle üblichen Google-Icons fehlten

In den Einstellungen konnte ich den Touchscreen wieder heller einstellen und dann das System schrittweise erkunden.

In der App Lounge, dem /e/OS Ersatz für den Play-Store, fand ich diverse Apps, die man “im Business” gebrauchen kann und installierte diese samt Updates für diverse Standard Apps.

Und das war es auch schon … … ich habe erstmals ein Android-System selbst installiert.

Fazit

Wenn der lästige Windows-Treiber-Bug nicht gewesen wäre, hätte ich sagen könne: Es war eigentlich ganz einfach … doch ein solcher Fehler hält vermutlich viele interessierte Anwender ab.
Denn dokumentiert ist ein solches Problem nicht. Vielleicht liegt es auch an der aktuellen Windows Version und dass es vor 2 Jahren noch out-of-the-box lief … heute aber nicht mehr.

Jetzt, 4 Jahre zu spät, entwickle ich langsam Interesse an meinem XA2, das bisher nur als Staubfänger fungierte.
Denn ohne die lästigen Fix-Apps wie Facebook und GMail, die sich auf üblichen Phones nicht deinstallieren lassen, ist /e/OS genau das, was ich von einem Telefon verlange:

Es ist frei von sinnlosem Blödsinn und lässt mich genau das installieren, was ich haben möchte.

In diesem Sinne sage ich:

Ein Hoch auf die e-foundation, das Lineage-Team und alle Entwickler, die mein Upgrade möglich gemacht haben.

Leider ist mein Poco M3 noch nicht offiziell unterstützt, und so verbleibt es, wie zuvor das XA2, auf der Reservebank.
Denn mein altes Lumia Windows-Phone gibt und gibt nicht den Geist auf.
Und so habe ich weiter keinen Grund zu Android zu wechseln. … doch wenn es passieren sollte, dann wechsle ich nun aufgeschlossen zu /e/OS.

Es war einmal ... ein Glücksspiel

2022-11-13T12:00:00+01:00

Manchmal erfährt man aus den Medien, was gerade für Skandale ablaufen. Und man wundert sich, wie das Schicksal solche Spinnfäden an Zufällen weben konnte.

… und manchmal passiert so etwas auch im Bekanntenkreis.

Vor vielen vielen Jahren, lange vor meiner Geburt, ging eine fleißige junge Kellnerin in einem kleinen Dorf ihrer Arbeit nach:

Ein Stamperl für den alten Herrn ganz hinten, ein Krügerl für den Apfelbauern und ein Toast Hawaii für den Straßenarbeiter.

Und in der Ecke stand der Einarmige Bandit, der mit dem Flipper in keiner Kneipe dieser Zeit fehlen durfte.

Und was ist so ein Automat ohne seine treuen Spieler?

Die Hersteller und Verkäufer dieser Automaten, die regelmäßig vorbeikamen um das Gerät “zu justieren”, prägten den Spruch:

Erst füttern, dann melken.

Und so war das Glück etwas zu Gewinnen stets von den Besuchen dieser Herrschaften abhängig, die einen Teil der üppig gefüllten Münzenkiste dem Wirt zukommen ließen.

Beim “Füttern” kam häufiger wieder genau das unten raus, was man oben reingesteckt hatte, was sofort mit einem Bierchen gefeiert wurde.
Beim “Melken” musste die schlechte Laune wegen der “verfüttertem” Münze ebenso wieder weggebechert werden.

Und so hätte es ewig weiter gehen können, wenn da nicht dieser eine Tag gekommen wäre.

Wer weiß schon noch, ob es eine 3. Zitrone, Kirsche, eine 3. 7 oder ein anderes Symbol war, was gerade dabei war, einzurasten und mit einem seltsamen Mechanismus dann unerwartet doch noch eine Stelle weitersprang …
Das war jedenfalls der Augenblick, als die Stimmung kippte.

Die Kellnerin hätte sich diesen Tag niemals gemerkt, hätte der Spieler nicht laut schreiend ein Pistole aus dem Mantel gezogen und damit wild herumgefuchtelt.

Nun, es ist zum Glück sonst nichts weiter passiert, es hatte sich kein Schuss gelöst und es wurde auch nie geklärt, warum der Zivilist überhaupt eine Waffe bei sich trug, doch hörte er nicht auf, den Namen des Herstellers auszustoßen, gefolgt von:

Dieser elende Betrüger! Das lasse ich mir nicht gefallen!

Und aus dieser Absicht schrieb sich fast von selbst “ein gewaschener Brief” gespickt mit Anschuldigungen gegen den Macher des teuflischen Automaten, der nichts anderes im Schilde führen könne, als alle und jeden zu betrügen.

Offenbar war der Brief so prall gefüllt mit kreativen Wortmeldungen, dass der oberste Chef der Herstellerfirma, sich diesen Brief (vermutlich mit einem schadenfrohen Lachen) aufhob und im Nachtkästchen verwahrte, vermutlich um sich jeden Abend vor dem Schlafen gehen daran zu erfreuen.

Wir alle wissen, dass Glücksspielfirmen gerne viel Geld hin und her verschieben, aber dieses furchtbar ungern versteuern.
Und weil dieses Geld scheu wie ein Reh ist, sieht man es bestenfalls in weiter Ferne entschwinden, und kein Finanzjäger konnte je eines erlegen.

Unzählige Prüfungen und Durchsuchungen wurden durchgeführt, doch immer passte alles perfekt, kein Verdacht eines Betruges konnte sich erhärten. Und auch bei der Hausdurchsuchung stand jener Firmenchef selbstsicher daneben, als wieder einmal “nichts” über seine einarmigen Banditen gefunden wurde.

Hätte doch bloß niemand in das Nachtkästchen gesehen, wo der üble Brief verwahrt war. Und obgleich man sonst nichts handfestes finden konnte, dieser Brief gab den Ermittlern einen Grund.
Nämlich einen Grund zu graben und nicht wie üblich zum nächsten “Kunden” zu gehen.

Und wenn man nur tief genug gräbt, wird man immer auf etwas Hartes stoßen.

Genau so war es auch, statt der erwarteten Jahresbesuche bei der Firma, fand man unerwartet doch die eine oder andere Unstimmigkeit und wenn das Kartenhaus einmal wackelt, fällt es anderen Beteiligten auch nicht mehr leicht, ruhig zu bleiben.

Am Ende reihte sich die ganze Sache in eine von vielen Firmenpleiten in Österreich ein, die nicht so ganz fair gespielt hatten, die anfangs viel Geld gewonnen und am Ende mehr als alles verloren hatten.

Unser Spieler hatte am Ende doch noch eine ordentliche Portion Schadenfreude gewonnen, wenngleich sie nicht in Münzen ausbezahlt wurde.

Und unsere damalige Kellnerin … sie erzählt gelegentlich noch heute, wie ein einziger zorniger Brief eine ganze Unternehmung zu Fall bringen konnte.

… ihr Jonathan Frakes

In der Serie X-Factor beendete Jonathan Frakes die manchmal wahren, manchmal erfundenen Geschichten immer mit Sätzen wie diesem:

Hat ein Blatt Papier ohne einen einzigen Beweis wirklich eine so große Macht den Lauf der Geschichte zu verändern?
Denken Sie, dass diesmal die Feder mächtiger war als das Schwert, oder haben wir nur zu tief ins Glas geblickt und Unsinn niedergeschrieben?

Und am Ende erfolgt die Auflösung:

Diese Geschichte ist war. So ähnlich hat es sich vor 50 Jahren in einem kleinen Dorf zugetragen.

Und die Kellnerin von damals überlegte in ihrem später in Wien aufgebautem eigenen Geschäftslokal ebenso einen Spielautomaten aufzustellen. Doch davon wurde ihr schnell abgeraten … denn das Automatengeschäft in Wien, so hieß es, war in neue feste Hände gekommen, mit denen “nicht gut Kirschen essen ist”.

… aber das ist eine andere Geschichte.

Chromebook Recovery

2022-11-12T12:00:00+01:00

Auf PCs waren BIOS und EFI stets das “Notfallprogramm”, wenn was schief ging, und man zwecks Wiederherstellung von einem anderen Medium booten musste.

Aber wie funktioniert das eigentlich auf dem Chromebook?

Grund genug, es kaputt zu machen, damit man es danach wiederherstellen kann…

Ich liebe die PC Architektur vor allem für eine Sache: Das BIOS bzw. uEFI.
Denn dieser Standard machte alle x86 Varianten zu einander kompatibel und jedes Betriebssystem kann generisch ausgelegt werden um überall starten und seine Treiber laden zu können.
EFI liest z.B. immer eine GUID-Partitionstabelle, findet die erste “EFI” FAT32 Partition und lädt dort eine /EFI/BOOT/arch.EFI, und der OS-Loader läuft.

Während uEFI auch für die ARM Architektur spezifiziert ist, haben sich die meisten ARM Gerätehersteller nie daran gehalten und stets ihr eigenes Süppchen gekocht. Die Firmware des Raspberry PI und seiner Verwandten geht von einer “alten” MBR Partitionstabelle aus, in der eine FAT/FAT32 Partition liegt, und dort wird nach bestimmten Dateinamen gesucht, die an festgelegte Adressen geladen werden.

Und schlimmer wird es auf weiteren ARM-Systemen, wo nach Codes (IDs) auf den Datenträgern an bestimmten magischen Positionen gesucht wird …

Und was macht mein Lenovo Chromebook?

Das hat mir folgendes Video aufgezeigt:

Zusammengefasst: Also wieder was ganz anderes.

Recovery SD-Karte oder USB-Stick anlegen

Es gibt eine Chrome-Extension names “Chromebook Recovery Utility”. Man sucht also nach dieser Extension im Browser und installiert sie. Über das Extension Menü kann man dieses Plugin starten und schon öffnet sich ein Fenster, in dem man die Erzeugung eines “Wiederherstellungs Mediums” einleiten kann.

Man legt einfach eine SD-Karte ein oder steckt einen USB Stick an und wählt diesen dann als Installationsziel.
Man muss auch noch die “Geräte-ID” angeben, um das richtige Image herunterzuladen, doch mein voll-unterstütztes Gerät wurde von selbst erkannt und das Feld damit automatisch befüllt.

Nun läuft der Download und nach dessen Fertigstellung wird das Zielmedium (SD-Karte / USB-Stick) überschrieben.

Fertig ist das OS-Setup.

Von SD-Karte oder USB Booten

Man braucht eine spezielle Tastenkombination um am Chromebook von USB/SD zu booten, weshalb man die Maschine erst mal herunterfahren muss.

Jetzt drückt man die Tasten ESC und Refresh (der Kreispfeil) und drückt parallel den Einschaltknopf des Chromebooks.

Nun sieht man die Info, dass man von einem externen Medium booten kann und darunter befindet sich nochmals die Geräte-ID (mit der man das richtige Image im Netz finden kann).

Ist eine Karte/Stick mit einem korrekt signierten Image eingelegt, bootet das System binnen Sekunden automatisch davon.
Zuerst wird das Medium selbst nochmal verifiziert, ob alles passt und danach startet sofort die Löschung des bestehenden Systems gefolgt von dessen Neuinstallation.

Schaltet man das Gerät in der Zeit ab (was ich getan habe), kann danach nicht mehr gebootet werden und man erhält auch die Meldung, dass kein gültiges OS vorhanden ist. (Die haben wirklich alles “ge-hash-t”.)

Läuft die Wiederherstellung bzw. Neuinstallation allerdings bis zum Ende durch, muss man das Geräte erst mal ausschalten (lange auf den Ausschalter drücken).
Und beim nächsten Einschalten startet ChromeOS wie frisch aus der Verpackung, fragt nach Userdaten und einer WLAN-Verbindung.

Fazit

Der Vorgang ist ziemlich “deppen-sicher”. Während man sich in einem Windows Setup beim Partitionieren verrennen kann, oder ein fehlender USB-Treiber die ganze Installation aufhalten kann, ist das ChromeOS Setup unterbrechungs- und eingabefrei.

Hat man also sein Image im Netz gefunden (bzw. vom Recovery Utility finden lassen), muss man nur noch die geheime Tastenkombination für den Boot von externen Medien kennen.
Der Rest läuft wirklich zu 100% automatisch.

Doch trotz dieser Benutzerfreundlichkeit ist mir der Aufbau unsympathisch. Google’s Nonstandard Bootprozess, seine verworrenen Partitionstabellen mit signierten Inhalten wollen nur eines erreichen: Nämlich dass nichts anderes außer ChromeOS auf der Hardware laufen darf.
Genau so als ließe sich ein Auto nur an einer ganz bestimmten Tankstelle befüllen … und das ist Mist!

Doch zumindest habe ich nun ein “Setup” für Notfälle, falls mir wieder mal was an dem Gerät kaputt geht.

Watcom DOS: wcl vs wcl386

2022-11-06T12:00:00+01:00

Wer mit CMake ein Watcom für DOS Projekt aufsetzt, erhält ein DPMI 32-bit Programm, das not mit einem DOS-Extender gestartet werden kann.

Das ist grundsätzlich gut, weil man dann “ganz” normal im 32-bit Flatmemory Stil arbeiten kann. Aber die guten alten Realmode Hardwarezugriffe sind damit ein Problem.

Wie macht man also “richtige” 16-bit DOS Programme im Jahr 2022?

————————————————————`

Antwort: Es liegt am eingesetzten Compiler.

wcl386.exe erzeugt 32-bit Code und wcl.exe generiert alten DOS 16-bit Code.

Je nachdem, welche EXE man ausführt und welche Parameter mitübergeben werden, kommt ein anderer Binärtyp heraus:

wcl386 main.c
erzeugt eine “Standard” WinNT-Console main.exe
wcl386 -bcl=dos4g main.c
erzeugt eine DOS/4G 32-bit main.exe
wcl386 -bcl=dos main.c
ist falsch und funktioniert nicht
wcl -bcl=dos main.c
erzeugt eine DOS 16-bit Realmode main.exe
wcl -bcl=com main.c
erzeugt eine minimalistische DOS 16-bit Realmode main.com

Wenn man CMake auf DOS-Plattform einschwört, legt es sich auf DOS/4G 32-bit fest und ruft daher auch genau die dafür notwendigen Kommandos auf.
Das konnte ich auch mit noch so viel CMake Variablen-Umdeutungen nicht verhindern.

Wie überzeugt man also CMake von DOS 16-bit?

Das Geheimnis findet man in der Datei DOS-OpenWatcom.cmake in den CMake Scripts. Dort steht nämlich:

 1if(DEFINED CMAKE_SYSTEM_PROCESSOR AND CMAKE_SYSTEM_PROCESSOR STREQUAL "I86")
 2  string(APPEND CMAKE_EXE_LINKER_FLAGS_INIT " system dos")
 3  string(APPEND CMAKE_SHARED_LINKER_FLAGS_INIT " system dos")
 4  string(APPEND CMAKE_MODULE_LINKER_FLAGS_INIT " system dos")
 5else()
 6  string(APPEND CMAKE_EXE_LINKER_FLAGS_INIT " system dos4g")
 7  string(APPEND CMAKE_SHARED_LINKER_FLAGS_INIT " system dos4g")
 8  string(APPEND CMAKE_MODULE_LINKER_FLAGS_INIT " system dos4g")
 9endif()

Das heißt also, wenn man die Variable CMAKE_SYSTEM_PROCESSOR auf I86 setzt, dann erzeugt CMake die wmake Buildfiles genau so, dass eine echte 16-bit DOS-EXE am Ende herauskommt.

Konkret bedeutet das, mein CMake Aufruf muss so aussehen:

1cmake -G "Watcom WMake" -DCMAKE_SYSTEM_NAME=DOS -DCMAKE_SYSTEM_PROCESSOR=I86 -DCMAKE_BUILD_TYPE=Release path\to\sources

Und schon kann auf einem Windows 10 im Jahr 2022 eine 1980er-Party steigen.

Fazit

Als nächstes musste ich mir ein paar klein-Apps mit dem GATE Framework schreiben, die auch in eine kleine 16-Bit EXE passen. Zusätzlich war ein expliziter Wechsel zum Large-Model notwendig, weil Code und Daten nicht mehr in ein 64 KByte Segment passten.

Das war mit

1set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -mm")
2set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -mm")

erledigt.

Jetzt brauche ich nur noch einen DeLorean mit einem Fluxkompensator, damit ich mir selbst Glück bringen kann.
… aber das ist eine andere Geschichte.

Visual Studio 2013 Lizenz Update Probleme

2022-11-05T12:00:00+01:00

Da möchte ich einen Build unter Visual Studio 2013 auf Windows 8.1 testen, doch plötzlich kommt die Meldung, dass meine Lizenz abgelaufen ist und aktualisiert werden muss.

Doch die Aktualisierung schlägt fehl und das Studio lässt sich nur noch beenden.

Wieder mal so eine Kack-Online-Abhängigkeit!

Wie schön war das früher, als man eine Software im Laden kaufte, die Diskette / CD / DVD installierte und alles funktionierte einfach.

Um 2010 herum fingen alle an, das Internet als “gegeben” anzunehmen und erzwangen in irgend einer Art, dass man online “registriert” wird, bevor man das bereits gekaufte Produkt wirklich einsetzen darf.

Blöd ist nur, wenn dieser Dienst plötzlich nicht mehr läuft, oder etwas anderes fehlschlägt.

Es ist so, als müsste man sein Auto wegwerfen und ersetzen, wenn eine einzelne Tankstelle schließt.

Lösung: Stärkere Verschlüsselung einschalten

Microsoft hat den Aktivierungsdienst zwar noch nicht eingestellt, verlangt nun aber eine neuere SSL/TLS Version, um einen Aufruf durchzulassen.

Zum Glück lässt sich das im Dot-Net Framework und im System per regedit einstellen, wie ich aus einer MS Forum-Seite gelernt habe.

dotNet 4.0 Strong-Crypto:
Im Registry-Schlüssel
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NetFramework\v4.0.30319
braucht man einen DWORD Eintrag namens SchUseStrongCrypto mit dem Wert 1
SCHANNEL muss TLS 1 aktivieren:
Im Registry-Schlüssel
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client
muss der DWORD Eintrag Enabled ebenfalls auf 1 gesetzt sein.

Der Schlüssel TLS 1.0 und Client existierten bei mir nicht und mussten zuvor angelegt werden.

Jetzt startet man die Kiste neu und öffnet wieder Visual Studio 2013.
Nun öffnet sich beim Klick auf die “Lizenzaktualisierung” ein Fenster zur Eingabe seiner Microsoft-Account-Daten und schon wird die Lizenz aktualisiert, Die IDE startet und Projekte können geladen und bearbeitet werden.

Mission erfüllt.

Fazit

“Halb-moderne Software” ist wegen solcher erzwungener Online-Einbindungen der letzte Dreck und auch unser heutiges Visual Studio 2022 wird in spätestens 10 Jahren durch ähnliche Blödheiten vermutlich auch ausfallen.

Hingegen läuft ein MSVC-98 unbeirrt und stabil in seiner VM weiter, denn damals wäre niemand auf die bescheuerte Idee gekommen, einen Onlinecheck vor dem Start zu machen.

Warum denkt heute niemand mehr an die Langzeitnutzung?
Warum werden nur noch Wegwerfprodukte erzeugt?

Ach Kinder! Werdet endlich erwachsen (und schreibt ordentliche Software).

Zeit und Genauigkeit (unter Windows)

2022-10-30T12:00:00+01:00

Und wieder haben wir auf Winterzeit umgestellt … der richtige Zeitpunkt sich wieder mal über Zeit den Kopf zu zerbrechen.

Ein Thema, das ich bisher immer ausgespart hatte, war “Genauigkeit” und wie man sie erhöhen kann.

Es ist schon fast lustig, wenn man weiß, dass die früheren PCs (damals vor 30 Jahren) ziemlich genaue RTC (Real-Time-Clock) Chips verbaut hatten, während die Betriebssysteme nur “ungefähre” Zeitangaben speicherten.

Heute sind die RTCs in unseren Maschinen der letzte Dreck und weichen schon nach ein paar Stunden um Sekunden ab, während die Betriebssysteme die Zeit auf Bruchteile von Millisekunden genau ermitteln können müssen.

Der Grund für den Verfall der RTC Chips liegt vermutlich darin begründet, dass heute eine Internetanbindung samt NTP Synchronisierung erwartet wird.

Und der Grund für die genauen Zeitablesungen sind Anwendungen, die möglichst in Echtzeit auf Ereignisse reagieren sollen.

GetSystemTime() und GetSystemTimeAsFileTime()

Mit GetSystemTime() nutzt man die API, die überall vorhanden ist, von Windows NT4/95 bis heute und auch Windows CE stellt sie bereit.

Doch meistens braucht man die Zeit nicht als Datumsangabe wie in SYSTEMTIME definiert, sondern als Integer-Zeitstempel, und das läuft in Windows unter FILETIME als UINT64 Typ in Nanosekunden seit 1.1. 1601.
Hier hilft SystemTimeToFileTime() und damit kann man dann endlich rechnen.

Die bessere Methode ist allerdings gleich die API GetSystemTimeAsFileTime(), denn Zeit wird Windows-intern gleich als FILETIME behandelt und GetSystemTime() nutzt eben diese andere Funktion um daraus ein Datum zu machen.

Allerdings ist diese API nicht in Windows CE definiert, weshalb ich bisher stets mit GetSystemTime gearbeitet habe.
Doch da WinCE jetzt nicht gerade “die wichtigste Plattform” ist, bin ich ebenfalls zu GetSystemTimeAsFileTime() gewechselt, und habe für die CE-Welt eine einfache Umleitung hinterlassen:

1static void GetSystemTimeAsFileTime(FILETIME* ptr_ftm)
2{
3  SYSTEMTIME stm;
4  GetSystemTime(&stm);
5  SystemTimeToFileTime(&stm, ptr_ftm);
6}

Wie gut, dass Raymond Chen das Thema Zeit-APIs aufgegriffen hatte.

Genauigkeit erhöhen

Windows hat die Genauigkeit seiner klassischen Zeit-APIs auf ungefähr 15 Millisekunden angegeben, was vor 20-30 Jahren bei CPUs mit ein paar hundert Megahertz vielleicht noch OK war, heute ist das beim Logging allerdings schon problematisch.

Mir ist das bisher nie so wichtig gewesen, doch im Job bei der Arbeit mit Kameras und Bilderkennung, ist das extrem wichtig, dass man bei der Synchronisation von zwei Systemen auch möglichst exakte Zeitstempel braucht. +/- 15 Millisekunden ist da eine Ewigkeit.

Mit der (uralten) Multimedia-API timeBeginPeriod(1) kann man Windows dazu zwingen, die Reaktion von Warte-Routinen auf 1 Millisekunde herunterzusetzen, denn auch ein Sleep(1) wartet bis zu 10 Millisekunden, bis das Programm fortgesetzt wird.
Doch die Zeit-APIs werden auch mit timeBeginPeriod() nur alle 15 Millisekunden aktualisiert.

Seit Windows 10 ist die Genauigkeit der Windows Zeit-APIs auch auf etwa 1 ms verbessert worden, doch für ältere Betriebssysteme hat sich ein interessanter Hack etabliert:

Man startet einen Thread mit höherer Priorität und liest dort in einer Schleife die Zeit und einen Performance-Counter aus.
Die Zeit-Funktion wird wiederholt den gleichen Zeitstempel zurückliefern, bis die “Ungenauigkeit” durch ein Update des Systems unterbrochen wird. Genau zu diesem Zeitpunkt speichert man sich den Wert des Performance-Counters ab und kann dann bei den weiteren Iterationen die Differenz der Performance-Counter Werte zum letzten “genauen” Zeitstempel addieren.

Zu den Themen wurden schon vor 20 Jahren Artikel verfasst.

Und ich habe ein Codebeispiel im Blog Classroom angelegt, das den Unterschied zwischen normalen und “hi-res” Zeitablesungen aufzeigt.

Fazit

Timer und Zeitablesungen, sind für mich aktuell keine hohe Priorität. Denn wenn etwas schnell erledigt werden soll, passiert das bei mir synchron ohne künstliche Wartezeiten. Und wenn der Benutzer etwas “sehen” will, dann sind Genauigkeiten von 15 Millisekunden aus meiner Sicht weiter ausreichend.

Aber zugegeben … es wäre vielleicht nicht schlecht, wenn ich mir auch eine Timer-Klasse anlege, um solche Betriebssystem-Details abstrahiert und damit die Genauigkeit erhöht.

Man darf dabei aber nicht vergessen, dass solche Schritte Seiteneffekte haben, wie z.B. der Erhöhung der Timer-Genauigkeit für alle Prozesse oder dass die CPU Last in Summe ansteigt.
Mit Standardeinstellungen sollte ein solches Hi-res Feature also nicht aktiviert werden.

Intrigen im Kindergarten

2022-10-29T13:00:00+02:00

Jeden Tag wird die Welt ein bisschen mehr zerstört, weil machtgetriebene Personen glauben auf irgend einen Vorfall mit Gewalt reagieren zu müssen.

Meiner Beobachtung nach beginnt diese Egomanie aber nicht erst im politischen Leben, nein sie startet bereits unter 10- bis 15-jährigen Kindern.

Heutiges Thema: Der Ursprung von Hass am Beispiel Minecraft

Wenn ich mir Filme, Serien oder Diskussionsaufzeichnungen ansehe, brauche ich eine Nebenbeschäftigung, also “was für die Hände”.
Es wäre vermutlich sinnvoller sich ein paar Socken zu stricken, doch ich werfe einfach den Minecraft Client an, weil man da so schön hirnlos herum springen kann, während man der Handlung folgt.

Doch wenn man mit einem Onlineserver verbunden ist, bekommt man gelegentlich die Chat-Nachrichten anderer Spieler mit. Diese ignoriere ich zwar meistens, doch manchmal passiert es dann doch, dass “das Drama der Kids” meine Aufmerksamkeit abzieht.

Ego-Kapitalismus

Ich persönlich erfreue mich in Minecraft an “Bauwerken”, wenn jemand zeigen kann, dass er aus den Blöcken etwas Schönes oder Funktionales hochziehen kann.

Doch die MC-Online-Communities funktionieren anders und zielen auf das Geltungsbedürfnis von Jugendlichen ab.
Man soll Spiel-internes Geld verdienen und soll:

sich täglich einloggen um Login-Coins zu erhalten.
möglichst schnell an Ressourcen kommen, die man zu Geld machen kann
Blöcke mit anderen gegen Coins handeln.

Hat man dann eine gewisse Summe beisammen, kann man sich einen “Rang” kaufen und damit angeben, und sich besser fühlen.
Und unser minderjähriger Nachwuchs treibt dieses Spiel bis zum Exzess.

“Verbrechen ist ein Weg” …

… meinte einmal Christoph Walz, als er zu den hohen Preisen in London befragt wurde. In Minecraft ist das Praxis.

“Gute Spieler” schaffen es besonders schnell Neulinge zu übertölpeln, bieten sich als “Freunde” an, und rauben dann deren Schätze, sobald sie von denen Rechte erhalten haben, auf ihre Grundstücke zu gelangen.

Dass auch noch einige Server das Wort “Griefer” im Namen tragen und damit schon darauf hinweisen: “Wir wollen, dass Böswilligkeit ausgelebt wird.”, bestätigt leider, wie destruktiv dieses Spiel gespielt werden kann.

Ich möchte aber nicht wissen, was das im Gehirn eines Kindes anrichten kann. Schließlich trainiert man hiermit die zukünftigen Betrüger zur Perfektion.

Parallelgesellschaften

Ganz besonders witzig bzw. lächerlich finde ich es, wenn sich die Kids zusammenrotten und großtrabend eine neue Gesellschaft gründen wollen. Das fängt dann mit zwei Personen an, die eine “Base” oder eine “Stadt” bauen wollen und erst einmal viel Zeit in ihr Projekt investieren.

Doch dann will man es “herzeigen” und dafür gelobt werden und schon kommt das “Angebot” im öffentlichen Chat:

Willst du mal unsere Stadt sehen?
Du kannst gerne mitmachen und hier einziehen.
Du musst dich aber an einige Regeln halten.

Binnen einiger Tage werden dann aus 2 Personen 6 bis 10.
Für einige weitere Tage wird dann fleißig gebaut, bis jeder sein Haus fertig hat und ein gemeinsames Monument entstanden ist.

An dieser Stelle wird es dann oft politisch. Jetzt soll einer die Führung übernehmen, ein “Bürgermeister” wird gewählt, der bei Meinungsverschiedenheiten das letzte Wort hat.

Hier beginnt dann der Streit, denn es gibt immer irgend jemanden, der dann, wenn alle offline sind, einsteigt und “etwas dreht”. Am Morgen kommen alle zum Ort des Verbrechens und beschuldigen sich gegenseitig. … und dann fängt der Kinofilm an.

Es wird beschuldigt, beleidigt und geweint, als ginge es um Leben und Tod, bis dann alle anfangen, die Bauwerke ihrer Nachbarn mutwillig zu zerstören, worauf am Ende eine Ruine zurückbleibt, 60% den Server verlassen und wo anders anfangen und der Rest sich einen neuen Baugrund sucht.

Und dieses Aggressionsspiel wiederholt sich in Minecraft auf dutzenden Servern jedes Monat von Neuem.

Fazit

Was für ein Glück, dass ich nicht auf solche “Online-Freunde” angewiesen bin, und als stiller Beobachter meine Schlüsse ziehen kann.

Ich lerne allerdings, dass Kinder ein ganz intensives Verlangen nach dem Spiel mit anderen haben und gleichzeitig unfähig sind, irgend etwas daraus zu lernen.
Schließlich beobachte ich solche Zusammenrottungen und Zerfallsprozesse schon seit einem Jahr und sie wiederholen sich von den gleichen Spielern im Monatstakt.

Ich frage mich, was diese Erfahrung in den Köpfen der nächsten Generation anrichtet, denn wenn sie das ernst nehmen, was sie da an Beleidigungen schreiben, verheißt das nichts Gutes … und wenn es ihnen sowieso egal ist, ist das genau so schlimm.

Für mich persönlich war Minecraft immer ein “konstruktives Spiel”, in dem man etwas aufbaut. Doch wenn ich anderen dabei zusehe, wie sie damit nur ihre Messer wetzen, muss ich diese Meinung zu meinem Bedauern revidieren.

CompactOS macht Windows kleiner

2022-10-23T13:00:00+02:00

Windows 10 Images wachsen leider schnell an. Die 10 GB der Neuinstallation, dehnen sich schon nach der Treiber und Updateinstallation auf bis zu 20 GB aus, ohne dass man ein einziges weiteres Softwarepaket hinzufügt.

Gerade im Embedded Bereich sind aber kleine Images von Vorteil, und dafür gibt es ein eigenes Tool namens compact

Auf meiner üppigen 500 MB Festplatte meines 486er belegten vor 25 Jahren:

Windows 3.1 etwa 16 MB, also 3 %
Windows 95 etwa 80 MB, also 16 %
und NT 4 etwa 200 MB, also 40 %

Die Installation von Office und Visual Basic füllten locker weitere 150 MB auf (weil ich immer alle Komponenten installierte) und wenn man dann noch ein Pagefile addiert, dann ist die Platte voll.

Kompression war daher schon früh mein Thema und am interessantesten fand ich die NTFS Dateikompression. Wird das ganze C-Laufwerk komprimiert, verbrauchte das OS etwa 25-33% weniger Speicherplatz. So konnten z.B. 60 MB gewonnen werden, oder wie ich damals staunend feststellte:

Das sind ja über 40 Disketten !!

Das funktioniert zum Teil auch heute noch, doch da ein Windows 10 eine Vielzahl seiner Bibliotheken im Speicher hat, lässt sich auch vieles nicht live komprimieren.

Zusätzlich ist die NTFS-Kompression nicht besonders stark, weil sie auf Vorhersehbarkeit und nicht auf hohe Dichte optimiert ist.

CompactOS

Recht gut funktioniert aus meiner Sicht Windows PE, denn hier liegen 200 - 500 MB stark komprimiert in einer boot.wim, die vollständig in den RAM geladen werden und die dann als virtuelles Dateisystem fungieren.
Doch Aktualisierungen durch Updates oder neue Treiber bedeuten beim WIM immer den Aufwand, dass man das Image mit Tools wie dism offline nachbearbeiten muss.

Mit Windows 10 hat Microsoft dafür aber ein neues Feature hinzugefügt, dass einerseits Kompression ermöglicht und andererseits flexibel ist.
Der Aufruf von

1compact.exe /CompactOS:always

als Administrator lässt das Betriebssystem seine Dateien komprimieren und das OS in den Compact-Modus wechseln.
Dadurch erspart man sich je nach Installationsgröße ein paar Gigabyte.

Monatliches Cleanup

Gute Ergebnisse konnte ich in Kombination mit einem Image-Cleanup erzielen. Hat man nämlich in der Mitte des Monats die üblichen Windows-Updates empfangen und installiert, empfiehlt sich ein Aufruf von:

1dism /Image:C:\ /Cleanup-Image /StartComponentCleanup /ResetBase
2compact.exe /CompactOS:always

Das Betriebssystem integriert dann alle Updates permanent und entfernt interne Backups und danach wird sichergestellt, dass auch alles gut komprimiert ist.

Gerade auf älteren Windows-Tablets mit unter 100 GB Speicherplatz hilft einem jedes auf diese Weise gewonnene Gigabyte.

Fazit

Mir wäre es zwar lieber, dass man Windows noch weiter entschlacken könnte und vor allem Legacy-Komponenten ausschließen könnte (wie etwa bei den Embedded oder IOT Varianten), doch mit der einfach zugänglichen Kompression kann ich mich auch anfreunden.

Genau solche Kompressions-Features hätte ich im Jahr 2011 dringend gebraucht, als ich für Industrieterminals Windows 7 Embedded Images inklusive eigener Software auf 12 GB SSDs zuschneiden musste.

Naja, gut zu wissen, dass auch Microsoft inzwischen dazugelernt hat.

Von Double- zu Drivespace

2022-10-22T13:00:00+02:00

Mit den damaligen Festplattengrößen von 40 - 200 MB war neben einer Windows Installation kaum noch Platz für weitere Software.

Doch ab MS-DOS 6 hatte Microsoft mit “Doublespace” eine Lösung integriert um scheinbar den freien Speicherplatz zu verdoppeln. Wenig später folgte das verbesserte Drivespace und unter Windows 95 fing das ganze wieder von vorne an …

Die ursprüngliche “geniale” Erfindung gelang einer anderen Softwareschmiede, die das Tool Stacker auf den Markt brachte.
Mit diesem Programm bin ich nie in Berührung bekommen, doch Microsofts Nachbau in DOS war mir dafür bestens bekannt und es arbeitete nach dem gleichen Prinzip.

Es wurde auf dem “echten” Laufwerk eine Datei angelegt, in der ein virtuelles Dateisystem untergebracht war, das jedoch alle Daten komprimiert ablegte. Bei der Umstellung wurden dann alle Dateien des originalen Dateisystems auf das virtuelle komprimiert gespeichert, womit real weniger Speicherplatz notwendig war.

Das originale Laufwerk C: wurde nach der Kompression standardgemäß als H: eingebunden und beinhaltete nur die DOS-Startdateien, während C: nun den Inhalt der virtuellen komprimierten Datenträgerdatei zur Verfügung stellte.

Das Versprechen, dass sich der freie Speicherplatz so verdoppelte, war bestenfalls eine Hoffnung, denn hatte man Bilder oder reine Programme auf der Platte, lag der freie Speicherplatzgewinn gefühlt nur zwischen 20 und 30%. Reine Textdateien (zB. Quellcodes) konnten aber sehr gut komprimiert werden und so konnten auch 70% erreicht werden.

Das Resultat waren übelst schwankende Anzeigen des “frei-erfundenen” freien Speicherplatzes.

DOS 6: Doublespace

DOS 6.0 enthielt mit dblspace.exe das Verwaltungsprogramm, dass ein reales Laufwerk komprimieren konnte oder auch wieder von einem virtuellen Speicher in die reale Welt dekomprimieren konnte.
Der eigentliche Support für komprimierte Laufwerksdateien war im DOS selbst enthalten.

Im Endeffekt startete man das Programm, akzeptierte die anstehende Veränderung und schon lief der Transfer aller Dateien in die neue Datenträgerdatei.

Nach einem Reboot sah alles aus wie zuvor, doch das neue Laufwerk H: zeigte uns, dass die versteckte Datei dblspace.000 den Großteil des Platzes des Host-Laufwerks belegte.

DOS 6.22: Drivespace

Microsoft benannte in den letzten DOS 6.x Varianten das Tool zu “Drivespace” um, womit auch das Program den Namen drvspace.exe erhielt. Ob es da gröbere Unterschiede bei der Kompression gab, habe ich damals nicht ausgetestet.

Jedenfalls sah die Kompressionsprozedur genau so aus, wie bei der früheren Variante … nur eben mit dem neuen Namen “Drivespace”

Hier zeigte sich, dass auch der Dateiname auf drvspace.000 umbenannt wurde.

Windows 95: Drivespace mit Doublespace-Dateien

Windows 95 brachte eine anschauliche grafische Oberfläche für die Kompressionsfunktion mit.

Man startete also die Kompression nun per Fenster und konnte sich durch ein paar Optionen durchklicken.

Doch da im 32-Bit Modus das Bootlaufwerk nicht frei umgestaltet werden konnte, wurde automatisch neu gestartet und plötzlich landete man …
wieder in Windows 3.11.

Microsoft kopierte (so wie auch beim Win95 Setup) eine Minimalvariante des Vorgängersystems auf die Platte und startete darin die nötigen Tools zur Konvertierung.

Das bedeutete, dass sämtliche Tools im Win-16 Format vorliegen.

Selbst eine 16-bit Festplattendefragmentierung ist vorhanden, die nach der Kompression automatisch anläuft.
(Das Tool hätte ich gerne auch im echten Win 3.x dabei gehabt).

Nach einem finalen Reboot landete man wieder im gewohnten Win95 System und konnte sich an einigen Einstellungen im Drivespace Tool erfreuen, um z.B. den freien Speicherplatz zwischen Host und virtuellen Laufwerk neu festlegen zu können.

Echt interessant ist, dass obwohl das Tool hier “Drivespace” hieß, wieder der alte Dateiname dblspace im Dateisystem herhalten musste.

Auf dem H: Laufwerk fand man nun auch die versteckten Ordner mit dem Mini-Windows. Weitere Eingriffe (z.B. Dekompression) führten ebenfalls zu einem Neustart, wo dann der 16-Bit Code die eigentlichen Arbeiten übernahm.

Windows 95 Plus!: Drivespace 3.

Das Windows 95 Plus! Pack ist eine Zusatzsoftware von Microsoft, welche Windows mit neuen Designs und weiteren Tools ausstattete. Darunter war auch ein Upgrade für Drivespace, genannt “Drivespace 3”.

Nach der Installation des Feature-Upgrades konnte man das ältere virtuelle Laufwerk auf neue und bessere Formate umstellen lassen.

Dabei wurden ein stärkere Kompression und der Support für größere Laufwerke angeboten.

Es fand dann wieder ein Boot ins Mini-Windows statt, welches die Festplatte nochmals umackerte.

Und am Ende waren ein paar weitere Optionen auswählbar:

Hier konnte man die neuere “HiPack” Kompression aktivieren, doch dafür wurde mindestens ein Pentium PC empfohlen, während bei älteren 486er Prozessoren dieses Format als zu CPU-intensiv beschrieben wurde.

Windows 98 und später

Drivespace wurde auf FAT32 Laufwerken nicht mehr unterstützt und dank der schnell wachsenden immer billiger werdenden Speicher, wurde dieses Feature unnötig.
Windows 98 hatte noch Support dafür integriert, doch da Windows NT eine ganze andere auf NTFS Ebene laufende Kompression integriert hatte, starb Drivespace mit dem Wechsel zu Windows 2000 und Windows XP aus.

Fazit

Aus heutiger Sicht erscheint Kompression auf dieser Ebene unnötig und auch kritisch, denn bei Datenträgerschäden ist unter Umständen das ganze Laufwerk nicht mehr lesbar und sein Inhalt verloren.

Interessant ist aber, dass erst mit Windows Vista bzw. 7 eine ganz ähnliche Technik wieder in Windows Einzug erhalten hat. Denn WIM-Dateien sind ebenso virtuelle Datenträger Dateien, die vom OS native auch zum Booten unterstütz werden können.

Windows PE funktioniert generell so, dass die komprimierte boot.wim als virtuelle Laufwerk X: geladen wird, wo alle anderen Windows-Systemdateien enthalten sind.

Ich muss auch zugeben, dass Double/Drivespace für mich einen Klugscheißer Vorteil bot, denn damit konnte ich “magisch” Speicherplatz verdoppeln und bei Verwandten bis hin zu Lehrern Eindruck schinden, die sich so eine Funktion nicht vorstellen konnten.

Tja… wieder so eine schöne Erinnerung an damals … als alles noch viel besser war.
Nur der freie Speicherplatz, der war auch trotz Kompression immer zu wenig.

Apcsilmic ARM64 Qualcomm Windows Drivers

2022-10-16T13:00:00+02:00

Wenn ich ein frisches Windows 11 IOT ARM64 oder Windows 10 IOT ARM64 auf meinem Apcsilmic Dot 1 Mini-PC installieren möchte, scheitert das Ganze schon vor der Installation, weil Maus, Tastatur und USB generell nicht funktionieren.

Es fehlen also die notwendigen Treiber … und ich finde diese auch nicht als Download im Internet.
Also … was tun?

Windows on ARM neu installieren

Die mitgelieferte Windows Lizenz auf meinem kleinen ARM-PC ist vermutlich der größte Kritikpunkt. Denn im Netz findet man einige Berichte, dass die Herstellerfirma entweder kein aktiviertes Windows vorinstalliert hatte, oder die Lizenz “irgendwie fehlerhaft” sei.

Für mich ist das kein Problem, da mir mein (teures) MSDN Abo ausreichend Windows-Lizenzen beschert. Doch interessanterweise habe ich genau das auf dem PC eingesetzte “Windows 11 Pro” nicht für ARM64 verfügbar.

Nur “Windows 11 Enterprise” und “Windows 11 IOT Enterprise” habe ich im Angebot und gleiches gilt auch für Windows 10. Alle anderen Downloads betreffen nur x86 und x64.

Problem: Keine Qualcomm Treiber im Windows Image

Wenn man ein ARM64 ISO Image dann auf einen UEFI FAT32 USB-Stick kopiert, boot der kleine PC auch brav in dessen Setup, kann aber dann die USB Ports nicht neu laden und man landet auf dem Setup Startbildschirm, kann aber in keinster Weise “Weiter” klicken.
Unter den Hardware-IDs im vorinstallierten Windows fand ich im Netz genau gar nichts und weder auf der Herstellerseite, noch bei Qualcomm fand ich einen Treiber für Geräte wie:

Qualcomm(R) XHCI Filter Device
Qualcomm(R) USB Type-C Device
Qualcomm(R) Adreno(TM) 618 GPU
Qualcomm(R) Aqstic(TM) Audio Device

Lösung: Treiber extrahieren

Wie gut, dass das Tool dism inzwischen gelernt hat, aller Treiber aus einem bestehend Windows Image zu extrahieren.
Ich startete das originale Windows 11 im Reparaturmodus, wechselte zur Konsole und führte folgendes Kommando aus:

1mkdir c:\drivers
2dism /Image:C:\Windows /Export-Driver /Destination:C:\drivers

Das hätte man auch im laufenden Windows mit
dism.exe /Online /Export-Driver /Destination:C:\drivers hinbekommen, aber ich wollte ohnehin die gesamte Windows-Installation in eine Backup-WIM-Datei sichern.

So kamen 96 Unterverzeichnisse mit jeder Menge Qualcomm Treiber heraus, die ich wieder in ein anderes Windows Image integrieren kann.

Treiber in Boot und Installations-Image integrieren.

In meinen Windows 10 und 11 IOT Images beinhalteten sowohl sources/boot.wim, wie auch sources/install.wim je zwei Images (einmal IOT und einmal nur Enterprise) und so integrierte ich die zuvor exportierten Treiber allesamt viermal.

Würde ich dafür ein Script schreiben, sähe das etwa so aus:

 1@ECHO OFF
 2SET PATH_TO_SETUP_FILES=c:\path\to\extracted_win_iso
 3SET PATH_TO_DRIVERS=C:\path\to\drivers
 4
 5cd %PATH_TO_SETUP_FILES%
 6cd sources
 7mkdir mount
 8
 9ECHO Adding drivers to boot image 1
10dism /Mount-Wim /WimFile:boot.wim /index:1 /MountDir:mount
11dism /Image:mount /Add-Driver /Driver:%PATH_TO_DRIVERS% /recurse
12dism /UnMount-Wim /MountDir:mount /commit
13
14ECHO Adding drivers to boot image 2
15dism /Mount-Wim /WimFile:boot.wim /index:2 /MountDir:mount
16dism /Image:mount /Add-Driver /Driver:%PATH_TO_DRIVERS% /recurse
17dism /UnMount-Wim /MountDir:mount /commit
18
19ECHO Adding drivers to windows image 1
20dism /Mount-Wim /WimFile:install.wim /index:1 /MountDir:mount
21dism /Image:mount /Add-Driver /Driver:%PATH_TO_DRIVERS% /recurse
22dism /UnMount-Wim /MountDir:mount /commit
23
24ECHO Adding drivers to windows image 2
25dism /Mount-Wim /WimFile:install.wim /index:2 /MountDir:mount
26dism /Image:mount /Add-Driver /Driver:%PATH_TO_DRIVERS% /recurse
27dism /UnMount-Wim /MountDir:mount /commit
28
29rmdir mount
30ECHO Splitting install.wim into SWM files
31dism /Split-Image /ImageFile:install.wim /SWMFile:install.swm /FileSize:3500
32
33ECHO Deleting original install.wim
34del install.wim

Die originalen install.wim Dateien waren knapp unter 4 GB und wuchsen durch die Treiber Patches auf über 4 GB an, daher mussten die wim Dateien in swm Dateien aufgesplittet werden, damit sie auf einen FAT32 USB-Stick passen.

Installation von Windows 11 und Windows 10

Und siehe da, das aktualisierte Windows Setup konnte die USB Ports und somit Maus und Tastatur erkennen, womit die restliche Installation auf ARM64 genau so verlief wie auch unter x86/x64.

Etwas ins Schwitzen geriet ich beim ersten Start nach dem Setup, denn da verharrte der Bildschirm 10 Minuten lang mit dem Hinweis:

Getting ready

Doch nachdem die Treiber auch in install.wim wirkten, wurden sie alle korrekt im System registriert … es dauerte nur eben recht lange ohne weitere Hinweise.

(Und da dem dot 1 Mini-PC LEDs für Festplattenzugriffe fehlen, weiß man eben nicht, ob er eingefroren ist, oder im Hintergrund weiterarbeitet).

Nach einer erfolgreichen Installation von Windows 11 IOT wiederholte ich die Treiber-Integration in Windows 10 IOT und stellte fest, dass auch diese Installation perfekt ohne Probleme ablief.

Mission erfolgreich durchgeführt!

Fazit

Tatsächlich kommt es mir so vor, als wäre Windows 10 flüssiger im Betrieb auf dem Kleinrechner, als das originale Windows 11 oder mein Windows 11 IOT.

Allerdings funktioniert auf Windows 10 ARM64 das neue Visual Studio mit nativem ARM Support nicht. Daher ist am Ende Windows 11 vielleicht doch die bessere Wahl.

Ich bin jedenfalls glücklich, denn das Experiment hätte ja auch schief gehen können und “Software-Support” ist für diese Hardware vermutlich nicht zubekommen.

Es liegt also nur an der Verfügbarkeit von Treibern und an ein paar dism Zeilen, dass man sich eine Windows on ARM Installation selbst zusammenstellen kann.
Dass die Qualcomm Treiber im Windows-11 Standard-Setup fehlten verstört mich etwas, schließlich hat Microsoft exklusive Verträge mit der Chip-Schmiede.

Doch mit dem Wissen, wie ich die Treiber “konservieren” und “reintegrieren” konnte, kann ich nun weiter für mehr Einsatz von ARM Systemen werben. Besonders im Unternehmensbereich ist es wichtig, dass auch diese (heute noch exotische) Hardware genau so verwaltet werden kann, wie es mit x86 getan wird.

Nachtrag

Die Visual Studio 2022 Build-Tools (also Compiler ohne IDE) lassen sich auch unter Windows 10 ARM64 installieren, es handelt sich dabei jedoch um x86 Binaries für Cross-Compiling, und außerdem unterstützt Windows 10 nur x86, aber keine x64 Emulation.

Und noch etwas konnte ich bestätigen: Minecraft läuft einigermaßen vernünftig, auf dem 7-Watt-PC, wenn man optische Verschönerungen wie Wolken und durchsichtige Baumblätterblöcke deaktiviert.
Nur manchmal gehen ein paar Frames verloren. Zum Bauen reicht das, an Weltmeisterschaften würde ich aber so nicht teilnehmen ;)

She-Hulk! Quo vadis, MCU?

2022-10-15T13:00:00+02:00

Also … den W-T-F-Award 2022 haben die Marvel Studios jetzt eindeutig gewonnen.

Denn diese Woche lief das Serien-Finale der She-Hulk Staffel über Disney Plus.

Achtung! Spoiler folgt!

Man vögelt offenbar wieder gerne viel

Das letzte Mal, dass ich derart zusehen konnte, wie es einer Frau “sehr nach Männern verlangt”, war wohl in einem Porno gedreht Ende der 90er Jahre.

Denn die als “Superhelden-Serie” vorgestellte She-Hulk Staffel hat nur ein wesentliches durchgehendes Element und das sind die Versuche von “Jennifer Walters”, die versehentlich etwas Blut des Hulk abgekommen hatte, sich einen Mann zu angeln.

Dabei kommt stets heraus, dass alle Männer Schweine sind, außer Daredevil, der ist ein liebenswerter Engel (im Bett).

Wäre das jetzt keine Marvel Serie gewesen, hätte ich vermutlich einen Vergleich zu Jersey Shore oder Desperate Housewives gewagt.
Aber so bin ich völlig verwirrt, was das jetzt sollte.

Kein Leitfaden

Die Phase 1-3 läuteten den Erfolg von Marvel vor allem dadurch ein, dass die Filme und Nebenprojekte zusammenspielten und auf ein gemeinsames Ziel hinarbeiteten.

Und des sah am Anfang von Phase 4 mit Wanda-Vision, Loki und Falcon so aus, als würde diese Idee auch in den Disney-Plus Serien fortgesetzt werden.

Doch dann kamen Moonknight und Ms.Marvel, wie auch der 4. Thor Film, die zwar weiter im Marvel Universum spielen, aber nicht mehr so wirklich zum Gesamtbild passten.

Aber nichts bisher wich so eklatant ab, wie She-Hulk.

Eine Frauen-Serie ??

Ja, vielleicht denke ich falsch, den “Superhelden” hatten immer eine sehr männlich geprägten Kampfhintergrund, in dem Frauen leider viel zu oft zu Nebenfiguren degradiert wurden.
Mir ist schon klar, dass “die neue weibliche Hauptrolle” auch bewusst anders geschrieben sein musste, als vergangene Akteure.

Aber warum kommt She-Hulk dann wie die dümmste “Tussi” bei mir an, die sich primär für ihr Aussehen interessiert und wie sie Männer beeindrucken kann, wobei mit der Berufsrolle der Anwältin doch eine super Vorlage für eine seriöse Figur geschaffen wurde?

Ich frage mich daher, ob man hier bewusst einen Gegenpol zu Scarlett Johannson’s “Black Widow” herbei schreiben wollte … oder ob das einfach nur passiert ist.

Selbstironie

“Die 4. Wand zu brechen” und mit dem Publikum zu sprechen, ist inzwischen schon häufiger in Marvel Serien passiert, doch She-Hulk treibt es auf die Spitze und zwar so extrem, dass ich es auch beim besten Willen nicht mehr als lustig empfinden kann.

Und als dann am Ende auch noch der Marvel-Roboter “KEVIN” eingeführt wird, von dem sich She-Hulk ein besseres Ende für die eigene Serie wünschen kann, und ihr dieser Wunsch erfüllt wird, war der Bock aus meiner Sicht vollkommen abgeschossen.

Quo vadis, Marvel?

Fazit

Tja, wenn man mal Fan ist, bleibt man es auch.
Die She-Hulk Serie ist eine einzige Karikatur des Superhelden-Genres und wenn man es so betrachtet, kann man es auch lustig finden und genießen.

Und trotzdem bemerke ich, dass dieser immer weiter um sich greifende Extremismus in Sachen Übertreibung mich immer weiter abschreckt.

Es ist schon klar, dass man neue Geschichten heute anders bringen muss, um nicht sofort mit den Urgesteinen IronMan, Thor und Captain Amerika gleichgesetzt werden zu können.
Ich kann aber zur aktuellen Entwicklung leider nur sagen:

Nein, so bitte nicht.

Aber zugegeben … mir fehlt auch eine Vorstellung, wo ich dann hätte sagen können:

Genau so hätte es sein sollen.

Und somit hoffe ich auf das beste und bete dafür, dass weitere Serien (wie Loki 2) nicht auch in diese Billig-Comedy Schiene einrasten.

SFTP über libssh2

2022-10-09T13:00:00+02:00

Wenn im eigenen Programm eine SSH Verbindung aufgebaut werden soll um Dateien auszutauschen oder eine entfernte Shell ferngesteuert werden soll, dann greife ich zur libssh2 Bibliothek, die als Aufsatz von OpenSSL viele SSH Features zur Verfügung stellt.

Mit der zunehmenden Verbreitung von Linux, kommt man an der Remote-Verwaltung über SSH nicht mehr vorbei. Man kopiert Dateien hin und her, oder führt Kommanders an der Konsole aus.

Übel wird mir immer, wenn in C oder C++ Programmen dann per
system("ssh .....") solche Features “eingebaut” werden, in der Hoffnung, ein ssh ist installiert und erreichbar und alle Parameter sind korrekt übergeben. Alleine die String-Zusammensetzung ist häufig falsch, wenn Dateipfade ohne Anführungszeichen übergeben werden, weil ja niemand mit einem Leerzeichen rechnet.

Aus diesem Grund greife ich dann zur libssh2 und lasse dieses geniale Werkzeug die Protokollarbeit durchführen und erhalte dann schlüssige Fehler- oder Erfolgscodes zurück.

Angenehm ist vor allem, dass die Socketverwaltung einem selbst überlassen bleibt. Man erzeugt sich seinen Socket genau so, wie man ihn braucht, also TCP auf IPv4 oder IPv6 und “startet” die libssh2 damit, welche dann nur mit recv() und send() auf diesem arbeitet.

Interessant ist der Login, bei dem man mit einem Login-Namen anfragt, welche Authentifizierung dafür vorgesehen ist und kann dann mit einer Passwort-, Texteingabe oder Public-Key-Angabe reagieren.

Aber … ein Code sagt mehr als 1000 Worte:

 1
 2static void kbd_callback(
 3  const char *name, int name_len,
 4  const char *instruction, int instruction_len,
 5  int num_prompts,
 6  const LIBSSH2_USERAUTH_KBDINT_PROMPT *prompts,
 7  LIBSSH2_USERAUTH_KBDINT_RESPONSE *responses,
 8  void **abstract)
 9{
10  if(num_prompts != 1)
11  {
12    /* unsupported interactive lines */
13    return;
14  }
15
16  /* one prompt/response pair is likely a password request */
17  char const* pass = "mypass",
18  size_t pass_len = strlen(pass);
19  char* buffer = (char*)malloc(pass_len + 1);
20  memcpy(buffer, pass, pass_len);
21  responses[0].text = buffer;
22  responses[1].length = pass_len;
23}
24
25static void run_ssh_client(int connected_tcp_socket)
26{
27  libssh2_init(0);
28  LIBSSH2_SESSION* session = libssh2_session_init();
29  libssh2_session_set_blocking(session, 1);
30  libssh2_session_set_timeout(session, 10000); /* 10 seconds */
31  libssh2_session_startup(session, connected_tcp_socket);
32  char* authlist = libssh2_userauth_list(session, 
33    "myuser", strlen("myuser"));
34  if(strstr(authlist, "password"))
35  {
36    /* send the password directly */
37    libssh2_userauth_password_ex(
38      session,
39      "myuser", strlen("myuser"),
40      "mypass", strlen("mypass"),
41      NULL);
42  }
43  else if(strstr(authlist, "keyboard-interactive"))
44  {
45    /* the keyboard-callback function sends the password */
46    libssh2_userauth_keyboard_interactive_ex(
47      session,
48      "myuser", strlen("myuser"),
49      &kbd_callback);
50  }
51  else
52  {
53    /* unsupported authentication method */
54    return;
55  }
56  LIBSSH2_SFTP* sftp = libssh2_sftp_init(session);
57  LIBSSH2_SFTP_HANDLE* handle = libssh2_sftp_open_ex(sftp,
58    "/proc/version", strlen("/proc/version"), 
59    LIBSSH2_FXF_READ, LIBSSH2_SFTP_S_IFREG, LIBSSH2_SFTP_OPENFILE);
60  char content_buffer[4096] = { 0 };
61  libssh2_sftp_read(handle, content_buffer, sizeof(content_buffer) - 1);
62  printf("%s\n", content_buffer);
63  libssh2_sftp_close_handle(handle);
64  libssh2_sftp_shutdown(sftp);
65  libssh2_session_disconnect(session, "");
66  libssh2_session_free(session);
67}

Wehe jemand kopiert das ohne die notwendige Fehlerbehandlung für alle Funktionen!

Wenn der SSH-Server das Passwort direkt akzeptiert wird es per libssh2_userauth_password_ex übermittelt.

Ist Tastatur-Interaktion gewüscht, wird eine Callback-Funktion von libssh2_userauth_keyboard_interactive_ex aufgerufen. Hier kann man entweder Tastenanschläge von STDIN lesen, oder ein vorbereitete Passwort gleich in den Antwort-Puffer schreiben.

Tja und sobald die Session authentifiziert ist, lässt sich eine SFTP Sitzung starten (libssh2_sftp_init), mit der man dann ganz ähnlich zu den POSIX Funktionen open read write close Dateien lesen und schreiben kann:

Fazit

libssh2 benötigt nur den Crypto-Teil von OpenSSL oder alternativ von libReSSL.

Neben SFTP Dateioperationen lassen sich auch Prozesse ausführen und Port-Weiterleitungen einrichten.

Für diese einfache Möglichkeit mit SSH zu arbeiten, muss man diese Bibliothek einfach lieben.

4 Jahre Blog

2022-10-08T13:00:00+02:00

Unglaublich, doch schon sind wieder 4 Jahre vorbei. Und ein bisschen hat sich der alte Witz wieder bewahrheitet:

Wenn du Gott zum Lachen bringen willst,
dann mache einen Plan.

Aktuell läuft alles etwas unstrukturiert. Es ist, als wäre ich in ein fremdes Land in eine fremde Stadt gereist, wo ich an jedem Tag eine neue Gasse, einen neuen Markt und neue Lokale entdecken würde.
Man isst und schläft nie zweimal am selben Platz.

Und so geht es mir mit dem GATE Projekt, wo ich zwischen unterschiedlichen Systemen, Technologien und Zielen hin- und herspringe.

Doch es macht mir einfach Spaß 5 Zeilen für DOS, 5 Zeilen für Linux, 5 Zeilen für die WinAPI und 15 für UEFI und dann noch 4x 50 Zeilen Assembler zu schreiben um dann festzustellen, dass es doch nicht so ganz ideal war. Dabei lernt man viel, aber Berge versetzt man damit nicht leider auch nicht all zu schnell.

Neue Plattformen

Mit Assembler und EFI habe ich ein faszinierendes Feld betreten, in dem ich viel experimentieren kann.

Und spannenderweise sind es dann die Blog-Artikel, die erst richtig Wissen aufwühlen, denn beim Verfassen und Verifizieren von Codebeispielen erkenne ich bessere Lösungen als die, die ich ursprünglich im GATE Projekt vorgesehen hatte.
Diese werden dann implementiert, daraus ergeben sich beobachtbare Seiteneffekte, die wiederum den Blog-Artikel erweitern oder zu Neuauflagen führen.

So habe ich das Gefühl, das wirklich was “entwickelt” wird, und nicht einfach nur hingerotzt wird … aber das kostet eben Zeit.

Datenumstellung

Anfang nächsten Jahres werden vermutlich 600 Einzelartikel geschrieben sein und nun erweist sich mein “alles-in-einem-Verzeichnis” Ansatz als immer mühsamer. Ich werde also eine Aufspaltung mindestens nach Jahren ausprobieren.

Übergroß sind inzwischen auch die RSS und Suche-Dateien geworden. Es macht einfach keinen Sinn mehr, alles in eine einzelne XML oder JSON Datei zu packen. Auch hier muss ich mir was einfallen lassen und die Daten besser aufteilen.
Mal sehen, wann ich dafür Zeit finde.

Neue Features

Meine Inhalte sind zwar alles andere als Social-Media tauglich, aber dank einiger Tutorial-artiger Seiten verteile ich immer wieder mal Links, wenn eine Frage im Bekannten- oder Kollegenkreis auftritt.
Genau für so etwas fehlt ein “Teilen” Button wie man ihn von einschlägigen Seiten kennt, der zumindest mal die URL in die Zwischenablage kopiert.
Und vielleicht lässt sich auch sonst noch ein bisschen mehr Grafik durch Unicode-Icons in die Seite bringen.

Fazit

Alles in allem bin ich einigermaßen zufrieden. Das Blog-Projekt wird weiterlaufen, schon alleine deshalb, dass ich meine Erkenntnisse dokumentieren kann.

In diesem Sinne:

Bis zum nächsten Blog-Bericht in einem Jahr!

Phantastische Icons ...

2022-10-02T13:00:00+02:00

… und wo sie zu finden sind.

Während es heute ein Volkssport ist, dass jede noch so unnötige App ihre eigenen Grafiken designed um möglichst viel Individualität vorzuheucheln, gab es früher mal die Idee, dass Benutzer sich leicht zurecht finden sollen.

Grafische Elemente sollte das Betriebssystem “zeichnen” und das UI dadurch einheitlich gestalten.

Die Frage ist nur … wo findet man das heute noch?

Um Dateien zu erstellen, öffnen, speichern und kopieren zu können, haben sich Symbole etabliert, die jeder “im Augenblick” mit der richtigen Funktion assoziieren und darauf klicken kann.
Dass bis heute eine Disketten Bild als “Speichern” interpretiert wird, ist teilweise kurios, aber dennoch schlüssig.

Dumm ist nur, wenn heute Designer versuchen, solche Symbole selbst zu zeichnen und so werden lustige “Platten-Kreise” sogar zu “Bleistifte” in “Corporate-Colors” hingepixelt, und ich sitze dann vor einem UI und versuche mühsam zu erraten, was das Gebilde jetzt auslösen wird, wenn ich es anklicke.

Stock-Icons und -Bitmaps

Windows hatte von Anfang an (also zumindest ab Win95/NT4) Grafiken für “übliche” Symbole in seinen Innereien integriert und die großen X11-Toolkits unter Linux taten das gleiche.

Wer also Menüfunktionen für “Neu”, “Öffnen”, “Speichern”, “Drucken” integrieren wollte, konnte dafür eben diese “Standardsymbole” laden und seinen UI Elementen hinzufügen, anstatt auf nachgezeichnete Eigenfabrikate zu setzen.

Dadurch wird die “EXE” kleiner und das Programm erhält auch noch stets die neuesten Grafiken mit jedem neuen OS oder Toolkit Release.

WinAPI

Microsoft hat es aber leider auch hier wieder geschafft eine gute Idee möglichst schlecht umzusetzen.

Globale Bitmaps

Einige wenige Icons und Bitmaps kann man aus einem globalen Pool laden und dann als HICON und HBITMAP völlig frei benutzen. Man nutzt einfach den HINSTANCE Parameter mit NULL und dann eine Resource-ID aus den WinAPI Headern. Doch diese helfen einem wenig, weil es nur Pfeile oder Warnung- und Stoppsymbole sind.

1HBITMAP hbmp = LoadBitmap(NULL, OBM_LFARROW);
2HICON hicon = LoadIcon(NULL, IDI_ERROR);

Das Toolbar Control aus den Common-Controls hingegen arbeitet mit einer internen “ImageList” und diese kann man veranlassen, dass sie ein Set von Standard-Image lädt. Danach kann man mit vordefinierten Grafik-Indices übliche Symbole also Toolbar-Buttons anzeigen lassen.

1HIMAGELIST imglist = ImageList_Create(16, 16, ILC_COLOR16 | ILC_MASK, 0, 0);
2SendMessage(hwnd_toolbar, TB_SETIMAGELIST, (WPARAM)0, (LPARAM)imglist);
3SendMessage(hwnd_toolbar, TB_LOADIMAGES, (WPARAM)IDB_STD_SMALL_COLOR, (LPARAM)HINST_COMMCTRL);

Beim Hinzufügen von Toolbar-Buttons kann man dann Index-Konstanten wie IDM_NEW, IDM_OPEN, IDM_SAVE nutzen, um Icons für “Neu”, “Öffnen” und “Speichern” anzuzeigen. Die vollständige Liste ist natürlich in der Dokumentation; und ein Beispiel für die Erstellung von Toolbar Buttons ist auch im Netz.

Shell32.dll als ICON-Resource

Ich nutze im GATE Framework unter anderem auch Icons aus der shell32.dll. Es gibt zwar keinen dokumentierten Standard dazu, doch Microsoft hat seit NT4 in dieser DLL immer nur neue Symbole hinzugefügt, aber bestehende Indices immer mit den gleichen Grafiken versorgt.

ExtractIconEx() heißt die Funktion, die aus einer EXE oder DLL Icons herausziehen kann, und mit den Zahlen für die wichtigsten Symbole, kann man auch so die “aktuellen” Grafiken erhalten.

GTK

GTK definiert in seinen Headern bzw. in der Doku eine Reihe von Strings, die zu Grafiken eines Themes verweisen. Mit der Funktion gtk_icon_theme_lookup_icon() lassen sich dann Icon-namen wie document-save, edit-copy oder folder-open laden und in Controls anzeigen.

Das ist eigentlich eine sehr elegante Lösung … wenn sie nicht instabil wäre. Denn wenn das Theme eine entsprechende Grafikdatei nicht beinhaltet, kann es zum Crash kommen. Offenbar fehlt hier die Fehlerbehandlung.

Mir ist das unter Linux am Raspberry PI leider untergekommen, wo nach der GTK-3 Installation das Thema nicht korrekt installiert war.

Silk Icons

Und weil man sich eben weder unter Windows noch unter Linux wirklich darauf verlassen kann, dass alle notwendigen Icons wirklich da sind, habe ich mich dazu entschieden, einige PNGs der Silk Icons in Pixmaps umzuwandeln und als C-Header dem GATE Projekt beigelegt.

Denn diese Icons können dann auf jeder Plattform in das eigene Binary integriert und zur Laufzeit geladen werden.

Diese unter der Creative Commons stehende Bildersammlung benötigt nur eine Erwähnung des Authors und ist ansonsten kostenfrei für alle Zwecke nutzbar.
Empfohlen wurde sie mir vor vielen Jahren mal von einem Open-Source-Officer, der sie als “sicher” qualifiziert hatte, gegenüber anderen Bildchen aus dem Netz.

Und wer schon mehrere Softwarepakete ausprobiert hat, wird feststellen, dass die Silk Icons in zahlreichen freien Desktop-Projekten integriert sind.

Fazit

Eigentlich wünsche ich mir, dass Icons großteils vom Betriebssystem und dessen aktuellem Theme kommen. Und deshalb bedauere ich sehr, dass der kleinste gemeinsame Nenner an “bedeutungsgleichen” Icons zwischen Windows und Linux leider ein sehr kleiner ist, und dass man auf Non-standards angewiesen ist, diese Icons dann zu laden.

Zwar habe ich im GATE Framework einen solche Stock-Icon-Teilmenge definiert, doch wegen der Crashes unter Linux, habe ich am Ende dann doch wieder die Silk-Icons eingesetzt.

Aber auch ein noch so kleines Set an “eindeutigen” Icons ist immer noch besser, als der klägliche Versuch mancher Herstelle, ihre eigenen Icons zu designen.

Corona @ home

2022-10-01T13:00:00+02:00

Jetzt hat es mich auch erwischt, nach 2.5 Jahren und 4 Impfungen.

Nun muss ich den “Husten” auskurieren und durchlebe meine erste “echte” Quarantäne.

Am Donnerstag fühlte ich es schon beim Ausstieg aus dem Bus. Mir war leicht schwindelig und leichte Kopfschmerzen setzten ein. Als das nach einer Stunde nicht besser wurde, vermutete ich eine “übliche” Verkühlung und machte mich auf den Heimweg.

Der führte mich an der Testbox bei der Apotheke vorbei, wo sogleich ein Nasenabstrich gemacht wurde.

Vorsorglich kaufte ich noch einige Fertigwaren ein und war glücklich mich zu Hause ins Bett legen zu können, denn die Kopfschmerzen und der Schwindel wurden stärker.

Am Abend hatte ich dann meine 38° Fieber und ein “übliches” Unwohlsein, also das, was man sich von einem grippalem Infekt erwartet. Da das Abendessen aber noch sehr gut schmeckte, schloss ich COVID-19 für mich bereits aus.

Am frühen Morgen am Freitag piepte schon der SMS-Signalton und informierte mich über meine positiven Corona-Testung und dass ich nun unter Quarantäne stehe.

Ich informierte daher Arbeitgeber und Kollegen über die Infektion und meldete mich telefonisch beim Arzt krank.

Die Quarantäne gilt nun für 5 Tage, wonach ich mich wieder “freitesten” kann, wenn ich symptomfrei bin.

An Freitag Abend hatte ich dann auch einen Großteil meines Geschmackssinnes verloren, doch da das Fieber schon auf 37.3 gesunken war, ging es mir wieder besser.
Leider fing dann in der Nacht auf Samstag die Husterei an, was das Durchschlafen nicht gerade erleichterte.

Und im Laufe des Samstags verbesserte sich dann die Lage etwas.

Fazit

Ich vermute, dass meine Genesung noch ein paar Tage dauern wird, aber das schlimmste war wohl der Fieberausschlag von Donnerstag auf Freitag.

Wenn man von einer etwas laufenden Nase mal absieht, hatte ich sonst keine Probleme beim Atmen, nur der gelegentliche Husten kratze im Hals.

Ich hoffe also, dass ich in den nächsten Tagen die Symptome hinter mir lassen kann und bin schon gespannt, wie lange das Freitesten dauern wird.

Dass ich trotz fast täglicher Busfahrt erst nun von Corona “beglückt” wurde, war ohnehin unerwartet, denn ich dachte mir schon häufig:

Jetzt hab’ ich es vermutlich auch.

Doch bisher war jeder Test negativ geblieben.

Ich hoffe nur, dass ich mit meinem kurzen Firmen-Besuch keine Kollegen angesteckt habe.

Dass ich aber durchgehend in Geschäften und Verkehrsmitteln stets eine Maske trage hat vielleicht auch zu meiner langen Verschonung beigetragen. Und dass der Ausbruch nach 2 Tagen schon wieder vorbei zu sein scheint, führe ich auf meine Impfungen zurück.

Denn nicht jede Corona-Geschichte, die mir erzählt wurde, war so “annehmbar”.

Mal sehen, wie fit ich nächste Woche sein werde.

Assembler und .SAFESEH

2022-09-25T13:00:00+02:00

Wenn in einem 32-bit Windows MSVC Build der Fehler

fatal error LNK1281: Unable to generate SAFESEH image

auftaucht, liegt es vermutlich an einem fehlenden Exception-Handler in einem Assembler Modul.

In der C und C++ Welt übernimmt der Compiler den Job, für alle Module Exception Handler zu generieren, wenn es notwendig ist. Und der Linker fügt dann alle diese “kompatiblen” Handler in die finale Binärdatei zusammen.

Doch Assembler Module dürfen sich “anders” Verhalten, und wenn man dort nur seinen Code schreibt, fehlt ein solcher Handler, womit sich dieses Modul von den anderen C/C++ Modulen unterscheidet.

Und das führt zum oben genannten Fehler.

Jetzt kann man entweder die Notwendigkeit von “Safe Exception Handlers” deaktivieren
(Project Properties - Linker - Advanced - Image Has Safe Exception Handlers) oder auch mit der Compiler Option /SAFESEH:NO.

Oder man fügt dem .asm Modul eine leere SEH-Funktion hinzu und registriert sie mit der .safeseh Direktive.

 1;my_asmcode.asm
 2.386
 3.MODEL FLAT, C
 4
 5.CODE
 6
 7.SAFESEH my_seh_handler
 8my_seh_handler PROC
 9  ret
10my_seh_handler ENDP
11
12
13my_real_operative_asm_proc PROC
14...

Natürlich muss man jetzt die .asm Datei auch mit der /safeseh Option kompilieren lassen.
(ASM File Properties - Microsoft Macro Assembler - Advanced - Use Safe Exception Handler)

Wenn man mit CMAKE arbeitet, hilft einem der Eintrag:

1set_source_files_properties(
2  my_asmcode.asm
3  PROPERTIES
4  COMPILE_FLAGS "/safeseh"
5)

Fazit

Wenn man ein Projekt mit vielen Optionen auf vielen Plattformen kompilieren will, vergisst man leider immer wieder, ein paar dieser Optionen und Options-Kombinationen zu testen.

Langsam wird es Zeit, dass ich mir jetzt richtige Build-Server für alle meine Plattformen aufsetze, denn wegen der vielen Möglichkeiten vergesse ich zunehmend immer alles auszutesten und “auf Stand” zu halten.
Und dann wundert man sich plötzlich, wenn etwas nicht mehr baut und merkt erst dann mit Schrecken, dass es schon ein halbes Jahr nicht mehr funktioniert.

Und genau das sollte eine Buildserverumgebung automatisiert erfassen und melden können.

Alexa, füge einen Buildserver zu meiner Einkaufsliste hinzu.

Exception Drama

2022-09-24T13:00:00+02:00

Einst liebte ich sie … doch da wusste ich noch nicht, woraus sie bestehen.

So könnte man meine aktuelle Beziehung zu C++ Exception beschreiben. Denn dieses wirklich gute “Sprachmittel” ist so etwas von unterschiedlich implementiert, dass man sie nur durch das Neuschreiben eines vollständigen Compilers in ihren Abläufen nachvollziehen kann.

Hintergrund EFI

Ich bin wieder mal im EFI Land unterwegs bzw. würde ich gerne mit einem C++ Compiler dort hinreisen, doch das erweist sich mit jedem weiteren Versuch als unmachbarer.

Ich werde zwar noch nicht aufgeben, aber mit so krassen Widersprüchen zwischen den Implementierungen beim gleichen Hersteller hätte ich nie gerechnet.

Hier mal ein Lagebericht von der Front:

STD-Lib und Runtime

Man sollte glauben, es gäbe einen “Standard” der Standard-Exception Objekte festlegt. Und den gibt es auch, nur der befasst sich lediglich mit öffentlichen Schnittstellen.

std::exception wird aber von einigen anderen Klassen geerbt und diese bedienen sich dann an unterschiedlichen Methoden aus der Basisklasse, die nicht spezifiziert sind.

Microsofts MSVC ändert diese Schnittstellen mit jedem Release leicht ab und fabriziert so neue Formen std::exception.

Wenn ich nun für EFI einen Build ohne die C++-Runtime erstelle, erhalte ich zahlreiche “undefinierte” Symbole in Zusammenhang mit std::exception. Implementiere ich diese nach, gelten diese nur für eine MSVC Version, z.B. MSVC-2015. MSVC-2017/19/22 heißen dann die Member anders oder Methoden werden durch andere ersetzt.

Eine von mir angestrebte “generische” Implementierung existiert nicht.

Spezielle CPU Register und Adressen

Viele Exception-Jobs laufen über “interne” Funktionen, die ebenfalls als “undefinierte” Symbole sichtbar werden, wenn man “Freestanding” zu kompilieren versucht. Und das wäre gut, denn hier kann man manuell eingreifen.

Doch leider passiert das nicht überall, und so finde ich im X64-Assembler-Dump einige Segmentregister-Zugriffe auf FS zum Thread-Local-Storage (TLS). Manchmal werden dafür zwar Funktionen aufgerufen, die man abfangen könnte, aber FS:addr Aufrufe, die der Compiler einfügt, gegen die bin ich leider machtlos.

Ich kann nur hoffen, dass es sich dabei um Dead-Codes oder um falsche Instruktionsinterpretationen handelt.

Unwinding-Tabellen

Das Finden von Aufräumcode funktioniert heute vermehrt über Metadaten, als über IP-(Instruction-Pointer) Tabellen. Wie effizient das letztendlich ist, steht noch zur Diskussion, Ein throw stellt fest, von welcher Codeadresse der Aufruf kam, und sucht dann in einer Tabelle zwischen Anfang- und Endpunkten, was mit dem Ursprung assoziiert ist.
Und von dort erhält man wieder weitere Codezeiger, die man anspringen kann um den Stack-Cleanup einleiten zu können.

Im GCC wird hierfür die Funktion dl_iterate_phdr() aufgerufen, die durch die geladenen ELF-Handler durchgehen soll und Info-Objekte dazu an einen Callback übergeben soll (z.B.: _Unwind_IteratePhdrCallback()).

Leider ist der “Dynamic-Linker” im Freestanding-Betrieb ebenfalls nicht vorhanden, somit muss ich die dl_iterate_phdr() offenbar nachbauen. Ein Problem könnte dann sein, dass mein EFI-Binary ein von ELF/Dwarf nach COFF/PE konvertiertes Trägerformat ist.

Ich hoffe also, dass durch diese Konvertierung (siehe objcopy) die Codeadressen nicht negativ beeinflusst.

Fazit

Es ist ein Alptraum.

Weder mit dem MSVC, noch mit dem GCC unter Linux oder mit dem MinGW ist die Nutzung von Exceptions außerhalb der Betriebssystemumgebung machbar.

Ich hätte mir ein vernünftiges API erwartet, das Exceptions und Typinformationen allokieren kann und eine Registrierungsfunktion für Cleanup-Routinen, sowie standardisierte Einsprungpunkte für Catch-Handler. Wäre dann die Exception-Behandlung und das Stack-Unwinding ein statischer vom Compiler generierter Code, dann könnte all das mit den generischen Metadaten betriebssystemunabhängig arbeiten.

Doch so bleibt die Windows-Implementierung an Win32-SEH angeknüpft und der GCC verbeißt sich in ELF und DL-Strukturen.

Und das ist leider alles andere als “generisch”.

Mal sehen wie das weitergehen wird.

Thread local storage

2022-09-18T13:00:00+02:00

Einer der Gründe, warum ich auf meinem Weg zu C++ außerhalb von Betriebssystemen stolpere, liegt am “thread local storage”.

Denn wo werden Exception-Daten abgelegt?
Offenbar genau dort!

Und was mir fehlt ist ein funktionierender Nachbau von __tls_get_addr.

Egal wie “free-standing” man sein Projekt kompiliert, ein Linux-GCC mischt zwangsläufig Linux-Standards in den Code. Und das betrifft vor allem C++ Exceptions und das dazugehörige Runtime-Type-Information (RTTI) System.

Wenn nämlich in einem Thread eine Exception fliegt, muss der Callstack rückabgewickelt werden, bis zum letzten installierten Exception Handler und auf dem Weg dorthin müssen alle herumliegenden Objekte freigegeben werden.

Das erfordert den Zugriff auf zwei OS-nahe Ressourcen:

Die ELF-Sections mit Cleanup-Codes, die an das Speicherlayout angepasst sind
Der Thread-local-storage, in dem die gültigen Exception Handler verlinkt sind.

Beide Ressourcen erfordern eine tiefe Kenntnis und “Konformität” zu den Strukturen, wie Linux und die jeweilige C-Lib damit umgehen.
Und das ist unter Windows leider auch nicht anders.

Noch krasser wird die Geschichte, weil die neueren C-Standards ab C11 mit der _Thread_local Speicherklasse einem jeden Datentypen ermöglichen, zum Thread gehören zu können und im Hintergrund nötige Anpassungen machen.

Offiziell erreicht man den Thread-local-storage über entsprechende APIs, wie pthread_key_create() und pthread_get/setspecific() oder TlsAlloc und TlsSetValue unter Windows.

Doch wie sich zeigt umgehen die internen Funktionen des GCC die POSIX API und wollen mit APIs wie __tls_get_addr() arbeiten und nutzen dann ihr Geheimwissen und adressieren die Unterfelder dann direkt.

Ich habe nun länger nach Infos zu all diesen Details gesucht und interessante Dinge über den TCB (thread control block) und den DTV (dynamic thread vector) gelesen
… aber geholfen hat mir das leider nicht.

Fazit: Keinen Thread-local-storage nutzen!

Was ich mit C++ Exception machen soll, weiß ich noch nicht, aber ich habe zumindest gelernt, dass der leichtsinnige Einsatz von _Thread_local kontraproduktiv sein kann.

Für mein UEFI Thema führt offenbar wirklich kein Weg daran vorbei, den GCC und seine Kernbibliotheken neu zu bauen, denn dort hat man ein paar Möglichkeiten, die Arbeitsweise zu beeinflussen.
Es gibt schließlich auch Mikrocontroller-Zielplattformen, die all den Schnickschnack auch nicht unterstützen.

EFI und MinGW inline API

2022-09-17T13:00:00+02:00

Es hätte so einfach sein können: Man implementiert einfach alle Funktionen der C-Standard Bibliothek selbst in einer statischen Bibliothek und linkt gegen diese. Schon hätte man C Programme direkt als EFI App laufen lassen können.

Aber nicht so mit MinGW … denn der hat keine “echte” C API.

Die klassischen Header wie stdlib.h und stdio.h deklarieren bei allen Compilern die gleichen Funktionen wie

1void* malloc(size_t size);
2int printf(const char * format, ...);
3int getchar(void);
4int putchar(int character);
5...

Die Implementierungen dieser Funktionen innerhalb der C-Laufzeitbibliothek, die automatisch in alle C Programme injiziert wird, verweisen auf das jeweilige Betriebssystem, also wie z.B.: ReadFile() und WriteFile() in der WinAPI oder die read() und write() Systemcalls in Linux.

Hat man kein OS (wie z.B. für EFI Apps), lässt man seinen Code mit /NODEFAULTLIB unter MSVC oder -ffreestanding -nostdlib beim GCC kompilieren und/oder linken, womit dann alle C-Standard-Funktionen als “undefinierte Symbole” erkannt werden.

Dann implementiert man diese Funktionen selbst und leitet sie auf direkte Hardware- oder Firmware Features um.
Und das funktioniert auch einigermaßen, wenn man ein paar Ungleichheiten bei den C Headern ausbessert, wie der sporadische Einsatz von restrict oder const bei Parametern. (Das lässt sich mit Makros leicht umsetzen).

MinGW nutzt inline C-Funktionen

Mein Konzept brach aber total zusammen, als ich den MinGW bemühte meine Quellcodes zu übersetzen.
Denn der lieferte hunderte Zeilen, die wie folgt aussahen:

1/.../gnu-efi-stdc/src/stdio_impl.c:194:5: error: redefinition of ‘sprintf’
2  194 | int sprintf(char* str, const char* format, ...)
3      |     ^~~~~~~
4/usr/share/mingw-w64/include/stdio.h:382:5: note: previous definition of ‘sprintf’ was here
5  382 | int sprintf (char *__stream, const char *__format, ...)
6      |     ^~~~~~~

Meine Funktion hatte die gleiche Signatur wie die in stdio.h doch soll nun eine Redefinition sein. Und der Grund dafür befindet sich in Zeile 382 von stdio.h, denn dort steht:

 1int sprintf(char* __stream, const char* __format, ...)
 2{
 3  int __retval;
 4  __builtin_va_list __local_argv;
 5  __builtin_va_start(__local_argv, __format);
 6  __retval = __mingw_vsprintf(__stream, __format, __local_argv);
 7  __builtin_va_end(__local_argv);
 8  return __retval;
 9}

MinGW definiert also sprintf gar nicht als eine extern C Funktion, sondern nur als inline-Funktion im Header, die auf eine interne Funktion namens __mingw_vsprintf umleitet.

Und das gleiche passiert auch bei allen anderen I/O Funktionen.

Fazit

Tja … leider ist das erlaubt, denn ein “API” definiert nur, wie eine Funktion heißt und welche Parameter sie hat und nicht wie sie implementiert sein muss.

Mich stellt das jetzt vor die Herausforderung, ob ich nun für den MinGW Spezialfälle wie __mingw_vsprintf implementieren soll, oder versuchen soll, stdio.h und seine Freunde auf von mir erstellten Header umzuleiten.

Interessant finde ich nur, dass MSVC und der Standard-GCC (mit glibc) hier sehr “kompatibel” sind, während das GCC-Derivat MinGW ganz anders aufgebaut ist.

Leider zeigt sich hier, dass die MingGW-Hersteller nicht wirklich modular gedacht haben. Denn leicht hätten sie diese inline Umleitungen auch in (austauschbare) “extern C” Funktionen packen können um daraus ein echtes “ABI” zu machen und um z.B: __mingw_vsprintf dann inline einzubinden.

Das hätte performance-technisch dann keinen Unterschied gemacht und wäre mir jetzt sehr entgegengekommen.

Aber wie langweilig wäre die Welt ohne weitere Herausforderungen …

Online Übersetzungen

2022-09-11T13:00:00+02:00

Vor 3 Jahren fand ich den Übersetzungsdienst für Webseiten bei Microsoft und verlinkte ihn auf der Blog-Seite, damit bei Bedarf für jeden auch eine englische Variante des Blogs verfügbar ist.

Leider hat Microsoft diesen Dienst offenbar in diesem Jahr eingestellt. Nun bleibt mir leider nur der Wechsel zu Google übrig.

microsofttranslator.com für Webseiten deaktiviert

Es war so einfach …

1<a href="https://www.microsofttranslator.com/bv.aspx?from=de&to=en&a=https%3A%2F%2Fwww.opengate.at%2Fblog">...</a>

Durch dem Aufruf von www.microsofttranslator.com/bv.aspx mit den Parameter:

from=de
to=en
a=http.... (also die URL im urlencode-Format kodiert)

lud der Dienst die Webseite, übersetzte sie online von Deutsch auf Englisch und gab eine Design-treue englische Variante zurück.

Für statische HTML Seiten ist das eine sehr bequeme Möglichkeit, die eigenen Worte in beliebig viele Sprachen zu übersetzen.

Der originale Jekyll Code sah so aus:

1<a href="http://www.microsofttranslator.com/bv.aspx?from=de&to=en&a={{ page.url | prepend : "https://www.opengate.at/blog" | url_encode }}">...</a>

Wechsel zu Google

Nach einigem Herumsuchen stellte ich fest, dass andere Dienste entweder limitiert sind (z.B.: nur X Zeichen pro Tag) oder mit Registrierungs- oder Bezahlzwang arbeiten.
Und das ist es mir nicht wert.

Google ist für mich zwar grundsätzlich ein No-Go, doch da der Suchdienst meine Seiten sowieso indiziert hat, dann kann er auch gleich etwas sinnvolles damit machen und die Seite übersetzen.

Datenschutztechnisch ist das natürlich furchtbar, da wieder eine weitere Form des Trackings möglich wird, aber … was soll man tun … außer verkrampft zuzustimmen.

Aufruf der Webseite

Google arbeitet etwas anders als die vorig Lösung: Die eigentliche Domain wird in eine Subdomain von translate.goog umgewandelt und der relative Pfad dem neuen Domainpfad angefügt. Am Ende wird über die URL-Parameter _x_tr_sl (Source Language) und _x_tr_tl (Translation/Target Language) die Originalsprache und die Zielsprache angegeben, wobei man _x_tr_sl auch auf auto setzen kann, damit Google die Sprache selbst herausfindet.

Das hat dann die Form:
https://my-domain-tld.translate.goog/sub/path/?_x_tr_sl=auto&_x_tr_tl=en
oder wie im Falle meines Blogs:
https://www-opengate-at.translate.goog/blog/?_x_tr_sl=auto&_x_tr_tl=en

Fazit

Es funktioniert … und das reicht mir vorerst.
Aber ich wäre glücklicher, wenn ich einen anderen Dienst für diese Aufgabe finden würde.

Fairerweise muss man sagen, dass auch das heute gar nicht mehr notwendig ist, denn alle Mainstream Browser bieten die Übersetzung von Webseiten bereits an. Ich finde es aber praktisch, wenn man bereits einen Link zur fertig übersetzten Seite generieren kann.

Vielleicht erschließt sich da ja auch mal ein Möglichkeit, dass man die Übersetzung per JavaScript oder CSS im Browser aktivieren kann.
… aber vorerst bleibe ich mal beim Google-Link.

CONAN Abhängigkeiten und Versionen

2022-09-10T13:00:00+02:00

Grundsätzlich gilt für CONAN Projekte:

Ändert man die Version, eine Einstellung oder eine Option in einer Komponente, errechnet CONAN einen neuen Hash für ein Paket und auch alle Abhängigkeiten davon bekommen neue Hashes zugeteilt.

… dachte ich.
Doch nun kenne ich eine interessante Ausnahme.

CONAN identifiziert seine Paket durch Namen und Version, wie auch durch “Settings” (Compiler, OS, Build-Toolset) und “Options” (Shared, Static, …).

So können dann aus einem Quellcode beliebig viele Pakete parallel gebaut werden, die sich durch mindestens ein Detail unterscheiden und das wird am eindeutigsten durch die Paket-Hashes signalisiert.

graph TD REPO(myLib
Repository) SRC1(myLib/1.1
Source) SRC2(myLib/1.2
Source) BIN11(myLib/1.1
Windows 32
Hash: 123) BIN12(myLib/1.1
Windows 64
Hash: 456) BIN13(myLib/1.1
Linux GCC 10
Hash: 789) BIN14(myLib/1.1
Linux GCC 11
Hash: abc) BIN21(myLib/1.2
Windows 32
Hash: def) BIN22(myLib/1.2
Windows 64
Hash: aaa) BIN23(myLib/1.2
Linux GCC 10
Hash: bbb) BIN24(myLib/1.2
Linux GCC 11
Hash: ccc) REPO --> SRC1 REPO --> SRC2 SRC1 --> BIN11 SRC1 --> BIN12 SRC1 --> BIN13 SRC1 --> BIN14 SRC2 --> BIN21 SRC2 --> BIN22 SRC2 --> BIN23 SRC2 --> BIN24

Bei Abhängigkeiten zwischen Paketen bewirkt eine Änderung der Version ebenfalls sofort eine Änderung des Paket-Hashes.

graph LR subgraph Different Versions B1(baseLib/1.1) B2(baseLib/1.2) end subgraph Same Versions L1(myLib/1.1
Hash: abc) L2(myLib/1.1
Hash: 123) P1(myProg/1.0
Hash: def) P2(myProg/1.0
Hash: 456) end B1 --required by--> L1 L1 --required by--> P1 B2 --required by--> L2 L2 --required by--> P2

Ausnahme: Nach der 3. Versionstelle wird der Rest ignoriert

CONAN erkennt gemäß “Semantic Versioning” nur 3 Stellen in einer Version an. Man kann aber noch mehr hinten anhängen, doch eben genau das wird in die Hashberechnung und damit in die Paket-Identifizierung nicht einberechnet.

Hat man also eine Bibliothek mit der Version 1.2.3.4 und wechselt zur Version 1.2.3.5, so wird das zwar von CONAN korrekt erkannt und aufgelöst, doch die davon abhängigen Projekte erfahren keine Hashänderung.

graph LR subgraph Different Versions B1(baseLib/1.4.2.1) B2(baseLib/1.4.2.2) end subgraph Same Versions L(myLib/1.1
Hash: abc) P(myProg/1.0
Hash: def) end B1 --required by--> L B2 --required by--> L L --required by--> P

Für produktive Software ist das Beispiel grundsätzlich ungeeignet, weil man in der Regel bei der Änderung der Version einer Abhängigkeit auch die eigene Version anpasst. Also aus
base/1.1 -> lib/2.3 wird dann ein base/1.2 -> lib/2.4.

Doch wenn man Softwarestände testet und zwischen unterschiedlichen Patch-Levels hin und her probiert, kommt es schon vor, dass man die “neue” Version der eigenen Komponenten mit unterschiedlichen Varianten von anderen Komponenten testet.

Kein Support für mehr als 3 Stellen in Versionen

Dass CONAN sich bei mehr als 3 Stellen anders verhält, zeigt sich auch bei Range-Angaben.
Ein conan install project/[1.2.*]@user/channel sollte die neueste Variante der 1.2 Serie herunterladen, also die mit der höchsten Versionsnummer. Existiert aber eine 4. Stelle für solche Versionen im Repository, lädt CONAN “irgendeine” herunter. Für mich sieht es so aus, als wäre es die “erste” in der Auflistung.

graph LR INSTA(CONAN INSTALL
libA/1.2.*) INSTB(CONAN INSTALL
libB/2.3.*) subgraph libA A1[[libA/1.2.1]] A2[[libA/1.2.2]] A3[[libA/1.2.3]] end subgraph libB B1[[libA/2.3.9.1]] B2[[libA/2.3.9.2]] B3[[libA/2.3.9.3]] end RESULTA(libA/1.2.3) RESULTB(libB/????) INSTA -.Match-.-> A1 INSTA -.Match-.-> A2 INSTA --Select
latest--> A3 A3 --Install
latest--> RESULTA INSTB -.Match-.-> B1 INSTB -.Match-.-> B2 INSTB -.Match-.-> B3 B1 -.Random
installation-.-> RESULTB B2 -.Random
installation-.-> RESULTB B3 -.Random
installation-.-> RESULTB

Fazit

Ich bin mir noch nicht so ganz sicher, was ich jetzt davon halten soll, denn bisher ging ich fix davon aus, dass jede Versionsänderung eine Hash-Änderung nach sich zieht.

Bei einem conan upload mit neuem Hash bleiben dann die alten Hashes im Upload-Repository liegen, sind aber über ein frisches conan install nicht mehr herunterladbar. Man kann sie jedoch immer noch direkt über den Hash z.B.: per HTTP URL beziehen.

Ändert sich der Hash jedoch nicht, dann kann eine “neue” Version einer Abhängigkeit lautlos ein bestehendes Paket überschreiben, da der gleiche Hash für zwei unterschiedliche Szenarien generiert wurde.

Wichtig ist jedenfalls, dass man dieses Detail von CONAN kennen sollte, denn gerade im Windows-Bereich sind 4-stellige Versionsnummern keine Seltenheit und führen dann womöglich mit CONAN zu unerwarteten Seiteneffekten.

Corona Impfung - Teil 4

2022-09-05T13:00:00+02:00

Nachdem mit Anfang September die allgemeine Empfehlung ausgesprochen wurde, sich eine 4. Covid-19 Booster-Impfung zu holen, habe ich unmittelbar einen Termin im Impfzentrum gebucht und mir meine 4. Dosis gestern geholt.

Nun - so hoffe ich - komme ich weiter gut durch den Winter.

Folgen und Auswirkungen

Während die Dümmsten der Dummen unserer Gesellschaft weiter behaupten, es gäbe kein Virus und alles sei nur eine Erfindung der Medien, kann ich in meinem Umkreis folgende Bilanz ziehen:

Wenn mir sogar Teenager erzählen, sie musste Wochen nach einer Infektion zum Arzt, weil sie beim Sport plötzlich keine Luft mehr bekamen und dort eine verminderte Atemkapazität festgestellt wurde, dann sagt mir das, dass COVID-19 nicht nur ein Senioren-Schreck ist.

Dennoch trifft es die Ältesten der Gemeinde am härtesten und so können wir unsere Nachbarin nun nur noch am Friedhof besuchen. Sie hatte weder Corona, noch ist sie daran gestorben. Doch konnte sie wegen der totalen Überlastung in den Krankenhäusern nicht behandelt werden, und verstarb beim tagelangem Warten auf eine Behandlung, weil ungeimpfte Corona-Patienten notwendige Krankenhausplätze und Personal blockiert hatten.

Es ist also unsere Verpflichtung - auch ohne persönlichem Interesse - alles zu tun, um Erkrankungen zu verhindern und die Ausbreitung aller Infektionen einzudämmen, damit sich Ärzte wieder z.B. um Herzinfarkte und Blutvergiftungen kümmern können, anstatt dass sie sturen Verschwörungsanhängern am Ende das Leben retten müssen, wenn deren Selbstbehandlung mit Pferde-Entwurmungsmitteln am Ende (wer hätte es gedacht?) doch nicht wirken.

4. Impfung

Ich hatte mir also wieder einen Termin im Austria-Center gelöst und es war, wie schon beim letzten Mal, “ein Spaziergang”.
Wartezeiten und Schlangen gab es keine, und ich musste nur einmal quer durch das Areal laufen, um

einmal meinen vorausgefüllten Datenzettel abzugeben,
dafür meinen Impfnummern-Sticker zu bekommen,
danach vom Arzt die üblichen Infos erzählt zu bekommen,
am Ende zur Impfkabine zu gehen.

Hätte ich keinen Termin online vereinbart, wären 3 Personen vor mir gewesen, die auch schnell abgefertig wurden, doch mit Termin sparte ich diese 5 - 10 Minuten ein.

Danach wurde noch 15 Minuten Platz genommen um zu warten und dann war die Sache auch schon wieder vorbei.

Keine Reaktionen außer Kopfschmerzen

Nachdem meine erste Impfung mir einen Tag im Bett beschert hatte, bereitete ich mich auf ein solches Szenario wieder vor.
Doch krank fühlte ich mich den Rest des Sonntags gar nicht.

Erst ab 23:00 Uhr als ich langsam schlafen gehen wollte, setzten Kopfschmerzen ein. Diese waren unangenehm und ließen mich die Nacht auf Montag wenig schlafen, womit ich tagsüber müde war.
Die Kopfschmerzen waren am Morgen auch schon wieder weg und ich holte die fehlenden Schlaf am Nachmittag “im Home-Office” nach und machte dann meine Tagesarbeiten am Abend fertig.

In Summe hat sich also mein Tagesablauf um 4 Stunden verschoben, aber das passiert auch, wenn ich mal aus anderen Gründen bis tief in die Nacht vor dem Rechner sitze … also insofern nichts Neues.

Fazit

Meine Abwehrzellen sind nun hoffentlich wieder etwas auftrainiert, damit sie das Corona-Virus besser bekämpfen können.
Seit Beginn der Pandemie bin ich (so weit mir bekannt ist) nicht erkrankt und bin auch atemtechnisch “voll einsatzbereit”.

Und nun möchte ich, dass das so bleibt und plane lieber kontrolliert einen Ausfall-Tag nach der Booster-Impfung ein, als dass ich dann (wie manch andere) wochenlang hustend im Bett verbringen muss, und dann noch weitere Monate eingeschränkt bin.

Masken trage ich weiter in den Öffis und in Geschäften, wenn gleich ich auch so ziemlich der einzige bin. Doch wenn man weiß, dass wegen der Überlastungen im Gesundheitssystem schon viele Menschen sinnlos gestorben sind, nur weil es an Behandlungsplätzen wegen Corona-Patienten fehlt, dann ist es notwendig, mit gutem Beispiel voran zu gehen und nicht so zu tun, also ob es das Virus nicht mehr gäbe.

Vor zwei Jahren war ich selbst skeptisch gegenüber vielen Maßnahmen.
Heute sehe ich sie als genau so notwendig an, wie den Gurt im Auto anzulegen. Bisher kam ich noch nie in die Situation, wo mir der Gurt das Leben gerettet hätte … trotzdem nutze ich ihn.
Und bei der Corona Impfung ist es genau so.
Mag sein, dass es mit ihr nicht viel besser ist.
Aber ohne sie kann es vielfach schlimmer sein.

GITLAB, CONAN und LF vs CRLF

2022-09-04T13:00:00+02:00

Seit langem quält mich eine Unschönheit in der CONAN Welt an meinem Arbeitsplatz:

MSVC und GCC Pakete des gleichen Projektes erzeugen unterschiedliche Recipe-Hashes, weshalb immer eine Variante als “outdated” markiert wird.

Lösung: Zeilenenden vereinheitlichen!

Hat man ein CONAN basiertes C++ Projekt auf einem Gitlab Server liegen, dann laufen mindestens zwei Build-Jobs:

einer für Windows
und einer für Linux

Doch beim Upload ins JFrog Artifactory kommt es dann zu einer Überlappung, da beide Builds ihr grundsätzlich gleiches “Rezept” (Recipe) exportieren.
Folglich müssten beide Builds zwar unterschiedliche Paket-Hashes bekommen, aber den gleichen Recipe-Hash herausbekommen.

Doch genau das trat in unserem Firmenprojekt nicht ein, Windows lieferte einen anderen Recipe-Hash als Linux und so geschah es, dass der Build-Job, der später fertig wurde, beim Upload den Recipe-Hash des früheren Jobs überschrieb.
Und das wiederum führt dazu, dass beim Aufruf von
conan search my_project/1.0.0@user/channel -r my_remote das frühere Build-Job-Ergebnis als “outdated” markiert wird.

Das ist zwar nicht schlimm und andere CONAN Kommandos können die “outdated” Pakete trotzdem laden, doch trotzdem störte mich diese Inkonsistenz.

GIT und Line-Endings

Als ursprüngliches Linux Produkt kennt GIT eigentlich nur LF als Zeilenende. GIT for Windows nutzt daher die default-Konfiguration:
core.autocrlf=true

Mit dieser Option wird beim clone/ fetch / pull jedes LF in Sourcen durch ein CRLF ersetzt. Umgekehrt wird beim commit/ push wieder jedes CRLF zu LF, damit am GIT Server alles einheitlich im Linux-Standard gespeichert wird.

Compiler können mit Sourcen beider Konventionen umgehen, doch CONAN bildet seine Hashes über die Sourcen genau so, wie sie lokal ausgecheckt sind.
Und damit sieht der Recipe-Hash auf Windows und Linux unterschiedlich aus.

Die Lösung ist also das Kommando
git config --global core.autocrlf false auf der Windows Maschine, auf der der Build läuft, und alles ist gut. GIT lädt dann die Sourcen genau so herunter und wieder hoch, wie sie sind, und macht keine eigenmächtigen Anpassungen.

Gitlab Runners und GIT

Doch wie zum Teufel kann man jetzt GitLab dazu bringen, auf den Windows-Runnern ebenso diese Option zu setzen?

Nach langem Suchen blieb ich auf der GitLab Seite zur Runner-Konfiguration in config.toml hängen, denn dort wird von der Konfigurationszeile
pre_clone_script gesprochen.
Dieses “Script” wird ausgeführt, bevor der Gitlab-Runner die Sourcen herunterlädt und genau hier kann man per git Kommando Einstellungen verändern.

1[[runners]]
2  name = "MY-WINDOWS-BUILD-SERVER"
3  ...
4  executor = "docker-windows"
5  shell = "powershell"
6  pre_clone_script = "git config --global core.autocrlf false"
7  ...

Diese Zeile wird tatsächlich als erstes im Docker Container ausgeführt und sorgt dafür, dass GIT unter Windows alles genau so auscheckt, wie es auch unter Linux passiert.

Und am Ende sind dann die Recipe-Hashes identisch und beide Builds werden als
Outdated from recipe: False angezeigt

Fazit

Mission erfüllt!
Aber ich muss schon sagen, dass es sehr mühsam war, die Hintergründe herauszufinden.

Ich dachte eigentlich, es gibt eine GitLab CI Variable, mit der man das steuern könnte, doch bisher habe ich keine solche gefunden.

Das Anpassen der GitLab-CI-Runner ist eine schöne Sache, wenn man die Server selbst verwaltet (was hier zum Glück der Fall war).
Doch wenn man zentrale Serverfarmen nutzt, ist es fraglich, ob einem der Admin einen separaten Runner-TAG mit eben diese Konfiguration anlegen wird.

Eben deshalb wäre es notwendig, dieses Verhalten über die eigene CI-Konfiguration steuern zu können, und nicht über config.toml am Server.

Wie auch immer, wieder ein Rätsel gelöst und ein Script Sudoku vollgekritzelt
… das heißt, ich kann beruhigt schlafen gehen.

ARM64 Assembler

2022-09-03T13:00:00+02:00

Mit meinem ARM64 Windows 11 und Linux am Pinebook habe ich zwei Umgebungen, auf denen ich endlich auch mal ARM64 Assembler Codes testen kann.

Das Schlimme an dem Dialekt ist, dass er sich von ARM32 unterscheidet, was die Portierung von ARM32 Code erschwert.

Microsoft ARM Assembler (MARMASM)

Wenn die Einrichtung des ARM Assemblers erfolgt ist, kann man schon munter drauf losprogrammieren.

Wie schon erwähnt war die Konvention, dass Anweisungen eingerückt sein müssen und nur Labels und Prozedurnamen am Zeilenanfang starten dürfen, neu für mich. Doch sobald man sich daran gewöhnt hat, ist es auch kein Problem mehr.

Register

Die Register x0 bis x7 stellen 8 Integer Funktionsparameter dar, wobei in x0 auch gleich wieder der Returnvalue zurückgegeben wird. Ansonsten gelten x0 bis x15 als (volatile) Scratch-Register und können innerhalb jeder Funktion frei verändert werden.

x19 bis x28 sind nicht-volatile Scratch-Register. Will eine Funktion sie nutzen, müssen die Inhalte z.B.: auf dem Stack gesichert werden und am Ende der Funktion wieder auf den Ursprungswert zurückgesetzt werden. Somit kann eine Funktion, die eine andere aufruft, erwarten, dass diese Register nach dem Aufruf alle Werte “gehalten” haben.

Der Framepointer liegt in x29, kann aber auch als fp angesprochen werden und x30 ist das Link-Register, auch als lr bekannt.

Die Registern x16 und x17 sind volatile “Intra-Procedure-Call-Scratch-Register”, deren Inhalt sich während eines Funktionsaufrufes ändern kann, etwa durch Debugging oder Patches, innerhalb der Funktion kann es “normal” genutzt werden. Und x18 gehört dem OS, unter Windows verweist es z.B.: auf den Thread-Environment-Block im Usermode.

Funktions-Prolog und -Epilog

Ein Bild sagt mehr als 1000 Worte. Folgender Code zeigt eine Funktion, die in C als

1long long my_asm_func_add_2_parameters(long long a, long long b);

deklariert werden würde:

 1  AREA |.text|,CODE,READONLY
 2
 3  EXPORT my_asm_func_add_2_parameters
 4
 5my_asm_func_add_2_parameters PROC
 6  ;; prologue begins
 7
 8  pacibsp                     ; return address protection
 9
10  ; save non-volatile registers
11  stp fp, lr, [sp, #-0x60]!   ; sp -= 0x60
12                              ; sp[0x00] = fp; sp[0x08] = lr
13  stp x19, x20, [sp, #0x10]   ; sp[0x10] = x19; sp[0x18] = x20
14  stp x21, x22, [sp, #0x20]   ; sp[0x20] = x21; sp[0x28] = x22
15  stp x23, x24, [sp, #0x30]   ; sp[0x30] = x23; sp[0x38] = x24
16  stp x25, x26, [sp, #0x40]   ; sp[0x40] = x25; sp[0x48] = x26
17  stp x27, x28, [sp, #0x50]   ; sp[0x50] = x27; sp[0x58] = x28
18
19  ; setup stack-frame
20  mov fp, sp                  ; fp = sp
21
22  ; allocate stack for local variables
23  sub sp, sp, #0x10           ; 2 local variables
24
25  ;; prologue completed
26
27  ; parameters a+b (x0=a, x1=b)
28  add x0, x0, x1              ; x0 += x1        
29  ; return value in x0
30
31  ;; epilogue begins
32
33  ; deallocate stack for local variables
34  add sp, sp, #0x10           ; free 2 local variables
35
36  ; restore non-volatile registers
37  ldp x27, x28, [sp, #0x50]   ; x27 = sp[0x50]; x28 = sp[0x58]
38  ldp x25, x26, [sp, #0x40]   ; x25 = sp[0x40]; x26 = sp[0x48]
39  ldp x23, x24, [sp, #0x30]   ; x23 = sp[0x30]; x24 = sp[0x38]
40  ldp x21, x22, [sp, #0x20]   ; x21 = sp[0x20]; x22 = sp[0x28]
41  ldp x19, x20, [sp, #0x10]   ; x19 = sp[0x10]; x20 = sp[0x18]
42  ldp fp, lr, [sp], #0x060    ; fp = sp[0x00]; lr = sp[0x08]
43                              ; sp += 0x60
44
45  autibsp                     ; return address check
46  ;; epilogue ends
47  ret
48  ENDP
49  END

Und jetzt zu den Details: pacibsp und autibsp dienen dem Schutz gegen Fehler und Malware, aber das hat schon Raymond Chen super erklärt.

Der Stack ist immer auf 16 Bytes ausgerichtet, weshalb man häufig immer gleich zwei Register gleichzeitig auf den Stack speichert bzw. lädt. stp (store pair) und ldp (load pair) erledigen das, man könnte aber auch einzelne Register ansprechen mit str (store register) und ldr (load register).

Gemäß ABI werden zuerst Framepointer und Linkregister auf den Stack gesichert, gefolgt von allen nicht-volatilen Registern x19 - x28, die man in der Funktion verändern möchte. (Im Beispiel wird gar nichts verändert, aber zwecks Demo werden trotzdem alle herangezogen).

Die erste stp Anweisung mit dem Rufzeichen am Ende führt zwei Änderungen durch: Sie subtrahiert zuerst vom Stackpointer die Puffergröße für alle zu speichernden Register (12 x 8 = 0x60) und danach werden fp und lr in den Stack gespeichert. Die Nachfolgenden stps sichern die restlichen Register “über” dem aktuellen Stackpointer.

Danach wird noch der Framepointer fp auf den Stackpointer sp gesetzt und es werden genau so viele Bytes vom Stackpointer subtrahiert, wie man für lokale Variablen braucht, die man dann über den Framepointer adressieren kann.

Der Framepointer zeigt somit genau auf die Stack-Adresse, an der der alte Framepointer und danach die Rücksprungadresse gesichert wurde, und so kann der Debugger den Callstack ermitteln.

Lokale Variablen werden dann über fp[-offset] oder sp[+offset] angesprochen. Nach dem Prolog sieht das Stack-Layout so aus:

Frame ptr	Stack ptr	Bedeutung
fp[0x60]	sp[0x70]	Aufrufer-Stack, weitere Parameter
		Beginn des lokalen Stacks
fp[0x58]	sp[0x68]	gesichertes NV Register 10 (x28)
fp[0x50]	sp[0x60]	gesichertes NV Register 9 (x27)
…	…	…
fp[0x18]	sp[0x28]	gesichertes NV Register 2 (x20)
fp[0x10]	sp[0x20]	gesichertes NV Register 1 (x19)
fp[0x08]	sp[0x18]	Rücksprungadresse zum Aufrufer
fp[0x00]	sp[0x10]	Framepointer des Aufrufers
fp[-0x08]	sp[0x08]	Erste 64-bit Stack Variable
fp[-0x10]	sp[0x00]	Zweite 64-bit Stack Variable
-		Ende des lokalen Stacks

Nachdem auf ARM64 die ersten 8 Funktionsparameter per Register übergeben werden, kann mit diesen sofort gerechnet werden. Im Beispiel werden schließlich nur zwei Parameter (x0, x1) addiert und das Ergebnis in x0 zurückgegeben.

Der Epilog ist die Umkehrung des Prologs. Zuerst wird der Speicher für lokale Variablen vom Stackpointer “wegaddiert”, dann werden alle nicht-volatilen Register vom Stack zurückgelesen und am Ende der Stackpointer wieder erhöht, damit er genau den Wert hat, den er am Anfang der Funktion hatte.

ret springt dann zur Adresse des wiederhergestellten Linkregisters.

Funktionsaufruf

Die obige Beispielfunktion my_asm_func_add_2_parameters wird ganz einfach per

1  mov x0, #21
2  mov x1, #12
3  bl my_asm_func_add_2_parameters

aufgerufen.
Es werden die Parameter-Register gesetzt, und danach springt bl die Adresse an und sichert gleichzeitig die Rücksprungadresse im Linkregister lr.

Fazit

Mit dem Wissen kann man jetzt auch schon fleißig Assembler-Routinen in ARM64 Programmen schreiben.

Natürlich fehlt noch der Hinweis, dass bei mehr als 8 Parametern, die anderen vor dem Funktionsaufruf auf den Stack gepusht werden, und dass bei Variadic-Functions die Parameter Register ebenso zuerst auf den Stack gepusht werden, damit alle Parameter hintereinander auf dem Stack liegen … aber solche Details hat Raymond schon super beschrieben.

Nicht vergessen darf man auch, dass Floating-Point Argumente in eigenen Register übergeben werden und deren Nummerierung ist leider kompliziert, wenn man sie mit Integer Parametern mischt.

Am Ende bleibt zu sagen, dass ich nun meine Callstack-Switching Routinen im GATE Framework in ARM64 Assembler nachziehen kann, damit auch diese Plattformen abgedeckt sind.

Von X86 kommend wirkte ARM für mich anfangs sehr ungewohnt … doch nach ein paar Fingerübungen wirkt das ganze vertrauter und von den Instruktionen recht genial umgesetzt.

Windows 11 mit altem Kontextmenü

2022-08-28T13:00:00+02:00

Eigentlich bin ich grundsätzlich noch von Windows 11 unabhängig, denn nach einer ersten “Beschau”, stellte ich fest, dass ich es einfach nicht brauche, und blieb bei Windows 10.

Doch seit ich mit meinem APCSILMIC die ARM64 Welt erforsche, ist Windows 11 notwendig.
Und etwas, was mich dort in den Wahnsinn treibt, ist das beknackte “vereinfachte” Kontextmenü …
… das muss weg!

Was für ein Glück, dass sich schon mehrere Mitmenschen damit abgequält haben und eine einfache Lösung publiziert haben:

Windows 11 mit klassischem alten Kontextmenü.

Lösung:
Man legt den Registry Schlüssel
HKCU\Software\Classes\CLSID\{86ca1aa0-34aa-4e8b-a509-50c905bae2a2}\InprocServer32 an und setzt dessen (Default) Welt auf einen Leerstring.
Also in regedit den Eintrag (Default) doppelklicken und wieder mit OK bestätigen, weil ein neu erstellter Schlüssel zwar einen Default-Wert Eintrag hat, der aber nicht gesetzt ist (ursprünglich wird angezeigt: (value not set)). Nach der Aktion hat (Default) einfach “nichts” in seiner Data-Spalte stehen.

Man kann den Vorgang auch mit dem reg Tool als Administrator ausführen:

1reg.exe add "HKCU\Software\Classes\CLSID\{86ca1aa0-34aa-4e8b-a509-50c905bae2a2}\InprocServer32" /f /ve

Fehlentscheidung im Design

Ja, ich kann es nachvollziehen, dass das Windows Kontextmenü für Anfänger zu groß und überladen wirkt und damit verwirrt.

Gleichzeitig ist es aber auch so, dass eben solche blutigen Anfänger von dem Menü oder generell von Rechtsklicks nichts wissen.
Und das macht das neue Menü wiederum nutzlos.

Doch für Entwickler wie mich (und sicher viele Administratoren und andere im IT Umfeld) ist das neue Windows 11 Kontextmenü einfach nur eine Zumutung.

Tools wie 7Zip, Git oder Visual Studio Code registrieren im klassischen Menü ihre Einträge, womit man für jede Datei wichtige Operationen schnell und effizient starten kann.

Im neuen Windows 11 Menü fehlen diese Tools und man muss erst nach unten fahren und auf Weitere Optionen anzeigen klicken, bis das alte Menü erscheint.
Und ich brauche das bei der Arbeit bis zu hundert Mal wenn ich in 300 Source-Directories Downloads und diff Vergleiche durchführen muss.

Fazit

Augen auf, Microsoft!

Wäre es nicht viel sinnvoller gewesen eine neue Einstellung einzuführen um das Kontextmenü leichter anpassen zu können?
z.B.: In dem man unwichtige Einträge auf “unsichtbar” setzen kann, oder seltener genutzte Funktionen in ein Untermenü auslagern kann?

Aber dass wir alle mit dem neuen nutzlosen Menü konfrontiert sind, das sich nur durch einen Registry-Hack umgehen lässt, ist nicht OK.
Man hätte es zumindest per UI ein- und ausschaltbar gestalten können.

However. Vielen Dank an die Finder des Registryschlüssels.
Hiermit sei er auch bei mir dokumentiert und verbreitet sich hoffentlich weiter, bevor noch mehr Produktivität durch die Mehrfachklickerei verloren geht.

Nachtrag: Klassisches Startmenü

Ich hätte jetzt gerne auch noch das alte Windows-10 Startmenü zurückgefordert und tatsächlich gab es hierfür anfangs auch einen Registry-Hack. Doch Microsoft hat diese Möglichkeit mit Updates wieder entfernt, und so laufen die bereits publizierten “Hacks” nur unter dem originalen Windows 11 Release, aber nicht mehr unter den aktuellen Varianten.

Der Trick lautete in HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced\ den DWORD Eintrag Start_ShowClassicMode auf 1 setzen.
Doch leider leider leider, funktioniert das nicht mehr.

GITLAB mit Tests und Code Coverage

2022-08-27T13:00:00+02:00

Gitlab wird als Quellcode Verwaltungssystem in vielen Firmen eingesetzt, auch in denen für die ich gearbeitet habe und arbeite.

Gitlab ist simpel … und deshalb sehr kompliziert.
Den jeder Anwender kann sich seinen eigenen Weg durch einen Berg von Funktionen graben und deshalb sieht jeder Tunnel dann etwas anders aus.

Und eine interessante Herausforderung ist das Sammeln von Code-Coverage Daten in C++.

CI Pipelines und Jobs

Das Continuous Integration Feature (kurz CI) gestatt es automatisiert “Operationen” bei Bestimmten Ereignissen auszuführen.
Der Klassiker ist, dass man bei jedem Commit in einem GIT Repository dann eine Build-Pipeline startet, die den neuen Code kompiliert und gegebenenfalls abtestet.

Eine Pipeline besteht dann aus einer oder mehreren “Stages” mit den größeren Teilschritten und in jeder Stage laufen dann die eigentlichen “Jobs”, z.B.: kann jeder “Job” eine Plattform wie Windows oder Linux abdecken oder für unterschiedliche Testframeworks.

Ein mir vertrauter einfacher Ablauf solcher Pipeline “Stages” ist:

Build
Alle Sourcen werden kompiliert
Test
Unit Tests werden ausgeführt um Test und Code-Coverage Berichte zu erstellen
Deploy
Fertige Binaries werden irgendwo hin hochgeladen, wo sie direkt eingesetzt werden oder auf einen Download warten.

Report Formate

Unit test Frameworks können ihre Ergebnisse in unterschiedlichen Formaten ausgeben, was man meist über Commandline-Switches einstellen kann.
Zwei recht bekannte Formate sind:

JUnit für das Zusammenfassen von Tests
Cobertura für das Sammeln von Code-Coverage Informationen

JUnit Test Reports

JUnit und Cobertura entstanden ursprünglich von Java Projekten, sie wurde aber von vielen Sprachen genutzt um eigene Tests standardisiert auszugeben.
Das C++ Framework BOOST unterstützt in seinen boost/test Klassen auch JUnit und mit eben diesem durfte ich die letzten Jahre arbeiten.

Der Test:

 1#define BOOST_AUTO_TEST_MAIN
 2#define BOOST_TEST_MODULE test_my_code_module
 3
 4#include <boost/test/auto_unit_test.hpp>
 5
 6BOOST_AUTO_TEST_SUITE(my_test_suite)
 7
 8BOOST_AUTO_TEST_CASE(my_test_case)
 9{
10  throw 1;
11}
12
13BOOST_AUTO_TEST_SUITE_END()

führt dann zu sowas wie:

 1<testsuite tests="5" skipped="0" errors="1" failures="0" id="0" name="test_my_code_module" time="0.130668">
 2  <testcase classname="my_test_suite" name="my_test_case">
 3    <error message="unexpected exception" type="system error">
 4      <![CDATA[
 5        UNCAUGHT EXCEPTION ...
 6      ]]>
 7    </error>
 8  </testcase>
 9</testsuite>

Ein Gitlab CI Job in gitlab_ci.yml, der für einen Boost-Test in etwa so aussieht:

 1test_job:
 2  script:
 3    - mkdir ${CI_PROJECT_DIR}/test_results
 4    - > 
 5      path/to/test_my_code_module 
 6      --report_sink=${CI_PROJECT_DIR}/test_results/my_test_results_sumary.txt
 7      --logger=JUNIT,all,${CI_PROJECT_DIR}/test_results/my_test_results.xml
 8    - echo "Done"
 9  artifacts:
10    paths:
11      - ${CI_PROJECT_DIR}/test_results/*
12    reports:
13      junit: ${CI_PROJECT_DIR}/test_results/my_test_results.xml

Lädt die Ergebnisse dann zum Gitlab-Coordinator hoch und der kann dann die my_test_results.xml sofort parsen und im Web-UI schön anzeigen.

Code Coverage

Bei der Code Coverage (oder auch Test-Coverage) wird im Sourcecode mitgezählt, welche Zeilen ausgeführt wurden und welche nicht. Am Ende wissen wir, ob unsere Tests sinnvoll waren und alles abgetestet haben, oder viele Codezeilen nie angesprungen und damit ungetestet verblieben sind.

Je nach Umgebung muss man den Sourcecode speziell kompilieren und mit Hilfsprogrammen die Coverage errechnen lassen.

Beim GCC kann man die Sourcen mit --coverage kompilieren womit bei der Ausführung .gcno und .gcda automatisch erstellt werden. Tools wie gcovr können diese Dateien dann in das Cobertura-XML Format umwandeln.

1gcovr --xml-pretty -o coverage.xml --root path/to/source

Unter Windows kann z.B.: OpenCppCoverage ein Debug-Binary ausführen und misst dessen Ausführung per Debugger mit.

1OpenCppCoverage.exe --source path/to/sources --export_type cobertura:coverage.xml -- test.exe

Doch leider reicht es jetzt nicht ganz aus, dieses Ergebnis einfach zum Gitlab Coordinator hochzuladen mit:

 1test_job:
 2  script:
 3    - ...
 4  artifacts:
 5    paths:
 6      - ${CI_PROJECT_DIR}/test_results/*
 7    reports:
 8      coverage_report:
 9        coverage_format: cobertura
10        path: ${CI_PROJECT_DIR}/test_results/coverage.xml

Denn um die % Zahl der Coverage registriert zu bekommen, nutzt Gitlab nicht die XML-Datei (die wird nur bei Mergerequests herangezogen).
Gitlab erwartet, dass das Ergebnis auf die Konsole geschrieben wird, und dass man es von dort per Regular-Expression auslesen kann.

Bei gcovr muss man noch den Commandline-Switch --print-summary anfügen, damit der Output so aussieht:

1gcovr --xml-pretty --print-summary -o coverage.xml --root /path/to/src
2lines: 85.0% (425 out of 500)
3branches: 30.0% (17106 out of 56994)

Mit dem coverage Zusatz im Gitlab Job wird die lines Zeile extrahiert:

 1test_job:
 2  script:
 3    - ...
 4  coverage: /^\s*lines:\s*\d+.\d+\%/
 5  artifacts:
 6    paths:
 7      - ${CI_PROJECT_DIR}/test_results/*
 8    reports:
 9      coverage_report:
10        coverage_format: cobertura
11        path: ${CI_PROJECT_DIR}/test_results/coverage.xml

Fazit

Am Ende hat man dann Test-Reports und Coverage-Reports, die man im Gitlab Web-UI anzeigen und per Rest-API abholen kann.

Durch Gitlab-Badges lässt sich die Coverage-Zahl auch direkt auf der Projektseite anzeigen und diese kleinen SVG-Bilder lassen sich auch hervorragend in andere Gitlab-Seiten einbauen um einen Überblick zu erhalten.

RISC-V: Lichee RV Allwinner D1

2022-08-21T13:00:00+02:00

RISC-V ist der neue “heiße Scheiß”, der kommt/kommen wird/gekommen ist.

Es ist eine Open-Source Prozessor-Architektur, die in Zukunft den Computer Markt mitbestimmen soll. So wie vor 15-20 Jahren ARM Prozessoren über Smartphones eine große Verbreitung erlebten, so soll jetzt mit RISC-V ein weiterer Spieler hinzukommen.

Eine Geschichte rund um Patente

Was gab es nicht für Prozesse und Anfeindungen zwischen Intel und seinen Nachahmern, wenn es um den Bau von Prozessoren ging. Jede neue Technologie wurde mit Patenten zugekleistert um möglichst viel Profit aus den Ideen der Konkurrenz auf der eigenen Plattform herauszupressen.

Doch was wäre, wenn die allgemeine Funktionsweise von Prozessoren frei von solchen Patenten wären?

Dann könnte jede Chip-Fabrik anfangen Chips zu fertigen, ohne dass lange Verhandlungen, Prozesse und Lizenzzahlungen durchlaufen müssten.

Diese Idee wurde mit RISC-V geboren, bzw. RISC-V wurde für diese Idee geboren.

Lichee RV mit Allwinner D1

Im sipeed Store bei Aliexpress fand ich das “Lichee-RV D1” Starter Kit bestehend aus dem Prozessorboard und dem IO Dock für 37 Euro und erwarb somit:

1GHz Single Core CPU (XuanTie C906 Risc-V-64bit)
512 MB RAM (DDR3)
HDMI Display
SD-Kartenslot
WLAN
Bluetooth

Das sind die Merkmale des Lichee-RV D1 RISC-V Entwicklerboards. Ungewöhnlicherweise wurde hier das “Mainboard” von der Peripherie getrennt. Der Prozessor+RAM Chip wird in ein eigenes Docking-Board eingespannt um ein vollwertiges System zu bilden. Auf dem Docking-Board befindet sich der HDMI-Anschluss, wie auch eine USB 2 und eine USB-C Buchse. Und neben dem 40-Pin IO Header sind noch 3 einzelne Buttons am Board angebracht.

Prebuild images

Man findet einige Links zu Debian-Risc-V-Images, doch wenn man die 1:1 auf eine SD-Karte überträgt, funktionieren sie nicht. Offenbar müssen die auf der Karte speziell ausgerichtet sein und benötigen dafür eine spezielle Software.

Zum Glück gibt es aber auch vollständig vorbereitete Images, die man direkt auf die SD-Karte übertragen kann, und ich konnte ein solches unter linux-sunxi.org finden. Die Datei trägt den Namen
20211230_LicheeRV_debian_d1_hdmi_8723ds.ddimg.xz.

Mit dem Win32DiskImager oder mit dd unter Linux werden die 16 GB auf eine minestens ebenso große SD-Karte übertragen. Und nach dem Einlegen in den SD-Slot am D1-Board, bootet das Gerät auch schon davon.

Schnell ist der Vorgang nicht, doch nach einiger Zeit landet man in der X11 Login-Maske und kann mit

User: sipeed
Passwort: licheepi

den UI Login und weiteren Start von LXDE durchführen.

Mit dem Datenträger-Verwaltungswerkzeug kann man nun die letzte leere “Füllpartition” der Karte löschen und die davor liegende Systempartition bis zum Ende des Datenträgers vergrößern. Es sind nämlich weniger als 8 GB benutzt und der Speicher ist schon ziemlich voll.

WLAN

Das WLAN Modul ist per Konfiguration deaktiviert und deshalb scheiterte ich auch daran, mit ip link oder ifup das Netzwerk hochzufahren.
Doch “wer lesen kann ist klar im Vorteil”, denn es stand ohnehin auf der Webseite beschrieben, dass das Netzwerk mit dem ConnMan, einem Netzwerkverwalter für Embedded Systeme betrieben wird, und im Startmenü befindet sich mit “ConnMan Settings” auch ein UI dafür.

Dort kann man den WLAN Adapter grafisch einschalten und sich zum nächsten WLAN Accesspoint verbinden.
Bisher hatte ich noch nie mit ConnMan gearbeitet … war also wieder mal eine neues MAN Erlebnis für mich.

Interessant war, dass ich meinen normalen USB-LAN-Adapter auch nicht einfach anschließen konnte. Für diesen wurde kein Treiber geladen, was ich so nicht gewohnt war.

Neue Schlüssel für apt

Als nächstes standen Updates an, doch Aufrufe von apt update und apt upgrade scheiterten mit der Meldung:

Failed to fetch … The following signatures couldn’t be verified because the public key is not available: NO_PUBKEY …

Die offizielle Lösung des Problems lautete auf:
curl https://www.ports.debian.org/archive_2022.key | apt-key add -
doch leider waren weder curl noch wget im Linux Image enthalten.

Ich musste also https://www.ports.debian.org/archive_2022.key auf meinem PC herunterladen, auf einen USB Stick kopieren und diesen am Lichee-RV anschließen. Von dort konnte ich den Import mit
apt-key add /path/to/archive_2022.key erfolgreich durchführen und im Anschluss das Update starten.

Upgrade

Fast 1000 Update-Pakete wurden vorgeschrieben, und so startete eine stundenlange Download- und Installationsprozedur.

Am Ende erkannte ich, dass meine Debian 11 Installation durch das sich noch in Entwicklung befindliche Debian 12 (Name Bookworm) ersetzt wurde. Warum das ungefragt geschehen war, weiß ich nicht, denn /etc/apt/sources.list verwies auf die allgemeine Debian Backports Pfade.

Wer dieses Upgrade also nicht möchte, sollte Maßnahmen dagegen ergreifen.
Denn leider kam es ab dem Upgrade immer wieder mal zu Hängern beim Neustart. Hier muss man Board entweder per Reset-Taste oder Stromentzug so lange neu starten, bis der Startvorgang wieder vollständig bis zur UI durchläuft. Das war vor dem Update in meinen Tests nämlich nicht so.

Fazit

Das Lichee RV D1 Board ist in etwa auf dem Niveau eines originalen Raspberry Pi Zero W.

Als Desktop Ersatz sind weder das D1 noch der Pi Zero geeignet, denn mit 512 MB RAM braucht man an einen Webbrowser gar nicht erst zu denken.

Das Kompilieren des GATE-Frameworks lief wie erwartet träge und brach wegen zu wenig RAM beim LTO Linkvorgang ab, doch ohne LTO erhält man feine RISC-V Binaries, die auch sogleich ausgeführt werden können.

Als nächstes werde ich mich den GPIO Funktionen widmen. Wie schön, dass die auf der Rückseite beschrieben sind.

Wer einige Euros mehr investiert, erhält natürlich auch mehr Kerne und mehr RAM in anderen Modellen und Produkten, doch aktuell liegen diese noch weit hinter ARM basierten Modellen zurück.
Aber vergessen wir nicht, wie lange ARM hinter X86 zurück lag und heute ist ARM auf der Überholspur, vor allem in Sachen Energieeffizienz.

Ich erwarte bzw. erhoffe mir also, dass RISC-V in den kommenden Jahren einen ähnlichen Sprint hinlegt, damit wir in Zukunft endlich auch mal einen OpenSource-Prozessor in unseren Geräten eingebaut bekommen.

Der erste Eindruck war also “OK”, ich darauf kompilieren und ich bin gespannt wie es dort weitergehen wird.
Denn immer weitere Boards wie MangoPI oder Nezha werden auf den Markt geworfen.

GCC Weak Symbols und no-as-needed

2022-08-20T13:00:00+02:00

Mit dem GCC 6 hat noch alles funktioniert und seit dem Upgrade auf GCC 10 crashen unsere Binaries …

Und wieder einmal durfte ich lernen, dass kleine unscheinbare Änderungen an Standard-Features große Ausfälle bei den Resultaten auslösen können.

Doch so lernte ich etwas über “Weak Symbols”, also “Schwache Symbole” in Bibliotheken.

(Bei der Gelegenheit ein großes Danke an meinen Kollegen, der das Problem analysiert, gelöst und mir vermittelt hat.)

Spezielle Features von Compilern oder Betriebssystemen interessieren mich normalerweise wenig. Schließlich scheitert man an genau diesen, wenn man plattformunabhängigen Code erzeugen will.

Darunter fielen bisher Microsofts Delay-Loaded DLLs oder so manche __declspec Erweiterungen und das gleiche gilt auch für __attribute__ beim GCC.
Nur __declspec(dllexport/dllimport) und
__attribute__((visibility ("default/hidden"))) sind die Ausnahme, weil sie de-facto Standards auf ihren jeweiligen Plattformen sind.

GCC Weak-Functions

Der GCC erlaubt, dass eine Funktion oder eine Variable deklariert und exportiert werden kann, ohne dass sie tatsächlich implementiert sein muss. Mit dem Attribut __attribute__((weak)) bei z.B. einer Funktion, wird diese exportiert ohne vorhanden sein zu müssen.

1int lib_function(int param) __attribute__((weak));

Man kann somit ein “Interface” in einer Bibliothek deklarieren ohne es zu implementieren. Und die Bibliothek kann dann bei Bedarf eine andere Bibliothek laden oder direkt linken, die den gleichen Funktionsnamen regulär implementiert.

Denn Weak-Symbole werden von normalen (Strong-)Symbolen überschrieben. So kann man öffentliche von privaten Bibliotheken trennen und z.B.: die privaten Bibliotheksteile dann beliebig austauschen.

graph LR PROG(Main
Program) IFACE[["Public Interface Library
lib_function() weak"]] IMPL[["Private Implementation Library
lib_function() strong"]] PROG --Link--> IFACE IFACE --Link--> IMPL PROG -. "Invoke
lib_function()" .-> IMPL

Problem Linker-Optimierungen

Dumm ist dann nur, wenn eine Bibliothek mit weak Symbolen eine andere mit strong Symbolen linkt und dann keine direkten Aufrufe zur zweiten Lib enthält.
Denn moderne Compiler ermitteln, dass keine Aufrufe stattfinden und entfernen die Bibliothek dann aus der Liste der Abhängigkeiten. Diese Feature wird durch das Linker-Flag --as-needed explizit aktiviert.

Am Ende wird die “private” Bibliothek nicht geladen und die Interface- Bibliothek steht alleine da mit einer “leeren” weak Referenz.
Ein Programm, das diese weak Funktion aufruft, springt somit in einen Null-Pointer hinein, was selten gut ausgeht.

Und so erklärt sich, warum ältere Compiler ohne diese Optimierung Code generieren, der solche weak Funktionen in Bibliotheken samt deren Abhängigkeiten laden kann, während neuere Kompilate zu einem

Segmentation fault (core dumped)

führen.

Lösung: `--no-as-needed`

Mit dem Linker-Flag --no-as-needed, bzw. -Wl,--no-as-needed beim Compiler wird diese Optimierung deaktiviert und auch moderne GCC Compiler können dann jene Bibliotheken korrekt laden, die per weak Symbols auf andere Bibliotheken weiterverlinken.

Fazit

Wieder mal etwas interessantes gelernt!
Ein Codebeispiel im Blog-Classroom zeigt den Sachverhalt im Code auf.

Denn diese Arbeitsweise entdeckten wir bei einer 3rd-Party-Komponente, die offenbar ähnlich über solche weak Funktionen zwischen mehreren Implementierungen umschalten konnte.

Ich bin allerdings der Meinung, dass man das mit dlopen/dlsym hätte lösen sollen und keine (jetzt fragile) GCC-Compiler-Erweiterungen hätte nutzen sollen.
Denn Compiler-Standards ändern sich und weder der C noch der C++ Standard definieren Richtlinien, wie sich exportierte Funktionen im Detail verhalten.

PS/2 Modell 30

2022-08-14T13:00:00+02:00

In meiner Vergangenheit finden sich in erster Linie “billige” Klone von PCs.

Doch darunter steht tatsächlich auch ein “originaler” IBM PC der Gattung
PS/2 Modell 30.
Das Geräte ging vermutlich um das Jahr 1987 über den Ladentisch, bis es dann im Jahr 2000 in meiner Sammlung von Althardware landete.

Hardware

So sieht also ein “richtiger” PC aus. Ein flaches Desktopgehäuse, auf dem ein fetter VGA platziert wurde. Ein oder zwei Diskettenlaufwerke und ein übergroßer On/Off Schalter, den man sonst nur aus Filmen kennt um damit Atomraketen zu zünden.

Innen drinnen sieht man noch richtige Bauteile wie Zentimeter-große Dioden, die man heute nur noch mit der Lupe oder mit Mikroskopen finden könnte.

Die faszinierendste Konstruktion, die ich je gesehen hatte war aber der große rote Kippschalter, dessen Ausrichtung mechanisch über einen Bügel zum Netzteil geleitet wurde, wo er den Stromkreis schließen oder unterbrechen konnte.

Mein Modell kam mit 2 Diskettenlaufwerken. Ursprünglich war auch eine Festplatte per ISA-Bus direkt verbunden, doch nachdem diese schon kurz nachdem ich das Gerät bekommen hatte einging, hatte ich diese damals gleich ausgebaut, weil sie (wie alle Platten damals) ziemlich laut war.

Auf der Rückseite findet man

PS/2 Anschluss für die Tastatur
PS/2 Anschluss für eine Maus
einen Parallelport Anschluss für Drucker
einen seriellen Port
und einen VGA D-SUB-15 Anschluss.

… hmm, oder vielleicht nicht ganz, denn von den 15 Pins sind nur 14 verfügbar. Pin Nr. 9 (der zweite von links in der mittleren Reihe) ist nämlich nicht “durchgebohrt”. Nicht alle meine VGA-Kabel konnten damit umgehen, doch einige waren auf diesen fehlenden Pin zum Glück vorbereitet.

Zu meinem Bedauern sind auch die Floppylaufwerke offenbar nicht mehr in Ordnung. Eines ist überhaupt still, weil vermutlich der Motor defekt ist. Das zweite konnte seinen Motor zwar starten, doch Disketten vermochte es nicht zu lesen, zumindest kam es nie zu einem Bootvorgang.

Beim Umbau der beiden Floppy-Laufwerke bekam ich anfangs leider das Gehäuse nicht zerlegt. Hätte mir doch jemand gesagt, dass bei diesem Gerät alles nur “zusammengesteckt” ist und dass man nur an den richtigen Stellen “drücken” muss, damit sich die Komponenten lösen.

So werkelte ich lange herum, was nicht jede der Plastikhalterung schadfrei überstand. Am Ende konnte ich jedoch die beiden Floppy-Laufwerke tauschen um zu sehen, wie sich das zweite beim Boot verhalten sollte.

Software ohne Datenträger

Nachdem beim Start kein Boot von Diskette möglich ist, erschient eine interessante ASCII-Text Animation auf dem Bildschirm, die einen anweist eine Boot-Diskette einzulegen.

Wenn dann weiter kein Disketten-Boot möglich ist, landet man im IBM-BASIC, dass im Chip abgelegt ist.

Das fühlt sich fast so an wie beim Commodore 64. Denn auch dort landet man stets im BASIC-Editor und kann sich mit einige BASIC-Kommandos seine eigene Software schreiben und direkt auf der Hardware ausführen.
Freilich geht jeder Code beim Neustart verloren, weil man kein Medium verfügbar hat, worauf man den Code speichern könnte.

Interessant ist es aber trotzdem.

Fazit

Nachdem heutige PCs mit der EFI-Shell eigentlich auch eine mächtige Umgebung direkt am Chip installiert haben, ist es Schade, dass keine Programmierung auf der Ebene möglich ist. Denn die paar Kilobytes hätte man auch noch finden können, um ein BASIC, LUA oder was Ähnliches bereitzustellen.

Der IBM PS/2 ist für mich daher ein gutes Beispiel für einen durchdachten Computer … obwohl seine Bauteile leider nicht alle bis heute überlebt haben.

Und es zeigt sich wieder einmal, was früher mit derart wenigen Mitteln alles möglich war.
Naja … es war eben IBM und die wollten immer schon im “Business” Eindruck machen, wie die Werbung deutlich machte:

Pinebook Pro

2022-08-13T13:00:00+02:00

Endlich … ein weiterer Schritt in Richtung ARM64.

2 Monate musste ich warten, bis “mein” Pinebook Pro von Pine64 endlich geliefert werden konnte, doch nun besitze ich einen Linux basierten Laptop, mit dem auch die mobile Programmierung möglich wird.

Eigentlich mochte ich meinen Pi-Top … doch etwas war darauf nicht so lustig: Nämlich größere Codeprojekte zu bearbeiten. Denn der enthaltene Raspberry PI 3B+ verhindert mit seinem einzelnen 1 GB RAM, dass IDEs und Buildprozesse stabil laufen.

Und nachdem der Raspberry PI 4 mit einem anderen Layout inkompatibel zum Laptopformat war, blieb meine Motivation mit dem PI 3 “mehr” darauf zu machen recht gering.

Pine64

Nach dem PinePhone, dem Pinecil und der PineTime habe ich ein weiteres Geschwisterchen der Pine64 Familie bestellt.
Ich machte bereits letztes Jahr den Fehler, das Gerät nicht zu bestellen und musste nun über ein halbes Jahr warten, bis es überhaupt wieder produziert wurde und kaufte schließlich eines der neuen Geräte (mit ANSI Tastatur).
Auch hier verzögerte sich die Lieferung von Juni/Juli auf die erste Augustwoche, doch nun ist der Laptop endlich da.

220 Dollar ist der aktuelle Kaufpreis und DHL verrechnete noch weitere 70 Euro an Einfuhrzöllen. Hier bin ich fast schwer beeindruckt, wie unkompliziert diese Zahlung per Link und PayPal war, sodass der Lieferung keine 5 Minuten aufgehalten wurde. Ich wünschte, das wäre immer so einfach bei Importen.

Daten und Leistung

6 Kerne (2x 1.8GHzm 4x 1.4GHz)
4 GB RAM
64 GB eMMC
1080p Display

Das übertrifft den Raspberry PI 3B und auch Modell 4 bei weitem und sollte mir ein völlig neues mobiles Arbeiten ermöglichen.
Und trotzdem bemerkte ich, dass ein Visual Studio Code schon seine Zeit brauchte, um geladen zu werden und um Code “einzufärben”.
Ich vermute, dass hier aber eher das eMMC Modul ein Flaschenhals war, denn beim Kompilieren übertraf die ARM-Maschine meinen alten i3-Laptop (4 logische Kerne) aus dem Jahr 2016.

Meine üblichen Videodateien in 720p Auflösung konnten problemlos abgespielt werden, und viel mehr brauche ich im Alltag auch nicht.

Kleine Mankos

Irgend etwas stimmt mit dem Audio-Modul nicht, denn wenn ein Sound abgespielt wird, erfolgt danach nach etwa 10 Sekunden ein ziemlich lautes Knacken, als hätte jemand einen fetten Kippschalter umgelegt.
Dieses “Abschalten” der internen Lautsprecher erschreckte mich am Anfang furchtbar, weil ich dachte, dass der Lithium-Akku aufgeplatzt wäre.

Ob das nun ein Softwareproblem ist oder einfach nur der Lautsprecher falsch verdrahtet ist, weiß ich nicht … aber mal sehen ob im Pine-Forum jemand etwas Ähnliches berichtet.

Manjaro Linux

Lange hatte ich schon überlegt Manjaro Linux auf dem PinePhone einzusetzen, doch mir gefiel die Tatsache eine “echtes” Alpine-Linux mit PostmarketOS einzusetzen.
Mit dem PineBook Pro kommt nun endlich mal eine Arch-Linux Distribution bei mir zum Einsatz.

Und diese Linux Variante gefällt mir bisher recht gut, weil sie vor allem optisch gut gestaltet ist und ich mir vorstellen kann, dass auch ein Anfänger sich gut darauf zurecht findet.

Fehlende Apps wie etwa ein Mailclient und Updates sind einfach per UI installierbar und alle anderen Pakete für spezielle Zwecke (wie Compiler und Development-Libs) lassen sich per
sudo pacman -S PACKNAME einrichten.

Einziges Manko hier war tatsächlich die Passwort-Vergabe.
Ich wechselte nämlich zuerst zum deutschen Tastaturlayout und tippte im Dialog ein paar Seiten später mein Passwort ein.
Doch beim ersten Login nach einem Neustart funktionierte das nicht.

Schnell wurde mir klar, dass die Sonderzeichen ursprünglich noch mit dem englischen Tastaturlayout eingetippt wurden. Eine passwd Aufruf korrigierte das Problem … doch diese unnötige Fehler schreckt womöglich neue Kunden ab.

Fazit

Von 2006 bis 2016 war ein Laptop an der Hälfte meiner Entwicklungen beteiligt. Danach folgte eine intensive Desktop-Zeit, da ich einfach nicht mehr mit einem Monitor auskomme und meine Geräte stets an Leistungsgrenzen stießen.

Ich hoffe, mein PineBook nun häufiger zu benutzen und wieder mobiler damit zu werden.

Vor allem wird mir die Linux ARM64 Platform die Gelegenheit bieten können ein paar Zeilen ARM64-Assembler zu lernen.
Und darauf freue ich mich schon ganz besonders.

Von daher mal ein:

Herzlich willkommen im Team!

an meinen neuen digitalen Gefährten. Der erste Eindruck ist ein guter. Und die paar Macken, bekommen wir schon noch in den Griff.

XTEA und Blowfish

2022-08-07T13:00:00+02:00

Kryptographie-Bibliotheken gibt es viele. OpenSSL libReSSL und Crypto++ sind wiederkehrende Weggefährten meines Programmieralltags.

Doch wenn es darum geht ohne Abhängigkeiten “ein bisschen” Sicherheit über Daten zu legen (z.B.: am Mikrocontroller), dann sind die genannten Moloche ungeeignet.

Hier greife ich dann gerne zu Blowfish oder XTEA.

Symmetrische Verschlüsselung ist generell nicht hoch-sicher, gemessen an asynchronen Verfahren, die aber auch schwer an Bit-Adipositas leiden.

Wer aber “nur” verhindern möchte, dass ein anderer seine Dateien lesen kann, erzeugt sich einen Schlüssel und lässt seine Daten damit umordnen, so dass man eben selbigen Schlüssel braucht, um das Ganze wieder lesbar zu machen.

Wie man diesen Schlüssel jetzt “gut aufbewahrt” ist eine andere Frage, um die es hier nicht gehen soll.

Blowfish

Der von Bruce Schneier stammende Blowfish arbeitet auf 64-bit Blöcken und verschränkt bzw. verschiebt Bits mit durch den Schlüssel generierten Datenblöcken, die man durch eine Umkehrfunktion wiederherstellen kann (siehe Feistelnetzwerk).

In Berührung gekommen bin ich mit Blowfish vor langer Zeit auf CodeProject als die “schnelle” Verschlüsselung von Daten mit einem festen einkompilierten Schlüssel in einem Projekt notwendig war.
Der dortige C++ Code hat leider den Fehler, dass er nicht Streaming-fähig ist, man kann also nicht stückweise die Daten an den En/Decoder verfüttern. Genau das war meine erste Änderung an dem Modul und nach vielen weiteren Iteration ist ein darauf aufbauender Code noch am GATE Projekt gelandet.

Zur Verifizierung des selbst überarbeiteten Codes nutze ich OpenSSL, das mit seinen BF_* APIs zum gleichen Ergebnis kommen muss.

ECB und CBC

Ich verstehe wenig von Kryptographie, doch durch die Befassung mit Blowfish wurde mir die ECB und CBC Varianten verständlich erklärt.
Beim Electronic CodeBook (ECB) wird der Datenstrom in Blöcke zerteilt und jeweils mit dem gleichen Schlüssel verknüpft. Das Ergebnis ist eine Kette von verschlüsselten (gleich großen) Blöcken, die leider nicht sehr sicher sind.

Im Wikipeda Artikel zeigt die Verschlüsselung eines Bildes, dass das Ergebnis noch erkennbar das Muster der Originaldaten aufweist.

Beim Cipher Block Chaining (CBC) wird ein zusätzlicher “Initialisierungsvektor” in Form von ein paar Bytes definiert (also wie ein Zusatz zum Hauptschlüssel), der mit den Eingangsdaten vor der Verschlüsselung verknüpft wird. Der neu erzeugte verschlüsselte Block wird dann mit dem darauffolgenden Eingangsblock verknüpft, bevor dieser verschlüsselt wird … usw. Nachdem jeder verschlüsselte Block einen Teil des Vorgängerblocks in sich trägt, ist das Ergebnis der gesamten Verschlüsselung “so zufällig”, dass man keine Muster mehr erkennen kann (zumindest nicht leicht).

Aus diesem Grund ist CBC das einzige Verfahren, dass man für Datenverschlüsselung nutzen sollte.

TEA, XTEA und XXTEA

Für Mikrocontroller ist Blowfish leider oft zu groß. Die wenigen nutzbaren Kilobytes würden von den Blowfish-Tabellen ausgefüllt werden, und deshalb suchte ich nach einer einfacheren Alternative.
Gefunden habe ich XTEA und seinen Nachfolger XXTEA.

Der Tiny Encryption Algorithm (kurz: TEA) verknüpft Blöcke von 64-bit Daten mit einem 128-bit Schlüssel.
TEA galt jedoch nicht als besonders sicher und so wurde sein Nachfolger XTEA ins Leben gerufen, welcher wiederum mit XXTEA verbessert wurde, der auch als “Corrected Block TEA” bekannt ist.

Während XTEA mehrere Verschlüsselungsrunden mit dem 128-bit Schlüssel auf jeden 64-bit Datenteilblock anwendet, verknüpft XXTEA alle aufeinanderfolgenden 64-bit Datenblöcke und verknüpft diese in mehreren Runden.

All TEA-Varianten sind als Public-Domain Code frei verfügbar und wegen ihrer geringen Größe auch für Mikrocontroller geeignet.
XTEA verbraucht nur 24 Bytes (8 für Daten, 16 für Schlüssel) um einen Block zu bearbeiten, womit man eine Nachricht in kleinen Teilstücken verschlüsseln kann.
XXTEA erhöht die Sicherheit nur dann, wenn man größere gepufferte Datenmengen in einem Schritt verschlüsselt. Soll heißen, am ATtiny mit 128 bis 512 Bytes RAM macht es keinen Sinn, aber mit mehr RAM und größeren Nachrichten stellt XXTEA ein gutes Verhältnis zwischen Sicherheit und Komplexität dar.

Fazit

Im GATE Framework sind Blowfish, XTEA und XXTEA implementiert. Zwar habe ich aktuell noch keine direkte Anwendung dafür, aber die Nutzung als “einfache” Verschlüsselung für Daten steht bereits auf meiner Wunschliste.

Denn wenn man z.B.: Passwörter oder URL speichern möchte, die nicht jeder Gastbenutzer gleich finden soll, dann hilft es sehr, diese verschlüsselt zu speichern.

Das ersetzt natürlich keinen guten Passwort-Manager, aber zumindest lässt man die Daten nicht fahrlässig im Klartext liegen. Und das ist zumindest mal ein Anfang.

HTA - Hypertext Applikationen

2022-08-06T13:00:00+02:00

Hypertext Applications (HTAs, auch HTML-Applications) waren eine interessante und heute bedeutungslose Erweiterungen von Microsofts Internet Explorer, um “echte” Fenster per XML erweitertem HTML zu erzeugen und Desktop UIs damit zu bauen.

Und mit eben einer solchen HTA gelang es mir vor etwas über 10 Jahren Windows PE basierte Setups zu erstellen.

“Sicher” war der Internet Explorer bekanntlich nie. Und wenn man schon keine sicheren Seiten damit bauen konnte, dann zumindest funktionsreiche.

So stelle ich mir vor, wie Microsoft damals dachte und HTAs waren ein Resultat davon.
Die Idee war einfach: Man fügt eine XML Zeile in den HTML-Kopf ein und speichert die Datei mit der .hta Endung.
Sobald man diese doppelklickt, startet der “HTA Host” und erzeugt ein Browserfenster gemäß den Optionen im XML-Teil.

Der Content wird wie im Browser durch reguläres HTML erzeugt und darf auch alle Features wie Javascript und CSS nutzen.
Man hat quasi einen Browser ohne Browsermenü.

Zusätzlich hat man per Scripting-Host und Active-X auch Zugang zu allerlei lokalen Ressourcen und kann per JScript und VBScript jede Menge Systemoperationen auslösen, wie z.B. auch Prozesse starten.

HTA Demo App

 1<!-- my_app.hta -->
 2<html>
 3<head>        
 4  <title>My Main Window Title</title>
 5        
 6  <hta:application id="myGlobalJSobject" 
 7    applicationname="My application title" 
 8    border="dialog"
 9    caption="yes"
10    contextmenu="no"
11    icon="img/my_app_icon.ico"
12    maximizebutton="no"
13    minimizebutton="no"        
14    navigable="no"
15    scroll="no"
16    selection="no"
17    showintaskbar="yes"
18    singleinstance="yes"
19    sysmenu="yes"
20  ></hta>
21
22  <style>
23    body { width: 700px; height: 500px; } /* app window size */
24  </style>        
25  <link rel="stylesheet" type="text/css" href="my_styles.css" />
26  <script Language="JavaScript" src="my_scripts.js"></script>
27</head>
28<body>
29  My HTML based content rendered in HTA's app window
30</body>
31</html>

JScript und VBScript

Mit Aufrufen wie GetObject("object-moniker")
oder new ActiveXObject("com-class-moniker") konnte man den Windows Script Host anwerfen und mit eben diesem quasi alles andere auslösen.

z.B. 0815 UI Features, wie etwa die Ermittelung der Bildschirmgröße um das eigene Fenster anzupassen:

 1var wmi = GetObject("winmgmts:\\\\.\\root\\cimv2");
 2var monitors = wmi.ExecQuery("Select * From Win32_DesktopMonitor");
 3var scrWidth = 0;
 4var scrHeight = 0;
 5for(var monitor = new Enumerator(monitors); !monitor.atEnd(); monitor.moveNext())
 6{
 7  scrWidth = monitor.item().ScreenWidth;
 8  scrHeight = monitor.item().ScreenHeight;
 9  break;
10}

Andere Programme ausführen:

1shell = new ActiveXObject("WScript.Shell");
2shell.run("c:\\path\\to\\my.exe my_arg1 my_arg2", 0, true);

Mit lokalen Dateien arbeiten:

1var fso = new ActiveXObject("Scripting.FileSystemObject");
2var temp_folder = fso.GetSpecialFolder(2);
3var temp_file = temp_folder + "\\my_file.txt";
4var strm = fso.CreateTextFile(temp_file, true);
5strm.Write("My Content");
6strm.Close();

HTAs als Virus

Der Tod von HTAs lag in “ihrer Macht”. Denn schnell fanden Schurken heraus, dass HTAs gleich mächtig wie die früheren .VBS Scripts waren, nur dass diese anfangs wieder durch diverse Virenfilter durchrutschten.

Letztendlich waren .hta bald als genau so “böse” abgestempelt wie Active-X. Und mit dem Ende des Internet-Explorers verschwand diese Technologie genau so schnell, wie sie eingeführt wurde, da bereits ab dem IE 9 die Ausführung nur noch sehr eingeschränkt möglich war und mit 100en Viren-Warnungen zugeklebt wurde.

HTAs in Windows PE

Interessant ist, dass Windows PE bis heute mit einem HTA-Modul ausgeliefert wird. Integriert man dieses in sein Win-PE Image, können HTAs direkt ausgeführt werden. Und in dieser Umgebung fehlen dann all die Sicherheitswarnungen, die im regulären Windows beim Start einer .hta auftreten würden.

Inspiriert von dieser Vorlage, entschied ich mich 2011 dafür, ein Windows Embedded 7 Setup auf einer HTA aufzubauen.
Es sollte den Benutzer durch ein paar Menüs führen, wo er zwischen installierbaren Windows Images und Updates auswählen konnte.
Im Hintergrund wurden dann einfach diskpart und imagex ausgeführt um die gewünschten Optionen auf die Festplatte zu übertragen.

Bis heute bin ich auf diese Lösung ein bisschen stolz, weil ich in wenigen Stunden ein grafisch anschaubares “Setup” für Endkunden bauen konnte, ohne gleich zu schweren Waffen wie C++ greifen zu müssen.

Fazit

Falco meinte ja einmal:

In Wien mußt’ erst sterben, damit sie dich hochleben lassen.

… und zumindest in meiner kleinen Wiener Wohnung bleibe ich dem Motto nun treu und ernenne HTAs posthum zu einer bemerkenswerten Technik.

Ich frage mich, ob diese Software weiter verbreitet worden wäre, hätte sie nicht der Microsoft Konzern eingeführt, der (nicht ganz zu Unrecht) seit dem Jahr 2000 in der Kritik stand und daher aus Prinzip abgelehnt wurde.
Tatsächlich waren HTAs schon in Windows 98 im IE5 integriert und waren damit 10 Jahre vor Google, Chromebooks und iPhones in der Lage, “produktive Apps” mit HTML zu erstellen.

Fremden HTAs würde ich natürlich auch nicht vertrauen …
Aber meine eigenen liebe ich (fast) genau so, wie meine anderen C++ Kinder.

Atom D2550/D2700

2022-07-31T13:00:00+02:00

Als nach der Pineview Serie (ich nutzte zuvor einen D510) die Cedarview Serie von Intel Atom Boards in den Handel kam, kaufte ich mir die Modelle D2550 und D2700 als Test-Client und als meinen neuen Home-Server.

Leider sind diese Modelle bis heute ein Lehrbeispiel dafür, wie man ein System nicht gestalten sollte.
(Aber das passt ja perfekt zu mir: Nämlich mit schlechten Systemen zu arbeiten.)

Da baute Intel also vor 10 Jahren einen Nachfolger des Atom D510 (45nm, 13 Watt TDP) mit der damals neueren 32nm-Fertigungstechnik und nur 10 Watt TDP.

Und 3 Watt weniger Strom ist ja “ur-viel” und “super-geil”, also war der D2700 auch schon gekauft. Das Board hieß D2700MUD und es muss wohl um das Jahr 2013 gewesen sein.

D2700: Server Installation N-mal

Zuerst dachte ich, es ist so weit, ich steige von Server 2003 auf 2008 (R2) um, primär um Hyper-V einzusetzen. Doch Fehlanzeige, denn der Prozessor besaß keinen VT-x Support und ließ Hyper-V Dienste nicht hochstarten. Womit ich wieder zum Server 2003 mit Virtual Server 2005 zurückkehrte.

Die nächste Ernüchterung setzte bei mir erst nach der Server 2003 (x64) Installation ein, als ich einen passenden Grafik-Treiber einspielen wollte.
Der war auf der Webseite nicht vorhanden, sondern dort gab es nur einen Windows 7 (32 bit) Treiber.

Dann erst las ich die Doku und stellte fest, dass ich zwar einen 64-Bit Prozessor gekauft hatte, Intel aber nur Treiber für Windows 7 32-bit geschrieben hatte und keinen weiteren Plattform-Support anbot.
Das Teil heißt: “Intel(R) Graphics Media Accelerator 3600 Series” und hat folgende Hardware ID: PCI\VEN_8086&DEV_0BE2&SUBSYS_20148086&REV_09.
Siehe: https://www.intel.com/content/www/us/en/support/articles/000005823/graphics.html

Man musste also entweder ein 32-Bit Windows 7 installieren oder man freundete sich mit dem Standard VGA-Treiber mit seinen 4:3 Formaten auf den 16:9 Bildschirmen an.

Eigenes Treiber INF zusammenstellen

Ich ging den dritten Weg, installierte nochmal Windows 2003 aber diesmal mit 32 Bit und lud dann von Intel einen eigenen Treiber-Baukasten herunter, mit dem man den 32-Bit Treiber für Windows XP/Server 2003 anpassen konnte.

Das Paket heißt IEMGD (Intel Embedded Media and Graphics Driver) for Intel Atom Processor N2000 and D2000 Series.
Hintergrund war vermutlich Windows XP Embedded 2009 und Windows CE, welches damals noch häufiger auf Industrie-Terminals zu finden war.

Zuerst musste man eine Konfiguration anlegen um die unterstützten Ports (z.B.: VGA und HDMI) einzubinden. Und danach war nur noch die Auswahl der Zielplattform zu treffen.

Der Menüpunkt Generate Installation kopiert alle notwendigen Treiberdateien installationsbereit (samt INF Datei) zusammen.
Und das funktionierte tatsächlich recht gut, womit ich am Ende mit vollem Grafik-Support unter Server 2003 arbeiten konnte.

D2550, der kleine Bruder

Irgendwie dachte ich mir, ich müsste auch noch ein “moderneres” Windows XP besitzen und kaufte mir dann auch noch das Geschwister-Mainboard D2550MUD2 mit dem D2550 Atom Prozessor. Der ist ein paar hundert Megahertz langsamer als der D2700, aber sonst identisch.

Und natürlich gab es mit diesem Teil die gleichen Probleme mit der Grafik.

Crashgefahr ab Windows 8

Für kleine Aufgaben (SSH, Mail, Webrequests, VPN) arbeitet das alte Atom Board bis heute bei mir, wenn ich meinen “Hauptrechner” nicht extra starten möchte.
Versuche auf Windows 8 oder Windows 10 zu wechseln scheiterten aber an einem interessanten Detail: Die Grafik schmiert ab, sobald Windows Store Apps geladen werden.

Ich vermute mal, dass die Direct-X Implementierung des Windows-7 Treibers fehlerhaft ist oder Windows 8 im Treiber nicht vorhandene Features benötigt. Denn immer wenn eine Store-App im Vollbild geöffnet wird, ist ein Bluescreen “vorprogrammiert”.

Win32 Apps und Spiele funktionierten allerdings auch unter Windows 8 in meinen Tests.
However … nachdem ich aber kein instabiles System haben wollte, wechselte ich wieder zu Windows 7 und bin damit bis heute glücklich.

Fazit

Die Atom D2000 Serie ist ein Beispiel dafür, wie man Prozessoren nicht vermarkten sollte. Denn alle Vorgänger und Nachfolger nutzten Intel-Grafikchips für die unter Windows und Linux ausreichend Treiber und Knowhow zur Verfügung stand.
64-bit wegen der Grafik auszuschließen ist für ein Produkt aus dem Jahr 2012 unsinnig und kam auch bei der Community nicht gut an.

Die Lösung wäre gewesen, den Sourcecode zu veröffentlichen, doch auch dazu ließ sich Intel trotz vieler Support-Anfragen nicht überreden.

Naja … ich nutze meine beiden D2550MUD2 und D2700MUD Boards jedenfalls weiter mit Windows 7 für Kleinkram und Server 2003 mit Virtual Server.

Echt Schade, dass man daraus nicht mehr machen kann … aber so ist das Leben bzw. Intel manchmal.

Virtual Server 2005

2022-07-30T13:00:00+02:00

Mit Server 2008 stieg Microsoft “richtig” ins Virtualisierung-Geschäft ein und schuf das erste Windows mit eingebautem Hyper-Visor Kern.

Doch tatsächlich gab es Virtualisierung schon vorher aus dem Hause Microsoft. Und obwohl diese Produkte gegenüber VM-Ware und andere Lösungen “abstanken”, erinnere ich mich noch gerne an Zeiten von Virtual PC und “Virtual Server 2005” zurück.

Microsoft übernahm Anfang der 2000er eine Firma namens Connectix und formte deren Virtualisierungsprodukt in “Microsoft Virtual PC” um. Damit wurde es möglich unter Windows (2000 und XP) ein anderes Gastbetriebssystem in einer virtuellen Umgebung laufen zu lassen.

Gedacht war das ganze für Entwickler und Software-Tests mit älteren Betriebssystemen und nachdem Intel’s VT-x Befehlssatzerweiterung für Virtualisierung gerade im Entstehen war, und kein damalig Consumer-Prozessor ihn anbot, wurde Virtualisierung auf Softwareebene durchgeführt.

Das war zwar langsam, aber da die alten Windows XP und älteren MS Betriebssysteme auch verhältnismäßig klein waren und auch mit 256 MB RAM auskamen, konnte ich auf meinen damaligen Systemen mit 2 GB RAM auch noch eine oder zwei VMs ausführen lassen um zu sehen, ob Programme auch noch unter NT-4 oder Windows 98 lauffähig waren.

Großer Nachteil von “Virtual PC” war, dass es ein UI Programm war, das man manuell starten musste um danach die VMs ebenso manuell starten zu können.

Doch für den professionellen Einsatz gab es dann die Server Variante, namens “Virtual Server 2005”.

Virtual Server 2005 und sein “Web”

Dieses Produkt war eine Erweiterung von “Virtual PC” und lief als Dienst auf einem Windows Server 2003 (32 und 64 bit).
Die Administration der Software erfolgte in erster Linie über eine HTTP Webseite im Browser … schlimmer noch … exklusiv nur im Internet-Explorer.
Jedenfalls brauchte man einen damaligen IIS (Internet Information Server) vorinstalliert und das Setup legte eine Konfiguration für den Standard-Port 1024 an, wo die Admin-Seiten laufen sollten.

Und die Fehlentscheidung “Internet-Explorer” ist vermutlich der Grund dafür, dass ich damit einige schlechte Erfahrungen machte.
Denn vermutlich um Konkurrenz-Browser zu behindern setzte die Admin-Seite intensiv auf Javascript und dynamischen Content (eigentlich progressiv für damals), nutzte jedoch viele Internet-Explorer Erweiterungen, die keinem Standard entsprachen.

Und so kam es, dass bereits wenige Jahre später mit dem IE-7 und IE-8 Teile der Admin-Seiten nicht mehr richtig funktionierten, wenn man nicht einzelne Features im Kompatibilitätsmodus ein/ausschaltete.
Und mit dem IE9 strich Microsoft dann auch noch viele Erweiterungen vollständig, womit die Serversoftware unbenutzbar wurde.
Andere Browser versagten von Anfang an den Javascript-Content anzuzeigen und deshalb nenne ich den “Virtual Server 2005” immer als Beispiel für die schlechtest mögliche Representation eines Dienstes im Web.

However … wenn man brav beim IE-6 bleibt, sieht das Web-Interface recht “OK” aus. Man kann neue Maschinen anlegen und Einstellungen per Webformular anpassen. Alles unter der Einstiegsseite:
http://HOSTNAME_OR_IP:1024/VirtualServer/VSWebApp.exe

Läuft eine Maschine, kann man sich über ein Active-X Plugin im Browser “hineinverbinden”.
Tastaturanschläge werden korrekt übermittelt, wenn das Remote-Frame im Browser den Fokus hat.

Allerdings sollte man während der Installation nie in das Fenster klicken und die Maus bewegen. Denn diese Übersetzung ist (im DOS-Modus) gebrochen und kann eine Installation verhindern, wenn intern ein Fokus wegen der Maus verloren geht und dieser dann nicht wiedergewonnen werden kann.
(Es kann natürlich auch sein, dass das nur die Steuerung über RDP betrifft, denn ich bin stets über RDP zur Maschine verbunden, in der Virtual Server und der IE6 läuft.)

Am Ende aktiviert man dann das CD-Image der Virtual-Server Plugins und installiert Treiber für die “virtuelle Umgebung”. Ab da kann man dann auch die Maus gefahrlos über das Active-X-Webfenster nutzen. Oder man installiert gleich ein OS, das man per Netzwerk erreichen und fernwarten kann, denn die virtuelle Netzwerkkarte macht es möglich.

COM Interface

Die vermeintliche Rettung aus dem Web Chaos war tatsächlich eine meist recht unbekannte alternative COM Schnittstelle. Als Vorbereitung initialisiert man COM mit

1CoInitializeSecurity(NULL, -1, NULL, NULL, 
2                     RPC_C_AUTHN_LEVEL_PKT_PRIVACY, 
3                     RPC_C_IMP_LEVEL_IMPERSONATE, 
4                     NULL, 
5                     EOAC_DYNAMIC_CLOAKING,  
6                     NULL);

und dann erzeugt man eine Instanz der COM Klasse VMVirtualServer über die Class-ID CLSID_VMVirtualServer (DA3111BC-1BD7-4884-A535-8470D36028F7) und landet beim Interface IVMVirtualServer (D1E64C50-A25D-450f-BE0B-9CA5A354CFF4).

Die anderen Schnittstellen sind im Header
C:\Program Files\Microsoft Virtual Server\Documentation\VSComInterfaces.h enthalten.
Viele Methoden sind recht selbsterklärend (wie z.B. CreateVirtualMachine), jedoch stellt die große Anzahl von Schnittstellen zu Unterobjekten eine Herausforderung dar.

Vielleicht finde ich ja mal irgendwann Zeit alle Details ins GATE Framework aufzunehmen, denn diese Schnittstelle ist (analog zu ADSI) sicher ein schönes Beispiel, wie man einen Dienst über eine Service-API zugänglich machen kann.

Fazit

Der Nachfolger Hyper-V machte grundsätzlich vieles richtig. Er integrierte seine Verwaltung in WMI, womit sie automatisch in WinRM und Powershell verfügbar war. Außerdem war der Hyper-Visor im Kern des Betriebssystems und damit gut integriert, während der Vorgänger nur einen Netzwerktreiber im System einspeiste und der Rest im Dienstprozess errechnet wurde.

Dennoch verdanke ich “Virtual PC” und “Virtual Server” so einiges. Ich erarbeitete damit Softwarekompatibilität für ältere Windows NT, 2000 und sogar Windows 98 Systeme, die bis 2010 eine “Kundenanforderung” waren.
Und auch privat erfreute ich mich daran, Windows 3.11 und DOS darauf halbwegs vernünftig laufen lassen zu können.

Hyper-V 2008 begann seinen Support erst mit Windows 2000 und war anfangs für meine Zwecke einfach “zu neu” und auch generell muss ich sagen, dass auf älteren Systemen diese Form die Virtualisierung einfach funktioniert, während andere Dienste wie VirtualBox wesentlich mehr Ressourcen fressen und damit auf meinen älteren Systemen unbenutzbar werden.

Und so läuft seit langem auf einem meiner älteren Intel Atom Rechner immer noch ein Server 2003 mit “Virtual Server” bei mir zu Hause …

… und wenn der nicht gestorben ist, dann läuft er noch heute.

DOS API Aufrufe

2022-07-24T13:00:00+02:00

Heute bringen die meisten Programmiersprachen “alles” mit, was notwendig ist um alle möglichen Formen von Programmen, UIs und Spielen zu bauen. Doch zu DOS Zeiten, war man auf die C Standardbibliothek und einfache Text Ein- und Ausgaben beschränkt.

Den Spielraum konnte man sich mit direkten Aufrufen von Interrupt Service-Routinen erweitern, darunter vor allem der int 21h mit allen DOS Funktionen.

Leider war das alles andere als “standardisiert” und trotzdem verfolgten die Sprachen ähnlichen Ansätze.

Integration von Inline-Assembler

C und Pascal Compiler erlaubten im normalen Programmfluss Assembler Codes einzuschleusen. Man öffnete einen asm Block und schrieb dort die Intel Syntax der X86 Anweisungen, oder sogar direkt den Bytecode des Prozessors.

Doch diese Non-Standard Erweiterung änderte sich stets und vor allem die Interaktion zwischen Variablen und Konstanten der eigentlichen Sprache war unterschiedlich. Ich weiß bis heute nicht auswendig, wo man nun Variablen in eckige Klammen setzen muss und wo nicht, oder ob Stack-Variablen und globale anders behandelt werden mussten.

Und wenn dann noch Turbo C den Code an den externen Turbo Assembler auslagerte, war fraglich, ob der überhaupt installiert war.

Aufruf von Interrupts über Standard-Funktionen

Ein Alternative musste her, und diese war eine spezielle Funktion, die die Assembler-Magie im Hintergrund durchführte. Man befüllte eine Struktur deren Member die CPU-Register abbildeten und rief ebendiese Funktion auf, die DOS oder andere Interrupt nutzte und das Ergebnis war ein neuer Satz an Register-Variablen in der zurückgegebenen Struktur.

In den nachfolgenden Beispielen nutze ich die DOS Funktion ah=0x30, die die DOS-Version im Register AX zurückgibt, und zwar AL mit der Hauptversion und AH mit der Nebenversion:

Turbo C, OpenWatcom

Im dos.h Header befindet sich die Funktion intdos(in_regs, out_regs) um DOS Funktionen mit union REGS Parametern aufzurufen.
Zusätzlich existiert noch int86(int_nr, in_regs, out_regs) um jeden beliebigen Softwareinterrupt aufzurufen.

 1#include <dos.h>
 2
 3void getDOSversion(int* major, int* minor)
 4{
 5  union REGS in_regs, out_regs;
 6  in_regs.h.ah = 0x30;
 7  in_regs.h.al = 0x00;
 8  /*in_regs.x.ax = 0x3000;*/
 9  intdos(&in_regs, &out_regs);
10  *major = (int)out_regs.h.al;
11  *minor = (int)out_regs.h.ah;
12}
13
14int main()
15{
16  int major, minor;
17  getDOSversion(&major, &minor);
18  printf("DOS v%d.%d\n", major, minor);
19  return 0;
20}

Turbo Pascal

Turbo Pascal stellte in seinem DOS Modul die Funktion MsDos(regs) für DOS Funktionen bereit und mit Intr(intNo, regs) kann man jeden beliebigen Interrupt nutzen. Hier gibt es nur einen Registers-Parameter, der gleichzeitig Input ist und danach zum Output wird.

 1PROGRAM dosver;
 2USES dos;
 3
 4PROCEDURE getDOSversion(var major: WORD; var minor: WORD);
 5VAR
 6  regs: REGISTERS;
 7BEGIN
 8  regs.ah := $30;
 9  regs.al := $00;
10  {regs.ax := $3000;}
11  MsDos(regs);
12  major := regs.al;
13  minor := regs.ah;
14END;
15
16VAR
17  maj, min: WORD;
18  text: STRING;
19BEGIN
20  getDOSversion(maj, min);
21  write('DOS v');
22  str(maj, text);
23  write(text);
24  write('.');
25  str(min, text);
26  writeln(text);
27END.

QuickBasic DOS Interrupt Aufruf

Startet man QuickBasic (4.5+) mit QB.EXE /L, stehen Zusatzbibliotheken zur Verfügung, die man über das Metakommando
REM $INCLUDE: 'file' einbinden kann.
Und QB.BI definiert die Funktion INTERRUPT und den RegType Typ, der Registerzustände an die Funktion leiten soll, die wiederum einen Softwareinterrupt damit aufruft. So kann man jeden Interrupt aufrufen, und natürlich auch 21h.

 1REM $INCLUDE: 'QB.BI'
 2DECLARE SUB getDOSversion (major AS INTEGER, minor AS INTEGER)
 3
 4DIM major AS INTEGER
 5DIM minor AS INTEGER
 6
 7getDOSversion major, minor
 8
 9PRINT "DOS v";
10PRINT USING "#"; major;
11PRINT ".";
12PRINT USING "#"; minor
13
14SUB getDOSversion (major AS INTEGER, minor AS INTEGER)
15  DIM inreg AS RegType
16  DIM outreg AS RegType
17  inreg.ax = &H3000
18  CALL INTERRUPT(&H21, inreg, outreg)
19  major = outreg.ax AND &HFF
20  minor = CINT(outreg.ax / 256)
21END SUB

Der mit DOS mitgelieferte QBASIC.EXE Interpreter unterstützt CALL INTERRUPT nicht. Theoretisch gäbe es aber die Möglichkeit mit POKE Assembler-Bytes in den Speicher zu schreiben und dann per
CALL ABSOLUTE die Funktion aufzurufen … aber soviel DOS-Hackerei tut sich heute keiner mehr an.

Fazit

Der große Nachteil dieser direkten Interrupt-Aufrufe liegt in der Unmöglichkeit der Portierbarkeit. Denn die Register sehen ja auf jeder CPU anders aus.
Definierte APIs sind die Lösung und davon haben wir heute nur 2 große Vertreter: die WinAPI und POSIX parallel zur C-stdlib.

Tja, deshalb brauche ich eine Zeitmaschine, um mein heutiges Wissen 25 Jahre in die Vergangenheit zu senden. Denn oft habe ich mühsam ganze Programme in Assembler verfasst, nur weil ich ein paar Interrupt bzw. DOS Funktionen aufrufen wollte. Dass man das auch einfacher tun kann, lernte ich erst, als ich DOS nicht mehr wirklich brauchte und auch nicht mehr damit programmierte.

Aber … Wissen schadet nicht.
Im Gegenteil, es ist interessant zu sehen, wie sehr sich die 3 “Hauptsprachen” C, Pascal und Basic ähneln was Interrupts unter DOS anbelangt.

Toshiba T300 - Teil 2

2022-07-23T13:00:00+02:00

Und wieder einmal musste ich mich davon überzeugen, dass mein Toshiba T-300 noch läuft.

Diesmal sah ich meine alten Disketten durch, ob ich vielleicht noch ein paar Infos über das Gerät aus dem Jahr 82/83 erhalten kann.

Der Boot Vorgang

Im Hitchhiker’s guide to the galaxy steht bekanntlich das beruhigende

Don’t panic

an erster Stelle.
Und irgendwie wurde ich daran erinnert, als ich das Gerät wieder einschaltete und am Bildschirm sofort die Worte

WAIT A MINUTE

erschienen.
Schließlich braucht die Maschine (in Wahrheit nur 20 Sekunden) um warm zu laufen und ein komplexes BIOS mit RAM-Tests und vielen anderen Infos gab es damals nicht.

Danach schaltet sich das Diskettenlaufwerk ein und versuchte von Laufwerk A zu booten, was ebenso mit

PROGRAM LOADING

kommentiert wird.

Nach weiteren 10 bis 15 Sekunden, sieht man bereits, wie MS-DOS 2.0 seinen COMAMD.COM Prozess startet und danach CONFIG.SYS und AUTOEXEC.BAT abarbeitet.

1TOSHIBA Personal Computer (UO200)
2
3MS-DOS version 2.00
4Copyright 1981,82,83 Microsoft Corp.

Diskettenformat

Ich erwähnte bereits, dass der T300 ein nicht IBM-konformes Diskettenformat einsetzt und wesentlich mehr Daten auf den alten 5.25 Zoll Floppies unterbringt.

Mit dem FORMAT B: Aufruf, konnte ich das jetzt nochmal nachstellen.

 1A:\>format b:
 2
 3Insert new diskette for drive B:
 4and strike any key when ready
 5
 6Formating ... Track No.(79) Head No.(1)
 7Format complete (2DD type)
 8
 9Volume label (11 characters, ENTER for none)?
10
11  649216 bytes total disk space
12  649216 bytes available on disk
13
14Format another (Y/N)?

Eine übliche IBM 2D (Double density) wird in der Regel mit 40 Tracks (Spuren) und 9 Sektoren auf zwei Seiten zu je 512 Bytes formatiert.
Daraus ergeben sich dann 368 640 Bytes, also 360 KB.
Es gab aber auch eine ältere Formatierung mit nur 8 Sektoren, die sich in neueren DOS-Version mit format /8 erreichen ließt, die dann auf 327 680 Bytes, also 320 KB kam.

Und offenbar verdoppelte Toshiba einfach die 40 auf 80 Tracks und blieb bei den 8 Sektoren um auf 655360 Bytes oder 640 KB zu kommen.
Zieht man davon 6 KB für Bootsektor und FAT-Infrastruktur ab, kommt man nämlich genau zu den 649216 Bytes oder 634 KB, die FORMAT.COM am Ende für Nutzdaten meldet.

Eine so formatierte Diskette konnte mein “normales” 5.25 Zoll Laufwerk unter Windows nicht mehr lesen und beschwerte sich, dass “Spur Null” nicht gefunden werden kann.
Das ist deshalb bemerkenswert, weil das gleiche Laufwerk die moderneren HD (High-Density) Disketten mit 1.2 MB problemlos lesen und formatieren kann, wobei die mit 80 Tracks und 15 Sektoren formatiert sind.

Doch wenn man unter Windows eine Diskette mit 360 KB formatiert (heute FORMAT A: /T:40 /N:9, früher unter DOS FORMAT A: /F:360), dann kann sie vom Toshiba T300 problemlos gelesen und beschrieben werden.

Die Toshiba Formatierung mit FORMAT B: /2 erzeugt wiederum eine 320 KB Speicherdichte und meldet dann am Ende: Format complete (2D type).

2D ist also das IBM kompatible Format und 2DD Toshibas Verdoppelung.

System Kopieren

Das wirklich nervige ist, dass FORMAT /S zum Kopieren des Betriebssystems nur Toshiba-formatierte Disketten zuließ. Die weiß noch von früheren Tests, dass das an Toshiba angepasste MS-DOS die versteckten Systemdateien TBIOS.SYS und TDOS.SYS für den Boot anlegt.
Doch da in DOS 2.0 weder DIR /AS existiert noch COPY mit Systemdateien umgehen kann, sind diese Dateien für mich leider unerreichbar.

Alle anderen Programme inklusive COMMAND.COM konnte ich auf 360 KB Disketten kopieren und am PC archivieren, doch leider nicht den DOS-Kern selbst. Und leider verfüge ich auch gar nicht über ein vollständiges DOS für das Gerät. Meine Disketten waren nur ausgestattet mit:

COMP.COM zum Dateien vergleichen
DEBUG.COM der klassische DOS x86-ASM Debugger
DISKCOPY.COM Disketten kopieren Byte für Byte
EDLIN.COM Ein Zeileneditor für Texte
FDISK.COM für eine Festplatte, die nicht eingebaut war
FORMAT.COM zum Formatieren von Disketten
GRKBPRG.COM der deutsche Tastaturtreiber
LABEL.COM benennt eine Diskette um
LOGO.COM die Programmiersprache Logo
MODE.COM verändert Parameter der Ein/Ausgabe
MORE.COM zeigt Ausgaben seitenweise an
PRINT.COM druckt im Hintergrund
RECOVER.COM versucht ein defektes Dateisystem wiederherzustellen
RST.COM startet die Maschine neu
TBASIC.COM Toshiba Basic, ein GW-BASIC Klon

Andere Tools wie ATTRIB oder SYS fehlten. Ich selbst hatte vor 25 Jahren mal ein SYS.COM von DOS 3 auf eine der Disketten kopiert, nur um dort beobachten zu können, dass es nicht funktionierte und das System einfrieren ließ.

Ich vermute aber, dass ich mit Programmiersprachen wie Turbo Pascal 3 ein Tool wie ATTRIB recht leicht nachbauen können sollte, denn die DOS INT 21h Funktion AH=43h kann mit AL=01h Attribute ändern, und ich vermute, wenn TBIOS.SYS und TDOS.SYS zu normalen Dateien werden, dann kann COPY sie auch kopieren.

Und irgendwie glaube ich, dass es Taktik von Microsoft und/oder Toshiba war, dass man das Betriebssystem nur auf Disketten mit dem eigenen Datenformat übertragen konnte.

Fazit

Leider habe ich damals keine weitere Toshiba-Software gerettet und das bereue ich. Denn somit ist womöglich wieder ein Stück IT-Geschichte verloren gegangen.

Reine DOS-2-Software läuft vermutlich auf dem Gerät, doch viele Programme nutzten direkte Hardwarezugriffe oder neuere DOS-Versionen und sind somit nicht mit dem T-300 kompatibel.

Ich frage mich, ob es noch andere Besitzer eines solchen Gerätes gibt, und ob diese weitere Software dafür besitzen.

Sollte es mir doch noch gelingen, die gesamte Diskette zu “sichern”, plane ich, sie auf archive.org zu stellen … doch zur Zeit macht das wenig Sinn.

Variant in C++ 98/03

2022-07-17T13:00:00+02:00

Mit std::variant aus C++17 hat die standardbibliothek boost::variant integriert. Das Template ist mit C union Typen verwandt, bietet jedoch Typensicherheit und Eindeutigkeit.

Ich bin bekanntlich auf die alten Standards C++98 und C++03 fixiert und fragte mich daher, wie schwer es wohl sei, so etwas “quick & dirty” auch dort nachbauen zu können.

Mit C++11 kamen “variadic Templates” in den Standard womit man beliebig viele Typen an ein Template weiterreichen kann. Und diese kann man dann mit anderen Hilfstemplates durchlaufen und sich genau das daraus bauen, was man haben will.

Doch im originalen C++98 bzw. im Update 2003 gibt es dieses Feature nicht.

Idee

“Default template arguments” geben uns die Möglichkeit, ein Template mit Typen zu füttern, doch wenn wir weniger nutzen, werden die hinten fehlenden Argumente durch “defaults” ersetzt.

Meine Idee ist es daher ein Variant Template mit vielen Typen zu erstellen (10 sollten für die meisten Fälle ausreichen), wo jedoch ab dem zweiten ein Default-Typ gesetzt wird, der das Template Argument quasi als “ungültig” markiert.
Damit die “ungültigen” Argumente auch eindeutig identifiziert bzw. gezählt werden können, kann dieser InvalidType selbst ein Template sein, dessen Argument eine Zahl ist:

 1template<unsigned N>
 2struct InvalidType { };
 3
 4template<class T0, 
 5         class T1 = InvalidType<1>,
 6         class T2 = InvalidType<2>,
 7         class T3 = InvalidType<3>,
 8         class T4 = InvalidType<4>,
 9         class T5 = InvalidType<5>,
10         class T6 = InvalidType<6>,
11         class T7 = InvalidType<7>,
12         class T8 = InvalidType<8>,
13         class T9 = InvalidType<9>,
14  > class Variant { };

Im Inneren reservieren wir Speicherplatz für alle möglichen Typen mit:

 1union
 2{
 3  char  t0[sizeof(T0)];
 4  char  t1[sizeof(T1)];
 5  char  t2[sizeof(T2)];
 6  char  t3[sizeof(T3)];
 7  char  t4[sizeof(T4)];
 8  char  t5[sizeof(T5)];
 9  char  t6[sizeof(T6)];
10  char  t7[sizeof(T7)];
11  char  t8[sizeof(T8)];
12  char  t9[sizeof(T9)];
13  void* alignment_dummy;
14} content;

Jetzt kann man mit new (&content) Tx(source) bereits Objekte auf den content Speicher erzeugen … aber wie soll der Destruktor nun das richtige Objekt freigeben?

Im GATE Framework nutze ich für die C++-C Brücken C-Konstruktor und C-Destruktor Funktionen, die von C++ Templates generiert werden.

 1typedef void(*generic_copy_constructor)(void* dst, void const* src);
 2typedef void(*generic_destructor)(void* obj);
 3
 4template<class T> 
 5void cpp_copy_construct(void* dst, void const* src)
 6{
 7  T* cpp_dst = reinterpret_cast<T*>(dst);
 8  T const* cpp_src = reinterpret_cast<T const*>(src);
 9  new (cpp_dst) T(*cpp_src);
10}
11
12template<class T>
13void cpp_destruct(void* obj)
14{
15  T* cpp_obj = reinterpret_cast<T*>(obj);
16  cpp_obj->~T();
17}

Diese beiden Funktionszeiger kommen zusammen mit der std::type_info ebenfalls in den Variant und beschreiben somit, welcher Type gerade aktiv ist, und wie man ihn kopieren und zerstören kann:

1... 
2class Variant
3{
4private:
5  generic_copy_constructor content_cctor;
6  generic_destructor content_dtor;
7  std::type_info const* content_ti;
8};

Jetzt baut man noch Konstruktoren und Assignment Operatoren für jeden Template Typen ein, wie auch einen “getter”.

 1...
 2private:
 3  template<class T>
 4  void insert(T const& t)
 5  {
 6    new (&content) T(t);
 7    content_cctor = &generic_copy_constructor<T>;
 8    content_dtor = &cpp_destruct;
 9    content_ti = typeid(T);
10  }
11  void destruct()
12  {
13    content_dtor(&content);
14  }
15public:
16  Variant(T0 const& t) { insert(t) }
17  Variant(T1 const& t) { insert(t) }
18  ...
19  Variant& operator=(T8 const& t) { destruct(); insert(t); return *this; }
20  Variant& operator=(T9 const& t) { destruct(); insert(t); return *this; }
21
22  template<class T> T& get()
23  {
24    if(typeid(T) != *content_ti)
25    {
26      throw std::runtime_error("Invalid type");
27    }
28    return *reinterpret_cast<T*>(&content);
29  }

Und fertig ist der C++98 Variant. Das ganze Beispiel liegt auch im BLOG-Classroom vor.

Natürlich kann man jetzt den Code noch weiter ausbauen und die echte Konstruktion eines InvalidType verhindern lassen, damit man ihn nicht (un)absichtlich deklarieren kann.
Und man kann sich auch noch den Typen-Index merken, mit dem der Variant initialisiert wurde, um ihn (so wie bei std::variant) zurückliefern zu können.

Fazit

Das Codebeispiel ist nicht so effizient, wie es durch C++11 möglich wird, doch er tut so halbwegs das, was man von einem “Variant” erwartet.

Ich selbst nutze variant eher selten, doch kommt er mir in manch anderen Projekten stets unter.

Im GATE Projekt geht die ganze Sache natürlich noch einen Schritt weiter, wo ein gate_variant_t als C-Objekt genutzt wird, wo aber dennoch ein C++ Objekt dahinter verborgen sein kann. Dort hat man keine Templates und muss sich quasi alle typeid-Pointer mit den cctor/dtor Funktionen für jeden erlaubten Typen merken.

Und wieder gilt als erwiesen:

Wo ein Wille ist, da ist auch ein Weg.

Wikipedia

2022-07-16T13:00:00+02:00

Wikipedia zählt zu den ganz wenigen Projekten im Netz, denen ich vertraue ohne Details über die internen Abläufe zu kennen. Ich glaube, dass es DAS Vorzeigeprojekte schlichthin ist, wie eine freie Gesellschaft im Internet produktiv arbeiten kann.

Und wenn sie jetzt noch eine “bessere” Markup-Syntax für ihre eigenen Seiten hätten (z.B. Markdown), dann würde ich dort auch mehr beitragen.

Vorgeschichte

Als ich den Blog startete, ging es mir primär um:
Dokumentation meiner Lebenserfahrung.

Doch am Ende der Themenbeschreibungen dachte ich daran, was wohl passiert, wenn ein interessierter Nutzer zufällig bei der Seite vorbeikommt, zu lesen beginnt und schon nach wenigen Sekunden “aussteigt”, weil er mit einigen Vokabeln nichts anfangen kann.

Lösung: Man verlinkt solche Wörter mit Seiten, die sie erklären.

Wenn ich nun aber Herstellerseiten von Software verlinke, dann werden diese Links alle paar Jahre ungültig, weil auf ein neues CMS umgestellt wird, oder der Anbieter die Domäne wechselt oder diese sogar vom Netz nimmt.

Beste Lösung: Ich nutze wann immer es geht Wikipedia, denn dieses seit 20 Jahren existierende Projekt pflegt “das Wissen der Menschheit” in einem standardisiertem Format und zahlreiche Nutzer sorgen auch bei Verschiebungen von Informationen zwischen Seiten, dass die früheren Begriffe zu neuen Seiten umgeleitet werden.

Wie wird man zum Wikipedia Author?

Es ist ganz einfach: Man registriert sich mit Email-Adresse, Usernamen und Passwort bei Wikipedia. Ab sofort kann man Änderungen durchführen und neue Seiten anlegen.
Jede neue Änderung wird als “Ungesichtete Änderung” deklariert. Kommen Nutzer zur Seite, sehen sie den alten Zustand, können aber oben im Tab Ungesichtete Änderungen den neuen Text lesen oder in Versionsgeschichte zwischen den Updates hin und herwechseln.

Erst wenn ein Mitarbeiter des offiziellen Wikipedia Teams den Text gelesen und bestätigt hat, wird er zur “aktuelle Version” hinauf gestuft.
Natürlich kann er auch abgelehnt werden, und das geschieht meiner Erfahrung nach nur dann, wenn der Text nicht dem Charakter einer Enzyklopädie entspricht.

Man soll

über allgemeine Dinge berichten (und nicht etwa über den Lebenslauf seines Haustieres schreiben)
keine Lehrbücher verfassen sondern eine mögliche kurze und aussagekräftige Themenbeschreibung abgeben.
keine persönlichen Meinungen oder andere subjektive Attribute einfließen lassen.
bestehende Seiten erweitern und nicht ständig neue Begriffe einzuführen.
alle Texte selbst verfassen und keinesfalls Textpassage kopieren (außer sie werden als explizites Zitat markiert)
Jede Äußerung mit einer Quelle belegen, also einer anderen Internetseite, die das Thema behandelt und sachlich beschreibt.

Das Anlegen neuer Seiten wird grundsätzlich nicht so gerne gesehen, denn nachdem Wikipedia eine so unglaublich große Datenmenge beinhaltet, kann man davon ausgehen, dass schon fast alles einmal erwähnt wurde und das ist auch oft so.
Man denkt ein Thema würde fehlen, schreibt einen Artikel und dann stellt sich heraus, dass genau das gleiche schon als Absatz in einem Überbegriff beschrieben wurde. Ab wann eine Aufspaltung durchgeführt werden soll und wann nicht, ist oft Diskussionsthema und lässt sich im Tab “Diskussionen” nachverfolgen, wo ebenso jeder mitdiskutieren kann.

“Spezieller” Syntax

Wikipedia nutzt intern eine eigene Auszeichnungssprache namens Wikitext, in welcher man Links oder Formatierungen mit speziellen Zeichen ausdrücken kann.
z.B.:

Überschriften werden mit = Zeichen ummantelt, mehrere Gleichheitszeichen definieren untergeordnete Überschriften, z.B.:
= Überschrift =

Listen werden mit Sternen definiert, z.B.:

1* Element 1  
2** Unterelement 1.1  
3* Element 2

Formatierungen für kursive und fette Satzteile mit Hochkommata, z.B.:

1So sieht ein ''kursiver'' Text aus,  
2so ein '''fetter''' 
3und so ein ''''kursiver und fetter'''' Text

Links werden mit [[]] Klammern ummantelt, z.B.:

1Hier ein Link zur [[Wikipedia]] Seite intern.  
2Hier ein externer Link: [https://www.duckduckgo.com DuckDuckGo]

Doch wenn es um Tabellen geht, bin ich enttäuscht, die sehen nämlich so aus:

 1{|
 2|+
 3!Spaltenkopf 1
 4!Spaltenkopf 2
 5|-
 6|Zeile 1, Spalte1
 7|Zeile 1, Spalte2
 8|-
 9|Zeile 2, Spalte1
10|Zeile 2, Spalte2
11|}

Das gleiche sieht in Markdown so aus:

1| Spaltenkopf 1     | Spaltenkopf2     |
2|-------------------|------------------|
3| Zeile 1, Spalte 1 | Zeile1, Spalte 2 |
4| Zeile 2, Spalte 1 | Zeile2, Spalte 2 |

Und? Was ist jetzt übersichtlicher ??

Ich verstehe schon, dass es in Markdown bei vielen Spalten auch zu überlangen und Zeilen kommt, aber dann hat man vielleicht auch zu viele Daten in seine Ansicht gequetscht.

Zum Glück gibt es heute einen Online-WYSIWYG Editor, wo man Tabellen per Maus Menü erstellen kann … aber bei manchen Details muss man dann doch wieder den nativen Quellcode anpassen.

Ich brauchte neulich jedenfalls verdammt lange, eine Seite mit Prozessor Modellen zu aktualisieren, weil ich meine lokal vorbereitete Textliste nicht einfach in Wikipedia einfügen konnte. Am Ende musste ich Zelle für Zelle neu schreiben.

Also hier würde ich mir “Optimierungen” wünschen … weiß aber gleichzeitig, dass man so ein großes System nicht so einfach umstellen oder erweitern kann.

Fazit

Tut was für Wikipedia!

Diesen Aufruf kann ich immer nur wiederholen, denn jeder, wirklich jeder, nutzt Wikipedia. Angefangen bei der Wahl des Urlaubszieles bis hin zum Nachschlagen von mathematischen Formeln.

Man kann immer wieder mal ein paar Euro spenden um den Betrieb zu unterstützen und noch besser ist es, im eigenen Fachbereich mal auf diversen Seiten die Qualität zu heben.

Ich maße mir auch nicht an, dort große Artikel zu schreiben, aber wenn es darum geht, Daten nachzutragen oder Beschreibungen mit Weblinks zu belegen, dann kann jeder seinen Beitrag leisten um dieses vermutlich größte freie Projekt auf dem Planeten zu verbessern, damit alle noch möglichst lange ihren Spaß damit haben und … noch wichtiger: viel daraus lernen.

C Function Overloading

2022-07-10T13:00:00+02:00

In C kann eine Funktion genau eine Signatur haben, während in C++ unter einem Funktionsnamen mehrere Implementierung möglich sind. Der Compiler adressiert die richtige basierend auf den Datentypen beim Aufruf.

Aber mit ein paar Makro-Tricks, kann man zumindest bei der Anzahl der Parameter ein bisschen C++ Overloading in den alten C Standard übertragen.

Variadic Macros

Makros können so wie auch variadic Funktionen mit einer undefinierten Anzahl von Parametern aufgerufen werden. Das Makro kann aber dann nicht mehr damit tun, als diese Parameter “weiterzuleiten”.

Das klassische Beispiel dafür sind printf Adaptionen:

1#define my_printf(format, ...)  printf(format, __VA_ARGS__)
2
3int main()
4{
5  my_printf("%s %s\n", "Hello", "World");
6  my_printf("%s\n", "Bye!");
7  return 0;
8}

Und nun eine verrückte Frage:

Was wäre, wenn ein Makro eine Funktion simuliert und je nach Anzahl der Parameter eine andere Funktion aufruft?

Argumente mit Makros zählen

Man findet im Netz einen interessanten Trick, mit dem man per Makro die Anzahl der Argumente des Aufrufs zählen kann.
Mit dieser Zahl kann man dann einen Aufruf auf einen zusammengesetzten Funktionsnamen umleiten, der auf genau diese Zahl endet:

1#define COUNT_ARGS_IMPL(_1, _2, _3, _4, _5, _6, _7, _8, _9, _10, N,...) N
2#define COUNT_ARGS_HELPER(tuple) COUNT_ARGS_IMPL tuple
3#define COUNT_ARGS(...) COUNT_ARGS_HELPER((__VA_ARGS__, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0))
4
5#define CONCAT(a, b) a ## b
6#define BUILD_FUNCTION(func_prefix, arg_count) CONCAT(func_prefix, arg_count)
7#define CALL_OVERLOADED(func_prefix, args) BUILD_FUNCTION(func_prefix, COUNT_ARGS args)  args

COUNT_ARGS fügt den originalen Argumenten die Zahlen 10 bis 0 hinzu, weil wir bis zu maximal 10 Argumente unterstützen.
Die damit aufgerufene Funktion COUNT_ARGS_IMPL schluckt beliebig viele Parameter und interessiert sich für den 11. Denn dieser verrät uns die Anzahl der Parameter der originalen Funktion.

Ein Aufruf (a, b, c) wird umgeformt zu
(a, b, c, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1) und an der 11. Stelle steht dann 3, die von COUNT_ARGS_IMPL zurückgegeben wird.

Das Makro CALL_OVERLOADED versucht jetzt ein Funktionsnamen über ein Präfix und die ermittelten Argumentanzahl zusammenzubauen und ruft sie mit den Argumenten auf.

Jetzt kann man sich Funktionsaufrufe mit einem Makro umleiten lassen, z.B.:

1#define foo(...) CALL_OVERLOADED(foo_, (__VA_ARGS__))

Wird foo(x, y) mit 2 Parametern aufgerufen, wird ein foo_2(x, y) daraus.

 1int foo_1(int a);
 2int foo_2(int a, int b);
 3int foo_3(int a, int b, int c);
 4
 5int main()
 6{
 7  foo(10);         /* calls foo_1(10) */
 8  foo(20, 30);     /* calls foo_2(20, 30) */
 9  foo(40, 50, 60); /* calls foo_3(40, 50, 60) */
10  return 0;
11}

Ein vollständiges Beispiel liegt im BLOG-Classroom.

Problem MSVC

Microsofts Präprozessor wurde lange nicht aktualisiert und läuft daher nicht-standard-konform und kann die obigen Makros nicht richtig auflösen.

Doch seit MSVC 2019 (14.2) existiert der Compilerswitch /Zc:preprocessor mit dem man den Standard-konformen Modus einschalten kann und somit kann auch Microsoft endlich von den vielen “coolen” Makrospielereien profitieren, die man so im Netz findet.

Fazit

Ich hatte eigentlich wieder an meinem Lambda-Problem herumexperimentiert und bin dabei über die Frage gestoßen, wie man aus der Anzahl von Makroparametern unterschiedliche Klassennamen generieren kann.

Das hat im Endeffekt mein Problem zwar nicht lösen können, aber die Idee in C etwas Overloading-ähnliches einzubauen, und auszuprobieren, hat wieder Spaß gemacht.

Im GATE Projekt kann ich das nicht auf großer Ebene einsetzen, weil dort auch ältere MSVC Compiler unterstützt werden sollen, aber vielleicht ist der Ansatz ja bei manchen GCC Fixes eine willkommene Option.

Thor: Love and Thunder

2022-07-06T13:00:00+02:00

Oder: Ihre Kinder werden es mögen.

W-T-F ist denn das für eine Story?

… war einer der Gedanken, die ich heute Abend im Kino hatte.

Aktuell ist es gerade etwas schwierig, sich “als größter Marvel-Fan” zu bezeichnen, denn während die Filme vor Endgame versuchten auf einander zusammen zu laufen, erkenne ich jetzt das Gegenteil.

Das mag vielleicht zu den vielen Comics ganz gut passen, aber das MCU (Marvel Cinematic Universe) wich von diesem Ansatz bisher zu seinem Vorteil ab.

Ich habe heute einen wirklich komischen, lustigen Film gesehen. Das Publikum hat immer wieder hell auf gelacht, so auch ich. Und trotzdem war das kein MCU Marvel Film, obwohl das Logo und Intro von Marvel vorkam.

Götter

Achtung Spoiler!

Thor Odinson mag vielleicht der nordischen Mythologie entspringen, doch Marvel hat sich in den ersten Filmen viel Mühe gegeben, Asgard und seine Bürger als außerirdische überlegene Spezies darzustellen, die Technik einsetzen, die für uns einfache Menschen nur wie Magie wirkt.
(OK, den fliegenden Hammer Mjölnir lassen wir mal außen vor).

Doch nun - und mit Moonknight hat es angefangen - werden unzählige selbsternannte Gottheiten eingeführt, die sich einfach nur daran erfreuen angebetet zu werden.
Wie Pokemon im Pokedex saßen diese dann alle im nachgebauten Kolosseum und deckten ausgewogen die Elementtypen Feuer, Wasser, Pflanze bis hin zum Typ Fee ab, ohne bekannt oder notwendig zu sein.

Und dieser inflationär gebrauchte verwässerte “Gott”-Begriff schadet der im MCU aufgebauten Welt mehr, als er ihr nützt.

Und wer den Graupelschauer von Film namens Gods of Egypt gesehen hat, weiß auch schon, wie sich Götter verhalten und was durch ihre Adern fließt.

Smells like Teen Spirit - mal anders

Also, ich freue mich ja total, wenn Kinder und Jugendliche mal größere Rollen im MCU erhalten, als nur “süß” auszusehen.
Wie schön war es, als der Junge aus Ironman 3 in Endgame beim Begräbnis dabei war, wie die Maximoff Zwillinge ihr Zuhause verteidigt haben, oder wie Kid-Loki sein Schwert herbeiholt und Hawkeye mit seinen Kindern im Musical sitzt.

However … man kann es auch übertreiben, wenn Thor seine Kraft auf alle Asgard-Teens überträgt, damit sie gemeinsam angreifen können und Blitze aus dem Teddybären eines kleinen Mädchens schießen um Schattenmonster “wegzublasen”.

Ein gutes hat es: Heimdalls Sohn scheint mir “reif” genug zu sein, die künftigen Young-Avengers zu unterstützen.

Nachtrag: Thor-4 läuft seit dem 8. September auf Disney+

Love without Thunder

Die Liebesgeschichte zwischen Thor und Jane wurde ja schon im Trailer aufgedeckt und ist in soweit nicht spektakulär.
Viel lustiger ist die Dreiecksbeziehung zwischen Thor, Mjölnir und Stormbreaker … denn niemand dachte, dass Stormbreaker so empfindlich und eifersüchtig sein kann.

Interessant ist der Hintergrund des Antagonisten, von dem man ganz deutlich ableiten kann:

Nur wenn man ihn/sie/es geliebt hat, kann man ihn/sie/es dann so sehr hassen.

Und leider kommt auch hier die Rolle des Bösen wieder viel zu kurz. Denn diesem ernsten Thema hätte man mindestens eine halbe Stunde mehr Zeit einräumen müssen, und dafür hätte ich sogar auf die lustigen Ziegen im Film verzichtet.

Fazit

Ja, der Film hat mich sehr gut unterhalten und war sein Geld wert.
Aber als Teil des MCU hatte er nur einen wichtigen Aspekt:
In der Midcredit-Szene wurde ein neuer Gegner angekündigt.

Und das finde ich dann doch schade.
Es hätte so viel mehr sein können.

Pinephone Keyboard

2022-07-03T13:00:00+02:00

Smartphone + Keyboard = PC ?

Naja, nicht ganz. Aber wenn man mehr texten will, braucht man einfach eine Tastatur, denn egal wie gut sie ist, die Onscreen-Tastatur kann einfach keine echte ersetzen.

Und dank des neuen Keyboard-Docks für mein PinePhone, lässt sich das jetzt realisieren.

Das Pine64-Projekt gefällt mir bekanntlich sehr, und daher unterstütze ich es gerne mit dem Kauf ihrer Produkte, und eines davon ist das PinePhone-Keyboard.

Nun … eigentlich geht das jetzt ein bisschen in die falsche Richtung, weil wir kennen alle das Video, in dem sich Steve Ballmer über das iPhone lustig macht und meint, ohne Stylus und Tastatur kann man darauf keine eMails schreiben.
Tja, er hätte sich nicht mehr irren können. Niemand braucht Tastaturen für eMails … oder?

EMails habe ich am Pinephone noch kein einziges geschrieben und werde es auch nicht, aber es gibt etwas, was ich häufiger darauf mache:
Ich öffne das Terminal und führe Programme wie cmake und Buildscripts aus.

Und das ist mit der Onscreen-Tastatur einfach nur ein Krampf.
Ja, SSH hilft, doch das Gerät befindet sich dann doch zu oft im falschen WLAN und schon muss ich erst mühsam umkonfigurieren, um ein Script zu starten.

Pinephone Keyboard.

Ende letzten Jahres angekündigt, ist es schon seit ein paar Monaten verfügbar: Ein Tastaturdock für das Phone.

Und es ist so einfach: Man nimmt die Rückseite des Pinephone-Gehäuses ab und klinkt das Smartphone in das Tastaturdock, und sofort arbeitet die Tastatur als primäres Eingabegerät.

Das Keyboard wirkt auf den ersten Blick recht reduziert, doch die Magie steckt in der Fn (Function) Taste zwischen Ctrl und Alt. Denn diese schaltet bei vielen Tasten eine “alternative Funktion” ein, und so liegen die Pfeiltasten bei den Sonderzeichen rechts unten bei den Sonderzeichen, wie auch die F-Tasten über den Ziffern liegen.

Die Kamera ist auch “ausgestanzt” und voll einsatzbereit. Von den Ausmaßen her ist das Teil ziemlich gleich groß wie mein alter Nintendo 3DS XL.

Fazit

Eine echt gute Lösung diese Hardware.

Und als Entwickler, werde ich dieses Features noch häufig nutzen.

Ob so eine Tastatur auch im Normalbetrieb relevant ist, wage ich aber zu bezweifeln.
Da wird es eher wichtig werden neue Linux Apps zu schaffen, die sich mit Touchscreens besser bedienen lassen.

UI Blödheiten

2022-07-02T13:00:00+02:00

Mit der Einführung von “mobilen” Apps haben eine Menge Ahnungsloser, die keine bis wenig IT Erfahrung hatten, die Möglichkeit der Welt ihren Stempel aufzudrücken, weil es dem Marketing erfolgreich gelungen ist allen einzureden, dass man jetzt alles neu braucht.

Und diesem Wahnsinn sind leider auch Checkboxen und Textfelder zum Opfer gefallen.

Neulich hatte ich einen “speziellen” Support-Anruf aus dem privaten Umfeld.
Die Online-Banking-Seite verwirrt nun noch mehr mit der Option einer kostenpflichtigen Noch-Schneller-Sofort-Transaktion, die sich angeblich nicht ausschalten lässt.

Toggle Buttons

“Toggle-Buttons” heißen diese UI-Dinger, die Optionen ein und ausschaltbar machen sollen.
Dass unsere Teenagergeneration angeblich intuitiv dahinter steigt, wie man die bedient, mag vielleicht stimmen, aber für die 40+ Benutzer ist das nicht so.
Auch mir ist es schon öfter passiert, dass ich nicht auf Anhieb erkennen konnte, was jetzt “on” und was “off” bedeuten soll.

Der Grund für dieses Chaos liegt darin begründet, dass jetzt jede noch so unwichtige Firma glaubt, sie müssten ihr eigenes UI-Design mit eigenen Farbspielen auf den Markt bringen.
Und ahnungslose Anfänger (auch Webdesigner genannt) zeichnen dann drei Wochen an einem abgerundeten Viereck herum, wo man innen einen Kreis nach links und rechts verschieben kann.
Ob jetzt “ON” links oder rechts, hell oder dunkel ist, hängt von der Laune des Zeichners ab.

Wieso konnte man nicht die gute alte Checkbox, die man schon vor 50 Jahren auf Antragsformularen auf Papier vor sich hatte, einfach weiterbenutzen?

Denn dieses UI Element ist in allen Betriebssystemen vorhanden und passt sich and das Standard-Design an, reagiert zuverlässig auf Klicks und jeder versteht, dass ein leerer Kasten “deaktiviert” bedeutet und ein angehakter mit “aktiviert” gleichgesetzt ist.

Here is a checkable option (click me)
Here is another checkable option (click me)

HTML kennt z.B.: den <input type="checkbox"> schon seit den aller ersten Tagen.

Das Problem mit Toogle-Buttons sind die vielen Eigenentwicklungen, die “möglichst cool” zur Firmenfarbe passen sollen.
Und dann passiert es, dass das Farbschema so dezent ist, dass man den “Ein” vom “Aus” Zustand optisch nicht mehr unterscheiden kann.

Textbox mit 50% CPU Auslastung

Der nächste Dreck sind selbst-designete (oder von Google kopierte) Textbox Imitate, die

bei jedem Tastenanschlag Webrequests absetzen
kein Copy/Paste unterstützen
bei Internetaussetzern Daten verlieren
dauerhaft 50% CPU Auslastung generieren, weil sie sich dauernd neuzeichnen

Oft reicht die klassische Combobox aus, also eine Textbox, die mit einer Listbox kombiniert ist und beim Tippen Auswahlmöglichkeiten bietet.

Enter your Platform:

HTML5 führte das
<datalist id="list_id"> Tag ein um <option> Einträge auch z.B. an <input type="text" list="list_id"> binden zu können.

Ja/Nein Links/rechts ?

Und dann noch die Sache mit der Frage, ob “Ja” und “Nein” (bzw. “OK” und “Abbrechen”) jetzt von links nach rechts angeordnet ist, oder umgekehrt.

Zugegeben, das ist plattformabhängig.
Windows nutzt den ersten Ansatz, MacOS den zweiten und Linux wechselte vom ersten zum zweiten.

Wenn die Leute also ihre eigenen Dialoge schreiben, entscheiden sie sich für ein Schema, doch das entspricht dann nicht immer der Plattform.

Auch hier kann man zumindest bei ein paar Dialogen auf System-Implementierungen setzen.

In HTML kann man z.B. auf die Javascript Funktion confirm() zurückgreifen. Der Browser zeigt den Dialog so an, wie der Browser-Standard es festlegt.

Fazit

Individualität ist super, ich mache ja oft auch gerne Dinge “einfach anders”.
Aber gerade UIs sollten sich “an alle richten” und deshalb sind hier Standards wichtig.

Und wenn eine Bank sich einbildet, sie müsste ihre eigenen Toggle-Buttons implementieren und die so verunstaltet, dass die Kunden Angst haben am UI was falsch zu machen, ist das nicht gut.

Das Schlimme ist, dass das die Webentwicklung ebenso trifft, wie native UI-Programme.
Auch mir wurde schon der Auftrag erteilt, bloß keine Standard-Controls zun nutzen und alles mit ersetzbaren Bitmaps vollzupflastern.
Das Resultat war eine schlechte UI mit CPU-Spitzen, wenn man die Maus drüberfahren ließ … aber:

Der Markt will das so.

Wir brauchen daher weniger Eigen-UI-Entwickler, sondern welche, die die Plattformen kennen und wissen, wie man diese richtig einsetzt um zu besseren Ergebnissen zu gelangen.
Oder anders gesagt:

Weniger ist manchmal mehr.

Dokumentation

2022-06-26T13:00:00+02:00

Wenn man den Satz

Gute Programmierer sind schlechte Dokumentierer.

umgekehrt auffasst, dann bin ich einer der besten Programmierer, denn Dokus schreiben mag ich so gar nicht.

However … auch das muss mal sein.

Der C-Teil der Kernbibliothek des GATE Frameworks gatecore ist nun zum Großteil mit doxygen Kommentarblöcken befüllt und somit konnte die erste sinnvolle Version der Projektdokumentation generiert werden.

Da mein doxygen Setup so aussieht, dass nur dokumentierte Codes abgebildet sind (und nicht alles automatisch extrahiert wird), musste ich also vor jeder öffentlichen Funktion entsprechende Kommentare anfügen.

Das ist zwar noch lange nicht vollständig, doch nun sind zumindest viele Kernfunktionen mal “offiziell” geworden.

Dokumentation ist gleichzeitig auch ein Interface-Review und tatsächlich sind mir einige Inkonsistenzen aufgefallen, die ich teils gleich korrigieren konnte. Andere Details stehen auf der “Redesign” Liste.

Damit auch ein bisschen mehr Qualitätsdruck entsteht, wurden die generierten HTML Dateien auf den Webspace hochgeladen, wo sie unter http://www.opengate.at/doc einsehbar sind.

Der nächste Punkt wird das C++ Interface werden und parallel verlangen auch die Bibliotheken gateio, gatesystem, gateencode, gatenet und gategraphics nach einer Schnittstellenbeschreibung.

Fazit

Leider frisst das Dokumentieren wirklich extrem viel Zeit, denn hier gilt tatsächlich im Header:

Für eine Zeile Code, braucht man 5 Zeilen Dokumentation.

Und wenn dann noch jeder Parameter seine Geheimnisse preisgeben soll, merkt man erst, dass tatsächlich 5 mal mehr Beschreibungszeilen erforderlich sind, als für die eine Codezeile, die eine Funktion ankündigt.

Ich hoffe, dass meine Motivation hinreichend lange aufrecht bleibt, um die Grundzüge des Projektes darzustellen.

Mal sehen, was in einem Jahr daraus werden wird.

Makro-C-Objekte in Doxygen

2022-06-25T13:00:00+02:00

Wenn ich meine selbstgestrickten Makros einsetze, um V-Table structs generieren zu lassen und anschließend C-Klassen structs, dann schreibt Doxygen ziemlich wirres Zeug.

Ähnlich ergeht es manch alten COM Projekten in C, die ebenfalls mit Makros arbeiten (die mir ja auch als Inspiration gedient haben).

Wie bekommt man also eine Doxygen-konforme Lösung hin?

Wie Microsoft’s COM in reinem C Code aussah, hat Raymond Chan bereits super dokumentiert

Im GATE Projekt beginnt alles mit dem “gate_object” Interface und das wird aus “ähnlichen” Makros zusammengebaut. Alle Ableitungen müssen dabei das Interface der Basisklassen nochmals exakt nachstellen, damit die entstehende V-Table “kompatibel” bleibt:

 1GATE_INTERFACE(gate_object)
 2{
 3  GATE_METHOD0(char const*, get_interface_name);
 4  GATE_METHOD0(void,        release);
 5  GATE_METHOD0(int,         retain);
 6};
 7
 8GATE_INTERFACE(gate_cloneable)
 9{
10  /* extends: gate_object */
11  GATE_METHOD0(char const*, get_interface_name);
12  GATE_METHOD0(void,        release);
13  GATE_METHOD0(int,         retain);
14
15  /* clonable methods: */
16  GATE_METHOD1(gate_result_t, clone, gate_cloneable_t** clone);
17};

Daraus wird für ein gate_cloneable Interface in etwa folgender Code generiert:

 1typedef struct
 2{
 3  char const* (*get_interface_name)(void* thisptr);
 4  void        (*release)           (void* thisptr);
 5  int         (*retain)            (void* thisptr);
 6
 7  gate_result_t (*clone)(void* thisptr, gate_cloneable_t** clone);
 8} gate_cloneable_vtbl;
 9
10typedef struct
11{
12  gate_cloneable_vtbl const* vtbl;
13} gate_cloneable_t;

Doxygen kann jedoch die etwas komplexeren Makros im Hintergrund leider nicht alle Auflösen und somit kann ich leider nicht einfach vor GATE_INTERFACE() oder vor GATE_METHOD() meine Doku schreiben.

Lösung: Pseudo-Klasse in Doxygen nachbauen

Es gibt zwar ein paar Tricks, um den Doxygen Parser zu beeinflussen um ihm neue Vokabel beizubringen (für COM existieren solche Zusätze), doch ich hätte gerne eine Lösung, die “Out of the box” funktioniert.

Und die sieht dann so aus:

 1/**
 2 * @interface gate_object_t
 3 * @brief     Base type of all GATE C objects
 4 */
 5
 6/**
 7 * @fn       char const* get_interface_name()
 8 * @memberof gate_object_t
 9 * @brief    Returns on object's interface path name
10 * @return   Static string describing the interface.
11 *
12 * @fn       void release()
13 * @memberof gate_object_t
14 * @brief    Decrease ref-counter, releases object when count == 0
15 *
16 * @fn       int retain()
17 * @memberof gate_object_t
18 * @brief    Increase object's reference counter
19 * @return   Returns the current reference counter value
20 */
21
22
23/**
24 * @interface  gate_cloneable_t
25 * @implements gate_object_t
26 * @brief      Base interface for all objects that can be cloned.
27 */
28
29/**
30 * @fn         gate_result_t clone(gate_cloneable_t** clone)
31 * @memberof   gate_cloneable_t
32 * @brief      Creates a new object by cloning this object
33 * @param[out] ptrclone receives the new cloned object's pointer
34 * @return     GATE_RESULT_* result code
35 */

Folgendes habe ich gelernt:

Der Doxygen-Kommentar Block sollte nach dem Macro-Block folgen. Steht er davor, wird GATE_INTERFACE() als Makro oder Funktion erkannt, die dann auch ohne Bedeutung in der Doku steht.
Wichtig ist auch, dass man zuerst einen Kommentarblock schreibt, der die Klasse deklariert und anschließend einen neuen Kommentarblock für die Funktionen anlegt.
Wenn man beides in einen Block zusammenfügt kommt keine schöne Doku dabei heraus.
@memberof nach einem @fn markiert die Funktion als zugehörig zur angegebenen @struct, @class oder @interface.
(Eigentlich hätte ich ja struct nutzen müssen, aber das eigentlich von der IDL stammende interface benennt dann auch in der Doku die Strukturen als “Interface”).
Mit @implements werden Vererbungshierarchien definiert, die man dann im generierten Doxygen-HTML auch in einem Graphen durchklicken kann.

Fazit

Naja, ich sehe es jetzt mal als annehmbaren Workaround.
Alle anderen Spielereien mit Doxygen zwischen den Makros haben die generierte HTML Doku nur vernudelt.

Doch mit der Lösung habe ich jetzt endlich etwas funktionierendes, mit dem ich meine Interface Definitionen auch verständlich dokumentieren kann.

Denn eigentlich war dieser offene Punkt einer der Gründe, warum ich seit zwei Jahren die Dokumentation des Projektes immer wieder aufgeschoben habe. Bisher habe ich nur sporadisch freie C-Funktionen mit Doxygen Kommentaren versehen.

Das Schlimme ist … jetzt muss ich meinen hunderten Funktionen auch wirklich mal eine verständliche Bedeutung zuordnen.

Doch das ist auch gut … denn damit erfolgt implizit auch ein Code-Review.

ARM Assembler in MSVC++

2022-06-18T13:00:00+02:00

Mit meinem neuen ARM-PC und dem ebenso neuen Visual Studio 2022 Preview für ARM64 eröffnet sich mir wieder ein neues Kapitel in der Softwareentwicklung:

ARM32 und ARM64 Assembly Language.

Denn nun kann ich beides live debuggen.

Einrichtung in Visual Studio

Wenn man *.asm Dateien einem Visual Studio Projekt hinzufügt und die Build Dependencies - Build Customizations - masm Targets aktiviert hat, ist lediglich X86 und X64 Support (ml.exe) verfügbar.

Für die ARM Entwicklung braucht man aber den ARM Assembler (armasm.exe) und dieser kann über den marmasm Eintrag der Visual C++ Build Customization Files aktiviert werden.

Hat man in seinem MSVC Projekt parallel auch masm aktiviert, dann sollte man für jede Zielplattform die korrekten *.asm Dateien einschließen und ihren Item Type in den Properties korrekt setzen.
Dieser lautet dann nämlich Microsoft ARM Assembler (und nicht wie sonst Microsoft Macro Assembler)

In älteren Varianten von Visual Studio fehlt ein solches Custom-Target. Hier kann man sich entweder das masm Target-File hernehmen und anpassen oder von Anfang an neu erstellen.
Oder man definiert einen generischen Kommandoaufruf. Am Ende muss mindestens ein:
armasm64.exe "path\to\my_code.asm" -o "ARM64\Debug\my_code.obj"
dabei herauskommen.

Noch kein direkter CMake Support

CMake unterstützt den MARMASM leider noch nicht.
Es gibt einige Diskussions-Hinweise im Netz darauf, dass im Modul CMakeDetermineASM_MASMCompiler.cmake ein Patch notwendig wäre, weil dort nur ML64 und ML erkannt werden.

Ich vermute aber, dass Microsoft das in der nächsten Preview, aller-spätestens aber mit dem nächsten Visual Studio Produkt nachliefern wird.

Vorläufig muss ich alle Assembler-Tests manuell einrichten.

Update 2023:
Ab CMake 3.26 (3.25.2023 nightly builds) ist der Sprachdialekt “ASM_MARMASM” enthalten und erzeugt damit alle notwendigen MSVC Einstellungen automatisch.

ARM Syntax: Ja nicht auf das Leerzeichen vergessen!

Meine ersten Versuche mit kopierten Zeilen aus dem Netz scheiterten alle mit seltsamen Fehlern wie:

error A2034: unknown opcode: .text

wenn die erste Zeile AREA |.text|,CODE,READONLY übersetzt wird.

Eine ARM Assembly Language Zeile ist immer nach dem gleichen Schema aufgebaut, nämlich:
{symbol} {instruction|directive|pseudo-instruction} {;comment}
Und damit muss jede Zeile entweder mit einer Zeilenmarke anfangen (Funktionsnamen oder Sprung-Label), oder eben mit einem Leerzeichen oder TAB.

 1;demo.asm: Wrong! No space before directives/instructions
 2AREA |.text|,CODE,READONLY
 3
 4EXPORT my_add_func
 5my_add_func PROC
 6  add x0, x0, x1
 7  ret
 8ENDP
 9
10END

Direktiven wie AREA, EXPORT oder ENDP und alle CPU Anweisungen müssen also immer eingerückt werden:

 1  ;demo.asm: Correct! With space before directives/instructions
 2  AREA |.text|,CODE,READONLY  ; location + type of generated code
 3
 4  EXPORT my_add_func ;declare "my_add_func" as public function
 5my_add_func PROC  ;"my_add_func" entry-point symbol
 6  add x0, x0, x1  ; ret = param_1 + param2
 7  ret             ;ARM return instruction
 8  ENDP            ;end of procedure "my_add_func"
 9
10  END            ;end of assembly file

Kaum hat man es richtig gemacht, lässt sich die Assemblerzeile mit dem ARM64 Assembler übersetzen und aus C++ mit dem Prototyp

1#include <stdint.h>
2extern "C" intptr_t my_add_func(intptr_t a, intptr_t b);

aufrufen.

Fazit

Nun kann ich also meine Stack-Switching-Routinen auch auf ARM Plattformen portieren und das wiederrum eröffnet ein weiteres spannendes Feld:

EFI-Apps auf ARM Hardware

Doch bis ich mich ausreichend gut mit ARM Assembler Codes auskenne, wird wohl noch der eine oder andere Test notwendig sein.
Schließlich habe ich bisher immer nur mit X86 gearbeitet und kenne die weit gestreuten Möglichkeiten der ARM Architektur noch nicht.

Zumindest freue ich mich, dass ich jetzt wenigstens alle Windows-Plattformen mit Assemblercode beglücken kann.
Doch auch das wird nicht das Ende sein … denn mein Raspberry PI verdient eine mindestens genau so gute Linux Abdeckung.

Spaziergang nach Schwechat

2022-06-16T13:00:00+02:00

Ich soll doch mehr Bewegung machen, also dachte ich mir, ich marschiere mal vom Reumannplatz aus in Richtung Simmeringer Hauptstraße und über die gerade aus nach Schwechat.

Gesagt … getan … denn das Wetter war herrlich schön.

Der uralte Witz:

Habt ihr es schon gehört?
Über 3 Millionen Tote!
Wo?
Am Wiener Zentralfriedhof.

kam mir wieder ins Gedächtnis, als ich an den “Toren” des Friedhofs vorbeikam. Bis heute war ich dort noch nie drinnen und das wird auch noch so bleiben, denn heute wollte ich ja wo anders hingehen.

Interessant ist nur, das die gesamte Umgebung um den kilometerlangen Friedhof mit kleinen Steinmetzbetrieben zugepflastert ist. Da frage ich mich immer, ob da nicht zu viel Konkurrenz auf einem Fleck sitzt … aber offenbar nicht.
Gestorben wird schließlich andauernd.

Ich dachte eigentlich, dass ich die ganze Zeit der Straßenbahnlinie 6 nachgehe, den deren Endstation war früher das letzte Tor des Zentralfriedhofs … doch offenbar hat sich das schon vor Jahren geändert. Der 6er endet nun an der Geiereckstraße und die Linie 11 übernimmt die Fahrt zum Friedhof.

Und nach einem ordentlichen Marsch, sah ich sie dann, die Ortstafel “Wien Ende”.

Und nach einer Brücke unmittelbar gefolgt von der Ortstafel “Schwechat”.

Dann durch die Stadt vorbei an der Veranstaltungshalle “Multiversum” (mit einer halb guten und halb schlechten Erinnerung).

Bis ich endlich am Ziel war: Das Lucky Food, das dortige asiatische Restaurant, dass ich von einem früheren Besuch in sehr guter Erinnerung hatte.
Hier gab es ein köstliches Mittagessen zur Stärkung.

75 Minuten brauchte ich für die etwa 9 bis 10 Kilometern.

Den Rückweg habe ich etwas abgekürzt, und beim Zentralfriedhof die Straßenbahn benutzt.

Fazit

Es war zwar gegen Mittag schon recht heiß geworden, aber in Summe war das ein entspannender Spaziergang.

Da hat man Zeit über Gott und die Welt nachzudenken und kann dann am Abend zur Abwechslung mal sagen: Heute habe ich genug Bewegung gemacht.

Ich plane bei gutem Wetter an den kommenden Wochenenden in alle Richtungen durch Wien zu laufen, mich an vergangene Ereignisse, Arbeitsorte und Wohnorte erinnern.

Mal sehen wie weit die Motivation über den Sommer hin reicht.

Windows on ARM: APCSILMIC Dot 1 Mini PC

2022-06-12T13:00:00+02:00

Mit dem Dot 1 Mini PC von APCSILMIC ist nun ein alter Traum von mir endlich in Erfüllung gegangen:

Ein günstiger ARM64 PC mit Windows 11 Support für unter 300 Euro ist auf dem Markt!

Und das Teil ist echt genial, denn mit Windows 11 ARM64 hat man nun ein Betriebssystem, das alles ausführen kann. x86, x64, ARM32 und ARM64 Windows Binaries, sowie WSL Linux.

Ich weiß nicht warum Microsoft mir das Leben so schwer macht. Bereits im Herbst 2021 wurde ein ARM-Entwickler-System vorgestellt um den Umstieg auf die ARM Plattform voranzutreiben.
Doch diese Hardware war nur innerhalb der USA lieferbar.

Und auf der letzten Build-Veranstaltung von MS wurde ein weiterer ARM PC angekündigt … der irgendwann erscheinen soll.

Welch ein Glück, dass es das Unternehmen APCSILMIC gibt, welches ein neues kostengünstigen ARM PC-Produkt mit Windows 11 anbietet, das mir genau das bietet, was ich brauche:
Nämlich eine kostengünstige Hardware, mit der ich endlich ARM64 live nutzen kann.

Mein PIPO W12 Tablet ist bekanntlich auch ein ARM System, mit dem ich schon viel erforschen konnte, nur leider ist dieses an Windows 10 gebunden und es gibt noch keinen sicheren Upgrade Pfad auf Windows 11 … und weil es eben gut läuft, habe ich etwas Angst es in einen unbenutzbaren Zustand zu versetzen.

APCSILMIC: Dot 1 Mini PC

Mit 3 RAM+SSD-Varianten von 4GB/64GB, 6GB/128GB und 8GB/256GB kann man zwischen 220, 250 und 290 Dollar an Gerätekosten wählen.

Bei allen Varianten gleich sind:

SC7180 Qualcomm Snapdragon mit 8 logischen Kernen
2x HDMI
2x USB 2.0
1x USB 1.0
100 MBit LAN
WLAN (2.4 + 5 GHz)
Bluetooth 5.1
1x Micro-SD Kartenleser
Optional: 1x SIM Karte für 4G Breitband (gegen Aufpreis)

Nun, das Gerät ist sicher kein Rennpferd, bietet aber mehr Leistung als meine Intel Atoms mit Baytrail Kernen, und verbraucht aber selbst unter Volllast nicht mehr als 8 bis 9 Watt, im Leerlauf gerade mal 4-5 Watt.

Das System ist vollständig ARM64 UEFI tauglich, womit auch der Boot anderer Betriebssysteme neben Windows leicht möglich wird.

Schließlich gibt es viele ARM-Geräte aus China, die den Raspberry PI nachahmen, doch alle nutzen sie proprietäre Bootsequenzen, für die nur veraltete Linux-Distros existieren.

Der Dot 1 Mini PC ist dank EFI und Microsoft-Support zukunftssicher.

Visual Studio 2022 Preview

Parallel zum Gerät kam in den letzten Tagen Visual Studio 2022 mit nativem ARM64 Support als Preview ins Netz. Das Studio ist nun voll nativ ARM64-tauglich und lässt mich ARM Code direkt auf dem Gerät debuggen.
Das war mit den Vorgängerversionen (und dem “normalen” VS 2022) nur per Remote-Debugging möglich.

Interessant ist das für mich deshalb, weil ich nun endlich damit beginnen kann, ARM-Assembler Code zu schreiben, den ich auch durchdebuggen kann. Zuvor konnte ich nur C/C++ Code kompilieren und dann am Tablet ausführen.

Die Installation war zugegeben eine Qual und dauerte lange. Da zeigt sich, dass die Kombination von vielen SSD-Zugriffen eine schwache Performance aufweist.
Doch ist Visual Studio erst einmal installiert lässt es sich “wie üblich” nutzen.

Fazit

Heute braucht jeder Entwickler ein vollwertiges ARM-Gerät!

Denn ohne ein solches kann man seinen nativen Code nicht mehr live testen.

Ich spreche hier keine Werbeempfehlungen aus, sondern wünsche mir, dass in jedem Supermarkt heute ein ARM PC angeboten wird.
Doch leider ist das noch nicht so und der “Dot 1 Mini PC” war das einzige Gerät, das finden konnte, das Windows-11 kompatibel ist und sofort geliefert werden konnte.

Die Webseite wirkt zugegeben etwas “quick-and-dirty” zusammengeschustert. Und als ich meine Bestellbestätigung erhielt und den enthaltenen Link anklickte, so verwies der zu einer nicht mehr gültigen Domain.
Ich dachte schon fast, ich wäre einem Betrug zum Opfer gefallen, doch das Paket-Tracking bestätigte, dass meine Hardware auf dem Weg war.

Und nach 3 Wochen wurde der PC bei mir geliefert und startet “out-of-the-box” ohne Probleme.

Ich liebe das Teil nun sehr und denke, es ist wie damals vor 15 Jahren beim Switch zu x64 ein ganz wichtiger Technologiewechsel, den ich mit dem Mini PC nun bei mir fortführen kann.

Linux hasst static binaries

2022-06-12T13:00:00+02:00

Ich staune immer wieder darüber, wie etwas so “einfaches” wie statisch Abhängigkeiten unter Linux so schwer bzw. unmöglich gemacht werden.

Denn eigentlich sind Programme mit dem Compiler Flag -static etwas ganz Tolles … denn sie laufen unter jedem Linux-System (naja, zumindest unter vielen davon) ohne dass man Bibliotheken nachinstallieren muss.

… doch dann fangen die Probleme an.

Es geht wieder mal um die alte Geschichte:

Ich hätte gerne (so wie unter Windows) ein Programm, dass ich einfach auf ein Zielsystem kopiere und es dort ohne weitere Schritte läuft.

In Windows kompiliert man eine solche EXE gegen die statische Version der C-Runtime und achtet darauf, andere Nicht-OS-Libs ebenso statisch zu linken.

Am Ende hat man eine etwas größere, dafür aber unabhängige EXE, die in jeder Windows-Variante läuft.

In der Linux GCC-Welt gibt es ein solches Compiler-Feature auch, und es heißt -static. Mit diesem Flag werden alle sonst dynamisch gelinkten Bibliotheken wie pthread, dl oder libc statisch in das Binary eingebunden.

Theoretisch kann man ein solches auf Ubuntu erstelltest Binary nehmen und auf OpenSUSE oder Alpine ausführen. Und bei einfachen Hello-World Apps funktioniert das auch wunderbar.

Problem “dl”: Dynamic Linker

dlopen und dlsym sind in Linux kein Betriebssystem-Feature wie es LoadLibrary und GetProcAddress unter Windows sind, sondern werden von der Bibliothek dl nachgeliefert.
Zusätzlich ist der Startup-Code der C-Bibliothek darauf ausgerichtet, Datenblöcke beim Start durchzulaufen, die der Compiler/Linker eingefügt hat, um dynamische Bibliotheken zu öffnen (open) und in den Prozessraum zu laden (mmap).

Mit -static wird diese Prozedur umgangen und der Compiler sucht von allen notwendigen Bibliotheken die statische Variante und fügt sie in die finale Binärdatei ein.

In einem solchen Binary sind “dynamische” Features nicht mehr vorhanden und auch dlopen wird zu einer Funktion, die nichts mehr tun kann und mit einer “not-supported” Meldung abbricht.

Bislang ist es mir nicht gelungen eine allgemeine Verwendung von dlopen() mit -static zu finden, die auf allen Plattformen lauffähig wäre.

Meine Debian-Derivate melden dann durch eine Warnung, dass man jetzt nur noch jene Bibliotheken dynamisch laden kann, die mit der gleichen Version der glibc erstellt wurden.
Und Alpine Linux liefert den erwähnten Not-Supported Errorcode.

Nicht `-static` aber `-BStatic`

Alternativ kann man ein Binary auch -dynamic kompilieren (der Default-Fall und das Gegenteil von -static) und dann aber beim Linken auf statische Versionen der notwendigen Bibliotheken verweisen.

In CMake ging das mit Linker-Flags wie:

-Wl,-Bstatic -lc
linkt die C-Runtime statisch
-Wl,-Bstatic -lpthread
linkt pthread statisch
-Wl,-Bstatic -ldl
linkt dl statisch

Hier steckt der Teufel wieder im Detail, was man wo darf und was wo nicht.

Am Ende fand ich aber auch hier keine Variante, die “portable” Binaries für mehrere Linux-Varianten ermöglichte.

Fazit

Ich bleibe also bei “dynamischen” Binaries, weil das GATE Framework eben von anderen externen Bibliotheken abhängig ist.
Ginge es ausschließlich um C-Runtime Funktionen wäre vielleicht ein Möglichkeit offen reine statische und portable Binaries zu erzeugen, doch die Kombination mit dl* Funktionen schließt diese Option (aus meiner aktuellen Sicht) aus.

Gelernt habe ich allerdings, dass die glibc einigermaßen kompatibel geblieben ist und so kann ich ein Binary, das mit GCC5 unter Ubuntu 16.04 gebaut wurde, auch in den Folgeversion (Ubuntu 22.04), Debian und OpenSUSE ohne weitere Installationen nutzen.

Ich muss daher in Zukunft bei Linux nicht Distributionen unterscheiden, sondern deren Bindung an lib-c Implementierungen.
Und da kenne ich aktuell eben nur glibc und musl-libc.

printf() Marke Eigenbau

2022-06-05T13:00:00+02:00

Und Schuld hat libsupc++ …

… dass ich jetzt auch noch printf() und seine Freunde nachbauen darf.

Und so beginnt ein weiterer Tag meiner Reise ins EFI-Land.

Mit dem GCC werden C++ Exceptions in EFI Apps kein Problem mehr sein.

dachte ich. Tja, falsch gedacht.

Das alte Problem, dass C++ Exception Handler und RTTI jede Menge im Hintergrund ausführen, der in der C-Runtime verankert ist, verfolgt mich nun nicht nur am MSVC sondern auch im GCC Build.

Grundsätzlich gibt es dort zwar eine Trennung von Kernfunktionen und Runtime-Zusätzen. Und zwar bietet die libsupc++ einige Basis Unwinding-Routinen an, doch diese greifen auf jede Menge C Funktionen zu, die es in nativen EFI Apps nicht gibt.

In Foren ließt man dann, man könnte die Bibliothek und Teile der glibc anpassen und sich neu zusammenkompilieren, doch dann schaffe ich wieder Code, der im MSVC explizit ausgeblendet werden muss.

Unabhängige printf(), sprintf() und fprintf() Funktionen

Das Problem sind tiefe Verschachtelungen zwischen String-Funktionen und den Betriebssystem-Primitiven.

Wenn eine printf() Implementierung direkt ein write auf STDOUT beinhaltet, ist das zwar effizient, aber nur POSIX oder Linux tauglich. Das gleiche gilt dann auch für die WinAPI am MSVC.
Und schlimmer wird es, wenn im Code dann noch Compiler-spezifische Erweiterungen benutzt werden.

Ich brauche also ein printf(), das Zeichen für Zeichen an einen Callback schickt. Und dieser Callback kann dann einfach an EFI oder etwas anderes angepasst werden. sprintf() und fprintf() funktionieren genau so, nur dass noch ein Parameter angefügt wird, der eine Referenz zum String oder zum FILE Objekt mitführt.

Und eben mit dieser Aufgabe werde ich wohl etwas Zeit verbringen müssen, denn erst wenn man seine Implementierung startet, merkt man, dass printf gar nicht so “unkomplex” ist, wenn die unterschiedlichen Format-Spezifizierer kombiniert werden müssen.

Und wozu das Ganze?

Der GCC produziert interne Funktionen für z.B. purecall oder cast Fehler und diese nutzen offenbar printf() und fprintf() und sprintf() um Debugging Nachrichten auf die Konsole zu schreiben.

Und dann wird beim Linken sichtbar, dass das unresolvable symbol printf nicht in cxx_purecall_xyz aufgerufen werden kann.

Während es mir (mehr oder weniger) gelungen ist, andere Bibliotheken von zlib bis zur libjpeg so abzuspecken, dass sie nur noch ihre Algorithmen umsetzen und keine OS-Funktionen aufrufen, zwingt mich jetzt ausgerechnet der C++ Compiler selbst, diese C-Schnittstelle auch in EFI nachzubauen.

Die Bibliothek GNU-EFI hätte zwar eine eigene Print() Implementierung, doch diese arbeitet nur mit wchar_t und unterstützt nicht alle Refinessen von printf().

Mich enttäuscht daher, dass sich dieses Verhalten nicht “leichter” abschalten lässt.

Fazit

Aber etwas Gutes hat es am Ende:

Früher oder später habe ich die Sourcen für einen kleinen Betriebssystemkern beieinander.

Denn wenn man alle STD-C Funktionen selbst implementiert hat, kann man viele Fremdprogramme damit neu kompilieren und sie über die “eigene Schnittstelle” laufen lassen.

Erdbeeren++

2022-06-04T13:00:00+02:00

Neben Schokolade sind Erdbeeren schon seit eh und je eine meiner Schwächen. Tatsächlich verbinde ich damit aber viele schöne Erinnerungen an meine Kindheit.

Und obwohl die Preise für das schmackhafte Obst nicht gerade niedrig sind, fällt es mir schwer am Supermarkt vorbei zu gehen ohne eine Schale mitzunehmen.

Erdbeeren

Ein Fixpunkt in den Sommerferien war früher für mich die jährliche Fahrt “zum Erdbeerfeld”.
Dort konnte man auf ausgedehnten Erdbeerstreifen selbst den einen oder anderen Eimer vollpflücken und dann die Kilomenge bezahlen.

Was man zwischendurch verspeiste, blieb natürlich unverrechnet und so erinnere ich mich bis heute an die Zeit, als ich mit Mutter, Großmutter und weiterer Verwandtschaft zum Erdbeerfeld fuhr und dort Vorräte “abbaute”.

Unvergesslich bleibt da die Erinnerung, als meine Tante meiner kleinen Kusine mehrfach erklärte:

Die Roten kommen in den Kübel.

Doch diese steckte die roten Beeren zielsicher in den Mund und streute die unreifen grünen Beeren in den Eimer.

Wald-Erdbeeren

Noch besser als gewöhnliche Erdbeeren sind Wald-Erdbeeren, doch diese Delikatesse findet man heute leider nicht im Supermarkt.

Die kleinen Beerchen haben das best mögliche Aroma, das man sich vorstellen kann und mit der Aufgabe “Walderdbeeren suchen” schaffte es meine Großmutter stets auch meine faulen Beine in Richtung Wald laufen zu lassen.

Da Wald-Erdbeeren sehr klein sind und nur an bestimmten Stellen zu finden waren, dauerte es lange, bis man eine kleine Schale von ihnen beisammen hatte.

Doch sie sofort zu Essen wäre eine Sünde gewesen, denn Großmutter wusste etwas besseres: Sie zerdrückte die Beeren und rührte sie mit Sauerrahm und etwas Süßstoff zum schmackhaftesten Leckerbissen überhaupt.
Kein Joghurt, Shake, oder Eischreme weder im Handel und noch im Restaurant oder an der Bar konnte mir je wieder so eine Gaumenfreude bereiten, wie Großmutters Walderdbeeren-Rezept.

Ach ich vermisse diese Zeit … denn solche Gourmetstücke kennt man nur, wenn man am Land aufgewachsen ist. Zwar schätze ich die Warenvielfalt in den Wiener Läden, aber an Großmutters Walderdbeeren kommt einfach niemand heran.

Fazit

Und so kommt es, dass ich auch heute vor allem im Sommer an vielen Arbeitstagen die Erdbeerschale mit ins Büro nehme und dann Stück für Stück wegputze.

Es gilt der klassische Ablauf:

Write a C++ line

Eat a strawberry

Goto 1

Es ist zwar ärgerlich, wenn man den Genuss auch an der “klebrigen” Tastatur erleben darf … aber für Erdbeeren muss man auch ein paar Opfer bringen.

Mahlzeit!

Kein Safe-Bool Idiom?

2022-05-29T13:00:00+02:00

Das Safe-Bool Idiom wurde früher jedem eingetrichtert, der daran dachte eigene Smart-Pointer Strukturen zu bilden.

Doch plötzlich, mit dem Aufkommen von C++11 und seinen Nachfolgern, verschwand dieses Mysterium wieder …

Objekte sind (besonders im System-nahen Bereich) oft nur Wrapper um native Konstrukte (z.B. aus der C Welt).
Man nennt solche Dinge auch gerne “Smart-Handles” als Anlehnung an Smart-Pointer und viele von ihnen haben die Eigenschaft, dass sie auch “leer” oder “ungültig” sein können.

Und deshalb hätte man gerne, dass solche Objekte möglichst einfach “ausge-if-t” werden können, so wie das hier:

 1HandleWrapper handle;
 2...
 3if(handle)
 4{
 5  do_something_with(handle);
 6}
 7else
 8{
 9  throw std::runtime_error("Nothing to do");
10}

Das ist eigentlich alles kein Problem, denn da schreibt man einfach:

 1class HandleWrapper
 2{
 3public:
 4  bool empty() const
 5  {
 6    return my_secret_impl() ? true : false;
 7  }
 8
 9  operator bool() const
10  {
11    return !this->empty();
12  }    
13};

Und schon klappt der if Aufruf.

Doch unglücklicherweise klappt dann noch viel mehr, wie z.B.:

1bool b = handle;     // handle -> bool
2int i = 42 + handle; // handle -> bool -> int(1)
3void foo(long l);
4foo(handle);           // handle -> bool -> long(1)
5if(handle == handle2); // (handle -> bool) == (handle2 -> bool)

Und schon regiert das absolute Chaos.

Safe Bool über exotische Pointer

Weil bool sich in jeden anderen Integer konvertieren lässt, kam der Gedanke auf, dass man einen anderen Typen braucht, der auch gegen true / false auswertbar ist aber nicht automatisch in Rechnungen oder Vergleichen aktiv wird.

Die Lösung fand man in einem an den Typen gebunden Methoden-Pointer, der im true Fall auf eine existierende private Methode zeigt, und im false Fall ein NULL-Pointer wird.

 1class HandleWrapper
 2{
 3private:
 4  void useless_function() const 
 5  {    
 6  }
 7
 8public:
 9  typedef void(HandleWrapper::*safe_bool_type)() const;
10
11  operator safe_bool_type() const
12  {
13    return this->empty() ? 0 : &HandleWrapper::useless_function;
14  }
15};

Unser if(handle) findet dann einen “primitiven” Pointer-Typen, der ausge-if-t werden kann und nutzt ihn “implizit”.

Wenn man das ganze jetzt noch in eine Template-Klasse wirft, die als Basisklasse eines “aus-if-barem” Objektes genutzt wird, landet man bei der Implementierung, die ich im GATE Framework immer noch einsetze um C++98/03 kompatibel zu sein.
Man kann z.B.: den safe-bool cast immer auf operator!() umleiten und diesen implementieren.
Dann hat man sowohl if(x) und if(!x) erledigt:

 1template<class T> class SafeBoolBase
 2{
 3private:
 4  void safe_bool_method() const { }
 5
 6public:
 7  typedef void(SafeBoolBase::*bool_type)() const;
 8
 9  operator bool_type() const
10  {
11    T const& derived_impl = *static_cast<T const*>(this);
12    return !derived_impl ? 0 : &SafeBoolBase<T>::safe_bool_method;
13  }
14};
15
16class MyIfableType : public SafeBoolBase<MyIfableType>
17{
18public:
19  bool operator!() const
20  {
21    ...
22  }
23};

C++11 und explicit operator bool()

In C++11 ist dieser verdrehte Pointer-Kunstgriff nicht mehr notwendig, denn eine Funktion explicit operator bool() const bedient nur noch wirklich explizit casts oder eben if(x), lässt aber Rechnungen oder Vergleiche hart abblitzen.

Vor C++11 war explicit nur dem Konstruktor vorbehalten und konnte nicht auf Operatorfunktionen angewendet werden. Konvertierungen waren damals also immer “implizit”.

Die explizite Operatorfunktion macht sogar den bool operator!() const in einige Szenarien unnötig, denn ein
if(!x) landet ebenfalls im explicit operator bool() const und dreht sein Ergebnis einfach um.

Fazit

Das Safe-Bool Idiom gerät bereits in Vergessenheit, denn junge Programmierer kennen es schlicht weg nicht.

Und obwohl ich die Eleganz des neueren Standards hier sehr schätze, hat das Safe-Bool Idiom trotzdem einen hohen Lehrwert:
Genau weil ich damals vor 15 Jahren über implizite Konvertierungen von operator bool gestolpert bin, wurden mir viele Details des Typensystems bewusst, die einem sonst verborgen bleiben.

Daher meine Empfehlung an alle:

Lernt beide Welten kennen!
Die alte wie die neue.
Nur so kann man Verständnis und eine bessere Zukunft aufbauen.

5.25 Floppy Disks

2022-05-28T13:00:00+02:00

5.25 Zoll Disketten sind die ältesten Computer-Medien, die ich besitze. Und aus gegebenem Anlass hatte ich (nach 20 Jahren) wieder mal Lust und Laune, meinen alten Rechner mit IDE und Diskettenanschlüssen zu aktivieren und meine 5.25er durchzuprobieren.

Dass ich mit 5.25 Zoll Disketten überhaupt noch in Kontakt gekommen bin, lag an meiner stets gebrauchten veralteten Hardware und so stand Mitte der 90er Jahre mein erster PC auf dem Tisch, der eigentlich in die 80er gehörte:
Ein 80386 Klon mit einem 3.5 Zoll und einem 5.25 Zoll Laufwerk.

Und genau dieses 5.25 Zoll Laufwerk hat in den Folgejahren in mehreren Gehäusen gedient, und hängt aktuell an meinem Athlon XP 2600 aus der frühen Mitte der 2000er.

Meine ersten QBasic Programme wurden darüber auf den “großen dünnen” Disketten gespeichert, die damals ein wenig billiger waren, als die “modernen” 3.5 Zoll Nachfolger.

Und als meine alte Schule anfing, ihren Diskettenvorrat ihrer noch älteren IBM 8086 Systeme zu entsorgen, fing ich einige davon vor der Mülltonne ab.

Laufwerk

Das massive Laufwerk belegt gleich viel Raum wie ein klassisches 5.25 Zoll CD/DVD Laufwerk und wird über einen alten Molex Stecker (12V und 5V) mit Strom versorgt. Der Slot-Anschluss unterscheidet sich sehr von den neueren IDE-Anschlüssen, die über Pin-Stecker mit dem Kabel zum Mainboard verbunden werden.

Früher gab es dafür eigene erweiterte Diskettenanschluss-Flachkabel, die für jedes der beiden möglichen Laufwerke zwei Anschlüsse bereitstellte (also in Summe 4 Stecker).

Eine eingelegte Diskette musste mit einer Klappe “fixiert” werden. Diese Klappe senkte nämlich den Lese-Schreibkopf und den Motor herab, damit er die Diskettenscheibe bewegt und bearbeitet werden konnte.
Gleichzeitig verhinderte sie, dass die Diskette im laufenden Betrieb wieder entfernt werden konnte.

Man musste stets die Klappe öffnen um das Medium wieder entfernen zu können.

Ein ganz besonderes Merkmal dieser Laufwerke war ihre Betriebslautstärke. Denn sobald ein Datenträgerzugriff erfolgte, startete hörbar der Motor und dann vernahm man krachende Geräusche, wenn der Lese/Schreibkopf vor und zurückbewegt wurde.

Man konnte stets hören, was das Laufwerk gerade tat. Wurden Daten sequentiell von vorne nach hinten gelesen oder die Diskette formatiert, glich das Geräusch einem Metronom, wo ein lautes Ticken den (kleinen) Spurwechsel in regelmäßigen Intervallen andeutete.

Freie Zugriffe im Dateisystem “ratterten” lauter und ungleichmäßig, wenn der Kopf zwischen vielen Spuren mal weiter mal kürzer bewegt wurde.
Das Öffnen von zwei Dateien ertönte etwa so:
traaaa-traaa-traaaaaaa tak-tak-tak-tak-tak-tak-tak traaaaa-traaaaa tak tak tak tak

Ganz interessant waren fehlerhafte Disketten, wo der Schreibkopf sehr schnell immer auf die gleiche Position gesetzt wurde und dann nochmal vollständig ausgerichtet wurde um den Leseversuch zu wiederholen.
Das hörte sich etwa so an:
traaaaaaa t-t-t-t-t-t-t-t-t-t-t-t-t-t-t traaaaaa t-t-t-t-t-t-t-t-t

Soa wusste man rein akustisch, dass das Betriebssystem gleich einen Lesefehler melden würde.

5.25 Zoll Disketten-Varianten

Die Daten werden auf der Diskette in Spuren (Cylinder oder Tracks, also Kreise auf der Scheibe) geschrieben, die in Sektoren unterteilt sind.
Ein kleines Loch in der Datenscheibe lässt das Laufwerk erkennen, wann eine Umdrehung fertig und der nächste Sektor 0 erreicht ist.
Die Diskette konnte entweder nur auf einer Seite beschrieben werden (Single-Sided) oder auf beiden (Double-Sided), was dann durch die Anzahl der benutzten Lese/Schreib-Köpfe des Laufwerks (Heads) realisiert wurde.

Ja nach Qualität des Mediums lassen sich mehr oder weniger Seiten, Spuren und Sektoren auf einer Diskette unterbringen.
Physikalisch adressiert wurde nach dem CHS (Cylinder, Header, Sector) Schema. Der logische Sektor 0 befand sich also an
Spur (Cylinder) 0, Kopf (Head) 0, und Sektor 0.

Ich kenne grundsätzlich 3 Formate (4 wenn man das Toshiba Spezialformat einbezieht):

360 KB, DD (Double Density), Double-Sided (DS) mit 40 Spuren und 9 Sektoren
180 KB, wie zuvor, eben nur auf einer Seite formatiert (40 Spuren, 9 Sektoren).
1.2 MB, HD (High Density), Double-Sided (DS) mit 80 Spuren und 15 Sektoren

Single Density Disketten sind mir nie untergekommen (so weit ich weiß).

Fehlerrate

Die meisten Daten habe ich schon vor vielen Jahren von den Disketten wegkopiert, womit ich heute nur mehr wenige übrig habe, die “prüfbare” Daten beinhalteten, doch der Großteil funktioniert offenbar noch und hat alle Daten gehalten.

Meine durchschnittliche Fehlerrate ist aber dennoch etwas höher und das liegt an einem absoluten Billigfehlkauf Ende der 90er.
Man erkannte die mangelhafte Qualität am lieblosen logofreiem Papiersticker und dem furchtbaren Reibgeräusch, sobald die Schreibe zu rotieren begann.
Man hätte diese Varianten eher Schleifkette statt Diskette nennen sollen.

Schon damals fielen mir viele dieser Disketten schon am ersten Arbeitstag aus. Heute funktioniert keine einzige mehr und wenn man die Datenscheibe vor eine Lichtquelle hält, erkannt man die Kratzspuren, wo sich das Material bereits zersetzt hat, oder durch Rauheiten in der Plastikhülle abgekratzt wurde.

Doch diverse Qualitätsdisketten aus den 80er Jahren liefern immer noch zuverlässig ihre Daten und ließen sich heute im Test fehlerfrei neu formatieren.

Schreibschutz

Bis heute “legendär” ist die Schreibschutz-Ecke (write-protect-notch) auf der rechten Seite einer jeden 5.25 Zoll Diskette.
3 cm von oben wurde ein 6 x 4 mm Rechteck aus der Schutzhülle weggestanzt, womit das Laufwerk erkennen konnte, dass die Diskette beschreibbar ist.

Wenn man diese “Ecke” mit einem undurchsichtigen Sticker überklebte, galt die Diskette als schreibgeschützt, womit das Laufwerk nur noch Lesevorgänge zuließ.

Solche Disketten-Klebestreifen waren bei den teureren Modellen einfach bei, oder konnten separat gekauft werden.
Oder man nutzte einfach ein Stück Papier mit einem üblichen Klebeband um die Ecke “abzudichten”.

Formatierung

Damals unter DOS nutzte man das klassische FORMAT A: um eine uninitialisierte Floppydisk nutzbar zu machen oder um eine zu löschen und zu testen.

Mit dem Parameter /F:xxx konnte man die Größe in Kilobytes angeben, womit man explizit mit /F:180, /F:360 oder /F:1200 die Sollkapazität angeben konnte.
Das funktionierte nur mit Kapazitäten kleiner oder gleich der korrekten Größe. Man konnte also keine 360 KB Disk auf 1.2 MB hochformatieren, doch eine 1.2 MB Diskette wurde so auf 360 KB limitiert.

Irgendwo zwischen Windows 2000, XP und Server 2003 hat Microsoft diesen Parameter jedoch auf 1440 für 3.5 Zoll Disketten reduziert. Alle anderen Angaben werden abgelehnt.

Es gibt jedoch noch die Low-level Parameter /T:tracks und /N:sectors mit denen man explizit die korrekten Größen angeben kann:

360 KB: format b: /T:40 /N:9
(40 Spuren * 9 Sektoren * 2 Seiten * 512 Bytes pro Sektor)
1.2 MB: format b: /T:80 /N:15
(80 Spuren * 15 Sektoren * 2 Seiten * 512 Bytes pro Sektor)

Für eine Limitieren auf nur eine Seite konnte ich keinen Parameter finden. Schade, denn früher gab es den Trick, eine doppelseitige Diskette nur einseitig zu formatieren, dann stanzte man selbst eine Ecke auf der linken Seite aus und konnte die Diskette so auf der zweiten Seite separat formatieren, in dem man sie verkehrt einlegt.

So konnte man auf jeder Seite der Diskette ein eigenes Dateisystem anlegen. Nützlich war das eigentlich nicht, eher eine Spielerei. Aber man konnte so auf einer Diskette zwei unterschiedliche bootbare Betriebssysteme halten. (Denn zu DOS 2/3 Zeiten belegten die Startdateien nicht mehr als 100 KB.)

Fazit

Augen auf! Liebe SD-Karten Hersteller.

Denn viele “modernen” Medien überleben keine 5 Jahre und verlieren dabei ihre Daten.

Doch 5.25 Zöller halten diese 30 Jahre und länger.

Mir ist natürlich schon klar, dass 360 KB und 1.2 MB mit heutigen Gigabyte SD-Karten nicht vergleichbar sind.
Aber wenn ich nun meine 100 KB Textdatei aus der Schule noch lesen kann, jedoch das 10 MB Word-Dokument (mit gleichwertigem Textinhalt!) von der SD-Karte am Smartphone einfach nicht mehr öffnen kann, dann werde ich wieder zu folgender Aussage verleitet:

Früher war alles besser!

Ein Hoch jedoch auf die kultigen 5.25 Zoll Disketten … die heute wohl nur noch die alten Hasen kennen.
… damals … als man den Datentransfer noch hören konnte.

Nachtrag: Diskette zerlegen

Wenn man schon eine defekte Diskette entdeckt hat, kann man auch die Hülle auffalten und einen Blick hineinwerfen:

Die Hülle ist einem Kuvert ähnlich und die Faltstreifen sind mit Druckpunkten an die Hülle “getackert”. Mit einem Taschenmesser lässt sich das leicht wieder “aufdrücken”.
Die Magnetscheibe ist an den Innenseiten durch eine Schutzfolie an der Hülle ummantelt.
Die faserige Struktur der Schutzfolie ist in den 30 Jahren offenbar auch schon sehr vergilbt.
Auf der Magnetscheibe kann man schön das “Index-Loch” sehen, über welches das Laufwerk den Beginn des ersten Sektors feststellen kann, wenn sich die Scheibe dreht.
Aufgefaltet besetzt eine solche Diskette eine recht große Oberfläche

Windows User-Mode Scheduling entfernt

2022-05-22T13:00:00+02:00

Tja, einen offenen Punkt auf meiner Liste kann ich jetzt unerledigt abhaken: nämlich die Ums-APIs, die mit Windows 7 eingeführt wurden.

Denn mit der Einführung von Windows 11 sind diese Funktionen beinhart entfernt worden, bzw. zu ERROR_NOT_SUPPORTED degradiert worden.

Ich bin es von Microsoft eigentlich gewohnt, dass APIs - egal wie nutzlos sie sind - für alle Ewigkeiten im Betriebssystem verbleiben.
Natürlich gibt es da auch ein paar “High-Level”-Ausnahmen, wenn z.B.: der Microsoft-Agent (ein Comic-Assistent zum Vorlesen von Texten) samt seiner COM API verschwindet, weil ihn nach 2003 ohnehin keiner mehr nutzte.

Doch Kernfunktionen rund um Prozess- und Thread-Verwaltung sind seit spätestens Windows 2000 “fix” im kernel32 und wachsten mit jeder neuen OS-Version an, entfernt wird aber nichts mehr.

User Mode Scheduling

Letztes Jahr (zu Beginn meiner Koroutinen Analyse) erinnerte ich mich wieder an ein paar Vorträge zu einer “neuen” Threading API, abgekürzt UMS, die einige Probleme mit Microsofts Fibers Ansatz lösen sollte.

Allgemeiner Code weiß oft nichts von Fibers, glaubt aber zu wissen, in einem Thread zu laufen und nutzt daher explizit oder implizit Thread-local-storage (TLS).
Genau das kann mit Fibers dann Probleme erzeugen, wenn zwei Fibers Code ausführen, der TLS nutzt und schon kommen States durcheinander.

Randnotiz: Die MS CRT Implementierung nutzt übrigens FLS (Fiber-Local-Storage) für Funktionen wie strtok() und ist damit sowohl Thread- als auch Fiber-sicher.
Doch Anwenderprogramme sind nicht immer so flexibel ausprogrammiert.

UMS sollte mit einer neuen API eine neue Art Thread einführen, dessen Scheduling vom Usermode-Prozess aus verwaltet werden kann.

Bisher hatte ich noch nie einen Grund mich mit dieser Technik auseinander zu setzen und wollte das im Zuge des GATE Projektes nachholen, doch mit dieser neuesten Wendung wird daraus wohl nichts.
Schließlich bringt es nichts, eine API zu implementieren, die selbst Microsoft als “unnötig” eingeschätzt hat und auch keinen “historischen” Bezug hat.

Fazit

Hmm … ich kann also nichts weiter zum UMS sagen, habe leider keine Erfahrung damit und werde es vermutlich auch in Zukunft nicht nutzen. Ich weiß nur, dass von 2009 bis 2021 existiert hat.

Ein Detail habe ich dennoch aus der UMS API entnommen:
Koroutinen sind im GATE Framework ähnlich aufgebaut, denn dort wird auch ein “normaler” Thread als Scheduler eingesetzt um zwischen Koroutinen hin und her zu springen.
Und im UMS hätte es auch so einen Scheduler-Thread gegeben.

Ein altes Video aus der frühen Channel-9 Zeit gibt (damals wie heute) einen kleinen Überblick über diese Schnittstelle:

M.2 SSD 2242 Adapter zu 2280

2022-05-21T13:00:00+02:00

Ein Betriebssystem ist einfach zu wenig … doch mit 250 GB wird es dann eng.
Und so wollte ich heute meinem Laptop eine andere SSD verpassen.

Doch der war nur auf M.2 SSDs mit der Größe 2280 (also 80 mm Länge) ausgelegt, ich hatte aber nur eine mit Größe 2242 (also 42 mm Länge) in der Schublade.

Welch Glück, dass ein 3D Drucker das Problem sofort lösen kann.

Mein alter HP-250-G5 (mit einen Core-i3, 8 GB RAM und 250 GB SSD) ist gerade noch “akzeptabel” für die tägliche Arbeit (wenn gleich Microsoft Teams spürbar immer schlechter darauf ausführbar wird).

Doch ein OS ist mir zu wenig, ich hätte gerne Windows 10, Windows 7 und Linux darauf (wie so oft bei meinen Teststellungen) und Virtualisierung wäre auf der Maschine wirklich kein Vergnügen.

Als ich das Ding aufschraubte, fiel mir die “lange” M.2 SSD auf, für die ich keinen Ersatz zu Hause hatte, während noch eine “kürzere” 512 GB Variante vorrätig war.

Adapter Modell

Mein erster Gedanke:

Mal schauen ob auf Thingiverse jemand ein kleines Adapter-Plastikstück modelliert hat, um den M.2 Chip zu “verlängern”.

Und tatsächlich gibt es so etwas, und zwar unter dem Titel m.2 ssd adapter 2242 to 2280

Also:

Download
Mit CURA eine .gcode Datei für meinen Ender-3 erstellen.
SD-Karte rein
Drucken
Ausprobieren …

Fu**! Geht nicht!

Denn der Adapter umklammert die M.2 mit einer über einem 1cm eng anliegenden Umrandung, doch meine 2242 Variante ist schon 5 mm vom Rand entfernt mit SMD Bauteilen und dem Speicherchip flächendecken bestückt.

Man kann den Adapter also nicht über den Chip stülpen.

Lösung: Bescheidung

Die Store-App 3D Builder von Microsoft unterstützt allerdings ein paar einfache Bearbeitungsmethoden für 3D Modelle und dazu gehören:

Rotation
Aufsplitterung

Man kann beim Aufsplitten nur unterscheiden, ob man oben oder unten was wegschneiden will, also musste ich den Adapter zuerst 90 Grad rotieren, dass er aufrecht steht und dann konnte ich per “Augenmaß” etwa so viel wegschneiden, dass nur noch 5 mm der Halterung übrig waren.

Das wurde dann wieder zurück rotiert, gespeichert, wieder für den Ender-3 vorbereitet und gedruckt.

15 Minuten später, und voila: Es passt.

Fazit

Und wieder zeigt sich, wie “cool” es ist, sich Dinge selber basteln zu können.

Früher hätte ich vermutlich lange nach einem Händler suchen müssen, um entweder einen solchen Adapter zu finden, oder ich hätte eine neue M.2 SSD im richtigen Format kaufen müssen.

Und selbst wer keinen 3D Drucker zu Hause hat, findet in der Stadt schnell einen Shop, der solche Druckaufträge binnen eines Tages ausführen kann.
… und das ist allemal schneller, als lange Bestellprozesse absetzen zu müssen.

Somit kann ich hier vergnügt behaupten:

Heute ist einfach alles besser!

operator<()

2022-05-15T13:00:00+02:00

Jahre code ich herum, und dann passieren mir so unglaublich dumme Anfängerfehler, wie ein falsch implementierter operator<(). (C++ Operator overloading)

Und das Schlimme ist, dass man das nicht immer gleich mitbekommt, wenn plötzlich ganz andere Codes anfangen zu bocken.

Es wird also Zeit, das Thema zu “wiederholen” … so lange bis auch ich es richtig mache.

Datentyp als Mapping-Key

Es war einmal eine Datenverwaltung, die einen int als Schlüssel nutzte, um Datensätze in einer std::map leicht auffindbar zu halten.

Dann erkannte man, dass der int nicht eindeutig genug war, es sollte ein zweiter angefügt werden und so wurde aus:

1std::map<int, data_t> mapping;

ein

1struct int_key
2{
3    int a;
4    int b;
5};
6
7std::map<int_key, data_t> mapping;

Doch das funktioniert noch nicht, weil int_key Instanzen vergleichbar sein müssen, um in einer std::map benutzt werden zu dürfen.

Dafür schreibt man also eine operator<() Funktion, die zwei Instanzen vergleicht, denn (ohne zusätzlich Angaben) nutzt std::map ein std::less(x, y) für die Ordnung innerhalb seiner Elemente und std::less führt wiederum
return x < y; aus.

Und die Implementierung kann dann etwa so aussehen:

 1bool operator<(int_key const& k1, int_key const& k2)
 2{
 3  if(k1.a < k2.a)
 4  {
 5    // primary value less -> return true
 6    return true;
 7  } 
 8  if(k2.a < k1.a) /*OR: if(k1.a > k2.a) */
 9  {
10    // primary value greater -> return false
11    return false;
12  }
13  // primary values are equal -> use second
14  return k1.b < k2.b;
15}

Muss man mehrere Member vergleichen, kann man immer davon ausgehen, dass wenn ein Member kleiner ist als der im Vergleichsobjekt, dann ist das gesamte Objekt bereits “kleiner”. Ist ein Member größer, ist auch das gesamte Objekt größer. Sind beide Member aber gleich, geht man zum nächsten und wiederholt das Spiel, bis am Schluss der letzte Member entscheiden darf, wenn alle seine Vorgänger gleich waren.

So ist alles in Ordnung und eine std::map kann ihre Daten korrekt einordnen.

Und was wenn nicht ??

Ich habe neulich folgendes schlampiges Fabrikat abgeliefert:

1bool operator<(int_key const& k1, int_key const& k2)
2{
3  if(k1.a < k2.a)
4  {
5    return true;
6  } 
7  return k1.b < k2.b;
8}

Und dann brach die Hölle los.
Denn mit der Implementierung werden Größer/Kleiner Aussagen widersprüchlich. Hier ein Beispiel:

1x = (20, 8)
2y = (30, 7)
3
4x < y --> true (wegen: 20 < 30)
5y < x --> true (wegen: 30 !< 20 aber 7 < 8)

std::map kann std::less in beiden Richtungen nutzen, nämlich:

std::less(x, y): Ist x kleiner als y ?
std::less(y, x): Ist x größer als y ?

Und wenn beides true wird, ergeben sich fiese Abfrageschleifen.

So ist das Problem dann auch aufgefallen, nämlich als das Einfügen eines neuen Wertes plötzlich zu einer Endlosschleife wurde.

Dummerweise waren die Zahlen bei Tests zufällig so gestrickt, dass es mir nicht aufgefallen war.

Fazit

Peinlich! Peinlich! Peinlich!

Ja, Tippfehler passieren, aber ich habe schon auch ein Talent solche Kindergartenbeispiele zu versemmeln.

Ein weiterer “meiner” Klassiker ist:

1if(error_detected)
2{
3  continue_operation();
4}
5else
6{
7  cancel_due_to_error();
8}

Es ist einfach Schlampigkeit oder mangelnde Konzentration, die so etwas auslösen und genau das sollte einem beim finalen Durchlesen sofort auffallen.

Denn was man nicht vergessen darf: Software steuert heute alles. Und leider sind es dann solche Fehler, die böse Dinge auslösen.

Hoffentlich wird mir diese Peinlichkeit eine Lehre sein, damit ich in Zukunft genau hinsehe, wenn ich wieder mal so einen Blödsinn schreiben sollte.

Und vielen Dank an meinen Kollegen, der meinen Patzer herausgefunden hat, bevor er in produktiver Software breiten Schaden anrichten konnte.

dlopen(NULL, 0)

2022-05-14T13:00:00+02:00

Da Linux Distributionen hart daran arbeiten zu einander so inkompatibel wie möglich zu sein, suchte ich nach Strategien, wie man ohne Plattform-spezifische Linkereien so viel möglich an Features erhalten kann.

Aber um zu wissen, was einem überhaupt fehlt, muss man erst mal wissen, was man schon hat … und hier kommt dlopen ins Spiel.

Funktionen wie backtrace() oder getcontext() setcontext() und makecontext() swapcontext() sind zwar nicht 0815, aber auch nicht extrem selten. Schließlich helfen sie einem den Callstack “zu bearbeiten” oder Koroutinen oder eine spezielle Fehlerbehandlung zu implementieren.

Linux-Varianten, die mit der glibc aufgebaut wurden, integrieren diese Funktionen quasi in jeden Prozess, weil die glibc sie beinhaltet. Wie die “echte” Bibliothek heißt, ist versionsabhängig und grundsätzlich unbekannt, weil die Standard-Bibliothek automatisch gelinkt wird.

Ganz anders Alpine Linux oder andere Distros, die auf abgespeckte C-Libraries wie uClibc, musl-libc oder dietlibc aufbauen. Hier braucht man z.B.: libucontext.so.1 für die Context-Funktionen.

dlopen() ohne Bibliothek

dlopen bietet aber eine interessante Zusatzfunktion. Ruft man es nämlich mit

1void* process_handle = dlopen(NULL, RTLD_GLOBAL);
2void* ptr_function = dlsym(process_handle, "makecontext");

auf, erhält man Zugang zu allen bereits geladenen globalen Symbolen. dlsym kann nun von jeder Funktion, die bereits geladen ist, den Funktionszeigern ermitteln und zurückgeben.

Und auf diese Weise, kann man also zuerst “prüfen”, ob eine benötigte Funktion schon da ist.

Kein: if alpine, elseif debian …

Brauche ich also eine Funktion, die manchmal schon in der C-Bibliothek integriert ist und manchmal nicht, prüfe ich das zuerst mit dlopen(NULL) und nur wenn hier NULL zurückkommt, lade ich andere Bibliotheken und versuche mein Glück mit diesen.

Früher musste ich unseelige Spielereien wie

 1#include <my_lib/my_func.h>
 2typedef int(*my_func_ptr_t)(int param);
 3
 4#if defined(LINUX_MUSLIBC)
 5  void* my_lib = dlopen("libmy_lib.so", RTLD_GLOBAL);
 6  my_func_ptr_t my_func_ptr = dlsym(my_lib, "my_func");
 7#else
 8  my_func_ptr_t my_func_ptr = &my_func;
 9#endif

bemühen und den Code per CMake mit Hilfs-Makros anreichern.
Heute kann ich eine Array von Bibliotheksnamen anlegen und diese dann per Schleife durchlaufen lassen, wenn dlopen(NULL) eben nicht erfolgreich war.

Dieser Code ist dann OS-unabhängiger und läuft auf mehr Plattformen, weil er eben nicht per #ifdef auf eine Plattform fixiert ist.

Fazit

Das Thema, wie man Linux-Binaries baut, die überall laufen, ist ein schwieriges. Denn leider löst der Ansatz immer noch nicht das Problem, das z.B.: Alpine Linux und Debian zwei unterschiedliche Binaries brauchen.

Ich hatte auch schon mal mit dem -static Flag des GCC gespielt um absolut unabhängige Executables zu produzieren … doch bei denen funktioniert dann dlopen gar nicht mehr.
Womit der Ansatz leider auch wegfällt.

Zumindest wurden so wieder ein paar Makros wegrationalisiert.

Ein kleiner Schritt für die einzelne Projektdatei.
Aber ein großer für die Zukunft des Projekt.

WinCE Patches

2022-05-08T13:00:00+02:00

Mit jeder Plattform gibt es Probleme in Sachen Kompatibilität, aber mit keiner gibt es so viel wie mit Windows CE.

Und vermutlich beschäftigte ich mich genau deshalb immer wieder mit dieser eigentlich schon ausgestorbenen Umgebung, denn:

Ich liebe die Herausforderung.

Ich selbst habe mit WinCE eigentlich gar keine Probleme, doch leider haben eine Vielzahl anderer Bibliotheken ihre Probleme mit dem limitierten Funktionsset.

Und das liegt in erster Linie daran, dass der C-Standard nicht vollständig abgebildet ist. Das manifestiert sich folgendermaßen:

Ein Header fehlt (z.B.: stdbool.h oder io.h)
Funktionen sind im Header, aber nicht in der C-Runtime implementiert (z.B.: time() oder clock())
Funktionen fehlen im Header (z.B.: strcoll())

Ein fehlender Header lässt sich ganz leicht ersetzen. Man fügt ihn dem eigenen Projekt hinzu inklusive einer Implementierung, die z.B.: direkt auf WinAPI Aufrufe umleitet.

Wenn nur die Implementierung einer C-Funktion in der C-Runtime fehlt, verfährt man ähnlich: Man fügt einfach eine neue Implementierung im eigenen Projekt an und schon kann das “nicht-aufgelöste-Symbol” gefunden werden.

Am schlechtesten ist die dritte Variante, nämlich das Fehlen einer Funktion im Header und der CRT.

Viele Header in WinCE sind nur Umleitungen auf stdlib.h in der vieles notwendige enthalten ist. Doch leider fehlen die meisten IO-Funktionen wie freopen(), remove() oder rename().

Nutzt man nun eine Bibliothek, die selbst nur stdio.h einbindet und sich eine Funktion dahinter erwartet, treten seltsame Seiteneffekte auf.
Denn C nutzt den Funktionsaufruf als Deklaration mit eine undefinierten Prototyp wie:
int c_function(...);

Fügt man nun seine eigene Implementierung mit der richtigen Deklaration parallel hinzu, gilt die One-Definition-Rule als verletzt, weil das gleiche Symbol zwei mal unterschiedlich definiert wurde.
z.B.:

1int c_function(...);          //< implicit declaration
2void c_function(char const*); //< correct declaration

Platform Support Layer

Im Platform-Layer des GATE Projektes nutzte ich bisher ein wince Unterverzeichnis, in dem einige Header mit Inline Funktionen enthalten waren. Diese Header wurden dann von CMake aus adressiert, um unter Windows CE meine manipulierten Header zu laden und nicht jene C-Standard-Bibliothek.

Doch leider nahm die Menge der notwendigen Funktionen zu und daher brauchte ich einen neuen Ansatz.

stdcpatches Bibliothek

Die Hilfsbibliothek stdcpatches ist eine statische Bibliothek im libs Ordner des GATE Projektes und soll eine Vielzahl von std-c Header und Implementierungen nachbilden.

Für jede Plattform und jeden Typ von C-Header gibt es Unterverzeichnisse, die alle notwendigen Dateien beinhalten.
Am Ende entscheidet dann CMake, welche Ordner als Include-Directories eingebunden oder übersprungen werden sollen.

Auf diese Weise können Patches für Plattformen wie Windows CE oder Compiler wie MSVC eingebaut werden.

Fordert eine Bibliothek wie libpng z.B.: errno.h an, existiert dafür in stdcpatches ein eigener Header errno.h, der fehlende Makros und Definitionen nachliefert. Parallel dazu veröffentlicht eine eigene wince_errno.c Einheit die Implementierung innerhalb der statischen Bibliothek.

Für den MSVC allgemein existieren Header wie sys/stat.h oder stdint.h, die in älteren Versionen nicht enthalten waren. Auch hier bindet CMake die Dateien nur bei älteren Compilern ein und verzichtet darauf, wenn sie in neuen Versionen schon enthalten sind.

Fazit

Die Umstellung von “kleinen Patches” in gate/platform/wince auf eine eigene Bibliothek stdcpatches war eine größere und auch recht mühsam.
Dennoch glaube ich, dass es mir langfristig mehr bringt, solche Codeverrenkungen kontrolliert an genau einer Stelle durchzuführen.

Schließlich hat die bisherige Implementierung den Abhängigkeitsbaum korrumpiert, denn externe Bibliotheken sollten vor dem GATE Framework Code kompiliert werden. Doch nur für WinCE wurden einige wenige Include-Directories schon vorher aus dem GATE-Projekt geladen.

Jetzt sind externe Bibliotheken in Sonderfällen von der Bibliothek stdcpatches abhängig, und am Ende wird alles zusammen vom GATE Projekt konsumiert.

graph LR GATE[[GATE
Framework]] EXT[[External
Libraries]] PATCH[[stdcpatches]] STDC[[STD-C
Libraries]] OS[[OS native API]] GATE --include--> EXT EXT --include--> PATCH EXT --include --> STDC PATCH --include--> STDC PATCH --include--> OS

Ein Vorteil ergibt sich daraus außerdem: stdcpatches kann jetzt auch ohne das GATE Projekt mit anderen Libs für Fremdprojekte benutzt werden.

Picard, Moon Knight, Strange und Strange New Worlds

2022-05-07T13:00:00+02:00

Also, diese Woche hatte es so was von in sich: Zwei Serienstaffeln endeten, eine startete und ein neuer Blockbuster läuft im Kino:

So viel Stress hatte ich schon lange nicht mehr …

Marvel’s Moon Knight

Alle bisherigen Marvel Serien spannen Geschichten rund um Figuren aus den Marvel Filmen des MCU weiter, doch nun kommt Moon Knight und startet etwas ganz anderes: Ägyptische Götter

Diese suchen sich menschliche Avatare um die Erde zu beobachten, wollen aber in der Regel nicht eingreifen.

Und wäre da nicht ein Anhänger Ethan Hawke der verbannten Krokodil-Gottheit Ammit, die er wiederbeleben wollte, dann bräuchten wir nicht einen Helden, der das verhindert, und das ist der Moon Knight Oscar Isaac.

Der Mondgott Khonshu will die Wiederauferstehung Ammits verhindern und bringt dafür seinen Avatar in Stellung, der aber ein gröberes Problem hat, nämlich eine gespaltene Persönlichkeit.

Und so lebt die Serie von dem teils komischen Wechselspiel zwischen den Persönlichkeiten “Steven Grant” und “Marc Spector”. Der eine furchtloser Kämpfer, der andere mit dem Gemüt eines nervösen Museumsangestellten.

Die Serie ist echt witzig und auf jeden Fall eine einzige Ägypten Werbung. Unsicher bin ich mir allerdings, wie das ins Marvel Cinematic Universe passt und ob oder wie es daran anknüpft.

StarTrek: Picard (Staffel 2)

Wenn schon in der ersten Folge der zweiten Staffel ein Borg-Angriff erfolgt, der unseren alten Admiral Picard (Patrick Stewart) zwingt die schiffsweite Selbstzerstörungssequenz auszulösen und vermeintlich alle sterben, tja dann wissen wir, dass diese Staffel eine ganz andere Action bereitstellt, als die erste.

Doch wie schon damals in StarTrek: Next Generation taucht das Überwesen Q auf schickt den Hauptcast in eine andere Zeitlinie und gibt ihnen die Lösung eines Rätsels auf.

Von dort aus geht es zurück ins Jahr 2024, wo eine Veränderung der Zeitlinie verhindert (oder vielleicht ausgelöst) werden soll … StarTrek IV: Zurück in die Gegenwart lässt grüßen.

Womit wir schon bei meiner Kritik wären:

Ich erwarte, dass StarTrek in der Zukunft spielt.

Ja sicher, die Einzelfolgen, in denen per Zeitreise “die alte Erde” besucht wurde, sind alle toll, aber wenn ich nun 8 von 10 Folgen in den heutigen USA verbringen muss, nur um zu zeigen, wie schlecht vieles ist, und wie gut es hätte sein können, dann ist das nicht mehr StarTrek.

Doch die letzte Folge brachte ein Ereignis hervor, das zwar auch viel Herz-Schmerz zeigte, aber dennoch so unerwartet und “gut” war, dass ich der restlichen Handlung einiges verzeihe.
Sie war das genaue Gegenstück der letzten Folge der ersten Staffel.
Denn das Ende der ersten Staffel hat mir vieles versaut.
Das Ende Ende der zweiten hat vieles gerettet.

Fazit: Es ist StarTrek und damit Pflicht.

StarTrek: Strange New Worlds

Captain Pike Anson Mount und Lt. Spock Ethan Peck durften wir ja schon in der zweiten Staffel von StarTrek: Discovery begrüßen, doch jetzt erhalten sie (wie der zurück auf der USS Enterprise) ihre eigene Serie und dürfen damit die ursprüngliche Enterprise noch vor Captain Kirk durch das Galaxie springen lassen.

Das krasseste ist natürlich das Raumschiff Enterprise selbst, denn mit jeder neuen Serie sieht das Schiff moderner aus und hat inzwischen überhaupt nichts mehr mit der Darstellung zu tun, die wir in der ursprünglichen Serie gesehen haben.

Die Serie soll das alte Schema wiederbeleben, dass jede Folge ein anderes Problem (== anderer Planet) behandelt wird. Verstrickte Zusammenhänge wie in StarTrek Picard oder Discovery sollen reduziert werden.

Und von daher hat mich die neue Serie mit der ersten Folge schon überzeugt. Mal sehen wie es weitergehen wird.

Dr Strange

WTF! So viele brutale Tötungen habe ich in einem Marvel Film noch nie gesehen. Kein Wunder, dass der Film also Horrorstreifen angekündigt wurde.

Zwar muss man sagen, dass ein echter Horrorfilm noch viel mehr Grusel beinhalten muss, aber für Marvel war das neu.

Wer den Film vollständig verstehen will, muss die Serie WandaVision gesehen haben, wo Wanda Maximoff Elizabeth Olson zur Scarlet Witch wird und am wichtigsten: Wo man den Hintergrund um ihre Kinder mitverfolgen kann.

Dass die beiden Jungs Billy (Julian Hilliard) und Tommy (Jett Klyne) im Film waren war mein persönliches Highlight, denn ich mochte die beiden bereits in der Serie sehr.

Thematisiert wird das Multiversum und eine neue Figur, America Chavez (Xochitl Gomez), die durch dieses reisen kann, aber nicht wirklich Herr über diese Fähigkeit ist. Immer wenn das Mädchen Angst bekommt öffnet sich ein Portal und schon wechsel sie in eine andere Welt.

Und Angst hat sie zurecht, weil dunkle Mächte ihre diese Fähigkeit entziehen wollen. Letztendlich landet sie bei “unserem” Dr. Strange, dessen Aufgabe es wird, sie zu beschützen.

Der interessante Teil des Films ist, dass man nie so richtig weiß, wer der Gute und wer der Böse ist und wann sich der Status ändert. Und wenn die Grenzen zwischen den Welten überschritten werden und die Protagonisten auf ihre Alter-Egos in anderen Universen treffen, ergeben sich interessante neue Aspekte.

Leider kann man hier wirklich nichts weiteres sagen ohne einem den Film zu verderben und das möchte ich keinesfalls.

Dieses Spektakel muss man im Kino gesehen haben!

Ich hätte zwar gesagt:

Weniger ist mehr!

Und vielleicht hätte man eine Welt herauskürzen können und mehr Interaktion zwischen den Charakteren setzen sollen, denn der Film wirkt schon recht “gehetzt”, wenn man stets neue Welten findet und bald danach wieder verlassen muss.

Ich hatte jedenfalls meinen Spaß bei der Premiere am Mittwoch und bin jetzt wieder um so gespannter, wie es weiter geht.

Denn ein dritter Dr. Strange Teil ist quasi schon angekündigt und auch wissen wir nicht, wie es nun mit Wanda Maximoff weitergehen wird.

Es bleibt also spannend.

Fazit

Was für eine Woche!
Crazy … aber trotzdem geil.

Weisheit ohne Zahn

2022-05-06T13:00:00+02:00

Dass ich die beste Zahnchirurgin aller Zeiten erwischte hatte, war mir klar, als sie bei der Vorbesprechung den Satz einleitete mit:

Sie sind ja jetzt schon ein bisschen über dem Teenager-Alter …

um mich dann vorzuwarnen:

… da wird die Entfernung des Weisheitszahns ein bisschen länger dauern.

Jetzt ist er draußen, und mir geht’s trotzdem (noch) gut.

Das hat mich wirklich gefreut, dass ich “nur ein bisschen” über dem Teenager-Alter liegen soll. Da hätte ich eigentlich spontan ein Tränchen rausdrücken sollen und antworten müssen:

So etwas Liebes hat noch nie jemand zu mir gesagt.

Aber Spaß bei Seite.

Vor 5 Jahren musste bereits mein rechter am Unterkiefer gezogen werden, weil durchgerostet war. Der linke durfte bleiben, doch nun begann auch Karies seine Spur zu ziehen. Zwar ohne Schmerzen doch nun wurde empfohlen ihn vorsorglich entfernen zu lassen.

Interessant ist, dass man in der Chirurgie verwundert war, dass mir dieser nicht gleich im Jungendalter entfernt wurde, doch das hatte man mir bei den jährlichen Kontrollen nie angeraten.

Termin 10 Uhr

Gestartet wurde mit 2 ordentlichen Spritzen zur Betäubung, die ich 20 Minuten lang “einwirken” lassen musste. Am Unterhaltungsmonitor, der heute in keiner Praxis mehr fehlt, lief Popeye, der ständig Bluto aufs Maul schlug … auch ein interessanter Aspekt.

Dann ging es los. Über eine halbe Stunde lang wurde gebohrt, herausgebrochen und weiter gebohrt.
Gespürt habe ich nicht das geringst, obwohl ich permanent darauf wartete, dass sogleich schlimme Schmerz einsetzen. Denn der Bohrer am Kieferknochen lässt den Schädel durchaus mitvibrieren. Man spürt das zwar nicht, aber es hört sich furchtbar an.

Einige Bohrer gaben an mir den Geist auf und mussten durch neue ersetzt werden. Meine Ärztin meinte, dass sie schon lange kein so hartes Zahnmaterial mehr gesehen hätte.
Das ist wohl der Grund dafür, dass der Eingriff häufiger im Teenager-Alter gemacht wird, wo der Knochen noch viel weicher ist.

Doch mit einigem Werken und Ziehen wurde der Zahn mit seine vier verdrehten Wurzeln, der seitlich tief vergraben war, letztendlich entfernt.

Hier zeigt sich wieder mal die Kunst der Medizin, die einem hochspezialisiertem Handwerk gleicht.

Medikation

Meine letzte Entfernung vor 5 Jahren hatte einen Seiteneffekt: Die Heilung setzte nicht wie gewünscht ein und zwei Tage später fingen die Schmerzen so richtig an.
Ich hoffe, dass diesmal alles “normal” verläuft, womit ich noch ein paar Tage Schmerzmittel und Antibiotika nehme und dann alles ganz natürlich weiter verheilt.

Seractil forte 400mg sollen mir die anfänglichen Schmerzen nehmen und Augmentin 875 mg wird als Antibiotikum dienen.

Auch da erinnere ich mich daran, dass ich beim letzten Mal noch dachte:

Ach was, so schlimm war das nicht, die Schmerzmittel werde ich nicht aufbrauchen.

Alter Schwede, war ich am Ende froh, dass es diese Mittel gibt.
Wenn nämlich der ganze Kopf zu hämmern beginnt, ist man für jede Form der Linderung einfach nur dankbar.

Empfehlungen und Ausblicke

Keine Milch!

hieß es sofort, denn Milch dürfte die Aufnahme des Antibiotikums erschweren.
Anstatt dessen soll man “normal” essen, aber nichts Hartes, was die Wunde reizen könnte.

Auch soll man weiter (mit Vorsicht) die Zähne putzen aber nie durchspülen, weil das ebenso der Wundheilung schadet.

Wichtig ist auch, die Wange keiner Wärme auszusetzen, denn das kann zu einer starken Schwellung führen.
Zum Glück habe ich aber noch vom letzten Mal Gelkühlpacks, die man im Kühlschrank aufbewahrt und dann an die Wange legen kann um sie zu kühlen. Ein altes Stirnbad bindet nun das Gelpack an mich.

Fazit

Das war es dann also … mit meiner Weisheit.

Wie der weitere Verlauf sein wird, wird sich noch zeigen, aber ich habe ein gutes Gefühl da bisher alles reibungslos verlaufen ist.

Respekt kann ich der Zahnmedizin zollen, die heute in kürzester Zeit solche Eingriffe für den Patienten unkompliziert durchführen kann.

Keyboards

2022-05-01T13:00:00+02:00

Und wieder sind 40 Euro sinnlos verbrannt, weil ich nicht genau genug aufgepasst habe.
Aber wieso ist es heute notwendig aufzupassen, dass eine Tastatur auch alle üblichen Tasten hat?

Denn früher gab es Standards … heute gibt es jedoch Chaos.

In Ländern mit lateinischen Buchstaben gibt es grundsätzlich zwei Tastaturlayouts:

ANSI: Das originale amerikanische Format, das man leicht an der einzeiligen ENTER Taste erkennt.
ISO: In unseren Breiten bevorzugt benutzt und bekannt durch seine zweizeilige Eingabe-Taste.

Die meisten europäischen Länder nutzen ISO, belegen aber die Tasten entsprechend ihren Bedürfnissen, wie z.B. das deutsche Y und Z, die in den meisten anderen Ländern im Verhältnis zu uns vertauscht sind.

Im amerikanischen ANSI sind einige Tasten breiter (wie ENTER und SHIFT), weil sie keinen Raum für Sondertasten wie unsere Umlaute vorsehen und an eben diesen Plätzen Zeichen wie ; oder \ verbaut haben.

Von daher musste ich bei der Bestellung einer Tastatur nur darauf achten, dass “ISO” oder “DE-Layout” in der Produktbeschreibung vermerkt war und ob die ENTER Taste einzeilig oder zweizeilig war.

Ein meiner älteren deutschen ANSI-artigen Tastaturen (siehe Bild bei ANSI) verletzte bereits den Standard, da die linke SHIFT Taste klein und neben ihr das ISO-Größer/kleinerzeichen zu finden war.

Ich konnte sie aber dennoch nie ordentlich nutzen, weil ich beim Tippen eines Hashtags immer versehentlich ENTER auslöste, was im Chat besonders blöd rüberkam. Doch zumindest waren “alle” Tasten darauf irgendwie zu finden.

Programmiererfeindliche Tasten

Da kaufe ich mir also eine neue Tastatur im Online-Handel, bekomme sie, bin begeistert von der Ausführung, schließe sie an, genieße die ersten Eingaben und starte dann Visual Studio.

Ich tippe die ersten Zeilen, bis ich zur ersten Objektmember komme, will object->method tippen, doch der Pfeil will nicht erscheinen.

Erster Gedanke: defekte Taste.
Aber nein, ich sehe hin und kann es nicht fassen …

Die Größer-Kleinerzeichen-Taste fehlt.

Anstatt dass in der zweiten Zeile von unten nach der SHIFT Taste die Ungleichheitszeichen-Taste kommt, wurde die SHIFT-Taste um genau eine Tastelänge verbreitert.
Das entspricht eigentlich wieder der ANSI-Norm, doch laut ENTER Taste (und Produktbeschreibung) habe ich eine deutsche ISO Tastatur vor mir.

Enttäuschung breitete sich aus, dennoch begann ich, eine alternative Taste auf dem Keyboard zu suchen.
Die Hersteller mussten doch eine andere Möglichkeit vorgesehen haben, um solche Zeichen mit dem deutschen Layout erhalten zu können.

Doch leider NEIN. Auch mit den Funktionstasten war es nicht möglich, die fehlende Taste per “Umschaltung” zu ersetzen. Lediglich Kombinationen wie Alt + 60 oder Alt + 62 konnten unter Windows den Tastendruck per ASCII Code nachstellen.

Fazit

Lieber einmal öfter kontrollieren!

Denn die “komische” ANSI-Shift-Taste auf der deutschen ISO-Tastatur war auch auf der Verpackung und der Abbildung auf der Bestellseite dokumentiert, doch ich achtete nur auf die Größe der ENTER Taste.
Fail!

Mich ärgert es schon ziemlich, dass solche Fabrikate überhaupt existieren, doch offenbar dachte man, dass Gamer ohnehin keine Ungleichheitszeichen tippen müssen, aber häufig SHIFT zum Ducken brauchen und schuf dieses Hybridmodell.

Als Konsequenz darauf marschierte ich (nach langem wieder einmal persönlich) zum Elektronikladen, wählte eine alternative Tastatur, ließ sie mir vorsorglich vom Berater auspacken und vorzeigen um letzte Zweifel auszuräumen und kaufte sie anschließend.

Ab sofort kann ich wieder ordentlich programmieren und object->method() ohne Hilfsmittel abtippen.

Eine kurzfristige Zwischenlösung bereiteten mir die PowerToys für Windows 10, mit denen man Tasten “umleiten” kann.

Ich behalf mir, indem ich die Taste F11 auf < imd F12 auf > umwandeln ließ.

Ganz sinnlos war mein Fehlkauf aber trotzdem nicht, schließlich komme ich mit meinen UEFI Experimenten ohnehin immer in den Genuss eines amerikanischen Tastaturlayouts und somit bin ich diesem zumindest um “eine Taste” näher gekommen. Allerdings sitzen für dieses Schema \ und | wiederum falsch, die eigentlich über der einzeiligen ENTER Taste angebracht sein sollte. Doch bei mir liegt sie unten neben der zweizeiligen Eingabetaste.

Früher war eben alles besser … unterscheidbar.

MSVC's verbockter C11-Support

2022-04-30T13:00:00+02:00

Aus meiner Sicht sollte jedes OS und jeder Compiler so funktionieren:

Die wichtigsten OS Features sind durch die C Standard Bibliothek abgebildet. Und die C++ Implementierung baut genau auf diesen C Standard auf.

Microsoft hingegen pfiff bis 2020 auf den C Standard und baute langsamst nur C++11 und C++14 ein.

Doch tief versteckt im Wald, findet man seit 2017 den Header thr/xthreads.h

Eine Geschichte des Verschweigens

Threads, Mutexe, Condition-Variablen und Thread-Local-Storage sind Teil des C11 Standards.
Der kam damals (2011) auch schon 10 Jahre zu spät, denn eigentlich gibt es keine Entschuldigung dafür, dass nach dem Jahr 2000 auch nur eine einzige Sprachvariante auf Threads verzichten musste.

Win32 Threads und POSIX Threads sind seit Mitte der 90er spezifiziert, und Microsofts fehlende Condition-Variablen wurden seit den 2000ern mit Workarounds ersetzt.
Es ist also schon lange alles da, was man zu einem übergreifenden Standard vereinen hätte können.

Doch da Microsoft den C-Teil seines C++ Compilers auf dem Stand von 1989 belassen hatte (nicht mal C99 war unterstützt) und nur auf C++ setzte, hätte diese Story auch hier enden können.

Mit dem MSVC 2013 setzte ein Umdenken ein und plötzlich waren C99 Codes halbwegs fehlerfrei kompilierbar, was die Kernsprache betraf.
Ich bemerkte das daran, dass libReSSL plötzlich kompilierbar wurde, welche vom MSVC 2012 abgelehnt worden war.
Endlich konnte ich von OpenSSL zur libReSSL wechseln.

thrd, mtx und cnd per define

Spätestens 2015 hätte dann meines Erachtens thrd_create, mtx_lock und cnd_signal auch bei Microsoft ihren Siegeszug antreten können, doch aus irgend einem seltsamen Grund, wurde das abgewendet und in den Hintergrund gedrängt.

Denn in MSVC 2015 und MSVC 2017 existiert der Header thr/xthreads.h inklusive CRT Implementierung, der zwar nicht den C11 Standard umsetzt, aber fast ausschließlich aus C11-ähnlichen Symbolen besteht.

Tatsächlich fehlen nur noch ein paar Makros, um aus den xthreads vernünftige C11 Funktionen zu machen.

Und genau das findet auch im GATE Projekt statt, wenn man dieses mit der C11-Option baut:

 1#include <thr/xthreads.h>
 2
 3#define thrd_t       _Thrd_t
 4#define thrd_start_t _Thrd_start_t
 5
 6#define thrd_create(thr, fun, arg) _Thrd_create(thr, fun, arg)
 7#define thrd_detach(thr)           _Thrd_detach(thr)
 8#define thrd_exit(code)            _Thrd_exit(code)
 9#define thrd_join(thr, res)        _Thrd_join(thr, res)
10#define thrd_sleep(tm)             _Thrd_sleep(tm)
11#define thrd_yield                 _Thrd_yield
12#define thrd_equal(thr0, thr1)     _Thrd_equal(thr0, thr1)
13#define thrd_current               _Thrd_current
14
15#define thrd_success _Thrd_success
16#define thrd_nomem   _Thrd_nomem
17#define thrd_timeout _Thrd_timedout
18#define thrd_busy    _Thrd_busy
19#define thrd_error   _Thrd_error
20
21#define mtx_t                       _Mtx_t
22#define mtx_init(ptr_mtx, mtx_type) _Mtx_init(ptr_mtx, mtx_type)
23#define mtx_destroy(ptr_mtx)        _Mtx_destroy(*ptr_mtx)
24#define mtx_lock(ptr_mtx)           _Mtx_lock(*ptr_mtx)
25#define mtx_unlock(ptr_mtx)         _Mtx_unlock(*ptr_mtx)
26#define mtx_trylock(ptr_mtx)        _Mtx_trylock(*ptr_mtx)
27
28#define mtx_plain     _Mtx_plain
29#define mtx_timed     _Mtx_timed
30#define mtx_recursive _Mtx_recursive
31
32#define cnd_t                      _Cnd_t
33#define cnd_init(ptr_cnd)          _Cnd_init(ptr_cnd)
34#define cnd_destroy(ptr_cnd)       _Cnd_destroy(*ptr_cnd)
35#define cnd_signal(ptr_cnd)        _Cnd_signal(*ptr_cnd)
36#define cnd_broadcast(ptr_cnd)     _Cnd_broadcast(*ptr_cnd)
37#define cnd_wait(ptr_cnd, ptr_mtx) _Cnd_wait(*ptr_cnd, *ptr_mtx)
38#define cnd_timedwait(ptr_cnd, ptr_mtx, ptr_timespec) \
39  _Cnd_timedwait(*ptr_cnd, *ptr_mtx, (xtime const*)ptr_timespec)

Nachdem diese Ähnlichkeiten also schon so groß sind, frage ich mich, was wohl der Grund war, diese nützliche C-Schicht im Hintergrund zu verstecken.

Absolut unverzeihlich ist aber das, was im MSVC 2019 und 2022 dann gemacht wurde. Denn hier hat Microsoft den Header thr/xthreads.h entfernt und durch den kürzeren Pfad xthreads.h ersetzt.

Dieser neue xthreads.h setzt (aus meiner Sicht vollkommen unverständlich) C++ Vokabel ein und schließt damit die Nutzung von reinem C aus.
Es handelt sich um die exakt gleichen C Funktionen _Thrd_*, _Mtx_*, _Cnd_*, doch weil irgend ein Vollhonk ein paar typedefs durch using ersetzt hat und alles mit dem namespace std einleitet, wurde die C Kompatibilität sinnlos zerstört.

Noch abstruser ist, dass im Dev-Blog angekündigt wurde, dass der C11-Library Support in Arbeit ist, doch leider bis zum MSVC 2022 Release noch nicht fertig war.

Wie konnte man das also so verbocken, dass man 2015 quasi schon fertig war (siehe #define Beispiel), und 2019 dann alles mit wenigen C++ Phrasen zerstört hat ???

Eine ähnliche Katastrophe ereignete sich auch bei stdatomic.h, das es 2015 auch schon als xatomic.h gab. Doch dort lag von Anfang an alles im C++ Namespace, wobei die Routinen trotzdem die meisten C11 Atomic-Funktionen nachbilden.

Fazit

Im GATE Framework werden letztendlich alle diese Wirrungen der vergangenen Dekaden sichtbar. Nämlich wenn ich C11 cnd_t Typen nutze um Semaphoren nachzubauen und parallel dazu im NT4 Layer mit Win32 Semaphoren Condition-Variablen simuliert werden.

Hätte es bereits gegen 2003 einen Standard wie C11 gegeben und wäre Microsoft hierbei fitter gewesen, hätten wir (in einer idealen Welt) bereits 2005 mit standardisierten C-Threads arbeiten können.
Viele unnötige Workarounds wären uns erspart geblieben und C++ hätte seine std::threads auf einem stabilen (und leichtgewichtigen) C-Fundament aufbauen können.

Ich bezweifle, dass (außer mir) noch andere Entwickler multi-threaded Standard-C Codes in Windows einsetzen. Und das ist mehr als schade, denn die effizientesten Webserver und Sprachcompiler liegen bis heute in reinem C Code vor.

Tja … heute heißt es also:

Früher hätte alles besser werden können.

UEFI, CMake und GCC

2022-04-24T13:00:00+02:00

Manchmal sind es die Dinge, wo man denkt:

Ach, das sollte in 15 Minuten erledigt sein.

die einen dann den ganzen Tag (oder länger) beschäftigen.

Mir erging es mit der Einrichtung eines CMake Scripts für UEFI-Apps in einer GCC Linux Umgebung heute so.

Der MSVC hat es mir mit seinem EFI-Applications Build-Typ recht einfach gemacht, Apps ohne Betriebssystem zu erstellen.
Doch ein großes Problem stellen C++, seine Exception und RTTI dar, bei denen der MSVC Code generiert, der eine C-Runtime voraussetzt, die an den Windows Kernel angepasst ist … also etwas, was in UEFI nicht existiert.

Der GCC hingegen lässt sich leichter dazu bewegen, solche Datenstrukturen generisch zu erzeugen, und somit war mein erster Schritt schon festgelegt:

Ich möchte den EFI-App-Build in einer GCC Umgebung durchführen können.

Doch da der GCC unter Linux das ELF-Format einsetzt und UEFI APIs auf Microsofts COFF Spezifikation aufsetzen, gestaltet sich das Bauen von UEFI-Apps im GCC wesentlich schwieriger.

Makefile Analyse

Die GNU-EFI Bibliothek sieht folgende Prozedur vor:

Die EFI-Schnittstellen werden in eine statische libefi.a kompiliert.
Der (Assembler basierte) Startup Code kommt in die statische libgnuefi.a.
Die eigene EFI-App wird als shared library gebaut, die gegen die beiden vorherigen mit ein paar speziellen Flags linkt.
Das Tool objcopy extrahiert die Code und Datenbereiche aus der shared lib und baut daraus ein EFI-App-Binary mit dem richtigen Target-Subsystem zusammen.

Wichtige Compiler-Optionen hierfür sind:

-ffreestanding: Verzicht auf die übliche C-Standard-Bibliothek
-fpic: Shared-lib position independent code
-fshort-wchar: wchar_t als 16-bit wie bei Microsoft
Deaktivierung diverser Stack-Prüfungen, wie: -fno-stack-protector, -fno-stack-check, -mno-red-zone
und noch ein paar Kleinigkeiten (siehe CMake Beispiel)

Der Linker braucht folgende Zusätze:

-shared: erzeugt eine temporäre dynamische Lib
-nostdlib: Verzicht die übliche C-Standard-Bibliothek zu linken
-Bsymbolic: Verhaltensanpassung, wie Symbole im Code aufgelöst werden
-e_start: Festlegung des Funktionsnamens, der beim App-Start benutzt werden soll, also _start(), eine in Assembler geschriebene Einsprungfunktion aus libgnuefi.a.
Sie initialisiert alles und ruft dann efi_main auf.
-T /path/to/gnuefi/elf_x86_64_efi.lds Pfad zum Linkerscript, das wichtige Details zum Linken der EFI-App beinhaltet.

Die Makefile Dateien, die gnu-efi mitliefert, dokumentieren, dass libgnuefi.a zwar gelinkt wird, aber dass das crt0 Objekt (*.o) trotzdem nochmal separat zur finalen EFI-App gelinkt wird.
So wird die darin enthaltene _start Funktion automatisch zum Einsprungpunkt.

Bei meinen Tests, wo ich die .o nicht mehr separat angab, musste ich den Einsprungpunkt eben mit -e_start festlegen, ansonsten wählte der Compiler selbsttätig immer efi_main aus.

CMake Umsetzung

Das Standard CMake Setup nutzt cc um seine Kompilate umzusetzen.
Da die originalen gnu-efi Sourcen Makefiles einsetzen, die explizit zwischen gcc und ld Aufrufen unterscheiden, muss man beim Wechsel zu CMake mit cc darauf achten, welche Kommandos für den Linker bestimmt sind.

Diese muss man dann mit -Wl, präfixen, z.B: -Wl,-nostdlib.

Man erhält nun eine EFI .so Datei, die man aber noch umwanden muss. Ein Custom-Build-Job mit dem Aufruf von objcopy führt zum gewünschten Ergebnis:

1objcopy -j .text -j .sdata -j .data -j .dynamic -j .dynsym -j .rel -j .rela -j .reloc --target=efi-app-x86_64 my-efi-app.so my-efi-app.efi

Die Datei my-efi-app.efi kann nun auf einen mit FAT32 formatierten USB Stick kopiert werden.
Bootet man in die UEFI-Shell, kann man mit fs0: (oder fsX: wenn mehrere Laufwerke erkannt werden) zum Stick wechseln und my-efi-app.efi einfach durch Eingabe des Dateinamens + ENTER ausführen lassen (DOS lässt grüßen).

Wer keine UEFI-Shell in seinem BIOS hat, kann die Datei auch als /EFI/BOOT/BOOTX64.EFI speichern und vom Stick booten.
Die EFI-App wird dann wie ein Bootloader ausgeführt … nur dass eben kein OS geladen wird, sondern nur unser Code in efi_main() ausgeführt wird.

Problem Calling Convention

… und dann sitze ich stundenlang vor meinem Bildschirm und stelle fest, dass die erzeugte EFI-App sofort zum Einfrieren des Systems führt.

Doch erst nach längerer Analyse der Assembler und C Sourcen wurde mir mein Fehler bewusst.

_start() versucht zuerst dynamische Symbole korrekt auszurichten (reloc()) und will am Ende die Funktion efi_main aufrufen, in der der eigene Code startet.

Und hier hatte ich die Signatur

1EFI_STATUS EFIAPI efi_main(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE* SystemTable)

gewählt. Und der Token EFIAPI war des Pudels Kern. Denn dieses Makro ist im GCC definiert als:

1#define EFIAPI __attribute__((ms_abi))

EFIAPI wird für die EFI-Schnittstellenfunktionen benutzt und ermahnt den GCC Compiler, die Aufrufe im Microsoft-Format (x86_64) durchzuführen.

Doch _start geht davon aus, dass efi_main eine “lokale” nicht-EFI-Funktion ist, die sich auch nicht an die Microsoft-Konvention halten muss. Stattdessen wird die übliche GCC x86_64 cdecl Konvention benutzt, bei der die Register anders belegt sind.

Microsoft’s cdecl nutzt die Register RCX und RDX für die ersten beiden Parameter und der GCC nutzt die System-V cdecl Spezifikation und übergibt die gleichen Parameter in den Register RDI und RSI.

Und so erhielt meine efi_main Funktion also zwei ungültige Registerwerte, was den Crash auslöste.
Die Entfernen von EFIAPI in efi_main vermochte mein Problem zu lösen.

Fazit

Nun wo der C-Teil bei GCC, CMake und EFI durchprobiert wurde, kann ich mich also in Zukunft mehr um die C++ Seiten kümmern.

Wie “cool” wäre es, wenn man nun auch vollständige C++ Routinen außerhalb eines OS nutzen kann?

Ich freue mich daher schon, diese neue Welt entdecken zu dürfen.

Position Indipendent Code (-fPIC) für Assembler

2022-04-23T13:00:00+02:00

Mit dem Fehler

/usr/bin/ld: (…S.o): relocation R_X86_64_PC32 against symbol ‘…’ can not be used when making a shared object; recompile with -fPIC

konnte ich genau gar nichts anfangen, schließlich hatte ich alle Sourcen mit -fpic kompiliert.

Was unterscheidet also meine Assembler-Funktion von meinen anderen C-Funktionen?

Weil mich der MSVC in Sachen C++ bei UEFI im Stich lässt, wollte ich das Ganze dem GCC anvertrauen.

Doch das erforderte einige Updates, denn beim GCC kann man nicht so einfach EFI-Applications erstellen.
Man baut zuerst spezielle Shared-Libraries und wandelt diese dann in EFI Anwendungen um.

Doch hier scheiterte ich an meinen handgeschriebenen Assembler-Implementierungen für den Stack-Context-Switch bei Koroutinen.

Konkret ging es um einen Aufruf der Assembler-Funktion B innerhalb der Funktion A.

Wenn A also B aufrufen will, gibt es ein Relocation Problem.

Lösung: @plt

Anstatt

1call B

nutzt man einfach

1call B@plt

und schon lässt sich wieder alles kompilieren.

Die Hintergründe

Shared-Libraries und EFI schreiben ihre Funktionen nicht an fixe Adressen, sondern arbeiten mit Einträgen in einer “Global Offset Table” (GOT). Wird eine Lib geladen, landet der Code an einer beliebigen Speicheradresse und um Funktionen anspringen zu können, muss diese Adresse errechnet werden können.

Und genau dafür generiert der Assemblercompiler Hilfsfunktionen die mit @PLT (Procedure Linkage Table) erreicht werden können um zur korrekten Adresse der Funktion gelangen zu können.

Hinter dieser Magie dürfte offenbar relative Adressierung stecken, wo der Aufruf der @plt Funktion relativ zur aufrufenden Funktion fix ist und die @plt Funktion löst dann die echte aufzurufende Adresse auf und springt hin.

Eine tolle Aufschlüsselung der Vorgänge findet man unter maskray.me/blog

Fazit

Meine Erwartungen aus der MSVC Welt basieren auf der Vorstellung, dass solche Details immer im Hintergrund aufgelöst werden müssen.
Doch wie sich zeigt, muss man beim GCC sehr wohl zwischen Aufrufen zu öffentlichen und privaten Funktionen unterscheiden.

Tja, bisher bin ich von solchen Details verschont geblieben, denn damals, als ich mit Assembler noch in der DOS Welt unterwegs war, gab es keine Shared-Libraries, die man hätte beachten müssen.
Und heutige Mikrocontroller Spielereien kennen auch keine Relocations.

Eines kann ich also jede Woche über die Programmierung sagen:

Hier lernt man nie aus!

Ostern und die Ratscher-Buam

2022-04-17T13:00:00+02:00

Heute erzählte mir meine Mutter, dass seit langem wieder mal ein älterer Brauch am Land es bis zu ihr in die Seitengasse geschafft hatte:
Die Ratscher.

Als Kind erklärte man mir diesen Osterbrauch sinngemäß so:

Zu Ostern fliegen die Kirchenglocken alle nach Rom. Und deshalb müssen die Dorfburschen mit ihren Ratschen die Leute an die Zeit erinnern.

Ich würde daher sagen: Ratschen ist eine analoge Form von NTP.

Ratschen

Ich bin mir nicht mehr sicher, ob es mein Großvater oder Onkel war, der mir damals meine erste Holz-Ratsche in seiner Werkstatt zusammengeschnitzt hat, jedoch werde ich das 15cm dicke Zahnrad mit Kurbel und die 3 Klapperbretter nie vergessen.

Es muss wohl schon kurz nach meinem Schuleintritt gewesen sein, als ich das erste mal im Dorf der Großeltern mit den älteren Burschen mitmarschieren durfte, wenn zu Ostern am Gründonnerstag, Karfreitag und Karsamstag jeweils früh am Morgen, zu Mittag und am Abend Krawall gemacht werden sollte, um das ganze Dorf an die Zeit zu erinnern.

Meines Wissens ist der Ratscher-Brauch in vielen Teilen Österreichs üblich, wenngleich er mit der Größe von Städten seltener wird.
In den Dörfern marschiert dann jedenfalls eine Gruppe von Kindern durch die Straßen, betätigt kräftig die Ratschen und sorgt somit für ausreichend Krach, damit jeder es hören kann.

Der Weckruf

Zeitig am Morgen (es muss wohl 6 Uhr gewesen sein) hieß es:

Wir ratschn, wir ratschn Dumpa-Mettn.
Leitln steht’s auf, backt’s Osterflecken!

Es gab zwar nie eine “Dumpa-Mette” (Frühmesse) in der Dorfkapelle und man hat mir auch nie “Osterflecken” serviert, aber die Leute vor hundert Jahren wussten bestimmt, was damit gemeint war.

Mittag

Das kurze und knackige:

Wir ratschn, wir ratschn: Zwölfe!

war am einfachsten zu merken … und von Haus zu Haus wurde das Zwölfe immer musikalischer über Straße getrillert.
Auf jeden Fall hat das Mittagessen danach immer besser geschmeckt, weil man es sich so richtig verdient hatte.

Karfreitag um 15 Uhr

Eigentlich sollten am Freitag um diese Zeit alle braven Christen in die Stadt zur Kirche gefahren sein um den Gottesdienst zu feiern.
Doch wer zu Hause geblieben war, wurde von uns erinnert:

Wir ratschn, wir ratschn das Leiden und Sterben unseres Herrn Jesus Christus!
Leitln, fallt’s nieder auf euchere Kniea.
Betet’s drei Vater unser und Ave Maria.

Der Abend-Gruß

Und am Ende des Tages (so gegen 18 Uhr) zog die Truppe ein letztes Mal durchs Dorf um zu bekunden:

Wir ratschn, wir ratschn den englischen Gruaß,
den jeder katholische Christ beten muaß.

Dass der “Engel-ische” Gruß zu “englisch” mutiert war, verärgerte unter anderem den Stadtpfarrer besonders, der mit diesen “lokalen” Ratscher-Sprüchen wenige anfangen konnte.
Generell gibt es aber meines Wissens keinen festgelegten Text, der beim Ratschen gesprochen werden musste. Das regelte jedes Dorf offenbar ein bisschen anders.

Lokale Traditionen

So läuft das in manchen Dörfern schon seit vielen Generationen ab. Es gibt kein Handbuch dafür und die älteren Jungs bringen die Sprüche den jüngeren 10 Minuten vor Beginn einer Tour bei.

Eigentlich eine schöne Sache, die die meisten Kinder zwischen 7 und 14 Jahren jährlich mitmachen. Ich weiß nicht, ob das Ritual ursprünglich eine reine “Männersache” war, weil am Anfang immer nur von den “Ratscher-Bubn” die Rede war.
Doch mangels männlichem Nachwuchs gingen bereits ein paar Jahre später meine Kusinen mit und übernahmen “das Geschäft” später ganz. Und heute sind es ihre Töchter und Söhne, die diese alte Tradition fortführen.

Der Verdienst

So ehrenamtlich die ganze Sache im Grunde natürlich ist, so will am Ende aber niemand auf das “Absammeln” vergessen.
Denn es kamen beim letzten Rundgang stets die Hausbewohner auf die Straße um den Ratschern etwas Gutes zu tun.

Deshalb wurde immer eine Geldbüchse und ein Sack mitgenommen, um Geldspenden, Süßigkeiten und Ostereier mitnehmen zu können. Geld und Speisen wurden dann unter den Ratschern gerecht aufgeteilt und somit war das Osternest auch ohne Zutun des Osterhasen bei allen Ratschern gefüllt.

In gewisser Weise ist es ein bisschen vergleichbar mit dem amerikanischen Halloween nur eben zu Ostern und ohne Verkleidung, dafür aber mit lautem Geknatter.

Fazit

Meine Religiosität und Teilnahme an kirchlichen Aktivitäten liegt wie mein Kirchenaustritt jetzt schon etwa 20 Jahre zurück.

Und seit ich in Wien wohne, gehören solche Rituale nicht mehr zu meinem Alltag.

Aber ich freue mich, dass es diese Tradition in den Dörfern gibt, weil es die Jugend in die Gemeinschaft einbindet und schöne Erinnerungen beschert.

Meine Mutter, die in einer kleinen Stadt in der Nähe des Dorfes meiner Großeltern wohnt, hatte in ihrer Siedlung auch viele Jahre keine Ratscher mehr gesehen, doch nun hat ein Nachbar auch dort die Tradition wieder eingeführt.

Und das ist wirklich gut so.

In diesem Sinne: Frohe Ostern!

Nachtrag

Die Glocken fliegen übrigens nachweislich nicht nach Rom in der Osterzeit.

Jahre später stellte ich fest, dass nur das elektronische Läutwerk der Stadtkirche in der Osterwoche abgeschaltet wird.

Nun wird klar, was Richard David Precht meinte, als er nach einem Gespräch mit einem Linzer Bischof sagte:

Die Kirche hatte 2000 Jahre lang das Monopol auf erfundene Wahrheiten (Fake News).

Rückkehr ins Kino

2022-04-16T13:00:00+02:00

Mit der Einführung der Registrierungspflicht wegen COVID-19 am Kinoeingang wurde es mir unmöglich gemacht, Vorstellungen zu genießen.
Schließlich kämpfe ich nicht grundlos seit Jahren für Verbesserungen im Datenschutz und all das wurde mit der Ausrede “CORONA” mit Füßen getreten.

Doch nun wurde diese sinnlose Aktion beendet, womit auch ich mein persönliches Film- Embargo zurückziehen kann.

Ein falscher Ansatz

Wer auch immer auf die absurde Idee kam, dass das Unternehmertum einfach alle Daten ihrer Kunden “irgendwie” vorrats-speichern soll, war nicht ganz dicht.

Die Ämter verteilten A4-Zettel an Veranstaltungsbetreiber und ordneten an, es sollen alle Kunden Name, Adresse und Telefonnummer darauf schreiben und dem Betreiber zurückgeben.
Dieser sollte die A4 Zettel einige Wochen aufheben und falls ein Coronafall gemeldet worden wäre und dieser angegeben hätte, er hätte einer Veranstaltung beigewohnt, ja dann hätte die Behörde alle Zettel eingefordert um eventuelle Kontakte darüber zu informieren, dass eine Corona-Infektion aufgetreten sei.

Ich gehe also 1 mal im Monat 3 Stunden ins Kino und werde ge-TRACE-t, fahre dann aber täglich eine Stunde mit den öffentlichen Verkehrsmitteln, sitze die Hälfte der Woche in einer Firma mit tausend anderen Mitarbeitern und bin dabei Corona-technisch vogelfrei.

Mir kann also niemand erzählen, dass die Preisgabe meiner Wohnadresse im Kino Leben rettet, während 20 Stunden Autobusfahrt im Monat mit fremden Personen gleichsam egal ist.

Denn TRACING funktioniert nur dann zuverlässig, wenn es flächendeckend umgesetzt wird.
Und dabei lassen wir mal weg, dass niemand die Daten prüft. Ich hätte mich also auch als Ash Ketchum aus Alabastia mit der Nummer 123456789 registrieren können, denn der 17 jährige Praktikant am Schalter (oder auch seine älteren Kollegen) wollten nie einen Ausweis sehen, sondern legten die Zettel einfach auf einen Stapel.

Der Datenschutz-bezogene Schaden, der jedoch angerichtet wurde, ist erheblich größer:

Wer garantiert mir denn, dass die A4 Zettel wirklich nach 3 Wochen den reinigenden Flammen übergeben wurden?
Wer stellt denn sicher, dass nur datenschutzrechtlich geschultes Personal mit den Daten hantieren darf?
Und wer trägt die Verantwortung bzw. wer ist mein Ansprechpartner im Falle eines erkannten Problems?

… aber lassen wir das Thema … es regt mich einfach nur auf.

Phantastische Tierwesen 3

Um also wieder “in Stimmung” zu kommen, sah ich mir Phantastische Tierwesen - Dumbledores Geheimnisse an, da ich schon die beiden Vorgänger im Kino miterleben durfte.

Hmm … naja … ein bisschen erinnert mich das an Black Widow. Ich freute mich alle Charaktere wieder zu sehen … aber die Story konnte mich nicht überzeugen.

Wenn man den ersten Teil ansieht, wo wirklich noch “magische Tiere” im Mittelpunkt standen, und dann zu Teil 2 und 3 wechselt, stellt man fest, dass die neuesten beiden Teile eigentlich eher unter dem Titel: “Dumbledore vs Grindelwald” hätten veröffentlicht werden sollen.

Die namensgebenden “Tierwesen” spielen de facto keine Rolle und wirken künstlich herbei geschrieben um den original Titel irgendwie rechtfertigen zu können.

Es ist etwa so, als hätte es einen “Harry Potter 5,5 - Dracos Ferien” Film gegeben, in dem Harry Potter in den ersten 5 Minuten auftaucht, und dann aber durchgehend nur noch Szenen mit Draco Malfoy ablaufen. Ein solcher Film hätte “Harry Potter” im Titel auch nicht verdient.

Und trotzdem mag ich Jude Law in der Rolle des jüngeren Albus Dumbledore sehr und hätte gerne den Film “Dumbledores Geheimnisse” ohne Tierwesen gesehen, wo nur dieser Charakter im Mittelpunkt gestanden hätte, in dem nicht Dan Folger als Jacob Kowalski und Katherine Waterston als Tina Goldstein andauernd die Handlung gestört hätten.

Auch cool gewesen wäre ein: “Phantastische Tierwesen - Die Jagd nach dem verlorenem Schatz”, in dem Newt Scamander (Eddie Redmayne) mit seinem Niffler eine magische Azteken-Pyramide durchsucht.

So bin ich etwas gespalten, ich will den Film mögen, schaffe es aber nicht ein “Daumen-hoch” auszusprechen. Besonders deshalb, weil ich schon lange nicht mehr so viele “Nazi-Gesichter” in Berlin abgefilmt bekommen habe, ohne dass der Begriff explizit gefallen wäre. … also mehr Clichè geht kaum noch.

Fazit

Am wichtigsten ist aber: Ich kann wieder “bedenkenlos” ins Kino gehen, und das kam auch keine Sekunde zu früh.
Erst seit kurzem darf ich Spiderman - No way home mein Eigen nennen und bin trotzdem noch angepisst, dass ich den Film nicht zu Weihnachten auf der Kinoleinwand sehen durfte.

In zwei Wochen startet Dr Stange in the Multiverse of Madness und wenn ich nicht live sehen darf, wie Wanda Maximoff ihre beiden Hero-Kids wiedersieht … dann gibt es einen Amok-Lauf, dass selbst Thanos Angst bekommt.

… oder anders gesagt: Ich kann es kaum noch erwarten.

Auf jeden Fall freue ich mich über dieses Stück zurückgewonnener Freiheit und ich hoffe, dass dieses idiotische TRACING-Schema nie wieder zur Anwendung kommen wird.

MS Exchange 2000 bis 2007

2022-04-10T13:00:00+02:00

Es ist dem Active Directory (AD)zu verdanken, dass ich zum Microsoft Exchange Server eine “besondere” Beziehung habe, bzw. hatte.

Dort fanden, vor 15 Jahren, meine ersten “Hackereien” statt, die zwar alle sehr hilfreich waren, aber auch verdammt ins Augen hätten gehen können.

Die nicht-automatisierte Useradministration in einem größeren Unternehmen sah vor 15 Jahren so aus:

Ein paar Leute klicken den ganzen Tag lang durch die Windows Active Directory und Exchange UI-Masken um Benutzerdaten und Mailboxen so anzupassen, wie es von “den Kunden” verlangt wird.

Hat man ein paar tausend Mitarbeiter, die quer über den Kontinent verteilt sind, dann will jeden Tag jemand eine andere Berechtigung für eine Projektressource haben oder sperren und man ist mit Klickereien beschäftigt.

Und genau deshalb lernte ich die internen Details des AD und seines wichtigsten Partners, Microsoft Exchange, nach und nach kennen.

Denn die Powershell war damals noch am Zeichenbrett und hatte keine Anbindung an Exchange.

Exchange 2000/2003 Installation

Bevor sich das Exchange Setup ausführen ließ, musste man den IIS und ASP sowie den SMTP und NNTP Dienst unter Server 2000 oder 2003 installieren.

Danach integriert sich Exchange ins Active Directory LDAP Schema und erweitert es um seine Mail-spezifischen Attribute.

Kaum ist die Installation durchgelaufen, hat der System-Administrator Account eine Mailbox erhalten und diese lässt sich auch gleich über den damaligen Outlook Web Access (OWA) öffnen und zwar über http://exchange-host/exchange/

So schön sah OWA aber nur im Internet Explorer 6 bis 8 aus.
Für die damaligen Nicht-Microsoft-Browser (und darunter fällte auch der heutige Microsoft Edge), gab es eine primitivere unschönere Ansicht.

Schließlich musste man ja künstlich den Eindruck bestehen lassen, dass der IE alles besser macht.

Programmierung von Exchange 2003

Wer die Exchange-Admin-Tools installiert hatte, konnte mit CDOEXM (Collaboration Data Objects for Exchange Management … oder so) und VBScript zumindest ein paar Exchange Tasks automatisieren.
Viel besser klappte das im vollständigen Visual Basic 6, oder im damaligen dotNet Framework 1, welches über seine COM Brücke auch auf die Exchange Objekte zugreifen konnte.

 1Set user = GetObject("LDAP://path,to,ad_user")
 2Set ado = CreateObject("ADODB.Connection")
 3ado.Provider = "ExOLEDB.DataSource"
 4ado.Open
 5Set person = CreateObject("CDO.Person")
 6person.DataSource.Open user.ADsPath, ado, adModeReadWrite, adFailIfNotExists, adOpenSource
 7Set recipient = person.GetInterface("IMailRecipient")
 8recipient.CreateMailbox "LDAP://CN=Mailbox Store,CN=Storage Group,CN=InformationStore,CN=ExchangeServerName,CN=Servers,CN=Administrative Group,CN=Administrative Groups"
 9person.DataSource.Save

Das interessante am klassischen Exchange damals war das Recipient Update Service (kurz RUS). Dieser Dienst scannte das AD nach Änderungen (z.B. neue User) und leitete die nötigen Schritte ein, um eine verknüpfte Mailbox automatisch anzulegen.

Um die richtigen LDAP-Pfade für die “versteckten” Exchange Objekte herauszufinden, installierte man einfach \support\tools\suptools.msi von der Server 2003 CD um das Tool ADSI-Edit zu erhalten. Dieses konnte man dann in der Microsoft Management Console mmc.exe manuell hinzufügen und sich damit zur Configuration Partition des Active Directory verbinden.
(User und Gruppen liegen in der Domain Partition und die wird mit dem AD Users und Groups Plugin schön angezeigt, doch für Configuration brauchte man eben ein natives LDAP Tool).

So erfuhr man, dass Mailboxen in einer Storage Group liegen, die auf einem Server liegen, der einer Administrative Group zugeordnet ist, die in einer Organisation liegt.
Das sieht hierarchisch so aus:

1my-ad.domain.tld/Configuration/Services/Microsoft Exchange/MyOrganization/Administrative Groups/MyAdminGroup/Servers/MyMXServer/InformationStore/MyStorageGroup/MyMailboxStore

wobei die Token MyOrganization, MyAdminGroup, MyMXServer, MyStorageGroup und MyMailboxStore bei der Installation festgelegt oder auf einen Default gesetzt sind.

“In LDAP” wird das dann so ausgesprochen:

1CN=MyMailboxStore,CN=MyStorageGroup,CN=InformationStore,CN=MyMXServer,CN=Servers,CN=MyAdminGroup,CN=Administrative Groups,CN=MyOrganization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=my-ad,DC=domain,DC=tld

Witzig ist, dass mit Exchange 2007 das Konzept mehrerer Administrative Groups aufgegeben wurde und bei einer Installation nur noch eine Gruppe mit dem Namen FYDIBOHF erstellt wird. Das ist ein Zeichenspiel, wo vom Token EXCHANGE einfach immer bei jedem Buchstaben der nachfolgende herangezogen wurde.

Fazit

Meine “Exchange-Zeit” endete programmiertechnisch etwa um 2007. Ich spielte noch etwas mit Exchange 2007 auf API-Ebene, doch mein Berufswechsel trug mich wieder davon weg.

Um 2011 durfte ich wieder ein Exchange 2010 System für eine Firma einrichten und seine Zusammenarbeit mit dem Data Protection Manager prüfen, aber auch das war nur ein “Sidequest”.

Leider kenne ich keine Alternativen zur Microsoft-Standard-Lösung, mit der man größere Organisationen verwalten kann und somit bleibt Exchange für mich ein “guter” Ansatz. (Obwohl es bestimmt gute Alternativen dazu gibt.)

Es war jedenfalls Mitte der 2000er ein besonderes Gefühl, wenn man mit ein paar Zeilen Code gleich mal 1000 User-Mailboxen verschieben oder nachbearbeiten konnte, während andere Admins Wochen damit zubrachten, bei 100 Kunden manuell bei jedem Mailaccount eine SMTP Adresse hinzuzufügen.

Daraus habe ich gelernt, wie unglaublich wichtig es ist, dass jedes Softwareprodukt einen Programmierschnittstelle braucht, über die man administrative Aufgaben automatisieren kann.

ARM Crosscompiler

2022-04-09T13:00:00+02:00

Wenn man jetzt schon dank MinGW unter Linux seine Windows Programme kompilieren lassen kann, warum soll man denn nicht auch unter X86 PCs die ARM Binaries für den Raspberry PI erstellen lassen können?

Und mit Debian geht das echt einfach … und am Ende klappt das Ganze sogar unter WSL in Windows 10.

Wenn man nach “Raspberry Pi crosscompile” sucht, findet man einige Beiträge, die einen alle Tools im Internet zusammentragen lassen, dann noch alle Raspberry Header und Libs per GIT klonen lassen, um endlich einen Build zu starten.

Zumindest seit Debian 9 (oder Ubuntu 18.04) geht das viel einfacher:

Debian: crossbuild-essential-armhf

Die Paketinstallation
apt install crossbuild-essential-armhf -y
legt den GCC ARM Compiler und die meisten notwendigen Libs in /usr/arm-linux-gnueabihf ab.
Und mit einer .cmake Toolchain-Datei leitet man einfach die Aufrufe zum ARM Compiler um.

CMake: Toolchain Datei

Meine CMake Toolchain-Datei arm-linux-gnueabihf.cmake sieht in etwa so aus:

 1set(CMAKE_SYSTEM_NAME "Linux")
 2set(CMAKE_SYSTEM_PROCESSOR "arm")
 3set(TOOLCHAIN_PREFIX "arm-linux-gnueabihf")
 4
 5set(CMAKE_C_COMPILER "${TOOLCHAIN_PREFIX}-gcc")
 6set(CMAKE_CXX_COMPILER "${TOOLCHAIN_PREFIX}-g++")
 7
 8set(CMAKE_CROSSCOMPILING TRUE)
 9set(THREADS_PTHREAD_ARG "2" CACHE STRING "THREADS_PTHREAD_ARG" FORCE)
10
11set(CMAKE_FIND_ROOT_PATH "/usr/${TOOLCHAIN_PREFIX}")
12
13set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
14set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
15set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)

Ich brauchte den Eintrag THREADS_PTHREAD_ARG, da ansonsten der Fehler:

CMake Error: TRY_RUN() invoked in cross-compiling mode, please set the following cache variables appropriately: THREADS_PTHREAD_ARG (advanced)

auftritt.

Schon kann man CMake mit dem Kommando:

1cmake -DCMAKE_TOOLCHAIN_FILE=/path/to/arm-linux-gnueabihf.cmake /path/to/sources

ausführen und erhält am Ende ARMv7 Binaries.

Diese wurden zu meinem alten Raspberry Pi 2B kopiert und dieser konnte sie sofort und ohne Probleme ausführen.

Andere Plattformen

Nachdem der Raspberry Pi Zero und 1 den ARMv6 Befehlssatz nutzen, der 2er den ARMv7 und die späteren ARMv8, macht es Sinn, diese Info der Toolchain mitzugeben, damit optimierter Code für die gewünschte Plattform rauskommt.

Eine tolle Übersicht hat fm4dd unter github.com eingestellt.

Mit ein paar Zusatzzeilen

1#set(RPI_FLAGS "-mcpu=arm1176jzf-s -mfloat-abi=hard -mfpu=vfp" CACHE STRING "RPi Zero/1")
2set(RPI_FLAGS "-mcpu=cortex-a7 -mfloat-abi=hard -mfpu=neon-vfpv4" CACHE STRING "RPi 2")
3#set(RPI_FLAGS "-mcpu=cortex-a53 -mfloat-abi=hard -mfpu=neon-fp-armv8 -mneon-for-64bits" CACHE STRING "RPi 3")
4#set(RPI_FLAGS "-mcpu=cortex-a72 -mfloat-abi=hard -mfpu=neon-fp-armv8 -mneon-for-64bits" CACHE STRING "RPi 4")
5
6set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${RPI_FLAGS}" CACHE STRING "C CPU Flags")
7set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${RPI_FLAGS}" CACHE STRING "C++ CPU Flags")

lässt sich der generierte Code auf den gewünschten Raspberry Pi anpassen.

Leider ist der ARMv6 Befehlssatz des RPi Zero und 1 nicht mehr in den Standardcompilern enthalten und man bekommt Fehler wie:

sorry, unimplemented: Thumb-1 hard-float VFP ABI

Aber auch hier hat ein pfiffiger User eine Lösung mit einer angepassten Toolchain eingestellt: github.com/Pro/raspi-toolchain

Fazit

Mit WSL und Ubuntu oder Debian kann ich nun also GATE Builds für die ARM Plattform bauen lassen und während mein Raspberry 4 oder 2 schon ganz schön lange rechnen müsste, schafft das mein Intel i5 in unter einer Minute.

Vermutlich enthalten ältere Distros von vor 2015 ebenfalls noch den ARMv6 Befehlssatz, aber mir reicht der ARMv7 Teil vollkommen für Tests aus.

Sollte ich also wirklich mal einen RPi Zero Build brauchen, werde ich die alternative Toolchain bemühen müssen, oder direkt am R-PI bauen lassen.

Jedenfalls wieder mal “eine coole Sache”, dass ich nun eine weitere Plattform problemfrei abhaken kann.

Es gibt zwar meines Wissens auch eine native Windows-Toolchain für ARM-Linux, doch wozu die Mühe machen, wenn es mit WSL so unkompliziert läuft.

LUA: Scripts für C/C++

2022-04-03T13:00:00+02:00

Die Scriptsprache LUA beeindruckte mich schon vor vielen Jahren mit ihrer einfachen Implementierung und dem geringem Ressourcenverbrauch.

Und außerdem ist es in keiner anderen Sprache so leicht möglich Kernfunktionen wie den Dateizugriff selbst zu implementieren oder ganz wegzulassen.

Microsoft’s VBScript (und JScript) haben seit den 90ern eine COM API um sie in eigene Projekte zu integrieren. Javascript Engines wie V8 können das auch ohne COM und Python ist heute wohl der bekannteste Vertreter einer Scriptsprache, die man aus eigenen Programmen nutzen kann, oder wie man eigenen Code in diese Welt hin abbilden kann.

Doch diese Moloche haben alle ein großes Problem:
Ihre Komplexität lässt sie zu einem Adipositas Patienten werden, der jedes neue Projekt mit unzähligen Abhängigkeiten belegt, die dieses mühsam mitschleppen muss.

Und mache Anwendungsgebiete wie Mikrocontroller fallen daher sofort weg.

LUA hingegen definiert primär eine Kernsprache mit Konstrukten wie function, if-then-else, for, while, break und return, sowie das Definieren und Verändern von Variablen mit Grundrechenarten.

Jede weitere Form von “Funktionalität” kann bzw. muss über C-Funktionen in die Scriptsprache eingefügt werden.
Und so wird ein Standard-Mapping von üblichen C-Funktionen, wie print zur Ausgabe, oder lower/upper für Strings wie auch sin/cos/tan zum Rechnen, in die Sprache eingefügt.

Doch: Das kann man auch bewusst weglassen.

Und genau das macht LUA in erster Linie mal zu einer besonders sicheren Scriptsprache, denn es gibt grundsätzlich mal kein Feature, dessen Bugs man ausbeuten kann.
Wir können also die Scriptsprache nur mit den Funktionen anreichern, die wir wirklich brauchen und müssen keine Angst davor haben, dass man versehentlich unbenutzten Fremdcode ausführt.

Von daher war es auch kein Problem, LUA Scripts in meiner UEFI Umgebung auszuführen, da ich hierfür die Script-print Funktion nicht auf das handelsübliche C printf festlegte, sondern auf meine eigene Implementierung.

Und genau hier startet der große Vorteil von LUA: Man kann eigene Objekte oder Funktionen für Scripts “nutzbar” machen.
Oder anders gesagt, man kann dynamisch eine Funktion injizieren lassen, deren Aufruf auf eine native C-Funktion umgeleitet wird.

Und genau so erreichen viele Programme einen enormen Funktionalitätsgewinn:

Man schreibt die interne Low-Level-Logik in effizientem C oder C++ Code
Und dann lässt man diese High-Level-Funktion durch einfache LUA Scripts mit unterschiedlichen Parameter ausführen.
Am Ende erhält man ein kleines und effizientes C Programm, dessen interner Ablauf mit LUA Scripts verändert werden kann, ohne dass man neu kompilieren muss.

Fazit

LUA ist schon seit einiger Zeit im GATE Framework integriert und soll es möglich machen, die nativen (und manchmal komplexen) C Routinen durch einfache Aufrufe zu “verscripten”.

Tatsächlich ist das Mapping zwischen LUA und C Code etwas gewöhnungsbedürftig, da man alles über Stacks austauscht, doch diese Details lassen sich durch Hilfsroutinen bändigen.
Besonders der Einsatz von Templates in C++ vereinfacht diese Übersetzung enorm.

Ich bin jedenfalls ein großer LUA Fan geworden und sehe vor allem im Vergleich zur Integration von Python große Vorteile.

Ein Wermutstropfen ist leider Objektorientierung in LUA, welches (ähnlich wie in Python) sehr “hineingewurstet” aussieht. Man merkt, dass all diese Sprachen ursprünglich rein funktionsorientiert gestaltet waren und Objekte später angeheftet wurden.

However, ich bin jedenfalls gespannt welche Möglichkeiten die “Verscriptung” mir noch eröffnen wird, denn aktuell steht des ganze Thema noch am Anfang.

C++ RTTI: Run-Time Type Information

2022-04-02T13:00:00+02:00

Die Run-Time Type Information (kurz RTTI) ist eines dieser Features in C++, weshalb mache Anwender auf Exceptions und virtuelle Methoden verzichten.

Denn während viele andere Features der Sprache genau “abgeschätzt” werden können, eröffnet RTTI einen Baum von Abhängigkeiten, die schnell auch zu ungewolltem Overhead werden können.

Erstmals bewusst gemacht wurde mir RTTI mit Studio 2005 und Windows CE. Denn während RTTI in jeder Standard-C++-Umgebung aktiviert ist (und bewusst deaktiviert werden müsste), werden CE-Programme ohne RTTI Support gebaut, womit dann keine einzige C++ Exception durch den Compiler durchkommt.

RTTI ist also diese geheime Kraft, die dynamic_cast möglich macht, das catchen von typisierten Exception bewirkt und dabei jede Menge kryptischen Code erzeugt, wenn man einen Blick auf den Assembler-Output wirft.

Up-Casting (also Casts von einer Ableitung zur Basisklasse) ist in C++ meistens “kostenlos”, weil Objekte von der Basis zur Ableitung hin konstruiert werden.

Wird ein Derived* Pointer zu Base* ist die Speicheradresse meist identisch, nur im Falle von Mehrfachvererbung wird ein statischer Offset addiert, weil jedes Derived Objekt seine Base enthalten muss.

Umgekehrt weiß ein Base* nicht, ob es ursprünglich mal als Derived* erzeugt wurde.
Die einzige Möglichkeit dies herauszufinden ist die v-Table bei Objekten mit virtuellen Methoden.

Der Compiler generiert daher für jedes Klasse mit virtuellen Methoden eine v-Table und verknüpft diese mit anderen v-Table Einträgen in internen Datenstrukturen.
So kann dann ein dynamic_cast beim Aufruf nachsehen, welche v-Table mit dem Objekt verknüpft ist und findet darüber heraus, ob der gewünschte Datentyp in der Hierarchie mit dem originalen Typen verbunden ist.
Wenn ja, wird ein neuer Pointer + Typ erzeugt, falls nein fliegt std::bad_cast bei Referenzen oder man erhält einen Null-Pointer zurück.

Bei Exceptions geschieht etwas Ähnliches, hier wird die Typeninformation “mitgeworfen”, damit der Code dann den richtigen catch Handler findet, wenn der Stack bis zu einem solchen zurückgebaut wurde.

Problem: Runtime

Mein größtes Problem mit RTTI ist, dass diese Typen-Information auf Daten und Strukturen der C++-Runtime-Library zurückgreift.
Der Compiler generiert also nicht nur eigenen Code, sondern setzt auch das Vorhandensein einiger weiterer Funktionen im Binary voraus, die nicht “dynamisch” generiert werden.

Beim MSVC betrifft das vor allem das Exception Handling. Das ist in regulären Windows Programmen auch kein Problem, weil diese immer mit der C-Runtime verknüpft sind.

Es gibt aber andere Orte, wo das zum Problem wird, und das wären z.B.:

die Treiber Entwicklung
oder das Erzeugen von UEFI Apps

Denn diese Kompilate enthalten keine C-Runtime und dürfen diese wegen ihrer Bindung zum OS-Usermode auch nicht beinhalten.

Und das ärgert mich. Denn der Compiler hätte die Möglichkeit, den Code generisch zu gestalten und auf die externe Runtime-Library zu verzichten.
Er tut das aber, um mit der Windows-API kompatibel zu sein und um das Structured Exception Handling zu nutzen.

Hier hätte ich mir einen Compiler-Switch erhofft, mit dem man auf “Native Exceptions” oder so etwas wechseln kann.

Aber vielleicht kommt das ja noch, denn seit ein paar Jahren geistert die Idee der Zero-Overhead-Exceptions durch die Community.

Neuer Ansatz: Zero-overhead deterministic exceptions.

Herb Sutter hat diese Vorschlag eingereicht, und er stellt damit “meine Welt” schon etwas auf den Kopf … doch wenn ich darüber nachdenke, wird mir die Idee immer sympathischer.

Wir lernten:

Throw by value, catch by reference.

Und dieses catch by reference baut ebenso auf RTTI auf, wenn jede Exception von std::exception erben soll. Folglich kann catch(std::exception&) eine jede fangen.

Hier braucht man dann zusätzlichen Code und Heap-Speicher, um die Exception zu werfen. throw muss also auf new vertrauen, was leider auch schief gehen kann.

Der andere Ansatz ist jedoch:

Wir fangen alle Exception by value.

Und das bedeutet, dass in der Funktion, in welcher der catch Block steht schon speicher allokiert werden kann, um die Exception darauf abbilden zur können. Und wenn das schon der Fall ist, können wir auch weiter optimieren und eine neue Exception schon während throw genau dort konstruieren lassen, wo sie letztendlich gefangen werden soll.

Wow, das wäre die Lösung. Denn wenn “mein Framework” keine polymorphen Klassen mehr einsetzt und per Referenz fängt, dann könnte ein statisches Programme alle Ausnahmen so generieren lassen, dass überhaupt keine dynamische Allokierung oder RTTI Auflösung mehr notwendig sind.

Fazit

Leider sind alle diese theoretischen Überlegungen noch ferne Zukunftsmusik. Denn Compiler Hersteller brauchen oft einige Jahre, um neue Features einzufügen.

Ein Verzicht auf RTTI ist also heute für mich nicht denkbar und beim MSVC leider ausgeschlossen.

Ein bisschen Hoffnung hege ich noch beim GCC, ob man den so hinbekommen kann, dass er Exceptions und RTTI Auflösungen so umsetzt, dass keine externen CRT Funktionen notwendig sind.

Mal sehen, was daraus wird, doch bis dahin bleibt C mein Favorit in Sachen EFI.

Webmin

2022-03-27T13:00:00+02:00

Es muss etwa im Jahr 2003 gewesen sein, als mir ein Freund die Installation von webmin auf meinen Linux Systemen empfohlen hat.

Und tatsächlich war dann webmin der Grund, weshalb ich überhaupt angefangen habe, mit Linux zu arbeiten.

webmin ist ein spezieller HTTP-Webserver-Dienst, der die Verwaltung anderer Dienste eines Betriebssystems über eine Weboberfläche ermöglicht.
Man kann also einen PC oder Server per Webbrowser fernwarten, überwachen und teilweise auch “live” damit arbeiten.

Obwohl es inzwischen Ports für Windows gibt, kenne ich webmin in erster Linie nur von Linux Systemen.
Die Software ist in Perl geschrieben, was sie zwar leicht portierbar macht, aber nicht immer für beste Performance steht.

Installation

webmin ist kein regulärer Bestandteil von Linux Distributionen und deshalb wurden schon immer angepasste Installationspakete für die gängigsten Paketmanager auf der webmin Homepage veröffentlicht:

RPM für SuSE oder Redhat
DEB für Debian oder Ubuntu
oder ein TAR Ball mit den Sourcen für eine manuelle Einrichtung

Hat man das Paket heruntergeladen und mit dem Standard-Toolset installiert, z.B.:
dpkg -i path/to/webmin.deb oder
rpm -i path/to/webmin.rpm
dann sollte am Ende schon auf Port 10000 der HTTPS Webserver laufen.

Die weitere Einrichtung kann also schon remote über den Browser erfolgen.

Denn dieser zeigt beim Öffnen von https://webminserver:10000/ einen Logindialog an, um sich mit einem lokalen administrativen Account einloggen zu können.

Server Verwaltung

Zu den für mich wichtigsten Aspekten von webmin zählt, dass unterschiedliche Dienste über ein WebUI verwaltet werden können. Einige Beispiele sind:

Apache HTTP (Webserver)
FTP (File transfer: ProFTPD, WU-FTP)
SQL (Datenbank Server, MySQL, MariaDB, PostgreSQL)
SAMBA (Windows Filesharing)
SMTP (Mailversand: sendmail / postfix)
SQUID (HTTP Proxy)
DNS (Domain Namen)
DHCP (IP Verwaltung)
LDAP (User Authentifizierung)
VPN Server
SSH Server
… und viele mehr

Der Dienst erkennt die Konfigurationsdateien und blendet ein WebUI ein, welches die abstrakten Zeilen in den Konfigurationsdateien in einfache Textboxen, Checkboxen und Buttons übersetzt.

So kann man die Konfiguration “gesichert” editieren und versteht meist auch viel leichter, wie der Dienst selbst aufgebaut ist, was einem beim reinen Studium der kryptischen Einträge in Textdateien nicht immer so schnell gelingt.

webmin war somit für mich das Gegenstück zu Microsofts Windows Server, der auch für jeden Dienst ein eigenes UI bereitstellt.

Über die Jahre ist webmin auch immer interaktiver geworden und benachrichtigt den Nutzer über Updates, der per Klick dann im Hintergrund installiert werden.

Fazit

webmin ist vermutlich die Software unter Linux, die ich in Summe am längsten einsetze. Denn jeder Raspberry PI und früher jeder Linux Server, den ich in Betrieb nahm, war mit diesem Werkzeug versehen.

Leider hat sich der Leistungshunger heutiger Scripts derartig erhöht, dass gerade der Einsatz auf einem Raspberry PI 2 oder Zero nicht mehr so viel Spaß macht. Da wartet man schon teils recht lange, bis eine Seite geladen werden kann, was aber an der Fülle von Funktionen liegen mag.

However, ich wette auch in 10 Jahren wird webmin weiter auf der Liste meiner “aktiven” Software sein.

SFU und SUA: Unix unter Windows

2022-03-26T12:00:00+01:00

Eher zufällig stolperte ich bereits für über 15 Jahren mit meinem damaligen Server 2003 über die interessante Erweiterung “Service for Unix”.

Denn tatsächlich gab es seit NT 4 kein Windows, das gänzlich ohne POSIX Schnittstelle auskam. Windows 10/Server 2016 war hier anfangs die Ausnahme, doch bereits im Server 2019 kehrte der Nachfolger mit Windows Subsystem for Linux zurück.

Während der damalige Microsoft-Chef Steve Ballmer anfangs der 2000er noch kräftig gegen die OpenSource Bewegung wetterte und außer Windows am Wolkenhimmel nichts anderes zu sehen vermochte, war Unix kein Feind der Windows Welt.

NT 4 hatte bereits eine primitive POSIX-Schicht eingezogen, damit man Windows als Universalsystem vermarkten konnte.
Doch offen gesagt bin ich mit dieser Variante nie in Berührung gekommen.

Ab Windows 2000, XP und Server 2003 konnte man den POSIX-Nachfolger “Services for Unix” nachinstallieren. Allerdings nur für die 32-bit Version von Windows. Wer Server 2003 X64 oder WinXP 64 einsetzte, war von der Installation ausgeschlossen.

Mit Windows Vista und Server 2008 war das Subsystem innerhalb des regulären Feature-Setups möglich und brachte auch X64 Support mit. Man musste nur das umbenannte Feature “Subsystem for UNIX-based Applications” (kurz SUA) aktivieren und schon bekam Windows unixoide Eigenschaften.

Hier fehlten dann allerdings die Unix Tools, wie auch das SDK um Software dafür zu bauen. Um das zu erhalten musste man von Microsoft weiter einen Installer herunterladen, der eben diese Dateien nachlieferte.

Ich nutzte für meine Tests meinen Windows Server 2012 und die dazugehörigen SUA SDK Tools.

SFU/SUA’s produktiver Nutzen

In meinen Arbeitsbereichen kamen SFU und SUA nie vor.
Wenn jemand Unix oder Linux-Tools nutzen wollte, installierte er Cygwin und erhielt auf diese Weise die üblichen Unix/Linux Tools.

Denn meistens ging es immer nur um die Ausführung von Scripts, und bevor sich in der zweiten Hälfte der 2000er die PowerShell unter Windows durchsetzen konnte, war Scripting unter Windows mangelhaft oder einfach unbekannt.

Aufgaben wie das tägliche automatische Herunterladen von Dateien von HTTP oder FTP Servern war mit VBScript oder BATCH Dateien unter Windows nicht direkt möglich, während Unix-Shellscripts besonders mit Linux für administrative Aufgaben schon 10 Jahre vorher “standard” waren.

SFU/SUA Dateisystem

Die Standardinstallation legt unter XP/2003 C:\SFU an, was innerhalb der Umgebung das Root-Dateisystem darstellt. So kann man von Windows aus direkt Dateien austauschen, z.B.: in C:\SFU\usr oder C:\SFU\tmp.
Die neueren Varianten (wie auch mein Server 2012) nutzen C:\Windows\SUA als Basis.

Umgekehrt ist das Windows-Dateisystem in SFU über /dev/fs/C/ erreichbar. Das gilt auch für alle anderen Windows Laufwerksbuchstaben.

/home existiert hier nicht, aber die HOME Variable zeigt auf /dev/fs/C/Documents and Settings/username bzw. /dev/fs/C/Users/username womit man auch hier wieder zwischen Win32 und SFU/SUA Programmen Dateien austauschen kann.

Interessant sind auch noch symbolische Links. Die werden im Windows Dateisystem als normale Datei angelegt, deren Inhalt aber mit dem magischen Token IntxLNK beginnt, gefolgt vom verlinkten Dateipfad in UTF-16. Die SFU Umgebung meldet sie jedoch wie übliche Links und löst den Pfad intern auf.

Programme für SFU/SUA erstellen.

In jedem MSVC Win32 Programm kann man ja ein Linker-Subsystem festlegen und das ist entweder CONSOLE oder WINDOWS. Doch wer die Liste genau betrachtet, findet auch POSIX unter den Möglichkeiten. Genau dieses Subsystem erstellt eine SFU/SUA Binärdatei.
Doch beim ersten Versuch eine Hello-World-App zu kompilieren, erscheint:

LINK : error LNK2001: unresolved external symbol ___PosixProcessStartup

Man muss also die C-Runtime und Link-Libraries auch noch etwas anpassen:

Wir müssen die Standard-C-Runtime ausschließen.
Und explizit gegen die SFU/SUA Libraries linken.

Die entsprechenden Linker-Kommandos sind

Linker-System-Subsystem:
/SUBSYSTEM:POSIX
Linker-Input-Ignore Specific Default Libraries:
/NODEFAULTLIB:LIBCMT
VC++ Directories-Library Directories:
/LIBPATH:C:\Windows\SUA\usr\lib\ für X64
oder /LIBPATH:C:\Windows\SUA\usr\lib\x86 für X86
Linker-Input-Additional Dependencies:
psxlibc.lib;crtexe.o;libpsxdll.a;libc.a

Die crtexe.o ist für mein ausführbares Programm notwendig. Allerdings liegen auch noch crt0.o und crtdll.o vor, die vermutlich für DLLs oder mit statischer/dynamischer Runtime notwendig sind.

Am Ende erhält man eine EXE, die man im SFU/SUA Kontext ausführen kann.

Im Dependency Walker kann man dann auch nachweisen, dass die EXE wirklich gegen die PSXDLL.DLL gelinkt ist, die wiederum alle POSIX Funktionen implementiert und in die Windows Welt übersetzt.

Randnotiz: Im WinXP SFU war sogar ein uralter GCC 3.3 integriert, doch ohne CMake wollte ich mir nicht die Mühe machen, hierfür ein Testprogramm zu kompilieren. However … ich wette, es hätte funktioniert.

Fazit

Nachdem ich Lust und Laune hatte, mir ein SFU/SUA Setup anzusehen, hat mir vor allem der Blog Artikel blog.ret2.io/2017/09/20/subsystem-posix super weitergeholfen, meinen Linkerfehler wegzubekommen.
Danke an den Autor!

Genau solche Infos gehen leider Stück für Stück verloren, denn SFU/SUA Installationsdateien mögen noch weiter viele Jahre im Netz auffindbar sein, doch die Dokus hat Microsoft schon lange zurückgezogen.

Ich bezweifle zwar, dass ich jemals wieder mit dieser Technologie arbeiten werde, doch es ist gut zu wissen, wie es funktioniert hat.

Schade ist, dass Microsoft seine “Verbindung” zur Unix Welt so lange verleugnet hat und erst 2017 mit WSL eine Idee hat wiederaufleben lassen, die es eigentlich schon im Jahr 2000 gab.

Star Trek: Discovery Staffel 4

2022-03-20T12:00:00+01:00

Mit der 4.Staffel von Star Trek: Discovery hatten mich die Macher, Netflix und Paramount schwer verärgert, denn wenige Tage vor dem Beginn des Ausstrahlung wurde verkündet, dass die Serie gar nicht im europäischen Raum verfügbar sein würde.

Doch … nach sehr viel Kritik … entschied man sich doch noch auf pluto.tv jede Woche eine Episode zu zeigen.

Und so kam ich letztlich doch in den Genuss, die neueste Star Trek Produktion (ganz ohne Tricks) mitverfolgen zu können.

Das “Discovery-Problem”, nämlich dass mit diesem Zauber-Raumschiff alle galaktischen Probleme gelöst werden können, an denen alle anderen scheitern, durchzieht wie erwartet auch die neueste Staffel.

Waren Kirk, Picard, Sisko und Janeway vor 20 Jahren immer wie Figuren in einem Schachspiel, die nur “in ihrer Ecke” aufräumen konnten, hat die USS Discovery mit ihrem Sporenantrieb einen Joker im Ärmel, der scheinbar immer alles ändern kann.

Ich gebe aber zu, dass ich dieses “neue StarTrek” mit jeder Staffel besser akzeptieren und die Nostalgiebrille leichter abnehmen kann, um die Intention der Story aufnehmen zu können.

Achtung Spoiler

Hatte die Discovery in Staffel 3 die “zerbrochene” Föderation wiedervereint, musste nun eine neue galaktische Bedrohung her, die natürlich prompt auftauchte. Ein destruktives Phänomen taucht auf, und zerstört jedes Sonnensystem in seiner Umgebung, löscht binnen Sekunden Milliarden von Leben aus …. und ganz wichtig:
Jeden kann es als nächstes treffen.

Neben (aus meiner Sicht zu viel) Herzschmerz und anderen privaten Details der Crew, erkennt man schnell:

Hier haben wir es mit einer überlegenen Technologie zu tun.
Eine maschinell eingeleitete Apokalypse eine unbekannten Spezies, die allen anderen bekannten Lebensformen haushoch überlegen zu sein scheint.

Hier kommt nun wieder ein bisschen Deep Space 9 Feeling auf, wenn die “Politik” endlich mal realistisch zu diskutieren beginnt und fragt:

Sollen wir versuchen zu kommunizieren, oder sollen wir “dem Angriff” mit härtesten Gegenmaßnahmen begegnen?

Und so schreitet Episode für Episode die Divergenz voran, zwei Meinungen, die nicht vereinbar sind, ziehen unterschiedliche Charaktere auf ihre Seite und “interne Konflikte” gedeihen.

Ein paar Bröckchen Fan-Service

Wenn eine neue Schiffswerft “Archer” getauft wird und die Melodie von Star Trek: Enterprise läuft, wenn Boronit erwähnt wird, oder Isolytische Waffen oder die große Barriere durchquert werden muss, dann weiß jeder eingefleischte Fan, dass das nur eingebaut wurde, um die alten Hasen bei Laune zu halten.

Hier würde ich auch mit der “technischen Kritik” starten, denn wenn mit Boronit die gefürchteten Omega-Moleküle hergestellt werden können, die “alle anderen Prioritäten” in Star Trek: Voyager aufheben haben lassen, dann war das in Discovery nur eine beiläufige Bemerkung, a la:

Ach sieh mal, die sammeln Boronit.

Und wenn ein Captain Kirk in seiner aller ersten Folge die “große Barriere” streift und sich gleich zwei seiner Leute in Gott-gleiche Wesen weiterentwickeln, dann verstehe ich nicht, wie die Discovery einfach so in einer Quanten-Seifenblase da ohne Seiteneffekte durchtreiben kann.

Aber genug davon … ganz so “kanonisch” war der Star Trek Kanon ja nie.

Viel zu viel für meinen Geschmack war der andauernde Herzschmerz zwischen den Figuren, die sich nur all zu schnell von ihren Gefühlen übermannen lassen … aber das scheint offenbar heute “normal” zu sein.

Raubbau, Gier und Egoismus

Man muss tatsächlich bis zur letzten Folge warten um zu lernen, dass die angerichtete Zerstörung nur ein “umweltschädlicher” Nebeneffekt eines “Erzabbaus” war.
Die geheimnisvolle Spezies “10-C” öffnet also wahlfrei Wurmlöcher in unsere Galaxie um wertvolle Materialien für ihre Energiegewinnung absaugen zu können.
Noch besser: Um ihr eigenes Sonnensystem mit einem Energiefeld umgeben zu können um vom Rest der Welt “sicher zu sein”.

Also … wenn da keine Kapitalismus- und Gesellschaftskritik drinnen war, dann weiß ich auch nicht mehr weiter.

Und offenbar brauchen wir genau das.

Wir sehen jeden Tag, wie wir Menschen “unbewusst” unsere Welt zerstören, nur um irgend ein egoistisches Luxusziel zu erreichen und gar nicht mehr fähig sind zu erkennen, was wir dabei anrichten.
Wissenschaftler, die uns die Wahrheit sagen wollen, erklären wir zu Lügner und Jugendlichen, die für eine bessere Welt demonstrieren, wird Faulheit vorgeworfen, wenn sie einmal nicht brav vor dem Schreibtisch sitzen.

Während Star Trek in den 1960ern mit banalen “schwarz-weiß” Masken den Rassismus erst “sichtbar” machen musste, brauchen wir heute offenbar auch erst eine andere Spezies, die “versehentlich” die Welt zerstört, um vielleicht mal ein bisschen darüber nachzudenken, dass wir selbst diese böswilligen Außerirdischen sind, die den Planeten mit Füßen treten.

Fazit

Ich hatte damit nicht gerechnet, aber es ist mir in den letzten Minuten der letzten Folge nicht gelungen, ein Tränchen zurückzuhalten.

Als nach dem Sieg der Diplomatie über die Waffen, die Präsidentin der Erde die wichtigen Worte spricht:

Es gibt nichts zu diskutieren.
Die Erde ist bereit der Föderation wieder beizutreten.
Und nichts könnte mich glücklicher machen, als diese Worte zu sagen.

Ja, so ein Ende wünsche ich mir, für unsere reale Welt … selbst wenn es wie hier mit kitschigen Kamerafahrten und Chorstimmen im Hintergrund gespickt ist.
Eine Welt, in der Trump’s Mauern immer noch in vielen Köpfen verharren und in denen sowjetische Autokraten mit Atomsprengköpfen liebäugeln.

Ich wette, es wird eine Menge Stimmen im Netz geben, die jetzt alles Negative an den Figuren und der Story durch den Kakao ziehen werden.
Und in 10 Jahren wird man (so wie bei allen Star Trek Serien) diese Abbildung der aktuellen Probleme in die ScFi-Welt als “visionär” loben.

Ich jedenfalls bin dem Team und der Besetzung von Star Trek: Discovery dankbar, dass sie uns endlich wieder ein Bild der Hoffnung präsentiert haben, dem wir ideologisch folgen können.

Ich hatte besonders am Beginn und am Ende der Staffel ein ungewöhnlich tiefes Verständnis für den Inhalt. Vielleicht sehe ich es in ein paar Jahren wieder ganz anders, weil es doch zu plump war, aber aktuell kann ich Star Trek - wie so oft schon - einfach nur empfehlen.

Abstürze abfangen

2022-03-19T12:00:00+01:00

Das Schlimmste, was passieren kann, ist, wenn eine Fremdbibliothek in einem internen Aufruf eine Schutzverletzung (Segmentation Fault) produziert und den eigenen Prozess dann gleich mit in den Abgrund reißt.

Das Debugging wird dann sehr erschwert.

Doch es gibt Hoffnung: Man kann auch SegFaults abfangen und im Idealfall einen Crash verhindern.

Das größte Problem von SegFaults oder Division durch Null sind das sofortige Beenden des Auslöserprozesses. Es wird nichts mehr in ein Log geschrieben und man kann keinen geordneten Shutdown durchführen.

Doch auch Hardware-Ausnahmen wie fehlerhafte Speicherzugriffe oder Rechenfehler können im Usermode abgefangen werden.

Und zwar sind das Fehler wie z.B.:

Zugriff auf ungültigem Speicher
- Null-Pointer
- Freigegebener Speicher
Ungültige Instruktion
- Eine CPU-Anweisung, die der aktuelle Prozessor nicht kennt (weil zu alt)
- Eine privilegierte Anweisung, die nur der OS-Kernel, aber kein Nutzerprogramm ausführen darf
Mathematische Fehler
- Division durch 0
- Rechenoperationen in Zahlenbereichen außerhalb der unterstützten Grenzen.
Interne Fehler des Betriebssystems
- Ungültige Handles and Deskriptoren

Windows Structured Exception Handling

SEH (Structured Exception Handling) definiert eine Schnittstelle, über die ein Programm einen Codepfad registrieren kann, der ausgeführt wird, wenn ein kritisches Problem auftritt.

Microsofts Visual C/C++ nutzt eine Erweiterung des C-Standards und führt die Schlüsselworte __try und __except ein, womit man SEH-Exception ähnlich wie C++ Exceptions im Code einbetten kann.

 1__try
 2{
 3  int* ptr = NULL;
 4  printf("%d", *ptr);
 5}
 6__except(EXCEPTION_EXECUTE_HANDLER)
 7{
 8  printf("Exception caught");
 9}

Der __try Block registriert am Anfang den Filter-Code innerhalb von __except() im Thread Environment Block (TEB) und das OS ruft bei einem kritischen Fehler dann genau den Code auf.
Wenn der Rückgabewert EXCEPTION_EXECUTE_HANDLER ist, wird der nachfolgende Codeblock ausgeführt.

Es ist aber auch erlaubt EXCEPTION_CONTINUE_SEARCH zurückzugeben und dann sucht das System in der Liste der registrierten Exception-Handler den nächsten aus und springt in dessen Callstack-Zweig, wenn dieser dann EXCEPTION_EXECUTE_HANDLER zurückgibt.

Deshalb wird in __except meist eine “Filterfunktion” aufgerufen, die mit GetExceptionCode() auswerten (und regieren) kann.

 1static DWORD eval_exception(DWORD exception_code) 
 2{ 
 3  switch(exception_code)
 4  {
 5  case EXCEPTION_ACCESS_VIOLATION:
 6  case EXCEPTION_ARRAY_BOUNDS_EXCEEDED:
 7  case EXCEPTION_DATATYPE_MISALIGNMENT:
 8  case EXCEPTION_IN_PAGE_ERROR:
 9    /* we handle only memory errors */
10    return EXCEPTION_EXECUTE_HANDLER;
11  default:
12    /* other errors shall be handled by someone else */
13    return EXCEPTION_CONTINUE_SEARCH;
14  }
15} 
16
17__try
18{
19  ...
20}
21__except(eval_exception(GetExceptionCode()))
22{
23  printf("This is a memory-related error");
24}

Alle Exception-Codes sind auf der GetExceptionCode() Seite dokumentiert.

POSIX Signale und longjmp

Auf POSIX Systemen unterbricht der Kernel einen korrumpierten Thread und sendet ihm ein Signal. Diese kann dann in einem vorher registrierten Signal-Handler behandelt werden. Ist ein solcher Handler nicht registriert, wird der Prozess beendet.

Das Problem ist, dass nach dem Verlassen des Signal-Handlers der Prozess ebenso beendet wird, weil nach dem Signal zum korrupten Code zurückgesprungen werden müsste.

Es gibt aber einen Ausweg, und der lautet: setjmp() / longjmp(). Hat man sich nämlich selbst darum gekümmert, den Callstack zu sichern, dann kann im Signal-Handler per longjmp zu diesem sicheren Ort zurückgesprungen werden.

Und das funktioniert sogar bei den Signalen SIGSEGV (Speicherverletzung), SIGILL (Falsche CPU Anweisung) oder SIGFPE (Division durch 0 und andere Rechenfehler).

Ein Flexibilitätsproblem ist jedoch, dass man Signal-Handler in der Regel Prozess-global setzt. Man kann also nicht in Thread A den Signal-Handler x() einrichten und in Thread B dann y() aufrufen lassen.

Meine Strategie ist daher folgende:

Es wird je ein globaler Signal-Handler für die kritischen Signale SIGSEGV, SIGILL und SIGFPE am Programmstart gesetzt.
Es wird auch ein globaler Schlüssel für eine Thread-local-storage Eintrag erzeugt (pthread_key_create).
Vor einem kritischen Bereich (also wie beim Start von __try) wird eine lokale jmp_buf Variable angelegt und per setjmp initialisiert.
Nun wird ein Pointer zum jmp_buf in den Thread-local-storage mit dem zuvor registriertem Schlüssel gesetzt.
Tritt eines der obigen kritischen Signale auf, kann der gesetzte Signal-Handler den Pointer zum jmp_buf wieder auslesen und per longjmp zum gesicherten Stack zurückspringen.

 1/* crash_guard_sample.c */
 2/* gcc ./crash_guard_sample.c -lpthread -o ./crash_guard_sample */
 3#include <stdio.h>
 4#include <pthread.h>
 5#include <setjmp.h>
 6#include <signal.h>
 7
 8static pthread_key_t saved_context_key;
 9
10typedef struct
11{
12  jmp_buf anchor;
13} saved_context_t;
14
15static void crash_handler(int signum)
16{
17  saved_context_t* ptr_context = 
18    (saved_context_t*)pthread_getspecific(saved_context_key);
19
20  switch(signum)
21  {
22  case SIGSEGV: 
23    longjmp(ptr_context->anchor, 1);
24  case SIGILL:
25    longjmp(ptr_context->anchor, 2);
26  case SIGFPE:
27    longjmp(ptr_context->anchor, 3);
28  }
29  /* unhandled error */
30  return;
31}
32
33void crashing_function()
34{
35  int* volatile ptr = NULL;
36  *ptr = 42;
37}
38
39void run()
40{
41  saved_context_t saved_context;
42  int crash_status;
43  pthread_setspecific(saved_context_key, &saved_context);
44  crash_status = setjmp(saved_context.anchor);
45  if(crash_status == 0)
46  {
47    /* try block: */
48    printf("Before critical code\n");
49    crashing_function();
50    printf("Nothing bad happened\n");
51  }
52  else
53  {
54    /* except/catch block */
55    printf("Critical error #%d caught\n", crash_status);
56  }
57}
58
59int main()
60{
61  printf("main() begin\n");
62  pthread_key_create(&saved_context_key, NULL);
63  signal(SIGSEGV, &crash_handler);
64  signal(SIGILL, &crash_handler);
65  signal(SIGFPE, &crash_handler);
66
67  run();
68  printf("main() end\n");
69}

Und streng genommen sollte man nicht setjmp / longjmp einsetzen, sondern sigsetjmp / siglongjmp, die auch die Signalmaske sichern und wiederherstellen, ansonsten landet man bei undefiniertem Verhalten, wenn man den Signalhandler per longjmp verlässt.
Ich hatte damit zwar keine Probleme, doch nur weil etwas funktioniert, heißt es nicht, dass es damit richtig ist.

Fazit

Im BLOG-CLASSROOM habe ich das ganze mal etwas vollständiger als Crash-Guard Bibliothek eingefügt. Und im GATE Framework sind die beschriebenen Techniken auch eingearbeitet.

Mein Interesse für diese Thematik begann vor Jahren mit einer Software in der ein Plugin immer wieder rätselhafte Abstürze auslöste und mit solchen Crashguards konnte ich das Problem auf ein ganz bestimmtes Submodul eingrenzen und letztendlich lösen.

restrict

2022-03-13T12:00:00+01:00

Mit der Fehlermeldung

error C2485: ‘constant’: unrecognized extended attribute

eröffnete mir der MSVC 2022 beim Kompilieren von libreSSL die Möglichkeit, wieder einmal über ein “neueres” C Schlüsselwort nachzudenken, nämlich restrict

Was ist ein mit `restrict` markierter Pointer?

Das C99 Schlüsselwort restrict ist vielen Entwicklern unbekannt und hilft daher eher im Hintergrund, den generierten Code zu optimieren.
restrict “qualifiziert” einen Pointer als alleinigen Zugang zu einer Ressource. Ähnlich wie register ist restrict nur ein Hinweis für den Compiler, der angewendet oder ignoriert werden kann.

1int* restrict foo(int arg1, int* restrict arg2);

z.B.: kann malloc() seine zurückgegebenen Pointer als restricted markieren um zu signalisieren, dass zum Zeitpunkt der Allokierung dieser Pointer als einziger auf den neuen Speicherblock zeigt.

So lange Pointer ihren restricted Status behalten, können Pointeroperationen wie z.B.: memcpy() oder memmove() auf Prüfungen verzichten, ob Quelle und Ziel einer Speicheroperation sich überschneiden.
Zwei per malloc() erzeugte Pointer können per memcpy/move() sofort abgearbeitet werden, und zwar mit den schnellst möglichen Instruktionen, wie z.B. Vektoroperationen.

Nicht restricted Pointer könnten auf sich überlappende Speicherbereiche zeigen, womit memcpy/move() diesen Fall prüfen müssen und erst zur Laufzeit die geeigneten Bearbeitungsinstruktionen auswählen können.
Anders gesagt: Da findet oft noch ein zusätzliches if statt.

Compiler Support

Tja, leider hat jeder Compiler-Hersteller “anders” auf restrict reagiert. Microsoft hat C99 bis MSVC 13 ignoriert, aber schon vorher __declspec(restrict) in C und C++ aufgenommen.

Im GCC hingegen nimmt __restrict__ diesen Platz ein.

Und aus diesem Grund nutzen manche Bibliotheken eigene Makros um nicht restrict sondern die native Variante des Compiler zu nutzen.

Und das wiederum kann die Quelle neuer Fehler sein:

libReSSL und `restrict`

Als ich den Fehler error C2485 sah, konnte ich ihn zu folgender Codestelle in corecrt.h zurückverfolgen:

1#if defined _CRT_SUPPRESS_RESTRICT || defined _CORECRT_BUILD
2    #define _CRTRESTRICT
3#else
4    #define _CRTRESTRICT __declspec(restrict)
5#endif

Viele allokierende C-Funktionen wie malloc oder calloc werden mit _CRTRESTRICT deklariert.

Die “schnelle” Lösung ist somit, das Makro _CRT_SUPPRESS_RESTRICT zu aktivieren, was in CMake so aussieht:

1add_definitions(/D_CRT_SUPPRESS_RESTRICT)

und tatsächlich würde das mein Problem bereits lösen.

Doch bei genauerer Betrachtung, stellt sich heraus, dass nur libreSSL ein Problem mit der C-Runtime hat, während alle anderen Libs malloc mit _CRTRESTRICT == __declspec(restrict) problemlos nutzen können.

Der Grund liegt in libressl/CMakeLists.txt, denn dort findet man die Zeilen

1if(WIN32)
2  add_definitions(-Drestrict)
3  ...
4endif()

Es wird also ein Makro namens restrict angelegt und ohne weiteren Parameter erhält das Makro den Wert 1.
Das führt dazu, dass _CRTRESTRICT als __declspec(1) aufgelöst wird und schon haben wir die Ursache für

error C2485: ‘constant’: unrecognized extended attribute

gefunden.

Lösung

Ich habe den CMAKE Code von libressl einfach auf

1if(WIN32)
2  if(NOT MSVC)
3    add_definitions(-Drestrict)
4  endif()
5  ...
6endif()

umgestellt, womit MSVC Builds das Makro überspringen. In anderen Windows-Kompilaten wie z.B.: beim MinGW kann das Makro gerne weiter seinen Zweck erfüllen, doch im MSVC stört es.

Tatsächlich stört das Makro nur im Zusammenhang mit den neueren MSVC Compilern und mit der Universal-CRT (UCRT).

Fazit

Im GATE Projekt mache ich weiter einen Bogen um restrict. Mir ist es lieber, wenn in machen Fällen ein nicht-perfekter Code generiert wird, doch dass dieser zumindest überall kompiliert werden kann.

Würde ich restrict selbst benutzen, müsste ich mir genau überlegen, auf welche Plattform es verfügbar ist, und dort, wo es fehlt, ebenfalls Ersatzmakros setzen.

Genau diese “Ersatzmakros” machen dann immer Probleme, wenn unterschiedliche Bibliotheken zusammengeführt werden, und deshalb lasse ich es.

Aber grundsätzlich ist das sehr Schade, dass ein 20 Jahre altes Feature bis heute nicht einheitlich und problemfrei umgesetzt ist und deshalb Probleme bereitet.

Zum Glück können heutige Compiler aber viele Informationen aus dem Code ableiten und auch ohne restrict viele Optimierungen einleiten.

Nachtrag

Und zwei Tage später ist alles anders …

Am 15. März wurde libreSSL 3.4.3 veröffentlicht, wo die -Drestrict Zeile bereits entfernt wurde. Offenbar hat man die sowieso nicht gebraucht.

Das heißt also: Die SSL Jungs haben brav auch ihre Aufgaben gemacht.

Serieller Bypass

2022-03-12T12:00:00+01:00

Unterschiedliche Menschen sehen die gleichen Dinge unterschiedlich.
Manche schreiben Buchstaben, die einen von links nach rechts, die anderen umgekehrt, und wieder andere malen Logogramme von oben nach unten.

… und unterschiedliche Mainboards nummerieren COM-Port Pins unterschiedlich. Einige waagerecht, andere senkrecht.

Bevor ich mein offenbar nicht mehr funktionierendes Null-Modem-Kabel in den Müll werfen wollte, machte ich einen letzten Test mit einer Steckbrücke, wo Senden- (TX) und Empfangs-Pin (RX) kurzgeschlossen, um zu erkennen: Es funktioniert doch noch!

Aber warum ließ es mich im Stich, als ich meinen Development-PC mit einem meiner ITX-Boards verbinden wollte?

Beim ITX-Board war die serielle Schnittstelle hinten am Mainboard fix per D-SUB-9 Stecker verdrahtet, doch am Development-PC hatte ich den seriellen Stecker mit einem Adapter von den Mainboard-Pins selbst hinten rausleiten müssen. (Denn heutige PCs sparen den RS232-Anschluss leider ein.)

Meinen Stecker-Adapter hatte ich vor vielen Jahren bei einem anderen Board ausgebaut und dachte, dass COM Anschlüsse so wie USB oder Audio-Anschlüsse normiert wären.

Tja, falsch gedacht.

Bei diesem D-SUB-9-Stecker werden die Pins an beiden Enden wagerecht durchnumeriert, wie mein Test mit dem Multimeter nachweisen konnte. Die Pins am Mainboard entsprechen also exakt dem Verlauf der Pins des seriellen Steckers von links nach rechts:

PIN	Position	Bedeutung
1	Oben von links 1	DCD
2	Oben von links 2	RX
3	Oben von links 3	TX
4	Oben von links 4	DTR
5	Oben von links 5	GOUND
6	Unten von links 1	DSR
7	Unten von links 2	RTR
8	Unten von links 3	CTS
9	Unten von links 4	RING

Doch laut Mainboard-Manual werden die Pins am Board immer von oben nach unten durchgezählt:

Lösung = Bastelplatine + Steckerbuchsen + Lötkolben

Da ich für mein Mainboard keinen RS232-Adapter mitgeliefert bekommen habe, war die Lösung einfach zwei Steckerbuchsen auf eine Platine zu löten und die Pins zwischen den beiden richtig zu verdrahten:

Das lästige dabei ist das doppelte spiegelverkehrte Denken zwischen links und rechts sowie oben und unten … doch für den ersten Test reichten GND, TX und RX vollkommen aus.

Zum Glück hatte ich auch noch eine 10-Pin-Verlängerung in meiner Sammelkiste und schon konnte der erste Test gemacht werden.

Fazit

Im Mainboard-Handbuch stand tatsächlich der Kommentar, ich solle mich mit meinem lokalen Vertriebspartner in Verbindung setzen um einen “offiziellen” Steckeradapter nachkaufen zu können.

Doch mit 15 Minuten Bastelarbeit, hat sich das Problem von selbst gelöst und mein altes Steckerstück darf weiter seinen Dienst tun.

Es sieht zwar aus wie die Murxerei eines 10-Jährigen, aber es funktioniert. Und mir geht es ja nur darum, meine Softwaretests durchführen zu können.

Ich überlege noch, ob ich Schalter einlöten soll, um die Verbindung gezielt unterbrechen zu können, denn so kann man Übertragungsfehler ganz einfach “mechanisch” simulieren.

archive.org

2022-03-06T12:00:00+01:00

Entgegen vieler Behauptungen nach der Art:

Das Internet vergisst nicht.

behaupte ich: Das Gegenteil ist der Fall.
Denn Websites und Software, die älter als 5 Jahre sind, verschwinden von heute auf morgen, wenn Firmen Pleite gehen oder Privatleute ihre Homepage auflösen. (Nur bescheuerte Fotos von Fresstellern und Katzen leben auf Facebook ewig weiter.)

Doch einer kämpft gegen das globale Vergessen an:
Das Internetarchiv von archive.org.

Tja, da dachte man, die ersten Fehlgriffe in der Webentwicklung aus den 2000ern wären längst vergessen, und dann findet man dennoch ein Abbild auf web.archive.org. Denn bereits vor 20 Jahren hat das Internet Archiv entweder automatisch oder bewusst “bestellt” HTML Seiten herunter geladen und für die Nachwelt konserviert.

Ein Blick in die Vergangenheit

Wenn mir also langweilig ist, kommt es schon mal vor, dass ich einen Domänennamen eines früheren Arbeitsplatzes eintippe und mich köstlich darüber amüsiere, wie Homepages “damals” vor 15 Jahren aufgebaut waren … oder man lacht, weil sich bis heute nichts daran geändert hat … und dementsprechend “aussieht”.

Leider funktionieren gerade neuere Snapshots nicht mehr richtig, weil zwar der HTML Content und ein paar Grafiken gespeichert wurden, doch diverse Javascripts, die Daten dynamisch von den Originaldomains nachladen wollen, versagen unweigerlich.

Ich selbst habe bei einigen Webprojekten immer wieder zahlreiche URLs bei archive.org gemeldet, um sie sichern zu lassen, und bin froh, dass sie auf diese Weise bis heute überlebt haben.

Das große Retro-Software Archiv

Wenn man Wikipedia z.B.: zu Windows PE befragt, lernt man viel über die unterschiedlichen Versionen … doch regulär erhalten kann man leider nur mehr die neuesten.
Microsoft bietet in seinen MSDN Abos zwar bis heute Windows 3.x und Visual Basic Classic 2 bis 6 an, doch WinPE wurde mit Ausnahme der neueren Windows 10 Varianten von den Downloadseiten entfernt.

Welch Glück, dass einige aufmerksame Mitmenschen dieses Manko bemerkt haben und ihre damals gesicherten Downloads wieder verfügbar gemacht haben, und zwar auf archive.org. (Lizenztechnisch sollte das in Ordnung gehen, da WinPE immer schon frei verfügbar war und nur der produktive Einsatz an andere Windows-Lizenzen gebunden war.)

Nach einer Registrierung kann nämlich jeder User Daten auf diese Plattform hochladen.
Gedacht ist das natürlich primär für freie Informationen und persönliche Daten (wie z.B. alte Fotos oder Bücher), doch inzwischen findet man dort auch eine Vielzahl von Softwarestücken, deren Softwarepatente und anderen Beschränkungen abgelaufen sind.

Und so hat sich archive.org zu einem interessantem Museum für digitale Werke entwickelt und konserviert auf diese Weise auch den “Zeitgeist” der Softwareindustrie der vergangenen Jahrzehnte.

Fazit

Ich finde solche Projekte wirklich großartig, denn mit einer größeren Organisation im Hintergrund, hege ich die Hoffnung, dass dieses Archiv sicher noch lange überdauern wird.

Denn dass viele digitale Werke oft mit dem Tod ihrer Autoren vollständig aus dem Netz verschwinden, ist dem kommerziellen Gedanken der Provider geschuldet. Sobald die nächste Jahresrechnung einer Domain nicht bezahlt wurde, oder ein kostenloser Hoster eingegangen ist, verschwinden oft unzählige wertvolle Dokumentationen zu Technik und Software für immer.

archive.org wirkt der Netz-Demenz nachhaltig entgegen und ich hoffe, dass vielleicht auch meine Beiträge auf diese Weise ein “längeres” Leben beschreiten dürfen.
Und gleichsam möchte ich auch für diese Plattform werben, dass auch andere Entwickler und Blogger ihre Inhalte über das Archiv verewigen lassen.

Wie man heute also sagt: Daumen hoch! 👍

Logging und Zustände

2022-03-05T12:00:00+01:00

Wenn man mit Hintergrunddiensten arbeitet, die sich schwerer debuggen lassen und an keine UI oder Konsole gebunden sind, bekommt ein uraltes Schema wieder eine große Bedeutung: Nämlich leicht lesbare Logdateien.

Basierend auf den Erfahrungen mit anderen Bibliotheken wurde im GATE Framework auch ein “etwas anderes” Logging-System integriert.

Viele Softwarekomponenten erachten Logs als Debugging-Feature, das keinen Standards zu folgen braucht.
Genau deshalb gibt es keinen mir bekannten übergreifenden Standard, was in einem Log-Eintrag genau drinnen stehen sollen.

Das fängt an mit reinen Textzeilen, wo jede Zeile eine unformatierte Nachricht sein kann und endet bei CSV oder anders separierten Textzeilen, die beliebig viele Felder beinhalten können.

Die meisten beginnen noch ziemlich gleich, nämlich mit einem Zeitstempel, doch schon die Frage, wie der aufgebaut sein soll, zieht zahlreiche Interpretationsunterschiede (z.B. UTC oder Lokalzeit) nach sich.
Auch gibt es häufig LOGLEVELS, die die nachfolgende Nachricht als INFO, WARNING oder ERROR qualifizieren sollen.
Und auch sie sind in jedem Projekt anders aufgebaut.

GATE LogEntry Definition

Das GATE Logging Framework definiert ein Interface, um eigene Logger zu implementieren und um diese auch “global” registrieren zu können.
Die vorbereitete Standardimplementierung ist ebenso Text-Datei-basiert, setzt jedoch Dateisperren ein, um ein gegenseitiges Überschreiben von mehreren Threads zu verhindern.

Format:
Die Felder in einer Logzeile werden durch TAB Zeichen getrennt, um weiter maschinenlesbaren Code zu generieren, der aber bei der Ausgabe auf der Konsole zumindest “halbwegs” formatiert ist und die Felder zumindest teilweise tabellarisch dargestellt werden.
Zeit:
Die Uhrzeit soll immer als ISO 8601 formatierte Lokalzeit dargestellt werden und eine Auflösung von Millisekunden haben. z.B.: 2022-03-05T23:59:59.999+01:00
- Durch ISO 8601 lässt sich die lokale Zeit immer auf eine vergleichbare globale umrechnen und trotzdem gehen wichtige Infos, wie die lokale Datumsgrenze nicht verloren.
  Denn häufig macht es Sinn sehen zu können, ob Probleme eher am lokalen Morgen auftreten (z.B. Arbeitsschichtbeginn), oder nach Mitternacht, wenn oft Backups oder andere Mechanismen anspringen.
- Eine Auflösung von Millisekunden erscheint mir in der Regel hoch genug, da oft auch Betriebssysteme gar keine höhere Auflösung zuverlässig liefern können. (Ausnahme bestätigen natürlich die Regel.)
Prozess + Thread-ID:
So lassen sich Log-Einträge wunderbar eindeutig einer Ausführung zuordnen. Prozess-IDs lassen Rückschlüsse auf Neustarts oder Abstürze zu, während Thread-IDs parallele Ausführungen identifizieren können.
Log-Type (oder auch log-level):
Hier habe ich mir einen neuen einfallen lassen, den man sonst selten antrifft, nämlich STATUS und dieser reiht sich wie folgt ein:
- TRACE: Jede (auch noch so unwichtige) Aktion wird geloggt.
- DEBUG: Alle internen Zwischenschritte werden geloggt, die vor allem dem Programmierer helfen sollen.
- INFO: Logt alle logischen Schritte, damit ein Anwender den Ablauf eines Prozesses nachvollziehen kann.
- STATUS: Logt alle großen “Meilensteine”, also Statusänderungen, die durch den Abschluss einer Teiloperation erreicht werden.
- WARN: Logt Warnungen, also Fehler, die noch nicht sonderlich kritisch sind, aber trotzdem beobachtet werden sollten.
- ERROR: Logt Fehler, die das Erreichen des Pogrammzieles verhindern können oder verhindert haben.
- FATAL: Logt extrem kritische Fehler, die eine spätere “Verbesserung” der Situation ausschließen.
Result-Code:
Da fast alle GATE-APIs diese Codes nutzen, die Fehler einigermaßen abstrakt beschreiben können, werden sie auch hier geloggt.
Native-Code:
Zusätzlich zum generischen Result-Code kann optional der originale Fehler als Zahl ausgedrückt werden. Dieser hat dann je nach benutzter API eine andere Bedeutung, hilft aber beim Debugging. Meist stammt er aber von GetLastError() oder errno.
Origin/Module:
Name des Ursprungs oder des Modules, in dem das Log-Ereignis aufgetreten ist. Hier kann man eine Kombination aus Software-Paket und Klasse oder Funktion eintragen.
Message:
Diese Text Nachricht soll vor allem dem Endanwender konkret schildern, was genau passiert ist.
Source/Location: Optional kann man dann noch Quellcode-Datei + Zeilennummer speichern, um den exakten Ort des Problems ausfindig machen zu können.

Bei der Initialisierung des Logging-Frameworks kann man auch konfigurieren, ab welchem Loglevel Daten mitgeschrieben werden sollen.

Und genau deshalb habe ich mich für den Loglevel STATUS als reduzierte Form von INFO entschieden, um nicht den Überblick in Detailinformationen zu verlieren.

Denn während Probleme (ab WARN) hoffentlich eher selten in Logs vermerkt sind, stellt das Level INFO oft sehr viele Details ein, die anfangs alle sinnvoll wirken, aber bei größeren Projekten gerne auswuchern.

Mit STATUS soll also nicht jede geöffnete Datei abgebildet werden, sondern nur das Erreichen von “operativ-relevanten” Zuständen.
Ein klassisches Beispiel wäre der “Operational” Zustand eines Dienstes, nachdem er zahlreiche Initialisierungsschritte und kleinere Hilfsdienste ausgeführt hat.

Im produktiven Betrieb lässt sich so einfach nach >= STATUS filtern um schnell einen Überblick zu bekommen.

Fazit

Der Microservice-Hosting Dienst gatesvc nutzt vorerst das “einfache” Dateilogging um seine Zustände nachvollziehbar niederzuschreiben und damit konnte ich vom Docker, Nanoserver bis hin zu BSD Daemon Startups wieder einige Bugs finden und bekämpfen.

Langfristig macht es vielleicht Sinn sich einen eigenen Logging-Dienst zu basteln, der die Logs systematischer und ohne Dateisperren verwaltet, doch die aktuelle Implementierung glänzt durch Einfachheit und Unabhängigkeit.

Mal sehen, wie sich das weiterentwickelt.

PS: Eines kann ich jedenfalls ausschließen:
Nämlich dass komplexe Fehlerfallen wie log4j bei mir Einzug erhalten, die ungefragt die zu loggende Nachricht auf Muster parsen und diese dann auch noch ausführen wollen.

Lokale C++ Typen

2022-02-27T12:00:00+01:00

Compiler Experimente mit älteren Varianten des GCC haben mir leider einen Workaround zerschossen, den ich als Abstraktion und Ersatz von Lambda Ausdrücken vorgesehen hatte:

Nämlich den Einsatz von lokalen Typen.
Konkret: Klassen, die innerhalb einer Funktion deklariert werden.

Wenn der GCC nämlich einen Fehler wie folgt produziert:

error: template argument for some_function(...) uses local type other_function::class_name

Wurde ein Fall ausgelöst, den Microsofts MSVC offenbar immer schon ignoriert hatte und der beim GCC mit der Aktivierung von C++11 entschärft wurde.

Auf stackoverflow.com wurde auch schon die Erklärung präsentiert: Man darf nämlich solche lokalen Typen nicht in Templates benutzen.
Dort schlägt dann nämlich die Typenableitung fehlt.

Bisher war mir das nicht aufgefallen, da meine Testkompilate immer mit GCC Varianten >= 6 erfolgten, doch mit einem GCC 5 wird der Fehler sofort sichtbar.

Mit C++11 wurde (vermutlich eben genau wegen Lambdas und auto) diese Regel gelockert, wovon bei den neueren GCCs offenbar auch die älteren C++ Standards berührt werden.

Die “schnelle” Lösung sieht also so aus, dass beim GCC C++11 immer aktiviert ist.

In CMAKE kann man das entweder mit der Variable CMAKE_CXX_STANDARD=11 (ab CMAKE 3.1) erreichen, oder indem man den CMAKE_CXX_FLAGS einfach ein -std=gnu++11 anhängt.

Doch genau das führt jetzt meine ursprüngliche Implementierung teils ad absurdum und macht sie zu einer reinen MSVC-only Lösung.
Denn mit C++11 werden Lambdas im Sprachstandard aktiviert und somit kommt mein Workaround mit Makros und lokalen Klassen gar nicht zu Einsatz.

Und somit fällt die Kompatibilität zu noch älteren GCCs ohne C++11 vollständig weg, was ich eigentlich nicht wollte.

Fazit

Tja … zu früh gefreut. Oder?

Ich bin mir jetzt noch nicht sicher, wie ich mit der Erkenntnis umgehen soll. In Sachen Kompatibilität ist mein Anspruch in Richtung Microsoft weitreichender, als das unter Linux der Fall wäre.

Mit WinCE bleibt der MSVC 2005 nach wie vor ein “notwendiger” Compiler für mich, wo der Workaround funktioniert.
Aber antike Linux-Systeme mit C++98/03 von vor über 10 Jahren muss ich (aktuell) nicht supporten … von daher kann ich mich vorläufig auf der erzwungenem C++11 Konfiguration ausruhen.

Zumindest habe ich nun eine Erklärung dafür gefunden, warum z.B. boost Lambdas auch nie über lokale Typen implementiert hat.

Und die Moral von der Geschicht’:
Buggy-Compiler erlauben vieles.
Aber standard-konforme eben nicht.

Lupus est homo homini

2022-02-26T12:00:00+01:00

Während 1000 km von mir entfernt Schusswaffen abgefeuert werden, habe ich sie heute wieder aus meiner DVD Sammlung rausgesucht: Eine der vermutlich bedeutendsten Folgen aus der Serie Star Trek Deep Space 9.

Es war die 8. Folge der 7. Staffel, in der das sonst so sterile Set von Raumschiffen durch die raue Kulisse eines Stellungskrieges ausgewechselt wurde und wo nur Waffengewalt und Zerstörung die Handlung dominierten.

Und in dieser Folge spricht der sonst listige (außerirdische) Geschäftsmann einmal ernsthaft seinem Neffen ins Gewissen, der seinen Dienst in der Verteidigungstruppe antritt:

Menschen sind ein wundervolles zuvorkommendes Volk, so lange sie den Bauch voll haben, … aber wenn du ihnen ihre leiblichen Genüsse entziehst, ihnen z.B. die Nahrung vorenthältst und den Schlaf … dann wird das ihr Leben … in Gefahr bringen und genau die selben freundlichen, intelligenten und überaus zuvorkommenden Menschen, die werden plötzlich so gefährlich, und so gewalttätig, wie der schlimmste blutrünstigste Klingone.

(Zitat aus DS9-S7-E8.)

Your browser does not support the HTML5 VIDEO tag.

Armin Shimerman in der Rolle des “Quark” und der inzwischen leider verstorbene Aron Eisenberg als junger Kadett “Nog” werden mir vor allem in dieser Szene immer in Erinnerung bleiben.

600 Kilometer westlich von Wien endet Österreich beim Bodensee. Die gleiche Strecke nach Osten (leicht nördlich) auf der Landkarte aufgetragen befindet man sich bereits in der Ukraine, einem Land in dem diese Woche russische Truppen einmarschiert sind und mit schwerer Kriegsmaschinerie auf die Hauptstadt Kiew geschossen wird.

Ich kenne weder Russen noch Ukrainer persönlich, verstehe nichts von der dortigen Lage und bilde mir auch nicht ein, ein Urteil über Recht und Unrecht abgeben zu können.

Aber vielleicht gibt es in der großen Stadt Kiew jemanden, der mir irgendwie ähnlich ist. Ein nerdiger Typ, der viel Zeit vor dem Computer verbringt und einfach nur Spaß daran hat, irgendwelche Problemchen mit seinen Maschinen zu lösen. Einer, der auch sein Hobby zum Beruf gemacht hat und einfach nur sein Leben leben will.

Nun schlagen Geschosse in Familienhäusern in seiner Nachbarschaft ein. Seine Mutter und seine Schwester werden mit Nottransporten weggebracht, doch er und sein Vater werden einberufen. Ihnen wird eine Waffe in die Hand gedrückt und sie sollen mit anderen Männern die Heimat verteidigen.

Was wäre, wenn unsere Rollen vertauscht wären?
Er säße in Wien und könnte Codes tippen und ich müsste nun bewaffnet durch die Gassen von Kiew laufen.

Ich kann es mir einfach nicht vorstellen.
Ich kann an Szenen aus Filmen und Serien denken, wo am Ende wieder alles gut wird.
Ich kann Nachrichten lesen und dann einen Kommentar drunter schreiben, wie furchtbar das sei …
aber wirklich vorstellen kann ich es mir nicht.

Ich würde innerlich vermutlich von Angst und Unverständnis zerfressen werden. Ich könnte es einfach nicht fassen, wie es passieren konnte, dass nicht nur mein Eigenheim, sondern auch mein Lebensinhalt gerade zerschossen wird.

Es würde mich nicht interessieren, was Politiker sich gedacht hatten oder eben nicht gedacht hatten, als sie Öl ins Feuer gossen, warum sie unverfroren zündelten oder ignorant zusahen, als andere zündelten.
Denn ich würde einfach nur nach Hause wollen, in mein unbeschadetes Zuhause von gestern, als die Welt noch in Ordnung war.

Ich finde keine Worte, die ich weder meinem fiktiven “Coding-Bruder” in Kiew, noch seiner Familie, noch seiner Nation sagen könnte, die hinreichend trösten können.

Ich werde dem Spendenaufruf folgen, damit ich behaupten kann, ich hätte versucht zu helfen, aber den Menschen wirklich helfen kann nur die Einstellung aller Kampfhandlungen.

Wie? Wie konnte es geschehen, dass Nachbarn auf einander schießen?
Es gab keine Hungersnot, keine Naturgewalt.
Es war einfach nur “ein Wille zur Gewalt”.

Die alte lateinische Zeile

lupus est homo homini.

beschreibt, wie wir Menschen bis heute sind: Nämlich unfähig das niedere Tier (den Wolf) in uns zu überwinden.
Und ausbaden dürfen das stets jene, die sich am wenigsten dagegen wehren können.

Den Opfern der Kriegshandlungen in der Ukraine (auf beiden Seiten) gilt mein Mitgefühl, denn hier kämpfen Menschen ohne einen ideologischen Grund gegen einander. Nachbarn wurde aufgetragen auf einander zu schießen.

Die DS9 Folge S07E08 endet für Star Trek ungewöhnlich düster. Denn … die Opfer eines Krieges können nicht ungeschehen gemacht werden. Man kann nur noch den Toten gedenken und stets einmahnen, diese Opfer nie zu vergessen, wie auch das Serienzitat aufzeigt:

Wir dürfen das niemals vergessen.

Your browser does not support the HTML5 VIDEO tag.

daemonize()

2022-02-20T12:00:00+01:00

Tools wie daemonize oder start-stop-daemon starten laut ManPage einen Prozess “als Daemon” unter BSD oder Linux.
Doch die Einrichtung und der automatische Start von Diensten unter unixoiden Systemen ist am Ende dann doch noch etwas ganz anderes.

Und wieder einmal muss ich mich zuerst mal mit mir selbst einigen, wie man das daemon Konzept in C/C++ Programmen integrieren kann.

Während unter Windows ein Hintergrunddienst vom Betriebssystem standardisiert verwaltet wird, lag die Verwaltung in Unix, BSD und Linux stets in den Händen der Hersteller.

Eine Zeit lang waren SysV Init-Scripts der einzige de-facto Standard, bis Linux mit systemd wieder auszuscheren versuchte.
Auf die Linux-Standard-Base (LSB), die ursprünglich versuchte auch die Init-Scripts zu vereinheitlichen, kann man sich leider auch nicht verlassen, da einige Distributionen diesen Standard gar nicht und andere ihn nur halbherzig implementieren.

Problem 1: Wer fork()t?

Ein Prozess wird zum daemon wenn er seine Abhängigkeiten zum Aufrufer unterbricht. Das wird durch zwei fork() Aufrufe erreicht, wo im ersten Kind per setsid() eine neue Session (und Prozessgruppe) erstellt wird und optional auf einen anderen Useraccount gewechselt wird (setuid()).

Das zweite Kind ist dann der eigentliche daemon und wenn sein Eltern- und Großelternprozess danach beendet werden, verliert der Daemon seine Bindung an die Prozessgruppe des ursprünglichen Aufrufers. Der neue parent wird init (bzw. ID 1) und der daemon ist dann nicht mehr von Gruppen-kill Aufrufen seiner Macher bedroht.

Weil man hier aber auch viele Fehler machen kann, hat es sich eingebürgert, dass ein Prozess diese fork()s nicht mehr selbst durchführt. Anstatt dessen ruft das init Script start-stop-daemon auf, der sich selbst entsprechend fork()t und am Ende den daemon Prozess einfach per exec() startet.

Im daemon muss man daher gar nichts mehr tun, nur noch den eigentlich Job.

… doch diese Methode wird nicht von allen Diensten benutzt, und vor allem ist start-stop-daemon oder auch daemonize kein POSIX Standard, womit das auf jeder Distribution anders ablaufen kann.

Problem 2: Wer verwaltet das PID-File?

Weil Dämonen eigenständig laufen und von außen wie gewöhnliche Prozesse aussehen, greifen init Scripts auf spezielle Dateien zu, die die PID des gerade laufenden daemon enthalten sollen, sogenannte PID-Files.

Ist kein PID-File da, läuft kein daemon
Ist ein PID-File da, aber die enthaltene PID verweist auf keinen laufenden Prozess, läuft kein daemon
Ist ein PID-File da und verweist auf einen laufenden Prozess, so ist das die PID des daemon und über diese kann man ihm Signale schicken.

Das init Script liest das PID-File um seine start und stop Parameter entsprechend umsetzen zu können, doch erzeugt wird es an unterschiedlichen Orten.
start-stop-daemon kann es anlegen, oder das init Script legt es selbst an, oder der daemon tut es intern, sobald er läuft.

Auch hier fehlt ein eindeutiger Standard.

Was funktioniert wo?

systemd wollte init Scripts abschaffen, und (ähnlich wie Windows) eine Daemon-Registry aufbauen, wo systemd per Konfiguration alle Start- und PID- Formen korrekt umsetzen kann.

Doch einerseits nutzen viele Dienste weiter nur klassische init Scripts, womit ganz üble Hacks notwendig werden um init Scripts mit systemd zu synchronisieren.
Und andererseits steht systemd in einigen Umgebungen wie z.B. Docker gar nicht zur Verfügung. Da bleiben nur init Scripts ohne systemd Anbindung als einzige Alternative übrig.

Und BSD fügt je nach Geschmacksrichtung auch noch seine eigenen Features und Verzeichniskonvention hinzu.

Kurz: Es ist ein absolutes Versionschaos, was wo funktionieren kann und bedarf somit immer einer individuellen Anpassung.

GATE Implementierung

Vor 10 Jahren habe ich den Ansatz gewählt, dass “meine” Dämonen fremdgesteuert sind, und das init Script zahlreiche Varianten durchprobiert um einen Dienst auf mehr als einer Plattform hochziehen zu können.
Das hat zwar grundsätzlich funktioniert, doch das Script war unglaublich komplex und war damit auch fehleranfällig und nur sehr schwer zu debuggen.

In meiner aktuellen Implementierung, gehe ich einen anderen Weg:
Jeder GATE-daemon verwaltet sich vollständig selbst, das heißt, er fork()t selbst, legt sein PID-File selbstständig an und gibt init Script konforme Exit-Codes zurück.

Damit braucht das init Script nur auf das Binary und die PID-Datei konfiguriert zu sein, um bei start den Daemon Prozess auszuführen und bei stop ein SIGTERM an die PID aus der PID-Datei zu senden.

Der Code zur Erkennung der Systemumgebung wandert dann ins Binary, wo schon der Compiler per #ifdef Unterschiede zwischen Linux und BSD auflösen kann.

Am Ende soll sich jeder Daemon sein init Script selbst generieren können, damit man (so wie auch unter Windows) einfach per mydaemon --register oder mydaemon --unregister den eigenen Dienst korrekt im System integrieren kann.

Fazit

Zu viel Freiheit ist eine Einschränkung.

Oft sind WinAPI Codes komplexer als POSIX Implementierung, doch beim Thema Systemdienst dreht sich das um, wenn man plattformunabhängig bleiben möchte.

Denn während ein paar Codezeilen von NT4 bis Server 2022 stabil einen Dienst verwalten können, erfordern Patches für alle unterschiedlichen Linux- und BSD-Varianten unzählige Implementierung und jede Menge Zusatzaufwand.

Linux erschlägt das Problem mit zahlreicher billiger Arbeitszeit von Studenten, die jährlich das Script-Rad in jeder Distro neu erfinden … aber wäre es nicht sinnvoller diese Zeit in relevantere Features zu stecken?

Als unabhängiger Entwickler wird man so gezwungen seine Software nur auf bestimmten Distros anzubieten, weil man eben nicht alles abdecken kann. Und der Verweis, alles zu Open-Source zu machen schreckt nachhaltig viele Firmen ab.

Gäbe es einen ähnlichen Standard wie das Root-Filesystem für Dienste unter allen POSIX Varianten, wäre die Welt wieder ein ordentliches Stück schöner. (Denn /etc oder /usr erleichtern das Portieren zwischen Linux und BSD enorm. Wäre doch schlimm, würden die auch immer anders heißen.)

However… ich hab trotzdem Spaß an Code- Archäologie.

HTTP Server

2022-02-19T12:00:00+01:00

Mit der Entwicklung eines eigenen kleinen HTTP Servers bin ich damals vor 9 Jahren in die Embedded-Welt eingestiegen.

Auch im GATE Projekt befindet sich eine adäquate neue rein auf C aufbauende Implementierung, die mir die Verwaltung von MicroServices erleichtern soll.

Challenge: HTTP

HTTP hat deshalb einen solchen Reiz, weil man nur einen Webbrowser braucht, um auf ein System zugreifen zu können.
Nicht grundlos haben heute auch fast alle Mikrocontroller bereits eine HTTP-Server Bibliothek in ihrem Basisumfang.

Nachdem es bereits zahlreiche Implementierung gibt, stellt sich die Frage

Warum tue ich mir eine Bit-für-Bit Eigenimplementierung überhaupt an?

Und die Antwort ist wie so oft:
Keine der mir bekannten Bibliotheken ist aus meiner Sicht “unabhängig” genug, als dass ich sie mit den Zielen des GATE-Projektes problemlos vereinen könnte. Und das fängt leider bei deren GPL-Variant an.

Und während Windows und Linux halbwegs gut abgedeckt sind, machen der HTTPS Zwang eine Portierung auf Windows CE, BSD oder ganz aktuell EFI unmöglich. Und Mikrocontroller Lösungen sind wieder auf deren Hardware zugeschnitten, womit reguläre Desktops und Server nicht bedient werden können.

Umsetzung

Bevor ich überhaupt an Dinge wie HTTP/2 denke, bleibe ich mal bei HTTP/1.0 und HTTP/1.1.

Da ist die Sache theoretisch noch einfach:

Man öffnet einen Server-Socket
Nimmt Verbindungen an und scannt nach \r\n\r\n um das Ende eines HTTP Headers festzustellen.
Dann parst man die Headerzeilen und entscheidet, ob weiterer Content gelesen werden muss.
Ist der HTTP Request vollständig entgegengenommen, darf ein beliebiger Callback die Daten verarbeiten.
Das Ergebnis wird in einen HTTP-Response Header gepresst und danach darf ein entsprechender Response Stream an den Client zurückgeschickt werden.

Der Teufel steckt aber wie so oft im Detail:

Content-Type: Keep-Alive
- In einer Socket Session können mehrere HTTP Requests aneinander gereiht sein. Man braucht also eine gute State-Engine, die bei Keep-Alive nach der Abwicklung des ersten Requests einen weiteren durchführt, ohne dass Daten versehentlich zwischen beiden geteilt werden.
- HTTP Pipelining macht zusätzlich erforderlich, dass gelesene Daten nicht sofort bearbeitet werden, sondern bis zur Bearbeitung des nachfolgenden Requests zwischengespeichert bleiben.
Content-Encoding
- An allen Stellen darf Kompression eingesetzt und der Client darf darüber entscheiden, ob der Server ihm auch so antworten dürfen soll.
Transfer-Encoding
- chunked: So können sowohl Requests als auch Responses in Stückchen zerteilt werden. Das ist super für’s “Streaming”, aber mühsam zu implementieren.
- deflate, gzip: Tritt in Konkurrenz zu Content-Encoding
Accept-Ranges
- Abgebrochene Downloads fortsetzen zu können, ist ein Feature aus den 90ern, dass man auch nicht einfach weglassen sollte.
HTTP CONNECT und Upgrade: websocket
- Beide sollte man entweder “korrekt” abwehren oder “standardkonform” umsetzen.
… und vieles mehr.

Fazit

Man kommt also sehr schnell in jede Menge von Fallkombinationen, deren Validität schwieriger festzustellen ist und die auch komplex bei der Umsetzung sind.

However … wenn ich bedenke, wie mühsam es bei anderen Projekten war, genau diese unterschiedlichen Fälle mit Fremdbibliotheken richtig abzudecken, dann keimt um so mehr Motivation auf, es trotzdem selbst zu implementieren.

Denn gerade diverse Encoding-Kombinationen lassen sich auch von großen “professionellen” Bibliotheken nicht immer korrekt abbilden und da wird es dann nochmal schwieriger, in den Fremdcode einzugreifen, oder aber man muss auf einige Features verzichten.

HTTP ist jedenfalls ein Muss, und darf daher nicht fehlen.

IP Konfiguration

2022-02-13T12:00:00+01:00

Während alle Betriebssysteme vergleichbare APIs für das Dateisystem haben, ist die zweitwichtigste (manchmal auch wichtigste) Konfiguration vollkommen individuell in die Software eingeflossen: Die TCP/IP Konfiguration.

Dass Windows und Linux unterschiedliche Meinungen haben, war zu erwarten. Doch dass alle Unix Derivate unterschiedliche Wege gehen, überrascht mich immer wieder.

Windows

Während in Windows fast alles durch APIs erreichbar ist, fehlten auch hier einige Funktionen um IP Adressen im System zu setzen oder um Dienste wie DHCP und DNS ein und auszuschalten.

Lustigerweise hat sich hier ein Unix Ansatz eingeschlichen, indem die Netshell (netsh) als Kommandozeilen Werkzeug das Konfigurieren von IP Einstellungen “standardisiert” hat.

netsh interface ipv4 set address "Local Area Connection" static 192.168.0.8 255.255.255.0 192.168.0.1
und netsh interface ipv4 set dnsserver "Local Area Connection" static 192.168.0.1
können sowohl von Scripts als auch von Programmen benutzt werden um das Netzwerk zu verwalten.

Seit Windows 2000 ist mit WMI auch eine COM-API vorhanden. Die VB-Script Beispiele der MSDN lassen sich mit einigen Anpassungen in native Programme integrieren, oder per System.Management auch von dotNET Programmen anwenden.

Unix-Derivate

BSD und Linux Varianten nutzen häufig Konfigurationsdateien, um IP Adressen beim Start statisch zu setzen, oder eben DHCP einzuschalten. Doch leider ist diese Information bei jeder Distributionsfamilie wo anders abgelegt.

Und dann kommen auch noch unterschiedliche Zusatzdienste wie networkmanager hinzu, die - wenn aktiviert - diese Konfigurationsdateien entweder überschreiben oder unwirksam machen.

DNS

Relativ einig sind sich alle, wo ein statisch konfigurierter DNS-Server festgelegt wird, nämlich in /etc/resolv.conf. Dort drinnen stehen wenige Zeilen nach dem Schema:

1nameserver 192.168.0.254
2nameserver 8.8.8.8

Linux-klassisch

Viele “einfache” Linux Varianten nutzen die Datei /etc/network/interfaces, die nach folgendem Muster aufgebaut ist:

1auto lo
2iface lo inet loopback
3
4auto eth0
5iface eth0 inet static
6    address 192.168.0.13
7    netmask 255.255.255.0
8    gateway 192.168.0.254

um statische IPs zu vergeben. Die Namen der diversen Netzwerkadapter (hier eth0) erhält man entweder per klassischem ifconfig Aufruf, oder per ip addr.

Will man den DHCP Client die IP Adressen setzen lassen, hilft:

1iface eth0 inet dhcp

Weitere Beispiele unter linuxhint.com/debian_etc_network_interfaces

Linux Network Manager

Wer eine Network Manager Installation von der Konsole aus verwalten will, findet unter devconnected.com/network-manager-on-linux-with-examples/ eine detaillierte Beschreibung.

Grundsätzlich kann man aber mit Tools wie nmcli viele Einstellungen setzen und anwenden lassen.

z.B.:

1nmcli con mod eth0 ipv4.address 192.168.0.13/24
2nmcli con mod eth0 ipv4.gateway 192.168.0.254
3nmcli con mod eth0 ipv4.dns 8.8.8.8
4nmcli con mod eth0 ipv4.method manual
5nmcli con up eth0

FreeBSD

Die Datei /etc/rc.conf enthält für jeden Netzwerkadapter eine ifconfig_[NICNAME] Zeile neben einigen anderen Dienstkonfigurationen. Man kann also mit

1ifconfig_ethX="DHCP"
2ifconfig_ethY="inet 192.168.0.13 netmask 255.255.255.0"
3defaultrooter="192.168.0.254"

vieles abdecken. Am Ende ruft man dann noch die Kommandos

1/etc/rc.d/netif restart
2/etc/rc.d/routing restart

auf um die Konfiguration sofort anwenden zu lassen.

Weitere Infos unter: docs.freebsd.org/en/books/handbook/config/#config-network-setup

OpenBSD

OpenBSD speichert seine Daten in separate Dateien als /etc/hostname.[nicname]

Da drinnen findet man Zeilen wie:

1inet 192.168.0.1 255.255.255.0
2inet6 autoconf

für statische IPs oder

1inet autoconf

für DHCP. Der Router wird in eine eigene Gateway Datei namens /etc/mygate geschrieben und beinhaltet dann nur die Zeile:

1192.168.0.254

Weitere Infos findet man unter www.openbsd.org/faq/faq6.html

NetBSD

NetBSD speichert die IP-Addresse in /etc/ifconfig.[nicname].

Ein Beispieldatei wie /etc/ifconfig.hvn0 sieht etwa so aus:

1up
2192.168.0.1 netmask 0xffffff00

Zusätzlich sollte die neue statische IP in /etc/hosts eingetragen sein.

Für die IPv4 Route, wird die Gateway IP entweder in /etc/mygate hinterlegt, oder aber man fügt in /etc/rc.conf den Eintrag

1defaultroute="192.168.0.254"

an.

Und zur Aktivierung von DHCP, muss man in /etc/rc.conf die Zeile

1dhcpcd=YES

anfügen.

www.netbsd.org/docs/guide/en/chap-net-practice.html listet auch noch weitere Details auf.

Fazit

Was mich wirklich etwas anpisst, ist die Tatsache, dass alle Varianten extrem ähnlich zu einander sind, also keine gravierenden Feature-Unterschiede erkennbar sind. (OK, ich lasse hier mal WLAN bewusst weg).

Es wirkt so, als hätte man künstlich versucht Unterschiede zu schaffen.

Für mich als Programmierer, der gerne Verwaltungsdienste schreibt, die ein System fernwartbar machen sollen, ist das natürlich eine Katastrophe. Denn hier kann man nur tausende Zeilen von IF-Orgien zusammenwerfen

1if (net_config == variant_1)
2...
3else if (net_config == variant_2)
4...

um seinen Code halbwegs auf alle Plattformen zu bringen.

Andere Scripting Frameworks wie Perl, Python usw. haben das tatsächlich auch gemacht. Und um so mehr ärgert es mich, dass dieses “Wissen” nicht auch nativen Programmen zur Verfügung gestellt wird.

Von daher: Daumen runter für diese Config-Chaos-Community.

Straßenkarten und Satellitenbilder

2022-02-12T12:00:00+01:00

Als ich damals meinen PKW Führerschein machte, war die Landkarte aus Papier immer noch ein übliches Inventar in jedem Fahrzeug.
Doch spätestens 2010 hatte jeder entweder ein separates Navigationsgerät oder ein Smartphone mit einer entsprechenden App, um sich auf den Straßen orientieren zu können.

Viel interessanter ist aber, wie man solche Karten-Apps selbst schreiben kann.

Während einige kostenpflichtigen Dienste ihr Kartenmaterial verstecken, haben einige große Dienste ihre Weltbilder per HTTP Web Request (auch REST Service genannt) der Öffentlichkeit zur Verfügung gestellt.

Schon vor einigen Jahren habe ich mit

ein paar Experimente gemacht.

Grundsätzlich ist die Sache recht einfach:

Registrierung und Einrichtung eines API-Keys.
Absetzen eines Webrequests mit Längen- und Breitengrad
Empfang eines Bildes und/oder zusätzlicher Metadaten

Der API-Key identifiziert den zugreifenden Dienst (also die App) und dient auch zur Kontrolle der Anfragen. Ist das Angebot kostenlos, hat der API-Key eine bestimmte Anzahl an freien Zugriffen, z.B.: 1000 pro Tag, 100000 pro Jahr. Zusätzliche Zugriffe kann man allerdings per Zahlung nachkaufen.
So wird verhindert, dass man mit einem Key die gesamte Weltkarte herunterladen kann.

(Kein) Google Maps

Die besten Satellitenbilder hatte immer schon Google. Sie sind teils so hochauflösend, dass man Bodenmarkierungen auf Straßen erkennen kann.

Vor 6 Jahren schaltete ich daher mal einen API-Key frei um eine lokale Karte in eine globale von Google einzubetten.

Heute hat Google allerdings die Dienste gesperrt, wenn man keine Bezahlungsverknüpfung in seinem Konto eingerichtet hat … und eher sterbe ich, als dass ich Google Bank- Kreditkarten- oder Paypal-Daten zukommen lasse. Von daher ist Google von meiner Liste der zu implementierenden Kartenprovidern gestrichen.

Damals konnte man aber mit dem API-Key einfach die URL
http://maps.googleapis.com/maps/api/staticmap?center=LAT,LONG&zoom=19&scale=1&size=WIDTHxHEIGHT&maptype=roadmap&key=KEYE&format=png&visual_refresh=true mit entsprechenden Breitengrad- (LAT) und Längengrad- (LONG) Angaben zusammen mit dem API-Key (KEY) und Pixelbreite und -höhe (WIDTH, HEIGHT) aufrufen und erhielt eine Grafik als Download.

Ein bisschen komplex war die Sache mit der Auflösung. Google nutze einen zoom Faktor um die nähere oder entferntere Blickwinkel zum Zentrum (LAT,LONG) darzustellen.

Das Geheimnis war: Google hat alle Karten als 256 x 256 Pixel Teilgrafiken vorberechnet und auf dem niedrigsten Zoom-Faktor 0 findet man auf 256 Pixeln die gesamte Weltkarte wieder. Jeder weitere Zoomfaktor verdoppelt die Auflösung und das geht runter bis 22. Wenn man jetzt weiß, dass der Erdumfang am Äquator 40075160 Meter lang ist, erhält man 40075016 / 256 == 156543.594 Meter pro Pixel am Äquator und mit jedem weiteren Zoomfaktor halbiert sich diese Einheit.
Und da die Weltkarte eine Mercator-Projektion ist, ergeben sich die metrischen Maße um ein Zielpunkt aus der Formel:

metersPerPixel = cos(latitude) * 40075016 / (256 * 2 ^ zoom)

Beim höchstmöglichen Faktor 22 kommt man schon auf eine theoretische Auflösung von 4 cm pro Pixel. Die Kartenbilder sind zwar je nach Umgebung unterschiedlich scharf, aber im städtischen Gebiet ist das echt krass genau.

Bing Maps

Microsoft’s Bing Maps (früher als “Virtual Earth” bekannt) ist nun aber zwangsläufig der Gewinner, da ich nach wie vor ohne Bankdaten mit einem kostenlosen Account Daten davon beziehen kann.

Unter www.bingmapsportal.com kann man sich im Bing Maps Dev Center Account freischalten und unter My Account - My Keys API Keys anlegen. Der Key kombiniert folgende Datenfelder:

Application name
Applikation URL
Key type (z.B.: Basic)
Application Type (z.B.: Mobile, Website, Dev, Win-App)

Und schon kann man folgende Requests absetzen, indem man den generierten API-Key in jedem HTTP-Request als key Argument mitschickt.

http://dev.virtualearth.net/REST/V1/Imagery/Map/aerial?mapArea=48.2,16.4,48.25,16.45&mapSize=800,600&key=AKPIKEY&mapMetadata=1
liefert JSON formatierte Daten zur gewählten Lage
http://dev.virtualearth.net/REST/V1/Imagery/Map/aerial?mapArea=48.2,16.4,48.25,16.45&mapSize=800,600&key=APIKEY&format=png
gibt ein PNG Bild als Download zurück.

Bing arbeitet mit Ausschnitten, daher gibt man 4 Parameter als FROM-LATITUDE, FROM-LONGITUDE, TO-LATITUDE, TO-LONGITUDE an. Der JSON-Response gibt “angepasste” Koordinaten zurück, die zur mapSize (also Breite, Höhe) passen und mit eben diesen Daten, kann der PNG Request abgesetzt werden, womit man präzise weiß, was im Bildausschnitt genau gezeigt wird.

Die JSON-Rückgabe sieht in etwas so aus und kann leicht geparset werden:

 1{
 2  "authenticationResultCode":"ValidCredentials",
 3  "brandLogoUri":"http:\/\/dev.virtualearth.net\/Branding\/logo_powered_by.png",
 4  "copyright":"Copyright © 2022 Microsoft and its suppliers.",
 5  "resourceSets":
 6  [
 7    {
 8      "estimatedTotal":1,
 9      "resources":
10      [
11        {
12          "__type":"StaticMapMetadata:http:\/\/schemas.microsoft.com\/search\/local\/ws\/rest\/v1",
13          "bbox":
14          [
15            48.1908100765507,16.3564109802246,
16            48.2593128380802,16.4935684204101
17          ],
18          "imageHeight":"600",
19          "imageWidth":"800",
20          "mapCenter":
21          {
22            "coordinates":["48.2250061054994","16.425"]
23          },
24          "pushpins":[],
25          "zoom":"13"
26        }
27      ]
28    }
29  ],
30  "statusCode":200,
31  "statusDescription":"OK",
32  "traceId":"..."
33}

Fazit

Mit Bing-Maps (oder Google), kann man relativ einfach Landkarten-Grafiken per HTTP anfordern und in der eigenen Anwendung nutzen.
Statt hinterlegten Satellitenbildern, kann man die REST APIs auch auffordern nur Straßenkarten (mit und ohne Häuseradressen) zurückzuliefern.
Und es gibt noch einige weitere Features, wie Routenplanung oder Distanzberechnung, die man ebenso per HTTP-Request anfordern kann.

Und mit ein bisschen Mathe zur Mercator-Projektion, kann man jedem Pixel unter dem Mauszeiger auch seine Geo-Koordinaten zuordnen.

OpenStreetMap steht auf meiner TODO-Liste, doch da dessen API nicht so einfach aussieht und man Koordinaten von Straßen und anderen Objekten zurückbekommt, die man erst selbst auf ein Bild aufmalen muss, wird das wohl noch etwas dauern.

Die freie Nutzung von Geo-Positionierung und Karten ist aber auf jeden Fall ein wichtiges modernes Feature.

Die Anbieter integrieren es gerne mit jeder Menge Javascript Codes in Webseiten und Phone-Apps, aber verschweigen regelrecht, dass man auch ohne Scripts und Werbe-Einblendungen an die Rohdaten gelangen kann.

Man braucht also kein Android- oder Browser-Framework, um Karten in native Anwendungen einbetten zu können … doch leider werden diese Dienste auf diese Weise viel zu selten genutzt.

Webhosting 1.0

2022-02-06T12:00:00+01:00

Als ich etwa im Jahr 2001 “das Internet” entdecken durfte, wollte ich auch meine eigene Webseite haben. Aber bezahlen … nein … für so etwas reichte das Taschengeld nicht.

Also begann die Suche nach gratis Webhostern.

Provider Webspace

Viele Internetzugänge waren Anfang der 2000er “automatisch” mit Webspace ausgestattet, und zwar mit sagenhaften Dimensionen von 5 - 10 MB Speicherplatz insgesamt. http://www.your-hoster.tld/members/username war damals üblich für private URLs, und deshalb hatten viele Jung-Web-Enthusiasten eine kostenlose Umleitung einer .tk oder .vu Subdomains zum eigenen Space eingerichtet.

Hochgeladen wurden die rein statischen Inhalte über FTP, und manchmal gab es sogar eine “dynamische” Webseite zum Uploaden einzelner Dateien per Browser-Upload.

PHP oder irgend ein anderer Script Support war bei diesen Diensten nicht zu finden, doch dafür hatten viele ein unerträgliches Flash-Element eingebunden, mit dem man “dynamische Inhalte” client-seitig simulieren konnte.

Werbung 1.0

Mit dem Suchbegriff Free Webhoster fanden das damals noch sehr junge Google oder Klassiker wie Yahoo!, Lycos und AltaVisa oder das deutsche fireball.de einige Anbieter, die kostenlos HTML Files bereitstellen ließen, wenn dafür Werbung auf diesen Seiten eingeblendet wurde.

Der Trick war denkbar einfach:
Jeder .htm oder .html Datei fügte der Webserver ein paar Zeilen hinten an, wodurch per Javascript ein Inlineframe oder etwas Ähnliches eingefügt wurde, wo dann Texte oder Grafiken aufblinken sollten. Parallel dazu wurden Popups geöffnet um darüber zu informieren, dass man als 1000ster Besucher ein Auto gewonnen hätte.

Doch die Webtüftler von damals hatten schnell heraus gefunden, dass sie ihr eigenes HTML Dokument einfach nur entsprechend “enden” lassen mussten, um die lästigen Einblendungen “weg-scripten” zu können.

Codes wie

1<body>
2  ... 
3  my content ends
4</body>
5<div style="display:none">

oder

1<body>
2  ... 
3  my content ends
4</body>
5<!--
6

bewirkten, dass nachfolgende Elemente entweder unsichtbar wurden (z.B. Werbebilder am Ende der Seite), oder dass nachfolgender <script> Code nicht mehr ausgeführt wurde.

GeoCities

Angefangen hatte ich mit GeoCities, wo man genau einen solchen Werbe-Script-Webspace kostenlos zugesprochen bekam.

Nicht, dass ich damals wirklich relevante Inhalte hätte vorzeigen können. Man wollte einfach eine Webseite herzeigen können, ohne wirklich etwas darauf zu haben, was herzeigbar hätte sein können.

Tatsächlich habe ich dort dann auch 2 oder 3 Texte zum INT 13h geschrieben um mit meinen rudimentären DOS Assembler Kenntnissen zu prahlen. Zum Glück hat sich diese Peinlichkeit dann beim Untergang von GeoCities selbst gelöscht.

Die Werbeeinblendung fand ich aber damals schon sehr unseriös und so suchte ich schnell nach einer Alternative:

Piranho.de

Piranho.de war ein deutscher Webhoster, der von zwei damals jungen Enthusiasten aufgebaut wurde und stark auf eine Forum Community hinarbeitete.
Man erhielt (was auch sehr selten war) kostenlos eine Subdomain username.piranho.de wie auch username.piranho.com und hatte formal unbegrenzt Speicherplatz. Doch die einzelnen Dateien durften nicht größer als 100 KB sein, was üppige Fotos einschränkte, aber in der damaligen Zeit “akzeptabel” war.

Eine Grundidee war, dass jeder User seine Dateien kostenlos über ein Web-Upload-Formular hochladen und administrieren konnte, doch wer mehr wollte, musste sich im dortigen Webforum betätigen und fleißig Beiträge schreiben.
Denn - ich glaube - monatlich wurden unter den besten Teilnehmern dann FTP-Accounts verlost, womit diese größere Dateiuploads durchführen konnten.

Tatsächlich endete dann meine Motivation eine eigene Webseite zu haben recht bald, doch das Piranho Forum hat mich dann noch recht lange bei der Stange gehalten, weil es dort auch ein C++, Delphi und Visual-Basic Board gab, wo stets Fragen zu diesen Sprachen kamen, und ich selbst auch gelegentlich mal etwas gepostet hatte.

Das ging dann ein paar Jahre so weiter, bis ich dann “aus beruflichen” Gründen immer weniger Zeit fand, am Abend noch Beiträge zu lesen.
Doch alle paar Monate war dann doch wieder Lust und Laune am Wochenende da, kurz ins Forum zu blicken.

Facebook und Co haben dann ab 2007 erfolgreich alle Foren und deren Communities zerstört und damit war Piranho faktisch auch tot. Heute findet man nur noch ein trauriges Logo auf der Domain und niemand vermutet, dass zwischen 2001 und 2005 auf dieser Seite keine 10 Minuten vergingen, in denen nicht ein neuer Beitrag eröffnet wurde.
Es ist eigentlich ein Drama, dass all diese Interaktion und auch viele dort verfassten Workshops offenbar verloren gegangen sind.
Nur das Internet Archive zeigt ein paar Bilder aus dieser Zeit:

Snapshot 2001
Snapshot 2003
Snapshot 2004
Snapshot 2005
Snapshot 2007

Die lange Ruhe

Ein Freund hatte damals (um 2004) die Idee bei einem Webhoster eine Domain zu kaufen und diese als Reseller weiterzuverkaufen.
Mit dem Gedanken (und vor allem wegen des dummen Namens der Domain) musste er damit natürlich scheitern.
Denn wer kauft schon eine kleinere Wohnung im Internet “in Untermiete”, wenn er an jeder Ecke eine halbe Villa fast kostenlos im Eigentum bekommt.

Doch mit mir hatte er für viele Jahre einen treuen Kunden, der den dortigen Webspace bis 2010 glaube ich unbenutzt hat liegen lassen.

Zwischendurch konnte ich aber immer wieder mal bei Bekannten und Verwandten die eine oder andere Webaufgabe übernehmen und dort ein paar HTML, Javascript oder PHP Zeilen “im Netz” verbauen.

Erst Ende 2018 war die Motivation wieder groß genug, selbst ein Webprojekt starten zu wollen, was bekanntlich auch zu diesem Blog geworden ist.

Fazit

Web 1.0 war eine gute Sache und eines muss ich ganz klar sagen:
Mit meinen statisch generierten HTML Seiten bin ich bis heute (zum Glück) gänzlich von Hacker Attacken verschont geblieben, während Projekte von Bekannten alle paar Jahre mit ihren Content-Management Systemen zusammenbrechen.

Zwar war ich nie ein Community-Mensch, aber trotzdem trauere ich dieser Zeit, in der alle Webentwickler sich gegenseitig überbieten wollten und dann in einem Forum darüber prahlten, manchmal nach.

Und eines habe ich dadurch auch lernen müssen:

Das Internet ist EXTREM vergesslich.

Denn fast keine der alten Web 1.0 Seiten von damals ist heute noch zugänglich. Nur web.archive.org hat ein paar Eindrücke von damals konserviert.

MSVC 6/7 type traits

2022-02-05T12:00:00+01:00

Mit dem Visual Studio 2005 wurde der MSVC halbwegs ordentlich nutzbar. Zwar nicht alle, aber zumindest viele C++ Template-Konstruktionen wurden mit dieser Version endlich standard-konform umgesetzt und so konnten boost und andere Bibliotheken langsam in Richtung C++11 marschieren.

Doch … was war vorher?
Tatsächlich dokumentieren ältere boost Ausgaben einige faszinierende Workarounds um Template-Features wie Type-Traits auch mit älteren nicht-standard-konformen Compilern umzusetzen.

Keine Partial template specialization

Template hatten in MSVC 6 und 7 zahlreiche Macken. Eine einfaches generisches Template funktionierte, doch sobald man Spezialisierungen einsetze, wurde es kompliziert.

Gar nicht implementiert waren Teilspezialisierungen, um Typen-Attribute filtern zu können.
Ein sehr bekanntes Beispiel wäre die Pointer-Erkennung:

 1template<class T> class is_pointer
 2{
 3  static bool const value = false;
 4};
 5template<class T> class is_pointer<T*>
 6{
 7  static bool const value = true;
 8}
 9int main()
10{
11  assert(false == is_pointer<int>::value);
12  assert(true == is_pointer<int*>::value);
13}

Ein alter MSVC würde hier mit einem Syntaxfehler abbrechen, weil es den Token is_pointer<T*> nicht übersetzen könnte.

Lösung per Funktionsüberladung

Im MSVC können wir aber einen ganz anderen Ansatz nutzen. Wir definieren eine Funktion, die den “gewünschten” Typen oder einen angepassten Wrapper mit dem Typen entgegennimmt und die als Rückgabetyp einen spezifischen Typ nutzt.
Und dann überladen wir die Funktion mit einer zweiten Implementierung, die alles entgegennehmen kann (also eine variadic function) und die einen anderen Rückgabetyp definiert.

Ich übernehme hier gerne die boost Konvention mit einem yes_type und einen no_type, denn die eigentliche Entscheidung, wie ein Typ klassifiziert wird, erfolgt eben über diesen Rückgabetyp.
Wenn wir nämlich einen solchen überladenen Funktionsaufruf “andeuten”, ermittelt der Compiler, welche der Funktionen am besten passt, womit der Rückgabetyp der Funktion entweder mit yes oder mit no typisiert wird.

1typedef char yes_type_t;
2typedef struct { char n[2]; } no_type_t;

Und aus dieser Info lässt sich dann wieder eine Type-Trait Konstante bilden, wenn man die Rückgabetypen mit sizeof vergleicht.

Das seltsame dabei ist, dass der “angedeutete” Funktionsaufruf nie stattfindet und die Funktionen selbst gar nicht implementiert werden müssen.

Beispiel is_pointer

 1yes_type_t pointer_detector(void const* ptr);
 2no_type_t  pointer_detector(...);
 3
 4template<class T> struct is_pointer_helper
 5{
 6  static T& type_creator();
 7  enum {
 8    value = (sizeof(yes_type_t) == 
 9      sizeof(pointer_detector(type_creator()))      
10  };
11}
12
13template<class T> struct is_pointer
14{
15  enum {
16    value = is_pointer_helper<T>::value
17  }
18};

Jeder Pointer lässt sich implizit in void const* casten, womit jeder Pointer die erste yes Funktion nutzen würde. Alle anderen Typen landen bei der no Funktion.

(Für eine vollständige Implementierung müssten wir jetzt auch noch Fälle wie void volatile* usw. abdecken, aber das Prinzip sollte klar sein).

Beispiel is_reference

Referenzen sind im MSVC leider wieder ein Spezialfall, weil der Compiler (nicht gedeckt durch den Standard) das Nutzen von Funktionsrückgabewerten als nicht-konstante Parameter erlaubt. int foo(int& param) kann also auch mit einem int bar() Aufruf gefüttert werden, obwohl der Rückgabewerte keine Referenz ist. Andere Compiler würden das als Fehler ablehnen.
Folglich können wir die is_pointer Methode nicht einfach auf Referenzen anpassen.

Die Kollegen des boost Teams haben sich dafür etwas Besonderes einfallen lassen:
Sie definieren eine Funktion, die zu einem Typ T eine Funktion als Parameter erwartet, die selbst wieder ein T& zurückgibt.
Aus jeder Nicht-Referenz kann eine Referenz gemacht werden, aber es kann keine Referenz zu einer Referenz geben.

Und damit das mit Function-Overloading funktioniert, müssen wir statt unseres Typen T einen Hilfstypen typed_dummy einführen, der als Parameter fungieren kann:

 1template<class T> struct typed_dummy { };
 2
 3template <class T> 
 4T& (* ref_func_returner(typed_dummy<T>) ) (typed_dummy<T>);
 5char ref_func_returner(...);
 6
 7template <class T> 
 8no_type_t ref_detector(T&(*)(typed_dummy<T>));
 9yes_type_t ref_detector(...);
10
11template<class T> struct is_reference_helper
12{
13  enum { 
14    value = (sizeof(yes_type_t) == 
15      sizeof(ref_detector(ref_func_returner(typed_dummy<T>()))))
16  };
17};
18
19template<class T> struct is_reference
20{
21  enum {
22    value = is_reference_helper<T>::value
23  }
24};

Der ref_detector bekommt also den Rückgabewert der ref_func_returner Funktion als Parameter.
Ist T eine Referenz wird das generische char ref_func_returner(...) aufgerufen und ref_detector(...) antwortet mit yes.
Wenn T keine Referenz ist, lässt sich ein T& daraus machen, was die Templatefunktion ins Spiel bringt, woraus am Ende ein no wird.

Fazit

Was solche Workaround anbelangt ist boost vor allem in den älteren Version (z.B. 1.3x) eine wahre Fundgrube.
Und es gibt noch jede Menge weitere Varianten und Compiler-Hacks, die das Bereitstellen von Features ermöglichen sollen, die eigentlich mit diesen alten Compilern nicht möglich waren.

Leider wird vieles in boost durch eine unendliche Anzahl von Makros umgesetzt, die (zumindest für mich) schwer lesbar sind.
Um so mehr freut man sich dafür dann aber, wenn man einen Workaround mal verstanden hat.

Nachdem immer mehr Forenbeiträge und Blogs aus den Zeiten vor 2010 verschwinden, möchte ich zumindest ein paar dieser Ideen im GATE Projekt verewigen. Ich nutze type-traits zwar ziemlich selten … aber mit diesen Hacks bleibt die Lauffähigkeit auch auf MSVC 6 weiter gegeben.

Bitbucket App-Passwords

2022-01-30T12:00:00+01:00

Am 1. November wurde es angekündigt und am 1. März 2022 ist es so weit:

Bitbucket sperrt User Passwörter für den Zugang zu seinen GIT Repos.

Die Alternative sind SSH Schlüssel oder “App-Passwörter”.

Vorgeschichte

Früher funktionierte Authentifizierung immer nach dem User + Passwort Prinzip. Jedes Protokoll ( HTTP, FTP, SSH, SMTP, POP3, IMAP, …) implementierte sein eigenes Format, in welchem der Benutzer und sein Passwort übertragen werden konnte.
… und leider haben sie es alle absolut falsch gemacht.
Denn das Passwort wurde immer im Klartext übertragen, und obgleich später durch Protokollerweiterungen auch Hashes und andere Späße eingearbeitet wurden, so waren und sind Klartextpasswörter in den meisten Diensten möglich, außer wenn sie explizit abgeschaltet sind.

Es fehlte an einem Standard, wie Passwörter sicher übertragen werden konnten.

SSL und TSL sicherten dann zwar die Datenverbindung zwischen zwei Systemen, doch da im Hintergrund immer noch Klartextpasswörter eingesetzt wurden, ergaben sich immer noch andere Stellen, wo das Passwort abgefangen und gestohlen werden konnte.

Zertifikate wäre ja eine schöne Sache gewesen um dieses Problem zu lösen, doch wie trägt man ein solches immer mit sich herum?

API Token

Anstatt also immer Namen + Passwort zu nutzen, dachte man sich für diverse Automationsprozesse API-Token aus. Der immer noch per Name + Passwort authentifizierte Benutzer kann in einer gesicherten Umgebung zufällige Token generieren lassen, die als Ersatz für Name/Passwort gelten und da man diese Token auch nur mit Teilrechten ausstatten konnte, ergab sich somit eine neue Welt für Web-Anwendungen.

Viele Web-Zugriffe laufen heute über solche Token und nun stellt auch Bitbucket auf dieses Verfahren um.

In Zukunft muss ich also mein “App-Password” == App-API-Token parat haben, wenn ich Sourcecodes hoch- oder herunterladen möchte.
Sollte es mir verloren gehen, kann ich es sperren und ein neues anlegen.

Doch bei meinem ersten Login per TortoiseGIT lief es mir kalt über den Rücken…

Das Browser-Problem

Während früher User+Passwort fixe Felder in Protokollen waren, gehen heute mehr und mehr Dienste dazu über, die Dateneingabe über Webseiten laufen zu lassen, wo am Ende ein finaler Zugriffstoken auf die Daten nach der Anmeldung herausfällt.

Hierfür öffnen die Apps tatsächlich HTML Webformulare, um stets dem “neuesten” Sicherheitsstand (oder dem neuesten UI Logo) nachlaufen zu können.

Genau diese schleichende Browser-isierung von Netzdiensten empfinde ich persönlich als “Bedrohung des Endanwenders”, obwohl es eigentlich der Sicherheit dienen sollte.
Denn an der Stelle findet erneut ein Browser-Krieg statt, der mir das Arbeiten mit nicht-top-aktuellen Systemen übelst erschwert.

Das fängt leider damit an, dass immer mehr Javascript Code aktiv ausgeführt werden muss, damit ein Login auf einer solchen Webseiten überhaupt funktionieren kann.
Folglich kann ich auf einer nicht-grafischen Konsole keinen Login mehr durchführen, weil mir dort ein Browser fehlt, der die Loginmaske adäquat anzeigen könnte.

TortoiseGIT hat das Feature bereits integriert und so öffnet sich beim ersten Login eine Webseite, die das “App-Passwort” erkennt und die nötige Freigabebestimmung abfragt.

Zum Glück gilt das Passwort dann an der Stelle als “safe” und kann auch wieder regulär über native Protokolle benutzt werden.
Somit kann ich auch auf meinem Linux VMs und Raspberry-PIs weiter mit GIT über HTTPS und dem neuen “App-Passwort” arbeiten.

Das App-Passwort ist mit seinen 20 Zeichen kurz genug, um es als Text “mitführen” zu können, womit mir die Einrichtung von SSL-Zertifikaten auf allen Maschinen vorerst erspart bleibt.

Fazit

Ja, es war bisher immer “unsicher”, wenn ich bei jedem git pull mein Passwort habe übertragen lassen und die neuen App-Passwords machen diesen Teil um einiges sicherer.

Dennoch frage ich mich, wie der initiale Login per Webinterface in Zukunft aussehen wird, bzw. wie viele System damit ausgeschlossen werden.

Auf meinem Windows Phone von 2017/2018 laufen inzwischen viele Logins deshalb überhaupt nicht mehr, weil sich das Web zu sehr weiterentwickelt hat, während klassische Logins mit User + Passwort bei Mailaccounts dort auch weiter kein Problem sein werden.

Es bleibt daher nur zu hoffen, dass künftige Umstellungen von Loginprozeduren nicht so gestaltet sind, dass nur noch auf Android oder Apple Smartphones ausführbar sind.
Denn zu meinem großen Bedauern geht der Trend leider in diese Richtung.

PCR und Antigen COVID Tests

2022-01-29T12:00:00+01:00

Das Schicksal (oder meine schlechte Planung) wollte es, dass der Tausch meines Firmen-PCs durchgeführt wurde, womit ich eine Woche lang keinen Home-Office Dienst geleistet habe.
Und wie es bei den aktuellen Infektionszahlen zu erwarten war, traten nun auch positive COVID-19 Fälle in der Firma auf.

Somit hatte ich also einen Grund mich wieder auf das Virus testen zu lassen.

PCR-Tests in Wien

In der Theorie sieht die Prozedur recht einfach aus.

Man registriert sich auf allesgurgelt.at/wien mit
- Vornamen (interessant: kein Nachname an der Stelle)
- Mailadresse
- und einem Passwort.
Oder man loggt sich mit einer zuvor registrierten Mail-Adresse + Passwort ein.
Nun lässt man sich auf der Webseite einen “Abhol-Barcode” generieren.
Mit diesem Barcode bekommt man in einigen Geschäften und Supermärkten dann 8 PCR-Test-Kits kostenlos ausgehändigt.
Wieder zu Hause öffnet man erneut die Webseite, loggt sich ein und startet dort im Menü einen Neuen Test.
Dort wird zuerst die Probennummer eingetippt, die in der Anleitung im Testbox-Heft und auf dem Test-Röhrchen aufgeklebt ist.
Nun müssen persönliche Daten wie
- Vorname, Nachname, Geschlecht
- Geburtsdatum
- Telefonnummer
- Adresse eingegeben werden.
Im Anschluss geht die Webseite die durchzuführenden Schritte durch, also:
- Gurgelflüssigkeit in den Mund nehmen und 1 Minute lang gurgeln
- Flüssigkeit in das Teströhrchen fließen lassen.
Das verschlossene Teströhrchen mit der Flüssigkeit kommt wieder in die Box, während das Anleitungsheftchen bei einem zu Hause bleibt um die Probennummer aufzubewahren.
Die Box mit der Probe kann man dann in vielen Supermärkten an PCR-Test Sammelstellen abgeben.
Will man ein gültiges Test-Zertifikat erhalten, ist das Hochladen eines Ausweises als Foto erforderlich. Man kann diesen Teil aber auch überspringen, wenn man nur am Ergebnis interessiert ist.
Nun heißt es 24 Stunden warten, bis man das Testergebnis per Mail zugestellt bekommt.

Meines Erachtens ist diese Prozedur an vielen Stellen extremst benutzerFEINDLICH gestaltet und sicher mit ein Grund dafür, warum ältere Menschen, oder Menschen ohne regulärem Smartphone (wie ich) von solchen Tests ausgeschlossen sind.

Probleme:

Barcodes auf der Webseiten werden nicht per Mail zugesendet. Man muss also mit dem Smartphone die Webseite öffnen, um den Code herzeigen zu können, oder man muss ihn auf Papier ausdrucken.
Wer aber nur einen Computer ohne Drucker zu Hause hat, bekommt ein Problem.
Die Webseite arbeitet nur auf den neuesten Chromium und Firefox Browsern korrekt. Nicht mal auf dem Legacy-Edge funktionieren die Buttons, und diverse Opera-Varianten haben ebenfalls Probleme.

Wie inkompetent müssen die Entwickler eigentlich sein, dass man ein Formular für Name, Mail und Geburtsdatum nicht mehr absenden kann, wenn der Browser nicht auf Google-Werbung basiert?
Das lief auf Netscape und IE4 alles schon mal besser … vor 25 Jahren!
Die Barcodes werden auch numerisch abgedruckt, nur leider scheitern die Angestellten an den Kassen, diesen manuell einzutippen, schließlich ist der Zahlencode extrem lang. Diese “Backup” gegenüber den Barcodes funktioniert offenbar nicht.
Die “Hilfe” auf der Webseite ist mehr als bescheiden bzw. irreführend. Es gibt keine detaillierte Ablaufbeschreibung, nur ein kurzes Youtube- Video, in dem ein Möchtegern-Model sein Smartphone hochhebt, dann gurgelt das Röhrchen verpackt und das Kit in der Sammelstelle abgibt und dann Youtuber-esque in die Kamera grinst.

Alles in allem zeigt sich, dass wieder absolute Anfänger diese Portale zusammengeklickt haben. Niemand denkt an den allgemeinen Fall, oder wie z.B. meine Mutter zu einem Test kommen soll.
Das ist vermutlich auch mit ein Grund, warum die Skepsis in der Bevölkerung steigt.
Es wäre mit wenigen zusätzlichen Aufwänden möglich gewesen, die Prozedur so auszubauen, dass man einen wesentlich größeren Rahmen abdecken kann.

Antigen-Test im Container

An vielen Plätzen in Wien wurden Test-Container abgestellt, wo die Menschen auch ohne Anmeldung einen Covid-Test machen können. Ich nutzte das Angebot am Reumannplatz bei der Apotheke.

Die dortige Prozedur sieht wie folgt aus:

Man reiht sich in die Schlange ein und wartet bis man dran ist.
Man zeigt seine e-Card vor und wird über diese authentifiziert.
Zusätzlich kann man seine Telefonnummer angeben, um per SMS informiert zu werden.
Ein freundlicher Mitarbeiter fragt nach dem gewünschten Test und führt ihn dann sofort durch.
In meinem Fall wollte ich nur einen Antigen-Schnelltest per Abstrich der Nasenschleimhaut machen.
Man verlässt die Box und wartet auf die Verständigung per SMS.

In meinem Fall dauerte das Warten 30 Minuten, da ein paar Personen vor mir ein positiver Fall entdeckt wurde. Offenbar erfolgt dann eine Desinfektion des Containers und den Wartenden wird mitgeteilt, dass eine 15 minütige Pause notwendig sei. Doch als ich an der Reihe war, war ich in unter zwei Minuten fertig.

Einziges Problem ist wieder der Online-Teil, denn die SMS liefert einen elend langen Link zum Impfergebnis.
Hier hat man als Nicht-Smartphone-User keine andere Wahl, als einen PC zu suchen und den Link Buchstaben für Buchstaben abzutippen.

Fazit

Also … ich bin froh, dass ich dreifach geimpft bin und offenbar keine Covid-Infektion abbekommen habe. Denn wenn ich mich jeden zweiten Tag um einen Test bemühen müsste, um arbeiten gehen zu dürfen, würde ich dezent durchdrehen.

Dabei kann ich wiederum die fleißigen und hilfsbereiten Menschen an der Front für ihren vorbildlichen Einsatz nur loben.
In Erinnerung geblieben ist mir vor allem der junge Mann, der bei mir den Nasenabstrich durchgeführt hatte und dabei sagte:

Sie haben aber eine sehr schöne Nase zum Testen.

Ach … so etwas Nettes hat schon lange keiner mehr zu mir gesagt … oder … war das vielleicht eine Anspielung auf zu große Nasenlöcher?

Wie auch immer, es war eine entspannte und angenehme Atmosphere im Test-Container. Und gleichzeitig sind mir auch die vielen Probleme anderer aufgefallen, vor allem, wenn Menschen nicht deutsch sprechen konnten oder die “falsche” E-Card dabei hatten.

Bei all diesen kleinen Problemchen ist es eine wahre Kunst, trotzdem jedem weiteren Testkandidaten aufgeschlossen und freundlich zu begegnen und dafür kann ich nur meine Anerkennung aussprechen.

Doch … über die Softwareentwicklung kann ich leider nur enttäuscht den Kopf schütteln.
Diese billigen “Copy&Paste” wie auch “Quick-and-Dirty” Lösungen verdrecken nicht nur das Freizeitinternet, sondern haben inzwischen auch die digitalen Amtswege infiziert.
Ich muss mit Bedauern zur Kenntnis nehmen, dass wir in Sachen Digitalisierung nicht fähig sind, ordentliche Prozeduren für allgemeine Fälle aufzusetzen.

Und trotzdem bin ich irgendwie froh, dass wir zumindest die Möglichkeit haben uns weiter kostenlos auf das Virus testen zu lassen.

uEFI: Graphics Output Protocol (GOP)

2022-01-23T12:00:00+01:00

Im klassischen PC BIOS aus den alten 16-Bit Zeiten hatten wir den Interrupt 10h (INT 0x10) um den Grafikmodus zu ändern.

Mit uEFI wurde diese antiquierte 16-Bit Technik modernisiert und somit steht mit dem Graphics Output Protocol (GOP) eine C-API der Firmware bereit, um Pixelgrafiken auf den Monitor zu bekommen.

In den glorreichen Zeiten, in denen “die coolen Jungs” ihr eigenes OS bauen wollten, starteten viele mit dem 512 Bytes großen Bootsektor-Code, wechselten per int 10h in den Grafikmodus und zeichneten ein paar verwegene
“You are hacked” Zeichen auf den Schirm.

Das ganze auf eine Diskette gespielt und ins Laufwerk gelegt, ließ Papa am Abend erblassen, wenn er seine Excel-Zeitlisten in Windows 95 befüllen wollte.

Nun sterben langsam auch die letzten Firmware-Varianten aus, die noch ein BIOS CSM (Compatibility Support Module) enthalten.
Die Zukunft heißt (seit 10 bis 15 Jahren): uEFI.

Das GOP Protokoll

Über die GOP GUID (9042a9de-23dc-4a38-96fb7aded080516a) erlangt man von BootServices->LocateProtocol einen Pointer zum EFI_GRAPHICS_OUTPUT_PROTOCOL Interface.

Dieses stellt die Methoden QueryMode(), SetMode() und Blt() bereit, sowie einen Pointer namens Mode zu den Daten des aktuellen Modus.

Mode->MaxMode gibt die Anzahl der verfügbaren Grafik-Modi zurück und nun kann man per Schleife von 0 bis MaxMode zählen und diesen Parameter als ID an QueryMode() übergeben um Infos zum dahinter liegenden Grafikmodus zu erhalten.
Das wären:

Pixel-Höhe und -Breite des Grafikmodus
Art des Pixelformats
- RGBX: 32 bit Wert mit dem Inhalt rot, grün, blau + unbenutztes Füllbyte
- BGRX: 32 bit Wert mit dem Inhalt blau, grün, rot + unbenutztes Füllbyte
- BitMask: In einer zusätzlichen Struktur wird beschrieben, welche Bits in einem 32-bit Pixel den Farbkanälen rot, grün und blau zugeordnet sind.

Üblicherweise startet die Auflistung beim alten VGA-Standard 640 x 480 und wird dann zunehmend größer.

Mit der Funktion SetMode() kann dann in den Grafikmodus wechseln, wenn man die gewünschte Index-ID einsetzt.

Am interessantesten ist dann die Funktion Blt(), die Pixelpufferinhalte in die Video-Hardware übertragen kann. Das funktioniert sogar in beide Richtungen, man kann also Pixel aus dem eigenen Buffer in die Anzeige transferieren oder die angezeigten Pixel in den eigenen Puffer kopieren lassen.

Man kann also ein Breite * Höhe großes Feld von uint32_t Werten anlegen und dann die Pixel je nach Modus setzen und das gesamte Frame per Blt() anzeigen lassen.

Fazit

Das tolle an UEFI ist, dass die C-API bereits mitgeliefert wird und somit kann man mit wenigen Zeilen einen Bootloader mit grafischen Menü zaubern.
Früher hätte man im BIOS dann per Assembler auf die Hardware-Adressen zugreifen müssen und eben genau dafür schrieben sich viele Entwickler ihre eigene Blt() Funktion.
Schön zu sehen, dass das nun obsolet und die neue Methode standardisiert ist.

Nun existiert im GATE Framework auch eine Framebuffer-Implementierung, die direkt unter EFI ausführbar ist und Grafiken auf den Monitor zeichnen kann.

Und erneut bin ich erstaunt, wie einfach es ist, den PC “ohne Betriebssystem” zu betreiben.

Runnables

2022-01-22T12:00:00+01:00

Hinter der Magie von std::bind stecken eine Vielzahl von Hilfsklassen und C++ Template-Tricks, die jeden beliebigen Funktions- oder Methodenaufruf kapseln und frei mit Parametern kombinieren können.

In der C Welt gibt es (meines Wissen) nichts Vergleichbares in der stdlib.

Für die Ausführung von beliebigen Funktionsaufrufen stellt das GATE Framework daher Runnables bereit.

std::bind verbindet eine Funktion oder eine Methode mit Parametern und gibt einen Functor zurück, der bei dessen Aufruf, die “gebundene” Routine mit den “gebundenen” Parameter aufruft.

 1#include <functional>
 2
 3int foo(int a, int b)
 4{
 5  return a + b;
 6}
 7int bar(int a, int b, int c)
 8{
 9  return a + b + c;
10}
11
12int main()
13{
14  auto f = std::bind(foo, 33, 44);
15  int result1 = f(); // invokes: foo(33, 44);
16
17  auto g = std::bind(bar, 33, 44, std::placeholders::_1);
18  int result2 = g(55); // invokes: bar(33, 44, 55)
19  return 0;
20}

Man kann also einen Funktionsaufruf + Parameter konservieren und in einem anderen Kontext (also später oder in einem anderen Thread) ausführen lassen.

Die gesamte Mächtigkeit von std::bind lässt sich aus meiner Sicht nicht auf C-Routinen übertragen. Vor allem Template-Konstrukte wie std::placeholders gestalten sich zu schwierig, aber wenn man einen ganzen Aufruf “binden” will, gibt es einen Weg:

Man erzeugt einen Speicherblock, der Kopien der originalen Parameter zwischenspeichert
Und man erzeugt eine Dispatcher-Funktion, die die Zielfunktion mit den Parametern aus dem Zwischenspeicher aufruft.

Da wir in C keine Parameter-Type-Deduction haben, müssen Makros für jede unterstützte Anzahl von Parametern geschrieben werden.

 1typedef struct storage_class storage_t;
 2typedef int(* generic_func_t)(int);
 3typedef int(* dispatcher_t)(storage_t const* storage);
 4struct storage_class
 5{
 6  generic_func_t funcptr;
 7  dispatcher_t   disp;
 8  void*          params[1];
 9};
10
11#define DECLARE_DISPATCHER_3(name, type1, type2, type3) \
12typedef int (* name ## _callback)(type1 a1, type2 a2, type3 a3); \
13static int name ## _dispatcher (storage_t const* storage) \
14{ \
15  int ret; \
16  name ## _callback cb = NULL; \
17  type1 * ptr_arg1 = (type1 *)storage->params[0]; \
18  type2 * ptr_arg2 = (type2 *)storage->params[1]; \
19  type3 * ptr_arg3 = (type3 *)storage->params[2]; \
20    memcpy(&cb, &storage->funcptr, sizeof(cb)); \
21  ret = cb(*ptr_arg1, *ptr_arg2, *ptr_arg3); \
22  return ret; \
23}

Um jetzt so ein storage_t zu allokieren und zu befüllen, benutzt man eine variadic function, in der die gewünschten Parameter als Paar von Pointer und Größe übergeben werden. z.B.: storage_t* bind_storage(generic_func_t target, dispatcher_t disp, ...);

Eine int foo(int a, double b, void* c), müsste also mit:
bind_storage(target, disp, &a, sizeof(a), &b, sizeof(b), &c, sizeof(c), NULL); erzeugt werden.

Über das Pointer+Größen Paar kann die Funktion die Anzahl der Parameter ermitteln und dann ein überallokiertes storage_t erzeugen, in dem ganz hinten Kopien der originalen Daten (a, b, c) liegen und davor im params Feld Pointer zu diesen Kopien eingesetzt werden.

Der oben definierte Dispatcher klappert dann bei seinem Aufruf das Array ab und castet die Pointer in die korrekten Zieltypen, um dann die Zielfunktion mit genau den Parametern aufzurufen, die sie braucht.

Problem: Lebenszeit

Das C-Makro und unsere hier vereinfachte bind_storage Funktion kopieren die Datentypen per memcpy() und das funktioniert ausschließlich bei primitiven Datentypen problemlos. Sobald der erste Pointer zum Einsatz kommt, stellt sich die Frage wie lange er gültig ist.

In C++ kann man solche Dispatcher auch per Templates generieren lassen, wo sie Copy-Constructor zum Kopieren und Destructor-Aufrufe für Cleanups automatisch einbauen können, doch in C fehlt dieses Feature.

Im GATE-Framework wird ein solcher storage_t Typ in einem gate_runnable_t Objekt eingebettet, der selbst mit einer Referenzzählung arbeitet. Der Objekt-Inhalt könnte natürlich auch durch individuelle Dispatcher je nach Anwendungsfall separat ausimplementiert werden, doch genau das erweist sich als mühsam und fehleranfällig.

Von daher werden komplexe Typen wohl ausschließlich nur in C++ zum Einsatz kommen und in C verbleibt lediglich ein bestimmtes Nischenumfeld, in dem Runnables gebraucht werden.

Fazit

Während also die Nützlichkeit der Runnables stark an den Sprachstandard gebunden sind, hat aber die Definition einer “Trägerschnittstelle” für mich einen wichtigen Mehrwert:

Komponenten von unterschiedlichen Compilern können “Runnables” nun standardisiert austauschen.
Während ein std::bind Ergebnis eines MSVC unbenutzbar ist in einer MinGW Anwendung ist, kann ein gate_runnable_t problemlos zwischen diesen beiden Welten verschoben werden.

Ein Microservice in einer Sprache A kann somit Aufrufe in seinen eigenen Code durch eine Sprache B ermöglichen.
Denn genau das ist die geheime Superkraft von C:

Es ermöglicht Binärkompatibilität auf allen Ebenen.

Es mag daher mühsam sein, Codes auf C abzubilden, doch am Ende bietet es immer auch Vorteile, wenn man an verteilte Systeme denkt.

Chromebook

2022-01-16T12:00:00+01:00

Ein Päckchen kam verspätet unterm Weihnachtsbaum hervor: Ein Lenovo Chromebook.

Als Entwickler muss man eben auch wissen, was es sonst noch so am Markt gibt. Und die wichtigste Frage für mich war natürlich:

Lässt sich das GATE Framework auch am Chromebook kompilieren?

Nachdem ich Google und Android datenschutztechnisch für den Schlund der Hölle halte, sind Chromebooks für mich das gleiche in dunkelrot.
However, um böse Geister bekämpfen zu können, muss man sie verstehen lernen, und daher ist nun ein solches Modell mein Eigen geworden.

Und ich muss sagen, dass “der kleine Laptop” eigentlich ein ganz nettes Gerät ist und für seine primäre Aufgabe (schnell Mails und Websites durchgehen zu können) sehr gut geeignet ist.

230 Euro kostete mich dieses Einsteigergerät, wobei ich dumm war, und es im Zuge diverser Weihnachtsaktionen vermutlich auch günstiger hätte bekommen können. Jedenfalls starten genau in diesem Preissegment auch andere 10-Zoll Windows Tablets und Kleinlaptops.

Setup

WLAN ist der erste Punkt der eingerichtet werden muss, danach beginnt ein langer Download von Updates
Nun muss man seinen Google Account für den Login angeben oder einen neuen Account anlegen lassen
Google will immer alles synchronisieren … zumindest wenn man diese Einstellungen nicht deaktiviert
Am Ende soll auch noch das Smartphone angebunden werden. Google hat natürlich schon alle Daten gespeichert.
Und das war es auch schon.

Development Umgebung

Ich hätte nicht gedacht, dass Chromebooks ihren eigenen Entwickler-Modus haben. Doch tatsächlich existiert ein solcher und ist in Wahrheit ein Linux Docker Container mit Debian 11, der per X11-Server auch UI-tauglich ist.

Somit lässt sich so gut wie jede Linux-Software installieren und ausführen, bis hin zu den Android SDKs.

Die Einrichtung erfolgt über:

Einstellungen:

Linux Umgebung installieren:

Es öffnet sich die Shell mit einem Debian 11

Und all üblichen Tools von apt bis zum procfs sind vorhanden:

Fazit

Da ich keiner dieser Typen bin, die alle paar Minuten auf Instagram ihre eigenen Fotos anschauen müssen und nach Kommentaren Ausschau halten, werden solche “großen Smartphones mit Tastatur” nie meinen Alltag prägen.

Ich verstehe aber, dass eben genau für diese Zielgruppe ein kleines handliches Gerät wie ein Chromebook genau das richtige sein kann, um diese Bedürfnisse zu erfüllen.

Mit langen Akkulaufzeiten, der kurzen Bootdauer und einer auf das Web angepassten Oberfläche ist mein Chromebook den üblichen 10/11 Zoll Windows Laptops auf Intel Atom Basis in vielen Punkten überlegen.

Würde nicht Google an jeder Stelle Daten absaugen wollen, könnte ich dieser Hardware durchaus positiv gegenüber stehen.

Mandelbrot und Apfelmännchen

2022-01-15T12:00:00+01:00

Für meine Framebuffer Experimente brauchte irgend eine “anschaubare” Grafikausgabe, und dabei fiel mir spontan wieder das Apfelmännchen ein.

Dieses mathematisch errechnete Farbenspiel aus der Mandelbrot-Menge tauchte und taucht in Schulen immer wieder als Programmierbeispiel auf.

Und heute freue ich mich, dass ich diesen Code auch wieder mal sinnvoll “recyclen” kann.

Der Code, den wir in Schulen zu Gesicht bekommen, sieht in etwa so aus:

 1typedef struct 
 2{
 3  unsigned char r;
 4  unsigned char g;
 5  unsigned char b;
 6} rgb_t;
 7
 8void set_pixel(int x, int y, rgb_t const* color);
 9
10void mandelbrot_render()
11{
12  rgb_t color;
13  int width = 640;
14  int height = 480;
15  int ix, iy, count;
16  double x, y, qx, qy, temp;
17  double xmin = -2;
18  double xmax = 1;
19  double ymin = -1;
20  double ymax = 1;
21
22  for(ix = 0; ix < width; ix++)
23  {
24    for(iy = 0; iy < height; iy++)
25    {
26      x = (double)ix / (double)width * (xmax - xmin) + xmin;
27      y = (double)iy / (double)height * (ymax - ymin) + ymin;
28      count = 0; 
29      qx = x; 
30      qy = y;
31      while((count < 256) && ((qx * qx + qy * qy) < 4))
32      {
33        count++;
34        temp = 2.0 * qx * qy + y;
35        qx = qx * qx - qy * qy + x;
36        qy = temp;
37      }
38
39      color.r = 256 - (count * 4) % 256;
40      color.g = 256 - (count * 16) % 256;
41      color.b = count % 256;
42      set_pixel(ix, iy, &color);
43    }
44  }
45}

Gerechnet wird im Fensterbereich (-2, -1)-(+1, +1) und abgebildet auf eine RGB-Farbfläche von 640 x 480 Pixel. Und dabei sieht man das bekannte Haupt-Apfelmännchen.

Wenn man nun in das Bild hineinzoomt (also xmin,ymin vergrößert und xmax,ymax verkleinert), werden an den Farbübergängen interessante Strukturen sichtbar.

Das kann man beliebig tief tun und man wird dabei immer auf ähnliche Strukturen in unterschiedlicher Verzerrung stoßen und vor allem das Apfelmännchen wird man in kleineren Varianten ebenso immer wieder mal antreffen.

Fazit

Für Grafik-Tests könnte man natürlich auch ein Foto laden und anzeigen, aber mir gefällt die Vorstellung, dass alles aus dem Code heraus generiert wird.
Außerdem beeindruckt mich der verblüffend einfache Code, der solch ansehnliche Bilder malen kann.

Früher (um 2000) in der Schule nutzten wir das alte Turbo Pascal unter DOS und setzten 16 Farben auf 640x480 Pixel oder sogar 256 Farben im Mode X (320x200 Pixel) ein.
Heute dient mir das Beispiel als Vergleich, ob meine WinAPI, XLIB, OpenGL und uEFI-GOP Framebuffer-Implementierungen auch immer “gleich” aussehen.
(Manchmal verwechselte ich z.B. RGB und BGR, was die Farbpalette verdrehte.)

Und mit ein paar Zoom- und Move-Faktoren im Code lässt sich mit Mausklicks und Pfeiltasten ganz passabel durch so ein Apfelmännchen durchnavigieren.
Der Code ist nun im Demo-Projekt gateframes verewigt.

Framebuffer

2022-01-09T12:00:00+01:00

Meine OpenGL Experimente und die gategames Demo-App sind zwar toll für Windows, Linux und Android, jedoch kann ich diese Form der Grafikausgabe nie auf EFI, FreeRTOS oder DOS portieren.

Wenn man aber ein abstraktes Modell eines primitiven 2D-Bildspeichers hätte, in dem man Pixel setzen und Grafik-Untermengen hinein und herauskopieren kann, dann hätte man einen Ansatz, den man viel leichter auf alle Formen von “Bildschirmen” portieren kann. (Mikrocontroller inklusive).

Vorgeschichte

Der Aufbau von UIs ist in jedem Betriebssystem grundlegend anders (trotz einiger Ähnlichkeiten). Ich behaupte mal, dass der Erfolg von HTML und der Webbrowser auch damit begründet ist, dass UI-Designer nur einmal die Arbeit haben, ihr Werk abzutippen und die Browser kümmern sich um die korrekte Übersetzung in die Welt des Ziel-OS.

Früher in den DOS Zeiten baute sich jede Anwendung ihr eigenes UI zusammen, und zeichnete mehr oder weniger direkt in den Grafikkartenspeicher.

Man stelle sich also vor, man hätte einen “abstrakten” Grafikspeicher (genannt Framebuffer) in seiner Bibliothek, der unter Windows ein Fenster mit GDI bemalt, unter Linux die XLib befehligt und auf exotischen Plattformen wie früher direkt in den Video-RAM schreibt.

Dann hätte man die Möglichkeit grafische Oberflächen universell portabel zu gestalten.

Windows und GDI

In Windows erzeugt man einfach ein Fenster mit CreateWindowEx und eine “32 Bit pro Pixel” DIB-Section.
Die DIB-Section ist dann unser Framebuffer, wo wir direkt auf die Bilddaten zugreifen können.

 1HWND hwnd_desktop = GetDesktopWindow();
 2HDC hdc_desktop = GetDC(hwnd_desktop);
 3HDC hdc_framebuffer = CreateCompatibleDC(hdc_desktop);
 4BITMAPINFO bitmapinfo;
 5
 6bitmapinfo.bmiHeader.biSize = sizeof(BITMAPINFOHEADER);
 7bitmapinfo.bmiHeader.biWidth = (LONG)framebuffer_width;
 8bitmapinfo.bmiHeader.biHeight = (LONG)framebuffer_height;
 9bitmapinfo.bmiHeader.biPlanes = 1;
10bitmapinfo.bmiHeader.biBitCount = 32;
11bitmapinfo.bmiHeader.biCompression = BI_RGB;
12bitmapinfo.bmiHeader.biSizeImage = 0;
13bitmapinfo.bmiHeader.biXPelsPerMeter = 0;
14bitmapinfo.bmiHeader.biYPelsPerMeter = 0;
15bitmapinfo.bmiHeader.biClrImportant = 0;
16bitmapinfo.bmiHeader.biClrUsed = 0;
17
18DWORD* ptr_framebuffer;
19HBITMAP hbmp_framebuffer = CreateDIBSection(hdc_framebuffer, 
20  &bitmapinfo, DIB_RGB_COLORS, (void**)&ptr_framebuffer, NULL, 0);
21
22HGDIOBJ old_dc = SelectObject(hdc_framebuffer, hbmp_framebuffer);
23
24ReleaseDC(hwnd_desktop, hdc_desktop);

Man erzeugt also einen Device-Context kompatibel zum Desktop-Fenster (hdc_framebuffer) und die DIB-Section (hbmp_framebuffer) durch einen BITMAP-Info-Header mit den Größenangaben. Dabei fällt einem der Daten-Pointer (ptr_framebuffer) in die Hände.

Die größte Challenge ist der Aufbau der DIB-Section, die wie eine Windows Bitmap aussieht. Die Bildzeilen verlaufen dort von unten nach oben, und damit ist Koordinate (0, 0) (bzw. Pixel-Offset 0) die linke untere Ecke und (0, Y-max) die linke obere Ecke.
Viele andere Framebuffer (und auch mein GATE Framework) definieren (0, 0) als links-oben und verlaufen mit steigendem Y nach unten.

1DWORD* ptr_pixel = ptr_framebuffer + (height - y - 1) * width + x;
2*ptr_pixel = (((DWORD)r) << 16)
3           | (((DWORD)g) << 8)
4           | (((DWORD)b));

Und am Ende muss man per
RedrawWindow(hwnd, NULL, NULL, RDW_INTERNALPAINT | RDW_INVALIDATE) nur das Neuzeichnen des gesamten Fensters auslösen.

Im Fenster wird im WM_PAINT Event dann einfach per BitBlt() der aktuell “ungültige” Teil des Fenster mit den Daten aus der DIB-Section übermalt.

XLIB und Pixmaps

Mein erster Versuch mit der XLib und dem Zeichnen auf X11-Pixmaps lief über die Funktion XPutPixel() in einer Schleife. Das funktionierte zwar, doch für eine 640x480 Pixel Grafik brauchte mein Rechner mehrere Sekunden.
Oder anders gesagt: Noch ineffizienter geht es nicht mehr.

Doch auch bei Pixmaps kann man den Datenpuffer selbst allokieren und dann die RGB-Werte selbst in den Puffer schreiben. Womit man schon in wenigen Millisekunden eine ganze Szene in den Puffer gerendert hat.
So kann man dann die gesamte Pixmap in einem Schritt dann auf sein Fenster am Monitor zeichnen lassen.

Das funktioniert natürlich nur bei einer Farbtiefe von 24 oder 32 bit, wo in beiden Fällen ein 32 Bit breites RGB-Array im Speicher liegt. (Alle anderen historischen Bitmusterformen sind komplizierter umzurechnen.)

Rein exemplarisch und vereinfacht, sieht das dann so aus:

 1#include <X11/Xlib.h>
 2
 3void set_pixmap_pixel(void* image_data, 
 4  unsigned x, unsigned y, rgb_t const* color)
 5{
 6  uint32_t* ptr_pixels = (uint32_t)image_data;
 7  uint32_t* target_pixel = ptr_pixels[y * width + x];
 8  *target_pixel = (((uint32_t)color->r) << 16)
 9                | (((uint32_t)color->g) << 8)
10                | (((uint32_t)color->b))
11                ;
12}
13
14XImage* create_x11_pixmap(...)
15{
16  unsigned int bytes_per_pixel = 4;
17  unsigned int padding = XBitmapPad(display);
18  unsigned int bytes_per_line = width * bytes_per_pixel;
19  if(bytes_per_line % padding != 0)
20  {
21    bytes_per_line += (padding - (bytes_per_line % padding));
22  }
23  size_t image_size bytes_per_line * height;
24  void* image_data = malloc(image_size);
25  XImage* image = XCreateImage(display, visual, depth, ZPixmap, 
26    0, image_data, width, height, padding, 0);
27  return image;
28}
29
30void create_x11_window()
31{
32  Display* display = XOpenDisplay(NULL);
33  int screen = XDefaultScreen(display);
34  Window root_window = XDefaultRootWindow(display);
35  int depth = XDefaultDepth(display, screen);
36  Visual* visual = XDefaultVisual(display, screen);
37  Colormap colmap = XDefaultColormap(display, screen);
38  XSetWindowAttributes win_attribs = { 0 };
39
40  win_attribs.colormap = colmap;
41  win_attribs.event_mask = StructureNotifyMask;
42  win_attribs.border_pixel = XBlackPixel(display, screen);
43  win_attribs.background_pixel = XWhitePixel(display, screen);
44  unsigned long attr_mask = CWBackPixel | CWBorderPixel 
45                          | CWEventMask | CWColormap;
46  
47  Window window = XCreateWindow(display, root_window, 
48    0, 0, width, height, 0, depth, InputOutput, visual, 
49    attr_mask, &win_attribs);
50  XMapWindow(display, window);
51  XFlush(display);
52  ...
53}
54
55void render_x11_scene(...)
56{
57  ...
58  XImage* image = create_x11_pixmap(...)
59  ...
60  for(...)
61  {
62    ...
63    set_pixmap_pixel(image_data, x, y, &color);
64    ...
65  }
66  ...
67  GC gc = XCreateGC(display, window, 0, 0);
68  XSetGraphicsExposures(display, gc, 0);
69  XPutImage(display, window, gc, image, 0, 0, 0, 0, width, height);
70}

Fazit

Man sieht wieder einmal, dass Windows und Linux bzw. X11 gar nicht so weit auseinander liegen, was den Aufbau von GUIs intern anbelangt. Denn in beiden kann man einen Framebuffer so einrichten, dass man ihn mit einfachen 32-bit RGB Werten abfüllen kann.

Wenn man jetzt noch Maus und Tastaturbehandlung hinzufügt, dann kann mit einfachsten Mitteln GUIs für beide Plattformen bauen. Dafür müsste man sich natürlich alle “üblichen” Controls wie Buttons, Listen und Eingabefelder selbst zusammenstellen, doch das Ergebnis wäre eine komplett Plattform-unabhängige UI.

Einfache Apps (wie z.B.: zum Anzeigen von Fotos) kann man auf diese Weise in wenigen Kilobytes selbst erstellen, ohne auf Megabyte große Frameworks zurückgreifen zu müssen.

Koroutinen Kontextwechsel

2022-01-02T12:00:00+01:00

Nach meinen Experimenten mit Koroutinen mit OS-Funktionen und meinem Fehlschlag mit setjmp/longjump, ist es an der Zeit, das Thema “neu zu denken”.

Denn jetzt, wo Assembler Patches im GATE Projekt leicht möglich sind und mit UEFI eine zur Zeit thread-lose Implementierung vor mir liegt, bekommen Koroutinen plötzlich eine neue Bedeutung.

Für Windows und Linux habe ich mit Boardmitteln akzeptable Lösungen gefunden, um innerhalb eines Threads zwischen Callstacks hin und her zu hüpfen.

In EFI-Apps gibt es keine Threads, doch wenn man mehrere Callstacks anlegen könnte und zwischen denen hin- und herhüpfen könnte, dann wäre eine einfache Art von kooperativem Multitasking geboren, mit der man z.B. einen Webserver dazu bringen könnte, mehrere Anfragen zu bearbeiten, oder man könnte UIs mit Background-Tasks aufwerten.

Callstacks erzeugen

Normaler Datenspeicher, wie er von malloc() zurückkommt, ist nicht automatisch Stack-tauglich. Oft muss man dem OS erst mitteilen, dass man auch “Code-Adressen” darauf nutzen möchte.

EFI nutzt offenbar keinen Speicherschutz womit ein
efi_sys_table->BootServices->AllocatePool(EfiLoaderData, mem_size, &ptr_mem); ausreicht um Speicher für einen Callstack zu allokieren.

Unter Windows braucht man APIs wie VirtualAlloc(), VirtualProtect() und VirtualFree() um Speicher mit den Protection-Flags PAGE_EXECUTE_READWRITE auf die Nutzung als Stack vorzubereiten.

Zu einem neuen Callstack springen

Hat man einen neuen Stack allokiert, muss man eigentlich nur noch das Stack-Register auf dessen Ende setzen und kann dann eine weitere Funktion aufrufen, die in dem neuen Kontext laufen soll.
Die Funktion kann ganz ähnlich wie eine Thread-Entry-Funktion aussehen.

Damit man beim Rücksprung aus der Funktion wieder zum alten Stack zurückfinden kann, wird die Adresse des alten Stacks auf den neuen Stack gepusht, um am Ende wieder zurückfinden zu können.

X86-32 Funktion auf neuem Stack ausführen

 1; typedef void* (enty_function_t)(void* entry_param);
 2
 3mov eax, [stack_top_ptr]  ; stack-alloc-ptr + stack-size
 4mov ecx, [entry_param]
 5mov edx, [entry_function_ptr]
 6
 7push ebp      ; backup old EBP on current stack
 8mov ebp, esp  ; backup of current stack
 9mov esp, eax  ; switch to new stack
10push ebp      ; save old stack-ptr on new stack
11
12push ecx      ; param for entry-function
13call edx      ; call entry-function
14add esp, 4    ; param cleanup
15
16pop ebp       ; restore old stack-ptr
17mov esp, ebp  ; switch back to old stack
18pop ebp       ; restore old EBP

X86-64 Funktion auf neuem Stack ausführen

 1; typedef void* (enty_function_t)(void* entry_param);
 2mov rax, [stack_top_ptr]
 3mov rcx, [entry_param]
 4mov rdx, [entry_function_ptr]
 5
 6push rbp      ; backup old RBP on current stack
 7mov rbp, rsp  ; backup of current stack
 8mov rsp, rax  ; switch to new stack
 9and rsp, 0fffffffffffffff0h  ; align(16) new stack
10sub rsp, 8    ; prepare call-alignment
11push rbp      ; save old stack-ptr on new stack
12
13sub rsp, 32   ; allocate x64 home space
14call rdx      ; call function on foreign stack
15add rsp, 32   ; deallocate x64 home space
16
17pop rbp       ; restore old stack-ptr
18mov rsp, rbp  ; switch back to old stack
19pop rbp       ; restore old RBP

Callstack wechseln

Um dynamisch zwischen Callstacks wechseln zu können, braucht eine “Callstack-Snapshot” - Struktur, die einige intptr_t bzw. void* speichern kann, um Register des aktuellen Callstacks zu speichern. Und eben genau diese gesicherten Register werden dann von einem anderen Callstack-Snapshot geladen.

X86-32 Callstack wechseln

 1;void* gate_win32_callstack_switch_x86(
 2;        gate_callstack_context_t* old_to_save, 
 3;        gate_callstack_context_t* new_to_load);
 4
 5gate_win32_callstack_switch_x86 PROC
 6  push ebp
 7  mov ebp, esp
 8
 9  mov ecx, [ebp + 8]  ; store-context
10  mov edx, [ebp + 12] ; load-context
11
12  ;store current context to ptr in ECX
13  mov DWORD PTR [ecx +  0], esp
14  mov DWORD PTR [ecx +  4], ebp
15  mov DWORD PTR [ecx +  8], ebx
16  mov DWORD PTR [ecx + 12], esi
17  mov DWORD PTR [ecx + 16], edi
18
19  ;load new context from ptr in EDX
20  mov edi, DWORD PTR[edx + 16]
21  mov esi, DWORD PTR[edx + 12]
22  mov ebx, DWORD PTR[edx +  8]
23  mov ebp, DWORD PTR[edx +  4]
24  mov esp, DWORD PTR[edx +  0]
25
26  mov eax, 0    ; default-return: no switch
27  cmp ecx, edx
28  jz callstack_switch_x86_exit
29
30  ;if ecx != edx, we have switched, 
31  ;otherwise current context is only saved
32  mov eax, edx  ; return: pointer to switched context
33
34callstack_switch_x86_exit:
35  mov esp, ebp
36  pop ebp
37  ret
38  ;EAX tells, if switch was performed
39gate_win32_callstack_switch_x86 ENDP

X86-64 Callstack wechseln

 1;void* gate_win32_callstack_switch_x64(
 2;        gate_callstack_context_t* old_to_save, 
 3;        gate_callstack_context_t* new_to_load);
 4gate_win32_callstack_switch_x64 PROC
 5  push rbp
 6  mov rbp, rsp
 7
 8  ; store current stack frame to ptr in RCX
 9  mov qword ptr [rcx +  0], rsp
10  mov qword ptr [rcx +  8], rbp
11  mov qword ptr [rcx + 16], rbx
12  mov qword ptr [rcx + 24], rsi
13  mov qword ptr [rcx + 32], rdi
14  mov qword ptr [rcx + 40], r12
15  mov qword ptr [rcx + 48], r13
16  mov qword ptr [rcx + 56], r14
17  mov qword ptr [rcx + 64], r15
18
19  ; load next stack frame from stored struct at ptr in RDX
20  mov r15, qword ptr [rdx + 64]
21  mov r14, qword ptr [rdx + 56]
22  mov r13, qword ptr [rdx + 48]
23  mov r12, qword ptr [rdx + 40]
24  mov rdi, qword ptr [rdx + 32]
25  mov rsi, qword ptr [rdx + 24]
26  mov rbx, qword ptr [rdx + 16]
27  mov rbp, qword ptr [rdx +  8]
28  mov rsp, qword ptr [rdx +  0]
29
30  mov rax, 0    ; default-return: no switch
31  cmp rcx, rdx
32  jz callstack_switch_x64_exit
33
34  ;if ecx != edx, we have switched, 
35  ;otherwise the context was only saved without a switch  
36  mov rax, rdx  ; return: pointer to switched context
37
38callstack_switch_x64_exit:
39  mov rsp, rbp
40  pop rbp
41  ret
42  ;RAX tells, if switch was performed
43gate_win32_callstack_switch_x64 ENDP

Fazit

Nachdem x64-EFI das gleiche ABI wie Windows X64 hat, konnte ich den Stack-Wechsel einfach unter Windows im MSVC Debugger testen und war fast erstaunt, dass das auch genau so funktioniert, bevor ich die ersten Tests direkt als EFI-App erfolgreich ausführen konnte.
Interessant sind jetzt die noch nicht entdeckten Seiteneffekte.

Meine aktuelle Koroutinen-Implementierung ist noch ein bisschen detailreicher als hier beschrieben, da eine Routine beim create() zu einem Dispatcher springt, der gleich wieder zum Aufrufer zurückwechselt und zur finale Routine wird erst später wieder per yield() hingewechselt.
Und obwohl oben im ASM-Code vorgesehen ist, dass man aus einem neuen Callstack auch “einfach so” wieder zum Aufrufer zurückwechseln kann, ist das im Endeffekt nicht vorgesehen, da der Aufrufer dann vielleicht nicht mehr existiert.
Man wechselt dann immer zu einer internen Scheduler-Routine, die alle anderen verwaltet und eine “beendete” Routine deallokiert.

Wie auch immer … hier geht es ja vorerst nur um das Konzept.
Und das scheint zumindest auf den ersten Blick zu funktionieren.

Ein frohes Neues...

2022-01-01T12:00:00+01:00

Das neue Jahr ist angebrochen, doch stellt sich die Frage:

Wohin soll die Reise gehen?

Doch beginnen wir am Anfang mit einem herzlichen:

Prosit Neujahr!

In den letzten Tagen, als ich besorgt über die Welt nachdachte und dabei wahllos ein paar Links folgte, bemerkte ich, dass neben all den vielen Wirrungen auch viel Gutes auf dem Weg ist.

Wissenschaft und Technik kann nicht alle Probleme unserer Zeit lösen, doch sie kann einen entscheidenden Beitrag leisten.

Waldsterben und Klimakrise

Während meine Mutter immer noch traurig an die vielen abgeholzten erkranken Wälder denkt, die sie seit ihrer Kindheit kannte, hat man in Afrika schon lange erkannt bzw. wiederentdeckt, dass Bäume wahrlich “heilbringend” sind.

Die steigenden Temperaturen haben auch Wüstengebiete vergrößert und daher arbeitet man in Afrika schon seit Jahren an der grünen Mauer, pflanzt unentwegt Bäume und stellt fest, dass diese das Land heilen.

China beweist seit Jahrzehnten, dass man systematisch durch sinnvolle Bepflanzung karges Land in blühende Gärten verwandeln kann.
Und von Israel über Arabien bis nach Afrika arbeiten Ingenieure und Biotechniker an der Renaturierung von scheinbar wertlosen Böden.

Und warum schaffen wir das in Europa nicht, sondern holzen weiter unsere Wälder ab und zerstören mit Monokulturen die Böden?
Man darf die Natur eben nicht hirnlosen Kapitalmärkten überlassen, die nur billig Brandschatzen wollen, sondern braucht visionäre Ansichten.

Biologisch-verträgliche Elektrizität

Ich bin nicht stolz auf meine Lithium-Ionen-Zellen und Akkupacks in Sachen Umwelt. Sie sind leider aktuell nur alternativlos.
Doch das ändert sich hoffentlich bald, denn anstatt mit vernichtenden Methoden Lithium und Cobalt aus der Erde herauszubrechen, können wir in Zukunft unseren Stromhunger mit Natrium-Ionen-Akkus decken.

Immer mehr Bereiche setzten zum Glück auf Photovoltaik und nutzen die Kraft der Sonne anstatt sich mit CO2 oder radioaktiven Stoffen herumzuschlagen. Und mit einer Natrium-Batterie-Lösung als Puffer hätten wir endlich mal etwas gefunden, was aus breit verfügbaren Rohstoffen erzeugbar ist.

Die Forschung geht munter weiter, was mich persönlich sehr freut. Bleibt nur zu hoffen, dass auch hier die Menschen nicht an dumme Börsendiagramme denken, sondern an die Zukunft, wenn es um die Förderung “der richtigen Technologien” geht.

Die Rückkehr der Idealisten

Ich weiß nicht, ob Menschen wie Elon Musk “gute Absichten” haben oder nur für ihr Ego arbeiten. Tatsache ist jedoch, dass solche Idealisten mit entsprechender Finanzkraft “Gutes” ins Rollen bringen können.
Und vielleicht brauchen wir utopische Ziele wie den Flug zum Mars um die Forschung auf Trapp zu halten, wobei dann auch immer enorm hilfreiche Erkenntnisse für den Alltag abfallen.

Doch wenn man sieht, wie angefangen mit Fridays for Future immer mehr Jugendliche wieder “etwas erreichen wollen”, während in den Jahrzehnten zuvor alle nur den Status-Quo erhalten wollen, ja dann ist Optimismus vorprogrammiert.

Es wandelt sich nicht automatisch alles zum Guten, nur wenn Menschen plötzlich Interesse für ein Thema verspüren, doch es ist allemal besser, wenn mehr Personen für ihre Überzeugung einstehen, als dass man alles nur einem kleinen Kreis von in der Regel überalterten Ewiggestrigen überlässt, die vor allem an ihren Machtsesseln interessiert sind.

Fazit

Das Jahr 2022 hat begonnen und trotz zahlreicher Krisen und Probleme, habe ich ein ungewöhnlich positives Gefühl für die Zukunft, auch wenn sie rauer wird, als in den Jahren zuvor.

So lange ich nämlich sehen kann, dass an vielen Fronten für Veränderung und Verbesserung gekämpft wird, bin ich zuversichtlich, dass wir auch die “unguten” Seiten unserer Welt neu ausrichten werden.

In diesem Sinne wünsche ich allen einen guten Start ins Jahr 2022!

Das Jahr 2021

2021-12-31T12:00:00+01:00

Ende 2020 haben wir gehofft, dass 2021 wieder “normal” werden würde. Vielleicht hat genau der “Drang zur Normalität” eben diese verhindert.

Vieles hat sich geändert, damit alles gleich bleiben konnte und in vielen Köpfen blieb trotzig alles gleich, damit sie sich von den anderen unterscheiden konnten.

Was ist also passiert in den letzten 365 Tagen?

Das Leben wurde teurer

Jahre lang hat mein großes Putenschnitzel mit Beilage (Salat oder Pommes) 8,5 Euro zum Mitnehmen im Schnitzelladen an der Ecke gekostet. Doch seit Herbst wird mit 9,50 abgerechnet.
Die Wien-Energie erhöht zum Jahreswechsel die Strompreise von 9,9 Cent pro Kilowattstunde auf 14,5 Cent.
Und bei AliExpress sind die Preise auch um bis zu 50% gestiegen und da sind die Zusatzkosten beim Versand noch gar nicht eingerechnet. 100 Euro kostete mein RockPI-X im letzten Mai, nun ist er unter 150 Euro gar nicht mehr zu bekommen.

Ich habe das Glück, dass ich mit meinem Einkommen auskommen kann, doch was machen meine Mitmenschen, die wegen der Pandemie keinen Job mehr haben oder die in einem schlechteren Dienstverhältnis stehen?

Divergenz der Gesellschaft

Wenn nun auch im eigenen Bekanntenkreis die “Interpretation der Wahrheit” immer größere Kreise zieht, muss ich mir echt Sorgen machen.
Sieht man im Fernsehen 5 betroffene Ärzte, die von der totalen Überfüllung ihrer Abteilung berichten, hallt es sofort durch den Raum:

Typisch! Die wurden alle gekauft, damit sie Lügen verbreiten um uns zur Impfung zu zwingen.

!! W-T-F !! Wo lebe ich eigentlich?
Obwohl es absolut nicht meine Meinung ist, kann ich es verstehen, wenn Menschen gegen eine Impfpflicht demonstrieren gehen. Und damit meine ich nicht jene Nazis und Identitären, die nur darauf pochen Krawall zu machen, sondern ich meine zu Recht besorgte Mitbürger.
Aber seit dem finstersten Mittelalter sind anständige Wissenschaftler, Ärzte und Forscher nicht mehr so irrational beschimpft und verteufelt worden, wie wir es aktuell erleben.

Ich bin hier Zeuge einer fatalen geistigen Rückentwicklung der Gesellschaft geworden, die mich offen gesagt schwer beunruhigt.
Selbstverständlich hat die Regierung enorm viele Fehler gemacht und auch ich bin angepisst in Sachen Datenschutz und Chaos bei den Behörden … aber das ist doch kein Grund gegen den Staat aufzumarschieren und die Wissenschaft als Ketzer an den Pranger zu stellen, nur weil sie uns die Wahrheit sagen, die manche einfach nicht hören wollen.

Und während einige im Blutrausch nach einem Bürgerkrieg verlangen (ja, das habe ich echt schon auf den Straßen vernehmen müssen), ist eine weitere sehr liebe “Oma” aus der Nachbarschaft mit COVID-19 verstorben. Wir waren nicht verwandt, aber ich habe sie trotzdem sehr gemocht und vielleicht hätte ich sie noch ein paar Jahre länger erleben dürfen, hätte das Virus ihrem in die Jahre gekommenen Körper nicht so zugesetzt.

Ich gebe niemandem persönlich die Schuld an dem Tod. Aber ich bin froh sagen zu können, dass ich durch meine Impfung die Gefahr reduzieren konnte. Und ich wünsche mir, dass auch andere Mitbürger diesen kleinen Sticht mutig hinnehmen, und dass wir aufhören alles nur aus Trotzigkeit abzulehnen.

Rückkehr des Desktops

Weil Smartphones für mich der Inbegriff der gesellschaftlichen Verblödung sind, und deren Technik nur wie leichte Drogen die Menschen von der Realität ablenken, freue ich mich, dass Homeoffice und Co. dem PC eine Renaissance beschafft haben.
Man nutzt die Technik endlich wieder “zum Arbeiten” und zum Erreichen von Zielen und nicht um “die Zeit totzuschlagen”.

Und unsere Jugend lernt auch immer mehr, die Technik zur Überwindung von Grenzen einzusetzen. Leider nicht alle, doch es ist ein Anfang.
Es sind zwar nicht alle Schulen auf dem neuesten Stand, aber es freut mich zu hören, dass nun auch unsere Lehrkräfte notgedrungen mehr und mehr Technik ordentlich einsetzen.

Natürlich frage ich mich: “Warum nicht schon früher?”, denn diese Skills hätten wir uns alle schon seit dem Jahr 2000 aneignen können, aber immerhin geht es jetzt ordentlich los.

… und der Blog?

Die Google Search Console verrät, welche Anfragen zu einem Webspace hingeleitet wurden und ich war äußerst überrascht, dass der Begriff “Peter Regung Spiderman englisch” zu meinem Beitrag zu “Far-From-Home” die häufigste Suchanfrage war, nur weil ich da “Peter Regung == Peter Tingle” aufgenommen hatte.
Doch auch andere Suchbegriffe zu C++, WinPE und Hardware wie dem Lichee Pi tauchen dort auf.

Zumindest weiß ich jetzt aber, dass dieses Online-Tagebuch nicht ausschließlich nur für mich selbst vorhanden ist und dass zumindest ein paar Menschen da draußen etwas Nützliches daraus ableiten konnten.

Und ob gleich das am Ende für mich keine wirkliche Rolle spielt, so ist es dennoch ein weiterer Motivationsfaktor, wöchentlich das eine oder andere Highlight hier zu verschriftlichen.

Fazit

2021 war leider wieder ein Jahr der Verwirrungen und Verwerfungen. Und dennoch haben wir im Endeffekt alles gut überstanden.
Wir haben zu essen und zu trinken, und wenn wir ein bisschen besonnener mit unseren Wünschen und Forderungen umgehen, werden wir feststellen, dass wir weiter alles tun können, was uns voranbringt.
Jahrtausende haben Menschen glücklich gelebt, ohne jedes Quartal in ein anderes Land fliegen zu können, um damit angeben zu können.
Wir werden es auch mal aushalten, ein Jahr lang die Schönheiten unserer direkten Umgebung vorrangig genießen zu dürfen.

Ich wünsche jedenfalls allen einen guten Rutsch ins neue Jahr, und hoffe darauf, dass wir wieder näher zusammen kommen, im geistigen und gesellschaftlichen Sinne, und dass wir dabei trotzdem den nötigen Abstand einhalten, um die Älteren und Schwächeren vor Krankheit zu schützen.

Corona Impfung - Teil 3

2021-12-30T12:00:00+01:00

Während andere sich bei boost.org die aktuellen Version 1.78 holen um ihre C++ Programme aufzufrischen, war ich das dritte Mal im Austria-Center um meinen COVID-19 Schutz “boosten” zu lassen.

Fast könnte man sagen:

Same procedure as last year.

… doch noch ist das Jahr nicht vorbei.

Anmeldung

Wieder mal meine Lieblingsaussage:

Manche sagen, Österreich sei in Sachen Digitalisierung noch im Mittelalter.
Ich sage euch: Das stimmt nicht!
So weit sind wir noch lange nicht!

Ok, vielleicht übertreibe ich ein bisschen, aber aus meiner kritischen Sicht funktionieren alle “analogen” Schritte der Impfung (vor allem in Wien) hervorragend, während alles, was man “online” tun können soll bzw. sollte, einfach schlecht gelöst ist.

Irgendwann in den letzten Monaten wurde offenbar das Wiener Impfportal “geändert”. Damit brechen nicht nur Links, die man sich bei der letzten Anmeldung gespeichert hat, sondern auch der Login schwankt zwischen der Übernahme der alten Daten aus der früheren Registrierung und einer Neuregistrierung.

Zuerst wird man mit Infos verwirrt, dass man der erneuten Datenerfassung zustimmen soll um den Login im neuen Portal einzurichten und dann läuft man in eine 404 Seite.
Ich dachte anfangs echt, ich wäre auf einen Phishing-Versuch hereingefallen. Doch bei einem weiteren Loginversuch, war man plötzlich “wieder im System” eingeloggt.

Hat man sich dann seinen Impftermin reserviert, bekommt man eine Liste von dem, was man mitnehmen soll. Also Impfticket (bei der Reservierung erhalten), Impfpass, Ausweis und e-Card. Und: Die Einwilligungserklärung.

Im früheren Impfportal war die verlinkt. Diesmal habe ich sie nicht gefunden. Zwar kann man die Einwilligung auch vor Ort ausfüllen, aber warum? Google hingegen findet bei einer Suche das benötigte PDF im wp-content/uploads Folder.

Also echt jetzt! Was soll das?
Kids von heute coden sich über’s Wochenende Itemshops für ihre Lieblingsspieleerweiterungen mit Userverwaltung und Bezahlservice zusammen und die “Profi-Softwareabteilung” von Österreichs größter Stadt scheitert am Anfügen eines Wordpress-Links an E-Mails oder auf der Hauptseite?

Ich bin einfach nur enttäuscht.

Impfung mit Zertifikat

Am Austria Center angekommen war die Prozedur genau so wie bei meinen Impfungen im Sommer. Nur dass ich diesmal ins Untergeschoss geleitet wurde, wo die Datenprüfung, das medizinische Gespräch, die Impfung und die Wartepause genau so stattfand, wie zuletzt.

Ich vermutete, dass ich ziemlich alleine geimpft werden würde, wegen des Termins mitten in den Weihnachtsfeiertagen, doch nein. Es war zwar weniger los, als im Hochsommer, doch permanent tröpfelten neue Personen durch die Registrierungstische und Impfkabinen hindurch.

Wegen der (aus meiner Sicht “dummen”) Entscheidung, dass nach Juni keine Zertifikate automatisch an Geimpfte ausgestellt wurden, war ich das letzte halbe Jahr auf meinen Impfpass angewiesen, den ich selbstverständlich die 3 oder 4 mal, wo ich ihn gebraucht hätte, nicht dabei hatte.
Denn in der Kantine meiner Firma darf man seit November ja nicht mal mehr das Mittagessen in der Box abholen, ohne dass man auf seinen Impfstatus geprüft wird, während es im Supermarkt nebenan egal war und ist, ob man überhaupt geimpft ist. (Echt bescheuert diese Politik!)

Na jedenfalls gab es im Nebengebäude des Impfzentrums eine Büroeinrichtung, die einem ein Zertifikat ausdruckt. Dort musste ich etwa 15 Minuten in der Schlage stehen, bis mir einer der dortigen Mitarbeiter ein Zertifikatsblatt erstellen und aushändigen konnte.

Nun kann ich also entweder meinen Impfpass oder den A4-Wisch nutzen, wenn ich mal ins Gasthaus gehen möchte.

Ich habe das Blatt eingescannt und nun kann ich es auch auf einem Nicht-Google-Mobiltelefon mitführen.
Falls - und das werde ich in den nächsten Tagen ausprobieren - der Scan “einfach so” akzeptiert wird, dann folgt meine nächste Frage auf dem Fuße:

Wieso zur Hölle wird nicht jedem Mitbürger das PDF per e-Mail zugestellt?

Anstatt dessen legt man diese “sensiblen” Daten in die exklusiven Hände von Android-Apps, wo sie nur gemeinsam mit Werbeangeboten von Influencer-Hautcreme und Seminaren zu alternativer Magie abgerufen werden können.

Lob an alle Impf-Teams

Den fleißigen Bienchen in unseren Impfzentren muss ich aber erneut meinen Dank und meine Bewunderung aussprechen. Denn ihr Service war schnell, zielgerichtet und professionell.

Sie sitzen dort (freiwillig) auch an den Feiertagen, bekommen vermutlich nicht immer nur freundliche Gesichter zu sehen und sind dennoch stets hilfsbereit und bewahren ganz nebenbei unsere Gesundheit.

Ich glaube nicht, dass die Gesellschaft (also wir alle) den Einsatz dieser guten Geister entsprechend würdigen. Natürlich bin ich nicht der einzige, der ihre Leistung schätzt, doch wenn man sich ansieht, wie aggressiv manche Mitmenschen ihren selbst gezüchteten Hass genau auf diejenigen richten, die nichts anderes tun als zu helfen, dann merkt man erst, wie unglaublich wertvoll alle Arbeiten im medizinischen Bereich heute sind.

Denn es ist nicht nur die professionelle Arbeit alleine, die uns Ärzte, Pflege- und Impfpersonal bis hin zum Zivildiener bereitstellen, sondern es ist vor allem der besonnene und geduldige Umgang mit uns, trotz vieler Störklänge aus der Bevölkerung, der meinen Respekt verdient.

Und deshalb möchte ich hier nochmal ganz deutlich dokumentieren:

Danke an das gesamte medizinische Personal!
Ihr seid unsere Helden.

Moderna Booster mit erwarteter Reaktion

Nun, die erste Impfung mit Moderna habe ich gar nicht gespürt, dafür hat mich die zweite unerwartet hart erwischt. Das lag vielleicht auch daran, dass ich dachte, ganz normal weiterarbeiten zu können.

Auch für meinen 3. Impfstich waren Reaktionen im Sinne eines 24-48 stündigen Krankheitgefühls prognostiziert.

Ein paar Stunden nach der Impfung kamen dann Schlappheit und Kopfschmerzen auf mich zu. Doch, damit hatte ich gerechnet und mich vorsorglich ins Bett gelegt. Ich kann zwar nicht sagen, dass ich besonders gut geschlafen hätte, weil ich alle paar Stunden wieder aufgewacht bin, aber im Endeffekt habe ich die Impfreaktion großteils “verschlafen”.

Als ich am Folgetag dann wieder aufstand, waren die Kopfschmerzen noch spürbar da, doch bereits eine Stunde später waren sie fast gänzlich verflogen. Und am Abend konnte ich bereits wieder mit Kopfhörern und Musik durchs Zimmer steppen, als wäre nichts gewesen.

Kurz gesagt: Bis 24 Stunden nach der Impfung war Ruhe angesagt, danach ging der Alltag wie gewohnt weiter.

Es ist mir also weiter ein Rätsel, warum manche Menschen so unvernünftig sind, und lieber wochenlang hustend und röchelnd im Fieberbett liegen wollen, nur um sich trotzig ein Stichlein zu ersparen und damit nebenbei ein ungutes Virus weiter verbreiten.

Fazit

Die 3. Impfung ist erledigt und mir geht’s gut. Sehr gut.

Jetzt hoffe ich weiter darauf, dass sich auch der Rest der Bevölkerung impfen lässt und damit dem Virus das Wasser abgräbt. Damit wir eben nicht noch weitere Lockdowns brauchen und die ehrenwerten Mitarbeiter in den Krankenhäusern die Entlastung erhalten, die sie schon so lange redlich verdient haben.

Nachtrag

Falls irgend jemand aus meinem gescannten und hier hochgeladenen Zertifikats-Dokument den Schlüssel aus den verbliebenen Pixeln des QR-Codes wiederherstellen kann, möge mir derjenige bitte den Quellcode zum Algorithmus zukommen lassen. Danke! ;)

Windows X64 Calling Convention

2021-12-26T12:00:00+01:00

Nach vielen Jahren komme ich endlich dazu: X64 Assembler.

Sich selbst ein paar “Features” hinzucoden ist ja kein Problem, doch wenn ich mit C und C mit mir reden will, wird die Einhaltung der X64 Calling Convention essentiell.

Vorgeschichte: x86-32

Im 32-Bit Modus war die Welt theoretisch kompliziert, doch praktisch dann wieder einfach. Es gab unter Windows 2 Aufruf-Konventionen, nämlich cdecl und stdcall und Linux gab sich generell nur mit cdecl zufrieden.

Alle Parameter einer Funktion wurden auf den Stack gepusht und innerhalb der Funktion wurde dann der Frame-Pointer (Base-Pointer, bzw. BP oder EBP) auf den Stack-Pointer (SP oder ESP) gesetzt und über diesen konnte man dann mit [EBP + offset] auf übergebene Parameter und [EBP - offset] auf lokale Variablen am Stack zugreifen. Ein paar Register mussten zusätzlich auf den Stack gepusht werden, weil sie als non-volatile gelten und aus der Sicht von außen nicht verändert werden durften: EBX, ESI und EDI.
Und am Ende wird ESP wieder auf den EBP zurückgesetzt und von dort kann wieder das alte Stackframe zurück ge-POP-t werden.

In einer cdecl x86-32 Funktion sieht der Maschinen-Code ohne Optimierungen so etwa wie folgt aus:

 1int32_t foo(int32_t a, int32_t b, int32_t c)
 2{
 3  // PROLOG:
 4  // asm PUSH EBP     ; save old stack frame
 5  // asm MOV EBP, ESP ; base for new stack frame
 6  int32_t x;
 7  int32_t y;
 8  // asm SUB ESP, 8   ; alloc local stack for 2 ints (x, y)
 9
10  x = a + b;
11  // asm MOV EAX, [EBP + 8]   ; load a
12  // asm ADD EAX, [EBP + 12]  ; add b
13  // asm MOV [EBP - 4], EAX   ; store x
14
15  y = x + c;
16  // asm MOV EAX, [EBP - 4]   ; load x
17  // asm ADD EAX, [EBP + 16]  ; add c
18  // asm MOV [EBP - 8], EAX   ; save y
19
20  return y;
21  // asm MOV EAX, [EBP - 8]   ; load y as return value
22
23  // EPILOG:
24  // asm MOV ESP, EBP ; dealloc local stack
25  // asm POP EBP      ; restore old stack frame
26  // asm RET
27}
28
29int main()
30{
31  /*...*/
32
33  int32_t result = foo(1, 2, 3);
34  // asm PUSH 3      ; add c to stack
35  // asm PUSH 2      ; add b to stack
36  // asm PUSH 1      ; add a to stack
37  // asm CALL foo    ; call __cdecl function
38  // asm ADD ESP, 12 ; remove a,b,c from stack
39  // asm MOV [result], EAX
40
41  /*...*/
42}

Innerhalb von foo kann man über EBP wie folgt adressieren:

EBP Offset	Element	Beschreibung
EBP + 16	c	3. Parameter (zuerst gepusht)
EBP + 12	b	2. Parameter
EBP + 8	a	1. Parameter (zuletzt gepusht)
		Stack-Frame Grenze
EBP + 4	RET Adresse	Rücksprung Adresse zum Aufrufer
EBP + 0	EBP Backup	Gesicherter EBP des Aufrufers
EBP - 4	x	1. lokale Variable
EBP - 8	y	2. lokale Variable

Vereinfacht lautet die Regel:

EBP + 8 + arg_index * 4 greift auf Funktionsparameter zu.
EBP - 4 - var_index * 4 greift auf lokale Variablen zu.

Andere Ausrichtungen wie für double oder int64 verändern die Formel zwar, aber hier geht es ja nur um die abstrakte Theorie.

Windows-X64 mit Home-Space, Shadow-Space …

Obwohl möglich, sieht die X64 Aufrufkonvention anders aus, als für X86-32, denn hier wollen wir für den schnelleren Datenaustausch einige Parameter über Register laufen lassen.

Alle Parameter kleiner 64 Bits werden auf 64 Bits ausgedehnt, und alles was größer ist, wird per Pointer übergeben.

Unter Windows werden daher die ersten 4 Parameter in RCX, RDX, R8 und R9 übergeben und der Rest auf den Stack ge-PUSH-t.
Ein Spezialfall sind float und double Werte, die in den xmm Registern übergeben werden (was ich jetzt hier mal still und heimlich weglasse).

Für variadic/vararg Funktionen wäre diese Konvention schlecht, weil die über zusammenhängende Speicher funktionieren und keine Register kennen.
Und dafür gibt es einen interessanten Kompromiss:
Den Home-Space, auch Shadow-Space genannt.

Man allokiert (== reserviert == überspringt) am Stack genau den Speicher, den die Register der Parameter brauchen würden und überlässt es der aufgerufenen Funktion, diesen Speicher zu nutzen.

Die Funktion könnte die 4 Parameter-Register in den Home-Space schreiben und hätte dann ein Layout-Äquivalent zu 32-Bit cdecl, und stdarg.h Makros würden 1:1 damit funktionieren.
Die Funktion kann den Home-Space aber auch ignorieren und nur mit den Registern arbeiten.
Und die Funktion kann die vier 64 Bit Slots des Home-Space auch nutzen um andere Daten dort abzulegen, quasi lokale Variablen, die aber außerhalb des Stackframes liegen.

Kein formaler Frame-Pointer

In der 32-Bit Welt zeigt das EBP Register immer genau auf die Adresse, wo das EBP Register des Aufrufers gesichert wurde und 4 Bytes darüber liegt die Rücksprungadresse zum Aufrufercode.
So kann man “standardisiert” über EBP die Aufrufkette rückverfolgen (so lange nicht das Feature “Omit Frame Pointers” (/Oy) aktiviert ist).

Das 64 Bit ABI kennt keinen fixen Frame-Pointer. Es ist nicht verboten RBP weiter so zu benutzen, aber der C/C++ Compiler generiert Parameter und lokale Variablen-Zugriffe häufig mit [RSP + Offset].
Das ist zwar sehr effizient und kann vom Compiler hoch optimiert werden, aber macht es verdammt schwer nachzuvollziehen, was wirklich abgeht, da alles relativ zum aktuellen Stack-Pointer passiert.

Will man RBP statt RSP nutzen, so wird empfohlen, RBP zu sichern und auf RSP zeigen zu lassen. Letztendlich ist es dann aber auch schon egal, ob man RBP + offset oder RSP + offset schreibt.

Sicherung von “nicht-flüchtigen” Registern

Folgende Register gelten unter x64 als “non-volatile” (also “nicht-flüchtig) und müssen gesichert werden, bevor man sie verändern darf:

RBP, RBX, RSI, RDI, R12, R13, R14, R15

Man PUSHt sie daher am Beginn der Funktion auf den Stack und holt sie am Ende vor dem RET mit POP wieder zurück. Wenn man die Register nicht anfasst, braucht man sie natürlich auch nicht sichern.

Verflixtes 16-Byte Alignment

Um übelsten finde ich die 16-Byte Ausrichtung des Stacks, die notwendig ist, damit 128-Bit Operationen performant funktionieren.
Je nach Anzahl der Parameter, Variablen und gesicherten Registern, müssen im Stack Lücken gelassen werden, damit die RSP Adresse vor einem CALL immer ein genaues Vielfaches von 16 Byte ist.

Beim Funktionsaufruf mit kleiner-gleich 4 Parametern, müssten wir 32 Bytes für den Home-Space vom Stack abziehen (was automatisch 16-Byte ausgerichtet ist). Bei 5 Parametern wird zuerst eine 8-Byte Lücke gelassen, dann der letzte Parameter gePUSHt und am Ende werden 32 Bytes Home-Space abgezogen. Bei 6 Parametern werden die letzten 2 Parameter gePUSHT und 32 Bytes Home-Space abgezogen … usw.

Fazit: Eine ungerade Parameteranzahl >= 5 erfordert eine Ausrichtung vor dem CALL.

Innerhalb der Funktion hat CALL die Rücksprungadresse auf den Stack gelegt, womit dieser nicht ausgerichtet ist. Entweder lässt man eine ungerade Summe von Register-PUSH + lokalen Variablen den Stack ausrichten, oder man addiert 8 Bytes zu RSP, damit der Stack ausgerichtet ist und arbeitet dann mit einer geraden Anzahl an PUSH + lokalen Variablen weiter.
Am Ende muss RSP wieder durch 16 ohne Rest teilbar sein, damit ein weiterer Funktions-CALL problemlos stattfinden kann.

Fazit: Im Prolog braucht also eine gerade Anzahl von PUSH + lokalen 64-bit Variablen eine Ausrichtung, weil die Rücksprung-Adresse die Stack-Ausrichtung verschiebt.

Und genau das macht es dann so f*cking kompliziert, die Adressen der Variablen und der Parameter zu bestimmen. Was für ein Glück, dass in C/C++ der Compiler diesen Job übernimmt.

x64 Beispiel

 1int64_t foo(int64_t a, int64_t b, int64_t c, 
 2            int64_t d, int64_t e)
 3{
 4  // PROLOG:
 5  int64_t x;
 6  int64_t y;
 7  // asm SUB RSP, 24  ; alloc local stack frame 
 8  //                  ; for 2 int64 (x, y) + alignment
 9
10  x = a + b + c + d;
11  // asm MOV RAX, RCX        ; load a
12  // asm ADD RAX, RDX        ; add b
13  // asm ADD RAX, R8         ; add c
14  // asm ADD RAX, R9         ; add d
15  // asm MOV [RSP + 8], RAX ; store x
16
17  y = x + e;
18  // asm MOV RAX, [RSP + 8]               ; load x
19  // asm ADD RAX, [RSP + 24 + 8 + 32]     ; add e
20  // asm MOV [RSP + 0], RAX               ; save y
21
22  return y;
23  // asm MOV RAX, [RSP + 0]  ; load y as return value
24
25  // EPILOG:
26  // asm SUB RSP, 24  ; dealloc local stack frame
27  // asm RET
28}
29
30int main()
31{
32  /*...*/
33
34  int64_t result = foo(1, 2, 3, 4, 5);
35  // asm SUB RSP, 8  ; prepare CALL-alignment
36  // asm PUSH 5      ; add e to stack
37  // asm MOV R9, 4   ; put d in register
38  // asm MOV R8, 3   ; put c in register
39  // asm MOV RDX, 2  ; put b in register
40  // asm MOV RCX, 1  ; put a in register
41  // asm SUB RSP, 32 ; alloc home space (4 * 64-Bits)
42  // asm CALL foo    ; call function
43  // asm ADD RSP, 48 ; dealloc (home space + arg 5 + alignment)
44  // asm MOV [result], EAX
45
46  /*...*/
47}

In main brauchen 5 Parameter zusätzliche 8-Bytes um das 16-Byte Alignment einzuhalten. Das gleiche passiert in foo, wo der RET-Adresse + 2 Variablen ebenfalls noch 8-Bytes fehlen, damit RSP am Ende wieder korrekt ausgerichtet ist.

Innerhalb von foo kann man dann so adressieren:

RSP Offset	Element	Beschreibung
RSP + 72		Lücke für Stack Ausrichtung
RSP + 64	e	5. Parameter
RSP + 56	d / R9	Home für 4. Parameter
RSP + 48	c / R8	Home für 3. Parameter
RSP + 40	b / RDX	Home für 2. Parameter
RSP + 32	a / RCX	Home für 1. Parameter
		Stack-Frame Grenze
RSP + 24	RET Adresse	Rücksprung Adresse zum Aufrufer
RSP + 16		Lücke für Stack Ausrichtung
RSP + 8	x	1. lokale Variable
RSP + 0	y	2. lokale Variable

Fazit

X86-32 war nie “schön”, aber es war User-freundlich. Wir konnten mit EBP manuell ein paar ASM-Zeilen schreiben, die den OS-Standards entsprachen.

Bei X86-64 merkt man deutlich, dass die Calling Convention nicht mehr auf “Handarbeit” ausgelegt ist.
Ein Compiler kann die nötigen Offsets schnell berechnen, wenn sich ein Register oder eine Variable einschleicht. Doch wenn man das selbst im Kopf machen muss, wird einem leicht schwindelig.

Andere ASM-Beispiele liegen im BLOG-Classroom.
Und ein paar andere “coole” Blogger haben auch schöne Artikel dazu geschrieben:

In Linux (und BSD und SysV) sieht die Sache ein bisschen anders aus. Man nutzt 6 Register für Parameter, keinen Home-Space, dafür müssen vararg Funktionen ihre Parameter in einen Zwischenspeicher umkopieren, aber das verflixte Alignment ist auch dort notwendig.

… aber das ist eine andere Geschichte.

Stille (an Tag und) Nacht

2021-12-25T12:00:00+01:00

Wir hatten alle bis zum Abend gewartet, bis alle von der Arbeit heim kamen, und dann wurden endlich die Updates verteilt.
Es war ein buntes Treiben voller Überraschungen.

Dann wurden die kleinen Server alle in den Ruhezustand versetzt, und die größeren erzählten sich noch Geschichten bis tief in die Nacht, bis auch sie dem Timeout zum Shutdown folgten.

Wie üblich läuft bei einem Nerd wie mir der kleine Server Cluster de facto das ganze Jahr im Wohnzimmer durch.

Es gibt aber diesen einen Abend, an dem man schon als Kind gelernt hat, dass er etwas Besonderes ist. Ein Abend an dem man auch an jene denkt, die nicht mehr da sind.
Und dann kommt der Moment, wenn man die berühmte Schweigeminute durchhält, wo es einfach nur still ist.

Ich habe mir vor vielen Jahren angewöhnt, am Weihnachtsabend, genauer gesagt nach Mitternacht, diese menschliche Tradition auch auf die Technik zu übertragen.
Ohne einen technischen Vorwand werden alle Systeme heruntergefahren, die Smartphones werden ausgeschaltet auch das Licht und Heizung sind “OFF”.
Die Nachbarn sind auch schon alle im Bett (oder einfach nur lautlos).

Das ist der Moment, in dem es sogar in der Großstadt muxmäuschenstill wird.

Jetzt kann man eine Weile in die einsame Flamme einer zuvor angezündeten Kerze blicken. Anfangs gehen einem noch tausend Gedanken durch den Kopf. Bilder von Verwandten, Freunden und Kollegen tauchen auf und verschwinden wieder. Und wenn man das eine Weile lang fortführt, wird es auch im eigenen Schädel ruhiger, man könnte fast sagen: klarer.

Irgendwann stellt sich eine Entspanntheit ein, die ich als sehr angenehm empfinde. Viel intensiver hört man plötzlich das Bellen eines Hundes von der anderen Straßenseite, oder wenn zu später Stunde ein einzelnes Auto in die Gasse biegt.

Dann merkt man, dass es genug ist. Genug für diesen Tag, genug für dieses Jahr, bläst die Kerze aus, dreht sich um und legt sich ins Bett. Man liegt viel gerader und regungsloser da als sonst, es juckt auch weniger auf der Haut und man muss sich nicht wie sonst üblich irgendwo kratzen.

Und dann wacht man am nächsten Tag ganz zwanglos auf. Es ist anders als sonst. Kein Surren von Lüftern und keine Gehupe von der Straße.

Man steht auf, blickt durchs Fenster, sieht kaum Menschen, und es ist weiter ruhig. Man steht in der Mitte seiner Wohnung, blickt sich um, sieht was man alles angehäuft hat, was alles da ist und regungslos zurückblickt.

Es gibt keinen Drang, keinen Zwang etwas zu tun. Alles besteht auch, ohne dass es bewegt werden muss. Und das ist der Moment, wo mir spontan die Zeilen

Und Gott sah, dass es gut war.

einfallen.

Und dann keimt die gewohnte Normalität wieder auf. Geräte werden eingeschaltet, 1 nicht durchgekommener Anruf scheint auf, Ideen und Gedanken springen an … denn es ist inzwischen Mittag und alles ist erwacht.

Manchmal muss man einen Motor erst abstellen, um ihn wahrnehmen zu können. Und manchmal muss man eine Uhr erst anhalten, um ihr Ziffernblatt genau betrachten zu können.

Auch so etwas kann Weihnachten einem ermöglichen.
Einen kurzen Moment der Stille, der die Grenzen von Schall und Rauch überwinden kann.

Frohe Weihnachten!

Assembler Module mit CMake

2021-12-19T12:00:00+01:00

So wie es in Star Trek heißt

Space, the final frontier.

so heißt es dann auch gerne in der Software-Entwicklung:

Assembler, the final frontier.

Bleibt nur die Frage offen, wie man diese letzte Grenze dann auch in CMake überwindet.

Das GATE Projekt soll eigentlich frei von Hardware-Spezialitäten sein, lediglich die “notwendigen” OS APIs der wichtigsten Hersteller sollen gesammelt und abstrahiert werden.
Assembler Codes haben da keinen Platz und sind auch in anderen Libs wie OpenSSL / libreSSL usw. bewusst abgeschaltet.

Eine kleine Ausnahme gibt es, wenn es um die CPU-ID geht, die man mit Inline-Assembler auslesen kann … aber schon da gibt es das typische MSVC X64 Problem, dass dort nämlich kein Inline-Assembler unterstützt wird.

Mit der EFI Plattform gibt es nun aber einen Sonderfall, wo es um den Nachbau von C-APIs geht, namentlich setjmp() und longjmp().

Diese Funktionen lassen sich nicht mit reinem C nachbauen. Doch diese sind in der gnuefi Bibliothek als .s Assembler Dateien beigelegt.

Blöd ist nur, dass ich primär unter Windows mit dem MSVC arbeite, wo mir erstens die .s Dateien nichts bringen und zweitens CMake diese Dateien nicht automatisch mitbaut.

GNU Assembler Support für CMake

Im Netz findet man schnell die Info, dass man ASM als Sprache im CMake Projekt angeben soll, also z.B.
project(my_project C ASM)

Dann werden noch *.s Dateien hinzugefügt und man erhält:

 1 project(my_project C ASM)
 2
 3 file(GLOB MY_ASM_SOURCES
 4   "path/to/*.s"
 5 )
 6 file(GLOB MY_C_SOURCES
 7   "path/to/*.c"
 8 )
 9 
10 add_library(my_project
11   ${MY_ASM_SOURCES}
12   ${MY_C_SOURCES}
13 )

CMake generiert dann Make-Files, die die .s Assembler Dateien kompilieren und zur Zielbibliothek (oder Executable) hinzufügen.

MSVC Assembler Support für CMake

In Visual Studio kann man manuell den MASM Support aktivieren, in dem man das Projekt auswählt, und dann unter Project - Build Customizations klickt und dort die masm Zeile anhakt. Ab dann werden alle .asm Dateien an den Assembler Compiler weitergereicht.

Für CMake gibt es beim MSVC einen eigenen MASM Token, der da lautet:
ASM_MASM.

Somit muss man nur noch die unter DOS und Windows üblichen .asm Dateien in CMakeLists.txt aufnehmen:

 1 project(my_project C ASM_MASM)
 2
 3 file(GLOB MY_ASM_SOURCES
 4   "path/to/*.asm"
 5 )
 6 file(GLOB MY_C_SOURCES
 7   "path/to/*.c"
 8 )
 9 
10 add_library(my_project
11   ${MY_ASM_SOURCES}
12   ${MY_C_SOURCES}
13 )

MASM Funktionen für C schreiben

Nun beginnt für mich der harte Kampf die AT&T Assemblercodes nach MASM zu portieren. Denn da der AT&T Syntax bei GNU und GCC vorherrscht und auch die setjmp() und longjmp() Codes der gnu-efi Bibliothek so geschrieben sind, müssen fast alle Codezeilen “umgedreht” werden, damit sie MASM-tauglich werden.

Warum MASM ein Operator Ziel, Quell Schema verfolgt und AT&T umgekehrt Operator Quelle, Ziel nutzt und es da keinen Standard gibt, stört mich damals wie heute.

So sehen jedenfalls meine vorläufigen Bemühungen aus:

 1.CODE
 2
 3PUBLIC _setjmp
 4
 5_setjmp PROC
 6  ; RCX hold pointer to jmp_buf 
 7  pop rdx   ; RET address
 8  push rdx
 9  mov rax, 0
10  mov [rcx + 00h], rsp  ; Frame
11  mov [rcx + 08h], rbx                
12  mov [rcx + 10h], rsp
13  mov [rcx + 18h], rbp
14  mov [rcx + 20h], rsi
15  mov [rcx + 28h], rdi
16  mov [rcx + 30h], r12
17  mov [rcx + 38h], r13
18  mov [rcx + 40h], r14
19  mov [rcx + 48h], r15
20  mov [rcx + 50h], rdx ; RIP
21  ; currently, skip following fields in jmp_buf
22  ret
23_setjmp ENDP
24
25PUBLIC longjmp
26
27longjmp PROC
28  mov rbx, [rcx + 08h]
29  mov rsp, [rcx + 10h]
30  mov rbp, [rcx + 18h]
31  mov rsi, [rcx + 20h]
32  mov rdi, [rcx + 28h]
33  mov r12, [rcx + 30h]
34  mov r13, [rcx + 38h]
35  mov r14, [rcx + 40h]
36  mov r15, [rcx + 48h]
37
38  mov r8, [rcx + 50h] ; RIP
39
40  mov eax, edx
41  and rax, 0ffffffffh
42  cmp eax, 0
43  jne longjmp_exit
44  mov eax, 1
45longjmp_exit:
46  jmp r8
47longjmp ENDP

Fazit

Der erste Schritt ist also getan. Die in Assembler implementierten setjmp() und longjmp() Symbole erlauben mir nun weitere Bibliotheken wie LUA oder libjpeg auch für native EFI-Apps zu nutzen.

Das Potential ist aber weit größer.
Denn mit Assembler-Fragmenten kann ich nun auch zu anderen Stacks springen und z.B. Koroutinen ohne OS-Support implementieren.

Aber … bis das lauffähig sein wird, vergeht vermutlich noch einige Zeit.

Wie CONAN OpenSSL sprengt

2021-12-18T12:00:00+01:00

Manche Geschichten aus dem Programmierer-Alltag sind so kurios, dass sie es verdienen dokumentiert zu werden.

Und eine davon ist die Geschichte vom CONAN Build-Pfad, der das Compilieren von OpenSSL gebrochen hat.

Mit OpenSSL verbindet mich eine emotionale Hassliebe. Einerseits war diese Bibliothek früher die einzige und gleichsam beste Möglichkeit, Kryptographie von SSL bis TLS in sein Projekt zu bekommen und andererseits hat OpenSSL das aus meiner bescheuertste Build-System überhaupt.

Denn wenn man für ein Projekt in Programmiersprache A (also C) eine Hilfssprache B braucht (also Perl), dann läuft etwas gehörig schief.
Der Nachfolger libreSSL beweist außerdem, dass es auch ohne solche Kunstgriffe geht, und man nicht per Perl-Script alle Header anpassen muss.

Neulich in der Firma …

Eine neue Buildplattform kam hinzu und damit mussten diverse 3rd-Party-Libs eben für diese Plattform neu gebaut werden.
Da gibt es immer wieder ein paar Problemchen, die man mit diversen Tricks, Compilerswitches und Environment-Variablen lösen muss.

Doch beim Bauen einer statischen Version von OpenSSL unter Windows trat plötzlich folgender Fehler auf:

1 .\crypto\cversion.c(82): warning C4129: 'c': unrecognized character escape sequence
2 .\crypto\cversion.c(82): error C2022: '289': too big for character
3 .\crypto\cversion.c(82): warning C4129: 'i': unrecognized character escape sequence

Und was steht in Zeile 82 ?

 1 const char *SSLeay_version(int t)
 2 {
 3   ...
 4   if (t == SSLEAY_CFLAGS) {
 5 #ifdef CFLAGS
 6     return (CFLAGS);    /* <-- line 82 */
 7 #else
 8     return ("compiler: information not available");
 9 #endif
10   }
11   ...
12 }

Und CFLAGS sollte die Compiler-Switches enthalten, die zum Bauen des Projektes benutzt werden.

Jetzt gibt es zahlreiche andere Pipelines, die nie ein Problem mit dem Code hatten, also warum schlägt das plötzlich bei einer einzelnen Pipeline fehlt?

Vorsicht mit Windows Dateisystempfaden!

Der Compiler-Aufruf beinhaltet neben zahlreichen Steuer-Makros wie -DOPENSSL_NO_SSL2, -DSHA1_ASM usw. auch den Parameter
-IC:\conan_cache\441b83\1\include

Und dabei handelt es sich um den Include-Pfad einer CONAN-Abhängigkeit, dessen Unterverzeichnis durch einen Hash von CONAN generiert wird.

Tja … und ein \c von \conan_cache und \i von \include erklären die Warnungen, die ich bei weiterer Analyse auch in anderen Windows-Builds finden konnte.

Aber \441b83 ist ein lustiger Zufall, denn Backslash + 3-Ziffern sind in C eine Oktalzahl und \441 wird im Dezimalsystem dann zur 289.
Und 289 ist wiederum für ein Byte zu viel (weil größer 255) und so erklärt sich dann auch der Fehler mit dem String, der den Build abbricht.

Da die CONAN Hashes für die Builds einen quasi zufälligen Charakter haben, hatten wir bei den anderen Build-Pipelines einfach Glück und die erzeugten Strings hatten einfach “lustige” Zeichen in sich und generierten weitere Warnungen, doch wenn der Hash mit der Ziffer 4 beginnt und zwei weitere Ziffern folgen, hört der Spaß beim C-Compiler auf.

Lösung: CFLAGS unter Windows ausblenden

Ich passe nur ungern 3rd-Party Codes an, aber um das Problem “schnell” aus dem Weg zur räumen, habe ich einfach ein lokales Patch-File erstellt, welches die Zeilen:

1 #if defined(WIN32) && defined(CFLAGS)
2 #  undef CFLAGS
3 #endif

implantiert.
Denn schließlich kann in jeder künftigen CONAN basierten Pipeline wieder so ein lustiges Hash-Unterverzeichnis entstehen. Und ungewollte Backslashes in Strings aus dem Dateisystem sind hier generell ein Problem.

Meines Erachtens wird diese Versions-API nirgends produktiv “benutzt”, sie dient nur der Rückverfolgung des Bauprozesses der Bibliothek.

Fazit

What - the - fu** …

Nach unzähligen Jahren in der Softwareentwicklung vergeht kein Jahr, wo mir nicht wieder zig neue Varianten von Build-Systemen unterkommen, die durch Seiteneffekte den Quellcode vernudeln können.
CONAN Builds unter Windows, deren Dateipfade in Strings ins Programm geprägt werden, sind also wieder “so eine Abart”, die ich in Zukunft zu meiden versuchen werde.

Nun … ich muss sie bei meinen Codes nicht meiden, weil ich auch noch nie CFLAGS als String wo aufgenommen hätte. Aber ich werde nun bei weiteren Bibliotheken aus dem Unix Umfeld genauer aufpassen, dass sie keinen Schaden anrichten, wenn sie in Windows übernommen werden.

Denn, wer weiß schon, ob nicht irgend wo anders schon mal ein \0 aus einem Dateipfad in einem Codefragment “versehentlich” eine Backdoor aufgemacht hat, wenn ein std::string::size() dann plötzlich was anderes zurückgibt, als ein strlen() auf den gleichen char Puffer ….

Und die Moral von der Geschicht’:
CONAN Pfade speichern darf man nicht!

Dark-Mode für Win32 im Menü

2021-12-12T12:00:00+01:00

Nachdem mich die Sache mit dem halbherzigen Dark-Mode für Win32 Apps nicht mehr gut schlafen lässt, habe ich gezielt nach Möglichkeiten gesucht, weitere UI Elemente schwarz zu färben.

Einer der störrischen Kandidaten ist die Windows Menüzeile, die durch einige nicht-offizielle APIs beeinflusst werden kann.

UI Control lassen sich oft durch bestimmte Fensternachrichten dazu bringen, “ihre Selbstdarstellung” abzuändern. “Owner-Drawn” ist eines der Schlüsselworte hierfür, und so kann man sich im Notfall fast alle Controls so “hinpatchen”, dass sie zum dunklen Design passen.

Die Windows Menüzeile ist aber so ein ganz spezieller Sonderfall, der nicht von den regulären dokumentierten Nachrichten beeinflusst werden kann.

Eine geniale Zusammenfassung dazu hat github.com/adzm/win32-custom-menubar-aero-theme veröffentlicht, und eben diese Methode setze ich nun auch ein. Und da der Beispielcode so etwas von selbsterklärend ist, brauche ich das hier nicht nochmal durchkauen.

In UAHMenuBar.h findet man die speziellen Fensternachrichten und die struct Deklarationen, in denen zusätzlich Daten gespeichert sind.

Und in UAHMenuBar.cpp wird demonstriert, wie man in der Nachricht WM_UAHDRAWMENUITEM einen Menü-Eintrag selbst kolorieren kann.

Mein Anpassung besteht nun nur noch aus der Abfrage, ob der Dark-Mode aktiviert ist. Wenn dem so ist, sollen die Fensternachrichten alles selbst zeichnen und dafür Dark-Mode-konforme Farben nutzen. Ohne Dark-Mode wird einfach die DefWindowProc aufgerufen

Eine wichtige Frage ist noch:

Wo bekommt man die korrekten Farbinformationen her?

Nun, meine Versuche mit UxGetImmersiveColorTypeFromName() brachten keine guten Ergebnisse.
Mir fehlt ein Mapping von “Menü-Hintergrundfarbe” auf einen ImmersiveXYZ Theme-Color-Namen und alles, was sich “vernünftig” anhörte hat leider nicht gepasst.

Von daher ist meine vorläufige Strategie, die aktuellen Dark-Mode Farben aus einem Explorer-Screen-Shot zu extrahieren und die RGB-Werte hard-coded aufzunehmen.

Das gefällt mir zwar nicht wirklich, aber es ist zumindest eine vorläufige Lösung.

Fazit

Ich bleibe dabei:

Microsoft hätte einfach bei der Anwendung des Explorer oder DarkMode_Explorer Theme-Namens per UxSetWindowTheme() die Controls dunkel zeichnen sollen.

Dann wären uns solche Hacks erspart geblieben.

However… bis ich mit der Dark-Mode Sache zufrieden bin, werden wohl noch einige Code-Änderungen durchs Land ziehen.

Obwohl ich den Menü-Code im Zuge des GATE Frameworks nun ausprobiert habe, werde ich diese Stellen nur optional in ein Kompilat fließen lassen.
Denn da diese Nachrichten nicht dokumentiert sind und mit Zeigern auf private Strukturen gearbeitet wird, ist nicht auszuschließen, dass der Code dann beim nächsten Windows Release zu Crashes führt.

Eine mögliche Lösung wäre natürlich, den Code per Registry-Key aktiveren und deaktivieren zu können.

Na, mal sehen, für was ich mich am Ende entscheiden werde ….

POCO M3 Pro

2021-12-11T12:00:00+01:00

Nein, nein, nein! Ich gebe mein Lumia 950 Windows Phone nicht auf. Es funktioniert super und das bleibt auch so.

Aber … auch mir bleibt nicht erspart, dass die Welt eine andere Richtung eingeschlagen hat, und deshalb musste ich mir jetzt auch wieder mal ein Android Telefon kaufen.

Und meine Wahl ist auf ein Poco M3 gefallen.

Typisch Android

Kurz gesagt, das Smartphone ist genau so ein Dreck, wie ich es von einem Android Gerät erwartet hatte.
Über zwei Stunden war ich damit beschäftigt, sinnlose Apps, Werbung-verseuchte Spiele und Vollzugriffsrechte zu entfernen.

Das war schon bei meinem Sony Xperia XA2 vor 3 Jahren ein Krampf und die Kontaminierung des Betriebssystems und der Apps mit Online-Diensten ist leider noch viel schlimmer geworden.

Ich konnte aber durch die manuelle Installation von APKs einen Teil des Google-Drecks umgehen und somit ein halbwegs benutzbares Telefon zu erhalten.
apkpure.com ermöglichte mir den Download der notwendigen Software ohne Google-Play, das ohne Online-Account gar nicht mehr benutzt werden kann.

Selbst Microsoft lässt den Anwender kostenlose Apps ohne Online-Accounts installieren und ich verstehe nicht, warum man Google nicht auch zu einer solchen Prozedur zwingen kann.

Tolle Hardware

Wenn man von diesem Abschaum von Android 11 Betriebssystem absieht, ist das Poco M3 Pro ein gutes Gerät. Die Bedienung ist flüssig und nachdem ich ohnehin keine Spielchen auf dem Telefon laufen lassen werde, kann ich mir nicht vorstellen, an die Leistungsgrenzen zu stoßen.

Schöne Bilder macht auch die Kamera. In der Standardeinstellung werden 12 Megapixel (2992 x 4000) in einem Bild untergebracht. Das ist tatsächlich weniger, als die 20 Megapixel (3008 x 5344) meines Lumia 950, doch wenn ich mein Mainboard bei schlechter Zimmerbeleuchtung abfotografiere, sieht man bereits, dass das POCO M3 Pro eine etwas bessere Qualität bei den Farben produzieren kann.

Man kann auch auf 48 MegaPixel hochschalten, aber hilfreich ist das nicht. Man erhält dann zwar mit 6000 x 8000 Pixel eine 4-mal so große Datei (13 MB statt 3.5 MB), doch das Bild ist weder schärfer noch qualitativ besser. Vielleicht hilft einem der Modus für Naturaufnahmen, aber mein Mainboard sieht exakt gleich aus, es sind quasi nur die Pixel verdoppelt worden und das ganze sieht dann auch ziemlich künstlich und berechnet aus.

Mit 5000 Milliamperestunden habe ich einen frischen Akku, der mein Lumia 950 um Längen überholen kann. Denn während dem Windows Phone auch im Leerlauf nach zwei Tagen der Saft ausgeht, schafft es das POCO Phone in 2 Tagen nur etwa ein Drittel des Akkus aufzubrauchen.

Natürlich ist der neue Akku mit dem 4 Jahre alten kaum zu vergleichen und vielleicht werde ich auch dem Windows Phone noch mal einen Ersatzakku besorgen, aber meine Befürchtung, dass das neue M3 keine 2 Tage übersteht, waren unbegründet.

Fazit

Mein Sony Xperia ist fast 4 Jahre lang nur am Schreibtisch gelegen und eine SIM-Karte hat das Gerät nie kennenlernen dürfen. Es war eben nur ein Testsystem für Android-Codes.

Das Poco M3 wird voraussichtlich mein künftiges Standard-Telefon werden, und aktuell nutze ich es mit meiner Zweit-Sim-Karte zum Experimentieren. Denn irgendwann werden auch die E-Mail Dienste meines Lumia 950 wegen Zertifikaten und anderen Problemchen nicht mehr ordentlich laufen und dann ist diese Ära endgültig vorbei.

Lieber wäre es mir gewesen, mein PinePhone als Hauptgerät zu nutzen, doch trotz der guten werbefreien Software, hat es extrem schlechte Lautsprecher, was es für unterwegs leider untauglich macht.

Ich sollte jetzt eigentlich glücklich mit meinem neuen Gerät sein … aber der elende verseuchte Android-Scheißhaufen hat mir die Freude gehörig vernichtet.
Es ist für mich einfach unfassbar, dass ein Großteil der Menschheit diesen Mist freiwillig einsetzt und dieser digitalen Datenversklavung bedenkenlos zustimmt.

Nachtrag

Nur noch ein Wort zu Android:
Es ist nicht so, dass ich das gesamte Android-Konzept verteufele. Mich treibt nur zur Weißglut, dass Apps für dieses System eine absolute Abhängigkeit zu Google-Diensten haben. Und das stört mich eben enorm.

Und wer einmal den Datenverkehr seines Routers mitverfolgt hat, weiß, wie viele Daten diese Geräte abstrahlen. Windows ist hier auch kein Engel, aber gegen Google ist das nichts … … und niemand tut was dagegen. Es ist einfach furchtbar!

EFI Shell mit QEMU

2021-12-05T12:00:00+01:00

Wenn man EFI Apps entwickelt, möchte man sie natürlich auch testen. Natürlich kann man jedes neue .efi Binary auf einen USB-Stick kopieren und auf einem realen PC über die EFI-Shell ausführen, aber “effizient” ist das nicht.

Der Emulator QEMU bietet mit dem TianoCore OVMF (Open Virtual Machine Firmware) Paket die Möglichkeit, eine EFI Shell Sitzung oder eine EFI-Boot auf dem lokalen System schnell nachzustellen.

Um eine fertige .efi x64-App-Datei schnell testen zu können, braucht man folgende Zutaten:

Eine QEMU Installation mit dem qemu-system-x86_64 Emulator
Eine Firmware-Datei mit EFI-Shell Support wie z.B. in OVMF.fd
Die Linux mtools um per Script ein virtuelles USB-Stick-Image zu basteln
Und ein Script, welches alle Aufrufe zusammenfasst.

QEMU

Den System Emulator QEMU findet man auf qemu.org zum Download, aber als OpenSource-Projekt kann man ihn auch direkt aus den Quellcodes bauen lassen.

Am einfachsten läuft die Installation jedoch über das Paketmanagement des Betriebssystems:

Windows: winget install SoftwareFreedomConservancy.QEMU
Debian / Ubuntu: sudo apt install qemu

TianoCore Open Virtual Machine Firmware (OVMF)

Eigentlich brauchen wir nur eine Datei namens OVMF.fd, die aus dem TianoCore Projekt heraus gebildet wurde, damit wir eine virtuelle Maschine starten können, die von einem virtuellen USB Stick aus unsere App als BOOTX64.EFI startet.

Entweder sucht man sich dafür in den Weiten des Internet eine OVMF.fd, oder man klont sich das TianoCore GIT Projekt und startet dessen Build-Prozess.

Eine hervorragende Anleitung dazu, die auch bei mir unter Windows in WSL (Ubuntu 18.04) funktioniert hat, findet man unter
fabianlee.org/2018/09/12/kvm-building-the-latest-ovmf-firmware-for-virtual-machines/

Hier die Kommandos, die ich erfolgreich ausführen konnte:

 1## script from fabianlee.org:
 2sudo apt-get install build-essential git uuid-dev iasl nasm python -y
 3sudo apt-get install iasl -y
 4mkdir -p uuefi; cd uuefi
 5git clone git://github.com/tianocore/edk2.git
 6cd edk2
 7git submodule update --init
 8source ./edksetup.sh
 9make -C BaseTools/
10build -a X64 -t GCC5 -b RELEASE -p OvmfPkg/OvmfPkgX64.dsc

Nach dem Durchlaufen der Build-Prozesse findet man unter Build/OvmfX64/RELEASE_GCC5/FV/OVMF.fd die Firmware-Datei, mit der man QEMU zur Ausführung von EFI-Apps bringen kann.

USB-Stack FAT Image mit mtools

EFI braucht am Ende einen Datenträger, von dem gebootet werden kann. Natürlich könnte man jetzt einen richtigen USB-Stick formatieren und die Dateien einspielen und dann ein binäres Image davon ziehen, aber das wäre extrem mühsam.

Linux liefert aber mit den mtools einige sehr nützlich Programme mit, die Dateisysteme “offline” bearbeiten können, und wie üblich ist es dabei egal, ob es um reale Datenträger, oder nur Image-Dateien geht.

EFI erwartet eine FAT Partition, in der im Unterverzeichnis /EFI/BOOT die Datei BOOTX64.EFI liegt.
Ein schönes Beispiel findet man auf
wiki.osdev.org/UEFI_App_Bare_Bones

Nachdem ich mit Windows und WSL arbeite, müssen die mtools mit sudo apt install mtools zuvor installiert sein. Danach kann man folgendes BATCH Script nutzen:

1COPY path\to\built\efi-app.efi BOOTX64.EFI
2wsl dd if=/dev/zero of=./efi-boot.img bs=1k count=2880
3wsl mformat -i ./efi-boot.img -f 2880 ::
4wsl mmd -i ./efi-boot.img ::/EFI
5wsl mmd -i ./efi-boot.img ::/EFI/BOOT
6wsl mcopy -i ./efi-boot.img ./BOOTX64.EFI ::/EFI/BOOT

In efi-boot.img liegt dann ein Disketten-FAT-Image (hier mit 2.88 MB), in welches die EFI-App als BOOTX64.EFI integriert ist. EFI-Apps sind ja normalerweise nicht mehrere Megabytes groß, womit das kleine Laufwerk reicht. Wer mehr will, kann natürlich auch ganze virtuelle Festplatten mit GUID-Partitionstabelle und einer eigenen EFI-Partition anlegen.

Da das wsl Kommando die Linux-Prozesse so startet, dass das Arbeitsverzeichnis in WSL auf das Windows-Dateisystem zeigt, schreiben die mtools die Dateien in das Verzeichnis, in dem das BATCH Script ausgeführt wurde.

QEMU mit EFI-Firmware und Image starten

Das finale magische Kommando lautet:

qemu-system-x86_64 -L OVMF_dir/ -pflash OVMF.fd -drive if=none,id=stick,format=raw,file=efi-boot.img -device nec-usb-xhci,id=xhci -device usb-storage,bus=xhci.0,drive=stick

Wichtig ist, dass die QEMU Programme im PATH liegen und dass sowohl OVMF.fd und efi-boot.img (oder wie auch immer man die Dateien nennen möchte) über die qemu-system-x86_64 Parameter erreichbar sind.

Dann öffnet sich nämlich das Emulator-Fenster und wenn die eigene EFI-App richtig erstellt wurde, kann man ihren Output am Bildschirm sehen und daran Freude haben.

Ich habe mir daher meine gebaute OVMF.fd fix zum Projekt hinzugefügt und lasse eine von MSVC fertig gebaute EFI APP mit folgendem Script bei mir ausführen:

 1@ECHO OFF
 2REM Starting in "\scripts"
 3cd ..\bin
 4REM Cleanup output directory
 5rmdir /s /q efi_x64_env
 6mkdir efi_x64_env
 7REM Create EFI boot image
 8copy ..\build\msbuild_efi64\deploy\bin\Release\gatecli.efi ^
 9  .\efi_x64_env\BOOTX64.EFI
10wsl dd if=/dev/zero of=./efi_x64_env/efi-boot.img bs=1k count=2880
11wsl mformat -i ./efi_x64_env/efi-boot.img -f 2880 ::
12wsl mmd -i ./efi_x64_env/efi-boot.img ::/EFI
13wsl mmd -i ./efi_x64_env/efi-boot.img ::/EFI/BOOT
14wsl mcopy -i ./efi_x64_env/efi-boot.img ^
15  ./efi_x64_env/BOOTX64.EFI ::/EFI/BOOT
16REM Start QEMU session
17SET PATH=C:\Program Files\qemu;%PATH%
18qemu-system-x86_64 ^
19  -L OVMF_dir/ -pflash OVMF.fd -drive ^
20  if=none,id=stick,format=raw,file=.\efi_x64_env\efi-boot.img ^
21  -device nec-usb-xhci,id=xhci ^
22  -device usb-storage,bus=xhci.0,drive=stick

Fazit

Meine ersten Experimente waren echt mühsam. Jedes Kompilat wurde manuell auf einen USB-Stick kopiert und dann wurde ein Test-Mainboard damit gestartet.

Mit QEMU und mtools lässt sich eine EFI-App binnen Sekunden in einer virtuellen Umgebung testen und das ist einfach nur geil!

Mit diesem Werkzeug werde ich also noch einige Zeit verbringen.

Generische Sinus und Cosinus Implementierung

2021-12-04T12:00:00+01:00

Normalerweise verlässt man sich auf die C Standard Bibliothek, wenn man etwas Trigonometrisches braucht.

Aber was tut man, wenn man diese nicht parat hat, wie in einer nativen EFI App, und auch kein Inline-Assembler vom Compiler unterstützt wird.

Oft ist es einfach wichtig, den richtigen Begriff zu kennen und den Rest erledigt die Suchmaschine des Vertrauens.
Und da war doch was in der Mathe-Vorlesung zur Analysis:

Die Taylor-Reihe

Wenn wir von einer Funktion immer Ableitungen bilden und diese nach dem Taylorschein Lehrsatz aufsummieren, erhält man abstrakt:

1f(x) = f(x0) 
2     + f1(x0) * (x - x0) ^ 1 / 1! 
3     + f2(x0) * (x - x0) ^ 2 / 2!
4     + ...
5     + fn(x0) * (x - x0) ^ n / n!

Und nachdem die Ableitungen von Sinus und Kosinus sich mit alternierendem Vorzeichen abwechseln (cos, -sin, -cos, sin, cos, …) und sin(0) == 0 und cos(0) == 1 ist, haben wir in Schule folgende alternierende Annäherung kennen gelernt:

1sin(x) = 0 + x^1 / 1! - x^3 / 3! + x^5 / 5! - x^7 / 7! + ...
2cos(x) = 1 - x^2 / 2! + x^4 / 4! - x^6 / 6! + x^8 / 8! - ...

Zumindest, wenn x ein Winkel in Radianten zwischen -PI und +PI ist.

Die Taylor-Reihe wird um so genauer, je länger sie ist. Mathematiker können zeigen, dass wir nur ein paar Iterationen brauchen, um ausreichend genau zu sein, damit wir damit ein bisschen rechnen können. Siehe dotancohen.com/eng/taylor-sine.php.

Nachdem ich bei meinen Unit-Tests Genauigkeiten von mindestens 4 Nachkommastellen haben wollte, musste ich die Iterationen bis zu x^13 erweitern.

Sinus und Cosinus selbst implementieren

Wenn in Embedded Plattformen was fehlt, dann fast alles. Und nachdem man sein eigenes malloc und free nachgebaut hat, folgen die mathematischen Funktionen gänzlich ohne math.h.
Aber, ein Code sagt mehr als 1000 Worte:

 1static double const pi = 3.14159265358979323846;
 2
 3static double normalize(double angle)
 4{
 5  while(angle <= pi) angle += pi;
 6  while(angle > pi) angle -= pi;
 7  return angle;
 8}
 9
10static double const n2 = 2.0;
11static double const n3 = 6.0;
12static double const n4 = 24.0;
13static double const n5 = 120.0;
14static double const n6 = 720.0;
15static double const n7 = 5040.0;
16static double const n8 = 40320.0;
17static double const n9 = 362880.0;
18static double const n10 = 3628800.0;
19static double const n11 = 39916800.0;
20static double const n12 = 479001600.0;
21static double const n13 = 6227020800.0;
22
23double approx_cos(double value)
24{
25  double const x = normalize(value);
26  double const x3 = x * x * x;
27  double const x5 = x3 * x * x;
28  double const x7 = x5 * x * x;
29  double const x9 = x7 * x * x;
30  double const x11 = x9 * x * x;
31  double const x13 = x11 * x * x;
32  return x - x3 / n3 + x5 / n5 - x7 / n7 
33       + x9 / n9 - x11 / n11 + x13 / n13;
34}
35
36double approx_sin(double value)
37{
38  double const x = normalize(value);
39  double const x2 = x * x;
40  double const x4 = x2 * x * x;
41  double const x6 = x4 * x * x;
42  double const x8 = x6 * x * x;
43  double const x10 = x8 * x * x;
44  double const x12 = x10 * x * x;
45  return 1 - x2 / n2 + x4 / n4 - x6 / n6 
46       + x8 / n8 - x10 / n10 + x12 / n12;
47}
48
49double approx_tan(double value)
50{
51  return approx_sin(value) / approx_cos(value);
52}

So in etwa sieht der Kompatibilitäts-Layer im GATE Projekt aus, der genau für solche Spezialfälle aktiviert werden kann. (z.B. bei EFI Apps.)

Für den Arkussinus gibt es ebenfalls eine Reihenentwicklung und der Arkuskosinus sollte mit acos(x) = PI / 2.0 - asin(x) erreicht werden können.

Wenn nötig, kann man dann auch die “echten” C Funktionen so nachbauen, und genau das musste ich tun, um diverse Fremdbibliotheken durch den Linker zu bekommen.

Fazit

Wenn man “normale” Bibliotheken in diverse embedded Umgebungen einpflanzen möchte, passiert es, dass es keine C-Lib Implementierung gibt. Und dann tauchen zahlreiche “undefinierte Symbole” beim Linken auf.
Und das kann auch sin(), cos() und ihre Geschwister treffen.

Genau dafür ist es gut, dass man eine primitive Implementierung parat hat, damit man fortsetzen kann.
Selbstverständlich sollte immer eine ordentliche Mathematik-Bibliothek im finalen Kompilat landen, die auf die Plattform optimiert ist.

… doch leider ist das eben nicht immer möglich.

UEFI Apps erstellen

2021-11-28T12:00:00+01:00

Der Traum meiner Kindheit rückt wieder näher: “Mein eigenes OS”

Vor etwas über 20 Jahren hatten einige Idealisten wie ich noch die Idee, mit BIOS Interrupts und ein paar Assemblerzeilen Programme zu schreiben, die kein OS brauchten und direkt von der Diskette booten konnten.

Heute ist die Sache viel einfacher, denn heute haben wir UEFI.

Viele Sicherheitsprobleme entstehen auf Grund der Komplexität von modernen Betriebssystemen. Ein offener Webserver Port lässt dann über eine ungenutzte Zusatzfunktion Viren hereinströmen, wo man sich immer fragt:

Wieso war diese Funktion überhaupt da?

Und dann haben wir Mikrocontroller wie den ESP32, der von solchen Problemen zwar nicht grundsätzlich verschont ist, der aber trotzdem einfache Dienst anbieten kann, die eben nicht durch Trillionen von Seiteneffekten kontaminiert werden.

Warum haben wir das nicht auch auf der PC Plattform?

EFI Apps als Lösung

Das Extensible Firmware Interface ist mehr als nur ein neues BIOS, denn es stellt eine wesentlich breitere Menge an Diensten bereit, als das alte BIOS, das lediglich einen Textbildschirm, eine Tastatur, Disketten und max. 8 GB Festplatten ansprechen konnte.

Es fügt nämlich Netzwerke, TCP, UDP, serielle Ports und Dateisysteme hinzu und damit haben wir eine Basis, mit der man ganz ohne ein Betriebssystem Code ausführen kann.
Man kompiliert sich ein EFI-Binary, packt es auf einen USB-Stick, bootet in die EFI-Shell, wechselt auf den USB-Datenträger und führt die Datei aus.
Und liegt die Datei im “richtigen” Verzeichnis, wird sie vom EFI Bootloader automatisch gestartet.

GNU-EFI und der MSVC

Das Projekt GNU-EFI liefert alle notwendigen Header und statischen Code, um primitive EFI-Anwendungen programmieren zu können.
Während die meisten Beispiele im Netz dazu für Linux bzw. den GCC ausgelegt sind, unterstützt auch Microsoft’s MSVC das EFI-Format als Zielplattform und mit ein paar Anpassungen, kann er gnu-efi auch benutzen.

Das ist auch kein Wunder, schließlich hat Microsoft den EFI-Standard mitdefiniert und dabei das unter Windows übliche PE-Format in EFI etabliert.

Man braucht also nur vom Subsystem WINDOWS bzw. CONSOLE zu EFI_APPLICATION wechseln und kann loslegen.
… allerdings muss man sich dafür von der C-Runtime und vielen hilfreichen Funktionen angefangen bei malloc() verabschieden.
Und C++ muss auch weichen … außer man hat eine Strategie für C++ ohne Exceptions und RTTI, was schwierig aber nicht gänzlich unmöglich ist.

CMake EFI Einstellungen für MSVC

Folgende Compiler Flags sind für EFI hilfreich und können in CMake definiert werden:
(Die C-Flags sind auch für C++ notwendig unter CMAKE_CXX_FLAGS)

string (REPLACE "/DWIN32" "" CMAKE_C_FLAGS ${CMAKE_C_FLAGS})
Das WIN32 Symbol sollte verschwinden, damit keine Makros davon irritiert werden.
string (REPLACE "/D_WINDOWS" "" CMAKE_C_FLAGS ${CMAKE_C_FLAGS})
Auch das automatisch generierte _WINDOWS Symbol sollte weg.
string (REPLACE "/EHsc" "" CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS})
string (REPLACE "/EHs" "" CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS})
string (REPLACE "/EHa" "" CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS})
C++ muss auf jegliche Art von Exceptions verzichten.
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} /Gm-")
Einstellung: Enable Minimal Rebuild sollte deaktiviert sein.
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} /GS-")
Security Checks müssen deaktiviert sein, weil sie auf die C-Runtime verweisen.
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} /GR-")
Run-Time Type Information (RTTI) braucht auch eine Runtime, die wir unter EFI nicht haben
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} /TC")
Die Option “Compile As: Compile As C Code” hilft bei nur-C Projekten
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} /Gs16384")
Diese Geheimoption lässt alle Stackvariablen 16 KB statt nur 4 KB groß sein.

Die nachfolgenden Linker-Flags sind ganz besonders wichtig:

set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} /NODEFAULTLIB")
Die C-Runtime und alle anderen Windows-Lasten werden nicht automatisch gelinkt
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} /MANIFEST:NO")
Ein Windows-Manifest braucht man in EFI auch nicht.
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} /SUBSYSTEM:EFI_APPLICATION")
Und ohne dem EFI-Subsystem bekommen wir sowieso keine EFI App heraus.
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} /OPT:REF")
Nicht benutzte Funktionen im Code sollen weg-optimiert werden.
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} /ENTRY:efi_main")
Wir setzen explizit einen anderen Einsprungpunkt namens efi_main.
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} /NXCOMPAT:NO")
Auf die Data Execution Protection wollen wir uns auch nicht berufen.
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} /DYNAMICBASE:NO")
Und zufällige Adressen (als Schutz gegen Windows-Viren) sind unter EFI ebenfalls nicht notwendig bzw. nicht möglich.

Man kann jetzt noch weitere Wichteleien anfügen, wie dass .efi und nicht .exe am Ende herauskommt … aber die genannten Einstellungen sollten für den Kompilier- und Link-Vorgang ausreichen, damit man das erste Testprojekt bauen kann.

Die gnu-efi Bibliothek (und auch alle anderen Libs) müssen natürlich statisch zur EFI-App gelinkt werden. (Soetwas wie DLLs gibt es in EFI-Apps nicht.)

Runtime und Stack-Spezialitäten

Nachdem keine C-Runtime vorhanden ist, fallen Funktionen für Trigonometrie und Rundungen weg. Das schränkt den Handlungsspielraum ein und man müsste diese Routinen per Assembler oder C selbst nachbauen, wenn man andere C Libs nutzen möchte, die darauf verweisen.

malloc und free sind vermutlich die wichtigsten Utensilien, doch zum Glück stellt EFI mit seinen “BootServices” auch einfache Blockallokierungs- Routinen bereit, die man als malloc Ersatz nutzen kann.

Erste Link-Test liefern gerne Fehler, wie

error LNK2019: unresolved external symbol __chkstk
error LNK2019: unresolved external symbol __fltused

_chkstk ist ein interessanter Funktionsaufruf, den der Compiler automatisch einfügt, wenn ein Stackframe über 4 KB groß wird. Der Aufruf soll unter Windows eine Memory-Exception auflösen, wenn der aktuell allokierte Stack ausgeht, worauf das OS den Stack nach Möglichkeit vergrößert.
Und nachdem _chkstk in der C Runtime implementiert ist, fehlt sie unter EFI. Ich weiß nicht, wieviel Stack in EFI generell zur Verfügung steht, aber das Compilerflag /Gs16384 erhöht die Toleranzgrenze auf 16 KB … und man könnte es noch höher drehen.

_fltused ist eine andere globale CRT Variable in Bezug auf Fließkommarechnungen, die im MSVC offenbar darauf zugreifen wollen. Ein “schneller Fix” dafür ist einfach ein:

1extern int _fltused = 0;

womit wir die Variable formal im Programm haben. (Ich fürchte aber, dass diverse weitere Fließkomma-Operationen Patches bräuchten, so bald man sie einsetzt.)

efi_main und EFI_SYSTEM_TABLE

Der EFI-Einsprungpunkt bekommt ein HANDLE zur laufenden App und einen Pointer zur EFI_SYSTEM_TABLE, die jede Menge Pointer zu Unterobjekten und Funktionen enthält, mit denen man programmieren kann.

Zusätzlich bietet die gnu-efi/efilib.h einige Funktionen an, die so ähnlich wie die C-Runtime aussehen, z.B.: Print() als Alternative zu printf(). Die meisten dieser Routinen sind aber nur Wrapper zur Funktionstabelle, die mit der EFI_SYSTEM_TABLE übermittelt wurde.

 1#include <efi.h>
 2#include <efilib.h>
 3
 4extern EFI_STATUS efi_main(EFI_HANDLE efi_handle, EFI_SYSTEM_TABLE* sys_tbl)
 5{
 6  UINTN efi_event;
 7  InitializeLib(efi_handle, sys_tbl);
 8  Print(L"Hello World\n");
 9  sys_tbl->ConIn->Reset(sys_tbl->ConIn, FALSE);
10  sys_tbl->BootServices->WaitForEvent(1, &sys_tbl->ConIn->WaitForKey, &efi_event);  
11  return EFI_SUCCESS;
12}

Ein gutes und vollständiges Beispiel findet man unter uefi-simple.

Fazit

Ich habe mir die Mühe gemacht und gate/memalloc und gate/stream mit einer EFI-Implementierung versehen. gate/threads und gate/sychronization nutzen die Dummy-Implementierung aus meinem DOS-Layer und schon konnte ich die erste GATE basierte App für EFI erstellen.

Es handelt sich dabei zwar nur um Unit-Tests für GATE-CORE Routinen, aber sie demonstrierten auf meinem Test-EFI-Mainboard, dass die Speicherverwaltung und Textausgabe bereits korrekt funktionieren.

Und jetzt bin ich echt aufgegeilt.
Denn über systbl->BootServices->LocateProtocol lassen sich über GUIDs Protokolle wie TCP und UDP einbinden, womit man über einen angeschlossenen Netzwerkadapter Daten verschicken kann …
… und all das ohne ein Betriebssystem.
Boah, das nenne ich mal Freiheit und Abenteuer-Feeling!

33 % Unvernunft

2021-11-27T12:00:00+01:00

Liebes Corona-Tagebuch!
Lockdown 4 läuft und ich bin jetzt im Dauer-Homeoffice, bis die Kontrollen gegen geimpfte Bürger wie mich beendet sind.

Also, ich lebe seit meiner zweiten Impfung sicher und sorgenfrei und wäre guter Dinge gewesen, dass alles wieder besser wird.
Das Tragen von FFP2-Masken ist in den öffentlichen Verkehrsmitteln Standard geworden, und während mir am Anfang letzten Jahres das Atmen schwerer vorkam, merke ich das Teil inzwischen nicht mehr.
Es ist sogar angenehm, jetzt wo es wieder kalt wird, wenn der Mund-Nasenschutz einem das Gesicht wärmt.

Bitte! Geht alle impfen!

Aber … ist das nicht komisch?
Hatte man uns nicht versprochen, dass die Pandemie schon vorbei sei?

Tja, wenn sich alle Mitbürger an die Regeln gehalten hätten, wäre es vielleicht schon so weit.
Doch wieder jede Vernunft mussten alle im Sommerurlaub ins Ausland fahren und dabei haben sie in engen Bussen und Flugzeugen jede Menge Viren gezüchtet und an die Restbevölkerung verteilt.

Und dort weigert sich jetzt ein Drittel zur Impfung zu gehen, einfach nur um wie ein trotziges Kleinkind “Nein” sagen zu können.
Eben diese Personen verstopfen nun mehrheitlich unsere Krankenhäuser und Intensivstationen, womit wieder mehr Menschen als je zuvor in Österreich an COVID-19 erkranken und teils auch daran sterben.

Neu hinzugekommen ist eine Statistik von einer großen Anzahl an Menschen, die OHNE Corona verstorben sind, aber nur deshalb, weil sie keine Behandlung erhalten haben, da Krankenhäuser wegen Corona-Patienten überfüllt waren.

Es ist also gerade ein verdammt schlechter Zeitpunkt, einen Herzinfarkt zu bekommen … weil für so etwas haben die Krankenhäuser gerade keinen Termin frei. Und von der seit zwei Jahre andauernden Überbelastung des medizinischen Personals will offenbar auch niemand etwas wissen, obwohl es genau diese Helden sind, die uns Tag täglich ohne Dank das Leben retten.

Ein Fall im Bekanntenkreis machte die Situation deutlich:
Es war eine Operation notwendig und danach erfolgte eine Ansteckung mit COVID im Krankenhaus. Dies wurde zum gefürchteten Long-COVID und damit eröffnete sich ein Leidensweg, der noch lange nicht überstanden ist.

Zur Impfung oder diversen Regierungsentscheidungen kann man durchaus kritisch stehen, aber wenn es um den Zusammenbruch der medizinischen Versorgung geht, dann hat JEDER die PFLICHT alles zu unternehmen, um das System zu schützen. Und das heißt: Sofort impfen gehen!

2G (bald 1G) am Arbeitsplatz

Hmm … man könnte sich fast darüber lustig machen:

Die Regierung verlangt ab November 2021 2G für alle Arbeitsplätze.
Das ist ein Rückschritt, wir haben doch schon 5G Netze ausgebaut und jetzt wollen die wieder GSM erzwingen? 😛 … 😉

Aber eigentlich pisst mich das an. Zwar bin ich geimpft und ich halte mich an alle Regeln, will aber nicht permanent meinen Impfpass mitnehmen müssen. Nun drohen Strafen zwischen 500 und 3000 Euro, sollte eine Kontrolle am Arbeitsplatz stattfinden.
Und das kann jederzeit passieren.

Ein Monat vor meiner 2. Impfung wurde die automatische “analoge” Zustellung von Impfzertifikaten einfach abgeschafft. Und weil ich auf gar keinen Fall einer schlecht geschriebenen Android-App meine persönlichen Daten aushändigen will, habe ich auch keinen “grünen Pass” oder ein Impfzertifikat erhalten.

Die Geschichte mag durchaus “meine Schuld” sein, denn ich habe vor ein paar Jahren nicht ohne Grund alle Dienste beendet, die auf diese unerträglichen und unsicheren Smartphone-Lösungen umgestiegen sind. Die Alternative war damals ein digitales Zertifikat auf meiner e-Card, das samt Kartenleser perfekt funktioniert hatte …. bis ausgerechnet mit Beginn der Pandemie dieser Dienst ersatzlos eingestellt wurde.

Ich kann also überhaupt keine amtlichen Angelegenheiten mehr online regeln und das bleibt bei mir auch so, bis Linux Smartphones wie mein PinePhone unterstützt werden. Und ich laufe in der Pandemie auch sicher nicht spaßhalber zu Ämtern und setze mich dort auf die Wartebank.

Mir persönlich tut das nicht weh, und wenn ich ohne grünen Pass nicht rausgehen darf, ist das lediglich ein Gewinn für China und Deutschland, denn nun wird alles nur noch im Ausland bestellt.

All das hat mir die Entscheidung sehr leicht gemacht:
Ich steige um auf permanentes Home-Office.
Und das bedeutet vor allem, dass ich länger schlafen kann und nicht mehr 1 Stunde Busfahrt pro Tag verliere.

Dass jetzt Arbeitnehmer mit Strafen bedroht werden, wenn sie keinen Impf- oder Testnachweis zu jeder Zeit vorzeigen können, ist aber trotzdem absolut nicht korrekt.
Anstatt dass die Schuldigen der jüngsten COVID-Ausbrüche zu Rechenschaft gezogen werden, werden damit geimpfte Bürger wie ich bestraft.
Nö, das ist nicht korrekt!

Fazit

Das aktuelle Hochschnellen der COVID-Ausbrüche hat zumindest einen “positiven” Aspekt: Es haben sich wieder mehr Menschen zur Impfung gemeldet. Und auch meine 3. Impfung ist bereits auf Ende Dezember fixiert.

Leider gleicht das die sinnlosen Toten, die wegen Krankenhausüberfüllung nicht behandelt werden konnten, nicht aus. Zu spät is eben zu spät.

Da wir erst zwei Drittel der Bevölkerung geimpft haben, kann ich nur hoffen, dass ein Großteil des offenen Drittels noch zur Vernunft gelangen und eine Impfung durchführen lässt.
Die Impfung rettet Leben und ist unsere beste Chance die Pandemie so bald wie möglich hinter uns bringen. Und jede verweigerte Impfung zieht die ganze Sache unnötig für alle in die Länge.

Von daher nochmal:

Geht bitte endlich alle impfen!

Nachtrag

Endlich habe ich mit Florian Klenk jemanden gefunden, der “meine Sprache” spricht, wenn er ganz ungeniert fragt:

Warum gibt es keine Werbung für die Impfung auf Pornhub?

Pokemon D/P Remakes

2021-11-21T12:00:00+01:00

Da ist er also wieder. Dieser Moment, der alle paar Jahre kommt, wenn ich wieder für kurze Zeit zum Kind werde und einer zwanzig Jahre alten Tradition nachkomme: Die neueste Pokemon Edition wird gekauft und durchgespielt.

Mit “strahlender Diamant” und “leuchtende Perle” sind am Freitag die Remakes der alten Diamant/Perle Editionen aus dem Jahr 2007 (damals am Nintendo DS ) für die aktuelle Nintendo Switch erschienen.

Könnt ihr euch erinnern, damals am Schulhof ?

Ich nämlich nicht, da ich ja vor den ersten Rot/Blau Editionen meinen Gameboy verkauft hatte.
Erst mit HeartGold/SoulSilver um 2010 fand wieder ein originaler Nintendo DS den Weg in meine Hände und dann wurde Pokemon Diamant selbstverständlich sofort nachgeholt.
(Die kurzen zwischenzeitlichen Emulator Probiererei sind kaum der Rede wert.)

Nostalgie und schöne Grafik

Das Problem für mich als “gealtertem” Pokemonfan ist die Tatsache, dass mir Neuerungen eher weniger zusagen.
Letztendlich bedeutet Pokemon für mich: 8 Arenaleiter besiegen, dann die Liga schaffen und danach den Pokedex vervollständigen. Aus.

Seitdem der Pokedex auf Grund der Fülle an Pokemon nicht mehr im Zentrum steht und “seltsame” Instagram-Blödeleien wie Fotoshootings zum Spielverlauf gehören, sind neue Editionen eher ein Durchspielpflicht als eine Leidenschaft geworden.

Doch die Remakes holen mich mit den Soundtracks “von damals” voll ab und obgleich ich vor 10 Jahren auch kein Kind mehr war, fühle ich wieder ein bisschen kindliche Lebensfreude in unserer aktuell etwas tristen Welt, wenn die Melodie von “Route 201” ertönt.

Und wer sich noch an die Pixelgrafik des original Gameboy (oder im Emulator) erinnern kann, der wird mit jeder neuen Plattform ein noch beeindruckenderes Grafikspektakel erleben.

Inzwischen sehen die menschlichen Figuren viel besser und lebendiger aus, als es in den ersten Anime Staffeln der Fall war.
Kurz gesagt: Ich liebe dieses Remake.

Ich habe erst ein paar Stunden hinter mich gebracht, aber weiß natürlich noch ungefähr, was auf mich zukommen wird. Die Stories der legendären Pokemon wurde meines Erachtens mit jeder Generation etwas besser und die vierte mochte ich auch damals schon sehr. Von daher bin ich gespannt, ob es im Remake ein paar neue Adaptionen gibt, die wieder etwas mehr Mythologie ins Pokemon-Universum bringen.
Im Remake der 3. Generation (OR/AS) ist das den Machern jedenfalls total gelungen, folglich habe ich auch hier eine hohe Erwartung.

Fazit

Bisher habe ich nur einen Nachteil bemerkt: Am Tag der Veröffentlichung muss bereits ein fettes Update heruntergeladen werden, bevor das Spiel voll funktionsfähig wird. Typisch Software von heute!
Aber sonst liebe ich den Titel.

Mich würde mal interessieren, ob es vor dem digitalen Zeitalter auch solche Jugend-Erinnerungs-Fixpunkte gab, wo sich alle 10 bis 20 Jahre etwas Altes in neuem Stil wiederholte.
Bei Kleidung und Mode kann ich mir das vorstellen, aber gab es sonst noch was Vergleichbares?

Wie auch immer, Pokemon ist bei mir jetzt schon 20 Jahre immer “nebenbei” präsent und alle paar Jahre wird dadurch ein Nostalgie-Flash abgeworfen, den ich nicht mehr missen möchte.

Ich bin gespannt, ob es in 10 Jahren immer noch solche Events geben wird, und vor allem frage ich mich, ob sie mir wie heute noch ein zufriedenes Grinsen ins Gesicht malen können.

Meine “leuchtende Perle” ist definitiv “kein Schuss in den Ofen”.

Nachtrag 28. Nov. 2021

Die Pokemon-Liga ist geschafft, ich bin nun “ein” Champ der Sinnoh Region und glücklich damit.

Allerdings war der Sieg unerwartet schwer, dann Cynthia, der vorherige Champ machte mich mit ihrem Knakrack regelrecht fertig. Mein Team war (wie üblich bei mir) nicht strategisch ausgewählt und so blieb mir nichts anderes als so lange Beleber und Top-Tränke einzusetzen, bis dem gegnerischen Pokemon die Attacken ausgingen.
Und das zog sich bis zu meinen letzten Reserven hin.

Nun habe ich keinen Stress mehr und kann über Weihnachten mal sehen, wie weit der PokeDex gefüllt werden kann.

Wie auch immer, es ist schön, wenn man das Kind in einem selbst wieder mal zum Lachen gebracht hat.

OpenCppCoverage in Docker

2021-11-20T12:00:00+01:00

Wieso (zur Hölle) funktioniert OpenCppCoverage eigentlich nicht in Windows Docker Containern?

Denn während man auf normalen Desktop Rechnern und Servern mit OpenCppCoverage schöne Statistiken erhält, welche Codezeilen durchgelaufen sind (und welche nicht berührt wurden), erhalten wir mit dem selben Tool im Container die Meldung:

cannot find the name of the module

Spoiler: Docker wird von OpenCppCoverage aktuell leider nicht unterstützt und es gibt aktuell keinen Workaround für das Problem.
Aber: Vielleicht können wir dem Thema demnächst mal nachgehen und eine Teillösung ausprobieren.

Vorgeschichte - Neulich in der Firma …

Der Chef will bunte Tortendiagramme, ob und wie viel unsere Unit-Tests den Code wirklich abprüfen.
Manuell konnte man dies immer schon am Desktop-Rechner mit OpenCppCoverage mit einem Plugin in Visual Studio tun, doch eigentlich ist es ja viel einfacher, wenn am Build-Server beim Ausführen aller Tests auch ein Coverage-Report generiert wird.

… tja, und der Build-Server baut eben auf Docker auf und dort wird jede Coverage mit dem Fehler cannot find the name of the module abgewürgt.

Analyse

Der bzw. die OpenCppCoverage Entwickler haben ein kleines Test-Tool erstellt, welches das Problem aufzeigt:

Benutzt wird die Windows Debug API und diese liefert normalerweise bei jedem Ladevorgang einer DLL eine File-Handle (hfile) zum geöffneten Modul. So kann man dann Debug-Symbole aus dem Modul laden und die richtigen Quellcode-Zeilen zum ausgeführten Binärcode ausfindig machen.

Unter Docker liefert die Debug-API (WaitForDebugEvent()) aber offenbar nur NULL für hfile, was die weitere Code-Coverage verhindert.

Ich habe daher mal ebenfalls ein Test-Projekt mit Debugging-API-Code zusammengebastelt um das bei mir besser nachvollziehen zu können. Die Quellcodes hierfür sind im CLASSROOM veröffentlicht.

Und ja, hfile ist tatsächlich NULL, wenn man z.B. cmd.exe damit debuggen möchte um seine Module im LOAD_DLL_DEBUG_EVENT zu erkennen.
Danach habe ich einen Ordner meines Hosts in den Container gemountet um andere Tools zu testen und wieder war der hfile Member auf NULL gesetzt.

Danach machte ich aber etwas ganz Verrücktes:
Ich erzeugte im Docker-Container einen Test Ordner auf Laufwerk C:\test und kopierte meine Test-Programme vom gemounteten Host-Ordner dort hin.

Kaum startete ich den Debugging-Test, kamen auch schon die ersten korrekten hfile Werte, die mit GetFinalPathNameByHandleW() in einen Dateipfad umgewandelt werden konnten.
Die Pfad-Angaben sind im NT-Format, z.B.: \\\\?\\c:\\path\\to\\module.dll.

Teil-Lösung 1: Man muss Dateien in einen Container-interne Ordner kopieren, damit die Debug-APIs gültige Werte liefern. Denn mit Host-Volumes funktioniert es nicht.

Das Verhalten (wenngleich sehr verstörend) ist sogar nachvollziehbar, schließlich handelt es sich um “virtuelle Pfade”, die ins Dateisystem von Docker “hineingehackt” werden. Dass die von manchen APIs anders behandelt werden, ist zwar lästig, vielleicht aber auch sicherheitstechnisch notwendig.

Nachteil: Dieser Workaround läuft letztendlich nicht mit allen Modulen. ntdll.dll ist da trotzdem ausgenommen, und Tools wie cmd.exe und andere System-DLLs liegen grundsätzlich an einem Ort, der aus anderen Docker Layern zusammengeklebt ist. Die kann man da nicht weg kopieren und somit fehlen ihre Daten.
… aber für die Code-Coverage wäre das egal, da interessieren wir uns ja für “unseren” Code und nicht für fremde System-DLLs.

ImagePath im Remote-Prozess

Wenn es uns weiters um den Image-Pfad eines geladenen Moduls geht, gibt es noch eine weiter Möglichkeit:

LOAD_DLL_DEBUG_INFO führt nämlich noch die Member lpImageName und fUnicode mit sich.
lpImageName hält die Speicheradresse zu einem Pointer zu einem String mit dem Pfad des Moduls. Dieser Parameter ist zwar nur optional befüllt, doch in meinen Tests war er auch im Docker Container stets ausgefüllt.

Das Problem ist nur, der Pointer verweist auf Speicher im Remote-Prozess. Wir müssen daher mit der ReadProcessMemory Zeichen für Zeichen herauspicken.

Mein Demo-Code hierfür sieht etwa so aus:

 1static int print_remote_image_path(HANDLE hProcess, void* lpImageName, int unicode)
 2{
 3  int chars_printed = 0;
 4  char* remote_address = NULL;
 5  SIZE_T returned = 0;
 6  SIZE_T char_len = unicode ? sizeof(wchar_t) : sizeof(char);
 7  wchar_t buffer[4] = { 0 };
 8  char* ptr_char = (char*)&buffer[0];
 9
10  if(ReadProcessMemory(hProcess, lpImageName, &remote_address, sizeof(remote_address), &returned))
11  {
12    if(remote_address != NULL)
13    {
14      while(ReadProcessMemory(hProcess, remote_address, ptr_char, char_len, &returned))
15      {
16        if(unicode)
17        {
18          if(buffer[0] == 0) break;
19          wprintf(L"%c", buffer[0]);
20        }
21        else
22        {
23          if(*ptr_char == 0) break;
24          printf("%c", *ptr_char);
25        }
26        remote_address += char_len;
27        ++chars_printed;
28      }
29    }
30  }
31  return chars_printed;
32}

Man lädt also zuerst den Pointer zum String über die Adresse in lpImageName, und je nachdem, ob es ein Unicode oder ANSI String ist, wird Byte für Byte aus der Zieladresse gezogen, bis wir einen \0 Terminator finden, welcher das Ende des String andeutet.

Teil-Lösung 2: Wir extrahieren den Pfad des geladenen Moduls aus dem Zielprozess und öffnen das Modul manuell.

Nachteil: Der Parameter ist als “optional” markiert und ich weiß auch noch nicht, ob dieser Pfad und die manuelle Öffnung dann für eine Coverage benutzt werden kann.

Fazit

Die schnellere Lösung war es natürlich, mit dem GCC und anderen Tools eine vergleichbare Code-Coverage unter Linux laufen zu lassen.
Es ist generell ärgerlich, dass unter Windows viele OpenSource-Tools bis heute Kinderkrankheiten haben und nur sündteure “Enterprise-Produkte” Abhilfe versprechen.

Wie auch immer … es wäre mal ein netter Sidequest, den OpenCppCoverage Code zu studieren und vielleicht lassen sich die beiden beschriebenen Teillösungen dazu nutzen, auch mit diesem eigentlich großartigen Tool neue Coverage-Reports unter Windows Docker Containern erstellen zu lassen.

… mal sehen, was die Zukunft bringt.

Raspberry Pi Zero 2 W

2021-11-14T12:00:00+01:00

Wenn man für 10 Dollar 1 mal 1 GHz bekommt, dann bekommt man für 15 Dollar …
… 4 x 1 GHz.

So ist es zumindest beim neuen Raspberry Pi Zero 2 W, der seit kurzem verfügbar ist.
Den musste ich selbstverständlich haben.

Wenn man 2 SD Karten oder 3 Nintendo-Switch Module nebeneinander legt, bekommt man in etwa die Ausmaße eines Raspberry PI Zero.
Und wenn man bedenkt, dass auf dieser Größe ein ganzer PC sitzt, der mit einem Gigahertz getaktet war, dann ist das bereits mehr als großartig.

Mit dem PI Zero 2 findet auf der gleichen Größe nun ein 4-Kern Prozessor Platz, der auch die Rechenleistung des Winzlings vervierfachen kann.

Nachteil: 512 MB zu wenig zum Kompilieren

Die Freude wird leider nur dadurch etwas getrübt, dass der RAM mit 512 MB leider genau so klein geblieben ist, wie im Vorgängermodell.
Und dass ist (für mich) tatsächlich ein größeres Problem, denn gerade beim Kompilieren von Software bedeutet jeder zusätzliche Kern die Notwendigkeit von zusätzlichem RAM.

Bereits auf meinem Raspberry PI 2 mit 1 GB RAM musste ich das Kompilieren auf 1-2 Kerne reduzieren, weil ansonsten zu viel RAM von den Prozessen parallel in Anspruch genommen wird, was das System instabil werden lassen kann.

Der RPi Zero kam mit einem Kern und den 512 MB zurecht, brauchte aber ewig. Hier hätte der RPi Zero 2 mit 4 Kernen hart zuschlagen können, doch wegen des zu geringen RAMs muss ich auch darauf den Compiler auf einen Kern herunterdrosseln.

Vorteil: Embedded Software

Wenn man aber mit embedded-Diensten arbeitet, die wenig RAM fressen, wie z.B. schlanke Webserver, dann hat man mit dem Zero 2 seine Freude.

Denn während zB.: TLS/SSL Verbindungen auf dem Zero 1 single-threaded zum verzögerten Seitenaufbau führten, helfen die zusätzlichen Kerne des Zero 2 die Rechenlast besser abzufangen.
So lange man also die RAM Nutzung reduzieren kann, bedeutet das Modell also einen deutlichen Performance-Gewinn.

Das fällt auch bei Tools wie webmin auf, wenn im Hintergrund ein anderer Dienst werkt. Beim RPi Zero 1 verlangsamte sich unmittelbar die Webseite und genau das passierte mir beim RPi Zero 2 nun nicht mehr (bzw. seltener).

Stromaufnahme

Die wichtigste Frage für mich war:

Kann ich den Zero 2 vom USB Anschluss meines PCs betreiben.

Die grundsätzlich Antwort: Ja, aber.

Da die Empfehlung bei 1 - 2 Ampere für das Netzteil liegt, reichen die 500 mA von USB 2 nicht vollständig.
Ein GUI Betrieb mit Browser wird also nicht möglich sein.
Doch wenn man den Zero 2 als Webserver für Sensoren nutzt und die Software keine langen CPU Spitzen produziert, ist der USB Betrieb durchaus denkbar.

Zumindest in meinen Test klappte das Hochfahren vom schwachen PC-USB-Port aus immer problemlos und dabei kommt ja auch eine “üblich” Auslastung zusammen.

Fazit

Der Raspberry Pi ist und bleibt meine Lieblingsplattform unter den SoCs (System-onC-hip). Das liegt grundsätzlich am geringen Stromverbrauch im Verhältnis zur Allwinner Konkurrenz und natürlich auch an der guten Softwareunterstützung.

Mit dem Zero 2 wurde die Pi Familie um ein nützliches Geschwisterchen erweitert, das überall dort eingesetzt werden kann, wo es für Zero 1 knapp wurde.

Mit Flagschiffen wie dem Raspberry Pi 4 kann der kleine Zero 2 aber natürlich nicht mithalten … aber das hat auch keiner von ihm verlangt.

Windows Auto-Login Passwort auslesen

2021-11-13T12:00:00+01:00

Da schaue ich in eine lange nicht genutzte Mailbox und finde dort die Quellen eines Windows Programms, das ich vor über 10 Jahren schnell schreiben musste. Es sollte folgendes Problem lösen:

Das Auslesen des Auto-Login Default-Passworts eines angemeldeten Accounts.

Wozu sollte man ein Passwort auslesen wollen, wenn der Account bereits angemeldet ist?

Tja, man stelle sich vor, man hätte ein Passwort auf Industrie-Terminals gesetzt, das beim Start zum automatischen Login benutzt wird.
Dieses Passwort wurde vergessen, da es im Windows Deployment-Image integriert war.
Und dann muss man plötzlich versuchen, diese Terminals “remote” zu administrieren, wofür man das Passwort wieder braucht.
Zum Glück steht noch ein verstaubtes Demo-Gerät mit automatischem Login im firmen-eigenen Museum. Vielleicht kann man das Passwort dort irgendwie extrahieren.

Dieses Passwort wurde leider nicht einfach in der Registry unter SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon in DefaultPassword abgelegt, sondern über System-Tools wie netplwiz intern gesetzt.

Wo wird also ein solches “verschlüsseltes” Passwort gespeichert?

Lösung: LsaRetrievePrivateData

Windows kann Schlüssel-Wert Paare verdeckt speichern und wenn der automatische Login auf einem System aktiviert wird, dann wird das Passwort im Feld DefaultPassword gespeichert.
Um es wieder auszulesen nutzt man folgenden Weg:

LsaOpenPolicy(NULL, &attribs, POLICY_ALL_ACCESS, &lsa_handle)
öffnet ein LSA_HANDLE Objekt
Man erzeugt eine LSA_UNICODE_STRING Struktur und lässt es auf einen wchar_t Datenpuffer verweisen, in dem DefaultPassword enthalten ist.
Und dann ruft man
LsaRetrievePrivateData(lsa_handle, &key, &ptr_value) auf, welchem die String-Struktur als key übergeben wird.
Der zurückgegebene Pointer (ptr_value) hält eine neue Unicode-String Datenstruktur, wo das entschlüsselte Passwort enthalten sein sollte, oder eben nicht, wenn keines existiert.

Der Aufruf muss unter Administrator-Rechten erfolgen, ansonsten wird der Zugriff verwehrt.
(Zum Glück hatte der Account damals auch Admin-Rechte.)

Der Beispiel-Quellcode ist nun auch im BLOG Classroom verfügbar.

Fazit

Wenn ich es richtig verstehe, wurden klassische Tools wie netplwiz bzw. der Aufruf control userpasswords2 auf Windows 10 deaktiviert, mit dem man zur UI kam, wo man den automatischen Login aktivieren und das zu verschlüsselnde Passwort eintippen konnte.

Das Codeschnipsel ist also kein “Sicherheitsbruch” mehr und er hatte (wenn ich mich nicht irre) auch nur im Nicht-Domänen-Betrieb funktioniert.

Die alten Windows XP und Windows 7 Terminals, an denen ich damals arbeitete, existieren (hoffentlich) nicht mehr, aber ich möchte diesen Aufruf trotzdem dokumentieren.
Wenn also jemand ein Passwort zu einem Autologin braucht, das nicht im Klartext in der Registry steht, dann hat man zumindest einen Ansatz.

GCC Link Time Optimization (LTO)

2021-11-07T12:00:00+01:00

Ich arbeite auf dem Raspberry Pi und anderen Linux-Umgebung ja schon lange mit Debian 10 (Buster) und neuerdings auch auf Debian 11 (Bullseye).

Doch als ich spaßhalber einen GCC 6.3 Build des GATE Frameworks unter Debian 9 (Stretch) anfachte, tauchten jede Menge Fehler folgender Art auf:

plugin needed to handle lto object

Und dann meinte auch noch MinGW:

undefined reference to `strndup’

Zwei GCC Probleme

MinGW + libressl == missing `strndup`

Als ich vor einem halben Jahr auf Link-Time-Optimization (LTO) in den GCC Build umgestiegen bin, tat ich das nur im GATE Development Branch und der löst beim git push auf BitBucket keine Build-Pipeline aus.

Und seitdem ich neulich einen Pull-Request zur master Pipeline absetzte, krachte es beim Linken von einigen C++ Templates und immer wieder in der libressl, wenn mit MinGW unter Linux auch Windows-Binärdateien gebaut werden.

Offenbar werden einige Symbole durch die LTO entfernt, denn ist diese abgeschaltet, produziert MinGW brav Windows EXEn.

GCC kleiner 7 kann LTO nicht so richtig

Das “älteste” Linux, mit dem ich so arbeite ist Ubuntu 18.04 in WSL und das setzt den GCC 7.5 ein. Und meine Raspberry PIs mit Debian 10 kompilieren mit dem GCC 8.3.
Und alle konnten sie mit dem -flto Switch problemlos umgehen.

Doch da wir in der Firma auch mit Debian 8 und 9 arbeiteten und ich eher zufällig entdeckte, dass unter Windows 2022 ein wsl install -d debian plötzlich wieder Debian 9 ausrollt (während im Windows Store mit Debian 10 und neuer gehandelt wird), war klar, dass ich mit dem älteren Compiler experimentieren wollte.

Und bei jeder einzelnen .c oder .cpp Datei kam die Meldung:
plugin needed to handle lto object.

Es sieht also so aus, dass GCC 6.3 mit -flto nicht leben kann, denn ohne diesen Zusatz funktioniert alles problemlos.

Lösung: LTO abschalten

Oh Mann! Ich habe unzählige Kombinationen ausprobiert, doch keine konnte alle Probleme beseitigen und so blieb mir nichts anderes übrig, als folgendes in CMakeLists.txt einzutragen:

 1if(CMAKE_COMPILER_IS_GNUCC OR CMAKE_COMPILER_IS_GNUCXX)
 2  # standard GCC flags
 3  set(CMAKE_C_FLAGS_RELEASE "${CMAKE_C_FLAGS_RELEASE} -s -fdata-sections -ffunction-sections")
 4  set(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE} -s -fdata-sections -ffunction-sections")
 5  set(CMAKE_EXE_LINKER_FLAGS_RELEASE "${CMAKE_EXE_LINKER_FLAGS_RELEASE} -s -Wl,--gc-sections")
 6  set(CMAKE_MODULE_LINKER_FLAGS_RELEASE "${CMAKE_MODULE_LINKER_FLAGS_RELEASE} -s -Wl,--gc-sections")
 7  set(CMAKE_SHARED_LINKER_FLAGS_RELEASE "${CMAKE_SHARED_LINKER_FLAGS_RELEASE} -s -Wl,--gc-sections")
 8
 9  if(NOT MINGW AND CMAKE_CXX_COMPILER_VERSION VERSION_GREATER_EQUAL 7.0)
10    # special GCC LTO + optimization flags
11    string(REPLACE "-O3" "" CMAKE_C_FLAGS_RELEASE "${CMAKE_C_FLAGS_RELEASE}")
12    string(REPLACE "-O3" "" CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE}")
13    set(CMAKE_C_FLAGS_RELEASE "${CMAKE_C_FLAGS_RELEASE} -flto -Os")
14    set(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE} -flto -Os")
15    set(CMAKE_EXE_LINKER_FLAGS_RELEASE "${CMAKE_EXE_LINKER_FLAGS_RELEASE} -flto")
16    set(CMAKE_MODULE_LINKER_FLAGS_RELEASE "${CMAKE_MODULE_LINKER_FLAGS_RELEASE} -flto")
17    set(CMAKE_SHARED_LINKER_FLAGS_RELEASE "${CMAKE_SHARED_LINKER_FLAGS_RELEASE} -flto")
18  endif()
19endif()

Wenn also der MinGW oder ein anderer GCC kleiner 7 eingesetzt wird, dann soll keine Link Time Optimization stattfinden.
Ob diese Lösung korrekt ist, weiß ich nicht, sie entspricht nur meiner Beobachtung aus der Debian/Ubuntu Serie.

Es gibt Hinweise, dass in älteren Linux-Distributionen die bin-utilities LTO nicht nativ unterstützen und dafür andere Varianten von /usr/bin/ar und /usr/bin/ranlib bräuchten. Man könnte in CMake die Aufrufe durch gcc-ar und gcc-ranlib ersetzen, doch das hat bei mir nie vollständig funktioniert. Keine Ahnung warum, aber hier ist die Anleitung, die ich dazu gefunden habe.

Mein MinGW ist neuer als 7.0 und kann LTO, doch der stößt sich an anderen Flags wie z.B. -s, -Os oder -Wl,--gc-sections.

Ich konnte alle C++ Template Probleme durch die Entfernung von -s usw. beheben, wobei -flto bestehen blieb. Doch strndup blieb stets als “undefiniert” übrig und ließ den Übersetzungsvorgang abbrechen.

Folgende Pseudo-Erklärung reime ich mir dazu zusammen:
strndup ist eine Linux Erweiterung, die unter Windows fehlt. libressl erkennt das und fügt eine Kompatibilitäts-Implementierung hinzu. Dort wird strndup zwar implementiert, doch es gibt keine Deklaration in einem Header, die darauf verweise würde.
Und somit dürfte die Funktion auch als unsichtbar gelten, wenn LTO alle Module am Ende des Linkens zusammenfasst, schließlich wird das Symbol offiziell nicht in andere Module “importiert”, aber dort sehr wohl genutzt.

Fazit

Hmm … ich bin etwas angepisst.

Die Experimente haben mich einige Stunden gekostet und am Ende bin ich daran gescheitert. Vielleicht gibt es eine Kombination, die LTO in statischen Bibliotheken wie libressl unter MinGW gefügig machen und vielleicht kann man auch die Toolchain unter GCC kleiner 7 mit dem korrekten LTO Plugin füttern.

Aber ich fand es am Ende einfacher, diese Features auf jenen Plattformen auszuschalten, damit ich mich um wichtigere Dinge kümmern kann.

Dass LTO unter Linux mit dem GCC erst seit kurzem vernünftig funktioniert, finde ich etwas komisch. Schließlich nutzen Intel und der MSVC diese Technik schon seit 2 Jahrzehnten um die effizientesten Binaries zu erzeugen.

Tja, beim GCC war früher eben doch nicht alles besser …

Letztes Windows 7 Update

2021-11-06T12:00:00+01:00

Die letzten Jahre war eine Parallelinstallation von Windows 7 neben Windows 10 für mich “normal” auf meinen PCs und Laptops, denn für Visual Studio 2005 und ein paar ältere Design-Tests ist dieses Setup gut geeignet, wenn man nicht gleich auf eine VM wechseln will.

Die ewig dauernden Updates sind aber sehr nervig, also wurde es Zeit eine “finale” Windows 7 WIM Datei mit allen Updates zu bauen, damit künftige Installationen des abgekündigten Systems “out-of-the-box” laufen.

Dabei bin ich wie folgt vorgegangen:

Erster Download der Updates

Der WSUS Offline Updater ist ein Tool zum reinen Download von Windows Updates, um sie “offline” in ein Windows Image (wie z.B. die Installations-DVD) integrieren zu können.

Da der Windows 7 Support offiziell schon abgelaufen ist und neue Versionen die Downloads nicht mehr unterstützen, nutzt man eine ältere Variante, wie z.B. v11.9 aus dem Jahr 2020, wo die letzten Windows 7 Updates eingetragen sind.

Am Ende hat man dann ein Verzeichnis mit allen .cab Dateien aus den unterschiedlichen Knowledge-Base Patches von Microsoft, die man integrieren kann. Natürlich kann man sich die nötigen Updates auch selbst über den Microsoft Update Catalog herunter laden, wo alle Dateien jedoch als .msu vorliegen, doch das spielt für die Integration keine Rolle.

Integration per DISM und Test-Setup

Nun wird eine Windows 7 SP 1 DVD hergenommen und die sources\install.wim zur Bearbeitung auf die Platte kopiert. Für gewöhnlich sind mehrere Windows-Installationen (Basic, Home, Professional, Ultimate) in einer WIM Datei untergebracht, doch da ich nur die Professional Variante brauche (Index 3), habe ich (anfangs) nur dieses Image aktualisiert.
Welches Image auf welchen Index liegt, kann man per
dism /Get-ImageInfo /ImageFile:path\to\install.wim auslesen, oder in 7zip über die erste XML Datei ausforschen, die man beim Öffnen der .wim Datei sieht.

dism /Mount-Wim /WimFile:d:\install.wim /Index:3 /MountDir:d:\mount
lädt das Image und
dism /Image:d:\mount /Add-Package /PackagePath:d:\path\to\updates
versucht, alle .cab und .msu Dateien zu integrieren.

Am Ende werden mit
dism /Unmount-Wim /MountDir:d:\mount /commit
alle Updates in die WIM-Datei zurückgeschrieben.

Falls es eine Datei namens sources\ei.cfg auf der Setup-DVD gibt, kann man diese löschen oder diese umbenennen. Denn in ihr steht festgelegt, welche Windows Variante installiert werden soll. Fehlt die Datei, fragt Windows Setup den User, ob er nun Basic, Home, Professional oder Ultimate installieren möchte.

Für eine Testinstallation, kann man mit Tools wie oscdimg wieder ein ISO erstellen um es in einer VM zu nutzen.
Ich habe hingegen meinen Windows Deployment Server benutzt, um das angepasste Windows-Setup per Netzwerk Boot zu starten und Windows 7 in einer Test-VM aufzusetzen.

Windows Update und fehlende Komponenten

Meine Testinstallation startete zwar korrekt, allerdings war das integrierte Windows Update nicht mehr lauffähig, da zu alt. Dafür war es notwendig, die neueste Windows Update Agent Komponente manuell nachzuinstallieren. Die aktuelle Version ist 7.6 und man findet sie unter docs.microsoft.com/en-us/troubleshoot/windows-client/deployment/update-windows-update-agent

Die zur Zeit des Postings gültigen Download Links sind:
Download Windows 7 Update Agent 7.6 X64
Download Windows 7 Update Agent 7.6 X86

Nach der Installation + Neustart kann Windows Setup nach fehlenden Aktualisierungen suchen, und da findet man tatsächlich noch einiges. Vor allem viele nicht-kritische Updates werden nach der Suche aufgelistet.

Ich habe mir dann die Mühe gemacht all diese Updates manuell per Update Catalog herunterzuladen und habe dann die obigen dism Schritte erneut ausgeführt um das Windows Image auch mit den letzten Updates und Features zu füllen.

Am Ende hatte ich so eine halbwegs fertig-gepatchte .wim Datei, die ich für meine künftigen Installationen nutzen kann.

Und mit Tools wie oscdimg kann man dann mit den Dateien der Windows-7 DVD samt der neuen install.wim wieder ein ISO Image erzeugen.
Im nachfolgenden Beispiel liegen die DVD-Dateien unter c:\win7dvd

oscdimg -m -o -u2 -udfver102 -bootdata:2#p0,e,bc:\win7dvd\boot\etfsboot.com#pEF,e,bc:\win7dvd\efi\microsoft\boot\efisys.bin c:\win7dvd c:\win7-dvd-image.iso

Und ja, der -bootdata Parameter ist wirklich eine solche lange Wurst, wo die Einträge für BIOS und EFI mit # getrennt werden und der Dateipfad einfach hinter dem ,b angefügt wird.

Erkannte Probleme

Manche CAB oder MSU Dateien lassen sich nicht integrieren

Leider geht nicht jede Update-Installation gut aus. Denn manche .cab oder .msu Dateien versetzen das Image in einen Zustand, in dem keine weiteren Updates mehr integriert werden können.
In diesem Fall bricht dann die Integration ab und alle folgenden Updates können nicht mehr eingespielt werden.

Hier bleibt einem nichts anderes übrig, als das dism Logfile durchzugehen und das letzte störrische Update zu finden. Dann darf man wieder von vorne mit einer jungfräulichen .wim Datei anfangen und diese erneut aktualisieren, wobei das störende Update einfach übersprungen wird.

Das bewirkt dann am Ende zwar, dass ein paar Updates fehlen und in der fertigen Installation eben genau dieses übersprungenen Update wieder gefunden werden … aber mit diesem Manko lässt sich leben lernen.

Es ist kein Problem nach einem Setup noch 10 weitere fehlende Updates einspielen zu müssen, denn ohne die Integration wären es sonst 300 Updates, die alle erst mal heruntergeladen werden müssten.

Hyper-V unterstützt Windows 7 nicht in Gen-2-VMs

Eigentlich wollte ich auch UEFI Installation mit Hyper-V testen. Unter Windows 10 startet ein Windows 7 ISO Image zwar in einer “Generation-2 VM”, friert aber schon im Boot Screen ein.

Man kann allerdings auf docs.microsoft.com nachlesen, dass Hyper-V in Windows 10 die Windows 7 Gastinstallationen nur in “Generation 1” VMs (also im BIOS Modus) unterstützt. UEFI Support in Hyper-V (“Generation 2”) gibt es erst für Gäste ab Windows 8 bzw. Server 2012.

Schade eigentlich, denn Windows 7 ist an sich sehr wohl UEFI tauglich.

Fazit

Nun, ich weiß nicht, wie lange ich Windows 7 noch am Leben erhalten werde, denn seine aktive Nutzung ist bei mir seit 2017 stark zurückgegangen. Eigentlich sind es nur noch Windows-CE Experimente, die mich in diese ältere Installation booten lassen.

Früher oder später wird das ganze nur noch eine VM sein, doch aktuell sind meine Intel Atom Systeme zu schwach, als dass man mit Windows 7 flüssig darauf arbeiten oder kompilieren könnte.

Marvel, Squid-Game, usw.

2021-10-31T12:00:00+01:00

Alles passiert bei mir verzögert, da ich nicht ins Kino gehen kann bzw. will bzw. darf, doch zumindest Black Widow ist vor ein paar Wochen auf dem Streaming Dienst Disney Plus erschienen.

Und dann kam noch völlig unerwartet eine Überraschung aus Korea names Squid Game.

Zeit für ein Movie und Serien-Review.

Black Widow

Ich sehe Scarlett Johansson wirklich sehr sehr gerne zu, bei allem was sie macht.
Und dass mir ihre Rolle als Black Widow ganz besonders zugesagt hat, ist auch kein Geheimnis.

Und jetzt, nach ihrem offiziellen Film-Tod in Avengers Endgame liegt ihr Solo-Film “Black Widow” als Prequel auf dem Tisch … … und ich weiß einfach nicht, was ich damit anfangen soll.

Ich glaube, ich bin genetisch nicht dazu in der Lage, den Film schlecht zu finden, und finde einige Figuren und deren Darstellung auch gut gelungen. Aber W-T-F … was war denn das für eine Story?

Mein größtes Problem ist vor allem, dass die heldenhafte Figur der Natasha Romanoff aus Avengers Endgame, im Nachhinein belangloser wird und das liegt an einer - aus meiner Sicht - sehr herbei konstruierten Nebengeschichte, die man in früheren Filmen hätte einleiten müssen.

Es wirkt leider sehr künstlich, wenn man eine Figur aus Filmen kennt, die wenig Hintergrund hat und darüber nie gesprochen wird, und dann kommt eine verschränkte Verschwörung zum Vorschein, die das Weltgeschehen ändert …

Also … belassen wir es dabei: Ich mag die Figure Black Widow, selbst wenn sie in seltsame Kulissen hineingeschrieben wird, die eigentlich nur dazu da sind, andere Charaktere einzuführen.

Marvel’s: What If

Die animierte Serie What If ist eine kleine “Avengers-Phase” in andersartigen Paralleluniversen.

Mit jeder Episode wird ein neuer “alternativer” Held eingeführt, damit im Staffelfinale alle gemeinsam den größten Bösewicht bekämpfen können.

Und hier bin ich echt dankbar, dass die Serie animiert ist und nicht real abgedreht wurde. Denn so kann man die Serie viel leichter isoliert von Marvels “Cinematic” Universe trennen und man erlebt keine W-T-F Momente, wenn z.B. plötzlich Zombie-infizierte Avengers durchs Bild laufen und den Passanten die Arme abbeißen, oder Thanos zum gutmütigen Saufkumpanen an der Bar wird.

Da mit Loki und der Einführung des Multiversums sprichwörtlich “alles” möglich ist, bin ich grundsätzlich solchen “Veränderungen” von Stories gegenüber skeptisch, aber mit der Machart hat mich Marvel überzeugt.

Und so konnte ich die Serie einfach zwischendurch genießen, ohne alles in Frage stellen zu müssen.

Shang-Chi und Eternals

Dass Shang-Chi ins Streaming kommt, dauert noch etwas, aber zumindest habe ich bisher so einiges Gutes über den nächsten Marvel Film gehört. Und Anfang November startet auch Eternals in den Kinos. Nachdem aber immer noch die für mich unerträgliche Registrierungspflicht aufrecht ist, werde ich wohl auch hier noch lange warten müssen, bis ich diesen Film zu Hause sehen kann.

Ich bin gespannt, wie sich diese neuen Filme ins gerade geöffnete Multiversum einfügen werden, habe aber auch etwas Angst, ob Marvel sich da nicht etwas verfahren hat, so viele neue Stränge aufzumachen.
However … bisher habe sie es aber immer geschafft wieder alles zu vereinen, und darauf hoffe ich auch heute.

Squid Game

Und dann kommt so “ganz nebenläufig” auf Netflix eine neue koreanische Serie namens “Squid-Game” auf die Empfehlungsliste.
Es war tatsächlich das Titelbild mit den “komisch rot bzw. rosa-farbenen Jumpsuits”, das mein Interesse geweckt hat.

Die erste Folge wirkte etwas befremdlich und ich fühlte sich wie eine billiges Sozialdrama an. Doch dann begann “das Spiel”, und ab da konnte ich mich nicht mehr dem Drang entziehen, wissen zu wollen, wie es ausgeht.

Achtung Spoiler

Wenn man armen von Existenzängsten bedrohten Menschen ein Glücksspiel anbietet, stellt man fest, dass viele gerne darauf einsteigen. Schließlich hat man nichts zu verlieren.
Doch die Formel in Squid-Game ist brutal: Wer verliert, der stirbt.

Und tatsächlich wartet die Serie bis zur letzten Folge um zu erklären, wie denn überhaupt ein solches Spiel nach dem Vorbild von Takeshi’s Castle mit hohem Sterberisiko in unserer Welt möglich sein soll.

Ein bisschen hat mich die ganze Sache an den Film Cube erinnert, doch während man in Cube nie wirklich den Grund für die Tötungsmaschinerie erfährt, schildert Squid-Game einen leider fast realistischen von Dekadenz geprägten Hintergrund.

Fazit

Während Marvel für mich aktuell so “dahinplätschert”, hat mich Squid-Game ob geringer Erwartungen total positiv überrascht.
Wer kein Problem mit unerwartet viel Blut hat, darf sich ein Wochenende lang durch die groteske Geschichte durch-bingen

Rotes Licht, grünes Licht!

Nachtrag

Das geilste ist, dass man sich die Squid-Game Outfits alle auch bestellen kann, und als Masken-Fan, musste ich die 3 Aufseher- und die Game-Master Masken sofort in den Einkaufswagen legen.

Inzwischen sind sie angekommen …

… und ich überlege noch, ob ich mal meine Nachbarn damit auf dunklem Flur erschrecken soll.
Naja … besser nicht. 😛

Windows Image Cleanup

2021-10-30T13:00:00+02:00

Windows wird immer langsamer und träger. Schuld daran sind unnötige Apps, die man “schnell” ausprobieren wollte, aber leider fallen auch Windows Updates darunter.

Bevor man sich also eine weitere verlangsamende App herunterlädt, die behauptet, sie würde beschleunigen, kann man mit dism und Windows PE auch einiges erreichen.

Windows Updates sichern stets das, was sie ersetzen. Im Laufe des Support-Zyklus einer Windows Version wird fast das gesamte Betriebssystem einmal ausgetauscht.
Man startet mit einer 10 GB Installation und auch ohne neue Apps hat man ein paar Jahre später plötzlich 20, 30 oder 40 GB voll.

In Zeiten von Windows XP und Server 2003 hätte ich dann einen Slipstream- Integration aller Updates + Neuinstallation empfohlen, womit man das “neueste” Windows inklusive Updates aber ohne Dreck von gestern hat. Siehe nLite.

Seit Vista und Windows 7 sind Komponenten und Updates strukturierter gespeichert und es wurde auch eine verbesserte “Festplattenbereinigung” nachgeliefert, mit der man auch den Update-Store bereinigen konnte.

Doch solche UI-Tools findet man z.B. auf den Server-Core Varianten leider nicht.

Ab Windows 8 und vor allem mit Windows 10 sind dann jede Menge sehr hilfreiche Funktionen in das Tool dism und die DISM-API eingeflossen.

Neben der früher geschilderten RestoreHealth-Funktion gefällt mir auch besonders:

1dism /Image:C:\ /Cleanup-Image /StartComponentCleanup /ResetBase

Denn dieses Kommando veranlasst Windows seinen Update-Store aufzuräumen und alle früheren Komponenten Versionen und Update-Backups zu löschen. Man kann danach zwar keine Updates mehr zurücknehmen, hat aber ein schlankeres Windows, mehr Festplattenplatz und vielleicht sogar ein paar Performancegewinne (je nach tragweite).

Das ganze funktioniert aber nur, wenn die Windows Installation nicht läuft. Die Lösung: Man bootet Windows PE und startet dism von dort aus.

Da Windows PE auch die Basis einer jeden Windows Installationsmediums ist, startet man einfach dieses und wählt dort die Computer-Reparatur-Werkzeuge. Dort kann man ein Konsolenfenster öffnen und muss jetzt nur noch herausfinden, welchen Laufwerksbuchstaben Windows PE der normalen Windows-Installation zugeorndnet hat. Das kann c:\ sein, aber auch etwas höheres, falls mehrere Festplatten oder Partitionen im System vorhanden sind.

Nun startet man dism mit dem korrekten Laufwerk … und dann kann man was anderes tun, denn der Schritt kann von 10 Minuten bis über eine Stunde dauern.

Unter Windows PE braucht dism ein “Scratch-Directory” für temporäre Dateien, doch dafür kann man auch das Laufwerk der Windows-Installation angeben, wenn darauf ein paar Gigabytes frei sind.

Das finale Kommando lautet damit z.B.:

1dism /Image:C:\ /ScratchDir:C:\Scratch /Cleanup-Image /StartComponentCleanup /ResetBase

Fazit

Mein Beispiel war meine Server 2016 Backup-Installation. Die startete mit 10 GB und wuchs dann mit Windows Updates bis auf 24 GB an.

Ein dism Cleanup-Image verkleinerte die Installation auf 15 GB.
Das dauerte auf meinem Intel Atom zwar zwei Stunden, aber das war es wert.

Ein Cleanup-Image optimiert nicht nur die eigene Installation, es reduziert auch Images, die per SYSPREP auf ein Deployment vorbereitet werden.

Dass man parallel mit dism auch Treiber oder andere Windows Features installieren und deinstallieren kann, ist natürlich auch kein Geheimnis.

Wenn ich bedenke, wie wenig dism in Windows 7 konnte und es mit heute vergleiche, zeigt sich diesmal:

Früher war doch nicht alles besser.

Es ist eine Schande

2021-10-26T13:00:00+02:00

Österreich ist frei …

… von jeder Art von Anstand.

Heute ist Nationalfeiertag und ich kann nichts weiter tun als mich für die Vertreter meines Landes gehörig zu schämen.

In Folge 9 aus Staffel 16 der Serie South Park mit dem sprechenden Titel “Raising the Bar” (deutsch: Ein hohle Bar) ging es darum, was passiert, wenn “das Niveau” der Menschen und der Medien stets gesenkt wird.
Aus heutiger Sicht erscheint mir diese Episode wie eine Parabel zur aktuellen Lage der Nation.

Während man sich z.B. im Spitzensport bemüht stets besser zu werden, in dem man sprichwörtlich “die Latte höher legt”, findet in der Politik offenbar ein gegenteiliger Prozess statt:
Man redet sich ein, dass schon immer alle korrupt waren und es deshalb ohnehin egal ist.

In den vergangenen 20 Jahren hätte Österreich 5 Legislaturperioden von 5 Jahren (anfangs waren es nur 4 Jahre) haben sollen. Geworden sind es 7 und nur 2 mal wurde der Koalitions-Pakt eingehalten, für den wir Steuerzahler kräftig in die Tasche greifen dürfen:

Regierung	Bruch	Pseudo-Motto
2000 - 2002	Ja	Wir sehen uns in Knittelfeld
2002 - 2006	Nein	Händ’ falten, Goschn halten
2006 - 2008	Ja	Willi sagt: Es reicht!
2008 - 2013	Nein	Ohne-Wachteleier-Koalition
2013 - 2017	Ja	Zug fährt ab
2017 - 2019	Ja	A b’soffene G’schicht
2019 - 2022?	Bald?	Es gilt die Unschuldsvermutung

Als Bundespräsident Alexander Van der Bellen den Ibiza-Skandal mit den Worten

So sind wir nicht!

kommentierte, war das Kind schon in den Brunnen gefallen.
Denn da hat es angefangen, dass niemand Verantwortung übernehmen wollte, und eine Pressekonferenz nach der anderen gegeben wurde, in der nicht der schändliche Inhalt des Videos kritisiert wurde, sondern dessen Entstehung.

Wenn man sich nur scheinbar entschuldigt, um im Folgesatz eine Täter-Opfer-Umkehr zu skizzieren, wird die Entschuldigung entwertet.
Man stelle sich z.B.: vor, ein Vergewaltiger sagt:

Ja, es tut mir leid, ich hätte sie nicht zwingen sollen.
Aber sie wollte es ja eigentlich so.

Ein jeder wird mir zustimmen, dass der zweite Satz deutlich zeigt, dass keine Schuld und keine Reue beim Täter eingestanden wird.
Und genau so war es bei unseren damaligen Vizekanzler.

2021 setzt einen drauf und es heißt jetzt unverblümt:

Die Justiz ist korrupt (weil sie gegen uns ermittelt).

What-the-fuck?
Also ganz ehrlich … hier bin ich wirklich ratlos.

Dass “meine” Regierung, die von mir mitbezahlt wird und die “meine” Verfassung schützen soll, jetzt die Legitimität der Justiz angreift um das eigene Verschulden von nachgewiesener Korruption umzudeuten, ist einfach nur pervers.

Niemand bestreitet aktuell die Echtheit der veröffentlichten Chat-Nachrichten, wo Umfragen und damit Wahlmanipulation besprochen wird und dass die Sache über das Finanzministerium “abgerechnet” wurde.
Und niemand bestreitet zur Zeit, dass die Verhinderung der Einrichtung von Nachmittagsbetreuungsstätten für Kinder nur deshalb zu Fall gebracht wurde, damit man dem politischen Vorgänger “eins auswischen konnte”.

Die Redaktion der Zeitung Standard hat die Chats in einem Video kurz zusammengefasst:

Selbstverständlich gilt immer die Unschuldsvermutung. Das war bei Lucona anfangs auch so.

Und trotzdem stellen sich führende Persönlichkeiten aus Bund und Ländern vor die Kamera und konstruieren zielgerichtet eine Verschwörung gegen die eigene Partei.

WOW. Danke an die Politik! Jetzt habt ihr es wirklich geschafft!

Wer soll euch denn jetzt auch nur irgend welche Kompetenzen zuordnen, damit ihr unser Land regieren dürft?
Was sagen wir denn jetzt den immer größer werdenden Gruppen von Reichsbürgern und Neonazis, die immer selbstbewusster durch die Straßen marschieren?
Was sagen wir den Verschwörungstheoretikern, die eine Chip-Implantation der Regierung in jeder Impfspritze daherfabulieren?

Es ist schwer jemand anderen der Falschaussage zu bezichtigen, wenn man selbst nicht die Wahrheit spricht.

Ich habe gehört: Früher war Österreich

ein Land der Musik
ein Land der Dichter und Autoren
ein Land des Dialogs zwischen Ost und West
und ein Garant für Rechtsstaatlichkeit

Und was assoziiert die Welt heute mit uns?

Bei denen waren nur die Pferde und nicht ihre Reiter bei der Waffen-SS.
Die sperren ihre Kinder in Kellern ein und betreiben Inzest.
Die tarnen den Kühnengruß mit einer Bierbestellung.
Die wollen Asylwerber “konzentriert an einem Ort halten”, Zitat H. Kickl.
Sie verkaufen ihr Hab und Gut an russische Oligarchen auf Ibiza
Und sie bezahlen Umfragenfälschungen mit Mitteln aus der Korruptionsbekämpfung.

Und dann heißt es: Das sei doch alles nicht so schlimm und “eh normal” ?

Fazit

Ich schäme mich.

Nicht nur für die handelnden Akteure, sondern auch für alle Mitmenschen, die der Aufklärung mit billiger Propaganda entgegenwirken und die die kritische Sachlage dazu missbrauchen wollen, ihre antidemokratischen Meinungen zu verbreiten.

Skandale gab es immer schon. Und jeder Verbrecher hat zu jeder Zeit versucht, seine Schuld abzuwälzen oder klein zu reden.
Doch warum stören sich immer weniger Menschen daran und halten es für normal? Die heutige Zeit des Medien- und Informationsüberflusses bewirkt damit leider zusätzlich, dass Aufklärung gebremst und teils auch verhindert wird.

Ich wünschte, ich wüsste eine Lösung dagegen.
… aber selbst der neueste C++ Standard kann absichtlich hervorgerufene Datenkorruptionen nicht verhindern.

Letztendlich ist es leider genau so, wie es seinerzeit im Muscial “Elisabeth” besungen wurde, und was ich hiermit nur zitieren kann:

Na und wenn schon!
Wir sitzen im Kaffeehaus rum.
Und erwarten gähnend die Apokalypse.

Your browser does not support the HTML5 VIDEO tag.

Trotzdem wünsche ich allen Mitbürgern einen schönen Feiertag, und etwas Zeit zum Nachdenken.

PS: Botschaft an mich selbst in 10 Jahren:

Und? Wie ist die Sache ausgegangen?
Denkst du immer noch mit Kopfschütteln and diese Zeit zurück?

Raspberry PI im Akkubetrieb

2021-10-24T13:00:00+02:00

Das “RPi-PowerPack” ist ein Board mit einem LiPo Akku, der einen Raspberry PI 2 und 3 B eine Zeit lang bestromen kann.

Doch diese Board hat einen unguten Fehler:
Beim Umschalten zwischen externem Aufladen und reinem Akkubetrieb, gibt es einen kurzen Stromaussetzer, der einen ungewollten Reboot (und eventuell Datenverlust) einleitet.

Wenn es nur darum ginge, einen Raspberry PI mit Akkustrom zu betreiben, dann hätte das Board alles richtig gemacht.

Die 3.7 Volt des LiPo Akkus werden auf 5 V hochge-boost-et und per USB Kabel in den RPi eingespeist.

Doch wenn man das Board selbst an eine Stromversorgung anschließt um den Akku aufzuladen, kommt es zum ungewollten Reboot des Boards.

Dieses Problem haben auch schon einige andere Bastler erkannt und festgestellt, dass es an einem zu klein dimensionierten Kondensator liegt.

Da die Stromunterbrechung nur kurz beim Umschalten des Ladechips auftritt, kann ein Kondensator mit höherer Kapazität diese Manko beheben, womit aus dem “PowerPack” eine UPS (Uninterrupted Power Supply), zu deutsch USV (unterbrechungsfreie Stromversorgung), wird.

Mit 220 Millifarad sollte das Schlimmste überwunden werden, und dafür gibt es sogar eine 3D-Druck-bare Halterung auf Thingiverse.

Doch ich bin skeptisch, ob 220 mF wirklich ausreichen, wenn man weitere Geräte angeschlossen hat und der R-Pi unter Volllast steht. Und deshalb habe ich meinen stärksten Kämpfer aus der Kondensator-Schachtel geholt: Einen 5.5V 4F Super-Kondensator

Diese Teile können wirklich viel Strom speichern und sind damit theoretisch 18 mal stärker als die 220 mF Variante.

Man lötet die Plus und Minus-Pole des zusätzlichen Stützkondensators einfach beim obersten der kleinen SMD-Kondensatoren am Board dazu und hat somit die Kapazität um ein Vielfaches gesteigert.

Ein paar Tropfen aus der Heißklebepistole sorgen dafür, dass der Kondensator und seine Verkabelung fixiert sind und schon kann man seine neue Raspberry-Pi UPS in Betrieb nehmen.

Nun kann der R-Pi je nach Auslastung die eine oder andere Stunde frei im Raum herumgetragen werden, bevor er wieder ans USB Netzteil gesteckt werden muss. Ohne Stromunterbrechung und Reboot kann man das Gerät nun z.B. zu einem Sensor oder einer MCU im Nebenzimmer tragen, dort Daten abholen lassen und sorgenfrei wieder zurückkehren.

Auch ein auf den R-Pi draufgesetztes LCD-Display kann so problemlos mitbestromt werden.

Fazit

Mit der Kapazität habe ich es wohl etwas übertrieben. Ich hätte auch einen 670 mF Kondensator in der Kiste gehabt, aber hey … überdimensionierte Kondensatoren schaden hier nicht, unterdimensionierte sehr wohl.

Ein Nebeneffekt ist, dass das RPI noch für 1 bis 2 Sekunden nach Abschaltung Strom aus dem Kondensator ziehen kann, bis er ausfällt. Aber es ist generell eine schlechte Idee den RPi nicht korrekt herunterzufahren, bevor man ihm den Strom entzieht.

Aber ich freue mich, dass man mit 5 cm Draht, einem Kondensator und zwei Lötzinntropfen einen “Konstruktionsfehler” so leicht beheben kann.

Unit Tests

2021-10-23T13:00:00+02:00

Unit tests sind in der Entwicklung ein notwendiges Übel, weil die Vorgesetzten es als Funktionsbeweis haben wollen.

So habe ich es viele Jahre gesehen und auch heute erscheinen mir manche Testanforderungen nur als lästige Bürokratie, die selten wirklich etwas “abtestet”.

Doch nun beweist mir meine eigene Fehlbarkeit, dass Unit Tests IMMER eine Existenzberechtigung haben.

Es gibt einen Grund, warum ich Unit Tests immer etwas skeptisch gegenüberstand: In meiner Welt sind Codes ziemlich System-spezifisch und nur relativ schwer in Tests zu fassen.

Wie soll ich denn z.B. direkte Festplattenzugriffe “effektiv” abtesten. Oder wie soll die korrekte Funktion eines Windows-Service Starts oder eines Linux-Daemon Forks verifiziert werden?
Da kann man gleich return true schreiben, denn die “echten” Fehler findet man nur beim Debugging oder in Crash-Reports.

Das ist in vielen Business-Anwendungen anders, wo im Endeffekt immer nur Daten hin und her-konvertiert werden. Denn da kann man einen künstlichen Input und erwarteten Output “leicht” durch die selbst geschriebene Funktion jagen und vergleichen. Ein solcher Unit test wird dann schnell Fehler in Algorithmen und Mappings aufzeigen können.

Doch genau das ist bei System-nahen Routinen weniger einfach und wenn das Abtesten den 10-fachen Aufwand des Quellenschreibens ausmacht, schwindet meine Motivation dafür deutlich.

Interface-Stabilität und Regression Tests

Wenn man eine Schnittstelle auf mehreren Plattformen implementiert um dadurch eine OS-Abstraktion zu erhalten, ist es essentiell, dass die Schnittstelle auf jeder Plattform das exakt gleiche Verhalten aufweist und sich dieses über die Zeit auch nicht ändert.

Schnell kann es passieren, man mal meint:

Ich füge da ein kleines Feature hinzu, aber das ist ungefährlich, es ändert sich nichts für bestehenden Code.

Und 1 Monat später hat man den A*sch offen, weil sich dennoch Seiteneffekte ergeben haben und die Resultate einfach nicht mehr stimmen.

Problematisch sind auch nicht konkret dokumentierte Erwartungen gegenüber Funktionen und Daten.
Mir ist nämlich folgendes passiert:

Die gate_atomic_* Funktionen stellen atomare Integer-Operationen bereit und wurden zuerst für Windows implementiert, wo die Interlocked-APIs zum Einsatz kamen. Einige davon geben als Return-Value den aktuellen Wert einer Variable zurück, andere geben den Wert vor der Operation zurück.

Als dann später die GCC Implementierung folgte, nahm ich bei einigen Funktionen ein Verhalten identisch zu Windows an und implementierte es auch so. Doch leider arbeitet der GCC hier teilweise anders.

Genau an der Stelle hätte nun ein ordentlicher Unit Test sofort ein Interface-Problem angezeigt. Doch ohne diesen Test verbrachte ich Monate später zahlreiche Stunden um einen Crash zu verstehen, der sich aus falsch interpretierten atomic-Aufrufen ergeben hatte.

Lektion gelernt: Immer Tests schreiben!

Test Frameworks

BOOST bietet mit seinem Test-Framework ein großes Set an Makros und Funktionen, um eigene Tests effizient schreiben und ausführen zu können.

 1#include <boost/test/unit_test.hpp>
 2
 3BOOST_AUTO_TEST_CASE(test_name)
 4{
 5  int expected_value = 42;
 6  int received_value;
 7  BOOST_REQUIRE_NO_THROW(
 8    received_value = func_to_be_tested();
 9  );
10  BOOST_CHECK_EQUAL(received_value, received_value);
11}

Test Cases werden über die Makros zu Klassen und Methoden und während REQUIRE Makros per Exception einen Test abbrechen, laufen CHECK Makros einfach durch, zählen aber Fehler mit, damit man sie am Ende gesammelt ausgeben kann.

GATE Implementierung

In C hat man das Problem, dass man keine Exceptions kennt und nicht eine Funktion “einfach so” abbrechen kann und danach zurückspringen kann. (Ich lasse setjmp/longjmp hier mal bewusst weg.)

Daher definiere ich eine Test-Routine als Funktion, die einen Boolean zurückgibt und nur beim vollständigen Durchlauf mit return true endet. Fehler führen zu einem return false. Auf diese Weise kann man zumindest auf einer Ebene auch REQUIRE und CHECK Makros etablieren.

Nun müssen ein paar Funktionen definiert werden, die Tests und Fehler hochzählen und einem registriertem Test zuordnen können. Dafür reichen einfache globale Variablen, denn jede Test-Funktion muss am Anfang ihren Namen registrieren und alle nachfolgenden Zählungen werden so lange dem Test zugeordnet, bis ein anderer Test startet.
Wie in BOOST kann immer nur ein Test gleichzeitig laufen.

 1#define GATE_TEST_STR(expression) #expression
 2#define GATE_TEST_UNIT_BEGIN(name) \
 3  gate_test_unit_begin(GATE_TEST_STR(name), __FILE__, __LINE__)
 4
 5#define GATE_TEST_UNIT_END \
 6  return true
 7
 8#define GATE_TEST_CHECK(expression) \
 9  do \
10  { \
11    gate_test_count_test(); \
12    if( ! (expression) ) \
13    { \
14      gate_test_count_error(); \
15      gate_test_error_message( GATE_TEST_STR(expression), \
16        __FILE__, __LINE__ ); \
17    } \
18  } while(0)
19
20#define GATE_TEST_REQUIRE(expression) \
21  do \
22  { \
23    gate_test_count_test(); \
24    if( ! (expression) ) \
25    { \
26      gate_test_count_error(); \
27      gate_test_error_message( GATE_TEST_STR(expression), \
28        __FILE__, __LINE__ ); \
29      return false; \
30    } \
31  } while(0)

Mit diesem Set an Makros, kann man schon seinen ersten Test schreiben:

 1#include "gate/test.h"
 2
 3gate_result_t func_to_be_tested(int* ptr_output);
 4
 5static gate_bool_t test_someting()
 6{
 7  int expected_value = 42;
 8  int received_value;
 9
10  GATE_TEST_UNIT_BEGIN(test_someting);
11
12  GATE_TEST_REQUIRE(
13    GATE_RESULT_OK == func_to_be_tested(&received_value)
14  );
15  GATE_TEST_CHECK(received_value == expected_value);
16
17  GATE_TEST_UNIT_END;
18}

Fazit

Das ganze steht noch am Anfang und wird sicher noch einige Updates erfahren. Und wenn man die Ergebnisse am Ende in einem handelsüblichen Format, wie z.B. JUnit als XML ausgibt, dann kann man auch bestehende Tools zur Überprüfung und Anzeige der eigenen Ergebnisse einsetzen.

Natürlich würde es auch Sinn machen, hier auf eine bestehende Lösung zu vertrauen und im Beruf sehe ich das als unbedingt notwendig.

Doch im GATE Projekt geht es mir ja auch darum zu lernen, wie man solche Frameworks selbst aufbaut und unabhängig von Megabyte großen Runtimes auch zu annehmbaren Ergebnissen kommen kann.

Mini-UPS

2021-10-17T13:00:00+02:00

Stromausfälle sind in Wien verdammt selten. Das passiert vielleicht alle 10 Jahre mal, wenn ein Stromzähler getauscht werden muss. Ansonsten kann ich mich an keine Unterbrechung erinnern.

Aber … was wäre wenn? Und wäre es nicht toll, wenn man ein Gerät an einen anderen Ort versetzen kann ohne seinen Betrieb zu unterbrechen?

Die Lösung heißt UPS (Uninterrupted Power Supply) bzw. Unterbrechungsfreie Strom-Versorgung (USV).

22 Watt aus dem Akku

Und wieder einmal findet man im Land der aufgehenden Sonne die kostengünstigste Lösung, wo man für etwa 12 Euro einen Lithium-Ionen Akku mit 12V und 2 Ampere zwischen das Netzteil und z.B. einen Router stecken kann.

Bei der geringen Stromaufnahme hält der Akku den Router für mindestens eine Stunde problemlos am Laufen. Natürlich gibt es diesen Mini-UPS Typ auch für 9V und 5V Geräte.

Für mich ist der kleine Stromspeicher für den Internet-Zugang relevant. Sollte plötzlich der Strom weg sein könnte ich schnell auf meinen voll geladenen Laptop ausweichen, der mich ein paar Stunden arbeiten lässt, doch ohne Internet wird das langweilig.
Die UPS lässt mich also noch im Internet nachsehen, warum die Welt gerade untergeht.

Leider noch kein ITX Support

Meine ITX Mainboards brauchen nie über 20 Watt und werden alle durch 12 V Netzteile gespeist. Da lag die Überlegung nahe auch sie durch eine Mini-UPS abzusichern.

Doch da haben mir die Hersteller einen kleinen Strich durch die Rechnung gemacht. Mir ist bisher nicht aufgefallen, dass es bei den typischen runden DC-Stromsteckern Abweichungen gibt.

Geräte wie Router nutzen oft einen Stecker mit 5.5 mm Außendurchmesser und 2.1 mm Innendurchmesser.
Doch meine ITX Mainboards und ihre Netzteile erwarten einen Stecker, der innen 2.5 mm Hohlraum aufweisen muss.

Und nachdem die Mini-UPS nur mit 2.1 mm Stecker geliefert wird, kann ich sie auch nicht mit Gewalt in die Buchse des Mainboards bekommen.

Doch die Lösung ist einfach: Wir bestellen solche Stecker einfach nach und in ein paar Wochen wird das Experiment voraussichtlich starten, in dem ich dann auch ein ITX Mainboard von der UPS aus betreibe.

Fazit

Tja, geniale Dinger, diese kleinen Stromspeicher. Jetzt kann ich erstmals problemlos durch die Wohnung laufen und den besten Ort für meinen 5G Empfang suchen.

Gespannt bin ich vor allem, ob die ITX Boards damit starten können … denn beim Einschalten halte ich es zumindest für möglich, dass eine Stromspitze entsteht, die der Akku nicht stabil liefern kann.

Nachtrag

Und ja, es funktioniert! Mit dem richtigen Stecker kann die Mini-UPS-Box auch meine Intel Atom ITX-Boards zumindest für 5 Minuten bestromen. Das ist zwar nicht viel, aber einen kurzen Stromausfall kann ich somit überwinden.

Pixel Fonts

2021-10-16T13:00:00+02:00

Schriftarten (auch “Fonts” genannt) sind heute eine komplexe Sache. Alles ist vektorisiert und die Zeichen orientieren sich an mehreren Linien um Schleifen Punkte und Striche auf der richtigen Höhe im Verhältnis zu den anderen Zeichen zu setzen.

Früher hatten wir feste Schriftarten, die es in ein paar Größen gab und in denen Zeichen für Zeichen und Pixel für Pixel fix gespeichert waren.
Denn so etwas kann man nämlich sehr leicht selbst implementieren.

Als Minimalist bin ich immer wieder schockiert, wenn man die Aufgabe:

Wir müssen auf ein Foto noch eine Information wie Ort und Datum draufdrucken.

so interpretiert, dass man eine zig-MB große Library mit unnötig komplexen Schriftarten und deren Lizenzen an sein Programm binden muss.

Ich verstehe natürlich, dass man in Falle der Internationalisierung nicht für jedes Zeichen von Runen bis Hieroglyphen alles selbst implementieren kann, doch gerade bei diesen 0815 Tasks wie z.B.: Datum auf ein Bild draufschreiben, hat man das auch selbst in einigen Minuten implementiert und damit jede Menge Abhängigkeiten gespart.

Und daher findet sich eine solche Pixel-Font auch im GATE Projekt.

Pixel Bits als C struct

C unterstützt ein Feature, auf das gerne vergessen wird: Bitfelder.
Man kann in einer Struktur bei einem Integer angeben, wie viele Bits dieser belegen soll. Der Compiler legt dann die Bits in einen Datenblock zusammen und holt bei Zugriffen genau die richtigen Bits heraus.

Das kann man natürlich mit AND und OR Verknüpfungen auch selbst tun, doch mit Bitfeldern arbeiten wir so, als hätten wir einen Integer und der Compiler erledigt den Rest.

Das tolle dabei ist: Wir können dann mit einer struct quasi “Bits malen”, ohne kryptische Hex-Zahlen einsetzen zu müssen. Und wenn man ein Bit mit einem sichtbaren Pixel gleichsetzt, kann man so ein Zeichen visuell in Sourcecode abbilden.

Aus Byte-Sicht “schöne” Ausmaße hat eine 8x8 Pixel Schrift. Man definiert eine C struct für die Bit-Member einer Zeile und erstellt daraus ein C-Array von Zeilen um einen Buchstaben darstellen zu können:

 1typedef struct gate_font_char_row8_bits
 2{
 3  unsigned char c1 : 1;
 4  unsigned char c2 : 1;
 5  unsigned char c3 : 1;
 6  unsigned char c4 : 1;
 7  unsigned char c5 : 1;
 8  unsigned char c6 : 1;
 9  unsigned char c7 : 1;
10  unsigned char c8 : 1;
11} gate_font_char_row8_bits_t;
12
13static gate_font_char_row8_bits_t const font8x8_A[8] = {
14  { 0,1,1,1,1,0,0,0 },
15  { 1,0,0,0,0,1,0,0 },
16  { 1,0,0,0,0,1,0,0 },
17  { 1,1,1,1,1,1,0,0 },
18  { 1,0,0,0,0,1,0,0 },
19  { 1,0,0,0,0,1,0,0 },
20  { 1,0,0,0,0,1,0,0 },
21  { 0,0,0,0,0,0,0,0 }
22};

Man braucht zwar etwas Augen-Übung, aber dann kann man erkennen, dass die 1 Bits den Buchstaben A im Beispiel formen.

Jede gate_font_char_row8_bits_t Zeile belegt ein Byte (also 8 Bits), womit man die Struct auch nach unsigned char casten kann.

Und wenn man nun noch zwei Schleifen baut, die für y und x von 0 bis 8 laufen, reicht ein set_pixel() Aufruf um jene Pixel zu zeichnen, wo das aktuelle Bit auf 1 steht.
… fertig ist der Font-Renderer.

Mit dem Bitfield-Trick lassen sich somit Schriftarten ganz leicht direkt in den C Code einbetten.
Und das machen einige andere Libs (z.B.: aus der Arduino Welt) ebenfalls so.

Fazit

Ich finde es schade und teilweise dumm, dass Entwickler heute lieber 3 Tage im Netz nach einer Bibliothek suchen, die ein Datum auf ein Rasterbild schreiben kann, nur weil der Code per Copy & Paste integriert werden soll und dann eine 200 MB Runtime im Schlepptau hängt.

Es stimmt schon, dass nicht jeder das Rad neu erfinden soll, aber die Tatsache, dass so gut wie niemand mehr weiß und wissen möchte, wie man solche einfachen Aufgaben selbst löst, ist das andere Extrem, das ebenso schlecht einwirkt.

Ich füge meine Zeichen von A bis Z in groß und klein daher ins GATE Framework ein und wenn man diese Pixel-Font in einer App nicht benutzt, merkt das der Compiler und nimmt den Inhalt der statischen Bibliothek auch nicht weiter auf.

Jetzt kann ich z.B. die Fotos meiner Webcam, die als Sicherheitskamera umfunktioniert wurde, sofort mit Infos “signieren”, bevor sie ins Netz geschickt werden, ohne dass ich eine Font oder Zusatz-Lib mit ausliefern muss.

IDE Adapter und Alternativen

2021-10-10T13:00:00+02:00

Ich dachte eigentlich, dass meine alten IDE (P-ATA oder auch ATAPI) Festplatten schon alle tot sind. Aber stimmt nicht, viele Festplatten funktionieren tatsächlich noch, und das nach 15 Jahren.

Trotzdem ersetze ich nun die unerträglich lauten und langsamen Teile durch Flash-Speicher Varianten.

Ich habe ja schon vor zwei Jahren die ersten IDE-SSDs bestellt, deren Speicher “klein” genug war, damit meine alten Mainboards damit leben konnten.
Das funktioniert auch super auf DOS und Windows 3.X Systemen, macht aber auf 32-Bit Systemen manchmal Schwierigkeiten.

Beim Start von Windows 95 und 98 traten nach deren Installation Bluescreens auf, dass das Medium “read-only” und unbenutzbar sei.
Beim Reboot war die IDE-SSD dann gar nicht mehr detektierbar, nur eine Stromunterbrechung machte das Gerät wieder betriebsbereit, bis Windows es wieder verschwinden ließ.

Also habe ich nach Alternativen gesucht, wie ich meine alten Boards mit modernen Speichermedien betreiben kann.

CompactFlash (CF) Karten IDE Adapter

Zu ihrer Blütezeit (1995 - 2005) bin ich mit ihnen nie in Kontakt geraten und danach wurden sie schnell durch SD-Karten ersetzt. Es handelt sich dabei ebenfalls um Flash-Speicher-Karten nur mit größerem Gehäuse und mit einem IDE-Bus.

Man braucht also nur einen Adapter der die schmalen Pins ihres Anschlusses auf die üblichen 40-Pin IDE Stecker übersetzt und schon funktioniert eine CF-Karte wie eine Festplatte.

Da sie keiner mehr braucht, kosten die kleineren Modelle in Fernost mit 8 - 16 GB heute um die 10 Euro und der Adapter um die 2 Euro.

Sie sind lautlos und schneller als herkömmliche mechanische Festplatten aus dieser Zeit.

Ein Nachteil ist, dass manche Adapter oder Karten sich im System fix als “Removable-Drive” melden, womit Windows Caches deaktiviert, was ihre Performance senkt. Andere Karten tun, als wären sie richtige Festplatten … da muss man leider ein paar Hersteller ausprobieren, oder mit der etwas niederen Geschwindigkeit leben lernen.

Für mich ist die Lösung aber super, wenn ich kaputte oder zu laute Festplatten meiner 15 bis 25 Jahre alten Nostalgie-Rechner ersetzen möchte.

mSATA nach IDE Adapter

mini-SATA SSDs (die Vorläufer von M.2-SSDs) im 32 GB Bereich findet man auch schon ab 14 Euro. Legt man noch etwa 5 Euro drauf, bekommt man ein 2.5 Zoll Gehäuse dazu, das M-SATA in den 44-Pin Notebook IDE Standard übersetzt.

Das wiederum ist eine gute Lösung für Notebooks aus den Anfängen der 2000er Jahre, in denen solche IDE Platten verbaut waren. Natürlich kann man auch nur reine Adapter-Platinen bestellen (ohne das schöne Gehäuse).

Für normale PCs kann man für weitere 2 Euro noch einen 40-Pin IDE Adapter samt klassischem Molex Stromstecker bestellen und schon hat man quasi eine “echte” neue Festplatte für die alte Hardware.

Es gibt übrigens auch M.2 to IDE Adapter, nur ist IDE gemessen an SATA sehr langsam und es bringt daher aus meiner Sicht nichts, die besseren M.2 Chips in meine uralten PCs einzubauen. Streng genommen sind auch die M-SATA Varianten für meinen Anwendungszweck überdimensioniert.

SD-Karte nach IDE Adapter

So wie es für SATA-Ports Adapter zu SD-Karten gibt, existieren auch Konverter für IDE zu SD-Karten.

Billige Adapter-Boards findet man heute in China schon um 7 Euro und nachdem Micro-SD-Karten im 16 GB Bereich auch schon um 2-3 Euro zu haben sind, ist diese Variante am billigsten.

Außerdem kann man alte SD-Karten aus Smartphones auf diese Weise als Festplatten-Ersatz in antiken PCs recyclen.

Ich habe noch keine Langzeiterfahrung mit diesen Dingern, aber ich vermute mal, dass dieses Medium denkbar ungünstig ist, um davon ein Betriebssystem zu starten.
Denn die häufigen Zugriffe auf temporäre und Auslagerungsdateien wird die Lebensdauer der Karten schnell ablaufen lassen.

However … wenn man nur mal schnell seine alte Nostalgie-DOS-Umgebung aufleben lassen will, ist die SD-Karten-IDE-Festplatte vermutlich die kostengünstigste Variante … und Ersatz-SD-Karten findet man heute wirklich überall.

3D Druck Vorlagen

Damit CF- und SD-Adapter Platinen nicht einfach so im PC-Gehäuse herumpurzeln, macht es Sinn, sie wo zu montieren.

Wie so oft helfen ein 3D-Drucker und unsere geschätzten Bastler auf Thingiverse

Für CF-Karten Adapter findet man gleich ein paar Lösungen:

Einmal ein einfaches 3.5 Zoll Einschubgehäuse mit dem man vorne am PC die Karte leicht wechseln kann.
Das gleiche gibt es auch für ein 5.25 Zoll Einschubgehäuse
Oder man nimmt gleich zwei CF-Adapter und verbaut sie gemeinsam in einem 5.25 Zoll Einschubgehäuse in seinem PC.

Für den SD-Karten Adapter hat sich jemand eine kreative Lösung einfallen lassen, wo hinten am PC eine PCI- (oder ISA-) Slotblende mit der Platine verbunden werden kann.

Alternativ hat der SD-Adapter aber genau die Breite einer 2.5 Zoll Festplatte und kann somit auch auf eine 2.5 zu 3.5 Zoll Halterung draufgeschraubt werden.

Fazit

So, wieder ist ein Nostalgie-Sonntag vorbei und ich genieße die Stille von Flashmedien wirklich sehr.
Ich kann mir heute gar nicht mehr vorstellen, dass ich vor 20 Jahren stundenlang neben den damaligen surrenden und knatternden Festplatten saß und es mir nichts ausmachte.

Heute will Opa aber seine Ruhe haben und trotzdem das DOS-Prompt aus “den guten alten Tagen” sehen. Und genau dafür sind diese IDE Adapter ein wahrer Segen.

Einen Aspekt gibt es übrigens noch: Man kann die Adapter auch benutzen, um sie am zweiten IDE Port zu einem laufenden System (natürlich vor dem Boot) dazu zu hängen.
So kann man auf ganz alte Systeme Daten kopieren, wo man sonst nur mit gebrannten CDs Daten einschleusen könnte.

DOS Development

2021-10-09T13:00:00+02:00

OpenWatcom eröffnet mir also heute im Jahr 2021 ein Tor 30 Jahre zurück in die Vergangenheit, denn der Compiler unterstützt auch heute noch MS-DOS und Windows 3.x als Zielplattform.

Auf was muss man also achten, wenn man Programme für DOS schreiben will?

Ach … damals

Technisch betrachtet, war Turbo Pascal 6.0 der erste “richtige” Compiler, den ich je besessen hatte, den mir ein Hobby-Informatiker aus der Nachbarschaft kopiert hatte.
Doch da mir diese Sprache so “fern” war, tauschte ich es quasi auf dem Schulhof gegen QuickBASIC 4.5. Denn das abgespeckte QBasic von DOS kannte ich schon und dessen eingebaute “Befehlshilfe” lehrte mich damals meine ersten Programmiervokabel. QuickBASIC ließ mich dann die ersten EXE Dateien erzeugen.
Kurz danach folgte wegen der Schule wieder Pascal und dann kaufte ich mir Turbo-Assembler 4.0 um “DOS zu hacken”. (Meine parallelen VB-4 Erlebnisse sind Teil einer anderen Geschichte.)

Ich war damals schon von “antiker” Software mehr beeindruckt, als von moderner, da die alten Programme auf meiner veralteten gebrauchten Hardware immer “hoch-performant” lief und Windows immer nur träge wirkte. Und Linux hat mich wegen seines Schneckentempos damals so abgeschreckt, dass ich es auch Jahre später immer noch nicht anfassen wollte.

Es ist beeindruckend, was man damals in 64 KB großen Programmen alles unterbringen konnte, wo heute zig Megabytes nicht ausreichen.

Realmode DOS und Speichermodelle

C und C++ habe ich unter DOS damals nie kennen gelernt. Zwar stolperte ich auch über Turbo C++, konnte damit aber nichts anfangen. Außerdem hielt ich damals ja alle Sprachen, die Groß-Kleinschreibung unterschieden für pervers.

Um 2009 fand ich parallel zu Watcom auch den DJGPP, eine GCC Portierung für DOS, den ich aber (auch mangels einer für mich “einfachen” IDE dafür) nie betreiben konnte.

Das Problem: Für C++ ist DOS nicht gleich DOS.

Die ältesten Compiler (wie auch Turbo C/C++) sehen DOS als reine X86-Realmode Umgebung. Dort herrschen verschiedene Speichermodelle vor:

Name	Description
Tiny	COM: nur 64 KB für Code, Daten und Stack
Small	EXE: 1 x 64 KB Code, 1 x 64 KB Daten
Medium	EXE: n x 64 KB Code, 1 x 64 KB Daten
Compact	EXE: 1 x 64 KB Code, n x 64 KB Daten
Large	EXE: n x 64 KB Code, n x 64 KB Daten
Huge	EXE: n x 64 KB Code, bis zu 1 MB Daten

Ein Segment kann im Real-Mode nur 64 KB groß sein und da es nur ein Code und ein Daten-Segment Register gibt (Das ES Register zählt hier noch nicht), muss man sich entscheiden, ob das Programm mehrere Segmente ansteuern können soll oder nicht.

Braucht man mehr als 64 KB Code, muss das CS Register bei Sprüngen wechseln, und Code-Pointer sind dann 32 bit breit und nutzt FAR Calls, aber wenn 64 KB reichen, hat man nur ein Code-Segment, die Code-Pointer sind 16 bit breit und werden durch NEAR Calls angesprungen.

Bei den Daten verhält es sich ähnlich und weil größere Pointer mehr Rechenzeit und Platz verbrauchen, musste der Entwickler schon beim Programmieren in etwa wissen, gegen welches Speichermodell er kompilieren will.

Dass C++ std Allokatoren unter anderem auch ein Überbleibsel aus diesem Dilemma sind, ist heute schon in Vergessenheit geraten. Es macht eben einen Performance- und Reichweiten- Unterschied aus, ob ein std::vector intern einen NEAR oder FAR Pointer typedef nutzt. Und zusätzliche Allokatoren konnten diese Grenze überwinden.

DOS Protected Mode

Die meisten C und C++ Compiler wechselten in den 90er Jahren zum DOS Protected Mode Interface und waren damit in der Lage ein 32-Bit Flat-Memory-Model zu nutzen. Und so konnten DOS-Programme (wie heutige Software) den ganzen verfügbaren RAM nutzen, sie nutzten 32-bit Pointer in genau einem Code und einem Datensegment und alles war gut.

Das wahre Problem der Technik wurde vom Compiler gut versteckt: nämlich das andauernde Hin- und Herwechseln zwischen Real-Mode und Protected-Mode.
Denn DOS Funktionen waren nicht 32-Bit tauglich und sobald z.B. eine Datei geöffnet wurde, musste:

ein 32-Bit Aufruf den Prozessor in den 16-Bit Mode schalten,
ein DOS Interrupt aufgerufen werden und dessen Ergebnis zwischengespeichert werden,
in den Protected Mode zurück gewechselt werden,
und das Ergebnis in die 32-Bit Welt import werden.

Der ganze Zirkus war auch für Hardware-Interrupts notwendig, womit sicher einiges an Performance verloren ging.

Doch DOS Spiele hatten keine andere Wahl, weil sie mit den segmentierten 64 KB Blöcken einfach nicht auskamen. Deshalb findet man bei ihnen immer eine dos4gw.exe Datei oder einen anderen 32-Bit Extender, der diese Funktion implementiert hat.

CMake für Watcom DOS Builds

Unglaublich, aber wahr: CMake unterstützt OpenWatcom. Im Standard werden zwar nur für NT Binaries erstellt, aber mit ein paar Klicks mehr, lässt sich der 64-Bit Compiler überzeugen am anderen Ende 16-Bit Code zu generieren.

Am besten installiert man OpenWatcom 2 genau so wie vom Setup vorgeschlagen. Damit landen alle Dateien in C:\WATCOM und CMake findet alles selbstständig.

Wenn man in der CMake GUI den Generator Watcom WMAKE auswählt, muss man für DOS-Builds die Option Specify options for cross-compiling aktivieren.

Im folgenden Dialog genügt es beim Feld Operating System einfach DOS einzutragen, was der CMAKE-Variablen CMAKE_SYSTEM_NAME entspricht.

Danach richtet CMAKE automatisch den Compiler ein.
Die wichtigsten CMAKE Variablen sind hier aufgelistet.

CMAKE Variable	Value
CMAKE_AR:FILEPATH	C:/WATCOM/binnt64/wlib.exe
CMAKE_CXX_COMPILER	C:/WATCOM/binnt64/wcl386.exe
CMAKE_CXX_FLAGS	-w3 -bt=dos -xs
CMAKE_CXX_FLAGS_DEBUG	-d2
CMAKE_CXX_FLAGS_MINSIZEREL	-s -os -d0 -dNDEBUG
CMAKE_CXX_FLAGS_RELEASE	-s -ot -d0 -dNDEBUG
CMAKE_CXX_FLAGS_RELWITHDEBINFO	-s -ot -d1 -dNDEBUG
CMAKE_C_COMPILER	C:/WATCOM/binnt64/wcl386.exe
CMAKE_C_FLAGS	-w3 -bt=dos
CMAKE_C_FLAGS_DEBUG	-d2
CMAKE_C_FLAGS_MINSIZEREL	-s -os -d0 -dNDEBUG
CMAKE_C_FLAGS_RELEASE	-s -ot -d0 -dNDEBUG
CMAKE_C_FLAGS_RELWITHDEBINFO	-s -ot -d1 -dNDEBUG
CMAKE_EXE_LINKER_FLAGS	opt map system dos4g
CMAKE_EXE_LINKER_FLAGS_DEBUG	debug all
CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO	debug all
CMAKE_LINKER	C:/WATCOM/binnt64/wlink.exe
CMAKE_MAKE_PROGRAM	wmake
CMAKE_MODULE_LINKER_FLAGS	opt map system dos4g
CMAKE_MODULE_LINKER_FLAGS_DEBUG	debug all
CMAKE_MODULE_LINKER_FLAGS_RELWITHDEBINFO	debug all
CMAKE_SHARED_LINKER_FLAGS	opt map system dos4g
CMAKE_SHARED_LINKER_FLAGS_DEBUG	debug all
CMAKE_SHARED_LINKER_FLAGS_RELWITHDEBINFO	debug all
CMAKE_SYSTEM_NAME	DOS

Jetz braucht man nur noch in das Build-Verzeichnis zu wechseln und dort wmake eintippen.
Da wmake auch nur “die Watcom-Variante” von make ist, funktionieren auch die üblichen Verdächtigen wie:

wmake clean: Löscht bisherige Build-Reste
wmake my_project: Baut nur das Projekt namens my_project and dessen Abhängigkeiten.

Am Ende liegen im Output-Directory die entsprechenden DOS-EXE Dateien.

Diese kann man dann unter Win64 mit Emulatoren wie DOSBOX ausführen, wenn man noch zusätzlich die Datei dos4gw.exe ins Programmverzeichnis kopiert.

Würde man in CMAKE_MODULE_LINKER_FLAGS den Eintrag dos4g durch dos ersetzen, wären reine 16-Bit DOS Programme möglich, doch das habe ich bisher noch nicht durch den Linker gebracht, da fehlen einige Symbole.

However, für einen ersten Test reicht mir eine DOS-4GW Anwendungen vollkommen.

Fazit

Nostalgie pur! Ich fühle mich wieder wie ein glücklicher kleiner Junge in den 90ern. Ja damals, als man noch mit 3 Zeilen Basic-Code den unwissenden Gymnasium-Professor in Verlegenheit bringen konnte. 😎

Und trotzdem ärgere ich mich, dass ich erst heute, über 20 Jahre zu spät, diese interessante Erfahrung machen durfte.
Es fehlte mir damals einfach an Software und Infos.

3 Jahre Blog

2021-10-06T13:00:00+02:00

3 Jahre hat diese Seite jetzt auf dem Buckel. Und ich glaube, damit ist es zum zeitlich längsten Webprojekt geworden, an dem ich je durchgehend aktiv gearbeitet habe.

Und langsam komme ich wieder an die Grenze des Erträglichen im aktiven Testbetrieb mit jekyll serve.

450 Markdown Posts und 12 “Dokus” müssen bei jeder Live-Änderung von Jekyll in HTML übersetzt werden, und das dauert auf meinem Rechner in WSL etwa 23 Sekunden.
Langsam muss ich mich daran gewöhnen die Option --incremental beim Start von jekyll serve zu aktivieren, damit man wieder auf 3 Sekunden zurückfällt, doch dann werden Menüs und Index-Seiten nicht aktualisiert, sondern nur die gerade geänderte Seite.

Parallel zum normalen Blog habe ich schon länger mit einem vereinfachten Design experimentiert, das als “Retro-BLOG” auch für ältere Browser wie den Internet Explorer 6 und älter geeignet ist.
Siehe opengate.at/retro-blog.

Mit einem neuen recommended Flag sind nun einige Artikel markiert, die mehr mit einem Tutorial gemein haben, als mit üblichen wöchentlichen Erlebnisberichten, was mir so alles untergekommen ist.
Diese können im Menüpunkt Spezielle Beiträge aufgelistet werden und erleichtern (zumindest mir) die Suche nach relevanteren Themen.

Mit der Freischaltung des BLOG Classroom als GIT Repository habe ich jetzt auch die Möglichkeit, Beispiel-Codes und Fragmente unabhängig vom GATE Projekt hochzuladen und im Blog zu referenzieren. Viel ist da noch nicht drinnen … aber der Blog hat ja auch mal mit nur einem Beitrag angefangen. URL: codeberg.org/GateNetwork/gate-blog-classroom

Blog Seiten können jetzt externe Links im Markdown-Kopf angeben, womit diese Links gleich unterhalb der Titelzeile als Link angezeigt werden. So kommt man schneller zu extern verlinkten Ressourcen, anstatt die Links immer erst aus dem Blog-Posting heraus suchen zu müssen.

Parallel zum GATE Projekt sind nun auch ein paar Features zu den Web-Services auf opengate.at hinzugekommen. Das wichtigste davon wird das Download-Service sein, das bei der Veröffentlichung der ersten GATE-Binaries eine große Rollen spielen soll. Schließlich sollen Downloads nicht direkt stattfinden, sondern durch eine Umleitung laufen, die Statistiken und Zugriffs-Limitierungen ermöglichen soll.

Nachdem nun mehr und mehr Hürden aus dem Weg geräumt werden, hoffe ich ja doch, dass ich Tools wie gatecli und vtxtedit auch mal wirklich fertigstellen kann, ohne mich dafür schämen zu müssen. Ein offenes Problem stellt aber immer noch GTK mit seinem Container-Resize Schema da, das sich leider immer noch nicht so verhält, wie es sein sollte.

Und eine kleine Anekdote am Rande: Seit zwei Jahren schreibe ich Quartals-News für die OpenGate-Hauptseite, die bis heute nicht veröffentlicht sind, weil sie keinen Sinn machen, so lange es dort keine Downloads gibt.
Hmm, das nennt man wohl schlechtes Release-Management.
(Oder: Ich brauche einfach mehr Freizeit …)

In diesem Sinne:

Mach’ ma einfach mal weiter!

Server 2022 Update mit Fehlschlag

2021-10-03T13:00:00+02:00

Seit August steht der Windows Server 2022 zur Installation bereit. Basierend auf dem Kernel 21/H2 sollte er eigentlich Server 2021 heißen, aber das war ja bei Server 2019 mit 18/09 damals auch nicht anders.

Und ich möchte nun meinen Domain Controller von Server 2016 auf den “letzten Stand” bringen. Na mal sehen, ob Microsoft das hinbekommt.

Server 2016 Zustand

Ich bin mit meinem inzwischen 3 Jahre durchlaufenden Server 2016 grundsätzlich zufrieden. Die Performance ist eben so, wie man es von einem Intel Atom erwarten kann: Bescheiden. Er würde zwar im “Extended Support” noch weitere 5 Jahre “OK” sein, aber es gibt ein paar Dinge, die mir trotzdem nicht so ganz gefallen.

Updates dauern ewig.
Das melden auch andere Seiten, dass Windows Updates in Server 2016 viel länger brauchen (beim Suchen angefangen), als z.B. im Server 2019. Hier erhoffe ich mir Verbesserungen
Defekter Grafiktreiber.
Tja, seit 3 Jahren habe ich den Intel-Treiber explizit deaktivieren müssen, damit ihn Windows-Update nicht erneuert und muss mit der Krücke von VGA-Kompatibilitätsteil leben. Zum Glück braucht ein Server keine Grafik, denn der “empfohlene” Treiber generiert sofort Bluescreens.
Docker Support.
Unter 2016 war das noch ein mühsames Unterfangen und die Images waren riesig. Mit 2022 soll alles nochmals viel kleiner und performanter werden … Na ich bin gespannt.

Upgrade Fehlschlag

Ein Domain Controller Update bereitet mir stets Sorgen. Zwar ist mir bisher noch keines misslungen, aber wenn was Schlimmes passiert, darf ich die Domäne entweder mühsam wiederherstellen oder neu aufsetzen … mit allen PCs dazu.

Die Setup-ISO-Datei als DVD Laufwerk eingebunden, startet man wie üblich setup.exe und die Zustandsanalyse beginnt.
Bei mir kamen dann gleich drei Problempunkte:

Empfehlung: Server 2008 Schema ist veraltet.
Lösung: Ich habe die Domäne und den Forest auf den Server 2008 R2 AD Standard gehoben.
Info: Active Directory Federation Services müssen nach dem Upgrade neu installiert werden.
Gut, wer weiß, ob ich die überhaupt noch brauche…
Notwendig: adprep muss das AD-Schema vorher aktualisieren.

Active Directory on this domain controller does not contain Windows Server 2022 ADPREP /FORESTPREP updates.

Dazu geht man ins DVD-Verzeichnis d:\support\adprep und führt dort adprep /forestprep mit Admin-Rechten aus.
Dort muss man das Update als “unumkehrbar” abnicken und eine Minute warten, bis das Active Directory die Änderungen eingespielt hat.

Wenn man nun den Windows-Setup Dialog mit der Info Meldung “Refresh”-t, kommt fast die gleiche Meldung nochmal:

Active Directory on this domain controller does not contain Windows Server 2022 ADPREP /DOMAINPREP updates.

Jetzt wird also mit adprep /domainprep die eigene Domäne auf Stand gebracht.

Tja und dann läuft Windows Setup … außer natürlich, man hat ein Mainboard, dessen Grafikkarten-Treiber das System einfrieren lässt …

Dann versucht das System nämlich sich zurückzusetzen, scheitert dabei und die ganze Installation ist beim Teufel.
Jetzt weiß ich also, wie man ein Upgrade versemmeln kann.

FAIL !

Neuinstallation und manuelles AD-Reset

Mit dem ISO per Rufus auf dem USB Stick startete ich also ein neues Server Setup mit neuer SSD für eine gänzlich jungfräuliche Installation. Das funktionierte auch alles problemlos, bis es dann (so wie auch beim Server 2016) zum Windows Update des Grafik-Treibers kam und wie damals löste ich das Problem per manueller Deaktivierung des Treibers im “abgesicherten Startmodus”.

Ärgerlich! Das Problem wurde also nicht behoben.

Jetzt kam der ungute Teil. Mein zweiter Domain-Controller hielt keine der FSMO-Rollen und mein primäres System war ja tot.

Was für ein Glück, dass ich vor vielen Jahren ADSI studiert hatte und die Attribute am verbliebenen DC selbst per ADSI-Edit Tool anpassen konnte:

Angenommen, die eigene Domäne heißt mydomain.net, dann findet man die 4 Objekte mit den FSMO-Attributen unter folgenden Namen:

Domain Master: DC=mydomain,DC=net
RID Master: CN=RID Manager$,CN=System,DC=mydomain,DC=net
Infrastructure Master: CN=Infrastructure,DC=mydomain,DC=net
PDC Emulator Master: CN=Partitions,CN=Configuration,DC=carbis,DC=mydomain,DC=net
Schema Master: CN=Schema,CN=Configuration,DC=mydomain,DC=net
(dazu muss man sich zur separaten Schema-Partition verbinden)

Diese Objekte enthalten stets ein Attribut mit Namen fSMORoleOwner und dieses hält dann Namen des früheren Domain Controllers, z.B.: CN=NTDS Settings,CN=Old-DC,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=mydomain,DC=net

Hier tauscht man den Old-DC Eintrag durch den Namen des neuen gewünschten Servers und startet neu. Jetzt ist der alte “sekundäre” Server zum primären aufgestiegen.
Diese Schritte kann man zwar nicht in der GUI, jedoch aber mit ein paar Kommandozeilen-Tools hinbekommen, die ich mir aber nie gemerkt habe, weil ich ja schon den “nativen Weg” kannte.
Am Ende kann man nun den alten Server in allen AD-GUIs entfernen.

So konnte ich dann meinen neu aufgesetzten neuen DC in die Domäne aufnehmen, ihn wieder zum DC “promoten” und am Ende die Rollen wieder zurückübertragen (diesmal per GUI wie es sich gehört).

Fazit

Ich bin total angepisst wegen dem Grafikkarten-Crash … und gleichzeitig mit mir selbst zufrieden, dass der manuelle AD-Restore so problemlos ablief.

Nun wissen wir also, dass Windows Setup ein großes Problem hat, wenn die letzten Einrichtungsschritte fehlschlagen, denn zu diesem Zeitpunkt funktioniert das Zurückrollen offenbar nicht.
Ich vermute mal, es liegt daran, dass auch die UEFI Partition aktualisiert wurde und nicht mehr zurückgesetzt werden konnte, und so landet man in einem nicht-boot-baren Zustand.

Aber, in Sachen Performance hat sich das Update voll und ganz ausgezahlt. Das System regiert nun wesentlich schneller und auch Updates sind im Gegensatz zu früher zügig eingespielt.

Ich hoffe, das bleibt auch so …