Windows Script Host 5.6

 

Andrew Clinick
Microsoft Corporation

November 17, 2000

Contents

WSH Development
They're Calling Our Baby Ugly!
What's New in WSH 5.6
Remote WSH
Fixing Bugs
Tools Support
Where to Get WSH 5.6
Summary

Windows Script Host (WSH) has reached an important milestone with the release of WSH 5.6 Beta 1. In this article, I'll cover what's new in WSH, and I'll try to give you an insight into the development process and how we decided on the features in this release.

WSH Development

Developing the next release of WSH has been an interesting experience for the Windows Script team. When we started development, we looked at the feature set for Windows Script Host and tried to concentrate on enhancing the integration technologies—in particular, the ability to write command-line-driven scripts.

This is a reasonably strange goal for a Microsoft product, because we typically aim to make the user interface easier to use, and command-line programs aren't known for their great user interfaces. That said, writing command-line scripts is the main way people write Windows scripts. It provides a quick, relatively simple way to get tasks done, and when you're running scripts as part of a batch process, a flashy user interface can actually work against you. With this in mind, the feature set of WSH was heavily biased toward making command-line scripts easier to write.

They're Calling Our Baby Ugly!

Just when we felt we had the feature set of WSH nailed down, we started to get a lot of mail from people expressing their deep love for the Script team. It's always nice to get appreciative mails, but the whole "I Love You" debacle certainly didn't put WSH in a positive light. Concerned that people were casting aspersions on WSH, we quickly got together with Microsof security and safety experts, and we spoke with some key users (thanks to Ian Morrish and Mike Harris for helping us out even more than they usually do here).

We wanted to allow WSH to be used to script Windows, but we also wanted to assuage some of the legitimate fears that the "I Love You virus" raised. The issue of downloading executable code from an unknown or disreputable source isn't unique to WSH, and we worked closely with the Outlook team to see how they could put some safeguards in to help stop the spread of viruses immediately. However, the fix that we provided quickly was far from the ultimate solution, because it disallowed the distribution and execution of all WSH scripts, regardless of their authenticity or intent.

It was clear that we needed to come up with a more robust solution for WSH that allowed people to have some control over which code would be run and when. We went back to the feature list of WSH 5.6 and reassessed what we could do in the time we had to develop new features. We then made some tough cuts in order to implement the features that were required to reduce the potential to run malicious scripts. This meant deferring some features that we really wanted to add, but we felt it was more important to ensure that WSH remains a viable script platform for use in corporate and home-user environments. The advantage is that we have those other features ready to roll for the next version.

What's New in WSH 5.6

Some of you are probably wondering how WSH went from 2.0 to 5.6 in one release. The very first version of WSH was actually 5.0—yet we commonly referred to it as WSH 1. As we continued to develop WSH, we called it WSH 2.0. Unfortunately, we found that we couldn't actually mark it as WSH 2.0 because it wouldn't upgrade existing WSH installations. But we kept referring to the version as 2.0 even though in reality it was 5.1. Not surprisingly, this confused a lot of people, so for this release we decided to rationalize the version numbering and remove any confusion as to what actually constituted WSH. Thus the version number jumped to 5.6, along with the version numbers for Visual Basic® Scripting Edition (VBScript), JScript, and so forth. In this article, I'll discuss the security and authentication enhancements to WSH 5.6, then I'll talk about the command-line features. In both sections, I'll provide samples.

Authentication/Security Advances

One of the key advantages of writing scripts is the ability to write and run programs that are stored as text, which makes those programs exceptionally easy to write and distribute. That ease of distribution is, however, a double-edged sword because malicious coders can more easily distribute potentially damaging viruses via e-mail or the Internet.

If you receive an e-mail with a WSH attachment, Outlook and most other e-mail programs will show a dialog box that warns you about the potential risks of opening up attachments. However, most people (as witnessed by the "I Love You" virus) pay little attention to the dialog box, and open the attachment anyway. Initial solutions are to remove the ability to open attachments in e-mail and to force users to save those attachments to their hard disks, or to remove the ability to open certain file types as attachments. These are effective, but they limit what you can do on your machine and in your organization. For example, it might make sense for corporate administrators to send out scripts via e-mail. With WSH 2.0, you can run any script no matter where it came from, and you have little knowledge of whether the script is from a reputable, reliable source. If you get an e-mail from a friend with a script attached, you may assume that the script was written by that friend.

