Ralf Hüskes

Windows an der Leine

Windows-Skripte: Nachfolger für Batch-Dateien?

Was für andere Betriebssysteme wie Unix und den Mac selbstverständlich ist, läßt Windows bisher missen: eine Möglichkeit, Routine-Jobs zu automatisieren - eine Skript-Sprache. Mit dem `Windows Scripting Host´ sollen die Batch-Dateien aus der DOS-Steinzeit jetzt einen ehrwürdigen Nachfolger erhalten.

Unterthema: Windows-Kontextmenü erweitern
Unterthema: Listing 1
Unterthema: Listing 2
Unterthema: Listing 3
Unterthema: Windows-Skript-Architektur
Unterthema: Skriptbare Bibliotheken im Überblick

Mancher mag es nicht mehr hören wollen, aber der Macintosh gilt als bestens gerüstet und Unix als unbestrittenes Eldorado für Skripte. Und noch viele andere Betriebssysteme bringen Mittel und Wege gleich mit, Routineaufgaben als Skript zusammenzufassen, also letztlich zu automatisieren. Bloß im aktuellen Windows klafft seit dem Ableben des Windows-Makro-Recorders eine riesige Lücke, wenn der Rechner Routineaufgaben selbst erledigen soll.

Daß die Batch-Dateien aus der DOS-Steinzeit keine Lösung sein können, hat auch Microsoft eingesehen. Mit dem `Windows Scripting Host´ (WSH) will man die gravierende Lücke schließen. Durch die nun greifbare Lösung ist ein Ausflug in Microsofts Skript-Gefilde angebracht. Es hat den Anschein, als nähere man sich an das an, was dem aktuellen Macintosh als AppleScript seit Jahren innewohnt - eine Skript-Sprache, die dort natürlich die grafische Bedienoberfläche vollends erfaßt.

Die Entwicklung ist noch keineswegs abgeschlossen. Den Scripting Host will Microsoft als Komponente sowohl in Windows 98 als auch NT 5.0 integrieren. Für Windows 95 und NT 4.0 liegt diese Komponente als Nachrüstsatz auf dem Microsoft Web-Server bereit [1]. Sie birgt zwei Sprachdialekte mit VBScript und JScript. Anhand dieses Nachrüstsatzes kann jeder ausprobieren, wohin der Skript-Zug unter Windows fährt.

Wem wegen Internet-Abstinenz und einer Basic-Allergie weder VBScript noch JScript untergekommen sind: Es handelt sich um ausgewachsene Sprachen, die über die gebräuchlichen Datentypen und Konstrukte verfügen. VBScript ist ein Ableger des Haus- und Hofdialektes Visual Basic und JScript die Interpretation Microsofts von JavaScript. Beide zeichnet die Fähigkeit aus, auch mit den Methoden und Eigenschaften externer Objekte umgehen zu können.

Keine Insel

Windows-Skripte fügen sich nahtlos in Microsofts Strategie der Komponenten und der Zusammenarbeit von Anwendungen ein: Eigentlich benutzen Skripte bereits vorhandene Schnittstellen des Component Object Model (COM), um Anwendungen zu automatisieren (früher OLE-Automation). Darüber hinaus hat Microsoft das COM-Schnittstellensortiment so ergänzt, daß sich beliebige mit Skripten befaßte Komponenten ins System integrieren lassen (siehe Kasten Windows-Skript-Architektur).

Aber daraus ergibt sich zugleich die größte Einschränkung: Im Gegensatz zum betagten Makro-Recorder und den für AppleScript relevanten AppleEvents fußen die zukünftigen Windows-Skripte nicht auf der ereignisorientierten grafischen Bedienoberfläche, sondern auf speziellen COM-Schnittstellen. Das verursacht auf Entwicklerseite einen erheblichen Mehraufwand bei der Implementierung. Und aufgrund dieser Tatsache fehlt ein dem Makro-Recorder vergleichbares Werkzeug.

Zur ganzen Wahrheit gehört auch, daß ein Teil der Skript-Fähigkeiten gar nicht neu ist, sondern schon längst Bestandteil aller Internet-Techniken Microsofts. Während der Scripting Host noch unbekannt ist, erfreut sich die zugehörige Basistechnik bereits großer Beliebtheit: Die eigentlichen Interpreter kommen bereits seit der Version 3.0 des Internet Explorer zum Einsatz, sofern eine Web-Seite JScript- oder VBScript-Code enthält.

