Forum libero

Scritto da: exsinistro

> Oggi bisognerebbe avere un programma installatore configurabile.
> Così sai tutto quel che fa e dove lo mette.

Compera un Mac !

Scritto da: altg
> Quando rimasi deluso dal caos degli installatori, .net non era neanche in mente dei. Oggi qualche progresso l'hanno fatto, ma la situazione fa ancora cagare.

Ai tempi del DOS il SO era molto acerbo. Conteneva il minimo indispensabile e non andava oltre a fornire un elenco di interrupt da chiamare lato software.

Se nel tuo programma volevi permettere all'utente di stampare con una EPSON dovevi scriverti un driver tu apposta, se volevi permettere anche l'uso di una Olivetti idem, ecc. Stessa cosa dicasi per praticamente qualsiasi dispositivo hardware.

A questo bisognava aggiungere il problema che generalmente gli interrupt forniti dal DOS (ma anche dalla BIOS) erano parecchio lenti e se volevi avere un minimo di performances (tipo nei videogiochi) ti trovavi spesso a dover armeggiare direttamente con gli in/out e specifici indirizzi di memoria (della scheda video, dell'HD, ecc).

Questo poteva andare bene fintanto che avevi a che fare con un elenco limitato di periferiche... ma oggi non puoi più pretendere che uno ti scriva 10'000 driver per supportare altrettante stampanti...

Il SO si è perciò evoluto per fornire delle interfacce standard al software in modo che i singoli produttori di hardware si facessero carico di scrivere loro i driver dei loro dispositivi e tu, lato software, potessi invece appoggiarti su un'interfaccia standard semplificandoti di parecchio lo sviluppo e al tempo stesso permettendoti di usare al massimo le caratteristiche dell'hardware dell'utente.

Un primo tentativo in questo senso credo sia stato fatto con i lettori CDROM e il famoso MSCDEX (bene o male standard) che però si appoggiava su driver specifici per quel determinato lettore (con estensione .SYS).

Windows è stato il passo successivo. Oltre a supportare il discorso modulare dei driver ci si è chiesti se si poteva fare qualcosa di simile con i software. Visto che alcune librerie erano ampiamente usate da parecchi programmi... perché non fornirle con il SO o metterle nella cartella del SO in modo da risparmiare spazio e renderle disponibili a tutti? Poi si è centralizzata la configurazione con il Windows Registry che oltre a contenere impostazioni di sistema ora conteneva anche le impostazioni dei singoli programmi.

Questo è stato anche l'inzio del così detto DLL HELL... ovvero una marea di DLL, spesso dai nomi identici ma versioni o funzioni e interfacce molto diverse, che andavano a popolare la cartella di Windows.

Il risultato di tutto questo era che:
1) ora ti serviva un installer che verificasse se le DLL che ti servivano erano o meno già installate ed eventualmente installarle
2) ora l'installazione di un programma X poteva rompere un programma Y precedentemente installato per via della collisione di nomi delle DLL
3) disinstallare un programma non era più banale... dovevo disinstallare anche le DLL condivise? Se si, quali? Come facevo a sapere se erano usate da altri programmi?
4) i programmi non erano più facilmente spostabili da un computer all'altro e non era più banale backupparli

In altre parole questa è stata la fine della "portabilità" (non intesa come portare da un SO all'altro) dei software e della necessità di usare installer. Tutto questo era dettato anche dalla scarsità di spazio disponibile degli anni passati... se potevi condividere le DLL con altri programmi i tuoi programmi diventavano automagicamente più piccoli e quindi più apprezzati. Oggi, con l'abbondanza di spazio che c'è, queste valutazioni non hanno più molto senso ma erano importanti negli anni 90 e primi 2000. Per questo oggi si vede ad un "revival" di questi programmini "portable". Chi se ne frega se Eclipse usa 200MByte di spazio su disco? 200MByte su 1TB è una dimensione risibile... ma quando avevi 1GB di spazio disponibile 200MByte erano una buona fetta del tuo disco.

Un altro punto a favore di questo approccio "sparagnino" era che ora se aggiornavi una DLL condivisa, automaticamente tutti i programmi che la usavano godevano dei miglioramenti apportati, cosa impossibile nel caso di librerie incluse nella cartella del proprio programma.

Un primo tentativo di porre fine a tutto questo è stato proprio .NET basato sull'esperienza precedente con Java.
Con .NET ti bastava installare il framework e praticamente tutto quello che serve a te sviluppatore (salvo casi particolari) te lo trovi già installato sulla macchina e se non c'è è facile capirlo e installarlo. Inoltre, per la disinstallazione, non ti serve rimuovere il framework dato che è sicuramente usato da praticamente ogni singolo altro programma Windows esistente.

Anche per la configurazione si è cercato di porre rimedio con le cartelle nascoste ("application data") nella cartella degli utenti e molti programmi non hanno praticamente più alcun bisogno del registro di Windows (o per lo meno non lo usano più come pattumiera in cui sbatterci le loro impostazioni).

Insomma. Oggi come oggi, se scrivi un programma .NET, a meno che tu non abbia bisogno di hardware o librerie particolari, puoi praticamente inviare al tuo cliente solo la cartella da copia-incollare in "c:\Programmi" o dove diavolo vuole e funzionerà... quasi come ai tempi del DOS (con qualche attenzione in più, ma nulla di trascendentale).

> E chi ha difeso linux?

Era per dire che c'è di peggio. In Linux l'approccio "condividiamo tutto" è molto molto affermato. Così hai che scarichi un programma per scoprire che... cazzo... la mia distro non fornisce la versione ABC di quella cazzo di libreria (perché troppo vecchia o troppo nuova) e così devi stare a sbatterti a trovare una soluzione... quando non devi proprio ricompilarti tutto a manina, ammesso che tu lo sappia fare, e che il compilatore non sia cambiato al punto da considerare certe sintassi obsolete e rifiutarsi di compilare il programma (nel qual caso devi anche conoscere bene quel linguaggio per apportare le dovute modifiche).

Per esempio ho una versione di Linux di qualche anno fa su cui persino la versione portable di Firefox non funziona (delle poche librerie condivise che usa usa versioni più recenti di quelle fornite da quella distro)... da notare che la stessa versione di Firefox funziona tranquillamente su XP che ha molti più anni di quella distro.