Windows Scripting Host

The Windows Scripting Host (WSH) is a scripting host for 32-bit Windows operating system platforms that supports several scripting engines, notably the Microsoft Visual Basic script and Java script engines. You can run WSH from either the command shell-based host by using Cscript.exe, or the Windows-based host by using Wscript.exe.

With its support for the Microsoft ActiveX scripting architecture, WSH extends the Windows 2000 command shell and lets you create robust scripts that you can execute directly on the Windows desktop or command console without having to embed scripts in an HTML document via common scripting languages such as Microsoft Jscript development software and Visual Basic Scripting Edition (VBScript).

NOTE


The script action consumer in Microsoft Health Monitor 2.1 does not support the WSH object model, so you can't call WSH scripts as script actions in Health Monitor. In order to use WSH scripts, you need to create a command-line action for Cscript.exe, and then pass in the script file as the first command-line parameter.

WSH Architectural Overview

In the same manner as Microsoft Internet Explorer, WSH serves as a controller of ActiveX scripting engines. Because the scripting host is not a full Internet browser, it has smaller memory demands than the browser and is appropriate for performing simple, quick tasks.

The scripting host reads and passes the specified script file contents to the registered script engine by using the IActiveScriptParse::ParseScriptText method provided by the script engine. Figure 11.1 provides a high-level view of the WSH architecture and illustrates how scripts are processed.

click to view at full size

Figure 11.1 WSH architecture and execution flow

The scripting engine does not use the SCRIPT tag, which is used in HTML; instead, it relies on the file name extension to identify which script engine to use. Therefore, you don't have to know the exact ProgID of various script engines. The scripting host maintains a mapping of the script extensions to ProgIDs and uses the Windows association model to launch the appropriate engine.

NOTE


For more information on file extension registration, see the Windows Scripting Host Object Model at http://msdn.microsoft.com/scripting/default.htm?/scripting/windowshost/doc/wsAboutWSH20.htm.

Running Scripts By Using the Command-Based Scripting Host

You can run the command line version of the script host by entering the following information at the command prompt.

 CScript script_name //host_parameters /script_parameters 