Der Internet Explorer steuert die Sprachmodule zum Ausführen der Skripte nicht einmal selbst bei, sondern greift dafür auf im Betriebssystem universell verankerte Teile zu - oder anders gesagt: Die Installation des Browsers unternimmt in diesem Fall ein gar nicht so kleines Betriebssystem-Update, das unter anderem einen universell einsetzbaren Programminterpreter enthält.

Der Interpreter werkelt nicht nur in den Microsoft-Browsern (3.0 und 4.0), sondern kommt auch in den Active Server Pages (ASP) zum Einsatz - Microsofts Entgegnung zu CGI-Skripten. Der Windows Scripting Host, jener Komponente, die den Batch-Dateien den Garaus machen soll, ist so nur das letzte Glied in einer Kette. Er stellt letztlich eine andere Darreichungsform für `ohnehin´ vorhandene Funktionen dar.

Theoretisch bringt der Scripting Host alles mit, was fürs Ausführen von Skripten notwendig ist. In der Praxis jedoch ist es von Vorteil, wenn auf dem jeweiligen System eine aktuelle Version des Internet Explorer bereits installiert ist. Je nach Ausgangssituation kommt es beim Einrichten des Hosts zu Fehlermeldungen. Und: Die HTML-basierten Online-Hilfen zum eigentlichen Host und den Interpretersprachen lassen sich vernünftig ohnehin nur mit dem Web-Browser von Microsoft einsehen ...

Puzzlespiel

Microsoft hat in der Skript-Architektur nicht nur die Interpreter modular, also um andere Sprachen ergänzbar, angelegt, sondern auch die in Skripten benutzbaren Laufzeitbibliotheken. Einige Bibliotheken sind im WSH enthalten, andere muß man zusätzlich installieren. Wie bereits erwähnt, dienen sich die Bibliotheken über die Schnittstellen für COM-Automation den Skripten an.

Ein Grundstock von Funktionen respektive Objekten ist in einem Skript nutzbar, ohne daß das übliche Vorgeplänkel für Automation (`CreateObject´ et cetera) stattzufinden hat. Der Scripting Host erweitert den Sprachhorizont, indem er von sich aus einige Standardobjekte in den Namensraum der Sprache integriert, zum Beispiel eine Methode, um einfache Ausgaberoutinen aufzurufen.

Doch die offene und vielseitige Architektur hat ihre Schattenseiten: Gerade wer sich in die Möglichkeiten des Scripting Host einarbeiten möchte, verbringt einen Großteil der Zeit mit der Suche nach passender Dokumentation. Eine zentrale Anlaufstelle dafür gibt es leider nicht. Zum Scripting Host selbst gehört nur eine kleine Bibliothek, die Zugriffe auf Netzwerkobjekte und die Windows-Oberfläche (Shell) gestattet.

Viele Objekte, zum Beispiel für Dateizugriffe, String- und Fehlerbehandlung, sind nicht in der Dokumentation zum WSH beschrieben, sondern werden in den Informationen zur Laufzeitbibliothek des jeweiligen Interpreters dokumentiert. Außer der Dokumentation zum Scripting Host selbst braucht man also mindestens die zur jeweiligen Sprache (etwa die zu VBScript). Wer sich mit dem Steuern von Applikationen via Automation befaßt, fällt gleich ins nächste Loch. Hier ist brauchbare Dokumentation noch ein rares Gut.

Zunehmend interessant und deutlich besser dokumentiert sind dagegen diverse Toolboxen mit Automation-Schnittstelle. Microsoft selbst bietet beispielsweise eine solche für die Active Directories, das Herzstück der Systemverwaltung des zukünftigen Windows NT 5.0, und die Datenbankbibliothek Active Data Objects an. Dritthersteller liefern bereits Module zum Aufbau von Socket-Verbindungen, zum ftp-Transfer, zum Versand von EMail sowie zum Generieren von Grafiken.

Aber genug der Theorie. Trotz des Puzzlespieles vor dem Start ist das erste (VBScript-)Programm schnell geschrieben. Das einfachste Skript lautet

WScript.Echo "Hello World!"

