DI RECENTE ACCOMAZZI...
CERCA
» Ricerca avanzata
MAILING LIST

Se vuoi iscriverti alla mailing list di Luca Accomazzi inserisci qui la tua mail:

Vuoi ricevere i messaggi immediatamente (50 invii / giorno) o in differita e in gruppo
(due invii / giorno)?

» Vuoi saperne di più?

Windows 8 sotto al cofano

Windows 8 è nei negozi: la notizia l'ha riportata pure la Gazzetta dello Sport. Di recensioni più o meno approfondite sono piene le testate di settore, di carta e sul web. Un articolo in più di questo o quel tipo sarebbe puro spreco di carta e inchiostro. Scopo di questo pezzo è invece esaminare la tecnologia su cui si basa Windows dal punto di vista di un utilizzatore Mac, dunque paragonando le soluzioni che Microsoft ha messo in campo alle equivalenti risposte che Apple ha trovato per le medesime sfide.

Le radici della questione

Impossibile parlare dei moderni sistemi operativi senza citare le loro origini. Negli anni, infatti, si accumulano nuove tecnologie che rispondono a nuove esigenze, ma il motivo per cui ogni sistema operativo esiste è uno solo: e cioè permettere alle app di utilizzare le risorse della macchina fisica in modo flessibile, regolamentato, sicuro, compatibile con il futuro. Un sistema operativo offre alcune API (application programming interfaces) cioè metodi documentati e precisi con cui ottenere risultati desiderabili, come creare una cartella, copiare un file, far apparire una finestra  video.

A metà degli anni '80, la Microsoft era già dominante sul mercato e il suo sistema operativo si chiamava MS-DOS, il MicroSoft Disk Operating System. Come il nome dichiaratamente riconosce, era un sistema primitivo che offriva alle app solo metodi per lavorare con i dischi (e, in subordine, le altre unità periferiche connesse al calcolatore, che il DOS trattava in modo analogo; questo è il motivo per cui ancora oggi in Windows 8 all'utilizzatore non è permesso di creare una cartella chiama NUL o PRN, nomi riservati alle periferiche). Nel medesimo periodo Mac già disponeva di un sistema operativo in grado di mostrare a video finestre, mouse, icone e menu.

Windows nelle versioni da 1.0 a 3.1 non fu un vero sistema operativo, ma semplicemente una raccolta di API suppletive al DOS, che permettevano alle più moderne app dell'epoca (come Microsoft Excel, nato su Mac e per Mac) di manipolare finestre cestino e via discorrendo; e di girare anche sui PC. La versione 1 di Windows neppure permetteva alle finestre di sovrapporsi: si potevano solo affiancare. Quelle API vennero sistematizzate e definite a metà degli anni Novanta in un complesso chiamato allora come oggi Win32 (il numero fa riferimento ai trentadue bit dei processori dell'epoca).

Conservatori e progressisti

È certamente una semplificazione, ma una semplificazione utile: molte delle mosse inscenate da Microsoft e Apple si possono spiegare e interpretare alla luce di una differenza filosofica. Nel DNA di Microsoft si trova la produzione di software (lo hardware esiste in quanto indispensabile a far girare il software); il contrario vale per Apple. La casa fondata da Steve Jobs a Cupertino dunque non si fa troppi problemi nell'introdurre nuovi e più potenti calcolatori il cui supporto costringe gli sviluppatori a rimettere mano ai loro programmi, mentre per la casa fondata da Bill Gates a Redmond si concentra sul software è anatema l'idea di investire tempo e fatica su un programma già funzionante solo per "modernizzarlo". Per esempio, Apple ha cambiato completamente il processore supportato da Mac OS (da Motorola 68000 a IBM PowerPC a Intel x86), mentre Microsoft non ha mai fatto nulla del genere in Windows. Ma oltre a queste modernizzazioni epocali, di cui si rendono facilmente conto anche gli utenti meno tecnologicamente consapevoli, ne esistono altre che avvengono quasi nascostamente. 

Di tanto in tanto, il progresso impone di rimuovere una delle API esistenti. Per esempio, per decenni il sistema operativo di Mac e PC ha offerto alle app un sistema per scoprire se e dove un utente abbia fatto clic con il mouse. Oggi, trackpad e mouse multitouch consentono all'utente di "toccare" più punti contemporaneamente, e quindi la vecchia API è insufficiente. In questi casi, gli ingegneri che aggiornano il sistema operativo di solito cominciano con la creazione della nuova API, più moderna e destinata a rimpiazzare quella preesistente. In un secondo momento, la API più vecchia viene deprecata, cioè gli sviluppatori vengono informati del fatto che presto smetterà di funzionare. Infine, la API viene del tutto soppressa -- e a quel punto eventuali vecchie app che non siano state aggiornate per evitarne l'uso smettono di funzionare. Su un Mac, se aprire il programma Console (che si trova nella cartella Utility) e fate clic su systemlog nella colonna di sinistra troverete -- mischiato al resto -- una serie di avvertimenti che OS X manda alle app che avete aperto, incluse notifiche del tipo "stai usando la API taldeitali che è deprecata, passa invece alla nuova API talaltra". Queste notifiche sono del tutto inutili per noi utenti finali ma di vitale importanza per gli autori delle app.


