Quanto mi costa far funzionare le mie vecchie applicazioni su Vista?
Rieccoci con la terza riflessione nata da questo POST di qualche tempo fa (e con questa concludo la serie):
Quanto mi costa far funzionare le mie vecchie applicazioni su Vista?
Ricordo che le puntate precedenti le potete trovare qui:
Tipicamente passare da una release ad un'altra di Windows implica una serie di processi legati al testing delle applicazioni. La compatibilità applicativa infatti è stata sempre un elemento frenante per la migrazione. Non fraintendetemi... non sto affatto dicendo che bisogna migrare per forza... è implicito che se l'applicazione "core" della mia azienda non gira sulla nuova release non non è possibile migrare. Ma è anche vero che non è "bello" avere essere obbligati a tenere sistemi obsoleti (e magari non più supportati) solo perchè ci gira questa applicazione. E questo è sempre stato un'ostacolo a volte insormontabile.
Ma perchè le applicazioni sono incompatibili? La domanda è molto complessa non è negli obbiettivi di questi posto approfondirla nei dettagli.
Sicuramente, dall'esperienza che ho avuto, ho notato una cosa molto semplice.
Spesso le applicazioni cosiddette "legacy" risultano incompatibili con una versione successiva del sistema operativo in quanto, tipicamente, ad ogni release successiva di Windows viene sempre incrementato il livello generale di sicurezza. Vengono aumentate le restrizioni legate all'utente, si limitano i permessi sul file system, diminuiscono i task che l'utente può effettuare... insomma, la nostra povera applicazione "Contoso 1.0", scritta 10 anni fa, nel 1997, quando uno "user" di windows NT aveva molti più privilegi di uno "user" di Vista, letteralmente si troverà "bloccata" a funzionare nel nuovo più "ristretto" contesto utente di Vista. Naturalmente se si esegue l'applicazione con i privilegi massimi (local administrator), sempre che il problema sia questo (e nell'80% dei casi lo è) l'applicazioni funziona.
Ma come si è fatto fino ad ora? Come si faceva a far funzionare Contoso 1.0, scritta per Windows NT o magari Windows 98, su Windows XP?
Nel momento in cui si è trovata a dover migrare verso una release successiva di sistema operativo, l'azienda ha dovuto porsi il problema dei test applicativi; decine, spesso oltre un centinaio di applicazioni che debbono essere testate sulla nuova piattaforma per evidenziare eventuali problemi. Il costo generale di questa attività di test a volte può sembrare alto; davanti a troubleshooting, tentativi di ogni tipo, test non funzionanti, alla fine lo specchietto per le allodole, la finta panacea di tutti i mali, la decisione che salva capra e cavoli (in apparenza) è pronta per essere presa: "vabbè, per questi pochi utenti che usano questa applicazione diamo i privilegi amministrativi".
In realtà così si salva solo la capra.
Avete in mente cosa significa dare i privilegi di amministratore ad un utente. Sicuramente si. Se siamo in un contesto di ambiente gestito (managed), dare i privilegi di administrator ad un utente significa potenzialmente limitare la gestione della sua macchina e aumentare in maniera esponenziale il TCO (total cost of ownership). Per parlare in italiano, risparmio qualcosa nei test applicativi (o, più spesso, nel richiedere la versione nuova dell'applicazione) ma aumento a dismisura il costo di gestione di quella macchina (moltiplicato per tutte le macchine che sono utilizzate da utenti "amministratori"). Non ho infatti più la garanzia che la configurazione di quella macchina non venga modificata, che le applicazioni installate siano solo quelle previste, che le operazioni che faccio in maniera massiva su tutti i PC vengano eseguite correttamente anche su quello (in quanto potenzialmente non più standard). E il danno lo si paga prima o poi in termini di gestione, tempo perso, costi "extra".
Se prima di Vista il "costo" di far funzionare le applicazioni vecchie poteva essere alto (concedere i privilegi amministrativi), ora c'è un'interessante funzionalità che fa al caso nostro
File System and Registry Virtualization
Facciamo l'esempio dell'applicazione Contoso 1.0.
Una volta eseguita in contesto utente normale, tenta di scrivere una chiave di registro dentro la HKLM/System e un file dentro la c:\program files, entrambe azioni che richiedono privilegi amministrativi. Ovviamente l'applicazione fallisce segnalando un bell' ACCESS DENIED. In Windows XP.
In Windows Vista, alle applicazioni che lo richiedono, è consentito scrivere tali chiavi e files in posti "virtualizzati"; in breve all'applicazione viene fatto credere di scrivere nella HKLM/System o nella c:\program files; in realtà sta scrivendo dentro una ramificazione virtualizzata del registro contenuta nella HKCU (Current User, la parte del registro dell'utente loggato, nella quale l'applicazione ha FULL ACCESS) e in un path rediretto che emula la c:\program files.
Non più bisogno di aumentare i privilegi.
Un approfondimento in QUESTO articolo di MSDN.
Comments
- Anonymous
January 01, 2003
Già qualche mese fa avevo scritto una serie di post dedicati a quello che, almeno secondo me, era