[ malcom ]

“L’ultima di Windows è un (grosso) buco (nero) nell’acqua”: questo è il sentimento comune che gira da parecchio in rete, per lo più alimentato da tutta una serie di recensioni negative, campagne marketing, voltafaccia degli amici di sempre (vedi Dell e gran parte del settore enterprise) ma soprattuto da tutte quelle promesse disilluse e occasioni mancate che ne stanno decretando una (inevitabile) morte prematura.

Tutto questo, come avrete certamente capito, è Windows Vista, che ad oltre un anno dalla sua (sofferta) uscita ufficiale sembra dato per morto anche dalla sua stessa mamma.

In questi giorni Microsoft, nella importante (e occhialuta) figura di William Gates III (l’ormai non-pensionato), ha presenziato ad una nota trasmissione americana (D: All Things Digital) annunciando le (la?) novità di Windows 7 che verrà rilasciato (presumibilmente) nel 2009.

Il prossimo Windows supporterà il touch. Nel 2009 Windows permetterà all’utente di utilizzare tutte e dieci le dita per interagire sullo schermo… a patto che il sistema riesca a non collassare (a solito) su se stesso come è (in alcuni casi) la tradizione.

Ma questo articolo non vuole assolutamente porre l’accento su quello che potrebbe essere il Windows che verrà, quanto più analizzare cosa ha portato Microsoft ha ritrovarsi in casa un gallina stitica (gli analisti come Gartner prevedono, in maniera forse fin troppo drammatica, un collasso dell’intero sistema e della Microsoft).

Lo faremo in un (piuttosto lungo per un post di un blog) viaggio in cui le scelte e i destini delle due aziende più rilevanti del settore informatico di questi anni (Apple e Microsoft) sono stati messi a confronto e giudicati. Errori e strategie vincenti che spesso sono trascurate perchè poco visibili.

SIAMO SICURI CHE IL PROBLEMA E’ IL PRESENTE?

Come abbiamo detto, in questi ultimi giorni parecchi si sono cimentati nella critica delle scelte Microsoft nella progettazione e lancio del suo nuovo sistema operativo. L’errore che parecchi hanno fatto è stato però quello di guardare alle scelte presenti come fonte di tutti i mali: ma i problemi di Windows non vanno cercati ostinatamente nel suo futuro (perchè quella è solo una parte e probabilmente neanche così fondamentale), ma nella sua storia.

La necessità di coniugare 25 anni di decisioni cercando nel contempo di innovare (sono esagerato?) cercando una nuova rotta verso il futuro: è un pò come cercare di evitare un muro schiacciando il pedale dell’accelleratore (il che, come avrete intuito, non è proprio il miglior modo di salvarsi).

Queste decisioni sono state ammassate le une sulle altre, spesso si è trattato di idee che negli anni hanno contrastato con le precedenti (per motivi tenici o di marketing), o si è resa la necessità di creare delle vere e proprie pezze per mantenere una (necessaria) compatibilità con tutta una serie di vecchi applicativi.

Ad oggi, dando uno sguardo alla (maggior parte delle) applicazioni Windows ci si ritrova davanti ad un panorama di desolante confusione, dove al meglio si sono implementati set di controlli visuali personalizzati (ad esempio pulsanti stile Vista in XP e viceversa) ma al peggio ci si ritrova difronte a delle vere e proprie incosistenze del codice.

E se ogni male ha una radice quella di Windows è proprio la sua stessa azienda che è diventata la principale promotrice di software di sicuramente non eccelsa fattura (personalmente - lasciatemelo dire - sono ancora “scandalizzato” dallo scambio di posizioni tra barra dei menu e toolbar di pulsanti in Explorer).

Ma quando questi fatti erano ancora lungi dall’essere appena ipotizzati c’era un’altra azienda in grossi guai. Apple nella metà degli anni 90 si ritrovava con un sistema operativo (tecnologicamente e non solo) vecchio che non andava da nessuna parte e che aveva bisogno di un profondo e radicale cambiamento. Windows nello stesso periodo era parecchi passi avanti (multi-tasking preventivo, memoria protetta, la non necessità di allocare memoria per ogni applicazione e in generale una buona stabilità).

