Oggi stavo effettuando alcune ricerche su internet quando sono incappato in un mio messaggio inviato qualche mese fa sulla mailing list di ruby-it in risposta a chi chiedeva aiuto su come poter recuperare l'elenco delle unità montate su un sistema Windows. Ruby ormai offre da tempo un supporto particolarmente maturo all'interazione con il sistema su piattaforme Windows tramite Win32OLE e alle svariate librerie del progetto Win32 Utils. In questo caso, a dimostrazione della flessibilità delle soluzioni offerte da Ruby, lo stesso task può essere risolto in tre modi molto differenti tra loro.

Il primo approccio sfruttando il modulo Windows::Volume delle Win32 Utils consiste nell'utilizzare in maniera diretta le API di Windows e la sua implementazione, anche se può apparire grezza e magari non troppo elegante agli occhi dello sviluppatore Ruby puro, è comunque piuttosto facile:

require 'windows/volume'
include Windows::Volume

def get_drive_letters
    buffer = " " * 1024
    length = GetLogicalDriveStrings(buffer.length, buffer)
    buffer[0..length].split(0.chr)
end

p get_drive_letters
# => ["A:\\", "C:\\", "D:\\", "E:\\", "F:\\", "G:\\", "H:\\", "I:\\"]

Utilizzando GetLogicalDriveStrings si ottiene una lista di tutte le unità logiche montate nel sistema, indipendentemente dalla loro natura fisica, il tutto sotto forma di buffer contenente l'elenco di lettere di unità separate dal carattere NULL. Questo ci costringe a istanziare un buffer e a estrarne il contenuto con cui è stato riempito dalla funzione API in una maniera abbastanza lontana dal tipico stile di programmazione in Ruby, ma è pur sempre fattibile e tutto sommato non è poi così brutto a vedersi, c'è di peggio in altri linguaggi.

In Windows esistono poi gli oggetti COM messi a disposizione dalla Scripting Runtime Library e uno di questi, tra l'altro forse tra i più utilizzati, è FileSystemObject. Sinceramente sentire questo nome mi fa venire gli incubi tornare in mente a quando svariati anni fa mi è toccato usare ASP 3.0 che, per la cronaca, non ho mai sopportato. Il fatto di non dover usare le API Win32 salendo quindi di livello ci permette di utilizzare semplicemente Win32OLE:

require 'win32ole'

def get_drive_letters
    drives = []
    fso = WIN32OLE.new('Scripting.FileSystemObject')
    fso.drives.each { |drive| drives << "#{drive.driveletter}:\\" }
    drives
end

p get_drive_letters
# => ["A:\\", "C:\\", "D:\\", "E:\\", "F:\\", "G:\\", "H:\\", "I:\\"]

L'astrazione messa a disposizione da Win32OLE per le collection restituite da oggetti COM include automaticamente un metodo each che ci permette di iterare in maniera familiare e comoda il risultato dalla proprietà Drives dell'istanza di FSO.

Esiste infine la possibilità di utilizzare l'interfaccia messa a disposizione da WMI (Windows Management Instrumentation) per ottenere le stesse informazioni in maniera ancora più intuitiva con un approccio molto SQL-like nell'interrogazione delle informazioni sui sistemi Windows:

require 'win32ole'

def get_drive_letters
    drives = []
    wmi = WIN32OLE.connect('winmgmts://')
    devices = wmi.ExecQuery('SELECT * FROM Win32_LogicalDisk')
    devices.each { |drive| drives << "#{drive.DeviceId}\\" }
    drives
end

p get_drive_letters
# => ["A:\\", "C:\\", "D:\\", "E:\\", "F:\\", "G:\\", "H:\\", "I:\\"]

Interrogando la classe WMI Win32_LogicalDisk si può ottenere rapidamente una nutrita serie di informazioni risparmiandosi un sacco di giri o chiamate, delegando tutto al sistema operativo. Inoltre è possibile scremare già in fase di richiesta e molto facilmente il set di risultati desiderato, del resto come abbiamo visto le query WMI ricordano molto da vicino SQL. Per fare un esempio, cambiando la nostra query in SELECT * FROM Win32_LogicalDisk WHERE FileSystem = 'NTFS' è possibile ottenere l'elenco di tutte le unità il cui filesystem è NTFS. Un altro vantaggio non indifferente è quello di poter richiedere le stesse informazioni a computer remoti semplicemente cambiando la stringa di connessione al provider WMI, per esempio utilizzando una stringa di connessione come winmgmts:{impersonationLevel=impersonate}!\\192.168.1.2\root\cimv2 (in un dominio AD può tornare molto comodo per tenere sotto controllo le proprie installazioni).

