Warum Windows so wurde, wie es heute ist: Die Evolution von Windows aus Entwicklersicht

· Aktualisiert am: · · Windows, Windows-App-Entwicklung, Kompatibilität, Betriebssystemgeschichte, Win32, .NET, Sicherheit

1. Einleitung

Wenn von der Geschichte von Windows die Rede ist, geht es meist um optische Veränderungen.

Das Startmenü kam.
Aero hielt Einzug.
Es wurde zum Startbildschirm.
Die Taskleiste änderte ihre Position.
Die Ecken wurden rund.

Natürlich ist auch das Windows-Geschichte.

Aus Sicht von Windows-App-Entwicklern liegen die wirklich großen Veränderungen aber nicht nur im Bildschirmdesign. Wichtiger sind vielmehr Veränderungen wie diese:

  • Stabilität des Betriebssystems
  • Speicherschutz
  • Rechteverwaltung
  • Treibermodelle
  • 32-Bit-/64-Bit-Unterstützung
  • Kompatibilität mit COM, ActiveX und der Win32-API
  • .NET Framework und .NET
  • UAC
  • Windows Update
  • Sicherheitsfunktionen
  • Koexistenz von Store-Apps und Desktop-Apps
  • WSL
  • TPM, Secure Boot
  • Hohe DPI, Mehrfachbildschirme
  • Hybrid-CPUs und Energiesparsteuerung

Windows ist kein Betriebssystem, das sich einfach nur äußerlich weiterentwickelt hat, sondern eines, das alte Apps so lange wie möglich lauffähig hielt, während es Stabilität, Sicherheit, Leistung und Hardwareunterstützung Schritt für Schritt anhob. Genau das macht Windows sowohl faszinierend als auch mühsam.

In diesem Artikel blicken wir nicht auf eine bloße Zeitleiste der Windows-Generationen zurück, sondern auf die Veränderungen aus Sicht eines Windows-App-Entwicklers.

Bevor es weitergeht, hier eine kurze Übersicht über Abkürzungen, die in den folgenden Kapiteln ohne weitere Erklärung auftauchen.

Begriff Vollständiger Name Bedeutung in einem Satz Kommt vor allem in Kapitel
UAC User Account Control Sorgt dafür, dass auch Administratorkonten standardmäßig mit einem eingeschränkten Token laufen und nur bei Vorgängen, die Administratorrechte benötigen, eine Erhöhung anfordern. Eingeführt mit Vista 7, 13, 14
WDDM Windows Display Driver Model Das mit Vista eingeführte Anzeigetreibermodell, das die Bildschirmdarstellung grundlegend auf die GPU umstellte 7, 11
UEFI Unified Extensible Firmware Interface Der Firmware-Standard, der das klassische BIOS ablöst und die Grundlage für Secure Boot bildet 11
Secure Boot Sicherer Start Eine UEFI-Funktion, die nur Bootloader und Treiber mit überprüfbarer Signatur starten lässt 11
TPM Trusted Platform Module Eine Sicherheitsfunktion zur Schlüsselerzeugung und -speicherung sowie zur Messung der Startkonfiguration. Bei Windows 11 ist Version 2.0 Voraussetzung 11
WinRT Windows Runtime Die mit Windows 8 eingeführte neue API-Grundlage auf Basis von COM 9
ESU Extended Security Updates Ein Mechanismus, um auch nach Support-Ende gegen Bezahlung noch für eine gewisse Zeit ausschließlich kritische Sicherheitsupdates zu erhalten 14
LTSC Long-Term Servicing Channel Eine Windows-Variante, die keine Funktionsupdates erhält, dafür aber lange unterstützt wird 14

2. Die Geschichte von Windows ist auch die Geschichte des Zusammenflusses zweier Stränge

Um die Geschichte von Windows zu verstehen, sollten Sie zunächst festhalten, dass es bei Windows im Wesentlichen zwei große Entwicklungslinien gab.

Die Linie Windows 95 / 98 / Me, die sich über Heim-PCs verbreitete.
Die Linie Windows NT / 2000, die im Hinblick auf Unternehmen und geschäftliche Nutzung heranwuchs.

Diese beiden Linien fließen mit Windows XP entscheidend zusammen.

MS-DOS / Windows 3.xWindows 95 / 98 / MeHeim-PC, Benutzerfreundlichkeit, PeripheriegeräteWindows NT / 2000Geschäftlich, Stabilität, RechteverwaltungWindows XPVereinigung von Heim- und GeschäftsbereichWindows Vista / 7UAC, WDDM, verschärfte SicherheitWindows 8 / 8.1Touch, Store, CloudWindows 10Kontinuierliche Updates, WSL, Kompatibilität und ModernisierungWindows 11Sicherheitsbasis, moderne Hardware