In WSH 5.6, we introduce the ability to sign scripts and to set policies about running scripts. By signing your scripts, you can guarantee that you wrote the script, and that is hasn't been tampered with in any form since you signed it. The signing process uses your certificate, which you can get from a number of certificate authorities (you might even have an internal certificate authority), the hash of the script file, and your private key to create a signature in the script file. When WSH loads the file, it will check the certificate to ascertain whether the certificate is okay and whether the hash matches the contents of the file. If the hash is different, somebody has tampered with the file. WSH will tell you about this, and will ask whether you still want to run the file. If the script has been tampered with, you should proceed with extreme caution. Likewise, if the certificate is invalid, expired, has been revoked, or isn't trusted, then WSH will notify you and will refuse to run the code. For more information on code signing, I recommend you read the following:

  • CCITT, Recommendation X.509, The Directory-Authentication Framework, Consultation Committee, International Telephone and Telegraph, International Telecommunications Union, Geneva, 1989.
  • RSA Laboratories, PKCS #7: Cryptographic Message Syntax Standard. Version 1.5, November, 1993.
  • Schneier, Bruce, Applied Cryptography, 2d ed. New York: John Wiley & Sons, 1996.
  • The RSA Web site

It's important that the signing mechanism cover all file formats supported by WSH, so .vbs, .vbe, .js, .jse and .wsf file types are covered. It is also important that previous versions of WSH be able to run signed files, so the script signing mechanism puts the signature into comment blocks at the end of .vbs and .js files and into a <signature> element in wsf files. If the signed code is loaded by an older version of WSH, it will ignore the commented code or <signature>.

Examples of signed code

HelloWorld.wsf

<job>
<script language="VBScript">
WScript.Echo "Hello world"
</script>
<signature>

SIG MIIDKQYJKoZIhvcNAQcCoIIDGjCCAxYCAQExDjAMBggq SIG hkiG9w0CBQUAMGYGCisGAQQBgjcCAQSgWDBWMDIGCisG SIG AQQBgjcCAR4wJAIBAQQQTvApFpkntU2P5azhDxfrqwIB SIG AAIBAAIBAAIBAAIBADAgMAwGCCqGSIb3DQIFBQAEEA0F SIG XJYLd0k8EhI/etuA3SGgggGTMIIBjzCCATmgAwIBAgIQ SIG kFDTSxAAoaIR1DKaQiUeEDANBgkqhkiG9w0BAQQFADAX SIG MRUwEwYDVQQDEwxFcmljIExpcHBlcnQwHhcNMDAwMTAx SIG MDcwMDAwWhcNMDYwMTAxMDcwMDAwWjAXMRUwEwYDVQQD SIG EwxFcmljIExpcHBlcnQwXDANBgkqhkiG9w0BAQEFAANL SIG ADBIAkEA3VIzvDbRfyssTEP+KJ1tO8e2/4Et3ZKK23gH SIG GlIBlUJ6ss3Ro7GyILOWZCL+33NGpYQKL7mYZ+p5xSjc SIG tQNYPwIDAQABo2EwXzATBgNVHSUEDDAKBggrBgEFBQcD SIG AzBIBgNVHQEEQTA/gBAOsjyOexvxG/OkX9N6F8eMoRkw SIG FzEVMBMGA1UEAxMMRXJpYyBMaXBwZXJ0ghCQUNNLEACh SIG ohHUMppCJR4QMA0GCSqGSIb3DQEBBAUAA0EAYhQpLNPx SIG ab25g+3RdIKkSYiRKTUSeSpOVSsCEFVzZON8D93HYCAN SIG Wc+5ZhsKvs/U2/J50yXsxdLeRBqGWstuqDGCAQAwgf0C SIG AQEwKzAXMRUwEwYDVQQDEwxFcmljIExpcHBlcnQCEJBQ SIG 00sQAKGiEdQymkIlHhAwDAYIKoZIhvcNAgUFAKBsMBAG SIG CisGAQQBgjcCAQwxAjAAMBkGCSqGSIb3DQEJAzEMBgor SIG BgEEAYI3AgEEMBwGCisGAQQBgjcCAQsxDjAMBgorBgEE SIG AYI3AgEVMB8GCSqGSIb3DQEJBDESBBDKAv0x3ULOrAx+ SIG Uo3S9F8cMA0GCSqGSIb3DQEBAQUABEDF2tdMhRr8xzKi SIG cFi45A+xB2/zRLtmVXCywfR42J29m6ybYP+CjIQtNxS0 SIG naHd+wxLsLJwDXGq9BjGpuUPtuz9

