Il futuro dell’ambiente di sviluppo Microsoft è molto incerto. Meglio prepararsi alla transizione
di Michele Costabile
Non ci siamo fatti prendere dal millenarismo, tantomeno adesso che il primo millennio è passato senza danni e il secondo anche. Ci siamo, invece, posti il problema di cosa fare con una base di codice Visual Basic 6 ereditata dai tempi d’oro di questo linguaggio, tempi purtroppo trascorsi da un pezzo. Visual Basic 6, infatti è decisamente fuori tempo massimo. Non solo, ma mantenere in vita certi progetti può rendere difficoltoso l’acquisto di nuovi computer, dato che può essere necessario fare il downgrade del sistema operativo, almeno sulle macchine di sviluppo.
Microsoft continua a offrire supporto per il suo ex cavallo di battaglia, forse fino alla prossima release del sistema operativo, ma è un fatto che da più di qualche anno sta tentando di scoraggiare la sopravvivenza del suo attempato pupillo, ed è una buona cosa non farsi cogliere impreparati.
Le buone ragioni per mandarlo in pensione
L’azienda di Redmond ha avuto ottime ragioni per passare dalla vecchia architettura a quella corrente. Riassumiamole brevemente. In primo luogo, l’architettura del Com è basata sull’esportazione di proprietà e funzioni a livello binario. Chi ha pensato a questa soluzione ha creato un ottimo modello per il link dinamico di codice C, ma non ha si è reso conto per tempo di aver generato falle nella sicurezza, che lasciano un sacco di opzioni ai creatori di malware. In secondo luogo, l’architettura di Com è troppo povera per supportare in modo pulito versioni diverse del software, dando origine al famoso Dll hell, ossia al problema di trovare un insieme di librerie dinamiche che non mettesse in crisi nessuna delle applicazioni installate, man mano che ci sono aggiornamenti e iniziano a convivere applicazioni realizzate in tempi diversi.
La nuova architettura .net, si fonda su una macchina virtuale proprio come Java. In parte ci sono motivazioni storiche, dato che l’autore dell’architettura .net ha iniziato la sua carriera in Microsoft con Visual J++, dopo una lunga esperienza in Borland con Delphi. Visual J++ fu la prova che si può realizzare un ambiente virtualizzando l’intera piattaforma, senza dare accesso diretto alle librerie dinamiche Dll. La macchina virtuale può eseguire controlli di congruenza e applicare regole di sicurezza al codice binario, cosa che è fuori della portata del codice compilato.
Come aveva dimostrato ampiamente Java, si può realizzare una piattaforma molto più sicura usando una macchina virtuale, senza una evidente penalizzazione in termini di performance.
In secondo luogo, la macchina virtuale comporta l’indipendenza dalla piattaforma hardware e software. Quindi, anche se tutti vogliono bene a Intel, la grande disponibilità di chip potenti e veloci e la maggiore varietà di piattaforme consentono l’apertura di mercati nuovi, che è una buona cosa.
Microsoft si è aperta la strada verso gli Arm che muovono i telefoni e i tablet in circolazione, proprio grazie alla disponibilità di una piattaforma su una macchina virtuale.
Un gruppo di developer particolarmente dinamico ha creato un clone della piattaforma su Linux, il progetto Mono, e adesso disponiamo di tool di sviluppo open source, come MonoDevelop e ambienti compatibili con .net su Android e iOS, come Xamarin, che sono un’opportunità in più per gli sviluppatori Windows.
Microsoft ha visto tutto questo e ha imboccato la strada della piattaforma.net lasciandosi alle spalle il Com e le Dll, con tutti i problemi di compatibilità e sicurezza che hanno afflitto Redmond per un decennio.