Il supporto agli sviluppatori, al contrario di Apple, era buono (a partire dalle copie in pre-release inviate fino alla completa MSDN library, supporto imprescindibile per chiunque volesse entrare nel mondo della programmazione win) e c’erano delle vere e proprie roadmap.

Tutto questo e altro faceva si che lo sviluppo e gli sviluppatori Windows venissero letteralmente coccolati: il sistema in poche parole era in una enorme fase di crescita.

IL TRAGUARDO DI APPLE

Anno 2001: Apple finalmente si libera dal groviglio in cui era stata invischiata da ormai più di cinque anni e acquista NeXT (il che vuol dire Jobs di nuovo in casa ma anche e soprattutto un sistema operativo nuovo di zecca). L’idea di creare da zero un nuovo sistema operativo viene definitivamente accantonata e si sceglie di utilizzare NeXTstep come base per il nuovo OS.

Mac OS X entra così dalla finestra e per diverso tempo è costretto a convivere come il fratello scomodo (e ancora bebè) del più datato e meno dotato OS 9.

Mentre OS X incomincia a crescere gli sviluppatori iniziano a guardare con interesse alla nuova via: Quartz, Postiscript a video, core BSD Unix, Cocoa, Objective-C e tutta una serie di strumenti completi e moderni fanno (e faranno) di OS X una piattaforma di nuovo competitiva.

Nel frattempo viene presa una decisione di fondamentale importanza per gli anni a venire: la compatibilità con gli applicativi di OS 9 viene relegata ad una sorta di macchina virtuale, una sorta di sondbox in grado di isolare tutte le scomodità della vecchia guardia.

In compenso si offre (sebbene più che una scelta sia stata una necessità, comunque ben congeniata) ai programmatori di convertire le vecchie applicazioni in native con pochi aggiustamenti del codice (diverse presentazioni fanno i conti in termini di giorni o poche settimane) mentre le nuove avranno la possibilità di avvantaggiarsi utilizzando tutta una serie di strumenti e tecnologie moderne.

Questo tipo di approccio ribalta le carte in tavola e porta Apple in una posizione forte e nuovamente competitiva: il nuovo OS è libero da tutto il vecchio ciarpame, le vecchie applicazioni sono messe in una nicchia, chi vuole aggiornarsi può farlo con pochi passi mentre chi vuole guardare al futuro può farlo grazie a strumenti più semplici e moderni.

XP venne rilasciato più o meno in quegli stessi anni: era la personale risposta di Microsoft, una risposta che sarebbe dovuta durare (nelle intenzioni) per i successivi cinque anni.

Cinque anni che dall’altro lato della barricata sarebbero stati pieni di novità e di release. Mac OS X 10.1, 10.2, 10.3 e infine 10.4.

In questo periodo Apple non ha guardato solo alla superficie del proprio OS (tant’è vero che l’interfaccia, tranne alcuni ritocchi è rimasta per lo più la stessa - e probabilmente questo sarà uno dei punti alla base del prossimo 10.6) ma aggiunto e svecchiati definitivamente molteplici componenti: Core Audio ha offerto un moderno framework a bassa latenza per l’acquisizione e la manipolazione di segnali audio, Core Image ha introdotto tutta una serie di strumenti per la manipolazione anche complessa di immagini e così via.

Tutti questi componenti hanno permesso alla stessa Apple ma anche e soprattutto agli sviluppatori di poter creare software di grande qualità potendo contare su basi solide, professionali e di grande qualità (un nome su tutti che si può fare è Final Cut, ormai uno standard nel proprio settore).

Quello che in definitiva ha fatto Apple è stato creare una infrastruttura completa per supportare attivamente I propri sviluppatori, abbandonando deliberatamente il proprio ecosistema di compatibilità nel giro di pochi anni e rinnovando così tutto quanto.

LA PASSIONE COME PUNTO CHIAVE

Quello che ha fatto Windows nello stesso periodo è stato generare solo una maggiore confusione. 

L’ecosistema di strumenti e oggetti di terze parti per Win è davvero vasto - molto più vasto di quello Mac - ma anche pieno di parecchie schifezze (progettualmente e qualitativamente parlando).

