XML-based Windows Script files belong in your toolbox
In "Extensible Markup Language," April 2000, I introduced the new XML-based Windows Script (WS) files, which Microsoft Windows Script Host (WSH) 2.0 registers with a .wsf extension. I examined the WS files' XML schema and each element's syntax, definition, and usage. Now let's look at the new capabilities and benefits that WS files provide and put this knowledge to work.
WSH 2.0 Features
Before I dive into the code, let's recap several WSH 2.0 features. The XML-based WS files provide the following top WSH 2.0 capabilities.
Include file support. The include file capability lets you place commonly used code in a separate file or files, then reference the file (or files) in other scripts. The separate file's code becomes available to the script that contains the include directive. The <script> element's optional src attribute (src="filename") is the include enabler.
External constants support. WSH 2.0 uses the <reference> element to support external constants. This feature lets you use mnemonic constants defined in objects outside the script engine. For example, you no longer need to redefine constants that ActiveX Data Objects (ADO), the FileSystemObject, and Windows Management Instrumentation (WMI) already define.
Multiple languages support. WSH 2.0 provides support for multiple languages so that you can use several languages inside one WS file. The <script> element's mandatory language attribute makes switching between languages possible. For example, inside a WS file, you can write part of one job in JScript and write the other part of the job in VBScript. Also, you can pass variables that include object references across code boundaries.
The <object> element. WSH 2.0 lets you use the <object> element to create objects. The <object> element performs the same task that the WScript, VBScript, and JScript CreateObject, GetObject, and new ActiveXObject methods do.
Jobs. Jobs let you partition a WS file into autonomous self-contained work units. You use the <job> element's id attribute to give a unique name to each job in the file, and you use the new //job:jobid option to identify the job to execute at runtime. For example, you might use the jobs feature to divide your WS file into discrete tasks in which each job represents a primary script capability.
Tools support. The development tool enhancements let WS files leverage the IntelliSense and syntax-coloring features in Microsoft Visual InterDev 6.0 Service Pack 3 (SP3) and the Microsoft Office 2000 Script Editor. (For information about how to enable IntelliSense and syntax coloring in Visual InterDev, see the Microsoft article "HOWTO: Enable Windows Script Version Tools Support for Visual InterDev" at http://support.microsoft.com/support/kb/articles/q249/0/24.asp.)
Eventlog.wsf
Let's now examine a script that demonstrates an XML-based file's capabilities. Eventlog.wsf is a WSH 2.0 script that leverages the WMI Scripting API to search Windows 2000 (Win2K) event logs. (To make eventlog.wsf work with Windows NT, you need to run NT 4.0 with SP4 or later and download and install WMI Core 1.50 or later from http://msdn.microsoft.com/downloads/sdks/wmi/download.asp.) Eventlog.wsf uses WMI's Event Log provider and query language to produce a console-oriented utility that you can use to search for specific event records in Win2K's six event logs. (For more information about WMI, see Mark Russinovich, Internals, "Inside Windows Management Interface," February 2000.)
The script is easy to use and provides detailed instructions, which Screen 1, page 180, shows, when you provide a question mark (?) as the first argument. The script also includes a set of default values; therefore, eventlog.wsf will perform meaningful operations whether or not you provide command-line arguments to the script at runtime.
All the script's arguments are optional. When you don't specify arguments, eventlog.wsf searches for and echoes all events in the local computer's Application log. You can specify one or more arguments to control the script's search behavior and identify the target log file, event source, event type, event id, and target computer. For example, if you wanted to search the System log for DCOM errors with an id of 10006 on a remote computer named dell610, you'd enter the command line that appears toward the bottom of Screen 1.
The Notes at the bottom of the usage text in Screen 1 provide additional instructions about how to use the script. The Notes say you must use the console-based host, cscript.exe, to run eventlog.wsf. The cscript.exe requirement is mandatory because eventlog.wsf writes its search results to STDOUT. You can use WScript's STDIO properties, which include STDOUT, only in console-based scripts. You don't want to use WScript's Echo method because you might receive hundreds of pop-up windows if you inadvertently use the Windows-based host to run the script. You also need to use double quotes to enclose values containing spaces. For example, when you want to search the local domain controller's Directory Service (DS) log for all errors, enter the following command:
C:\> eventlog.wsf l="directory service" t=error
In this example, I don't specify cscript.exe on the command line. You can omit the host if you use the //h:host option to configure cscript.exe as the default host. If cscript.exe isn't the default host, eventlog.wsf will fail because the script depends on the console-based host. Also, this command doesn't contain the //job:xxxx option. When you don't define a job at runtime, WSH 2.0 runs the first job in the package, which is the Search job in eventlog.wsf.