Im Rahmen dieses Referats soll das Konzept des Windows Scripting Hosts erklärt werden. Hierzu ist zunächst einmal eine Begriffsklärung durchzuführen. Dieses und die Vorstellung der Architektur übernimmt das zweite Kapitel. Das dritte Kapitel beschreibt einige grundsätzliche Programmiertechniken, die beim Ausprobieren der im vierten Kapitel vorgestellten Programmbeispiele zu den Objekten, Methoden und Eigenschaften des Windows Scripting Hosts sehr hilfreich sind. Im letzen Kapitel möchte ich noch einige grundsätzliche Dinge zum Thema festhalten und eine mögliche zukünftige Entwicklung vorstellen.
Der
Windows Scripting Host (WSH) ist eine enorm leistungsfähige Erweiterung für
die Betriebssysteme der Microsoft Windows- Familie. Obwohl er bereits seit
Windows 98 zum Installationsumfang gehört, findet er in der Öffentlichkeit
noch nicht die Bedeutung, die ihm eigentlich gebührt. Ein Hauptgrund hierfür
ist die bisher meiner Meinung nach mangelnde Dokumentation von Microsoft, die
erst in letzter Zeit [vgl. MS 1] konkrete Formen annimmt.
Das Einsetzen von Scripten oder das Arbeiten mit Objekten, die man, grob gesagt
„nicht einfach nur mit der Maus anklicken kann“, zogen bisher viele Benutzer
und Entwickler nicht in Betracht, weil es als zu kompliziert bzw. die Leistungsfähigkeit
sehr eingeschränkt war.
Das bekannteste Beispiel hierfür sind die altgedienten Batchdateien unter DOS.
Sie waren während der DOS- Blütezeit (wer erinnert sich nicht gerne daran,
aber...), als objektorientiertes Programmieren noch als „höhere Mathematik“
galt eine enorme Erleichterung, boten jedoch keinerlei Komfort, denn ihre
Funktion beschränkte sich hauptsächlich auf das Aneinanderreihen von
DOS-Befehlen. Sie waren vom Umfang her meilenweit von einer Programmiersprache
entfernt und dennoch benötigte man zur Erstellung derselbigen enormes
Hintergrundwissen.
2 Die Windows- Skript- Architektur
Das Überwinden der bereits erwähnten „Einstiegshürde“ soll WSH- Neulingen unter anderem durch die von Microsoft entworfene Architektur zur Integration von Scripten erleichtert werden. Diese besteht aus drei Ebenen, die Scripting Hosts, die Scripting Engines und die
Bibliotheken, wobei die Komponenten der einzelnen Ebenen austausch- und erweiterbar sind. Über COM (Component Object Model)- Schnittstellen kommunizieren die einzelnen Schichten miteinander. Der Vorteil der Architektur liegt auf der Hand: Der Entwickler kann sich seine bevorzugte Umgebung „zusammenstellen“ und die erstellten Scripte sind sehr leicht portierbar.
Die Scripting Hosts stellen die Anwendungen dar, in denen die Scripts letztlich zur Ausführung und Anwendung kommen. Sie bilden einen Container für die Scripts, wobei deren Sicherheit für das System sehr umstritten ist und häufig diskutiert wird. Fest steht jedoch, dass einige nicht zu unterschätzende Sicherheitslücken bestehen und auch, trotz einer Unzahl an Bugfixes, immer wieder neue entdeckt werden.
Die Scripting Engines sind dafür verantwortlich, dass der Quelltext richtig interpretiert wird. Hierbei ist die Scripting- Architektur offen für jede Scriptsprache. Das bedeutet nicht, dass man in jeder Sprache munter drauflosschreiben kann, in der Hoffnung, dass eine der Engines es schon verstehen wird. Vielmehr ist es möglich, jede Scriptsprache einzusetzen, für die eine Scripting Engine erhältlich ist. Bisher stellt Microsoft je einen „abgespeckten“ und speziell auf die Anforderungen von Windows zugeschnittenen Dialekt von Visual Basic und Java, VBScript und JScript zur Verfügung. Fremdanbieter arbeiten an eigenen Script Engines wie z.B. PerlScript [vgl PerlScript] oder Rexx.
Die
Bibliotheken ermöglichen sowohl den Scripten, wie auch anderen Anwendungen den
Zugriff auf Objekte, Methoden, Eigenschaften und Ereignisse. Man kann hierbei
zwischen drei Hauptkategorien unterscheiden:
In diesem Kapitel sollen konkrete Programmiertechniken und -konventionen des Windows Scripting Hosts gezeigt werden. Auf andere Hosts wie z.B. den Internet Explorer soll nicht näher eingegangen werden, da es bei Beherrschung der Scriptsprache keinen großen Unterschied macht, auf welchem Host das Script ablaufen soll. Bei einfachen Scripts ist oftmals nicht mal eine Anpassung nötig.
3.1 Vorraussetzungen und Entwicklungswerkzeuge
Um mit dem WSH arbeiten zu können, muss er zunächst installiert werden. Seit Windows 98 gehört er zum Lieferungsumfang und kann somit per Windows- Setup hinzugefügt werden. Um unter Windows 95/NT den WSH nutzen zu können, muss er von den Microsoft Seiten [MS 2] heruntergeladen und installiert werden. Ist der WSH installiert, genügt ein Doppelklick auf das gewünschte Script, um es auszuführen. Ein Aufruf per Kommandozeile ist mittels „wscript“ (Windows) bzw. „cscript“ (MS-DOS- Eingabeaufforderung) gefolgt vom Dateinamen des auszuführenden Scripts möglich.
Zur Programmierung des Windows Scripting Hosts genügt ein einfacher Texteditor, der Textdateien im ASCII- Format speichern kann. Solche Editoren gibt es zur Genüge und in den verschiedensten Ausführungen, einen sehr einfachen [Editor] bringt jede Windows Version mit sich. Es ist sehr wichtig, dass die Scriptdateien die richtige Dateiendung haben, da der WSH anhand der Dateiendung erkennt an welche Script Engine er sich wenden muss z.b. „.vbs“, wenn die Datei VBScript enthält und „.js“, wenn sie JScript beinhaltet.
Da
Microsoft bisher noch keine Entwicklungsumgebung à la Visual Studio für den
WSH vertreibt, steht man beim Suchen der richtigen Objekte, Methoden und
Eigenschaften, bzw. beim Testen der Scripte ziemlich alleine da. Dennoch kann
man sich die Entwicklungsarbeit deutlich vereinfachen, indem man einen Editor
einsetzt, der über eine Zeilennummerierung verfügt, da der WSH bei Fehlern im
Script nur die Zeilen- und Spaltennummer über eine Dialogbox ausgibt. Ein
hervorragendes Produkt stellt hierfür der M&I WinEditor [M&I] dar, da
er über eine Zeilennummerierung verfügt und den WSH direkt aus dem Editor
heraus aufrufen und das aktuelle Script als Parameter übergeben kann.
Bei der äußerst nervenaufreibenden
Suche nach den richtigen Objekten hilft einem der Objektkatalog auf den man über
den Visual Basic für Applikationen (VBA)- Editor der MS-Office Programme
Zugriff hat. Er listet alle auf dem jeweiligen Computer registrierten Objekte,
deren Methoden und Eigenschaften übersichtlich auf. Microsoft Word (ab Version
97) bietet einige Funktionen, u.a. auch eine Zeilennummerierung, die das Scripte
schreiben deutlich vereinfacht.
Wer
noch etwas mehr Komfort bei der Code- Eingabe bzw. über keine VBA- Anwendung
verfügt, kann auf Visual Basic 5 CCE (Control Creation Edition) [MS 3] von
Microsoft zurückgreifen. Dies ist im Grunde eine komplette Visual Basic 5
Entwicklungsumgebung, bei der lediglich die Funktion zum Erstellen von EXE-
Dateien deaktiviert wurde.
Innerhalb der Windows Scripting Architektur werden die Script Sprachen Script Engines genannt (vgl. 2.2). Vom Microsoft Server [MS 4] lassen sich zwei Script Engines kostenlos herunterladen und installieren – VBScript und JScript. Mit diesen beiden Engines deckt Microsoft die beiden größten „Entwicklerlager“ VB und Java ab. Wobei VB mittlerweile zur Standardsprache im Microsoft- Umfeld erkoren wurde.
Nicht nur alleine die Tatsache, dass VB die „Haus- und Hofsprache von Microsoft ist und stark gepuscht wird, auch die leichte Erlernbarkeit und die fehlertolerante Eingabemöglichkeiten haben zum großen Erfolg der Sprache geführt. Wer bereits mit VB oder VBA gearbeitet hat, wird sich sofort mit VBScript zurechtfinden. Aus dem VB- Funktionsumfang wurden lediglich einige für den Internetbereich uninteressante Komponenten entfernt. Das Programmieren in VBScript ist sehr einfach, so dass auch Neulinge schnell zu einem erfolgreichen Ergebnis kommen.
Wer Netscapes JavaScript beherrscht, kann im Grunde sofort funktionierende WSH- Scripte schreiben, da ECMA 262 Script [ECMA] und damit JavaScript als Grundlage für Microsofts JScript diente. Microsoft hat lediglich einige Netscape- spezifischen Befehle bei der Implementierung „übersehen“ und dafür den Funktionsumfang in Richtung des Internet Explorers erweitert. Bei der Codeeingabe lässt JScript jedoch nicht so viele Freiheiten wie VBScript, da die Syntax sehr stark an C angelehnt ist, sind z.B. mehr Deklarationen und mehr Aufmerksamkeit (Groß- Kleinschreibung) bei der Eingabe nötig, um fehlerfreie Scripts zu schreiben.
4 Objekte, Methoden und Eigenschaften des WSH
Der Windows Scripting Host selbst stellt verschiedene Methoden und Objekte für die Scriptprogrammierung zur Verfügung. In diesem Kapitel soll ein Ausschnitt vorgestellt und erläutert werden. Hierbei werden Beispiele ausschließlich in VBScript genannt, da meiner Ansicht nach JScripts auf den ersten Blick verwirrend wirken und die wesentlichen Punkte sich so schlechter erkennen lassen.
Die wohl einfachste Möglichkeit dem Benutzer etwas mitzuteilen ist die (von DOS bekannte) Echo- Methode. Diese Methode lässt sich direkt über den WSH ansprechen. Da das WScript Objekt den WSH repräsentiert, genügt somit ein Doppelklick auf eine Textdatei mit der Dateiendung „.vbs“ und dem Inhalt:
WScript.Echo "Script- Programmierung ist total einfach!"
und auf dem Bildschirm erscheint folgendes Fenster:
Über die fehlenden Gestaltungsmöglichkeiten der Echo- Methode verfügt die aus VB und VBA bekannte Methode MsgBox. Mittels der Methode- Parameter kann man nicht nur den Titel des Fensters, sondern auch das Symbol bestimmen, welches links neben dem Text und den gewünschten Buttons erscheint. Somit genügt die nachstehende Zeile Code, um dieses Fenster zu erzeugen:
MsgBox "Script- Programmierung ist total einfach!", vbInformation, "Wichtige Information!"
Auf den ersten Blick bietet der WSH kaum Möglichkeiten für Benutzereingaben. Man kann zwar eine einfache Programmablaufsteuerung realisieren, in dem man den Rückgabewert der MsgBoxen auswertet, jedoch lässt sich damit z.B. kein String abfragen.
Um den Rückgabewert abfragen zu können, genügt es, eine Variable und ein „=“ vor die MsgBox- Methode zu schreiben. Wichtig ist hierbei nur, dass die Parameter der Methode jetzt in Klammern stehen müssen, sonst kann der WSH die Zeile nicht interpretieren.
erg
= MsgBox("Ist Script- Programmierung total einfach?", vbQuestion +
vbYesNo, "Frage")
if erg = vbYes then WScript.Echo "Richtig :-)" else WScript.Echo
"Blödsinn!"
Dieses Script bittet den Benutzer um seine Meinung zur Scriptprogrammierung und kommentiert anschließend dessen Angaben.
In VBScript lässt sich aber mit der InputBox- Methode eine deutlich komfortablere Eingabe realisieren. Das Aussehen des Eingabefenster lässt sich über die Parameter anpassen, zwingend erforderlich ist jedoch nur die Angabe des Textes, der im Dialogfeld angezeigt werden soll:
erg
= InputBox("Ist Script- Programmierung total einfach?", "Ihre
Meinung?")
if erg =
"" then WScript.Echo "Keine Meinung!" else WScript.Echo
"Ihre Meinung: " + erg
Die Methode liefert als Ergebnis die Eingabe des Benutzers oder einen leeren String beim Drücken des Abbrechen- Buttons.
4.3 Weitere Methoden und Eigenschaften
Der WSH besitzt außerdem Eigenschaften, die detaillierte Informationen über den WSH selbst, die benutzte Scripting Engine und das aktuelle Script Preis geben. So lässt sich z.B. durch einfaches Auslesen der Eigenschaft WScript.Version die Version des WSH ermitteln. Die Methode ScriptEngineMajorVersion() liefert die Hauptversion der Script Engine und die Eigenschaft WScript.FullName beinhaltet den kompletten Pfad des aktuellen Scripts. Die beiden wichtigsten Methoden, welche die WSH- Programmierung erst richtig interessant werden lassen, sind die Methoden WScript.CreateObject und WScript.GetObject. Mit Hilfe dieser beiden Methoden erhält man Zugriff auf sämtliche auf dem System befindlichen Bibliotheken incl. deren Klassen und damit auch deren Objekte. Das folgende Beispiel soll zum einen die Einfachheit und zum anderen die Mächtigkeit dieser Methoden widerspiegeln:
Set myExcel = CreateObject("Excel.Application")
Auf die mit CreateObject erzeugte Instanz erhält man nun über die Objektvariable myExcel Zugriff.
MsgBox "Der Pfad von Excel lautet:" + chr(13) + myExcel.Path, vbInformation
Mittels dieser Message Box wird der Anwendungspfad von Excel ausgegeben.
Mit der GetObject- Methode kann man sogar Objekte instanzieren, die nicht registriert, aber deren Pfade bekannt sind.
Eigentlich müsste der Beschreibung aller WSH- Objekte ein eigenes Kapitel gewidmet werden, doch um den Rahmen dieses Referates nicht zu sprengen, werden an dieser Stelle nur einige wenige Objekte vorgestellt. Anhand dieser Beispiele soll die Leistungsfähigkeit des WSH verdeutlicht werden.
WshShell
Eine Bearbeitung der Windows- Registrierung ermöglicht das WshShell- Objekt. Es stellt u.a. die Methoden RegRead (Auslesen eines Schlüssels oder Wertes), RegWrite (Erstellen/Verändern) und RegDelete (Löschen) zur Verfügung.
Shortcuts lassen sich mit dem WshShell- Objekt komfortabel erstellen, verändern und löschen. Eine der interessantesten Methoden ist die Run- Methode. Sie führt den als Parameter übergebenen Prozess bzw. die übergebene Anwendung in der gewünschten Fensterform (minimiert, maximiert, etc.) aus.
WshNetwork
Den Zugang
zu Netzwerkressourcen und - Informationen erhält man über das WshNetwork- Objekt. So lassen sich z.B. über die Eigenschaften ComputerName,
UserDomain und UserName den Namen
und die Domäne des Rechners und der Benutzername ermitteln.
Dass sich
der WSH auch hervorragend für administrative Aufgaben einsetzen lässt, zeigt
folgendes Beispiel: Mit nur zwei Zeilen VBScript kann man eine Druckerverbindung
zu einem Netzwerkdrucker anlegen.
Set
mjWshNw = WScript.CreateObject("WScript.Network")
mjWshNw.AddPrinterConnection "LPTPort",
"\\Rechnername\Drucker"
Die Vorgehensweise beim Zuweisen von Netzwerklaufwerken ist sehr ähnlich. Die Methode MapNetworkDrive erwartet als Parameter den gewünschten lokalen Laufwerksbuchstaben und die Netzwerkressource.
FileSystemObject
Hinter dem FileSystemObject versteckt sich ein komplettes Objektmodell mit mehreren Objekten, Methoden und Eigenschaften, die einen direkten Zugriff auf Laufwerke, Ordner und Dateien ermöglichen. Mit wenigen Zeilen lassen sich so Ordner und Dateien kopieren, verschieben und löschen, Dateiattribute verändern und Textdateiinhalte bearbeiten.
SendKeys
Diese Methode ist eine der mächtigsten, die dem WSH zur Verfügung stehen. Sie kann für viele programmübergreifende Aufgaben innerhalb eines Scripts genutzt werden. Mit SendKeys kann man jedem beliebigen Programm Tastatureingaben „vorgaukeln“ und ist somit nicht auf die VBA- Fähigkeit der fernzusteuernden Anwendung angewiesen. Das Rechner- Beispiel im Anhang zeigt dies anschaulich.
Mit
dem Windows Scripting Host stellt Microsoft endlich die sowohl von den
Entwicklern wie auch den Anwendern geforderte Automatisierungskomponente für
Windows- Betriebssysteme bereit. Trotz der hervorragenden Integration in die
bestehende COM- Architektur und der gigantischen Anwendungsvielfalt durch die
problemlose Nutzung aller Office (VBA)- Komponenten kann und wird sich der WSH
nicht durchsetzen, wenn Microsoft in die nächsten Versionen nicht einige
Verbesserungen einbaut.
Dies wäre
zum einen der gravierendste Nachteil, der fehlende Makrorekorder. Wenn dem
Anwender ein solches Programm zur Verfügung stehen würde, welches einfach alle
Aktionen des Benutzers in Scriptcode- Form festhält, eine „Nachbearbeitung“
zulässt und ihn dies dann beliebig oft abspielen lässt, wäre ein großer
Schritt in eine erfolgreiche Zukunft getan.
Der zweite
Grund, welcher sich erfolgshemmend auswirkt, ist die unbefriedigende
Dokumentation. Was nutzt dem Entwickler denn die Tatsache, dass er auf alle nur
möglichen Windows- und Office- Objekte Zugriff hat, er aber erst nach
(stunden-) langem Suchen die richtigen Bibliotheken, Objekt-, und Methodennamen
findet.
Dennoch
glaube ich, dass es eines Tages keinen Unterschied mehr macht, ob man innerhalb
einer Anwendung auf Betriebssystemebene oder in einer Entwicklungsumgebung
programmiert. Diese Umgebungen werden verschmelzen und der WSH ist zumindest ein
Schritt, wenn auch ein kleiner, in die richtige Richtung.