Ci sono poi parecchi sviluppatori ma in pochi si curano davvero di fare scelte oculate; molti di loro creano programmi gestionali in Visual Basic o siti in ASP/.net senza mettere passione nel proprio lavoro. Lo fanno perchè è un modo per essere pagati e tanto basta.

Queste affermazioni potrebbero sembrarvi stupide, ma la passione è una componente importante (non solo nello sviluppo di programmi ma anche e soprattuto in ogni aspetto della nostra vita); non c’è nessun interesse nell’usare nuove tecnologie, nel curare quello che si crea e non c’è nessun interesse nel progredire senza qualcosa che ci spinge a farlo. E probabilmente la miglior cosa che può fare questo (non sono i soldi) è la passione.

Gli sviluppatori Mac, la stragrande maggioranza di loro almeno, spesso non fanno software per grandi aziende e in generale non dimostrano lo stesso disinteresse. Questo significa che sicuramente per il mondo businness la piattaforma non offre tutto quel vasto repertorio di soluzioni che invece ha Microsoft, ma al contrario di questa ci si ritrova difronte a software di grande qualità.

Analizzando i movimenti di Microsoft in questi anni addietro si trova un peccaminoso immobilismo che è sfociato nella creazione di un OS [Vista] che non è poi così male, ma che sicuramente non è in grado di tracciare un solco che rimarrà nel tempo (è invece piuttosto probabile che Vista venga accantonato quanto prima).

Sviluppare software per Windows, secondo parecchi sviluppatori, è diventato ormai una pena e il ricordo dei bei giorni passati è ormai sfumato. Windows ha perso parecchio appeal verso i suoi sviluppatori e questo è in gran parte determinato da come Microsoft ha fatto crescere la sua creatura.

WINDOWS VISTO DA UN PROGRAMMATORE WINDOWS

Quella che segue è l’opinione di Peter Bright intervistato da Ars Technica qualche mese addietro. Peter è un programmatore Windows, o meglio lo è stato per parecchi anni, fino a quando un bel giorno si è trovato difrontre alla necessità di fare un cambiamento.

Ho creduto fosse un elemento importante per completare questa prima parte del racconto e per rafforzare le convinzioni che fin qui ho esposto (personalmente non sono un programmatore Windows e parlare per bocca mia sarebbe stato un crimine).

Nella storia di Microsoft per trovare un cambiamento che almeno in parte (una parte piuttosto piccola, difficile da mettere a confronto) sia simile a quello di Apple con OS X, dobbiamo risalire alla metà degli anni 90 e in particolare alla nascita di Windows NT.

Windows NT fu progettato come un sistema operativo moderno ma con la necessità di mantenere una compatibilità verso I suoi predecessori: fu questa la ragione per la quale le sue API (ovvero tutto il set di componenti e funzioni a supporto del programmatore) furono progettate tenendo a mente prima quelle di Windows a 16 bit, poi più avanti quelle a 32 (Win32).

Questa decisione si trascina a tutt’oggi e quindi Win64 continua a riflettere scelte ormai occorse 20 anni prima.

Lo stesso Peter Bright ha parlato a lungo in questo articolo circa Windows Vista, definendo ad esempio lo stack grafico come un modulo ancora fortemente ancorato al passato, e per questo ovviamente parecchio vecchio.

Tutto questo per far si che il vecchio riesca a coesistere ancora nel nuovo, castrando letterlamente la possibilità di innovare.

Ma quello che rende il tutto più problematico secondo Bright è l’inconsistenza che si trova in tutte le API da Windows 16 a, e soprattuto, Win32.

Le API Win32 raccolgo molte centinaia di funzioni ma la maggior parte sono inconsistenti.

Bright prende ad esempio alcune funzioni che richiedono che il chiamante dia un buffer alla funzione, che verrà usato da questa per salvare alcuni dati (e quindi la dimensione del buffer stesso sarà dinamica). Generalmente la funzione può sapere quanto deve essere grande questo buffer… ma non è così.

E se pensate che dentro Win32 questo problema sia risolto in un modo e sia lo stesso ogni volta (sperabilmente anche il migliore a disposizione), ebbene vi sbagliate di grosso.

Senza entrare troppo nel metodo ci sono almeno 4 soluzioni diverse utilizzate dagli sviluppatori MS.