E' possibile fare tutto e in molte maniere, ce ne è per tutti i gusti. Il vantaggio di poter interagire con Windows attraverso Ruby anziché con i soliti VBScript e JScript risiede prima di tutto nella sua estrema flessibilità rispetto ai suddetti linguaggi di scripting rivali forniti di serie nel sistema operativo, ma anche nella possibilità di sfruttare nei propri script di automazione tutte le classi standard e di terze parti che gravitano intorno a Ruby è un vantaggio da non sottovalutare nello sviluppo di task amministrativi più complessi. Ok posso percepire anche coloro che ci terrebbero a sottolineare come sia possibile fare le stesse cose con Perl e Python... sì, avete perfettamente ragione, ma qui si pubblicizza Ruby ;-P

Primo post del 2008 all'alba del tredicesimo giorno di gennaio, complimenti a me stesso per la tempestività. Insomma, anche se con un ritardo madornale vorrei augurarvi un buon 2008... per lo meno ora sapete che non ho fatto la fine del topo. Tornando al titolo del messaggio, oggi vagando a caso per internet ho trovato conferma sul blog di Davide Vernole a un sospetto che già mi era venuto nei giorni scorsi ma su cui non avevo indagato più di tanto per mancanza di tempo: dopo l'ultimo Windows Update che ho effettuato, SyntaxColor4Writer ha smesso di funzionare in Windows Live Writer. In realtà nell'approvare gli aggiornamenti avevo notato con la coda dell'occhio una voce riguardante Windows Live Writer per cui mi era bastato fare 1+1, ad ogni modo mi sono ritrovato impossibilitato a usare il mio plugin preferito per la formattazione del codice client-side data anche la mancanza di aggiornamenti pubblicati sul sito ufficiale dell'autore. Accidenti, proprio quando volevo mettermi di buzzo buono per aggiornare la mia definizione della sintassi di Ruby alle novità della 1.9. Oh well, poco male, rispolveriamo un mio post pubblicato in occasione del rilascio di WLW B2 e adattiamolo all'esigenza odierna:

1. E' necessario avere installato Visual Studio dal momento che verrà utilizzato ILDASM per effettuare il dump del relativo codice IL della DLL di SyntaxColor4Writer. In teoria credo sia possibile usare anche monodis (l'equivalente per Mono) ma sinceramente, non avendolo mai provato, non ho idea di quale possa essere il risultato finale e del suo grado di compatibilità.
2. Creiamo una directory in cui copiare il file IStaySharp.SyntaxColor4Writer.dll e apriamo una shell dei comandi puntando alla stessa per eseguire vsvars32.bat (importa tutte le variabili d'ambiente per usare i tool di VS)
3. Per effettuare il dump completo con ildasm.exe via command line dovremmo specificare una sfilza di parametri abbastanza lunga, per cui lanciamolo senza argomenti per eseguirlo in modalità GUI: a questo punto importiamo la DLL IStaySharp.SyntaxColor4Writer.dll e facciamone il dump nella directory corrente spuntando tutte le opzioni nella dialog delle dump options. Per comodità salviamo il file IL risultante con il nome IStaySharp.SyntaxColor4Writer.il
4. Apriamo con un editor di testo qualsiasi il file .IL appena generato e sostituiamo tutte le occorrenze della stringa .ver 12:0:1366:1026 con .ver 12:0:1367:1128 (in totale dovrebbero essere effettuate 3 sostituzioni). Con questa procedura non facciamo altro che aggiornare le reference agli assembly esterni di WLW specificando la nuova versione degli stessi, in realtà basta questo perché le API esposte da WLW verso i plugin non sono cambiate.
5. Ora dobbiamo ricompilare la DLL con ILASM: torniamo alla shell e lanciamo questo comando:
   ilasm IStaySharp.SyntaxColor4Writer.il /dll /res:IStaySharp.SyntaxColor4Writer.res
6. Una volta generata la nostra nuova versione di IStaySharp.SyntaxColor4Writer.dll non resta altro da fare che sostituire la DLL attualmente esistente nella directory Plugins di WLW e lanciare il programma.

Istruzioni sicuramente della mutua per uno sviluppatore .NET rodato, ma possono tornare comode ugualmente. A meno di cambiamenti particolari o differenze nelle API, come accaduto nel passaggio da B1 a B2 di WLW, questi passaggi dovrebbero rimanere validi anche per eventuali update futuri: basterà semplicemente aggiornare le stringhe di sostituzione con le relative versioni. Come in passato, se qualcuno avesse bisogno della DLL aggiornata e pronta per l'uso non dovrà far altro che contattarmi (anche privatamente, ho aggiunto l'indirizzo email in fondo alla pagina delle note in attesa di miglior organizzazione :-))