und gibt die klassische Meldung aus. Es verwendet das Objekt WScript, das der WSH direkt zur Verfügung stellt und das als Wurzelobjekt für jedwede Aktionen dient. Unter anderem stellt WScript die Methode `Echo´ zur Verfügung, um Meldungen auszugeben.

Starten lassen sich Skripte direkt auf der Kommandozeile oder von der grafischen Bedienoberfläche, wenn man der Datei eine von Windows mit dem WSH assoziierte Extension (.VBS oder .JS) zuweist. Alternativ kann man die Ausführungsgehilfen `wscript´ oder `cscript´ benutzen. Je nachdem, ob das Skript via Kommandozeile (cscript) oder auf der Oberfläche (wscript) ausgeführt wird, zeigt Windows die Meldung als Dialogbox oder als klassische Ausgabe auf `stdout´ an.

Der im Hello-World-Programm zu findende `objektbasierte´ Ansatz zieht sich als roter Faden durch die Arbeit mit Skripten. Der Scripting Host umfaßt kaum eine gewöhnliche Funktion, sondern präsentiert seine Programmierschnittstellen in Form von Objekten, die dann ihrerseits allerhand Methoden zur Verfügung stellen.

Ähnlich kurz fällt das Programm NewFolder aus. Es ist als Erweiterung für die Windows-Bedienoberfläche gedacht und läßt sich dort so registrieren, daß es über einen entsprechenden Menüpunkt im Kontext-Menü von Dateiordnern erscheint (die Details dazu enthält der Kasten `Windows-Kontextmenü erweitern´). Das Programm an sich ist schnell erklärt: Es öffnet über die Anweisung

Fname = InputBox ("Neuer Verzeichnisname")

eine Mini-Dialogbox zur Eingabe des neuen Ordnernamens und legt diesen in der Variablen Fname ab. Anschließend erzeugt es über den Aufruf

Set System = WScript.CreateObject("Scripting.FileSystemObject")

ein Dateisystem-Objekt, mit dessen Hilfe es den neuen Ordner erzeugt:

System.CreateFolder WScript.Arguments(0) & "\" & Fname

Im Ausdruck WScript.Arguments(0) spiegelt sich das erste via Kommandozeile an das Skript übergebene Argument wider (das kaufmännische Und verknüpft zwei Strings). Auf welche Weise dieses Argument an das Skript übergeben wird, steht ebenfalls im Kasten. Der Vollständigkeit halber seien noch die Befehle

Option Explicit

sowie

Dim System 
Dim Fname

zu Anfang des Skriptes (Seite 313) erläutert. `Option Explicit´ sorgt dafür, daß alle Variablen im Skript explizit definiert werden müssen, sozusagen ein Zwang zur Programmierdisziplin (VBScript fordert diese nicht). Das ist wichtig, um durch Tippfehler verursachte Unannehmlichkeiten zu vermeiden. Die beiden folgenden Zeilen definieren dann explizit die verwendeten Variablen.

Menüpunkt

Für Eingriffe in die benutzerspezifische Konfiguration der Bedienoberfläche stehen Skripten diverse Türen offen. So verursacht es nur geringen Aufwand, das Startmenü um einen neuen Eintrag zu ergänzen. Der erste Schritt besteht darin, ein sogenanntes Shell-Objekt zu generieren:

Set Shell = WScript.CreateObject("WScript.Shell")

Wie der Name des Objektes bereits andeutet, gewährt es Zugriff auf die Windows-Bedienoberfläche (Shell). Das Shell-Objekt enthält unter anderem eine Liste mit sogenannten Special-Folders, in der sich ein Eintrag `StartMenu´ findet, der den absoluten Pfad zum Startmenü verrät. Diesen Pfad liefert die Anweisung

Menu = Shell.SpecialFolders("StartMenu")

in der Variablen Menu. Der anschließende Aufruf

Set MenuItem = Shell.CreateShortcut( Menu & "\My Tiny Programm.lnk")

erzeugt in diesem Verzeichnis die gewünschte Verknüpfung (Shortcut), den Windows als Menüpunkt anzeigt. Nun setzt

MenuItem.TargetPath = "C:\tiny.exe"

den Pfad des zugehörigen Programmes und

MenuItem.WorkingDirectory = "C:\Programme\tiny"

ändert dessen Arbeitsverzeichnis. Schließlich gilt es, den neuen Menüpunkt über

MenuItem.Save

zu speichern.

Registry mit Mausklick

