WSH, Part 1: File Types

Windows Script Host (WSH) is a powerful, useful, and flexible facility for executing scripts in the Windows environment, but with its power comes a degree of complexity. This month, to begin an examination of WSH, I'll describe what WSH is and how it provides a way to run scripts in Windows. Then I'll look at the various types of script files and means of running them. In future articles, I'll cover the specifics of the .wsf script file format and Windows Script Components (WSC).

What Is WSH?
WSH is a Windows component that provides an environment for executing scripts at the OS level rather than in some other context (such as in a Web browser). WSH isn't a language like Perl or a script interpreter like perl.exe; it's a COM-based script host that executes scripts in Windows. WSH is a native OS component in Windows 2000 and later. You can install it on earlier platforms such as Windows NT 4.0 and Windows 98 after downloading it from Microsoft's Web site.

WSH comes with two standard scripting engines: VBScript and JScript. VBScript is commonly used in systems administration scripting, and JScript (Microsoft's implementation of JavaScript) is more widely used in Web browsers due to JavaScript's broad platform support. Depending on the task, both languages are suitable for WSH-based scripting. WSH can also execute scripts in other languages if you install the appropriate language engines.

WSH comes standard with a set of useful objects. Some of these objects, such as the WScript object and its related objects and collections, exist only in scripts executed by WSH (e.g., you can't use the WScript.Echo method in the script section of a Web page). Some of the objects, however, are general-purpose objects that you can use in any COM-compatible programming language.

There are two basic types of WSH scripts: standalone (i.e., language-specific) scripts and .wsf (Windows script file) scripts. Standalone scripts have a language-specific file extension—for example, .vbs ( VBScript) or .js (JScript). In contrast, .wsf scripts are language-neutral XML text files, and they provide some features beyond what standalone scripts provide. WSH also has two script hosts: WScript and CScript, which I'll describe shortly. The associated WSC technology, formerly known as server scriptlets, allows you to create your own COM components in a script.

Understanding the Script Hosts
You can execute WSH scripts by using the GUI-based host WScript or the console-based host CScript. These two hosts are provided by the wscript.exe and cscript.exe programs, respectively. Windows defaults to using the WScript host, but you can change this default, as I'll show you in a moment.

When you run a script with CScript, the script writes WScript .Echo output and runtime error messages to a console window (i.e., a command-prompt window). When you use Cscript at the command prompt to run a script, the script's output and errors appear in the current command window. When you use Cscript to run a script in the GUI (e.g., in Windows Explorer or in the Run dialog box), Windows creates a temporary console window for the script and executes it inside that window. The script's output and errors appear in the temporary console window, which disappears when the script is completed.

The WScript host, by contrast, executes scripts without a console window. When you use the WScript host, WScript.Echo output and runtime errors are displayed in Windows message boxes.

Both script hosts support a set of command-line options that control script execution and define the default host. The default host is the host used when you execute a script from the GUI or type only its filename at a command prompt. To see the command-line options, type one of the following commands at a command prompt:

cscript /? 

or

wscript /? 

(If you use the Wscript command, the usage message will appear in a Windows message box instead of in the command window.)

Table 1 shows the command-line options. Note that the script host's command-line options are prefixed with two forward slashes (//) to prevent confusion with the commandline options for user-written scripts, which use a single forward slash (/). For example, to set the default host to CScript, disable the logo, and save the options for the current user, type the following command at a command prompt:

cscript //h:cscript //nologo //s 

After setting these defaults, you no longer have to type the cscript command before running scripts at the command line, and the Microsoft copyright notice isn't shown. I generally recommend using these settings because lots of scripts (including many of the administrative scripts provided by Microsoft) require the CScript host. Also, some properties of the WScript object (not to be confused with the WScript host) exist only when CScript is the active host.

If you explicitly specify a host (e.g., when you preface the script's name with either the Cscript or Wscript command), you must also type the script's file extension. For example, the command

cscript hello 

won't work, but

cscript hello.vbs 

will (assuming, of course, that a script file named hello.vbs exists in the current directory). Typing a script name without a host or an extension at the command prompt causes the default host to execute the script.

To see which is the current default scripting host, right-click a script file in Windows Explorer. If the bold menu item is Open with Command Prompt, then the default host is CScript. If the bold menu item is Open, the default host is WScript.

Script File Properties
You can open a Properties dialog box for a script file by right-clicking the script file in Windows Explorer and choosing Properties. Go to the Script tab, which Figure 1 shows. The two options on this tab correspond to the //T and //Logo (or //Nologo) command-line options. If you change either of the options and click OK, Windows creates scriptname.wsh in the same directory as the script. The .wsh file is a plaintext file that contains the selected options; Figure 2 shows a sample .wsh file. The sample .wsh file's BatchMode setting isn't accessible via the GUI and corresponds to the //B command-line option. When it's set to zero (the default), the script will run in interactive mode (//I); if set to 1, the script will run in batch mode (//B). If you want to use this setting, you'll need to open the .wsh file in Notepad or another editor and add the setting.

A .wsh file is merely a way of executing a script with predefined options. When you open a .wsh file, its associated script is executed with the WScript host. Oddly, the //H command-line option doesn't change the default script host for .wsh files. To use CScript to run a .wsh file from the GUI, right-click the file and choose Open with Command Prompt. In a command window, type

cscript .wsh>

A .wsh file contains the full path to its associated script file, so it's possible to move the .wsh file to a different location and still execute the related script. Also, .wsh files aren't strictly necessary; you can always execute a script with the desired settings by using the CScript or WScript command-line options.

WSH File Extensions
Table 2 shows a list of the standard file extensions that WSH uses. Standalone script files use the .js and .vbs extensions. Other ActiveX scripting engine languages use their own extensions (e.g., .pl for Perl, .py for Python). Standalone scripts are the most common because they're the easiest to write.

XML-formatted WSH scripts, .wsf files, are more flexible than standalone scripts because they can contain code written in more than one script language. They also provide some other useful features, such as the ability to include script code from other files. XML-formatted text files that contain the code for script-based objects have the .wsc extension. I'll discuss .wsf scripts and .wsc script components in more detail in future articles in this series.

Clearing Up WSH Confusion
I hope that this explanation helps clear up some of the confusion about WSH and its related collection of file extensions. Next time, I'll describe .wsf scripts and the additional features they provide beyond standalone scripts.