Ohne diese Entwicklungslinien zu kennen, ist die heutige Gestalt von Windows etwas schwer zu verstehen.

Warum gibt es noch alte APIs?
Warum gibt es Probleme mit Administratorrechten?
Warum laufen 32-Bit-Apps noch immer?
Warum wird direktes Schreiben in Program Files zum Problem?
Warum gibt es manchmal Ärger mit Treibern und Peripheriegeräten?

Das sind weniger reine Designfehler als vielmehr das Ergebnis davon, dass Windows über lange Zeit die reale PC-Nutzung mitgetragen hat.

3. Windows 95 / 98: Die Zeit, in der der Heim-PC zum Standard wurde

Windows 95 ist das Betriebssystem, das die Bedienbarkeit des heutigen Windows entscheidend geprägt hat.

Das Startmenü.
Die Taskleiste.
Minimieren-, Maximieren- und Schließen-Schaltflächen.
Plug and Play.
Netzwerkfunktionen.
Der Zugang zum Internet.

Bedienweisen, die heute selbstverständlich sind, nahmen in dieser Zeit weitgehend Gestalt an.

Aus Entwicklersicht war die Ära von Windows 95/98 die Zeit, in der der PC vom „Gerät für ein paar Kenner“ zum „ganz normalen Werkzeug für Zuhause und Büro“ wurde.

Anwendungen installieren.
Einen Drucker anschließen.
Über ein Modem mit dem Internet verbinden.
Software von CD-ROM installieren.
Mit Digitalkameras und USB-Geräten umgehen.

Diese Art der Nutzung verbreitete sich schlagartig.

Bei Windows 98 wurden Elemente wie Internet, USB, DVD, Multimedia und Heimnetzwerke noch stärker.

Allerdings blieb in dieser Windows-Ära auch die von DOS ererbte Instabilität bestehen.

Eine App riss das ganze Betriebssystem mit sich.
Eine schlecht geschriebene Treiber führte zum Bluescreen.
Eine falsche DLL-Version brach eine andere App.
Die rätselhafte Faustregel „nach einem Neustart geht’s wieder“ hatte allgemeine Gültigkeit.

Für alle, die diese Zeit kennen, war Windows zugleich praktisch und ein wenig unheimlich.

4. Windows Me: Der letzte Kraftakt der Consumer-DOS-Windows-Linie

Windows Me ist ein Betriebssystem, das sich schwer bewerten lässt.

Allgemein wird es meist als „das instabile Windows“ dargestellt.
Tatsächlich haben wohl viele wenig gute Erinnerungen daran.

Aber auch Windows Me hatte neue Ansätze.

System Restore.
System File Protection.
AutoUpdate.
Digitale Medienfunktionen.
Heimnetzwerk.

Mit anderen Worten: Die Richtungen, die im heutigen Windows selbstverständlich sind – „bei Problemen zurücksetzen“, „wichtige Dateien schützen“, „Updates automatisieren“ – zeichneten sich bereits ab.

Als Fundament war es allerdings die Schlussphase der Consumer-DOS-Windows-Linie.

Funktional wurde versucht, moderne Elemente einzubauen.
Doch die grundlegende Substanz des Betriebssystems reichte noch nicht aus.

Genau diese Lücke war meiner Meinung nach die eigentliche Schwierigkeit von Windows Me.

Aus Entwicklersicht lehrt uns Windows Me: „Um neue Erfahrungen aufzusetzen, muss man das Fundament des Betriebssystems selbst verändern.“

Und die Antwort darauf war die Vereinigung mit der NT-Linie.

5. Windows NT / 2000: Das Fundament des geschäftlichen Windows

Neben dem Consumer-Windows gab es die eigenständige Linie von Windows NT.

Die NT-Linie war von Anfang an ein Windows, das stark auf geschäftliche Nutzung ausgerichtet war.

Stabilität.
Speicherschutz.
Rechteverwaltung.
Dienste.
Netzwerk.
Unternehmensinterne Verwaltung.

Ein wichtiger Meilenstein dieser Linie ist Windows 2000.

Windows 2000 war ein Betriebssystem, das die mit Windows 95/98 gewonnene Benutzerfreundlichkeit aufnahm und gleichzeitig die Stabilität und Verwaltbarkeit der NT-Linie in den Vordergrund stellte.