Die integrierten Fähigkeiten des WSH erstrecken sich auch auf Eingriffe an der Registrierung. Das ToggleButton-Skript installiert sich selbst, indem es eine Verknüpfung auf dem Desktop erzeugt, die auf das Skript selbst verweist. Bei jedem Aufruf seiner selbst ändert es einen (privaten) Wert in der Registrierung. Um den Zustand des jeweiligen Schlüssels zu visualisieren, ändert es zugleich jedesmal das Icon der Verknüpfung. Es entsteht der Eindruck eines Schalters.

Wie das Beispiel Menu erzeugt auch ToggleButton zunächst ein Shell-Objekt:

Set Shell = WScript.CreateObject("WScript.Shell")

Über die Liste SpecialFolder ermittelt das Skript den absoluten Pfad zum Desktop und erzeugt dort einen Shortcut namens `schalter´:

Desktop = Shell.SpecialFolders("Desktop") 
Set ToggleButton = Shell.CreateShortcut( Desktop & "\Schalter.lnk")

Darin trägt es sich selbst über

ToggleButton.TargetPath = Wscript.ScriptFullName

als zugehöriges Programm ein.

Mit

Shell.RegRead("HKCU\test")

liest das Skript den aktuellen Registry-Wert, um ihn anschließend über

Shell.RegWrite "HKCU\test", NeuerWert

zu invertieren. Gleichzeitig tauscht es über

ToggleButton.IconLocation = "toggle.dll,99"
ToggleButton.Save

das Icon des Shortcut aus und sichert die neuen Informationen für die Verknüpfung. (Die DLL finden Sie bei den Listings zum aktuellen Heft in der Mailbox oder auf dem ftp-Server; die Datei `toggle.dll´ enthält zwei Icons, die angegebene Nummer verweist auf eines der Icons). Ein Hinweis zu diesem Beispiel noch: Der Scripting Host kann zwar in der Registrierung Schlüssel anlegen, das Beispiel liest aber zuerst. Das heißt, das Anlegen muß man hier manuell via regedit erledigen, damit das Beispiel funktioniert.

Haken und Ösen

Die Beispiele unterstreichen, worauf Microsofts Entwicklung derzeit vor allem abhebt: eine programmgesteuerte Manipulation der Bedienoberfläche. Die ist wichtig, um zukünftige Windows-Versionen besser wartbar zu gestalten, zum Beispiel um netzwerkweit bestimmte Installationsvorgänge zu vereinfachen. Der schlichte Anwender, der lediglich seine Office-Applikationen automatisieren möchte, ist hingegen mit den eingebauten Skript-Sprachen der Anwendungspakete besser bedient, zumal diese in der Regel über halbwegs brauchbare Makro-Recorder verfügen.

Wohl auch nur dem erfahrenen Anwender zuzumuten ist die verstreut auf dem Microsoft-Web-Server herumliegende Dokumentation. Der Windows Scripting Host bietet zwar allerlei Möglichkeiten, doch es fehlt schlicht und ergreifend an Beispielen, die verraten, was sich mit dem Windows Scripting Host alles anstellen läßt.

Wer viel mit Visual Basic hantiert, dürfte mit dem Windows Scripting Host noch die wenigsten Probleme haben. Er kennt den Umgang mit dem Objekt-Browser und findet sich notfalls auch alleine zurecht. Wer sich aber ohne VB-Lizenz eben mal einen Überblick verschaffen will, muß ein ganzes Sammelsurium von Dokumentationen durchforsten, und kann sich dennoch nicht sicher sein, ob er tatsächlich den besten Weg zur Lösung seines Problems gefunden hat.

Entschlüsselt - der Objekt-Browser von Visual Basic gewährt detaillierte Einblicke in die Bestandteile der Automation-Bibliotheken.