Helloworld.vbs

WScript.Echo "Hello world"

'' SIG '' Begin signature block
'' SIG '' MIIDKQYJKoZIhvcNAQcCoIIDGjCCAxYCAQExDjAMBggq
'' SIG '' hkiG9w0CBQUAMGYGCisGAQQBgjcCAQSgWDBWMDIGCisG
'' SIG '' AQQBgjcCAR4wJAIBAQQQTvApFpkntU2P5azhDxfrqwIB
'' SIG '' AAIBAAIBAAIBAAIBADAgMAwGCCqGSIb3DQIFBQAEEA0F
'' SIG '' XJYLd0k8EhI/etuA3SGgggGTMIIBjzCCATmgAwIBAgIQ
'' SIG '' kFDTSxAAoaIR1DKaQiUeEDANBgkqhkiG9w0BAQQFADAX
'' SIG '' MRUwEwYDVQQDEwxFcmljIExpcHBlcnQwHhcNMDAwMTAx
'' SIG '' MDcwMDAwWhcNMDYwMTAxMDcwMDAwWjAXMRUwEwYDVQQD
'' SIG '' EwxFcmljIExpcHBlcnQwXDANBgkqhkiG9w0BAQEFAANL
'' SIG '' ADBIAkEA3VIzvDbRfyssTEP+KJ1tO8e2/4Et3ZKK23gH
'' SIG '' GlIBlUJ6ss3Ro7GyILOWZCL+33NGpYQKL7mYZ+p5xSjc
'' SIG '' tQNYPwIDAQABo2EwXzATBgNVHSUEDDAKBggrBgEFBQcD
'' SIG '' AzBIBgNVHQEEQTA/gBAOsjyOexvxG/OkX9N6F8eMoRkw
'' SIG '' FzEVMBMGA1UEAxMMRXJpYyBMaXBwZXJ0ghCQUNNLEACh
'' SIG '' ohHUMppCJR4QMA0GCSqGSIb3DQEBBAUAA0EAYhQpLNPx
'' SIG '' ab25g+3RdIKkSYiRKTUSeSpOVSsCEFVzZON8D93HYCAN
'' SIG '' Wc+5ZhsKvs/U2/J50yXsxdLeRBqGWstuqDGCAQAwgf0C
'' SIG '' AQEwKzAXMRUwEwYDVQQDEwxFcmljIExpcHBlcnQCEJBQ
'' SIG '' 00sQAKGiEdQymkIlHhAwDAYIKoZIhvcNAgUFAKBsMBAG
'' SIG '' CisGAQQBgjcCAQwxAjAAMBkGCSqGSIb3DQEJAzEMBgor
'' SIG '' BgEEAYI3AgEEMBwGCisGAQQBgjcCAQsxDjAMBgorBgEE
'' SIG '' AYI3AgEVMB8GCSqGSIb3DQEJBDESBBDKAv0x3ULOrAx+
'' SIG '' Uo3S9F8cMA0GCSqGSIb3DQEBAQUABEDF2tdMhRr8xzKi
'' SIG '' cFi45A+xB2/zRLtmVXCywfR42J29m6ybYP+CjIQtNxS0
'' SIG '' naHd+wxLsLJwDXGq9BjGpuUPtuz9
'' SIG '' End signature block

Helloworld.js

WScript.Echo("Hello world")