Ma questo è solo uno dei tanti esempi che rendono la programmazione Win decisamente poco attraente e sicuramente a volte anche problematica.

.NET

Ma Win32 non è certamente l’ultima creatura di Microsoft in ordine di tempo. Durante gli anni di staticità di XP, mentre OS X cresceva e OS 9 entrava ormai a far parte della storia, la società di Redmond iniziò a pensare ad una nuova piattaforma di sviluppo. Il suo nome, come avrete intuito, è .NET e merita sicuramente un discorso a parte.

Il framework .NET esce nel 2002 ed è per Microsoft una rivoluzione: finalmente gli sviluppatori si trovano davanti ad un prodotto organico e aggiornato coi tempi.

Ma soprattuto potrebbe segnare un punto di svolta dalle vecchie API Win16,Win32.

.NET è stato ed è a tutt’oggi molto appoggiato da Microsoft; le campagne pubblicitarie a partire dal 2002 si sono fatte molto insistenti e la stessa Microsoft ha cercato di dare il buon esempio sviluppando parti di XP proprio in .NET.

Ma il problema di .NET non è il suo linguaggio C# (che per quanto sia simile a Java è comunque un ottimo passo avanti) e neanche la sua macchina virtuale (che in quanto a performance non se la cava male), quanto più la libreria stessa: .NET Library.

Un altro grosso problema di .NET è il pubblico si rivolge, un pubblico di programmatori che non sono tutti uguali.

Ma per capire meglio questo devo entrare più nel dettaglio.

Provate a pensare a tutte quelle persone, tecnici di laboratorio, analisti o ricercatori che usano Access, Excel o VB6 per creare le proprie applicazioni. Tutte queste persone non sono veri programmatori, a loro non interessa scrivere del buon codice, curarsi dell’interfaccia ne tanto meno di creare un buon prodotto: il loro obiettivo non è sviluppare nel senso stretto. E in questo ambito I tre tool appena citati sono il massimo.

Poi ci sono tutti quei programmatori che lo fanno per lavoro e quindi nel bene o nel male hanno una certa familiarità con quello che usano. Questa gente non ama certamente le novità e non la vedrete mai fagocitare libri tecnici per aggiornarsi. Loro usano VB6 e probabilmente non vanno oltre perchè non ne hanno bisogno ne tanto meno voglia.

Il loro codice non sarà certamente arte ma funziona e poi il basic è pure facile. Questa gente lavora a programmi gestionali, quelli per PA o per aziende private. A nessuno di loro importa fare dell’ottimo codice, e I loro utenti sono ancora meno interessati a quello che dovranno usare.

Anche se il loro software non è gran che questo è il bacino più grosso di Microsoft: si tratta di applicazioni chiave fatte in VB che girano solo e soltanto su Windows.

Alla fine troviamo invece tutti quelli che sono I programmatori veri. Questo genere di persone sono conscie di quello che usano, si aggiornano e quando programmano cercano di dare il massimo. Di solito programmano in C++ e il software finale è molto curato e sicuramente di gran lunga superiore ai precedenti.

In un mondo pre-.NET tutto questo non sarebbe stato un problema: ad ognuno il suo e così  l’analista crea macro per excel, il secondo gioca con VB e il terzo fa il mago del C++.

Ma l’obiettivo di .NET è far stare tutti dentro .NET.

L’idea di base è quella di dare un set comune a tutti questi programmatori: così mentre I primi due gruppi trovano parecchio (anche troppo rispetto a quello) di quello di cui hanno bisogno, gli esperti si scoprono tutte le magagne e limitazioni.

Cosa ancora più grave, molte delle soluzioni adottate in .NET (come ad esempio I Windows Form) sono progettate e integrate strettamente con le relative funzioni di Win32, affossando così quello che sarebbe potuto essere ma non è questo nuovo framework: un taglio definitivo con il passato.

Il SECONDO CHECKPOINT

Dopo aver visto .NET è tappa obbligata fermarsi su un altro punto cruciale della storia di Redmond. Win64, la versione riscritta delle API per sistemi a 64-bit.

Portare un programma a 32 bit in Win64 significa almeno ricompilarlo e, in alcuni casi, effettuare i necessari cambiamenti affinchè possa funzionare senza problemi e sfrutti appieno le nuove potenzialità.