Auch die Scripting-Architektur an sich hat einige Sonderheiten. Wer bisher mit Skripten unter Unix oder mit den Batch-Dateien von DOS gearbeitet hat, muß sich gehörig umstellen: Während man in diesen Umgebungen verschiedene Skripte nach Belieben über `pipes´ aneinanderketten kann, gibt es unter dem Windows Scripting Host keinerlei Möglichkeit, die Ausgabe eines Skripts oder Programms in ein zweites Skript zu übernehmen, es sei denn, man wählt den Umweg über eine Datei.

Von der unter Unix anzutreffenden Universalität, die vor allem durch viele kleine Programme - jedes für seinen Zweck - eine modulare Welt mit unendlichen Variationsmöglichkeiten eröffnet, ist Windows weit entfernt. Auch wenn Microsoft die eigene DCOM-basierte Komponenten- und Objektwelt nach Kräften promotet - im aktuellen Windows ist nur ein kleiner Teil der Betriebssystem-Schnittstellen via COM-Automation erreichbar. Selbst für so simple Dinge wie das Verschicken von EMail kommt man ohne Hilfe Dritter nicht aus.

Konzepte zur Modularisierung von Skripten gibt es nicht. Früher oder später vermißt man beispielsweise eine Include-Anweisung, um vorgefertigte Funktionen in ein Skript aufzunehmen. Wer eine wiederverwertbare Komponente entwickeln möchte, muß das in Form einer ActiveX-Bibliothek mit gewöhnlichen Entwicklungssystemen à la Visual Basic Professional oder Delphi erledigen.

Der gegenüber AppleScript fehlende Makro-Recorder stellt vor allem Endanwender vor ein großes Problem. Die Latte der Einschränkungen mag Microsofts Haltung zum Windows Scripting Host erklären. Derzeit macht man - entgegen sonstigen Gepflogenheiten - keine Anstalten, offensiv für Windows-Skripte zu werben. Nur wer die Skript- beziehungsweise Management-Seiten auf Microsofts Web-Server durchstöbert, findet die entsprechenden Dateien.

In einigen Newsgroups entwickeln sich derweil interessante Diskussionen um das Thema, an denen sich auch mancher Microsoft-Mitarbeiter beteiligt. Doch wenn es um offizielle Aussagen geht, verweisen alle darauf, daß das Produkt noch nicht angekündigt ist und daß sich bis dahin noch einiges ändern kann. Mit einem weitgehend via COM-Automation steuerbaren Betriebssystem sowie einigen Anleihen bei Visual Basic für einen passenden Editor wäre das Skript-Problem unter Windows jedenfalls schnell gelöst. (ps)

Literatur

[1] http://www.microsoft.com/management/wsh.htm

[2] http://www.microsoft.com/scripting

Kasten 1

Windows-Kontextmenü erweitern

Windows 95 und NT 4.0 bieten eine einfache Möglichkeit zum Erweitern der Kontextmenüs, die bei einem rechten Mausklick auf ein Icon erscheinen. Für jede bekannte Datei-Extension kann Windows mehrere darauf anwendbare Vorgänge registrieren, die es im Kontextmenü aufführt.

Der Dialog Optionen des Explorers (zu finden im Ansicht-Menü unter Optionen) listet alle verfügbaren Dokumenttypen auf.

Standardmäßig sind für die meisten Extentions lediglich die Vorgänge `open´ und `print´ definiert, teilweise auch noch ein Vorgang `edit´. Die Screenshots demonstrieren, wie für den Dokumenttyp Ordner ein zusätzlicher Vorgang `Neu´ definiert und dieser dem Programmaufruf

wscript.exe c:\Scripte\NewFolder.vbs "%1"

zugeordnet wird. Das zugehörige Skript (siehe Listing NewFolder) fragt nach einem Namen für einen neuen Unterordner und erzeugt diesen anschließend. Den Platzhalter %1 ersetzt Windows beim Aufruf durch den Namen des ausgewählten Dokumentes - in diesem Falle den Namen des selektierten Ordners.

Der Dialog `Dateityp bearbeiten´ verrät, welche Vorgänge mit dem Dateityp verbunden sind, sprich im Kontextmenü aufgeführt werden.

Kasten 2

Toggle: Die Registrierung steht für Skripte offen.

´ Explizite Definition von Variablen erzwingen
Option Explicit

´ Shell-Variable definieren
Dim Shell

´ Variable für Desktop definieren
Dim Desktop

´ Variable für Schalter definieren
Dim ToggleButton

´ WSH-Shell erzeugen
Set Shell = WScript.CreateObject("WScript.Shell")

´ Pfad für Start-Menü auslesen
Desktop = Shell.SpecialFolders("Desktop")

´ Menüeintrag erzeugen
Set ToggleButton = Shell.CreateShortcut( Desktop & "\Schalter.lnk")

´ Setzt Pfad auf sich selbst setzen
ToggleButton.TargetPath = Wscript.ScriptFullName

