Einerseits schreibe ich ja gerade diesen Beitrag hier. Und ich verspreche, dass dies kein „Mach’s gut und danke für den Fisch“-Beitrag ist.

Andererseits ist es 226 Tage her seit dem letzte Beitrag. Und das ist keine Zahl einer gesunden, aktiven Website.

Also muss die Antwort auf die im Titel gestellte Frage lauten: „Es ist kompliziert.“

Was ist passiert? Ich habe diesen Blog ins Leben gerufen, um mein Wissen, meine Erkenntnisse und meine Projekte, vor allem rund um die Softwareentwicklung, zu teilen, etwa seit meiner Zeit als Doktorand. Hier sind sowohl meine Projekte an der Universität als auch meine privaten Projekte. Als ich dann von der Wissenschaft in die Industrie wechselte, änderte sich der Fokus natürlich auf meine privaten Projekte, da ich nicht mehr frei über alles schreiben kann, was ich in meinem Job tue. Und mit der Zeit wurden meine privaten Softwareprojekte meiner Meinung nach immer uninteressanter, zumindest was Neuigkeiten angeht.

Es ist nicht so, dass ich gar keine eigene Software mehr schreibe, ganz im Gegenteil. Wer einen Blick auf meine GitHub-Seite wirft, sieht, dass dort ständig neue Updates durchlaufen. Dabei handelt es sich vor allem um kleine Tools, die speziell auf meine Bedürfnisse zugeschnitten sind. Nichts Ausgefallenes oder Spektakuläres. Es ist also einfach nichts dabei gewesen, worüber es sich meiner Meinung nach gelohnt hätte, hier zu schreiben.

Ich habe in diesem Blog hier auch über andere Hobbyprojekte berichtet, die nichts mit Software zu tun haben. Ich habe jede Menge Hobbys, die in meiner sehr begrenzten Freizeit um meine Aufmerksamkeit buhlen: Gaming natürlich, aber auch Maker-Projekte, inklusive 3D-Druck. Vor einiger Zeit habe ich auch das Warhammer-Hobby wiederentdeckt. Außerdem habe ich jede Menge großartiger Ideen rund um Elektronik und Mikrocontroller. Und, natürlich, habe ich auch ein paar langfristige Softwareprojekte, die ich nicht aufgeben werde. Es gibt also viel, was ich mache und was mir Spaß macht. Viel mehr als ich leider Zeit dafür habe.

Und soziale Medien sind wirklich nicht meins. Ich möchte nicht und werde nicht auf diversen Plattformen meine Projekte, etc., präsentieren. Das ist nicht mein Stil. Ich habe diesen Blog als eine Art Tagebuch gestartet. Soll heißen, ich habe über Dinge geschrieben, über die ich schreiben wollte, nicht weil ich glaube, dass jemand das lesen sollte. Einfach nur, weil ich es aufschreiben wollte. Wenn es jemanden interessiert ist das natürlich fein. Und in diesem Sinne werde ich diesen Blog weiterführen. Ich werde über meine kleinen Projekte schreiben, sei es Software, Maker-Kram, Warhammer, 3D-Druck oder etwas ganz anderes. Es wird zweifelsohne lange Pausen zwischen den Beiträgen geben. Aufgeben werde ich diese Website aber wirklich nicht.

Vor einiger Zeit wurde gflags in Version 2.3.0 veröffentlicht. Als ich diese Nachricht sah, dachte ich: „Wofür brauche ich das nochmal?“ und habe es sofort wieder vergessen. Heute habe ich das erneut gesehen, nachgeschaut und bin zu dem Schluss gekommen, dass ich dieses Paket überhaupt nicht mehr brauche. Und wenn man sich die Statistik auf nuget.org mit so ungefähr null Downloads pro Tag ansieht, scheint es auch sonst niemand zu brauchen.

Daher gebe ich das „gflags (static)” Nuget-Paket auf, entferne es aus den Suchergebnissen, stoppe die AppVeyor-Builds und setze das BitBucket-Repository auf „read only“.

Falls Du das hier liest und das Nuget-Paket, das Repository usw. Adoptieren möchtest, dann melde dich sehr gerne bei mir. Ich übertrage die Ownership gerne.

 Lua 5.4.8 ist hier!

