Chi usa Windows da oltre vent’anni conosce bene quella sensazione: ogni nuova versione del sistema operativo porta con sé elementi grafici che non si parlano davvero con quelli delle versioni precedenti. E non è una questione di gusto estetico. Il problema tocca la coerenza, i modelli di interazione e, alla fine dei conti, la produttività di chi ci lavora ogni giorno. L’interfaccia di Windows aveva basi solidissime tra gli anni ’80 e ’90, quando Microsoft costruiva il proprio sistema operativo attorno a principi rigorosi, ben documentati e insegnati agli sviluppatori. Poi, a un certo punto, qualcosa si è rotto.
Per inquadrare la faccenda vale la pena ricordare una figura fondamentale: Charles Petzold. I suoi testi dedicati a Windows 3.x e Win32 hanno definito per anni il modo corretto di progettare applicazioni con interfaccia grafica, sfruttando le API Win32, il ciclo dei messaggi e i controlli standard. In quel periodo Microsoft aveva una direzione limpida: un set coerente di elementi per la UI, un modello di eventi stabile e linee guida che limitavano la frammentazione. Windows 3.1 e poi Windows 95 non erano semplicemente prodotti, ma una piattaforma con regole precise, replicate in modo uniforme su tutte le applicazioni.
Il modello Win32 imponeva una disciplina quasi rigida. Ogni finestra derivava da una classe registrata, ogni input passava da un message pump, ogni controllo rispettava convenzioni condivise. Il risultato era prevedibile: un’applicazione scritta bene si comportava come tutte le altre. La perfezione restava un’altra cosa, ma almeno le regole erano certe. Con l’arrivo del .NET Framework nei primi anni 2000, Microsoft ha iniziato a spostare l’attenzione verso modelli più astratti. Windows Forms manteneva una certa continuità con Win32, ma già con WPF (Windows Presentation Foundation, arrivato con .NET 3.0 nel 2006) il cambio era netto: rendering vettoriale, linguaggio dichiarativo XAML e data binding. Tecnologie molto avanzate, ma concettualmente diverse e non compatibili con i modelli precedenti. Ogni nuovo strato, però, non ha mai davvero sostituito quello sotto: si è semplicemente accumulato sopra. Win32, WinForms, WPF, UWP, WinUI: cinque modelli UI diversi, ciascuno con API, cicli di vita e vincoli differenti.
La frammentazione visibile in Windows 11
Molte di queste tecnologie, va detto, sono valide prese singolarmente. WPF ha introdotto un sistema di layout avanzato, UWP ha portato un modello sandboxed incentrato sul Microsoft Store, WinUI 3 cerca di separare il framework UI dal sistema operativo. Il nodo non è la qualità tecnica, ma la mancanza di continuità. Nel tempo Microsoft ha promosso e poi ridimensionato ogni approccio. Silverlight ne è l’esempio più lampante: spinto come piattaforma cross platform, poi abbandonato. UWP doveva unificare desktop e mobile, ma la strategia mobile è crollata. WinUI oggi prova a rimettere ordine, ma convive con tutto ciò che lo ha preceduto.
Il risultato pratico si vede chiaramente in Windows 11: pannelli di controllo duplicati, finestre di dialogo legacy accanto a interfacce moderne, impostazioni distribuite tra app diverse. Sotto la superficie non esiste un modello dominante. Windows 11 introduce il cosiddetto Fluent Design, con componenti aggiornati e maggiore attenzione alla consistenza visiva. Basta però accedere ad alcune impostazioni più avanzate per ritrovarsi davanti a componenti costruiti con il tradizionale modello Win32 o con le vecchie librerie COM. Il sistema operativo continua a rendere disponibili interfacce di programmazione datate come USER32 e GDI, affiancandole a tecnologie più recenti come DirectComposition e XAML Islands. Ogni livello risolve problemi specifici, ma non esiste vera convergenza. Pavan Davuluri, dopo le critiche di sviluppatori di peso, ha promesso interventi radicali su Windows 11.
Cosa comporta per gli sviluppatori e per il futuro della piattaforma
Chi sviluppa su Windows oggi si trova davanti a una scelta complicata: usare Win32 per massima compatibilità, WPF per applicazioni enterprise oppure WinUI per allinearsi alla direzione più recente. Nessuna opzione è davvero definitiva. Manca, in pratica, una “fonte di verità” per la UI di Windows: le linee guida di design esistono, ma non offrono una stella polare a livello di piattaforma. Anche software sviluppati dalla stessa Microsoft mostrano comportamenti diversi per operazioni simili. La frammentazione ha poi implicazioni tecniche concrete: gestione dello scaling DPI, supporto multi monitor, accessibilità tramite UI Automation. Ogni framework affronta questi aspetti in modo leggermente diverso, aumentando la complessità complessiva.