L'utility Console mette in evidenza un'app che probabilmente smetterà di funzionare in OS X 10.9, a causa dell'uso deprecato della API NSImage.

Obsolescenza programmata

Spesso accade che le API vengano deprecate e sostituite non individualmente ma per gruppi. Per esempio, il primo Mac era caratterizzato da una gestione relativamente primitiva del suono e il processore rallentava significativamente quando una delle API responsabili per emettere una nota veniva chiamata; quindi il Sound Manager (la collezione di API relativa al suono) venne interamente deprecato e riscritto in Mac OS 2.0. Quando un sistema operativo viene rinnovato in modo cospicuo -- come avvenne in Windows con la nascita di Windows NT, o al Macintosh passando dalla versione 6 alla 7 del suo sistema operativo, possono contarsi a centinaia le API rinnovate in un sol botto.

Quando Apple pianificò inizialmente il passaggio da Mac OS 9 a Mac OS X 10.0, era stato inizialmente immaginato un rinnovo totale di tutte le API esistenti, ma i più grandi sviluppatori -- Microsoft e Adobe in testa -- costrinsero Apple a desistere perché il prezzo per un rinnovo totale era per loro così alto che scelsero di astenersi, realizzando di fatto un boicottaggio del lavoro di Cupertino. Per capire meglio come andò e per un doveroso confronto con quanto accede in Windows, dobbiamo approfondire.

Abietto fallimento

Sia Microsoft che Apple hanno nel curriculum un colossale KO, un tentativo di rinnovamento del sistema operativo e delle sue API mancato ed abortito. Nel caso di Apple la cosa avvenne alla fine degli anni Novanta, subito prima del ritorno di Steve Jobs alle redini della casa che aveva fondato. Per modernizzare il sistema operativo, gli ingegneri di Cupertino avevano immaginato una riscrittura radicale, il progetto nome in codice Copland, ma dopo oltre due anni di lavoro i team di sviluppo erano riusciti soltanto a realizzare alcuni componenti del nuovo sistema -- gruppi di API che avevano senso solo al proprio interno ma che non sapevano interoperare con gli altri, come pezzi di puzzle che non combaciano gli uni con gli altri.

Esattamente la stessa cosa accadde in Microsoft con il progetto Longhorn nel 2002. Era già chiaro che Win32 è un sistema concettualmente vecchio e poco adatto a tenere alto lo stendardo di Windows nel nuovo millennio. Gli ingegneri di Microsoft si diedero obiettivi ambiziosi, il cui gioiello della corona era il file system (sistema di gestione di dischi e documenti) WinFS, che doveva somigliare a una base dati più che a un tradizionale sistema di stoccaggio dati basato su cartelle - il che avrebbe permesso a Windows di raggiungere e superare le capacità di ricerca e selezione documenti che Apple ha dato al suo Spotlight. Esattamente come gli ingegneri di Apple pochi anni prima, dopo molta fatica anche il progetto Microsoft si dimostrò un completo fallimento, con vari mandarinati contrapposti che si facevano la guerra, nessun coordinamento centrale degno di questo nome e interi team di sviluppatori che lavoravano come altrettante Penelope a fare e disfare codice sulla base di fondamenta che altri continuavano a riprogettare daccapo. Le API di nuova concezione insomma non riuscivano a venire consolidate.

Le due aziende reagirono in modo differente, ma in ultima analisi simile, alla crisi. Apple rinunciò del tutto a Copland, e acquistò da Steve Jobs la Next e il sistema operativo NextStep; fu su questa base solida e rodata che venne costruito il sistema operativo che noi oggi conosciamo come Mac OS X (non a caso nel sue API hanno nomi che cominciano con NS, sigla di NextStep). Le API del precedente sistema operativo Mac OS 9 vennero modernizzate facendo ritocchi il più possibile minimi. Nacque così un sistema che si può programmare a scelta dello sviluppatore individuale in due modi diversi e filosoficamente opposti: il sistema tipico dei vecchi Mac (chiamato Carbon) e le API ereditate da NextStep e collettivamente chiamate Cocoa. I due sistemi sono del tutto indipendenti, il che ha un evidente effetto negativo: se sul Mac vengono avviate in contemporanea un'app basata su Cocoa e una basata su Carbon il calcolatore deve tenere in memoria tutto il codice di ambo i sistemi, con una certa ridondanza e dunque spreco di risorse.

Microsoft nel 2004 abbandonò uno dopo l'altro gran parte dei moduli che aveva immaginato per Longhorn, a cominciare da WinFS. Anche in questo caso le vecchie API, Win32, sopravvissero. Vennero loro affiancate nuove API più moderne, .NET (pronunciato "dot net"), le quali però vennero costruite sopra a Win32, ovvero in gran parte funzionano chiamando il sistema preesistente. Fu così che alla fine nacque Windows Vista.

