NT Gains Scripting Muscle

If you administer or manage Windows NT networks, you'll want to know about Microsoft's Windows Scripting Host. WSH is Microsoft's new kid on the scripting block that offers more powerful capabilities than WSH's command-language, batch-file predecessor. In this article, I'll describe the architecture and components of WSH, explain how it works, and demonstrate its power with an example script.

WSH is more than just a language: WSH is a lightweight component object model (COM) scripting environment. The language is just one component of the script execution environment. Additional components include the objects you want your scripts to interact with or automate.

WSH provides improved systems administration capabilities through the use of the WSH Object Model. This runtime library includes objects, methods, and properties that you can use to map network drives or printers, retrieve and modify environment variables, create shortcuts, and read from and write to the Registry. You can use these functions to create logon scripts, configure users' desktops, create custom installation or configuration scripts, or perform other simple tasks. (For more information about using WSH, see Keith Pleas, "Windows Scripting Host in Action," February 1998.)

Although the built-in capabilities of WSH are useful, WSH's real power comes from its ability to use COM to call objects that expose automation interfaces. Microsoft calls this capability ActiveX Scripting. I'll show you an example script that exploits the power of WSH to access the services of Excel and the Active Directory Server Interfaces (ADSI). But first, let's look at how the WSH pieces fit together.

How WSH Works
Figure 1, page 204, is an architectural view of WSH. The WSH execution environment includes wscript.exe, a windows-based host; cscript.exe, a console-based host; and wshom.ocx, the WSH Object Model runtime library. WSH also includes two scripting engines: Microsoft JScript 3.0 (jscript.dll) and Microsoft VBScript 3.0 (vbscript.dll). Any optional Object Linking and Embedding (OLE) automation servers and your script source code (AddUsers.js and AddUsers.vbs in Figure 1) complete the picture. WSH uses the Registry to map scripts to the appropriate scripting engine.

Wscript.exe and cscript.exe provide the interface between a script source and a registered script engine (i.e., interpreter). The wscript.exe and cscript.exe hosts are language independent. You can write scripts in any language that is registered with WSH. When you double-click a filename with a .js, .vbs, or other registered extension, wscript.exe (the default execution host) executes the script by passing it to one of the registered script engines. WSH selects the appropriate script engine based on the script extension. This information is written to the HKEY_CLASSES_ROOT Registry hive during the script engine registration process. You can change the default execution host to cscript.exe, or you can specify the desired host via the Run dialog box or the command line at the time you invoke your script. For example, you can enter

c:\> cscript d:\source\scripts\wsh\myscript.js

or

c:\> wscript d:\source\scripts\wsh\yourscript.vbs

on the command line to specify the execution host you prefer.

Wscript.exe and cscript.exe also provide several runtime options, including an interactive or batch-mode switch and a maximum number of seconds that a script can run. Both hosts support interactive and batch modes. But cscript.exe's interactive mode uses a command-line interface and wscript.exe's interactive mode uses simple graphical dialog boxes; using either host in batch mode is easy.

To obtain a list of all supported options, at the command line, type

c:\> cscript

with no arguments, or type

c:\> wscript //?

(You use two slashes with all the WSH host options.)

The WSH Object Model is the runtime library that contains the objects and methods you need to create and control the script execution environment and perform administrative tasks. Table 1 lists the objects, methods, and properties the WSH Object Model provides. (You can find the complete WSH Programmer's Reference at http://www.microsoft.com/msdn/sdk/inetsdk/help/wsh/wobj.htm.) The WSH scripting engine creates the WScript object at the time you invoke your script; its methods and properties are immediately available. To use the additional WSH methods and properties, you must first create an object of type Shell or Network. For example, you can enter

set myShObj = Wscript.CreateObject("Wscript.Shell")

to create a Shell object, or type

set myNetObj = Wscript.CreateObject("Wscript.Network")

to create a Network object. When you obtain a reference to a Shell or Network object with the CreateObject Method, you can use the properties and methods these objects expose, as Table 1 outlines. In addition to the WSH objects, you'll also use the functions and language constructs of your preferred scripting engine (JScript, VBScript, or other third-party script engines) and any automation interfaces you call, such as ADSI, Excel, Internet Explorer, and OLE DB.

The scripting engines provide the language support you need to write scripts (e.g., variables, operators, control structures, and functions). The WSH scripting engines are COM based, which provides several important benefits: Third-party language developers can integrate their language into the WSH environment. Expect to see Perl-, Python-, Rexx-, and TCL-compatible scripting engines available soon. Also, software developers can implement and expose scripting capabilities in applications, and systems administrators can use the scripting language they're most comfortable with (provided a suitable WSH implementation exists).

Choosing between the two scripting engines Microsoft provides--JScript and VBScript--depends primarily on your environment. You can find complete language references and tutorials at http://www.microsoft.com/jscript and http://www.microsoft.com/vbscript.