// SIG // Begin signature block
// SIG // MIIDKQYJKoZIhvcNAQcCoIIDGjCCAxYCAQExDjAMBggq
// SIG // hkiG9w0CBQUAMGYGCisGAQQBgjcCAQSgWDBWMDIGCisG
// SIG // AQQBgjcCAR4wJAIBAQQQEODJBs441BGiowAQS9NQkAIB
// SIG // AAIBAAIBAAIBAAIBADAgMAwGCCqGSIb3DQIFBQAEEH9C
// SIG // vGh26/pqEkdo4pPjv4qgggGTMIIBjzCCATmgAwIBAgIQ
// SIG // kFDTSxAAoaIR1DKaQiUeEDANBgkqhkiG9w0BAQQFADAX
// SIG // MRUwEwYDVQQDEwxFcmljIExpcHBlcnQwHhcNMDAwMTAx
// SIG // MDcwMDAwWhcNMDYwMTAxMDcwMDAwWjAXMRUwEwYDVQQD
// SIG // EwxFcmljIExpcHBlcnQwXDANBgkqhkiG9w0BAQEFAANL
// SIG // ADBIAkEA3VIzvDbRfyssTEP+KJ1tO8e2/4Et3ZKK23gH
// SIG // GlIBlUJ6ss3Ro7GyILOWZCL+33NGpYQKL7mYZ+p5xSjc
// SIG // tQNYPwIDAQABo2EwXzATBgNVHSUEDDAKBggrBgEFBQcD
// SIG // AzBIBgNVHQEEQTA/gBAOsjyOexvxG/OkX9N6F8eMoRkw
// SIG // FzEVMBMGA1UEAxMMRXJpYyBMaXBwZXJ0ghCQUNNLEACh
// SIG // ohHUMppCJR4QMA0GCSqGSIb3DQEBBAUAA0EAYhQpLNPx
// SIG // ab25g+3RdIKkSYiRKTUSeSpOVSsCEFVzZON8D93HYCAN
// SIG // Wc+5ZhsKvs/U2/J50yXsxdLeRBqGWstuqDGCAQAwgf0C
// SIG // AQEwKzAXMRUwEwYDVQQDEwxFcmljIExpcHBlcnQCEJBQ
// SIG // 00sQAKGiEdQymkIlHhAwDAYIKoZIhvcNAgUFAKBsMBAG
// SIG // CisGAQQBgjcCAQwxAjAAMBkGCSqGSIb3DQEJAzEMBgor
// SIG // BgEEAYI3AgEEMBwGCisGAQQBgjcCAQsxDjAMBgorBgEE
// SIG // AYI3AgEVMB8GCSqGSIb3DQEJBDESBBAstdnTqrEZVeGY
// SIG // Ft7xbHdUMA0GCSqGSIb3DQEBAQUABEDZzXe/mSTNXJ/Q
// SIG // 1b2OkIFQsWJ1En8JHb2ypSDrjntPv600/TYD6SXC7HS+
// SIG // 1eaicqvyApoYuUriTo8p+F3Rs8CI
// SIG // End signature block

Signing your scripts

Windows provides a standard program, signcode.exe, that will sign any executable code. WSH 5.6 extends signcode.exe to support all WSH file types, so you can just run signcode.exe at the command line with the scripts you want to sign. You can get signcode.exe and a number of other tools to check the signature from the Platform SDK on MSDN. A code-signing object, Script.Signer, allows you to integrate signing capability into other tools. For example, the new beta version of PrimalScript 2.0, which supports WSH 5.6, uses the Script.Signer object to allow you to sign WSH scripts.

Policy for signed code

The Windows operating system provides a mechanism that allows administrators to set policy for particular users or machines. A policy can include many settings, and administrators can extend policies to meet the requirements of a specific application. WSH 5.6 provides a set of policy guidelines that integrate with the code-signing process, so that you can determine what the default behavior for WSH should be. For example, you might set a policy that allows users to run only scripts that are signed by trusted sources. This is just a matter of changing policy settings in the policy editor (provided in Windows 2000 Server) and rolling out the revised policy to users' machines. In addition to code signing, the WSH policy template includes the ability to disable remote WSH completely—and, for the paranoid, to turn off all access to WSH. The great thing about policies is that they can be applied on a per-user basis, so you could turn off access to remote WSH for all users other than administrators.