Und so war es also wieder einmal an der Zeit, das NuGet-Paket zu bauen. Zu meiner Überraschung schlug die Erstellung mit Clang als Werkzeugkette unerwartet fehl:

C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\Llvm\lib\clang\19\include\stdarg.h(22): warning RC4067: unexpected characters following '#if/#elif' directive; newline expected [D:\a\nuget-lua\nuget-lua\compiler\compiler.vcxproj] 
C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\Llvm\lib\clang\19\include\stdarg.h(22): warning RC4067: unexpected characters following '#if/#elif' directive; newline expected [D:\a\nuget-lua\nuget-lua\compiler\compiler.vcxproj] 
C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\Llvm\lib\clang\19\include\stddef.h(22): warning RC4067: unexpected characters following '#if/#elif' directive; newline expected [D:\a\nuget-lua\nuget-lua\compiler\compiler.vcxproj] 
C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\Llvm\lib\clang\19\include\stddef.h(22): warning RC4067: unexpected characters following '#if/#elif' directive; newline expected [D:\a\nuget-lua\nuget-lua\compiler\compiler.vcxproj] 
C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\Llvm\lib\clang\19\include\stddef.h(51): warning RC4067: unexpected characters following '#if/#elif' directive; newline expected [D:\a\nuget-lua\nuget-lua\compiler\compiler.vcxproj] 
C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\Llvm\lib\clang\19\include\stddef.h(51): warning RC4067: unexpected characters following '#if/#elif' directive; newline expected [D:\a\nuget-lua\nuget-lua\compiler\compiler.vcxproj] 

Ich suchte online nach den Compilerfehlern und ob es kürzlich Änderungen an Clang oder der Visual Studio Integration oder so etwas gab. Aber ich fand nichts. Ich habe versucht, die vorherige Version von Lua in meiner GitHub-Aktion zu bauen, und das ist auch fehlgeschlagen.

Und nach einigen Minuten habe ich endlich den wichtigen Teil bemerkt! Das sind KEINE c/cpp-Compiler-Fehler! Das sind RESOURCE COMPILER-Fehler!

Ich baue alle Binärdateien, d.h. den Lua-Compiler, den Lua-Interpreter und die Lua-DLL-Version, mit eingebauten Versionsinformationen. Und das Ressourcenskript dafür enthält den c-Header lua.h, um die in dieser Datei definierten Versionsinformationen zu verwenden. Da es sich auch um einen normalen c-Header handelt, enthält er natürlich weitere Dateien, darunter die stdarg.h und stddef.h, die die obigen Fehler auslösen.

Ich vermute, dass in diesen Systemheadern und im Cpp-Compiler einige Optimierungen vorgenommen wurden, die sich im Resource-Compiler nicht widerspiegeln. Und ich mache niemandem einen Vorwurf daraus, da der Ressource-Compiler ohnehin etwas Exotisches ist und man nicht wirklich erwarten kann, dass er vollständig mit Cpp kompatibel ist.

Das Skript für die Versionsinfo-Ressourcen wird für diese Projekte trotzdem generiert. Ich habe dieses Problem also behoben, indem ich lua.h nicht mehr in den Versionsinfo-Header aufgenommen habe, sondern alle benötigten Defines dupliziert habe. Nur für den Fall, dass Sie (oder mein vergessliches zukünftiges Ich 😉) auch bei anderen Projekten auf ähnliche Probleme stoßen.

Und so gibt es nun auch das neue NuGet-Paket von Lua.

Gegen Ende des letzten Jahres habe ich mir endlich einen 3D-Drucker gekauft. Mit den BambuLab-Produkten hatte ich endlich das Gefühl, dass die 3D-Drucktechnologie für den Privatgebrauch so weit war, dass ich mich nicht mehr mit Einstellungen oder Ähnlichem herumärgern müsste, mich nicht mehr mit dem Prozess des 3D-Druckens selber beschäftigen müsste, sondern mich ganz auf die Erstellung der Objekte konzentrieren konnte, die ich drucken wollte.

Und hier sind wir nur. Hier sind die ersten beiden 3D-Objekte, die ich designed und der 3D-Druck-Community zur Verfügung gestellt habe: kleine, aufklappbare Schachteln.

