Willkommen in unserer Kategorie „Damals & Heute“ – wo wir Technik damals und heute gegenüberstellen. Ob XML vs. JSON, FireWire vs. USB-C oder VHS vs. Streaming: Wir beleuchten, was früher mal „Zukunft“ war, was daraus wurde – und wie man’s heute (besser?) macht. Mit echten Beispielen, modernen Alternativen und einer guten Portion Nerd-Zynismus.
Ein Mediaplayer, der uns alle traumatisiert hat – und trotzdem Kult ist
Damals: Streaming mit Buffer-Schmerz
In den späten 90ern war das Internet langsam, aber voller Hoffnung. Musik und Videos? Damals eher ein Abenteuer als ein Feature. Und mittendrin: RealPlayer – ein Pionier des Streamings.
Der Player wurde 1995 von RealNetworks (damals noch Progressive Networks) veröffentlicht und war der erste weitverbreitete Streaming-Client für Audio und später auch Video. Statt eine Datei komplett herunterzuladen, konnte man nun Inhalte „live“ übertragen.
Das klang futuristisch, hatte aber seinen Preis: geringe Bitraten, miese Qualität, lange Pufferzeiten und ein proprietäres Format namens .rm (RealMedia) bzw. .ra (RealAudio).
Die Technik dahinter
Streaming-Protokoll: RealPlayer nutzte das hauseigene Real Time Streaming Protocol (RTSP).
Formate: .rm, .ra, später .rv (RealVideo), teils mit DRM-Schutz.
Encoder: Nur mit spezieller Software von RealNetworks nutzbar, was Open-Source-Player ausschloss.
Bitrate: Oft unter 64 kbit/s Audio, 240p Video war normal.
Codec: Anfangs RealAudio G2, später Helix.
Trotzdem war das revolutionär: Nachrichten, Konzerte oder Radio über Web war auf einmal möglich.
Warum alle RealPlayer gehasst haben
🐌 Performance-Killer: Der Player beanspruchte CPU und RAM wie ein ganzer Browser heute.
🧲 Zwangsinstallation: Wurde gerne mal mit anderer Software gebündelt.
🔊 Autoplay und Autoupdate: Nicht abschaltbar, oft mit Werbung.
🔐 DRM und Formatzwang: Inhalte konnten nur im RealPlayer abgespielt werden.
💸 RealPlayer Plus: Viele Standardfunktionen (z. B. Equalizer, CD-Ripping) waren nur kostenpflichtig verfügbar.
Heute: RealPlayer lebt – irgendwie
Die Firma RealNetworks existiert immer noch. Der RealPlayer 24 wird aktiv weiterentwickelt:
Tatsächlich zielt RealPlayer heute mehr auf Medienmanagement und YouTube-Downloads als auf Streaming. Die DRM-Vergangenheit wurde still beerdigt.
RealPlayer vs. Moderne Medienplayer
Feature
RealPlayer (damals)
VLC (heute)
Plex (heute)
Codec-Support
Selektiv + DRM
Fast alles
Alles + Streaming
Werbung
Ja (viel)
Nein
Optional
Systemfreundlichkeit
Niedrig
Hoch
Hoch
UI
Laut, blinkend
Minimalistisch
Modern
Preis
Shareware-Modell
Kostenlos
Freemium
Nerd-Fazit
RealPlayer war seiner Zeit voraus, aber hat sich selbst überlebt. Er war der erste Schritt in Richtung Streaming-Zukunft, aber mit den falschen Entscheidungen zur falschen Zeit.
Er steht exemplarisch für Tech-Unternehmen, die lieber Kontrolle statt Kompatibilität wollten. VLC und Co. haben ihn letztlich durch Offenheit überflügelt.
Und doch bleibt er ein Stück digitaler Nostalgie:
„Kennst du noch .rm-Dateien? Dann bist du offiziell alt genug für einen eigenen Serverraum.“
In diesem Beitrag zeigen wir, wie sich ein einfaches Projekt – eine Temperaturanzeige mit LED-Ausgabe – über die letzten zwei Jahrzehnte entwickelt hat. Dabei geht es nicht nur um die Programmierung, sondern auch um die rasante Entwicklung der Hardware: Vom großen DIP-AVR mit externem Programmer bis hin zu kompakten All-in-One-Boards wie dem ESP8266 oder ESP32.
Was macht das Projekt?
Ein DHT11-Sensor misst die Temperatur. Zwei LEDs zeigen den Wert an – entweder in Helligkeitsstufen oder als An/Aus-Anzeige. Die Helligkeit wird per PWM geregelt, sodass die Temperatur visuell erkennbar ist.
Variante 1: AVR-C auf dem Pollin ATmega32-Board
Technikstand: ca. 2000–2005 Diese Variante kommt ohne Bibliotheken aus und verwendet direkte Registerzugriffe. Die PWM wird über Timer0 realisiert, der DHT11 per Bit-Banging abgefragt.
Hardware: Pollin ATmega32 Evaluationsboard mit 16 MHz Quarz, DHT11 an PC0, LED an PD6 (OC0)
#define F_CPU 16000000UL
#include <avr/io.h>
#include <util/delay.h>
#include <stdint.h>
#include <stdbool.h>
#define DHT_DDR DDRC
#define DHT_PORT PORTC
#define DHT_PIN PINC
#define DHT_INPUTPIN PC0
uint8_t read_dht11(uint8_t *temperature) {
uint8_t bits[5] = {0};
uint8_t i, j;
// Start signal
DHT_DDR |= (1 << DHT_INPUTPIN);
DHT_PORT &= ~(1 << DHT_INPUTPIN);
_delay_ms(20); // >18ms
DHT_PORT |= (1 << DHT_INPUTPIN);
_delay_us(40);
DHT_DDR &= ~(1 << DHT_INPUTPIN);
// Wait for DHT11 response
_delay_us(80);
if (DHT_PIN & (1 << DHT_INPUTPIN)) return 1;
_delay_us(80);
if (!(DHT_PIN & (1 << DHT_INPUTPIN))) return 2;
// Read 5 bytes
for (j = 0; j < 5; j++) {
for (i = 0; i < 8; i++) {
while (!(DHT_PIN & (1 << DHT_INPUTPIN))); // wait for high
_delay_us(30);
if (DHT_PIN & (1 << DHT_INPUTPIN))
bits[j] |= (1 << (7 - i));
while (DHT_PIN & (1 << DHT_INPUTPIN)); // wait for low
}
}
// Checksum
if ((uint8_t)(bits[0] + bits[1] + bits[2] + bits[3]) != bits[4]) return 3;
*temperature = bits[2]; // whole °C from byte 3
return 0;
}
void init_pwm_timer0(void) {
DDRD |= (1 << PD6); // OC0 (PD6) als Ausgang
TCCR0 = (1 << WGM00) | (1 << WGM01) // Fast PWM
| (1 << COM01); // Non-inverting
TCCR0 |= (1 << CS01); // Prescaler 8 → 16MHz/8 = 2MHz
}
int main(void) {
uint8_t temp = 0;
init_pwm_timer0();
while (1) {
if (read_dht11(&temp) == 0) {
// Begrenzung des Temperaturbereichs auf 20–30°C
if (temp < 20) temp = 20;
if (temp > 30) temp = 30;
// Mapping 20°C–30°C auf PWM 0–255
OCR0 = (temp - 20) * 25;
} else {
OCR0 = 0; // Fehler → LED aus
}
_delay_ms(1000); // Messrate ca. 1 Hz
}
}
Diese Art der Mikrocontroller-Programmierung war damals Standard und bot maximale Kontrolle bei minimaler Abstraktion. Externe Programmer wie LPT-Adapter waren damals die einzige Option – der heute beliebte USBasp kam erst später auf den Markt, ab etwa 2005. In den frühen 2000ern wurden oft selbst gelötete Parallelport-Programmieradapter eingesetzt, die direkt über PonyProg oder einfache Bit-Banging-Tools angesteuert wurden., um den Code überhaupt auf den Chip zu bekommen. Komfort: Fehlanzeige.
Variante 2: ESP8266 mit Arduino-C++
Technikstand: 2015 bis heute Hier nutzen wir moderne Bibliotheken wie DHT.h von Adafruit, komfortable Methoden wie analogWrite() und deutlich mehr Rechenleistung.
Hardware: ESP8266 (z. B. NodeMCU oder Wemos D1 Mini), DHT11 an D4 (GPIO2), LED an D5 (GPIO14)
Die Programmierung erfolgt per USB, ohne externen Programmer. Flashen, Debuggen und sogar OTA-Updates (Over The Air) sind möglich.
Variante 3: ESP8266 mit MicroPython
Technikstand: Minimalismus trifft Moderne In nur wenigen Zeilen Python erreichen wir dasselbe Ergebnis. Ideal für alle, die lieber in Skriptsprachen arbeiten. Die MicroPython-Firmware wird per USB oder OTA aufgespielt und kann direkt über REPL oder Webinterface gesteuert werden.
Hardware: wie Variante 2
import dht
import machine
import time
sensor = dht.DHT11(machine.Pin(2)) # GPIO2 = D4
led = machine.PWM(machine.Pin(14)) # GPIO14 = D5
led.freq(1000)
while True:
try:
sensor.measure()
temp = sensor.temperature()
pwm = int((temp - 20) * 25)
pwm = max(0, min(255, pwm))
led.duty(pwm)
except OSError:
led.duty(0) # Fehler → LED aus
time.sleep(1)
Lesbarkeit und Einfachheit stehen hier im Vordergrund. Mehr zur MicroPython-Umgebung auf der offiziellen Seite: micropython.org
Variante 4: Assembler auf dem ATmega32
Technikstand: Nerd-Level over 9000 Wer maximale Kontrolle will (und den Schmerz nicht scheut), kann das Ganze auch in Assembler schreiben. Hier definieren wir die Bitmuster für Timer, LED und Sensorzugriff direkt.
.include "m32def.inc" ; Register-Definitionen für ATmega32
; --------------------------------------------------------
; OC0 (PD6) = PWM-Ausgang für LED
; --------------------------------------------------------
.org 0x00
rjmp RESET
; --------------------------------------------------------
; Reset-Vektor
; --------------------------------------------------------
RESET:
; Stackpointer setzen
ldi r16, high(RAMEND)
out SPH, r16
ldi r16, low(RAMEND)
out SPL, r16
; PD6 (OC0) als Ausgang
sbi DDRD, PD6
; Timer0: Fast PWM, non-inverting, prescaler 64
ldi r16, (1<<WGM00)|(1<<WGM01)|(1<<COM01)|(1<<CS01)|(1<<CS00)
out TCCR0, r16
; Initiale Helligkeit
ldi r16, 0
out OCR0, r16
MAIN:
; Erhöhe PWM-Wert langsam
ldi r17, 0 ; Zähler
LOOP:
mov r16, r17
out OCR0, r16 ; PWM-Wert setzen
rcall DELAY
inc r17
cpi r17, 255
brne LOOP
rjmp MAIN
; --------------------------------------------------------
; Einfache Delay-Routine (Software-Delay)
; --------------------------------------------------------
DELAY:
ldi r18, 20
DELAY1: ldi r19, 255
DELAY2: dec r19
brne DELAY2
dec r18
brne DELAY1
ret
Diese Variante ist nichts für Einsteiger, aber hervorragend geeignet, um zu verstehen, wie Mikrocontroller intern arbeiten. Eine gute Referenz für Assembler-Einsteiger bietet AVR Freaks und die Original-Datenblätter vom Microchip.
BONUS: DHT11 in Assembler auslesen (Hardcore)
Ein kompletter DHT11-Bit-Banging-Reader in Assembler erfordert feingranulare Kontrolle von Mikrosekunden-Timing, Schleifen mit Timeout und Bitmanipulation. Die Umsetzung wäre ein eigener Beitrag für sich. Wer es wagen will, braucht:
Zyklenexakte WAIT_US-Schleifen
Schleifen zur HIGH-Phasen-Messung (für 0 vs. 1)
5 Bytes Speicher (40 Bit) zum Zusammenbauen
Tipp: DHT11-Datenblatt genau studieren, dort stehen alle Timings. Wer sich daran wagt, verdient das Nerdabzeichen mit Goldrand.
Von der Backstein-Platine zum All-in-One-Modul
Der ursprüngliche ATmega32 war ein echter Brocken: 40 Pins, DIP-Gehäuse, externe Taktquelle, externer Programmer, keine Kommunikation ohne zusätzliche Schaltung. Im Kontrast dazu stehen moderne Boards wie der ESP32-S3 DevKit* (bezahlter Link), die WLAN, Bluetooth, USB-OTG, mehrere ADCs, DACs und SPI-/I2C-Interfaces auf kleinstem Raum vereinen – oft in der Größe eines USB-Sticks. Manche Boards, wie der LilyGO T-Display, haben sogar ein OLED- oder TFT-Display direkt mit auf dem PCB.
Was früher ein großes Steckbrett voller Kabel war, ist heute ein einziges Modul mit USB-C-Anschluss. Plug-and-play statt Kabelsalat.
Fazit: Vier Wege zur Temperaturanzeige
Ob du lieber klassisch mit direktem Registerzugriff arbeitest oder moderne Skriptsprachen bevorzugst – dieses Projekt zeigt, wie vielseitig Mikrocontroller heute einsetzbar sind. Und wer die Technik von damals noch kennt, weiß die heutigen Komfortfunktionen umso mehr zu schätzen. Aber weißt du, was noch älter als diese Schreibweise ist? XML und XSLT – ein Relikt aus der Zeit, als man Webseiten noch mit Stylesheets statt mit JavaScript animieren wollte. Wenn du denkst, Assembler sei archaisch, warte ab, bis du versuchst, eine Tabelle mit XSLT zu formatieren.
Und du?
Hast du selbst noch alte AVR-Boards in der Schublade? Oder bastelst du schon mit ESP32 und OLED direkt am Gerät? Lass es mich wissen – kommentiere unter dem Beitrag oder schick mir deinen Aufbau per Mastodon oder E-Mail!
Wer sagt, dass Schatzsuchen nur was für Abenteurer mit Hut und Peitsche sind? Wir haben mit nichts weiter als einem Terminal, einem Linux-System und einem Hauch Forschergeist eine echte digitale Zeitkapsel geöffnet – willkommen zur ausführlichen Analyse einer BIERCard. Was es damit auf sich hat, wie wir tief in die Geheimnisse eingestiegen sind und warum selbst Root-Zugriff manchmal nicht reicht, erfährst du jetzt.
Was ist eine BIERCard überhaupt?
Auf den ersten Blick scheint es sich um eine typische Terminal-Steuerkarte zu handeln, wie man sie z. B. aus Kiosksystemen kennt. Auffällig waren allerdings zwei CompactFlash-Karten: eine mit der Aufschrift „Produktiv“ (4 GB) und eine mit der Aufschrift „Backup“ (2 GB).
Beide Karten stecken auf einer speziellen Trägerplatine, die über IDE, mehrere serielle Schnittstellen (COM1–3) und USB mit dem Mainboard verbunden ist. Zentral auf der Platine sitzt ein ATmega32A – das Gehirn hinter der BIERCard.
Die Backup-Karte heben wir uns für ein späteres Kapitel auf – denn die Produktiv-Karte hatte es bereits in sich.
Die Produktivkarte unter der Lupe
Nach dem Einhängen (mount) zeigte lsblk, dass die Karte drei Partitionen enthält:
/dev/sdb1: vermutlich das Hauptsystem (Adminmodus)
/dev/sdb2: vermutlich der Kundenmodus (Kioskansicht)
/dev/sdb3: eine eigenständige Datenpartition, vermutlich zur Konfiguration und Sicherung
Ein Blick in /mnt/cf3 (also Partition 3) bestätigte unsere Annahme: Dort fanden sich Dateien wie biercard_version, copies, generate_from sowie ein ominöser oldimage. Alles deutet auf eine kontrollierte Verwaltung und Synchronisierung von Konfigurationen hin.
Zwei Welten auf einer Karte
Was sofort ins Auge fiel: Das System ist in mindestens zwei Modi aufgeteilt. Im Adminmodus (sdb1) gibt es klassische Systemzugriffe, Root-Zugriff, Logging und diverse Analysewerkzeuge. Im Kundenmodus (sdb2) hingegen scheint alles auf eine abgesicherte Anzeige reduziert – vermutlich ein Kiosksystem, das ohne direkte Eingriffe laufen kann.
Monitorerkennung und Grafik-Setup
Mit der PNY Quadro NVS 290 fiel der letzte Puzzlestein an seinen Platz: Zwei Monitore für den Kunden – robust, stromsparend, professionell. Keine Gaming-Karte, kein Schnickschnack – sondern ein Werkzeug, geschaffen für den Dauerbetrieb. Die parallele Anzeige von Quoten, Spielinformationen und Werbeanimationen war kein Zufall, sondern System.
Netzwerk und Peripherie – alles fest verdrahtet
Auch die Netzwerkverbindung ist hart kodiert: Die Datei iBet.conf nennt eine feste IP 192.168.100.11. Die Konfiguration erfolgt also zentral – vermutlich über ein internes Servernetzwerk. Auch der verwendete Drucker und Leser sind fix:
Eines der ersten Highlights: das Skript automatHelper.sh. Es prüft Logdateien, mountet gegebenenfalls Konfigurationspartitionen, analysiert Systemzustände und zeigt beim Systemstart passende Screens an. Es wirkt wie der zentrale Boot-Dispatcher.
Das zweite wichtige Skript: copy_ibet_conf.sh. Es kopiert iBet.conf auf eine spezielle Partition und sichert so zentrale Konfigurationsdaten – automatisiert, robust und mit viel Shell-Magie:
mount "/dev/${AUTOMAT_DEVICE}${AUTOMAT_CONFIG_PARTITION_DEVICE_NO}" ${CONFIG_MNT}
cp /etc/automat/iDev/iBet.conf "${CONFIG_MNT}/copies/etc/automat/iDev/iBet.conf"
Ein drittes Skript – reset_barcode_scanner.sh – verrät: Selbst die Scannerhardware konnte aus dem Terminal heraus neu initialisiert werden.
Kryptografie, bitte einmal unknackbar
Die Datei iBet.conf enthält nicht nur einfache Konfigurationsdaten, sondern auch einen über 3000 Zeichen langen RSA-Block im DER-Format. Was wie ein einfacher Header aussieht, entpuppt sich als massiver Public Key mit fest kodierten Parametern:
id=308204BD020100300D0609...
Obwohl es sich „nur“ um einen Public Key handelt, suggeriert die Verwendung: Hier wird nichts dem Zufall überlassen. Eine Kombination aus agencyId, companyId und serverId lässt vermuten, dass die Terminals zentral ausgerollt und individuell verschlüsselt aktiviert werden.
Ein Reverse Engineering wäre selbst mit Root-Zugriff keine triviale Aufgabe – besonders da keine privaten Schlüssel auffindbar sind. Wir sprechen hier definitiv von industriellem Anspruch.
Die BIERCard im Code
Mittels strings auf den Binaries automat und biertool fanden wir klare Bezüge zu einer C++-Klasse BierCard. Methoden wie BierCard::sendCmd() oder BierCard::switch2rescue() lassen vermuten, dass die Firmware modular auf das Umschalten zwischen Haupt- und Backup-System vorbereitet ist – vermutlich per seriellem Trigger über den ATmega:
BierCard::ReturnCode BierCard::switch2rescue()
Ein eindeutiger Cliffhanger für unser zukünftiges Kapitel, in dem wir uns die „Backup“-Karte vornehmen werden.
Besonders nerdig: Die Code-Pfade zeigen auf ../ibet/cashacceptor/biercard.cpp, was einen vollständigen C++-Quelltext vermuten lässt – leider natürlich nur als kompiliertes Binär vorliegend.
Die Fundstücke im Detail
Zu den spannendsten Fundstücken der Produktiv-Karte gehören:
automat – Hauptsteuerprogramm mit GUI-Funktionalität (vermutlich Qt-basiert)
biertool – Kommandozeilentool zur Kommunikation mit der BIERCard
Diverse Shellskripte zur Erkennung, Konfiguration und Reboot-Steuerung
Tools zur Barcodescanner-, Chipkarten- und Cashbox-Verwaltung
Feste Schnittstellen: /dev/ttyS0, /dev/ttyS2 und ein Chipkartenleser SCM SCR 333
Automatisiertes Speichern und Aktualisieren von Konfigurationen
Netzwerkbindung an eine feste Adresse 192.168.100.11
Hinweise auf Qt-basierte Architektur in den Binärdaten
Eine 3. Partition für Sicherungskopien und Versionsverwaltung (/mnt/cf3)
Eine Versionsdatei biercard_version mit Release-Informationen
Hinweise auf Debug- und Entwicklerfunktionen (u. a. elousbd, set_ibet_conf_option.sh, biertool, copy_config_files.sh)
Wer tiefer ins Thema Reverse Engineering alter Hardware eintauchen möchte, dem sei RetroReversing.com empfohlen – dort findest du fundierte Analysen und Community-Wissen zu klassischen Embedded-Systemen, Konsolen und Industrieelektronik.
Fazit: Reverse Engineering einer CF-Card mit Überraschungen
Die BIERCard entpuppt sich als modularer Embedded-Systemträger mit Sicherheitsfokus, Wartungsskripten und flexibler Systemstruktur – perfekt für Industrieumgebungen, aber auch für Nerds wie uns ein echter Schatz.
Ob wir das System je vollständig knacken? Vielleicht. Aber bis dahin bleibt uns ein würdiger Cliffhanger: BierCard::switch2rescue() – was passiert wohl, wenn wir die Backup-Karte aktivieren?
Affiliate-Tipp*: Wer ähnliche alte Systeme analysieren will, braucht solide Hardware – z. B. dieses CF-Kartenlesegerät* (bezahlter Link) oder einen günstigen USB-Seriell-Adapter* (bezahlter Link) für alte Steuerplatinen.
Stell dir vor, du öffnest eine Webseite – und sie sieht aus wie der Ausdruck eines Kassenzettels. Kein Bild, kein Layout, kein CSS, nur Text. Willkommen in der Ära des WAP Browser, dem Wireless Application Protocol – dem Versuch, das Internet auf ein Nokia 3310 zu stopfen. Ja, das Internet. Auf einem monochromen Display mit 84 × 48 Pixeln* (bezahlter Link).
Für alle, die sich gerade wundern: WAP war Anfang der 2000er eine große Sache. Oder sollte es zumindest werden. Mobilfunkanbieter überschlugen sich mit ihren „Internet-Angeboten“ für unterwegs. Die Realität? Scroll-Orgien auf pixeligen Displays mit Ladezeiten, die dir das Mittagessen verdarben.
Was ist ein WAP Browser? Einfach erklärt
WAP war ein Standardprotokoll, um Inhalte auf Mobiltelefonen zugänglich zu machen – und zwar zu einer Zeit, als „Smartphone“ noch nach Science-Fiction klang. Die Basis bildete eine eigene Sprache: WML (Wireless Markup Language), eine Art abgespecktes HTML mit weniger Funktionen als ein Toaster mit Display.
Webseiten mussten extra für WAP umgeschrieben werden. Bilder wurden durch ASCII-Smileys ersetzt, Layouts durch einfache Listen. Die Navigation bestand aus Menüpunkten, durch die man sich mit den Pfeiltasten quälte. Und trotzdem galt es als technisches Wunder.
Was konnte man mit einem WAP Browser machen?
Die Möglichkeiten waren überschaubar, aber für damalige Verhältnisse beeindruckend:
Aktuelle Nachrichten lesen (in 3-Zeilen-Abschnitten)
Wetter abrufen (wenn’s nicht schon vorbei war)
Klingeltöne oder Logos kaufen (Jamba Sparabo winkt)
Erste rudimentäre E-Mail-Dienste nutzen
Mobile Banking wagen (nur für besonders Mutige)
Das Ganze funktionierte ungefähr so flüssig wie ein 56k-Modem unter Wasser.
Technik hinter dem WAP Browser: So funktionierte es
Damit WAP funktionierte, brauchte es ein WAP-Gateway beim Mobilfunkanbieter, das die Inhalte vom Internet umcodierte. Eine Art Übersetzer von HTML in WML. Leider lag genau hier eine massive Sicherheitslücke: HTTPS-Verbindungen wurden am Gateway entschlüsselt – ein gefundenes Fressen für neugierige Netzbetreiber.
Die bekanntesten Geräte mit WAP-Unterstützung waren etwa das Nokia 7110 oder später das Siemens S45. Sie hatten eine „WAP-Taste“, die meist direkt ins kostspielige Datenchaos führte. Die Tarife? Abgerechnet wurde pro Minute oder pro KB – beides schmerzhaft.
Warum der WAP Browser gescheitert ist
Kurz gesagt: zu langsam, zu teuer, zu nutzlos. Das Web entwickelte sich rasant weiter, WAP blieb statisch. Entwickler mussten Inhalte doppelt pflegen (HTML & WML), was kaum jemand tat. Und sobald HTML-Browser auf Smartphones Einzug hielten (z. B. mit dem iPhone oder Blackberry), war WAP so überflüssig wie ein Faxgerät im Wald.
Was bleibt vom WAP Browser heute?
Die damalige Website des WAP-Forums ist heute nur noch über die Wayback Machine erreichbar – ein digitales Fossil der Frühzeit des mobilen Internets.
Und wer die gute alte Pixelgrafik aus Nokia-Zeiten vermisst, findet mit dem Divoom Pixoo Pixel Art Bilderrahmen* (bezahlter Link) ein stylisches Gadget, das Retro-Charme mit moderner Technik verbindet.
Nicht viel – außer einer seltsamen Mischung aus Nostalgie und Fremdscham. Aber WAP war ein Anfang. Der erste Versuch, Inhalte mobil zugänglich zu machen. In gewisser Weise der Vorfahre responsiver Webseiten. Und vielleicht ein Vorbote dessen, wie Technik manchmal läuft: mit guten Ideen, aber schlechter Umsetzung.
Fazit: Der WAP Browser als digitale Urform des mobilen Webs
WAP war wie ein Zettel mit Wetterbericht aus dem Faxgerät. Aber immerhin mobil. Heute lachen wir darüber, aber ohne diese Zwischenstufen wäre das mobile Internet nie dort angekommen, wo es heute ist.
Also danke, WAP. Auch wenn du die meisten Nutzer mehr gekostet als genutzt hast.
Meta-Description: XML und XSLT sollten einst das Web revolutionieren – doch was wurde wirklich aus den beiden? Ein zynischer Blick auf tote Technologien, überladene Tags und moderne Alternativen.
1. Einleitung: Der Traum vom semantischen Web
Es war einmal, im finsteren Zeitalter vor HTML5, da träumten Webentwickler von einer besseren Welt. Einer Welt, in der man sich seine Tags selbst aussuchen konnte. Einer Welt, in der Design und Inhalt so konsequent getrennt waren, dass man beide hassen lernte. Einer Welt… mit XML und XSLT.
XML – das Extensible Markup Language – klang nach Fortschritt, nach Struktur, nach Ordnung im HTML-Chaos. Und XSLT? Das war der Versuch, Stylesheets mit einer Gehirnverdrehung zu kombinieren. Wenn du jemals versucht hast, ein <xsl:for-each> mit einem Namespace zu debuggen, dann hast du wahrscheinlich heute noch Albträume in UTF-8.
Doch was wurde eigentlich aus dieser glorreichen Vision? Warum sieht das Web heute aus wie React-Komponenten mit CSS-Grütze – und nicht wie ein gepflegtes XML-Skulpturenmuseum?
Willkommen im Gruselkabinett der Webentwicklung. Wir graben aus, was längst vergessen schien – und zeigen dir, warum das vielleicht auch besser so ist.
2. XML: Die Sprache der Hoffnung – und des Wahnsinns
In den späten 90ern war XML das neue heiße Ding. Die Idee: HTML ist zu fest verdrahtet, zu unflexibel. XML dagegen lässt dich selbst bestimmen, wie deine Tags heißen. Statt <div> und <p> konntest du plötzlich <produkt>, <preis> oder <superMegaDatenModul> verwenden.
Das versprach Semantik, Struktur, Zukunft – und endete in Chaos, Namespaces und nicht enden wollenden DTDs. Der Mensch war frei. Viel zu frei.
3. XSLT: Wenn Stylesheets Albträume bekommen
Dann kam XSLT – das „eXtensible Stylesheet Language Transformations“. Der Name allein klingt schon nach XML-Sekte. Die Idee war eigentlich clever: Statt HTML mit Layout zu schreiben, schreibst du XML mit Inhalt – und XSLT formt es zu hübschem HTML.
Oder zu dem, was man damals für hübsch hielt.
Aber XSLT war nicht CSS. Es war XPath, Templates, Bedingungshölle und eine Schreibweise, bei der jedes < doppelt und jedes </ dreifach gezählt werden musste. Wer damit arbeiten musste, lernte schnell: Das Web ist nicht freundlich.
4. 🧟 Das Gruselkabinett: Ein extremes, aber valides XML+XSLT-Beispiel
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rezept-style.xsl"?>
<kochbuch xmlns="https://prokrastinerd.de/rezept"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="https://prokrastinerd.de/rezept rezept.xsd">
<rezept datum="2025-04-14T12:34:56" vegetarisch="true">
<titel>XML-Auflauf mit XSLT-Kruste</titel>
<autor>Gray The Zebra</autor>
<zutaten>
<zutat menge="200g">Verzweiflung</zutat>
<zutat menge="100ml">Tränen von Entwicklern</zutat>
<zutat menge="1 EL">Namespace-Magie</zutat>
</zutaten>
<zubereitung>
Alles in eine Datei werfen, mehrfach validieren,
bei Fehlern laut fluchen und dann im Browser servieren.
</zubereitung>
</rezept>
</kochbuch>
XML ist nicht tot. Es ist nur dahin zurückgekehrt, wo es hingehört: tief in die dunklen Eingeweide von Maschinenprotokollen, Konfigurationsdateien, E-Book-Formaten und Industrienormen.
Und XSLT? Hat sich dort in einer .xsl-Datei zusammengerollt und schläft. Hoffentlich für immer.
Aber wir danken ihnen für ihren Dienst. Möge der Validator immer mit euch sein. Amen.