Figure 1: Setting properties for controlling script sources

This policy, illustrated in the graphic, above allows users to run scripts from script authors in the company and from authorized suppliers, but it won't allow users to run any scripts from random authors on the Internet or from e-mail.

Command-Line Improvements

WSH has always had the ability to run scripts from the command line. WSH 2.0 introduced more control over standard I/O functions, but there was still room for considerable improvement—particularly in the ability to control applications and to write better command-line scripts. When WSH 2.0 shipped, we looked at the script samples from Microsoft and all the scripts posted on the WSH community Web sites. It became clear that script writers were writing a lot of code that dealt with command-line options, usage strings, and so forth. In many scripts, only about 20 percent of the code was actually doing what the script was designed for. To alleviate this, WSH 5.6 introduces the ability to create the command-line options from a structured XML format. For example, if your script needed two arguments, server and name, it would be represented in the XML using the <named> elements.

reboot.wsf

<job>
    <runtime>
        <description>This script reboots a server</description>
        <named
            name="Server"
            helpstring= "server to run the script on"
            type = "string"
            required="true"
        />
        <named
            name="User"
            helpstring= "user to run the script as"
            type = "string"
            required="false"
        />
      <example>Example: reboot.wsf /Server:scripting /User:Joe</example>
    </runtime>
    <script language="VBScript">
       ' Do something useful here
    </script>
</job>

When you specify the command-line arguments in XML, you are free to concentrate on the script code you need to perform your task, rather than writing additional code. It also means that your script will be automatically self documenting, because the usage string is built from <runtime> elements. Whenever you add an argument, it will be documented in the usage string. Essentially, WSH provides you with a standard command-line argument library that is data-driven within the file via XML. Because it's XML based, it's pretty simple to write, and it allows tools to support the new format. In fact, PrimalScript 2.0 supports the new <runtime> definition by providing a graphical view of the XML.

The named elements contain all the information required to create a command-line argument, including the type. WSH will not check the type against the argument. After all, script is typeless, but the type is used when the usage string is created. The usage string is created automatically when the script is called with the /? argument. The previous example would result in:

Microsoft ® Windows Script Host Version 5.6 for Windows
Copyright (C) Microsoft Corporation 1996-2000. All rights reserved.

This script reboots a server
Usage: reboot.wsf /Server:value /User:value

Options:
server : Server to run the script on

Example:
reboot.wsf /server:scripting /user:joe

Because arguments are defined in XML, you don't have to worry about updating the argument-checking code whenever you add a new argument. Your script usage string will always show the most up-to-date options for your script. We're also working on a simple XSL style sheet that will take a .wsf file and automatically generate HTML documentation.

Improved application control

The improved standard I/O support in WSH 2.0 was a considerable improvement over WSH 1, but it was only part of the final solution because it still didn't allow scripts to run other programs or share the same command console. Batch and Perl scripters have had access to those capabilities for a considerable time, and their absence made it difficult to chain command-line programs together by using WSH.

WSH 5.6 introduces the ability to start programs or scripts in a command process that shares all the environment variables of the parent script. It also allows the parent script to capture any output from the child process. This final capability is particularly useful because you no longer have to run the program, capture its output into a text file, and read in the text file—hardly the most efficient mechanism. When designing this feature, we looked at the functionality of the WScript.Run method, but we decided against extending it because we wanted to ensure that WScript.Run behaved exactly as it did in prior versions of WSH. WSH 5.6 introduces a new method, WScript.Exec, that runs a command line and returns a WScriptExec object. The WScriptExec object provides information about the running task and access to its standard input, standard output, and standard error streams. This means you can launch another process and manipulate it via the standard input, then capture its output via the standard output stream. For example, you could run ping and capture the output to see whether the DNS name resolved, what its average round trip was, and so on. Object models will allow you to get similar information, but sometimes running a command-line tool and capturing its output is the quickest way to get the data—and if there isn't an object model, running a command-line tool is your only option.

