Direkte Win32-API, seltsam geformte Fenster und warum die meisten davon verschwunden sind

• Moderne Windows-Apps sind durch die Abhängigkeit von webbasierten Frameworks langsam und schwergewichtig geworden, und die Kontrolle auf Betriebssystemebene aus der Win32-Ära ist verloren gegangen
• Mit der Win32-API ließ sich über Message Loops und HRGN-Objekte die Fensterform frei definieren, und nicht standardisierte Fensterdesigns waren weit verbreitet
• Mit Bitmaps und der Layered-Window-Technik konnten frei geformte Fenster mit Transparenz und Animation umgesetzt werden
• Benutzerdefinierte Fenster verschwanden jedoch allmählich wegen der Komplexität, alle Grundfunktionen manuell implementieren zu müssen, und wegen einer veränderten Nutzerpräferenz hin zu Einfachheit
• Dennoch bietet Win32 weiterhin Freiheit bei Fenstersteuerung und Experimenten und erhält die Möglichkeit, kreative Desktop-Software zu entwickeln

---

Die Monotonie moderner Windows-Apps und die verlorene Freiheit von Win32

• Die meisten aktuellen Windows-Desktop-Apps laufen auf Browser-Wrappern wie React, Electron, Tauri und haben sich zu komplexen webbasierten Strukturen entwickelt, die langsam sind und übermäßig viel Speicher verbrauchen
  • Sogar ein einfacher Editor belegt 50 MB Speicher, während eine funktionsgleiche App, die in reinem Win32-C geschrieben ist, nur 1,8 MB benötigt
  • Selbst auf moderner Hardware erreicht die Speicherauslastung beim Start von Windows 11 77 %
• Früher, als direkt mit der Win32-API programmiert wurde, hatte man vollständige Kontrolle auf Betriebssystemebene
  • Man war damals nicht auf rechteckige Fenster beschränkt und konnte Fenster in nicht standardisierten Formen frei erstellen
  • In der Windows-XP-Ära hatten unter anderem der Windows Media Player und viele andere Apps ein unverwechselbares Äußeres

Die seltsam geformten Fenster von früher

• Windows-Apps wurden einst in vielen unterschiedlichen Formen gestaltet, um Identität und Individualität auszudrücken
  • Media Player sahen wie Hardware aus, Desktop-Maskottchen liefen über den Bildschirm, und Utility-Panels waren wie Instrumententafeln, Spielzeuge oder außerirdische Konsolen gestaltet
  • Die Fensterform musste nicht rechteckig sein, und das Ziel der UI lag eher in der Individualität als in der Benutzbarkeit
• Dass solche Formen heute verschwunden sind, liegt daran, dass Programmierer das Fenster selbst nicht mehr kontrollieren
  • Die meisten modernen UI-Frameworks verbergen das Betriebssystem, und Entwickler arbeiten nur noch innerhalb eines begrenzten rechteckigen Bereichs

Die nachrichtenbasierte Struktur von Win32 und Fensterkontrolle

• Der Kern der Win32-Programmierung liegt im ereignisbasierten Message Loop
  • Ein Loop aus GetMessage, TranslateMessage, DispatchMessage bildet die Grundlage aller Abläufe
  • Durch die Verarbeitung von Nachrichten wie WM_CREATE, WM_PAINT, WM_SIZE, WM_DESTROY wird das Verhalten des Fensters definiert
• Mit HRGN (Region Object) lässt sich die Form eines Fensters frei verändern
  • Mit SetWindowRgn wird einem Fenster eine Region zugewiesen, und nur diese Region wird als tatsächliches Fenster erkannt
  • Im Beispielcode wird mit CreateEllipticRgn ein elliptisches Fenster erzeugt und die Drag-Funktion ohne Titelleiste direkt implementiert
  • Bei WM_LBUTTONDOWN wird WM_NCLBUTTONDOWN mit HTCAPTION gesendet, um das Verschieben des Fensters nachzuahmen
• Das Entscheidende ist: Die Form zu erzeugen ist einfach, aber die vom Standard-Frame bereitgestellten Funktionen müssen selbst implementiert werden

Bitmap-basierte Fenster und Layered Windows

• Das Beispiel drivenbyimage/main.c definiert die Fensterform anhand von Bitmap-Daten
  • shape.bmp wird geladen, und Pixel außer der transparenten Farbe (Magenta) werden als Fensterregion gesetzt
  • Die Bitmap dient gleichzeitig als auf dem Bildschirm gezeichnetes Bild und als tatsächliche Fensterform
  • Frühere Apps mit Skins setzten auf diese Weise Formen wie Hund, Raumschiff, Radio oder Charaktergesicht um
