domenica 1 aprile 2007
Sappiamo tutti che, nonostante i vari Service Pack e gli aggiornamenti per Windows Vista, la compatibilità di Visual Studio con questo sistema operativo non è totale. In larga parte si tratta comunque di problemi secondari o che possono essere aggirati avviando l'IDE come amministratore. Altri inconvenienti, invece, sono più "rognosi". Uno di questi si verifica quando si crea un programma di setup comprendente il modulo che scarica e installa automaticamente i prerequisiti dell'applicazione. In questo caso, infatti, viene creato un file di nome SETUP.EXE contraddistinto dalla classica icona con lo scudo, ovvero che richiede i diritti di amministratore per essere eseguito. Il problema è che, quando si lancia l'installazione, appare il messaggio Tentativo da parte di un programma non identificato di accedere al computer; nella stessa finestra si legge che l'autore non è identificato.
La situazione è leggermente diversa con la CTP di Marzo 2007 di Orcas. In questo caso il setup creato non richiede l'elevazione dei diritti. Tuttavia, se si prova comunque ad eseguire l'installazione come amministratore, si ottiene di nuovo il messaggio Tentativo da parte di un programma non identificato di accedere al computer.
Qualche giorno fa Determina ha segnalato una vulnerabilità che affligge i sistemi operativi Windows 2000, XP, 2003 Server e Vista e riuarda i cursori animati (ANI). Nel caso di Windows Vista, come si può vedere in questo video, un cursore animato non valido fa entrare il sistema in un ciclo infinito di crash-riavvio di Explorer-crash.
Con questo post so di suscitare qualche polemica... Perché un amico mi ha detto che la causa principale dell'astio nei miei confronti sono proprio i progetti che ho pubblicato su CodePlex. Ma di questo parlerò nei prossimi giorni...
Poco fa sono ho reso disponibile la versione 1.0 finale di Windows Disguiser, il programma che consente di spostare nella system tray i programmi ridotti ad icona, per "fare spazio" nella barra delle applicazioni. Il primo annuncio di questo software non ha suscitato molto interesse, visto che gli unici feedback che ho ricevuto mi accusavano di buttare via il mio tempo... Tuttavia, guardando le statische del progetto, ho notato comunque che qualcuno è stato incuriosito dalla mia idea, e questo mi rallegra 
.
Qualche giorno fa avevo segnalato un problema nell'accedere al sito Microsoft Connect. In quell'occasione, su consiglio di Alessandro Petrelli avevo risolto cancellando i cookie di Internet Explorer. Tuttavia, ho notato che questo problema si presenta periodicamente (ho verificato su due macchine diverse), ed ogni volta devo cancellare i cookie per poter accedere di nuovo al sito...
L'introduzione della UAC di Windows Vista ha reso necessaria, tra le altre cose, una maggiore attenzione alla posizione in cui i programmi salvano le proprie impostazioni: questo perché, ad esempio, lo standard user non ha i diritti di scrittura nella cartella C:\Program Files. La seguente routine permette di sapere se l'utente dispone di determinati diritti sul file specificato:
public bool HasPermission(string fileName, FileSystemRights rights)
{
bool deny = false, allow = false;
WindowsIdentity identity = WindowsIdentity.GetCurrent();
FileInfo fi = new FileInfo(fileName);
AuthorizationRuleCollection acl = fi.GetAccessControl().GetAccessRules(true, true, typeof(SecurityIdentifier));
for (int i = 0; i < acl.Count; i++)
{
FileSystemAccessRule rule = (FileSystemAccessRule)acl[i];
if (identity.User.Equals(rule.IdentityReference))
{
if (AccessControlType.Deny.Equals(rule.AccessControlType))
{
if ((rule.FileSystemRights & rights) == rights)
deny = true;
}
else if (AccessControlType.Allow.Equals(rule.AccessControlType))
{
if ((rule.FileSystemRights & rights) == rights)
allow = true;
}
}
}
IdentityReferenceCollection groups = identity.Groups;
for (int j = 0; j < groups.Count; j++)
{
for (int i = 0; i < acl.Count; i++)
{
FileSystemAccessRule rule = (FileSystemAccessRule)acl[i];
if (groups[j].Equals(rule.IdentityReference))
{
if (AccessControlType.Deny.Equals(rule.AccessControlType))
{
if ((rule.FileSystemRights & rights) == rights)
deny = true;
}
else if (AccessControlType.Allow.Equals(rule.AccessControlType))
{
if ((rule.FileSystemRights & rights) == rights)
allow = true;
}
}
}
}
return !deny && allow;
}
Utilizzando questo codice, per sapere se l'utente ha il diritto di scrittura su un file basta scrivere qualcosa del tipo:
bool permesso = HasPermission(fileName, FileSystemRights.Write);
if (permesso)
MessageBox.Show("Hai i diritti di scrittura sul file.");
else
MessageBox.Show("Non hai i diritti di scrittura sul file.");
Il FileSystemWatcher ha un comportamento che, all'apparenza, può far pensare ad un bug: alcuni eventi, come OnChanged e OnCreated, vengono generati più volte. In realtà, questo comportamento è normale. Come viene indicato da MSDN:
Common file system operations might raise more than one event. For example, when a file is moved from one directory to another, several OnChanged and some OnCreated and OnDeleted events might be raised. Moving a file is a complex operation that consists of multiple simple operations, therefore raising multiple events. Likewise, some applications (for example, antivirus software) might cause additional file system events that are detected by FileSystemWatcher.
In questo post, inoltre, viene spiegato perché l'evento OnChanged viene generato due volte quando si salva un file utilizzando Notepad.