Für Entwickler ist wichtig, dass Windows etwa ab diesem Zeitpunkt seinen Charakter zunehmend von einem „Heim-Betriebssystem, bei dem Abstürze halt vorkommen“ hin zu einer „Plattform, die den Geschäftsbetrieb trägt“ verschob.

Als Windows-Dienst resident laufen.
Ins Ereignisprotokoll schreiben.
Über Benutzerrechte nachdenken.
In einer Netzwerkdomäne verwaltet werden.
Mit Freigabeordnern und Druckern zusammenarbeiten.

Solche Annahmen, die in der heutigen Entwicklung von Geschäftsanwendungen selbstverständlich sind, wuchsen im Kontext der NT-Linie von Windows heran.

6. Windows XP: Die Vereinigung von Heim- und Geschäftsbereich

Windows XP ist eines der wichtigsten Betriebssysteme in der Geschichte von Windows. Der Grund liegt nicht einfach in seiner Beliebtheit, sondern darin, dass sich die Consumer-Windows-Linie und die geschäftliche Windows-NT-Linie hier praktisch vereinigten.

Durch Windows XP konnten sich auch Heim-PCs auf die Stabilität der NT-Linie verlassen. Das war eine enorme Veränderung.

Im bisherigen Consumer-Windows konnte eine fehlerhafte App oder ein fehlerhafter Treiber leicht das gesamte Betriebssystem destabilisieren.
Ab XP lässt sich zumindest auf Fundamentebene auf die stabilere NT-Linie bauen.

Gleichzeitig wurde XP sehr lange genutzt. Das war sowohl positiv als auch schwierig. Durch die lange Nutzungsdauer übernahmen Unternehmenssysteme, interne Werkzeuge, ActiveX, COM-Komponenten, alte Peripheriegeräte und geschäftsspezifische Software in großer Zahl Annahmen aus der XP-Zeit.

XP ist also zugleich der Prototyp des modernen Windows und einer der Ausgangspunkte des bis heute fortbestehenden Alt-Bestands.

Für Windows-App-Entwickler lässt sich die Lehre aus XP auf einen Satz bringen.

Wird ein Betriebssystem lange genutzt, bleiben auch die Annahmen der Apps lange bestehen.

Das ist sowohl ein Kompatibilitätsproblem als auch ein Problem der Geschäftskontinuität.

7. Windows Vista: Oft als Fehlschlag abgetan, aber ein wichtiger Wendepunkt

Windows Vista wird gelegentlich als das unbeliebte Betriebssystem dargestellt.

Langsam.
Zu viele Warnungen.
Treiber passen nicht.
Apps laufen nicht.
XP war besser.

Als Benutzererfahrung von damals hatte diese Bewertung durchaus ihre Gründe.

Aus Sicht von Windows-App-Entwicklern ist Vista jedoch ein wichtiger Wendepunkt.

Besonders groß sind vor allem diese Änderungen.

  • UAC
  • WDDM
  • Aero / Desktop Window Manager
  • Ein neues Treibermodell
  • Verschärfte Sicherheit
  • Verbreitung von 64-Bit-Umgebungen
  • Schreibbeschränkungen für Program Files und den Windows-Ordner
  • Anwendungsmanifeste

Vista brachte Windows „die Unbequemlichkeit, die für sicheres Arbeiten nötig ist“.

Im bisherigen Windows war es viel zu selbstverständlich geworden, mit Administratorrechten zu laufen.
Apps schrieben ihre Konfigurationsdateien in denselben Ordner wie die ausführbare Datei.
Sie schrieben unbekümmert in die Systembereiche der Registrierung.
Sowohl Installer als auch die Anwendung selbst setzten Administratorrechte voraus.

Ein solcher Aufbau war nichts Ungewöhnliches.

Ab Vista funktionierte das nicht mehr so einfach.

Wohin darf eine App ihre Einstellungen schreiben?
Kommen benutzerspezifische Daten nach AppData?
Kommen für alle Benutzer gemeinsame Daten nach ProgramData?
Wo und wie erklärt man dem Benutzer, dass ein Vorgang Administratorrechte erfordert?

Wer sich darüber keine Gedanken machte, dessen App verhielt sich zunehmend nicht mehr wie ein wohlerzogenes Windows-Programm.

Aus Sicht der Anwender war Vista vielleicht lästig. Langfristig betrachtet war es aber die notwendige Stufe, damit Windows zu einem modernen Sicherheitsmodell voranschreiten konnte.

