| Downloads |
|---|
| 23936.zip |
Windows Script Host (WSH) 5.6 is the new version of the Windows scripting environment that Microsoft bundles with Windows XP. This new environment is also available for Windows 2000, Windows NT 4.0, and Windows Me. You can download the executable from Microsoft's scripting Web site at http://msdn.microsoft.com/scripting. But before you begin experimenting with the new version, you'll benefit from an overview of the environment's new features.
First Impressions
The first thing you're likely to notice about WSH 5.6 is the unusual version number. The preceding version of WSH was 2.0; why did Microsoft jump to WSH 5.6? Some people guessed that Microsoft wanted WSH to match XP's version number; however, XP is version 5.1 of Windows. Microsoft made the new WSH version number correspond to the version number of Windows Script. WS is the scripting infrastructure that consists of WSH, VBScript, JScript, Windows Script Components (WSC), and Windows Script Runtime.
Although WSH 5.6 provides significant improvements over WSH 2.0, the new environment looks much the same. WSH 5.6's object model is slightly enhanced, but the new version doesn't provide much in the way of extended features. To extend the environment's functionality, you still need to develop COM objects, as I've done in recent columns. ("VBScripting Solutions: An Improved GUI Component for Data Entry," January 2002, InstantDoc ID 23369, provides a COM object that lets WSH silently retrieve a user's password; "VBScripting Solutions: Extending WSH with the Functionality in Wshextra.dll," February 2002, InstantDoc ID 23601, supplies objects that let a WSH application move data to and from the clipboard and that provide a couple of other missing but useful functions.)
Object model enhancements are minimal, but WSH 5.6 provides significant improvements in security, command-line interaction, and remote-process control. In general, rather than increasing the programming power of script developers, WSH 5.6 makes the environment match an administrator's expectations. So, for example, an administrator can now more easily enforce security policies on the system and determine which users are allowed to run scripts.
When you look at the programming aspects of WSH 5.6, you can't miss two reasons that the XML schema for WSH files—the WS file (.wsf) file format—seems destined to become increasingly important. First, WSH 5.6's most valuable improvements derive primarily from enhancements to the WS file schema. For example, you can embed usage information in the XML script through the new <named> tag and automatically retrieve and display that information through the ShowUsage method. The second reason that the .wsf file format is likely to remain an important part of WSH stems from the role of scripting in the future of Microsoft OSs. The advent of Microsoft's .NET strategy will eventually limit the usefulness of .vbs scripts. Although VBScript still works in XP, VBScript will become an archaic language that future Windows OSs won't support. The .NET languages are more powerful and use a new component model, which will have two consequences. First, backward compatibility with existing VBScript applications will be difficult. Second, you'll be able to write a true program with much the same effort you expend now to write scripts.
The direction that Microsoft is heading doesn't mean that VBScript and JScript will disappear anytime soon, but they'll morph into the more powerful, first-class languages Visual Basic .NET and JScript.NET. The object-oriented nature of these languages, along with the nature of the hosting .NET environment, will probably signal the end of batch-style scripting, in which a text file contains only executable code. To run effectively, script code of the future will need to contain more context information (e.g., references, version information, resources). This information will most likely be buried in the project files or be part of the compile command line. However, today's scripts can't include project files or explicit compile command lines. The transition to .NET applications won't be immediate. The WS file format provides improved functionality and represents a sort of intermediate step toward scripts that rely on context information. Hence, I suggest that you familiarize yourself with the .wsf file format if you haven't already done so.
Enhancements in Brief
As I mentioned earlier, WSH 5.6's most important new features relate to security, improved process control, and enhanced command-line interaction. Recently, WSH has been the vehicle for some serious virus infections. For example, a simple and apparently inoffensive VBScript file triggered the VBS.LoveLetter virus. As a scripting environment, WSH can't do much to prevent users from writing malicious scripts and can't differentiate malicious from nonmalicious scripts. Nor can WSH check the behavior of a COM object before invoking it. Securing WSH is primarily an administrative responsibility, and the scripting environment should let administrators decide whom and what to trust. Changes to the WSH security model go in this direction, as I explain later.
Before version 5.6, WSH provided the ability for scripts to spawn external processes but not the ability to access an external process's internal status, such as the process's standard input and output devices. WSH 5.6's enhanced process control provides two new objects that let scripts launch executables on remote machines (the WshRemote object) and control the status of spawned processes (the WshScriptExec object).
Finally, the new version's WsgArguments object, which provides access to a script's command-line arguments, includes two new properties: Named and Unnamed. These new properties let you specify parameters by name, not just by position.
WSH Security
In the past, WSH was primarily a tool that systems administrators could use to access programs, file systems, network shares, FTP sites, and so on. From this viewpoint, WSH scripts are simply a modern Windows-oriented version of MS-DOS batch files. Like any other Windows executable, scripts written in the WSH 2.0 or WSH 1.0 environment provide no way for an administrator to control their execution.
WSH 5.6 lets administrators enforce security policies on the system at two levels: the user level and the script level. At the user level, an administrator can determine which users are allowed to run scripts and whether those users can execute scripts on local and remote machines.
The script level of security relates to the authentication of scripts. Unlike WSH 2.0, WSH 5.6 lets administrators configure the WSH environment to accept and run only scripts that come with a valid digital certificate. A valid digital certificate is a certificate of identity issued by an authority that the organization recognizes and trusts. In basic terms, a certificate constitutes an explicit guarantee that the person who signed the script is known and reasonably reliable.
Administrators can choose to let users run only scripts a certain authority has guaranteed or only scripts signed with a certain author identity. On systems that need to be further restricted, administrators can configure WSH 5.6 to support only scripts that their company's certificate server has signed. (Win2K Server now provides a certificate server.) Because a company administrator or department must verify and sign such scripts, this configuration gives a company total control over the scripts that users can execute on company servers. If someone tampers with a certified script after the company receives it, WSH will immediately detect the modifications and originate a runtime error.
WSH 5.6 implements this security model in one of two ways, depending on the underlying OS. When running under XP, WSH 5.6 integrates with the XP Windows Installer and Software Restriction Policy. When running under earlier versions of Windows, WSH 5.6 stores all the needed settings in protected registry keys that only a user who has administrator privileges can edit. For more information about this security model, see the Microsoft Windows XP Resource Kit.
Controlling Remote Scripts
A new WSH 5.6 object, WshController, gives you a way to launch and control a remote script. You instantiate the WshController object with the code
Set controller = _
CreateObject("WshController")
The WshController object has no properties and exposes only the CreateScript method, which lets you create a remote script process. The method returns a reference to another object that's new to WSH 5.6: the WshRemote object.
The code in Listing 1 shows the CreateScript method's signature. The first argument is the pathname of the script that you want to run on a remote machine. The script can be on the local machine or on another machine in the network share. The second argument is the Universal Naming Convention (UNC) name of the server on which you want to run the script. If you omit the server name, the script runs locally. Thus, you can sit at one computer, retrieve a script from a second computer, and run the script on a third computer. You don't need to make a physical copy of the script on the remote machine on which you want to run it—the WshController object temporarily duplicates the script. For this reason, the CreateScript method's first argument must be a local path.
The CreateScript method prepares the script for execution and returns a WshRemote object, which provides the interface you use to control the remote script. You use the WshRemote object's properties and methods to control, execute, and terminate the script on the remote machine. For example, as callout A in Listing 1 shows, you call the Execute method to execute the script.
To enable remote functionality from WSH 5.6, you must first configure the remote server's security settings. The remote server and the local machine must both be running NT 4.0 Service Pack 3 (SP3) or later, and both machines must have WSH 5.6 installed and enabled. A user who wants to run the remote script must be a member of the remote machine's Local Administrators group.
Remote functionality isn't enabled by default when you install WSH 5.6. To enable the functionality, you can use an ad hoc registry entry or an administrative template that you access through Control Panel. For more information about enabling remote functionality, see the Help file that comes with WSH 5.6.
Command-Line Arguments
The WshArguments object is a collection of command-line arguments. In WSH 5.6, this object has two new properties: Named and Unnamed. The Named property returns the WshNamed object, a child collection that contains the script's named arguments. The Unnamed property returns the WshUnnamed object, a child collection that contains the script's unnamed arguments. A named argument is a command-line argument that's associated with a name and a switch.
All arguments that are specified on the command line without being associated with a name are consid-ered unnamed arguments. The contents of the WshArguments collection is always the sum of the contents of the WshNamed and WshUnnamed child collections. For example, the command
scanfile.exe /file:file.txt /recursive
contains two arguments: /file:file.txt and /recursive. The first argument consists of a switch, which represents the name of the argument (/file:) and a filename (file.txt). The second argument consists of only the /recursive switch, which indicates a Boolean value. When the switch is present, the Boolean value is True; when the switch is absent, the value is False.
Compare the preceding command with
scanfile.exe file.txt true
This command also contains two arguments but no switches to qualify the arguments with a name. When the switch is present, as in the first command, you're working with named arguments. When the switch is missing, the arguments are unnamed. The scanfile.exe command supports both named and unnamed parameters in any combination. If your script supports named arguments, you can retrieve the actual values of the arguments by using names as well as index positions.
WSH 5.6 automatically groups named and unnamed parameters in ad hoc collections. You can use the WshNamed object's Exists method to test whether a parameter with a given name already exists. The code in Listing 2, page 3, shows how to use the Exists method.
When you use a WSH script through the XML format, you can associate named arguments with a help string and a type. You can then use a new, long-awaited feature—the ShowUsage method—which automatically prompts a Help message box to appear. This message box displays information about the options you can use when launching the script from the command line.
As you can see, WSH 5.6 qualifies as a major upgrade to the WSH environment. In addition to providing structural improvements in crucial areas such as security, the enhanced environment makes writing scripts easier with the introduction of long-awaited features such as named arguments and script controllers.