Questo potrebbe portarci a pensare che forse questa volta MS abbia deciso di rendere le API più compatte (almeno un pò), ma in realtà non è stato così.

Per chiarire meglio proviamo a fare un esempio. In Windows esiste una funzione che restituisce la dimensione di un file; I file in windows sono limitati a 2 alla 64 bytes e quindi per essere espressi facilmente hanno bisogno di 64bit. Per risolvere questo su sistemi a 32 bit li si combina in una maniera particolare; su Win64 ci si aspetta invece ragionevolmente un intero di 64bit. Speranza persa.

Quello che voglio dire è che la necessità di supportare API deprecate (alcune fin da Win16) ha fatto si che Microsoft non riuscisse a tagliare in maniera adeguata i ponti con il passato, contribuendo a rendere tutto l’ambiente pieno di questi piccoli problemi che alla fine danno solo grattacapi ai programmatori come Peter.

Si è sacrificato quindi il design - e la pazienza dei programmatori - a favore di una forte retrocompatibilità.

Questo fatto si riflette sia sui programmi esterni che sulle applicazioni di Microsoft stessa, alcune delle quali (soprattuto nel settore business) non sono state più aggiornate e spesso incappano in problemi dovuti ai cambiamenti interni del sistema intercorsi nei vari aggiornamenti.

Per cercare di mantenere un ambiente il più possibile amichevole con queste applicazioni Microsoft ha inserito in windows tutta una serie istruzioni che non si sa bene come funzionano (nessuna di queste è documentata quindi la loro stessa funzionalità non è garantita da nessuno) e che tendono a rendere più fragile l’intero sistema.

Peter racconta anche un piccolo aneddoto per farci capire meglio le cose: in Windows a 16bit la cartella di sistema dove vengono inserite tutte le librerie è chiamata “system”. In Win32 il suo nome è cambiato in “system32”; in Win64 il suo nome è cambiato in… “system32”(!). Solito problema di retrocompatibilità, anche se quella cartella contiene tutta roba per il 32 bit.

I file per il 64 bit sono in “syswow64”.

Esatto, una cartella con 64 nel nome, ma che contiene file per il 32bit. Riuscite a darci un senso?

LA SITUAZIONE DI OS X

Ma lasciamo per un attimo Windows. Quello che Microsoft non è riuscita a fare, ovvero troncare in maniera netta col passato - innovando - pur mantenendo una certa retrocompatibilità, lo ha fatto Mac OS X.

Un ottimo set di API ha facilitato la creazione di applicazioni di grande qualità; le applicazioni della stessa Apple (se lasciamo di conto alcune scelte intercorse tra 10.3 e 10.4) hanno creato una pista seguita da tutte le altre perchè hanno fatto si che nell’utente si insediasse il desiderio di poter utilizzare dei buoni prodotti (buoni nel codice ma anche nella loro resa grafica).

VISTA

Quello che non si è materializzato con Windows XP Microsoft ha cercato di renderlo realtà con l’arrivo di Windows Vista; in particolare si è cercato di creare un intero set di funzionalità per .NET in grado di essere utilizzate in applicazioni chiave quale, ad esempio, lo stesso Explorer.

.NET per Longhorn (nome in codice di Vista) sin dalle prime versione ha trasmesso nel programmatore l’idea che finalmente era possibile tornare a programmare per Windows in maniera decente avendo addinittura un look&feel consistente.

Purtroppo però quell’idea è andata perdendosi tra una build e l’altra, tra un taglio e l’altro e il sogno anche questa volta è svanito. Il risultato è stato Windows Vista.

Siamo tornati così al punto iniziale del nostro viaggio, ed è finalmente giunto il momento di parlare di questa (in)voluzione.

Durante la progettazione di Vista gli ingegneri hanno lavorato parecchio sulle linee guida dell’interfaccia; l’ovvia ispirazione viene da OS X, ma la realizzazione pecca ancora di parecchi buchi.

Pensiamo ad esempio alle finestre di dialogo che in Windows sono sempre state bistrattate. Queste finestre riportano quasi tassativamente I due pulsanti “Si” “No” oppure “OK”, “Cancel”; questo significa che è necessario leggere l’intero messaggio per avere solo la vaga idea di quello che succedere.