´ Prüfen welcher Wert der Registry-Schlüssel jetzt hat
If Shell.RegRead("HKCU\test") = "1" Then

	´ Registry-Wert umschalten
	Shell.RegWrite "HKCU\test", "2"

	´ Button umschalten
	ToggleButton.IconLocation = "toggle.dll, 99"
Else
	´ Registry-Wert umschalten
	Shell.RegWrite "HKCU\test", "1"

	´ Button umschalten
	ToggleButton.IconLocation = "toggle.dll, 98"
End If

´ Einstellungen von Button speichern
ToggleButton.Save

Kasten 3

Menu: Eingriffe in die Bedienoberfläche, zum Beispiel das Ergänzen eines Eintrags im Startmenü, sind auch kein Problem.

´ Explizite Definition von Variablen erzwingen
Option Explicit

´ Variable für Shell definieren
Dim Shell

´ Variable mit Pfad zum Startmenü definieren
Dim Menu

´ Variable für Menüeintrag definieren
Dim MenuItem

´ WSH-Shell erzeugen
Set Shell = WScript.CreateObject("WScript.Shell")

´ Pfad für Start-Menü auslesen
Menu = Shell.SpecialFolders("StartMenu")

´ Menüeintrag erzeugen
Set MenuItem = Shell.CreateShortcut( Menu & "\My Tiny Programm.lnk")

´ Programm-Pfad setzen
MenuItem.TargetPath = "C:\tiny.exe"

´ Arbeitsverzeichnis setzen
MenuItem.WorkingDirectory = "C:\Programme\tiny"

´ Menüpunkt abspeichern
MenuItem.Save

´ Abschlußmeldung ausgeben
WScript.Echo "Menu-Eintrag eingerichtet"

Kasten 4

NewFolder: Skripte können einfache Eingaben übernehmen und weiterverarbeiten.

´ Explizite Definition von Variablen erzwingen
Option Explicit

´ Variable für Shell definieren
Dim System

´ Varialbe für Folder-Name
Dim Fname

´ Neuen Folder-Name vom Benutzer erfragen
Fname = InputBox ("Neuer Verzeichnisname")

´ WSH-Shell erzeugen
Set System = WScript.CreateObject("Scripting.FileSystemObject")

´ Folder anlegen
System.CreateFolder WScript.Arguments(0) & "\" & Fname

Kasten 5

Windows-Skript-Architektur

Die von Microsoft entworfene Architektur zur Integration von Skripten weist drei wesentliche Kategorien austauschbarer Komponenten auf. Die Zusammenarbeit zwischen den Kategorien (Ebenen) erfolgt über COM-Schnittstellen. Komponenten auf einer Ebene sind erweiter- und austauschbar.

Die Basis bilden die verschiedenen Automatisierungs-Bibliotheken. Sie definieren Funktionen, Konstanten, Objekte, Methoden und Ereignisse, die andere Anwendungen und Skripte benutzen können. Grundsätzlich lassen sich drei Bibliothekarten unterscheiden: in sich geschlossene Programme à la Word, einzelne Steuerelemente (die im Internet umstrittenen ActiveX-Controls) sowie reine Code-Bibliotheken wie `ActiveX Data Objects´ (ADO). Während das Entwickeln eigener Bibliotheken unter C++ oder gar in C eine recht tüftlige Angelegenheit ist, bereitet es in Visual Basic oder Delphi mittlerweile keinerlei Probleme.

Die nächste Kategorie bilden Scripting-Engines, also die eigentlichen Sprachinterpreter. Microsoft selbst hat zwei Scripting-Engines im Angebot, eine für JScript und eine für VBScript. Es ist jedoch ohne Probleme möglich, eigene Engines für andere Programmiersprachen zu entwickeln. Perl wird als Favorit gehandelt, wenngleich wir die derzeit verfügbare Entwicklung (http://www.activestate.com) nicht zum Funktionieren überreden konnten.

Die dritte und letzte Ebene stellen sogenannte Scripting Hosts dar. Darunter versteht man die Anwendungen, in denen Skripte benutzt werden. Microsoft hat derzeit drei Anwendungen im Angebot: den Windows Scripting Host zur direkten Ausführung von Skripten unter Windows, den Internet Explorer sowie die Active Server Pages, zur serverseitigen Programmierung fürs Internet. Wer möchte, kann die Scripting-Engine jedoch auch in seinen Programmen nutzen und diese dadurch um eine `eigene´ Makrosprache erweitern.

