Windows è concepito come sistemi multi utente. Ogni utente si connette sotto il proprio nome e il suo profilo, e le impostazioni personali vengono caricate per tutte le applicazioni e per Windows. Il sistema operativo dovrebbe tenere presente questa funzionalità sia durante l’installazione, sia durante il funzionamento: infatti, nella cartella del programma dovrebbero essere contenuti solo i file del programma stesso, mentre i dati utente dovrebbero trovarsi nella cartella DOCUMENTI di colui al quale si riferisce la configurazione del software.
Lo stesso dicasi per le impostazioni: i file con estensione INI dovrebbero essere memorizzati solo nelle cartelle DOCUMENTI, mentre le impostazioni del registro di configurazione dovrebbero essere archiviate sempre e solo in una sottochiave di HKEY_CURRENT _USER, se si tratta di impostazioni utente. Nella chiave HKEY_- LOCAL_MACHINE, invece, dovrebbero andare solo le impostazioni globali, ossia indipendenti dall’utente. È importante sapere anche che i collegamenti ai programmi dovrebbero essere presenti nel menu di avvio comune a tutti gli utenti, non in quello di colui che ha installato il programma. La separazione tra impostazioni di sistema e impostazioni dell’utente dovrebbe quindi essere mantenuta in linea con queste indicazioni. Le modifiche eseguite da un utente non possono ripercuotersi sugli altri. Gli interventi che agiscono su impostazioni globali, invece, dovrebbero essere consentiti solo agli amministratori. Sorprende tuttavia riscontrare che, con le proprie applicazioni, le grandi software house sono meno fedeli alla filosofia multi user rispetto ad alcuni freeware o shareware in circolazione.
Mozilla. Un esempio decisamente positivo è rappresentato dal browser gratuito Mozilla al sito mozilla.org In questo caso, infatti, le impostazioni globali e quelle specifiche dell’utente sono ben separate, le espansioni software e i plug-in possono essere installati in due modi: o vi provvede l’amministratore, che li mette a disposizione di tutti gli utenti, oppure un utente li installa nella propria cartella. In questo caso sarà l’unico a poterli utilizzare e tali espansioni non andranno a modificare i profili degli altri, per esempio con abbinamenti diversi dei file, comportamenti differenti del browser o certificati accettati.
Internet Explorer. Il browser Microsoft funziona in modo corretto, ma solo a prima vista. Le opzioni Internet possono essere impostate individualmente per ogni utente. Alle connessioni remote può provvedere l’amministratore, a livello di sistema, oppure ogni singolo utente le può creare e gestire per se stesso. Ma proprio in un punto di particolare importanza per la sicurezza, il browser di Microsoft fallisce miseramente. Se un utente preleva un controllo ActiveX e ne accetta il certificato, tale controllo approda nella cartella globale %WINDIR%\DOWNLOADED PROGRAM FILES, anziché nel profilo personale in APPLICATION DATA\- MICROSOFT\INTERNET EXPLORER. Anche l’accettazione del certificato ha uguale validità per gli altri utenti. Se la verifica del certificato viene disattivata nelle impostazioni per la sicurezza, il controllo giunge nella predetta cartella anche senza questa ulteriore conferma, ed è quindi a disposizione di tutti gli altri utenti, senza che abbiano alcuna possibilità di verifica. Basta fare una prova: se si visita per esempio il sito www.google.it e si installa la barra degli strumenti di Google, è necessario accettare il certificato di Google. Se poi ci si connette con il nome di un altro utente, la barra degli strumenti sarà comunque a disposizione senza dover dare un’ulteriore conferma al certificato di Google. Se ci si imbatte in un controllo ActiveX “cattivo”, basta che un utente ingenuo faccia una volta di troppo clic su OK e il controllo sarà installato per tutti.
Con un software professionale ci si aspetta almeno che sia l’utente a decidere i percorsi di installazione delle principali cartelle di programma. Mentre alcuni software arrivano persino a lasciare all’utente la possibilità di copiare le librerie del programma nella cartella generale delle DLL (SYSTEM o SYSTEM32) piuttosto che nella cartella del programma stesso,
altri sono davvero carenti in tal senso. Proprio Windows offre pochissime possibilità di intervenire sulla struttura delle cartelle con la quale ci si trova poi a confrontarsi ogni giorno. L’unica libertà che il sistema operativo riserva all’utente durante la normale procedura di installazione è quella di stabilire il nome (conforme alle specifiche DOS) della cartella di destinazione. Windows stesso, tuttavia, non si attiene alla convenzione prevista, con la conseguenza che i nomi di file vengono memorizzati nel registro di configurazione sia abbreviati, sia “abbelliti” di tilde. Le cartelle PROGRAMMI e PROGRAM FILES diventano spesso “Progra~1” e “Progra~2”. Per questo le applicazioni che vengono installate successivamente a volte non riescono ad accedere correttamente alle cartelle corrispondenti e sono in qualche misura costrette a creare le proprie cartelle in un’altra posizione. Gli utenti di Windows hanno sempre a che fare con il percorso DOCUMENTS AND SETTINGS, il che almeno in script e righe di comando è d’impedimento e, a causa degli spazi, è causa di numerosi errori.