Perché Microsoft è accusata di non avere più una vera strategia per l'interfaccia di Windows

Chi lavora con Windows da più di 20 anni riconosce una sensazione precisa: ogni nuova versione introduce elementi grafici che non dialogano davvero con quelli precedenti. Non si tratta solo di gusto estetico: il problema riguarda coerenza, modelli di interazione e, in ultima analisi, produttività. L’idea dello sviluppo di un’interfaccia uniforme per Windows aveva radici solide negli anni ’80 e ’90, quando Microsoft costruiva il suo sistema operativo attorno a principi rigorosi, documentati e insegnati agli sviluppatori. Ne parliamo nell’articolo sui migliori sistemi Windows di tutti i tempi. Poi qualcosa si è incrinato.

Per capire il punto, conviene tornare a una figura chiave: Charles Petzold. I suoi testi su Windows 3.x e Win32 hanno definito per anni il modo corretto di progettare applicazioni con interfaccia grafica utilizzando le API Win32 (insieme di funzioni di basso livello del sistema operativo Windows), il ciclo dei messaggi (message loop, cioè il meccanismo che intercetta e gestisce eventi come clic del mouse e input da tastiera) e i controlli standard (elementi predefiniti dell’interfaccia come pulsanti, finestre di testo e menu).

In quel periodo Microsoft aveva una direzione chiara: un set di primitive UI coerenti, un modello di eventi stabile e linee guida che riducevano la frammentazione. Windows 3.1 e poi Windows 95 non erano solo prodotti; erano una piattaforma con regole precise, replicate in modo consistente su tutte le applicazioni.

Dall’unità di Win32 alla frammentazione moderna

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 era un’altra cosa, ma almeno le regole erano certe.

Con l’introduzione del .NET Framework nei primi anni 2000, Microsoft ha iniziato a spostare il focus verso modelli più astratti. Windows Forms manteneva una certa continuità con Win32, ma già con WPF (Windows Presentation Foundation, introdotto con .NET 3.0 nel 2006) si intravedeva un cambio netto: l’interfaccia non veniva più disegnata con elementi grafici “pixel per pixel“, ma tramite rendering vettoriale, cioè basato su forme scalabili che mantengono qualità a qualsiasi risoluzione; veniva utilizzato XAML, un linguaggio dichiarativo in formato XML per definire l’aspetto grafico; si introduceva il data binding, un meccanismo che collega automaticamente i dati all’interfaccia utente. Tecnologie molto avanzate, ma concettualmente diverse e non compatibili con i modelli precedenti.

Il punto è che ogni nuovo strato non sostituiva davvero il precedente: si accumulava sopra. Win32, WinForms, WPF, UWP, WinUI: cinque modelli UI diversi, ciascuno con API, cicli di vita e vincoli differenti.

In pratica, uno sviluppatore che lavora su Windows oggi deve scegliere una tecnologia senza avere la garanzia che resti centrale nel medio periodo.

Il problema non è la tecnologia, ma la direzione

Va detto chiaramente: molte di queste tecnologie sono valide. WPF ha introdotto un sistema di layout e styling avanzato; UWP ha portato un modello sandboxed e un meccanismo di distribuzione controllata incentrato sul Microsoft Store; WinUI 3 cerca di separare il framework UI dal sistema operativo. Il problema non è la qualità tecnica, ma la mancanza di continuità.

Nel tempo, Microsoft ha promosso e poi ridimensionato ogni approccio. Silverlight ne è un esempio evidente: 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 è venuto prima.

Il risultato pratico è visibile in Windows 10 e Windows 11: pannelli di controllo duplicati, finestre di dialogo legacy accanto a interfacce moderne, impostazioni distribuite tra app diverse. Scavando sotto la superficie, non esiste un modello dominante.

Windows 11: un caso emblematico

Windows 11 introduce il cosiddetto Fluent Design, con componenti aggiornati e una maggiore attenzione alla consistenza visiva.

Basta, tuttavia, accedere ad alcune impostazioni più avanzate per imbattersi ancora in componenti costruiti con il tradizionale modello Win32 o con le vecchie librerie COM (Component Object Model, un sistema per far comunicare tra loro diversi componenti software).

Anche Windows 11, infatti, continua a rendere disponibili interfacce di programmazione datate come USER32 (gestione delle finestre e dell’interfaccia) e GDI (disegno grafico di base), affiancandole a tecnologie più moderne come DirectComposition (per il rendering grafico accelerato) e XAML Islands (che permette di integrare interfacce più recenti all’interno di applicazioni tradizionali).