Dies ist nur der Anfang meiner Reise in yet-another Hobby. Ich habe Ideen für viele weitere Dinge, die nun physische Realität werden können.

WordpressIch schreibe meinen Blog hier schon immer zweisprachig, auf Deutsch und auf Englisch. Ganz früher war das noch mein eigener Webcode. Dann bin ich irgendwann auf WordPress umgestiegen. Und die Plugins für die mehrsprachigen Posts, etc., waren schon immer irgendwie … anstrengend.

Und jetzt hat mein bisheriges Plugin für den mehrsprachigen Blog vollends den Geist aufgegeben; vermutlich durch ein WP-Update oder PHP-Update. Wie auch immer. Hilft ja nix. Also, gibt’s jetzt mal wieder ein neues Plugin. Das verwaltet jetzt unterschiedliche Sprachen indem jeder Post genau eine Sprache hat, und dieselben Posts in unterschiedlichen Sprachen „nur“ verlinkt sind. Eigentlich ein ganz nettes Konzept.

Heißt aber auch das meine bisherigen Posts alle, wirklich alle, überarbeitet werden müssen, genau wie die Webseitenstruktur selbst und alle Extraseiten auch. Und das wird dauern.

Also, wird der Inhalt auf meiner Webseite bis auf weiteres immer so ein bisschen Kaputt aussehen. Tschuldigung.


Update 2024-09-15: während ich so dabei bin meine Blog-Artikel zu fixen, d.h. sie nach ihrer Sprache in zwei getrennte Artikel zu splitten, da merke ich dass Links zwischen den Artikeln dabei falsch sein können, im Besonderen bei den englischsprachigen Versionen. Sorry, aber mir ist dieses alte Zeug nicht wichtig genug, dass ich das durchgehend fixe…

Ich bin auf dieses Nuget gestoßen, weil ich WPF-UI-Anwendungen geschrieben habe und einen Folder-Picker brauchte. Irgendwer im Internet schlug vor, die WinForms-Dialoge zu verwenden. Ich hasse es irgendwie, zwei Frameworks zu verwenden. Und dann brachte jemand anderes das Nuget WindowsAPICodePack.Shell ins Spiel, mit seinen Klassen der Windows Common Dialogs, einschließlich der Möglichkeit zur Auswahl von Ordnern im File-Öffnen-Dialogfenster.

Also fing ich an, das Nuget zu benutzen. Irgendwann wies mich ein Freund darauf hin, dass das Nuget-Paket gar nicht wie ein offizielles Microsoft-Paket aussah, sondern wie ein Repackage, das irgendjemand gemacht hatte. Das brachte mich zum Nachdenken. Ich unterstelle niemandem böse Absichten, aber ich fand es sehr, sehr seltsam. Das offizielle Paket war . Und es gibt eine ganze Reihe von Paketen mit seltsamen Namen:

Ich mag das nicht. Selbst wenn keiner der Autoren böse Absichten hegt, gefällt mir das nicht, denn es riecht nach Betrug, Phishing und Schwachstellen. Tut mir leid, aber nein.

Also, wo ist das offizielle Paket? Es scheint verschwunden zu sein, deshalb gibt es die Repackages von Community-Mitgliedern. Warum ist es verschwunden? Keine Ahnung. Vielleicht wurde es bei einer halbautomatischen Bereinigung erwischt, da es verwaist war. Jemand behauptet es wäre Microsoft.Windows.SDK.Contracts ersetzt worden.

Letztendlich habe ich den Code in meinen Projekten ersetzt, indem ich entweder doch den WinForms-Dialog verwendet oder eine sehr kleine P/Invoke-Wrapper-Klasse geschrieben habe, die die Win32-API-Funktion direkt aufruft. Wen es interessiert, der kann sie sich gerne anschauen:

https://github.com/sgrottel/open-here/commit/9de68198e35f0f6dec9386372cc71bada54c2f5b

Die Moral von der Geschichte ist, dass ein Nuget-Paket nur so gut ist wie die Menschen, die es pflegen. Und ich meine Menschen, nicht Organisationen. Denn am Ende kommt es darauf an, ob eine einzelne Person dahinter steht und ihr Bestes geben will oder nicht.