In un mondo perfetto non ci sarebbero problemi, ma gli utenti di solito cliccano a caso e sopra le due righe di testo perdono la concentrazione.

Così in un documento di testo non ci sarà ad esempio “Save” “Don’t Save” ma “Yes”, “No”.

Dopo 20 anni Microsoft ha capito questa cosa.

L’idea delle linee guida è ottima; lo abbiam visto con OS Classic e lo vediamo con OS X. La necessità di rendere le applicazioni omogenee con l’intero sistema non è semplicemente una questione di look ma anche di semplicità e immediatezza nell’uso.

Quando neanche Microsoft rispetta le proprie linee guida ne in Vista, ne in Office, come si può pretendere che qualcuno le legga?

Window Explorer e Internet Explorer sembrano uguali, alcuni pulsanti sono simili, ma se guardate bene ci sono differenze deliberate ovunque. Non c’è nessuna consistenza. E questo si riflette sia sull’interfaccia sia sull’implementazione dei controlli (che non è la stessa e condivisa ma che ricalca scelte personali dei programmatori).

E così si ritorna di nuovo indietro.

Piccoli e grandi cambiamenti, piccole e grandi differenze che contribuiscono a rendere l’esperienza d’uso da potenzialmente buona a…sicuramente mediocre.

Se neanche Microsoft si prende cura di rispettare le proprie linee guida perchè dovrebbero farlo I programmatori? E anche volendolo fare a quale genere di implementazione dovrebbero ispirarsi? Messenger? Office? Explorer?

E per quanto la loro implementazione potrà essere usata se da una versione all’altra viene abbandonata completamente la precedente?

Mac OS X non è certamente un sistema perfetto; chi lo ha usato continuamente durante questi anni avrà sicuramente notato i diversi esperimenti (e follie) che a volta Apple ha deciso di fare sulle proprie applicazioni.

Tuttavia tranne delle piccole differenze l’interfaccia rimane quella. Ad esempio, la menubar è sempre quella, non è messa sotto i pulsanti della toolbar per chi sa quale motivo e non ha un look diverso dalle altre.

Schemi di interfaccia come le HUD (quelle grigie) sono usati da applicazioni di terze parti in ben determinati ambiti e non sfociano in un uso indiscriminato e casuale.

Questo continuo reinventare la ruota senza fare di queste realizzazioni porzioni di sistema (ovvero renderle disponibili alle altre app) ha portato alla creazione di implementazioni customizzate degli stessi che possono di nuovo cozzare col resto di Windows nel momento in cui qualcosa cambia.

La ribbon bar (quella di Office) ha ben due implementazioni, quella interna di Microsoft e quella comprata da sviluppatori di terze parti, e nessuna delle due può essere al momento usata su .NET; solo C++.

La chicca speciale è che sembra ce ne sarà una nuova anche per il prossimo sistema operativo.

CONCLUSIONE

E’ stato probabilmente l’articolo più lungo di questo blog e se siete arrivati fin qui vorrete certamente un piccolo riassunto di quanto detto.

Sono principalmente due i concetti che ho voluto sviscerarvi. Il primo riguarda un ambito che a prima vista può sembrare di poco conto: la passione che i programmatori in Windows metto nelle loro applicazioni. Questo punto è fortemente penalizzato dalle scelte di Microsoft nella sua storia, dalla incoerenza nel perseguire le proprie scelte e nello scarso e frammentato supporto che offre.

L’altro punto chiave è di natura più tecnica e riguarda la necessità sempre più impellente di dare un taglio con il passato; abbiamo visto come Apple sia riuscita perfettamente in questa scelta mentre in Redmond nella corsa a dare manforte al passato ci si è ritrovati a combattere con un futuro più disomogeneo, confusionario e ultimo ma fondamentale, anche più fragile.

Eppure, come abbiamo visto nell’ultima parte, le occasioni non sono mancate; semplicemente le si è ignorate.

Ora che Bill ha presentato le novità più grandi del Windows prossimo venturo (in cui sembra dominerà il touch) ci chiediamo se ancora una volta verranno fatti gli errori di sempre, oppure si guarderà veramente in avanti.