8. Windows 7: Das Betriebssystem, das Vistas Fundament praxistauglich machte

Windows 7 ist als ein außerordentlich ausgereiftes Windows in Erinnerung geblieben.

Es nahm die großen Veränderungen aus Vista und formte sie leichter, benutzerfreundlicher und stabiler.

Auch als geschäftliches Windows war es sehr beliebt und diente in der Windows-App-Entwicklung lange als Referenzumgebung.

Das Entscheidende an Windows 7 ist weniger ein „großer Philosophiewechsel“ als vielmehr seine „praktische Reife“.

Die mit Vista eingeführten Richtungen wie UAC und WDDM blieben erhalten, während sich die Benutzererfahrung verbesserte.

Für Entwickler wurde durch die Verbreitung von Windows 7 eine App-Entwicklung auf Grundlage der Vista-Designprinzipien praktisch umsetzbar.

Zum Beispiel dieser Denkansatz:

  • Davon ausgehen, dass die App als Standardbenutzer läuft
  • Vorgänge, die Administratorrechte benötigen, in den Installer oder einen separaten Prozess auslagern
  • Speicherorte für Konfigurationsdateien sauber trennen
  • Hohe DPI und Mehrfachbildschirme allmählich berücksichtigen
  • Davon ausgehen, dass 32-Bit-Apps auf 64-Bit-Windows laufen
  • Die Kompatibilität von Treibern und Peripheriegeräten prüfen

Man kann sagen, dass Windows 7 in der Windows-App-Entwicklung die praktische Brücke vom „Stil der XP-Ära“ zum „Stil der Vista-Ära und danach“ war.

9. Windows 8 / 8.1: Die scharfe Wende zum Touch-Zeitalter

Windows 8 war ein ziemlich mutiges Betriebssystem.

Der Startbildschirm.
Live-Kacheln.
Der Windows Store.
Touch-Bedienung.
Charms.
Cloud-Anbindung.

Es war ein Windows, das nicht nur den PC, sondern stark auch das Tablet im Blick hatte.

Als Richtung war das meiner Meinung nach keineswegs falsch.

Smartphones und Tablets verbreiteten sich rasant, und auch der PC musste das Konzept von Touch und Store-Apps aufnehmen.

Für klassische Desktop-Nutzer kam die Veränderung jedoch abrupt.

Das Startmenü schien verschwunden.
Der ganze Bildschirm wechselte.
Auf geschäftlichen PCs, die auf Maus und Tastatur ausgelegt waren, änderte sich der Bedienkontext zu stark.

Im Ergebnis wurde Windows 8 zu einem Betriebssystem, an dem sich die Meinungen schieden.

Aus Entwicklersicht verstärkte Windows 8 die Realität, dass „auf Windows mehrere App-Modelle nebeneinander existieren“.

Klassische Win32-Desktop-Apps.
.NET-Framework-Apps.
WPF-Apps.
Store-Apps.
WinRT.
Touch-orientierte UI.

Auf demselben Windows standen nun mehrere Stilrichtungen nebeneinander.

Das macht die Sache unübersichtlich.
Gleichzeitig ist genau das typisch für Windows.

Neues aufnehmen.
Aber Altes nicht sofort verwerfen.

Diese Haltung setzt sich auch in Windows 10 und danach fort.

10. Windows 10: Windows als Dienst

Das zentrale Merkmal von Windows 10 ist, dass Windows von einem „Betriebssystem, das man alle paar Jahre neu kauft“ zu einem „kontinuierlich aktualisierten Betriebssystem“ wurde.

Windows as a Service.
Funktionsupdates.
Kumulative Updates.
Ein verstärkter Windows Defender.
Microsoft Edge.
WSL.
Virtualisierungsbezogene Funktionen.
Cloud-Anbindung.

Mit Windows 10 wurde es zur Grundannahme, dass Windows selbst ständig aktualisiert wird.

Das war sowohl für Anwender als auch für Entwickler eine große Veränderung.

Früher, bei Windows XP oder Windows 7, ließ sich eine bestimmte OS-Version lange als Referenz nehmen.
Ab Windows 10 unterscheidet sich aber selbst dasselbe „Windows 10“ je nach Version.

1507, 1511, 1607, 1703, 1709, 1809, 1903, 2004, 21H2, 22H2.

Man muss nicht jeden einzelnen Unterschied im Blick haben, aber Entwickler mussten sich die Grundannahme aneignen, dass „Windows sich ständig weiter aktualisiert“.

