Why Use WSH?

You typically have many options when creating scripts in the Win32 environment. You might be able to script a task using Visual Basic Script (VBScript) within Windows Scripting Host (WSH), VBScript within the context of a Web page, or Visual Basic for Applications (VBA) within one of the Microsoft Office applications (e.g., Word).

How do you decide which approach to take? In many respects, the choice is a matter of personal preference. However, I prefer to use WSH for several reasons:

Centralization. With WSH, you can keep all your general-purpose scripting efforts within one environment and, presumably, within one folder. Centralization minimizes confusion and makes the interface to all your scripts consistent. You simply go to the folder and double-click on the desired script rather than, say, opening a Word document to access a utility that cleans up temporary directories.

Versatility. With WSH, you can use tools written in scripting languages other than VBScript. If you find a JScript utility that does exactly what you want, you don't have to port the utility, as you would have to do if you were using, for example, VBA within Word documents.

Security. The 5.0 version of the scripting engines for VBScript and JScript let you encrypt scripts. Encryption keeps others from tampering with your code.

Functionality. A script that affects local files and directories won't work within the Internet Explorer (IE) or Netscape Navigator environment, because of the security schemes that these applications impose. WSH scripts that affect local files and directories will work in the IE and Navigator environment. In addition, WSH lets you incorporate Web digest functionality into other scripts, such as logon scripts.