15. Januar 2026, 10:30
Lesezeit: ca. 2 Min

Warum nicht jedes Problem ein Framework braucht

In den späten 80er- und frühen 90er-Jahren musste man für gute Software noch “runter auf’s Blech”. Hardwarenah Registerwerte abfragen, um zum Beispiel Mauskoordinaten via Interrupt 33h zu erhalten.1 Oder Inline-Assembler innerhalb von Turbo-Pascal Procedures oder PowerBASIC Functions schreiben. Das waren die Programmiersprachen, mit denen ich aufgewachsen bin. Später kamen weitere hinzu, mit denen ich aber nie so richtig warm geworden bin. Ich bin ein “BASIC-Guy” schreibe ich in meinen Readme auf Codeberg.2

Heute werden solche Selbstverständlichkeiten von Betriebssystemen und mächtigen Frameworks wegabstrahiert. Das ist auch gut so. Es erspart einem wirklich Arbeit. Andererseits ist es mit Nachteilen erkauft, die man ohne diese Abstraktion nicht hätte. Für kleine, präzise Werkzeuge, wo ein deterministisches und robustes Verhalten Voraussetzung ist, ist es selten hilfreich. Gerade wenn es “erwachsene Software” sein soll.3

Wer jetzt denkt, ich würde moderne Frameworks und Konzepte ablehnen, irrt: Ich bin genauso ein Freund von Python oder eines Django Web-Frameworks. Mein Punkt ist, dass in der heutigen Zeit es wichtiger denn je ist, auch Werkzeuge jenseits des Mainstream zu beherrschen.

Werkzeuge, die nahe am Compiler bleiben und cross-platform, kleine und native Single-File-Binaries erzeugen, mit oder ohne GUI. Moderne Sprachen wie Rust oder Go können es nur bedingt. Ein aktueller und lesenswerter Artikel: “Why PureBasic Is Potentially the Last Surviving Cross-Platform Systems GUI Language” erklärt warum.4

Screenshot des PureBasic Editors unter LinuxScreenshot des PureBasic Editors unter Linux

Das ist für mich in der Praxis essentiell, um beispielsweise customized Pentesting-Werkzeuge zu erstellen, die bewusst falsche Contentlängen von HTTP-Requests gegen eine API “werfen”. Mit NTFS-Filestreams umgehen oder “unter dem Radar” gängiger Antivirus- und EDR-Software zu bleiben. Ich darf mit Recht über dieses Schlangenöl ranten. Mein “Clipboard-Auditor” zum Ausleiten von Zugangsdaten wird seit Jahrzehnten nirgendwo erkannt.5

Die Verwendung von FreeBASIC, PureBasic oder Lazarus/FreePascal ist eine bewusste Entscheidung, nachdem Scope oder Spezifikationen festgelegt wurden. Für Aufgaben, bei denen Übersichtlichkeit, Kontrolle, Determinismus und Langlebigkeit entscheidend sind. Kein philosophischer Vendor-Talk oder “wir machen alles mit einem Hammer”.

Screenshot des Lazarus/Freepascal Editors unter LinuxScreenshot des Lazarus/Freepascal Editors unter Linux

Wer in die heutigen Industrielandschaften schaut, entdeckt RS232 Schnittstellen, VisualBasic in Siemens SPS-Anlagen, PGs aus Retro-Zeiten und moderne SteuerPCs, die nur geringfügig besser sind. Der Start eines Webbrowsers bringt diese oftmals bereits an Speicher- und Leistungsgrenzen.

Siemens SPS S5 PG aus den 90er Jahren, noch heute eingesetztSiemens SPS S5 PG aus den 90er Jahren, noch heute eingesetzt

Wer scheinbar unlösbare Herausforderungen hat, darf sich gerne bei mir melden.

In diesem Sinne,
Tomas Jakobs

© 2026 Tomas Jakobs - Impressum und Datenschutzhinweis

Mitglied im UberBlgr Webring:   < Zurück > Weiter >  

Unterstütze diesen Blog - Spende einen Kaffee