Il sistema operativo evidenzia una stratificazione di tecnologie accumulatesi nel tempo: ogni livello risolve problemi specifici, ma non esiste vera convergenza. Certo, la cosiddetta retrocompatibilità è assicurata ma la progettazione di nuove applicazioni diventa più complessa.

Pavan Davuluri, a valle delle critiche di sviluppatori “in vista”, ha promesso interventi radicali su Windows 11. Si sa, se i dev iniziano a mugugnare, Microsoft deve attivarsi prima possibile.

Conseguenze sulle attività di sviluppo e sul design delle applicazioni

Chi sviluppa su Windows oggi si trova davanti a una scelta difficile: usare Win32 per massima compatibilità, WPF per applicazioni enterprise oppure WinUI per allinearsi alla direzione più recente. Nessuna opzione, però, è davvero definitiva.

In pratica, manca una “fonte di verità” per la UI di Windows: le linee guida in termini di design esistono, ma non offrono una stella polare da seguire a livello di piattaforma. Il risultato è un’ampia variabilità tra applicazioni: anche software sviluppati da Microsoft mostrano comportamenti diversi per svolgere operazioni simili.

La frammentazione che tutti abbiamo registrato ha anche implicazioni tecniche: gestione dello scaling DPI, supporto multi-monitor, accessibilità tramite UI Automation. Ogni framework affronta questi aspetti in modo leggermente diverso, aumentando la complessità complessiva.

Il vero motivo tecnico della scomparsa delle UI “creative” in Windows

Per i più tecnici osserviamo, ad esempio, che Win32 permetteva di creare finestre non rettangolari tramite l’uso delle regioni (HRGN), consentiva di ricorrere a SetWindowRgn per definire la forma reale della finestra (ve la ricordate la forma irregolare della finestra dei vecchi Windows Media Player?), era aperto al rendering avanzato con finestre layered (WS_EX_LAYERED, UpdateLayeredWindow).

Il sistema non imponeva insomma vincoli rigidi sulla forma della UI, a differenza dei framework moderni che standardizzano fortemente layout e componenti.

I framework moderni “nascondono” il sistema operativo: lo sviluppatore non controlla più direttamente la finestra sulla quale sta lavorando, ma opera un livello più in alto. Con il tempo si è quindi verificata una perdita di accesso diretto al modello sottostante. L’aumento dell’astrazione ha portato a meno controllo nelle mani dei dev e una certa “uniformità forzata”.

Il fatto è che la scelta nasce anche da vincoli pratici legati alla complessità crescente delle applicazioni. Un esempio concreto riguarda memoria e performance: un’applicazione scritta in puro Win32, con rendering gestito direttamente tramite GDI o GDI+, può mantenere un footprint estremamente ridotto, anche nell’ordine di pochi megabyte. Al contrario, molte applicazioni moderne costruite su stack più complessi – basti pensare a soluzioni basate su runtime multipli o layer grafici avanzati – arrivano facilmente a decine di megabyte già all’avvio (i.e. app Electron-like).

L’astrazione introduce overhead: librerie più pesanti, gestione indiretta del rendering, maggiore consumo di risorse. I vantaggi risiedono nella maggiore portabilità e nella riduzione del rischio di implementazioni incoerenti. Dall’altro lato vi è meno “controllo fine”, più dipendenza dal framework, e un costo operativo che, su larga scala, non è affatto trascurabile.

Un confronto implicito con il passato

Negli anni ’90 Microsoft puntava a dominare il desktop con un approccio uniforme. La documentazione ufficiale e i libri tecnici erano allineati; gli esempi di codice riflettevano esattamente il comportamento del sistema.

Oggi l’azienda di Redmond sembra aver spostato il baricentro su cloud e servizi, come dimostrano le strategie degli ultimi anni e la recente corsa all’AI. L’interfaccia desktop non è più il fulcro della piattaforma: e questo potrebbe spiegare, almeno in parte, perché l’interfaccia grafica pare non ricevere la stessa attenzione di un tempo.

Il rovescio della medaglia è che Windows resta centrale in molti ambienti professionali: una strategia UI poco coerente incide sulla qualità del software e sull’esperienza quotidiana di centinaia di milioni di utenti.

Quello che serviva già ieri, e ancora più adesso, è una direzione chiara: WinUI potrebbe essere un tentativo credibile, a patto che venga sostenuto nel lungo periodo e non affiancato da nuove alternative tra qualche anno.