WSH Objects

Microsoft® Windows® 2000 Scripting Guide

The WSH environment includes the built-in WScript object and three COM objects: WshShell, WshNetwork, and WshController. Your scripts can use these objects to help automate system administration tasks.

The WSH objects provide your scripts with functionality that might not be available elsewhere, including the ability to work with command-line arguments, control script execution, and run scripts on remote computers. This means that the scripting language does not have to supply these elements. VBScript, for example, does not include any methods for working with command-line arguments. However, you can still use command-line arguments with VBScript by using the argument capabilities built into WSH.

WSH and the WSH objects do not include all the things system administrators might want to do; far from it. In addition, even tasks that are covered by the WSH objects are often better handled by using technologies such as WMI and ADSI.

For example, the WshShell object has a method named RegRead that allows your scripts to read a fixed registry entry. This method works fine if you know in advance the registry entry the script needs to read. Suppose you want to determine the wallpaper that the user is displaying. In a very specific situation such as that, a simple little WSH script such as this will suffice:

Set WshShell = WScript.CreateObject("WScript.Shell")
strWallpaper = WshShell.RegRead("HKCU\Control Panel\Desktop\Wallpaper")
Wscript.Echo strWallpaper

But what if you have a more open-ended task, such as enumerating all of the entries within a given subkey? In a case such as that, WSH is of little use. Instead, you should use the WMI StdRegistry provider to enumerate the entries of a subkey. The StdRegistry provider gives your scripts more complete and more flexible methods for managing the registry than the WshShell object.

In addition, WMI, for the most part, works exactly the same on remote computers as it does on the local computer. WSH, by contrast, is designed to work only on the local computer. To run WSH scripts remotely, you must use the WshController object and actually create two scripts: the script to be run and the script that allows that script to run remotely. (The WshController object is discussed in detail later in this chapter.)

Nevertheless, there are still times when you might want to use WSH rather than WMI. For example, "pure" WSH scripts are more likely to be supported by Windows NT 4.0-based and Windows 98-based computers. WSH is included with both those operating systems; however, neither WMI nor ADSI shipped with Windows NT 4.0 or Windows 98. If you need to support these older operating systems, WSH might allow you to write a single script that will run on all your computers rather than requiring you to write separate scripts for each platform.