Where

  • The value for script_name is the name for the script file.
  • The value for host_parameters is command line switches that are used to enable or disable various WSH options. The host_parameters are always preceded by two slash marks (//).
  • The value for script_parameters is switches that are passed to the script. The script_parameters are always preceded by a one slash mark (/).

Each parameter is optional, but you can't specify script-parameters without specifying a script. If you do not specify parameters, Cscript.exe displays the Cscript.exe syntax and the valid host parameters that you can use.

Cscript.exe supports the host parameters described in Table 11.1.

Table 11.1 Command Line Options

OptionDescription
//BSpecifies batch mode, which will not display alerts, scripting errors, and input prompts.
//DEnables active debugging.
//E:engineUse the specified engine (the value for engine) for executing script.
//H:CScriptChanges the default script host to CScript.exe.
//H:WScriptChanges the default script host to WScript.exe, which is the default.
//ISpecifies interactive mode, which displays alerts, scripting errors, and input prompts. This is the default and the opposite of //B.
//Job:xxxx Run the specified job (the value for xxx).
//LogoDisplay an execution banner at execution time (the default, opposite of //NoLogo).
//NologoPrevent logo display; no banner will be shown at execution time.
//SSave the current command line options for this user.
//T:nnSpecifies the maximum time the script can run in seconds (the value for nn). You can specify up to 32,767 seconds. The default is no time limit.
//XExecute the script in the debugger.
//UUse Unicode for redirected I/O from the console.

The following example shows a valid script host command:

 C:\>cscript //logo %windir%\mysamples\testscript.vbs 

Running Scripts by Using the Windows-Based Scripting Host

There are three ways to run scripts under Windows by using the Windows-based script host. You can:

  • Double-click files and icons in the My Computer, Explorer, and Find windows.
  • Use the Windows Run command, and then type the full name of the script to be executed.
  • Use the Windows Run command to run Wscript.exe and specify the script name and optional parameters.

    NOTE


    You can use the Windows Run command to specify which host application, Cscript.exe or Wscript.exe, is used by default by Cscript with the //H: script_hostname parameter. For example, if you set Wscript.exe as the default, this host will be used when you specify any files that have the .vbs extension.

The Windows Script Host Properties dialog box provides the options listed in Table 11.2. You can access this dialog box by entering wscript from the command line.

Table 11.2 WSH Properties and Options

PropertyUse to...Cscript.exe equivalent
Stop script after nn secondsSpecify a maximum number of seconds that a script may run. (The default is no limit.)//T:nn
Display the logo when scripts are executed in a command console.Display an execution banner at execution time. (The default is the opposite of //NoLogo.)//logo or //nologo

The .wsh File

In addition to setting global scripting options for all the scripts that are executed on the local computer, you have the ability to set script properties on a per-script basis. By creating a .wsh file for a script, you can specify script settings that give you control over how a specific script will execute. (A .wsh file contains custom script settings and is similar to a .pif file for 16-bit applications.) Because you can create several versions of a script .wsh file, you can manage how different users within your organization use your scripts.

What Is Stored in a .wsh File?

A .wsh file is a text file that has a format similar to that of an .inf file. The following example shows the contents of a .wsh file:

 [ScriptFile] Path=C:\WINNT\Samples\WSH\showprop.vbs [Options] Timeout=0 DisplayLogo=1 BatchMode=0 

The Path setting in the [ScriptFile] section points to the script file that this .wsh file affects. The settings found under the [Options] section correspond to settings on the Script tab in the Windows Script Host Properties dialog box.

Creating a .wsh File

In order to set per-script properties and create a .wsh file, simply right-click the script file (.vbs or .js) within Explorer, and then choose Properties. Set specific script properties, such as the amount of seconds the script should execute, and then choose OK. You will notice that a .wsh file is created in the same directory as the original script and is created by using the same name as the original script.

Using a .wsh File

To use a .wsh file, in Explorer, double-click the .wsh file icon or at a Windows command prompt, use Cscript.exe or Wscript.exe to execute that script. For example:

 C:\> cscript Myscript.wsh  

When you double-click the .wsh file or execute the .wsh from the command line, the appropriate engine (Cscript.exe or Wscript.exe) reads the .wsh file to determine the script settings that should be used to execute the script. Cscript and Wscript execute the original script, passing in the properties that are defined within the .wsh file.

NOTE


You must have the original script file present when executing the .wsh file. If the .wsh file fails to execute the script, check the Path= entry in the .wsh file to ensure that it is pointing to the correct script that you are attempting to run.

The .wsf File

The Windows script file (.wsf) is a text document containing XML code that incorporates several features that provide increased scripting flexibility. Because Windows script files are not engine-specific, they can contain script from any ActiveX-compliant scripting engine.

With .wsf files, you can take advantage of the following benefits as you create your scripts:

  • Support for Include statements—allows you to incorporate previously written functions from VBScript or JScript files into your WSH project.
  • Support for multiple engines—allows you to use more than one scripting language in each file—for example, VBScript and Perl.
  • Support for Type libraries—allows you to use constants in your scripts.
  • Support for tools—allows you to edit files with any XML editor.
  • Support for multiple jobs in one file—allows you to store all of your script code in a single location.

These benefits are described in more detail in the following excerpt from the WSH online documentation that is available at the Windows Script Technologies Web site: http://msdn.microsoft.com/scripting/default.htm?/scripting/windowshost/doc/wsAdvantagesOfWs.htm

Include Statements

If you have .js and .vbs files from previous WSH projects, a .wsf file enables you to use them with WSH. A .wsf file encapsulates a library of functions that can in turn be used by multiple .wsf files.

The following example shows the contents of a .wsf file that includes a JScript file (Fso.js), plus a VBScript function that calls a function (GetFreeSpace) in the included file. The contents of Fso.js are also provided.

 <Job id="IncludeExample"> <Script language="JScript" src="FS0.JS"/> <Script language="VBScript">     ' Get the free space for drive C.     s = GetFreeSpace("C:")     WScript.Echo s </Script> </Job> 

The contents of Fso.js are:

 function GetFreeSpace(drvPath) {     var fs, d, s;     fs = new ActiveXObject("Scripting.FileSystemObject");     d = fs.GetDrive(fs.GetDriveName(drvPath));     s = "Drive " + drvPath + " _ ";     s += d.VolumeName;     s += "Free Space: " + d.FreeSpace/1024 + "Kbytes";     return s; } 

Multiple Engine Support

Because one scripting language might not provide all of the functionality you need, WSH allows you to combine multiple languages in a single .wsf file. The following example shows the contents of a .wsf file that includes both VBScript and Perl script code:

 <job id="PERLandVBS"> <script language=PerlScript RUNAT=Server>     sub PerlHello     {         my $str = @_[0];         $Wscript ->Echo($str);     } </script> <script language="VBScript">     Wscript.Echo "Hello from VBScript"     PerlHello "Hello from PERLScript" </Script> </Job> 

Type Library Support

In the following example, MyComponent was developed with Visual Basic version 5.0. MyComponent defines the constant MyError with the following statement:

 Public Const MyError = "You are not using MyComponent correctly." 

The type library is contained in Mycomponent.lib, which you have installed in C:\MyComponent.

 <JobId="IncludeExample"> <Reference progid="MyComponent.MyClass"> <Script language="VBSCript">     Dim MyVar     Set MyVar = CreateObject("MyComponent.MyClass">     Currentreturn = MyVar.MyMethod     If Currentreturn= False then         Wscript.Echo MyError     End If </Script> </Job> 

Tools Support

Because .wsf files are in XML format, you can use any editor that supports XML to edit .wsf files. You can also use any text editor, such as Notepad.

Multiple Jobs in One File

Instead of keeping all of your scripts in separate files, you can incorporate them into one .wsf file, and then organize them into several different jobs. You can then run each job separately by using syntax similar to the following example, where MyFirstJob is the name of the job contained in the MyScripts.wsf file:

 Cscript //Job:MyFirstJob MyScripts.wsf 



Microsoft Application Center 2000 Resource Kit 2001
Microsoft Application Center 2000 Resource Kit 2001
ISBN: N/A
EAN: N/A
Year: 2004
Pages: 183

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net