To get an idea of the uses of the new command-line integration and application-control features, check out Michael Whalen's Amazing Directory Filter Script. It uses the new XML command-line definition to describe the command-line options and the extensions to the WScript.Arguments collection that allow simple access to named and unnamed arguments. Finally, the script uses the new exec method to execute dir and capture the output via the standard output stream. If you remember back to my article from June 14, 1999, you'll see that prior to the new exec mechanism, you had to run dir separately and pipe the information into the script.

<package>
<job id="ExecDemo">

<runtime>
<description>

********************************************* * The Amazing Directory Filter Script!!!! * ********************************************* This script will filter out unwanted file types from your directory listing, using the powers of script and Windows Script Host. *********************************************

</description>
<named
      name="d"
      helpstring="The directory to list."
      type="string"
      required="false"
/>
<named
      name="s"
      helpstring="Show the extensions in the list."
      type="simple"
      required="false"
/>
<unnamed
      name="filetype"
      helpstring="A file type to show or ignore."
      many="true"
      required="false"
/>
<example>

********************************************* You may include any number of file types. By default, the types will be filtered from the list - use /s to filter all other types from the list. If no files types are indicated, then a full directory listing will be displayed. *********************************************

 Example:
   dirfilter /d:c:\ /s js vbs wsf
     This will display all js, vbs, and wsf
     files in the directory.

*********************************************

<object id="oShell" progid="WScript.Shell"/>

<script language="JScript">

var i; // counting variable

var bShow = WScript.Arguments.Named.Exists("s");
var cTypeCount = WScript.Arguments.Unnamed.length;
if (0 == cTypeCount)
      bShow = false;

var aList = new Array(cTypeCount);
for (i = 0; i < cTypeCount; i++)
      aList[i] = WScript.Arguments.Unnamed(i);

var sDir = oShell.CurrentDirectory;
if (WScript.Arguments.Named.Exists("d"))
      sDir = WScript.Arguments.Named("d");

var oExec = oShell.Exec("%comspec% /c dir \"" + sDir + "\"");
var sText = "";
var quit = false;
for (;;)
{
    if (!oExec.StdOut.AtEndOfStream)
        sText += oExec.StdOut.ReadAll();
   if (quit) break;
   if (oExec.status == 1)
      quit = true;
    else
     WScript.Sleep(100);
}
var aText = sText.split("\n");
var cTextCount = aText.length;

sText = "";

for (i = 5; i < cTextCount - 3; i++)
      if (CheckLine(aText[i], aList, bShow))
            sText += aText[i] + "\n";

WScript.Echo(sText);

function CheckLine(sStr, aList, bShow)
{
      var iExt = sStr.lastIndexOf(".") + 1;
      if (0 == iExt)
            return !bShow;
      var sExt = String(sStr.substring(iExt, sStr.length - 1));

      for (var i = 0; i < aList.length; i++)
      {
            if (sExt == aList[i])
                  return bShow;
      }
      return !bShow;
}

</script>

</job>
</package>

Remote WSH

The introduction of the exec command provides a more flexible way to call programs that run on the same machine, but script writers are asking for the ability to run scripts on remote machines for tasks such as remote administration. WSH 5.6 Beta 1 ships with a new object, WshRemote, that is designed to do exactly this. The WshRemote object model provides an execute method that will run a WSH script on a remote Windows machine. When you use the execute method, you provide the name of the script you want to run and the server on which you want to run it. When the remote method is called, WSH loads the script file for transmission to the remote server, starts an instance of the WshRemote object on the remote machine, and transmits the script to the remote server for execution. It isn't necessary to copy the script file to the remote server prior to running it, because WSH deals with the distribution. This should make remote administration easier to manage, because you can have one central repository for your scripts, and you can run them on any Windows machine.

Remote WSH provides considerable power, but it also allows malicious scripters to propagate viruses quickly and, in some cases, invisibly. A virus writer's dream is the last thing that the Windows Script team wanted to build, so security and access control for Remote WSH were key to its design. Remote WSH uses DCOM for its communication protocol. (We really wanted to use SOAP, but we felt that the required installation of an HTTP server on all machines and the connectionless nature of HTTP made SOAP unsuitable for Remote WSH version 1.0. We'd love to get your feedback on this, so please e-mail us or provide feedback in the comments for this article.)

