Introduzione al Windows Scripting Host

Vai all'articolo successivo

Tutti i sistemi 'moderni' hanno almeno un sistema di Scripting che consente ad un utente o ad un programmatore di automatizzare passaggi ripetitivi, creare piccoli programmi di utilita' quotidiana o (per i piu' smanettoni) dei veri e propri programmi.

Unix e' stato il primo sistema ad integrare un esteso sistema di scripting interpretato direttamente dalla shell, in grado di gestire cicli (do..while e for...next), varibili, annidamenti (if) et similia.

Il DOS aveva i file .BAT che, per quanto molto meno efficienti (e la documentazione al riguardo era molto confusa) svolgevano egregiamente molti compiti. Forse proprio sentendo questa 'mancanza' la maggior parte delle versioni di DOS era dotata di un qualche tipo di interprete Basic, che in molti casi suppliva alla carenza degli scripting interni.

Windows.... no. Windows non e' mai stato dotato di un proprio sistema di scripting, potevano essere utilizzati dei file .BAT anche all'interno di Windows, ed e' tutt'ora cosi', ma un suo linguaggio non lo ha mai avuto.

Questo ovviamente non ha fatto molto bene al sistema nel suo insieme, quello che potrebbe essere automatizzato non lo e', e molte volte un'insieme di attivita' relativamente 'sceme', cone l'analisi di un semplice file ASCII per estrarne dei dati da elaborare poi con Excel o con altri strumenti molto piu' sofisticati e' lasciata all'utente stesso.

In realta' cio' che e' stato fatto e' stato di spostare il linguaggio di scripting dal Sistema Operativo al singolo Applicativo: tutti i programmi piu' o meno sofisticati esistenti in Windows hanno un loro, personale, linguaggio di scripting con il quale si automatizzano le operazioni che in DOS ed in Unix si fanno a livello di Sistema Operativo.

Oltre a creare una grande confusione e ad essere assai poco pratico (perche' cavolo devo perdere 1,5 minuti per caricare Excel per poi eseguire una Macro che dura 2 secondi e mezzo???) questo sistema e' anche assolutamente non-portabile: il linguaggio di Excel e' diverso da quello di Word, che e' diverso da quello di Lotus... e cosi' via.

Per non parlare poi del fatto che, in moltissimi casi, questi linguaggi risentono anche della nazionalizzazione dei vari applicativi, percui uno script (o macro) sviluppato dalla casa-madre tedesca della nostra societa', portato sul nostro Excel in Italiano magari non funziona (anzi, e' sicuramente cosi').

Questo atto di Microsoft non fu' dettato da un desiderio di fare del bene al prossimo (che poi sarebbero anche i suoi clienti), ma allo scopo di spingere tutte le altre societa' ad abbandonare i loro linguaggi di scripting proprietari implementando il motore di Visual Basic come interprete per gli script (pagando le royalties a MS naturalmente).

A parte le mie considerazioni personali sulla cosa, questa operazione non e' ancora terminata, e gli unici motivi per cui si muove con cosi' tanta lentezza sono il costo necessario per acquisire il 'motore' di Visual Basic da integrare nella propria applicazione e la necessita' di inserire nel proprio codice una vera e propria montagna di richiami a tale motore per consentirne il funzionamento. Insomma passare a VBScript per una societa' che ha gia' un prodotto, non e' per niente semplice.

Un effetto collaterale di questo tipo di azione, fu il rilascio, da parte di Microsoft di una cosa denominata Windows Scripting Host o WSH (un'altro dei maledetti acronimi di 3 lettere per cui MS e' famosa).

Il WSH altro non e' che il motore di Visual Basic, spogliato di tutte le amenita' 'grafiche' e ridotto al mero (si fa per dire) interprete del linguaggio, ed un minimo di codice intorno per permettere il richiamo di DLL standard e cose cosi'.

I file 'originali' provenivano da un sistema SAP, la societa' che aveva commissionato la cosa sapeva perfettamente che chiedere a quelli di SAP di realizzare direttamente il file in formato 'giusto' equivaleva ad una mortale emorragia di soldi, percui si erano accontantati di chiedere che la stampa di un modulo (ridotto all'essenziale), venisse indirizzata su file anziche' su stampante.

Ora, un simile problema e' di una banalita' sconcertante, fossi stato su Unix avrei messo mano ad uno script o ad un minimo di AWK per produrre il risultato nel giro di 10 minuti, purtroppo il tutto doveva funzionare sui client Windows 95 della societa'.

Mi vedevo gia' a penare per scrivere un programma in C, con tutti i problemi di manutenzione, per fare cio' che sarebbe stato immediato con uno script da due soldi (sigh!).

Fu a questo punto che mi capito' sotto mano l'ennesima pubblicazione targata Microsoft, dove si sbandierava Visual Basic Scripting Edition al grido di 'metti VB nel tuo programma'. In un angolino, quasi nascosto si faceva riferimento ad un fantomatico 'Scripting Host' che "aggiunge capacita' di scripting a Windows e sara' integrato nelle future versioni di Windows '98 e 2000".

Siccale' sta' roba qua'??? Mi chiesi, indi, attaccatomi al sito Microsoft mi diressi a spron battuto verso l'indirizzo Internet riportato sul documento.

Cio' che dissi dopo aver letto la documentazione fu' "se funziona, e' proprio quello che stavo cercando!".

Funzionava, risolsi il problema con uno script VB che poi modificai in 5 minuti di fronte al cliente finale perche' quelli di SAP avevano scambiato due campi nella struttura del file. Se avessi fatto un programma in C avrei dovuto fare le modifiche e poi tornare, con WSH dovetti solamente usare il Notepad per modificare lo script.

Cosa ottenete con WSH? In apparenza niente, nel senso che, dopo che avete fatto l'installazione tutto rimane come prima, il WSH c'e', ma non si vede. L'unico momento in cui si vede e' quando si comincia ad usarlo.

Nel caso del Windows Scripting Host, abbiamo il supporto di due linguaggi: VBScript, cioe' Visual Basic Scripting Edition e JScript, la versione di JavaScript implementata da Microsoft.

Per creare uno script e' possibile usare un qualunque editor in grado di produrre file ASCII, il volgare Notepad va' benissimo, il file deve avere estensione .VBS se e' VBScript e .JS se e' JavaScript.

Per eseguire lo script e' sufficiente farci doppio click sopra con il mouse, se il WSH 6egrave installato nella macchina il file verra' eseguito.

La differenza fondamentale tra un file .BAT ed un file di Scripting, e' che il file di Scripting e' integrato nel sistema. Un file di Scripting puo' avviare Word e 'pilotarlo' usando le chiamate DDE o OLE, un file BAT non puo' farlo.

Uno script WSH puo' accedere al registro di configurazione di Windows, leggere e/o modificare delle chiavi del registro, puo' accedere ad un file Excel usando Excel stesso attraverso l'OLE

Semplicemente copiate il codice seguente in un file chiamato PROVA.VBS, se il WSH e' installato noterete una icona un po' diversa dal solito, quindi fateci doppio click per eseguirlo.

' Introduzione al Windows Scripting Host
' Questa e' una prova per verificare il funzionamento del WSH
'
' By Davide Bianchi (C) 2000
'

Dim userName

userName = InputBox( "Immettere il proprio nome", "Una domanda" )
MsgBox "Questo e' il WSH mio caro " & userName, vbOkOnly + _
  vbInformation, "Esempio"

' fine del programma

prosegue...

Max length of comments: 1000 chars.

Add a comment (max 1000 chars)