Moderne Softwareentwicklung im Jahr 2025: IDEs, die zweistellige Gigabytes verschlingen. Build-Systeme, die mehr RAM brauchen als unsere ersten Computer Festplattenspeicher hatten.

Projektverzeichnisse vollgestopft mit config.json, settings.yaml, .eslintrc, tsconfig.json, package.json, docker-compose.yml, bevor auch nur eine Zeile eigentlicher Code existiert. Das ist 'normal.'

Und wer glaubt, Clang sei ein schlanker, moderner Compiler, soll mal versuchen, das Ding manuell zu bauen. Viel Spaß mit den 200+ CMake-Flags und LLVM als Abhängigkeit.

Das ist der Stand der Technik. Das ist... alternativlos?

Falsch.

Der Auslöser

Es fing mit Sean Barrett an. Falls der Name nichts sagt: Er ist der Kopf hinter stb (https://github.com/nothings/stb), einer Sammlung von Header-Only-Libraries, die in der Gamedev- und Embedded-Welt quasi Kultstatus haben. stb_image.h allein dürfte in Millionen von Projekten stecken.

Und dieser Mann? Entwickelt in Visual Studio 6.0. Von 1998.

Nicht als Retro-Projekt. Einfach so. Als sein daily driver.

Meine erste Reaktion: Warum zur Hölle tut jemand sich das an? Meine zweite Reaktion: Ich muss das ausprobieren.

Das Experiment

Die ISOs zu finden war trivial, Anna's Archive sei Dank. Zwei Disk-Images, Windows 11 mit neuestem Kernel als Host. Was soll schon schiefgehen?

Die Installation startete, ein paar Warnungen poppten auf, ein paar DLLs fehlten angeblich. Klassiker. Ich brach das Setup ab.

Aber: Die Dateien existierten bereits auf dem Dateisystem.

Also: Direkt starten. Doppelklick auf MSDEV.EXE.

Es funktionierte. Einfach so:

Keine Kompatibilitätsmodus-Trickserei. Kein Fummeln an Registry-Keys. Keine Stack-Overflow-Recherche mit obskuren Workarounds. Eine 26 Jahre alte IDE startete auf einem aktuellen Windows 11 und lief.

Und das bei einer Größe von 30 Megabyte. Das ist weniger als ein durchschnittliches NPM-Paket. Das ist weniger als manche einzelne Header-Datei in modernen Frameworks. Das ist weniger als der Electron-Wrapper einer simplen To-Do-App.

Und nebenbei liefert es:

• - Einen vollständigen C/C++-Compiler
• - Einen Debugger
• - Einen Editor mit Syntax-Highlighting
• - IntelliSense (ja, wirklich)
• - Einen Resource-Editor
• - Profiling-Tools

hello 1998

New -> Leeres C-File. Klassiker:

#include  

int main(void) {
    printf("Hello, 1998!\n");
    return 0;
}

Build drücken.

Kompiliert. Läuft. Überraschend? Eigentlich nicht. Es ist ANSI C. Das kompiliert auf einem Toaster, solange der einen C-Compiler hat. Der Standard ist von 1989 und funktioniert heute noch überall.

Warum funktioniert MSDEV.EXE überhaupt?

Weil es Win32-API Native ist:

• - Existiert seit Windows NT 3.1 (1993)
• - CreateWindow(), SendMessage(), ReadFile() – gleiche Signaturen seit 30+ Jahren
• - Microsoft kappt diesen Draht nie. Backwards Compatibility um jeden Preis
• - VS6 ist pure Win32. Kein .NET, kein Electron, keine Abstraktionsschichten

Was ist passiert?

Die Frage, die sich aufdrängt: Was ist in den letzten 26 Jahren schiefgelaufen?

Visual Studio 2022? Minimum 20 GB. JetBrains CLion? Ähnliche Größenordnung. Und selbst leichtgewichtige Alternativen wie VS Code werden mit Extensions schnell zum Multi-Gigabyte-Monster. Und wir editieren ja eigentlich nur Text!

Klar, moderne IDEs können mehr. Language Server Protocols, Container-Integration, AI-Assistenten, Cloud-Synchronisation. Aber brauche ich das alles, wenn ich einfach nur C-Code kompilieren will?

Sean Barrett sagt dazu: 'things, maybe they've gotten better... but you know... probably not.' Und wenn man sich seine Arbeit anschaut, die Qualität und Effizienz seines Codes, dann liegt er wohl nicht ganz falsch.

... na und?

Dieses kleine Experiment hat etwas in Perspektive gerückt:

Komplexität ist nicht kostenlos.

Jedes Feature, jede Abstraktion, jede zusätzliche Schicht hat einen Preis. In Speicher, in Startzeit, in kognitiver Last. Mehr Lines of Code mehr Bugs.

Und irgendwann muss man sich fragen: Kaufe ich mir damit tatsächlich Produktivität, oder nur das Gefühl von Produktivität?

Manchmal ist die Antwort auf die Frage 'Wie löse ich dieses Problem?' nicht 'Welches Framework installiere ich?', sondern 'Brauche ich überhaupt eins?'

Sean Barrett weiß das. Jetzt weiß ich es auch ein bisschen besser.