DCOM provides the ability to restrict access to objects to certain users. By default, Remote WSH requires you to have administrative access rights to the machine that you are calling. We felt that this was the appropriate access control, because most of the scenarios for which Remote WSH was designed were remote administration. You can change the access rights of Remote WSH, but you should think carefully about this, because it could open up your system to abuse, just as providing access to sensitive shares would.

The access control is on a user or group basis, so Remote WSH is further constrained by not being available by default on Windows 95, Windows 98, or Windows Millennium Edition (Windows Me), because you can't authenticate users on machines that aren't part of an NT domain. It was a tough decision to make, because we're aware that the majority of home machines use those operating systems, and we strive to make WSH as functional on Windows 95, Windows 98, and Windows Me as it is on Windows 2000 and NT 4 machines. However, we felt that security was the most important factor. Because security is so important, even to machines that can provide full NT authentication, we have turned off Remote WSH by default; you have to turn it on specifically for each machine before you can run it. This ensures that machines require specific user actions before any remote code can be run.

Fixing Bugs

Quality is a huge feature for any product, and we've spent considerable time improving our code quality so that we can provide a more stable product. We hear consistently that bug fixes should be our number one priority before introducing any new features, and this release of WSH marks a new milestone in quality for the product. It is a beta release, and as you run the new features in new ways, you may find bugs that we haven't yet encountered. I encourage you to use the product and to report bugs back to us as soon as possible via the WSH newsgroup on msnews.microsoft.com.

Tools Support

WSH has traditionally had limited tools support, both from Microsoft and from third parties. The release of WSH 2.0 helped to alleviate this problem with tools such as Primalscript 2.0. Also, existing Microsoft Visual Studio editors could be "fooled" into editing .wsf files. Tools support in WSH 5.6 has improved considerably, notably in Primalscript 2.1 Beta 1 and the upcoming Visual Studio .NET.

PrimalScript abstracts the raw XML in the file into a workspace, so that you can see a graphical view of the elements in the XML, such as the objects and the new run-time features added in WSH 5.6. Primalscript 2.1 Beta 1 is available at http://www.primalscript.com/.Visual Studio .NET builds on the script-editing capabilities in Visual Studio 6.0 by integrating script editing into the new XML editing feature. You can create a .wsf file directly within Visual Studio, which provides schema help and Intellisense against the WSH XML schema. The upcoming beta of Visual Studio .NET supports the existing WSH 2.0 XML schema, and the final release will support the updated WSH 5.6 XML schema. Visual Studio also provides a full-featured debugging facility for WSH 5.6 scripts, with features such as watch windows and set next statement. You can also continue to use the Windows Script Debugger, which you can download from https://msdn.microsoft.com/scripting/debugger/.

Where to Get WSH 5.6

WSH 5.6 is in its first beta and is available from the Windows Script Web site. It will run on Windows 95, Windows 98, Windows Me, Windows 2000, and Windows NT 4. If you want to run WSH on Windows 95 or Windows NT 4, you need to ensure that Internet Explorer version 4.x or higher is installed before you install WSH. Because WSH is a key part of Windows, the current beta of Windows, codenamed Whistler, has WSH 5.6 pre-installed.

Summary

I hope this has given you a taste of what's possible with the new features in WSH 5.6 and, in particular, how we've started to address the issue of authentication and trust by introducing code signing. The feature set in WSH 5.6 is a first step to providing a solution, but it isn't the complete solution. We're working closely with the .NET Common Language Runtime and Windows teams to ensure that future versions of WSH can take advantage of the extensive code-security capabilities that those platforms provide. We're really excited by the new features and how they can make writing scripts easier. Please get back to us with your thoughts on the new features and how we could extend WSH in the future. We really appreciate your feedback no matter whether you think we'll like it.

Andrew Clinick is a program manager in the Microsoft Script Technology group, so chances are, if there's script involved, he's probably had something to do with it. He spends most of his spare time trying to get decent rugby coverage on U.S. television and explaining cricket to his American colleagues.