Das wirkt sich auch auf das Testkonzept aus.

  • Treten nach einem Windows-Update Probleme auf?
  • Blockiert eine verschärfte Sicherheitsfunktion den Installer?
  • Gibt es Konflikte mit Antivirensoftware?
  • Hängt die App zu stark vom Zustand des .NET Framework oder anderer Laufzeitumgebungen ab?
  • Funktionieren vorhandene Peripheriegeräte und Treiber auch mit dem neuesten Windows?
  • Gibt es Probleme bei der Koexistenz mit WSL oder Virtualisierungsfunktionen?

Windows 10 war ein Betriebssystem, das sich einer sehr Windows-typischen Herausforderung stellte: der Modernisierung bei gleichzeitiger Wahrung der Kompatibilität.

11. Windows 11: Das Zeitalter von Sicherheitsstandards und moderner Hardware

Bei Windows 11 änderte sich auch das Erscheinungsbild.

Eine zentrierte Taskleiste.
Eine abgerundete Benutzeroberfläche.
Ein neues Startmenü.
Snap Layouts.
Ein neuer Microsoft Store.

Aus Entwicklersicht ist jedoch die Veränderung bei Sicherheitsstandards und Hardwarevoraussetzungen noch wichtiger.

Bei Windows 11 wurden die Systemanforderungen angehoben: TPM 2.0, UEFI, Secure Boot, eine DirectX-12-fähige GPU, WDDM-2.0-Treiber und mehr.

Das ist keine bloße Aussortierung, sondern eine Entscheidung, Sicherheitsfunktionen, Zuverlässigkeit, Aktualisierbarkeit und moderne Hardwarefunktionen des Betriebssystems als Grundvoraussetzung zu setzen.

Für Betriebe, die noch alte PCs oder alte Peripheriegeräte einsetzen, ist das natürlich eine leidige Sache. Doch damit Windows auch künftig eine sichere Geschäftsgrundlage bleibt, muss die Messlatte irgendwann angehoben werden.

Für Entwickler markiert Windows 11 eine Zeit wie diese:

  • Sicherheitsfunktionen als gegeben voraussetzen
  • Hohe DPI, mehrere Bildschirme, Touch, Stift und Spracheingabe als gegeben voraussetzen
  • Generationsunterschiede bei GPU und Anzeigetreibern berücksichtigen
  • Hybrid-CPUs wie P-Kerne/E-Kerne berücksichtigen
  • Auswirkungen von Energiespareinstellungen und Hintergrundausführung bedenken
  • Die Beziehung zu Cloud-Konten und Verwaltungsrichtlinien bedenken

Leistung und Stabilität einer Windows-App werden längst nicht mehr allein durch den Code bestimmt.

OS-Version, Update-Zustand, Sicherheitseinstellungen, Energieeinstellungen, CPU-Konfiguration, Treiber, Rechte, Peripheriegeräte.
All das muss zusammen als Ausführungsumgebung betrachtet werden.

12. Die Evolution von Windows aus Entwicklersicht

Grob aus Entwicklersicht geordnet, ergeben die Windows-Generationen dieses Bild.

Ära Repräsentatives Windows Erscheinungsjahr Veränderung als Betriebssystem Auswirkung auf Entwickler
Verbreitung des Heim-PCs Windows 95 / 98 1995 / 1998 Startmenü, Taskleiste, Plug and Play, Internetunterstützung Installer, DLLs, Peripheriegeräte und Netzwerkunterstützung wurden wichtig
Endphase der Consumer-DOS-Linie Windows Me 2000 System Restore, AutoUpdate, digitale Medien Zeigte, dass neue Funktionen ein starkes OS-Fundament brauchen
Geschäftliches Fundament Windows NT / 2000 1993 (NT 3.1) bis 2000 Stabilität, Rechteverwaltung, Dienste, Netzwerkverwaltung Geschäftsanwendungen, residente Prozesse, Ereignisprotokoll und Rechtedesign wurden wichtig
Erfolgreiche Vereinigung Windows XP 2001 Vereinigung von Heim- und Geschäftsbereich, Verbreitung der NT-Linie Eine große Menge an Geschäftsbeständen auf XP-Basis entstand
Sicherheitswende Windows Vista 2006 UAC, WDDM, Treibermodell, 64-Bit Designs auf Basis von Administratorrechten funktionierten nicht mehr so einfach
Praxistauglichkeit Windows 7 2009 Verbesserung von Vista, Stabilität, Verbreitung im Geschäftsumfeld Die Vista-Konventionen setzten sich in der Praxis durch
Touch und Store Windows 8 / 8.1 2012 / 2013 Startbildschirm, Store-Apps, Cloud-Anbindung Die Koexistenz von Win32 und neuen App-Modellen wurde zur Herausforderung
Kontinuierliche Updates Windows 10 2015 Windows as a Service, verstärkter Defender, WSL Tests mussten von laufenden OS-Updates ausgehen
Moderne Hardware Windows 11 2021 TPM, Secure Boot, überarbeitete UI, moderne CPUs/GPUs Design musste Sicherheit, Energie, CPU und Treiber mit einbeziehen