Non proprio guai, ma il gioco di parole nel titolo mi ha tentato fino all'ultimo. Qualche settimana fa, come ho già avuto modo di dirvi in precedenza, ho installato Windows Vista (in versione 32 bit) e devo dire di non aver riscontrato alcun problema con il riconoscimento dell'hardware e il sistema risulta essere piuttosto stabile, per lo meno dopo aver effettuato tutti gli aggiornamenti di Windows. Questo computer è collegato a uno switch KVM Avocent DVI/USB con funzionalità di hub USB, un prodotto che tra l'altro mi sento di consigliarvi se necessitate di un certo tipo di prestazioni come il supporto per risoluzioni fino a 1920x1200 che non sono raggiunte da tutti gli switch. Perché ho specificato il collegamento a un KVM USB? Perché fa parte della storia, ovviamente. Fino a qualche giorno sul computer usato per Vista erano installati 2 GB di RAM e tutto era perfetto, KVM compreso. Poi l'altro giorno ho deciso di passare a 4 GB di RAM ma non tanto per Vista in sé, il quale non mi sembrava necessitare più memoria di quella già presente, quanto per la virtualizzazione e per un po' di sana sboronanza. In realtà anche per evitare che il modello di RAM utilizzato per i primi 2 GB, già relativamente difficile da trovare, sparisse del tutto o aumentassero di prezzo (in effetti ho già risparmiato 4€), ma sono dettagli. Così ecco i banchi aggiuntivi installati, la schermata del boot loader, l'avvio di Vista... e la lucina del KVM che comincia a lampeggiare. Uh? Comunicazione tra computer e KVM interrotta, niente più tastiera e mouse. Spengo, tolgo i 2 GB di RAM aggiunti, riaccendo: KVM funzionante. Rimetto i due nuovi banchi: KVM non funzionante. Di conseguenza collego tastiera e mouse diretti tentando prima un Windows Update, rivelatosi tuttavia inutile, e poi una rilevazione hardware forzata che però non ha rilevato proprio nulla. Il sospetto di una pesante presa per i fondelli si fa largo e comincio di conseguenza a fare varie prove sostituendo l'hard disk con un altro su cui...

• installo Vista 32 bit: durante l'installazione lo switch KVM viene visto perfettamente ma al primo riavvio ecco che la lucina comincia a lampeggiare nuovamente. Almeno è coerente, non va.
• installo Vista 64 bit: tutto funziona alla perfezione, anche dopo l'installazione lo switch KVM viene visto correttamente. Ah beh.
• installo XP a 32 bit: tutto funziona alla perfezione, anche dopo l'installazione lo switch KVM viene visto correttamente. Eh?

Con XP 32 bit funziona e con Vista 32 bit no: sospettavo bene, mi prendono per i fondelli 🙂 Una volta ricollegato l'hard disk originale e avviato nuovamente Vista 32 bit usando mouse e tastiera diretti, ho potuto notare la presenza di un device USB sconosciuto nell'elenco delle periferiche USB e così, sicuro del fatto che si trattasse dello switch KVM, ho iniziato una pesante sessione di ricerca su Google interrotta però da un popup di notifica di Windows Update segnalante la presenza di un nuovo aggiornamento. Nel leggere la descrizione dell'aggiornamento proposto noto una frase del tipo "miglioramenti nel supporto e nella compatibilità con alcune periferiche USB". Vuoi vedere che... aggiornamento installato, computer riavviato per sicurezza e switch KVM nuovamente funzionante. Ah! Ma notificarmi prima l'aggiornamento? Ora il KVM viene visto nella gestione dei dispositivi (ex periferiche) come Dispositivo USB composito. Una dicitura che, per inciso, solo lui sa cosa voglia dire... però funziona. Morale della favola? Nessuna, ho perso 4 ore per una stupidata che però ho pensato di riportare sul blog nel caso dovesse capitare qualcosa di simile a qualcuno di voi o al lettore di passaggio.

Solo due note di contorno prima di chiudere:

• Vista 32 bit con il flag per l'attivazione dell'estensione PAE sembra non dare risultati, i 4 GB di RAM vengono visti comunque come 3 GB. Sapevo benissimo delle limitazioni di indirizzamento di memoria delle versioni di Windows a 32 bit ma speravo di poterle superarle in questo modo, tuttavia parrebbe non funzionare. Farò altre prove, ma del resto sfrutto lo stesso i 4 GB con Kubuntu a 32 bit quindi poco importa 🙂 Non ho molta voglia di installare Vista a 64 bit per motivi che magari vi elencherò prossimamente.
• Aggiornando la RAM installata sul proprio computer con banchi aggiuntivi, anche senza sostituire quelli precedentemente presenti, Vista richiede nuovamente l'attivazione (o almeno con me si è comportato così). Considerando che l'aggiunta di nuova RAM dopo aver installato Vista su un computer può non essere un'attività così astrusa, la cosa mi sembra un po' ridicola.

Dopo neanche 5 minuti dal termine di una installazione di Windows Vista, Internet Explorer mi delizia con questo:

Non male come inizio 🙂

Come ho avuto modo di dire in più di un'occasione, utilizzo con soddisfazione Windows Live Writer fin dalla sua primissima versione per pubblicare i messaggi che leggete sul mio blog. Da pochissimi giorni ne è stata rilasciata una nuova beta, distribuita all'interno del nuovo pacchetto Windows Live e questa volta disponibile anche in italiano, per cui eccomi a provarla con la scrittura di questo stesso post. La prima novità, quella che ritengo più interessante e che probabilmente è stata la funzionalità più richiesta nei mesi scorsi, è rappresentata dalla possibilità di impostare per ogni singolo blog registrato in WLW il tipo di codice generato: HTML oppure XHTML. Chi possiede blog con template XHTML e ci tiene al rispetto della corretta formattazione delle proprie pagine nella sua interezza può finalmente ritenersi soddisfatto, io sicuramente sono contento che abbiano ascoltato le richieste in merito da parte di molti utenti. Un'altra nuova possibilità offerta riguarda la decisione del set di caratteri da utilizzare, un'impostazione predefinita comunque su UTF-8. Aggiunta anche la stampa, con anteprima, dei propri post. Migliorie anche per le funzionalità di inserimento disponibili di default nell'applicazione:

• In Inserisci collegamento è stata aggiunta la possibilità di fare riferimento a precedenti messaggi pubblicati sul proprio blog sfruttando la combinazione Collega a -> Post precedenti. Si aprirà un'interfaccia, la stessa utilizzata per aprire vecchi messaggi attraverso Apri, che vi permetterà di sfogliare i vostri messaggi alla ricerca di quello a cui vorrete fare riferimento cercando tra quelli recenti oppure andando a recuperare dal blog quelli più vecchi.
• Con Inserisci immagine ora è possibile inserire immagini non solo dal proprio computer ma anche direttamente dal web, con tanto di anteprima. Migliorata anche la qualità risultante dalle funzionalità integrate di ridimensionamento, modifica e salvataggio delle immagini. E' possibile salvare come predefinite le impostazioni che volete nel caso siate soliti utilizzarne di differenti rispetto a quelle di default del programma. Infine, per chi utilizza Blogger, è prevista l'integrazione diretta per la pubblicazione delle proprie foto su Picasa Web Album.
• Inserisci video (novità per la distribuzione di default, erano già disponibili alcuni plugin di terze parti ma erano abbastanza bruttini rispetto a questo ufficiale) dovrebbe funzionare con i video portali più famosi, oltre all'ovvia integrazione con SoapBox, permettendo di mostrare un'anteprima del video (con tanto di player) a partire anche soltanto dal link "grezzo", risparmiandovi di dover inserire tutto il codice HTML necessario alla corretta visualizzazione del player nei messaggi. L'unica pecca per ora riscontrata è che non riconosce gli indirizzi localizzati di YouTube, per esempio quelli che riportano it.youtube.com vengono rifiutati perché non riconducibili a un provider video riconosciuto. Per aggirare rapidamente il problema, basta sostituire it (o l'identificativo della localizzazione) con www.

Il risultato mi sembra decisamente molto buono sotto tutti gli aspetti, ora le mancanze più importanti (pubblicazione XHTML, per esempio) sono state risolte e anche la stabilità del programma sembra visibilmente migliorata. Da parte mia continua a essere un programma estremamente consigliato e che facilita enormemente la vita a chi scrive con formattazioni più o meno complesse (aiutato poi dalla scrittura in linea per vedere direttamente i risultati all'interno del layout del proprio blog) oppure è abituato a buttar giù, abbandonare e poi riprendere spesso una o più bozze dei propri messaggi (bozze che tra l'altro possono essere memorizzate come draft sul proprio blog, in modo da poterle riprendere da altri computer con WLW stesso oppure semplicemente attraverso le solite interfacce web di amministrazione dei propri blog).