Kasten 6

Skriptbare Bibliotheken im Überblick

Die Arbeit mit dem Windows Scripting Host wächst sich schnell zu einem Suchspiel aus. Für jede Bibliothek gibt es separate Dokumentation. Besonders beim Einarbeiten ist es nur schwer möglich zu entscheiden, welche Bibliothek welche Funktionen bietet. Die nachfolgende Tabelle soll daher einen ersten Überblick vermitteln. Doch Vorsicht: für einige Funktionen, beispielsweise im Bereich der Benutzerverwaltung, gibt es derzeit noch gar keine Bibliothek. Ändern soll sich das erst mit Windows 98 beziehungsweise NT 5.0.

VBScript-Laufzeitbibliothek Basis-Sprachkonstrukte, Datenkonvertierung, Datum/Uhrzeit, String-Behandlung, Fehlerbehandlung, Meldungs- und Eingabefelder, mathematische Grundfunktionen, Dateisystem, Dateizugriffe, Dictionary-Objekt (http://www.microsoft.com/vbscript/us/vbslang/vbstoc.htm)
WSH-Laufzeitbibliothek Shortcuts, Aufruf-Parameter, Environment-Variablen, Registry-Zugriffe und Benutzerangaben, Netzwerk, zum Beispiel Laufwerke und Drucker (http://www.microsoft.com/msdn/sdk/inetsdk/help/wsh/wobj.htm)
Remote Data Service Remote-Datenaustausch, zum Beispiel zwischen Client und Web-Server (http://www.microsoft.com/msdn/sdk/inetsdk/help/rds/ref01_26.htm)
ActiveX Data Objects Datenbank-Zugriffe (http://www.microsoft.com/msdn/sdk/inetsdk/help/ado/idx01_1.htm)
Schnittstellen für Microsoft Office 97 Hunderte von Objekten für Zugriffe auf VBA in Word, Excel und PowerPoint (Referenzhandbuch auf Office-CD, wird standardmäßig jedoch nicht installiert)
Internet-Explorer-Objekt Fernsteuern des Internet Explorer (http://www.microsoft.com/msdn/sdk/inetsdk/help/itt/EProg/WB/Objects/InternetExplorer.htm)
Dynamic HTML Object Model Zugriffe auf den Inhalt einer Web-Seite im Internet Explorer 4.0 (http://www.eu.microsoft.com/msdn/sdk/inetsdk/help/dhtml/references/dhtmlrefs.htm)

VBScript-Laufzeitbibliothek	Basis-Sprachkonstrukte, Datenkonvertierung, Datum/Uhrzeit, String-Behandlung, Fehlerbehandlung, Meldungs- und Eingabefelder, mathematische Grundfunktionen, Dateisystem, Dateizugriffe, Dictionary-Objekt (http://www.microsoft.com/vbscript/us/vbslang/vbstoc.htm)
WSH-Laufzeitbibliothek	Shortcuts, Aufruf-Parameter, Environment-Variablen, Registry-Zugriffe und Benutzerangaben, Netzwerk, zum Beispiel Laufwerke und Drucker (http://www.microsoft.com/msdn/sdk/inetsdk/help/wsh/wobj.htm)
Remote Data Service	Remote-Datenaustausch, zum Beispiel zwischen Client und Web-Server (http://www.microsoft.com/msdn/sdk/inetsdk/help/rds/ref01_26.htm)
ActiveX Data Objects	Datenbank-Zugriffe (http://www.microsoft.com/msdn/sdk/inetsdk/help/ado/idx01_1.htm)
Schnittstellen für Microsoft Office 97	Hunderte von Objekten für Zugriffe auf VBA in Word, Excel und PowerPoint (Referenzhandbuch auf Office-CD, wird standardmäßig jedoch nicht installiert)
Internet-Explorer-Objekt	Fernsteuern des Internet Explorer (http://www.microsoft.com/msdn/sdk/inetsdk/help/itt/EProg/WB/Objects/InternetExplorer.htm)
Dynamic HTML Object Model	Zugriffe auf den Inhalt einer Web-Seite im Internet Explorer 4.0 (http://www.eu.microsoft.com/msdn/sdk/inetsdk/help/dhtml/references/dhtmlrefs.htm)