Diese Tabelle zeigt: Windows ist nicht einfach nur „neuer“ geworden. Es hat alte Kompatibilität mitgetragen und sich zugleich an neue Sicherheit und neue Hardware angepasst.

Deshalb reicht es in der Windows-App-Entwicklung nicht, nur die neuesten APIs im Blick zu haben.

Vielleicht gibt es noch alte COM-Komponenten.
Vielleicht gibt es noch Geschäftsabläufe auf Basis von ActiveX.
Vielleicht wird eine 32-Bit-DLL benötigt.
Vielleicht sind Druckertreiber oder USB-Geräte veraltet.
Vielleicht muss die App ohne Administratorrechte laufen.
Vielleicht ändert sich das Verhalten nach einem Windows-Update.

Das ist Windows.

Es ist mühsam.

Aber genau diese Mühsamkeit ist auch der Beweis dafür, dass Windows lange den realen Geschäftsbetrieb getragen hat.

13. Wo Geschichtskenntnis in der Windows-App-Entwicklung nützt

Wer die Geschichte von Windows kennt, sieht die Praxis mit anderen Augen.

Zum Beispiel, wenn eine App nicht startet.

Man kann nicht einfach sagen: „Das ist ein Bug.“

Es könnte ein 32-Bit-/64-Bit-Problem sein.
Das benötigte .NET Framework könnte fehlen.
Die VC++-Laufzeitumgebung könnte fehlen.
Die COM-Registrierung könnte defekt sein.
Ein Schreibvorgang könnte an UAC scheitern.
Die App könnte von Antivirensoftware blockiert werden.
Ein alter Druckertreiber könnte eine Rolle spielen.
Die Darstellung könnte bei hoher DPI zerbrechen.
Es könnte ein Verhaltensunterschied nach einem Windows-Update sein.
Die Leistung könnte durch Energiespareinstellungen gedrosselt sein.

In der Windows-App-Entwicklung müssen Sie nicht nur die App isoliert betrachten, sondern die gesamte Umgebung.

Das ist mühsam. Aber genau deshalb lohnt es sich, Software zu bauen, die in der Praxis wirklich funktioniert.

14. Eine Checkliste für die Praxis

Bei der Überarbeitung bestehender Windows-Apps oder bei Neuentwicklungen ist es beruhigend, zumindest diese Gesichtspunkte im Blick zu haben. Da sich bloß aufgelistete Punkte nicht überprüfen lassen, ist jeweils angegeben, „wo man nachsehen kann“.