• Bitmap-basierte Regionen haben jedoch harte Kanten und erlauben keine halbtransparente Darstellung
  • Für weiche Ränder oder Animationen ist ein Layered Window (WS_EX_LAYERED) erforderlich
• Im Beispiel Animated/ wird ein 32-Bit-Bild mit transparentem Alphakanal per UpdateLayeredWindow hochgeladen
  • Mit GDI+ wird ein Sprite-Sheet in ein Bitmap im Speicher gezeichnet, um zwischen Frames zu wechseln, und anschließend auf dem Desktop angezeigt
  • Die Fensterform ist nicht fest vorgegeben; stattdessen wird der aktuelle Pixelzustand selbst zur Fensterform
  • Dieser Ansatz unterstützt weiche Transparenz, Formänderungen pro Frame und natürliche Animationen

Die Schwierigkeiten benutzerdefinierter Fenster und der kulturelle Wandel

• Wenn man mit der Win32-API benutzerdefinierte Fenster erstellt, muss man jedes Detail des Verhaltens selbst behandeln
  • Dragging, Größenänderung, Schließen, Tastatureingaben, DPI-Anpassung und andere Funktionen, die Standardfenster automatisch übernehmen, müssen manuell implementiert werden
  • Ein Prototyp ist leicht erstellt, aber ihn zu einem ausgereiften Produkt zu verfeinern erfordert hohe Kosten und viel Aufwand
• Nutzer begannen, Stabilität und Einfachheit solchen visuellen Experimenten vorzuziehen
  • Nicht standardisierte Fenster wurden oft mit Adware, Toolbars und unnötigen Utilities verbunden, was zu einer negativen Wahrnehmung führte
  • Infolgedessen galten „seltsam geformte Fenster“ eher als verspieltes Gimmick denn als ernsthafte Software

Die fortbestehenden Möglichkeiten und die Bedeutung von Win32

• Trotzdem bietet Win32 weiterhin direkte Kontrolle und Freiheit zum Experimentieren
  • Schon mit Nachrichten, Handles und Zeichen-APIs ist Fensterkontrolle auf Betriebssystemebene möglich
  • Rechteckige Fenster sind in den meisten Fällen sinnvoll, doch es erinnert daran, dass ihre Form nur eine Wahl und kein Zwang ist
• Der Beispielcode ist im GitHub-Repository WierdApps veröffentlicht
  • Enthalten sind drei Samples: elliptische Fenster, bitmap-basierte Fenster und ein animiertes Maskottchen
  • Win32 ermöglicht weiterhin die Entwicklung kreativer und experimenteller Desktop-Software

[GN⁺]

Hacker-News-Kommentare

• Hoffentlich kommen seltsam geformte Fenster nicht wieder zurück.
  Nur weil man etwas bauen kann, heißt das nicht, dass man es auch bauen sollte.
  Dass Apps, die mit Browser-Wrappern wie React, Electron, Tauri erstellt werden, heute alle ähnlich aussehen, liegt daran, dass sie nicht die GUI-Frameworks des OS verwenden.
  Wenn Apps jeweils ihre eigenen nicht standardisierten Widgets oder Farben und Formen verwenden, leiden Barrierefreiheit und Nutzbarkeit.
  Ironischerweise sind die Apps, die heute besonders stark auf „Identität“ setzen, meist Dinge wie Treiber-Kontrollzentren, die Hardware-Hersteller dazwischenschieben, und genau das ist die schlimmste Art von Bloatware.

  • Electron erzeugt eher das gegenteilige Problem. Alle Apps sehen jeweils anders aus und halten sich nicht an die Plattformrichtlinien.
  • Barrierefreiheit ist ein wichtiger Bereich und teils auch gesetzlich vorgeschrieben. Moderne Cross-Platform-GUI-Frameworks unterstützen Screenreader für Sehbehinderte und HiDPI in der Regel gut.
  • Ich finde solche ungewöhnlichen Fensterformen trotzdem cool. Wenn jemand das noch einmal versucht, bin ich dafür.
  • In der Vista-Zeit habe ich viele nicht standardisierte UIs gesehen, die mit WPF und XAML gebaut waren; beim Ändern der Fenstergröße oder Verschieben auf einen anderen Monitor war das Scaling furchtbar, und am Ende blieb nur Frust.
  • Ich sehe das genau andersherum. Ich möchte Computer wieder spaßig und cool machen wie früher. Heute sieht alles wie ein Aktenordner aus. Die interessanten Teile des Lebens sind von Natur aus optional.