Tempi moderni

La nascita dei dispositivi ultraportatili (smartphone e tablet) ha comportato nuove sfide per i progettisti delle aziende. Apple, giunta per prima sul mercato, ha effettuato una serie di scelte che oggi consideriamo imprescindibili ma che nel 2007 furono molto discusse. Le app vennero separate le une dalle altre, rendendole impervie ai (potenziali) attacchi di software maligno scritto da criminali. Dal punto di vista della programmazione e delle API, iPhone e il suo sistema operativo iOS nacquero per sottrazione da Mac OS X: venne rimosso Carbon e mantenuto Cocoa, "dimagrendo" il sistema. Questa traiettoria venne indicata anche agli sviluppatori Mac: solo Cocoa venne aggiornato per funzionare al massimo con i nuovi processori a 64 bit, mentre Carbon venne lasciato a 32 bit. Con OS X 10.8 "Mountain Lion" si può dire che tutto Carbon è deprecato.

Microsoft si trovò in un'impasse, perché era impossibile incapsulare le API di .NET gettando a mare il sottostante strato Win32. Inoltre, i più preziosi programmi targati Microsoft -- come Office -- sono scritti su fondamenta Win32, non .NET, ed è impossibile pensare a una nuova versione di Windows incompatibile con i programmi esistenti in generale e con Office in particolare. A Redmond si cominciò a discutere di un possibile sistema ulteriore: WinRT (contrazione di Windows runtime), che nel tempo avrebbe potuto rimpiazzare entrambi i precedessori. WinRT comunque, per quanto detto, doveva somigliare il più possibile a Win32. Così, mentre Apple ha gradualmente rimpiazzato il "vecchio", classico sistema di API, Microsoft ha riprogettato un sistema basato sulle radici più antiche, da MS-DOS in giù.

Oggi chi scrive applicazioni per Windows 8 ha la scelta tra tre diversi gruppi di API. Se sceglie Win32 può scrivere software che gira anche sul vecchissimo Windows XP. Se opta per .NET avrà modo di lavorare da Windows Vista in poi. E se invece sposa WinRT produce una app che usa la nuova interfaccia multitouch "a quadrotti" che venne inizialmente propagandata sotto al nome di Metro ma che oggi, per motivi di copyright, viene chiamata semplicemente "interfaccia Windows 8".


L'interfaccia utente Windows 8, (già "Metro") caratteristiche delle app scritte con WinRT. Immagine: cortesia Microsoft.

Il prezzo del compromesso

Microsoft oggi produce tablet concorrenti di iPad, chiamati Microsoft Surface. Ne esistono di due tipi: i più costosi usano processori Intel dal consumo (e prestazioni) relativamente ridotte (rispetto ai normali PC) e fanno girare il sistema operativo Windows 8 completo. I più economici offrono un processore ARM parente di quello scelto da Apple per iPhone e iPad, più parco di consumi ma incompatibile con tutto il vecchio software Windows. Solo le app scritte di recente su base WinRT  vengono realizzate anche nel codice variante richiesto per questi processori, e sono quindi compatibili con questi ultimi  tablet.

A bocce ferme e osservando questo risultato, possiamo dire che gli sforzi di modernizzazione di Microsoft si sono scontrati contro due ostacoli poderosi. La necessità di presentare tablet capaci anche sul piano dei videogiochi ha fatto sì che Microsoft riproponesse su tutti i suoi tablet il sistema Direct3D 11, tipico dei Windows precedenti e fondato sui più vecchi metodi di programmazione. Inoltre, la scelta di offrire una versione completa di Office sui nuovi ultraportatili ha fatto sì che alla fin fine WinRT sia stato realizzato esattamente come .NET dieci anni fa: come uno strato costruito e fondato sopra a Win32, che continua ad esistere e tirare le file da tutto, sotto sotto.

In definitiva, mentre i tablet di Microsoft sono apparecchi del tutto ammirevoli sotto il punto di vista dell'hardware, e dimostrano alcune caratteristiche di tutto rispetto persino se paragonate all'iPad 4, il loro sistema operativo presenta una serie di compromessi che chi scrive trova francamente discutibili. In mancanza della volontà di saldare una volta per tutte i conti con il passato, Microsoft ha affardellato una volta di più la sua più recente offerta con i bagagli di tecnologie obsolete e le cui limitazioni emergono da limiti di sistemi vecchi di decenni. Un esempio su tutti: Win32 non consente la creazione di percorsi nel file system (cioè disco/cartella/cartella/documento.estensione) più lunghi di 260 caratteri, perché il DOS dei primi anni Ottanta non ne era capace, e di conseguenza anche WinRT limita le sue app e i suoi utenti nel medesimo modo. Dopo .NET, anche WinRT si dimostra una occasione sprecata.

Questo articolo fa parte di uno dei miei percorsi. Se vuoi saperne di più su questo argomento, visita il resto del percorso cliccando qui.