Zu prüfender Gesichtspunkt Wo man das prüft
Ist das Ziel-Betriebssystem Windows 10 oder Windows 11? winver ausführen. Oder unter „Einstellungen“ > „System“ > „Info“ nachsehen
Bei Windows 10: Wie stehen Support, ESU und LTSC? Auf der Microsoft-Lifecycle-Seite das Support-Ende der jeweiligen Edition prüfen
Ist es eine 32-Bit- oder eine 64-Bit-App? Im Task-Manager auf der Registerkarte „Details“ prüfen, ob beim Prozessnamen „32-Bit“ steht. Bei Build-Artefakten die machine-Zeile von dumpbin /headers
Hängt sie von 32-Bit-DLLs oder COM-Komponenten ab? Mit dumpbin /dependents die abhängigen DLLs auflisten. Die Registrierung von 32-Bit-COM landet unter HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Wow6432Node\CLSID
Lassen sich normale Vorgänge ohne Administratorrechte durchführen? Ein Standardbenutzerkonto anlegen und damit den gesamten Ablauf einmal durchspielen
Werden Einstellungen nicht in Program Files geschrieben? Mit Process Monitor die Schreibziele beobachten. Tauchen Dateien in %LOCALAPPDATA%\VirtualStore auf, wird an einen unzulässigen Ort geschrieben
Sind benutzerspezifische Daten in AppData und gemeinsame Daten in ProgramData getrennt? Mit echo %APPDATA% und echo %ProgramData% die tatsächlichen Pfade prüfen und mit den Schreibzielen der App abgleichen
Sind Vorgänge, die eine UAC-Erhöhung benötigen, ausgelagert? Im Manifest der ausführbaren Datei requestedExecutionLevel prüfen. Läuft der erhöhungsbedürftige Vorgang in einem separaten Prozess?
Sind Installer, Update-Vorgang und Deinstallation sicher? Als Standardbenutzer von der Installation bis zur Deinstallation durchgehen. Auch die Deinstallation über „Einstellungen“ > „Apps“ ausprobieren
Sind Abhängigkeiten wie .NET Framework, .NET und VC++-Laufzeitumgebung klar dokumentiert? dotnet --info, die Liste unter „Einstellungen“ > „Apps“, dumpbin /dependents
Bleibt die Darstellung bei hoher DPI, Mehrfachbildschirmen und Remotedesktop intakt? Unter „Einstellungen“ > „System“ > „Bildschirm“ die Skalierung auf 150 % oder 200 % setzen und die App starten. Auch über Remotedesktop öffnen
Gibt es Kompatibilitätsprobleme mit Peripheriegeräten wie Druckern, USB-Geräten, serieller Kommunikation oder Kameras? Mit devmgmt.msc den Geräte-Manager öffnen und Erkennungsstatus sowie Treiberdatum prüfen
Gibt es einen Prozess, um das Verhalten auch nach einem Windows-Update zu prüfen? Mit winver die Build-Nummer notieren und vor/nach dem Update dieselben Schritte durchgehen. Mit Get-HotFix den Verlauf der angewendeten Updates prüfen
Wurde die Kompatibilität mit Windows Defender oder Sicherheitssoftware anderer Hersteller geprüft? Mit Get-MpComputerStatus den Status prüfen. Ereignisanzeige > Anwendungs- und Dienstprotokolle > Microsoft > Windows > Windows Defender > Operational
Wird berücksichtigt, dass Energiespareinstellungen oder unterschiedliche CPU-Konfigurationen die Leistung verändern? Mit powercfg /getactivescheme den Energieplan prüfen. Die CPU-Konfiguration im Task-Manager unter „Leistung“ ansehen
Werden bei Fehlern Logs geschrieben, aus denen sich der Zustand vor Ort rekonstruieren lässt? Erscheinen App-Logs in der Ereignisanzeige? Sind Zielpfad und Aufbewahrungsdauer festgelegt?

Wer einzelne Punkte vertiefen möchte, findet dazu passende Artikel auf dieser Website.

Diese Checkliste ist keine bloße Entwicklungstechnik, sondern die Geschichte selbst, die sich in Windows angesammelt hat.

15. Windows ist nicht alt, sondern geschichtet

Windows wird oft „alt“ genannt. Tatsächlich gibt es alte Teile.

Es gibt die Win32-API.
Es gibt COM.
Es gibt die Registrierung.
Es gibt DLL-Probleme.
Es gibt alte Steuerelemente.
Es gibt Verhaltensweisen, die aus Kompatibilitätsgründen erhalten geblieben sind.

Doch wer das einfach als alt abtut, sieht das Wesen von Windows nicht. Windows ist ein Betriebssystem, das Altes bewahrt und gleichzeitig Neues darauf aufgebaut hat. Es passt eher das Bild einer riesigen Stadt, die ständig um- und angebaut wurde, als das eines aufgeräumten Gartens.

Es gibt neue Gebäude.
Es gibt alte Gassen.
Unter der Erde verlaufen alte Leitungen.
Es gibt praktische Schnellstraßen.
Fabriken, Krankenhäuser, Schulen und Behörden – alles läuft in dieser Stadt.

Entwickler bauen ihre Apps innerhalb dieser Stadt.

Deshalb reicht es nicht, nur die neuesten Straßen zu kennen.
Man muss auch ein wenig wissen, warum die alten Straßen noch da sind.

Der am Ende von Kapitel 12 erwähnte Gedanke, „die Mühsamkeit ist der Beweis dafür, dass man den realen Geschäftsbetrieb getragen hat“, und das Bild dieses Kapitels von der „ständig um- und angebauten Stadt“ sagen im Grunde dasselbe aus unterschiedlichen Blickwinkeln. Dieses Gefühl etwas weiter vertieft habe ich in Die seltsame Liebe eines Entwicklers, oder: Wie ich lernte, mir keine Sorgen mehr zu machen, und Windows lieben lernte beschrieben. Dieser Artikel ist die Zeitleisten-Seite, jener die essayistische Seite.

16. Fazit

