Basic Information on Microsoft Windows Script Host

Microsoft Windows Script Host (WSH) is a language-independent scripting host for Windows Script-compatible scripting engines. It brings simple, powerful, and flexible scripting to the Windows 32-bit platform, allowing you to run scripts from both the Windows desktop and the command prompt.

Windows Script Host is ideal for non-interactive scripting needs such as logon scripting, administrative scripting, and machine automation.

The Benefits of Windows Script Host

Windows Script Host offers the following benefits:

• Two ways to run scripts, WScript.exe and CScript.exe. WScript.exe provides a Windows-based properties page for setting script properties; CScript.exe provides command-line switches for setting script properties.

• Support for multiple files. You can call multiple scripting engines and perform multiple jobs from a single Windows Script (WSF) file.

• Low memory requirements.

• Mapping of script extensions to programmatic identifiers (ProgIDs). When you start a script from the Windows desktop or the command prompt, the script host reads and passes the specified script file contents to the registered script engine. Instead of using the HTML SCRIPT tag to identify the script, the host uses file extensions; for example, VBS for Microsoft Visual Basic® Scripting Edition (VBScript) files, and JS for Microsoft JScript® files. The use of extensions means you no longer need to be familiar with the ProgID for a given script engine. Windows Script Host handles this for you by maintaining a mapping of script extensions to ProgIDs, launching the appropriate engine for a given script.

Windows XP includes the latest version of Windows Script Host—version 5.6.0 (Fig. 14.1). Versions of Windows Script Host implemented by Microsoft operating systems are listed in Table 14.1.

Fig. 14.1: Windows XP includes the latest version of Windows Script Host—version 5.6.0

Table 14.1: WSH Versions Implemented by Microsoft Operating Systems

Host Application	1.0	2.0	5.1	5.6
Microsoft Windows 98	x
Microsoft Windows ME			x
Microsoft Windows NT 4 Option Pack	x
Microsoft Windows 2000		x
Microsoft Windows XP				x

In comparison to previous versions, this one provides the following enhancements in functionality.

• Argument handling has been improved—handling and documenting command line arguments is simpler. The process of integrating your scripts with other command line scripts has been simplified, and it is easier to create scripts that can supply the user with help information. Refer to the following table for information on the WSH language features that connect you to this new functionality.

• You can run scripts remotely—you can load scripts onto several remote computer systems, and start them all running simultaneously. While a remote script is running, you can check on its progress, and after it has finished, you can ensure that it ran correctly, or find out what caused it to terminate prematurely. There is a new dispatch object used to create remote WSH objects—the Controller object. In addition, there is a new object that represents an instance of a running script—the Remote WSH object.

• When you start new processes, you can treat them as objects—you determine the status of spawned processes, and access their standard I/O streams.

• You can access the current working directory—you can determine/modify the active process' current working directory.

• Security issues unique to scripts have been addressed—Windows Script Host, a powerful a flexible tool for automating Windows, can at the same time be dangerous if used improperly or with malicious intentions. Windows Script Host 5.6, included with Windows XP, implements a new security model, which enables users to verify the authenticity of a script before running it. Script developers can sign their scripts to prevent unauthorized modifications. Administrators can enforce strict policies that determine which users have privileges to run scripts locally or remotely.

Note 

Windows provides a standard mechanism for signing code via signcode.exe. Unfortunately, signcode.exe doesn't ship with Windows, but rather with the Windows SDK. The most useful and interesting article on this important topic can be downloaded from http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnclinic/html/scripting10082001.asp