• Ich mag Win32, aber ich sehe die frühere Kultur seltsamer Skins als Vorboten der heutigen Denkweise „Branding = Identität“.
  Das hat letztlich zur unkontrollierten Verbreitung von Electron und halbfertigen Widget-Bibliotheken geführt.
  Außer bei Spezialanwendungen wie Blender oder Ardour hat eine eigenwillige GUI keine Priorität.

  • Electron-Apps sehen alle gleich aus. Win32-Skins wie bei Winamp hatten dagegen wenigstens Persönlichkeit.
    Die heutigen Betriebssysteme sind nicht mehr für Einzelpersonen, sondern für Unternehmen. Die Zeit von Win3.1 bis XP war das eigentliche Zeitalter des Personal Computing.
  • Für normale Office-Apps sollte man native Controls verwenden, aber bei einem komplett angepassten Fullscreen-UI wie auf dem iPad oder anderen Smart Devices kann das großartig aussehen und gut funktionieren.

• Heutige React-basierte Apps sind weder mit dem OS noch untereinander konsistent.
  Alle sechs Monate ändert sich das UI, ohne dass sich die UX verbessert. An Barrierefreiheit (a11y) denkt dabei offenbar niemand mehr.

• Früher wurde Software von kleinen Teams gebaut und über lange Zeit stabil gepflegt.
  Heute geht es um schnelle Iteration und große Teams, und Flat Design ist das Ergebnis, das zu diesem Umfeld passt.
  Skeuomorphes Design ist teuer, weil Assets ständig neu erstellt werden müssen.
  Am Ende sind Tempo und Skalierung zur Priorität geworden – so wie flach verpackte Möbel handgeschnitzte Möbel verdrängt haben.

  • Tatsächlich muss man auch in der Win32 API nicht alles selbst implementieren. Man kann die Standard-Nachrichtenverarbeitung delegieren.
  • Skeuomorphes Design war in seiner Nachahmung der Realität oft zu weit gegangen und dadurch visuell komplex und unordentlich. Die Richtung war gut, aber die Umsetzung schwierig.
  • Letztlich geht es um Kostensenkung. Man verzichtet auf bessere Nutzbarkeit, so wie man in Autos Tasten durch große Touchscreens ersetzt hat.

• Im HiDPI-Zeitalter ist es schwieriger geworden, UIs wie früher pixelgenau zu zeichnen.
  Damals, zu Zeiten von Win95 bis XP, konnte man direkt in den Front Buffer zeichnen, was schnell war und wenig Speicher brauchte; heute hält jedes Fenster einen Backing Buffer vor, was mehr RAM kostet.

• Als ich den Satz „The point was usually not usability. It was identity.“ gelesen habe, wirkte das auf mich wie ein von einem LLM geschriebener Text.

  • Ich hatte denselben Eindruck. Trotzdem hatte ich das Gefühl, dass der Autor etwas ausdrücken wollte.
  • Jeder Satz wirkte, als wäre er von einem LLM generiert worden.

• Ich habe früher Windows-Apps entwickelt, und das Win32-Interface ließ sich nur zu etwa 90 % kontrollieren.
  Ich erinnere mich, dass ich zum Ändern des Farbthemas MessageBox selbst neu implementieren musste.

  • Früher konnte man MessageBox mit einem Win32-Hook modifizieren. Über HCBT_CREATEWND bekam man ein HWND und konnte per Subclassing eingreifen.
  • Wenn man tiefer hineingeht, muss man in manchen Fällen statt User32.dll sogar Win32U.dll hooken.
  • Das selbst nachzubauen ist schmerzhaft. Ich frage mich, ob es mit Qt etwas besser wäre.

• Notepad, in reinem Win32-C geschrieben, braucht nur 1,8 MB, während heutige Editoren 50 MB verbrauchen.

  • Selbst ein minimales „Hello World“-Programm braucht 500 KB. Die Systembibliotheken belegen standardmäßig Speicher.
  • Das moderne Windows 11 Notepad nutzt standardmäßig 32 MB, weil es Tabs, formatierten Text und AI-Funktionen enthält.
    Sogar GNU Emacs verbraucht weniger Speicher.
    Dagegen braucht das textbasierte EDIT.EXE nur 520 KB und ist viel effizienter.

• Früher gab es auf dem Mac eine CD-Brenn-App namens Disco, bei der während des Brennvorgangs eine Rauchanimation über dem Fenster aufstieg.
  Steve Jobs hat das selbst auf der Bühne vorgeführt und mochte es sehr.

• Ich fand es schön, dass im Artikel auch Desktop-Maskottchen erwähnt wurden.
  Vor Kurzem habe ich ein Video zu einem mit Godot erstellten Desktop-Pet gesehen; es läuft plattformübergreifend.
  Es braucht etwas Handarbeit, ist aber nicht so komplex wie auf Win32-Niveau. Für Fans von Desktop-Pets ist das eine gute Wahl.