Die Geschichte von Windows ist nicht nur eine Geschichte des Erscheinungsbilds. Sie ist die Geschichte davon, wie Stabilität, Sicherheit, Leistung und Hardwareunterstützung bei gleichzeitiger Wahrung der Kompatibilität angehoben wurden.

Windows 95/98 brachte den PC in Haushalte und Büros.
Windows NT/2000 entwickelte Stabilität und Verwaltbarkeit als geschäftliches Betriebssystem.
Windows XP vereinigte diese beiden Linien.
Windows Vista wurde zum großen Wendepunkt für Sicherheit und Treibermodell.
Windows 7 machte diese Wende praxistauglich.
Windows 8 wagte den Schritt in die neue Richtung von Touch und Store.
Windows 10 etablierte ein kontinuierlich aktualisiertes Windows.
Windows 11 treibt Sicherheitsstandards und die Unterstützung moderner Hardware weiter voran.

Windows ist keine sauber aufgeräumte Utopie. Es ist eine riesige, komplexe Plattform, die weiterläuft, während sie gleichzeitig realen Geschäftsbetrieb, alte Bestände, Peripheriegeräte, Sicherheitsanforderungen und neue Hardware trägt.

Gerade deshalb ist es in der Windows-App-Entwicklung wichtig, nicht nur „das heutige Windows“ zu betrachten, sondern die von der Vergangenheit bis heute reichende Designphilosophie und Kompatibilitätsgeschichte zu verstehen.

Alte Bestände nicht leichtfertig verwerfen.
Aber sich zugleich an neue Sicherheit und neue Ausführungsumgebungen anpassen.

Auf dieser Balance beruht das heutige Windows. Und Software zu bauen, die darauf zuverlässig läuft, hat auch heute noch großen Wert.

Quellen

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Warum ist Windows XP für die Geschichte von Windows so wichtig?
Weil sich der Strang der Consumer-Windows-Versionen (95/98/Me) und der Strang des geschäftlichen Windows NT/2000 in XP praktisch vereinigt haben. Dadurch konnten sich auch Heim-PCs auf die Stabilität der NT-Linie verlassen. Gleichzeitig wurde XP sehr lange genutzt, weshalb Unternehmenssysteme, ActiveX, COM-Komponenten und alte Peripheriegeräte in großer Zahl Annahmen aus der XP-Zeit übernommen haben – XP wurde so auch zu einem der Ausgangspunkte des bis heute fortbestehenden Alt-Bestands.
War Windows Vista ein Fehlschlag?
Als Benutzererfahrung hatte der schlechte Ruf von damals – „langsam“, „zu viele Warnungen“, „Treiber passen nicht“ – durchaus Gründe. Aus Entwicklersicht ist Vista aber ein wichtiger Wendepunkt. Mit UAC, WDDM, einem neuen Treibermodell, der Verbreitung von 64-Bit-Umgebungen und Schreibbeschränkungen für Program Files funktionierten Apps, die auf Administratorrechten aufbauten, nicht mehr so einfach. Man kann sagen, dass dies die notwendige Stufe war, damit Windows zu einem modernen Sicherheitsmodell voranschreiten konnte.
Was hat sich für Entwickler mit Windows 10 geändert?
Die größte Veränderung ist, dass Windows von einem „Betriebssystem, das man alle paar Jahre neu kauft“ zu einem „kontinuierlich aktualisierten Betriebssystem“ (Windows as a Service) wurde. Da dasselbe Windows 10 Versionen von 1507 bis 22H2 umfasst, funktionierte die Idee, eine bestimmte OS-Version langfristig als Referenz zu nehmen, nicht mehr. Es wurden Tests nötig, die davon ausgehen, dass sich das Betriebssystem laufend ändert – etwa ob nach einem Windows-Update Probleme auftreten oder ob verschärfte Sicherheitsfunktionen den Installer blockieren.
Warum wurden die Systemanforderungen für Windows 11 angehoben?
Windows 11 setzt TPM 2.0, UEFI, Secure Boot, eine DirectX-12-fähige GPU und WDDM-2.0-Treiber voraus. Das ist keine bloße Aussortierung alter PCs, sondern eine Entscheidung, die Sicherheitsfunktionen, Zuverlässigkeit, Aktualisierbarkeit und moderne Hardwarefunktionen des Betriebssystems als Grundvoraussetzung zu setzen. Damit Windows auch künftig eine sichere Geschäftsgrundlage bleibt, musste die Messlatte irgendwann angehoben werden.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.

Zurück zum Blog