Windows Scripting Host 2.0

Microsoft is busy at work putting the finishing touches on Windows 2000 (Win2K). Similar to other parts of the OS, Windows Scripting Host (WSH) has undergone many improvements. The most significant enhancement is a new file type: the Windows Script (WS) file (with the filename extension .ws). The new file type supports the Extensible Markup Language (XML) and script. This month, I review the changes in WSH 2.0 and explain what you need to know to take advantage of WSH 2.0.

WSH 2.0 includes several new features and improvements: include-file support, multiple script-engine support, tools support, external-constant access, new runtime options, WSH object-model enhancements, and drag-and-drop support. Many of the WSH 2.0 enhancements rely on the XML elements that are part of the new WS file format. Let's look at the XML elements and the WS file in relation to the features in WSH 2.0.

Include Files
Include files provide a simple way to package (in a separate physical file) code that you reuse frequently in other WS scripts. Include files let you create script libraries so that you don't have to recreate identical code in every script you develop.

For example, suppose you have a collection of functions that you commonly use in scripts. Library.vbs in Listing 1, page 168, is a script library that contains a string variable (strMyString), a constant (MY_CONSTANT), and a couple of simple functions (NetworkInfo and ScriptInfo). The strMyString variable contains the text "Includes Rock!", MY_CONSTANT contains the integer value 123, and the two functions return strings. The NetworkInfo function returns information obtained from the properties that the Network object provides, and the ScriptInfo function returns information obtained from the properties that the WScript object exposes.

To access the variables and functions that library.vbs defines, you simply include library.vbs using the XML <script> element and src attribute, as callout A in Listing 2, page 168, shows. The trailing slash (appropriately named the empty-element tag) following the src attribute isn't a typographical error but a shorthand way to specify an XML end tag for empty elements. You can omit the slash and close the <script> element and src attribute by appending the end tag, as callout B in Listing 2 shows.

You can name your common library files whatever you want, and you can specify a Uniform Naming Convention (UNC) path for the src attribute to access include files remotely. To run include.ws, place Listing 1 and Listing 2 in the same working directory and run include.ws from the Win2K command prompt (e.g., C:\tmp> cscript include.ws). If you have WSH 2.0, you'll get the result that Screen 1, page 169, shows.

If you examine include.ws, you'll see that the script consists of a statement that echoes the values of the constant and string variable that library.vbs defines. In addition, the echo statement calls the ScriptInfo function that library.vbs defines. Because ScriptInfo returns a string, the echo statement happily echoes the function's return value.

Only the new XML-based WS file type supports include files. However, to turn your existing VBScript (.vbs), JScript (.js), or other ActiveX script source files into WS files, you need to only add two XML elements and change the file extension.

Multiple Script Engines
Multiple script engine support is a powerful feature that lets you develop one script that uses multiple languages. Why is such a script useful? Let's suppose that you develop all your systems administration scripts in VBScript. You're in desperate need of a particular routine that your company's intranet development team has written. The trouble is that the intranet team wrote the routine in JScript. Using WSH 2.0, you have no worries. You simply copy the JScript routine into your WS file, enclose the routine in the appropriate XML elements, and away you go.

Listing 3, page 168, is a simple script that shows how you can incorporate JScript and VBScript routines into one WS file. Mse.ws uses a JScript routine to create a desktop shortcut to Notepad, then uses a VBScript routine to delete the shortcut 10 seconds later.

Mse.ws begins with the two XML elements you need to create a WS file: and <script>. The first script block is in JScript, so you set the <script> element's language attribute equal to "JScript", as callout A in Listing 3 shows. The JScript code that follows creates a WSH Shell object, calls the Shell's CreateShortcut method to create a Shortcut object, sets the shortcut's properties, and saves the shortcut to the desktop. Then, the XML end-of-script block element closes the JScript block.

Because the second script block is in VBScript, you specify a new script block element and set the language attribute equal to "VBScript", as callout B in Listing 3 shows. Notice that the first statement in the VBScript block calls the Shell object's Popup method using the oShell object created in the JScript block. The Popup-generated dialog box informs the user that the script is preparing to delete the previously created shortcut. After the Popup method's 10-second timeout value expires, the method dismisses the dialog box and the script deletes the shortcut. Then, I use the FileSystemObject to delete the shortcut because the Shortcut object doesn't provide a built-in delete method.

The mechanics behind the WS's ability to use JScript and VBScript routines is quite simple. Recall that the WS file is an XML file. As such, the XML parser first parses the script. As the XML parser encounters script blocks, the parser passes the blocks of script to the appropriate interpreter based on what language attribute you set the XML <script> element to. For WS files, the design makes jumping between ActiveX scripting engines easy. And as mse.ws demonstrates with the oShell and strDesktopPath variables, you can share common variables between the different languages.