Components of the WSH Environment

Microsoft® Windows® 2000 Scripting Guide

« Previous | Next »   

WSH has a modular architecture: It is made up of separate parts, each responsible for performing a specific function. This modularity gives WSH two important capabilities: it can make use of multiple scripting languages and it can leverage COM objects.

Figure 3.1 illustrates the major components of the WSH environment and their interactions. The WSH environment includes script files, script hosts, scripting language engines, and COM objects. In this diagram, the shaded boxes represent the items that are installed when you install WSH 5.6. The major components shown in this diagram, and the ways in which they interact, are explained in subsequent sections of this chapter.

Figure 3.1   Major Components of the WSH Environment

Major Components of the WSH Environment

Script Files

You create WSH script files to automate system administration tasks. Script files (more commonly referred to simply as scripts) are plain-text files that contain instructions describing how to accomplish a task or set of tasks. (Plain-text means that the files cannot include any special formatting characters.) For example, the following script will fail because line 2 uses "smart quotes." Because these are not standard characters, WSH cannot interpret them, and the script fails with the error message, "Invalid character."

Wscript.Echo "This line is correct." Wscript.Echo "This line is incorrect." 

This is important to keep in mind because most word processing applications use special formatting characters by default. This means that word processing applications do not make the best environment for creating scripts: It is too easy to save a script with special formatting characters that will prevent the script from running. Instead, text editors designed to work with plain text (such as Notepad) are the best tools for creating WSH scripts. Because these editors typically do not support special formatting characters, there is less chance that you will inadvertently include such a character in your script.

Note

• You should also avoid the temptation of creating scripts in a word processor and then copying and pasting the code into a text editor; there is no guarantee that the pasted lines of code will actually be in plain-text format. These problems can be especially difficult to diagnose because the code might look as though it is in plain-text format. In reality, the code might still contain special characters that will cause the script to fail.

The instructions included in a script can be written in any WSH-compliant scripting language for which a corresponding scripting language engine has been installed. You should save the file with the file-name extension that corresponds to that language. Table 3.1 lists three example script files along with the language that corresponds to their file-name extensions.

Table 3.1   Script File Name Extensions

File Extension	Sample File Name	Scripting Language
.VBS	EnumPrinters.vbs	VBScript
.JS	EnumProcesses.js	JScript
.PLS	EnumDisks.pls	PerlScript

In other words, if you are writing a script using VBScript, save the file with the .vbs file name extension. If you are writing a script using JScript, save the file with the .js file name extension.

Note

• It is possible to run scripts even if you use a nonstandard file name extension (such as .xyz). This is explained later in this chapter.

After you have typed your script into Notepad and saved it, it is ready to run. This is one of the primary advantages of scripting: you do not need to create any supporting files nor run the script through a compilation process; instead, you simply write it, save it, and run it. For example, type the following two lines of code into Notepad:

Set objNetwork = Wscript.CreateObject("Wscript.Network") Wscript.Echo objNetwork.ComputerName 

Save the file with the .vbs file name extension, and you have a script that returns the name of the local computer.

Script Hosts

The script host initiates and coordinates the running of your script; it reads your script file and interacts with components of the WSH environment and any COM objects required by the script. It is also the responsibility of the script host to determine which language engine to use when running the script. For example, if the script has a .vbs extension, the script host will load the VBScript language engine and begin working with that engine to execute the code.

The WSH environment includes two script hosts: the console-based CScript and the GUI-based WScript. The two script hosts provide nearly identical capabilities, and in most cases, it does not matter which of the script hosts you use to run your scripts.

The two exceptions lie in how you interact with a script; that is, how you get information into a script (input) and how the script displays information it has retrieved (output). In general, CScript receives input from the command prompt and displays output in a command window. WScript, by contrast, receives input through a graphical dialog box and displays output in a graphical message box.

Otherwise, the two script hosts are largely identical: If you have a script that does not require user interaction, you can run that script under either CScript or WScript. For example, the following script maps a network drive. Because it neither requires input nor displays output, it runs exactly the same under either script host:

Set objNetwork = Wscript.CreateObject("WScript.Network") objNetwork.MapNetworkDrive "g:", "\\atl-fs-01\Sales" 

On the other hand, the following script which displays a series of messages runs much differently under CScript (where the messages are displayed as individual lines within a command window) and WScript (where the messages are displayed as a series of message boxes). If you are interested in seeing the difference for yourself, copy the script into Notepad, save it with a .vbs file extension, and then run it under both CScript and WScript. (For more information about running scripts under a script host, see "Running WSH Scripts" later in this chapter.)

Wscript.Echo "Line 1." Wscript.Echo "Line 2." Wscript.Echo "Line 3." Wscript.Echo "Line 4." 

Scripting Language Engines

Although the script host is responsible for initiating and coordinating the running of a script, it is not capable of interpreting any scripting language. The WSH environment separates the logic necessary to interpret a given scripting language from the script host.

It is this separation that enables WSH to be a multi-language scripting environment. This is because WSH does not attempt to "speak" VBScript, JScript, ActivePerl, Rexx, Python, or any other scripting language. Instead, it is up to the language engine to translate a script into commands that WSH can understand. You can write a WSH script in VBScript because the VBScript language engine can translate the code in your scripts into commands that WSH can understand and act upon. You cannot write a WSH script in C++ because there is no language engine that can translate C++ code into WSH commands.

When a scripting language engine is installed, at least one mapping is recorded in the registry. The mapping associates a file name extension with the dynamic link library (DLL) that implements the scripting language engine. The script host usually determines the language used in a script by examining the file name extension and then checking the registry to determine the corresponding scripting language engine.

Note

• You can force the script host to use the scripting language engine of your choice by specifying the //E: command-line option. (See Table 3.2.) This option allows you to use any file name extension on your script files, regardless of the scripting language in which they are written.

COM Objects

WSH includes the WScript object and three COM-based objects: WshShell, WshNetwork, and WshController. Although they are included with the WSH environment, you use them in your scripts in the same way you use other COM objects.

The WSH COM objects possess neither the depth nor the breadth of the system administration capabilities found in WMI or ADSI. Nevertheless, you are likely to find these objects useful in several situations:

• If you need to carry out a task that cannot be carried out using another Automation object. For example, the WshNetwork object allows you to map network drives; this capability is not available in either WMI or ADSI.
• If you have down-level clients that are not running WMI or ADSI. For example, ADSI might be the preferred method to retrieve the name of the local computer, but ADSI did not ship with Windows 98. For Windows 98 computers, you can use the WshNetwork object to retrieve the name of the local computer.
• If you need to run a script on a remote computer, and neither WMI nor ADSI is capable of carrying out this task remotely. In that case, you can use the WshController object to run the script on the remote computer.

---

 Send us your feedback

« Previous | Next »