Windows Script Host overview
You can use Windows Script Host to run scripts by clicking a script file on the Windows desktop or by typing the name of a script file at the command prompt. Similar to Microsoft Internet Explorer, Windows Script Host serves as a controller of Windows Script-compliant scripting engines. Unlike Internet Explorer, Windows Script Host has very low memory requirements and is ideal for both interactive and non-interactive scripting, such as logon scripting and administrative scripting.
There are two versions of the Windows Script Host: a Windows-based version (Wscript.exe), which provides a property sheet for setting script properties, and a command-prompt-based version (Cscript.exe), which provides command-line switches for setting script properties. You can run either of these by typing Wscript.exe or Cscript.exe at the command prompt.
Previously, the only native scripting language supported by the Windows operating system was the MS-DOS command language. Although MS-DOS is fast and small, its features are limited compared to VBScript and JScript. For example, the ability to control program flow was not built into the language. Today, the Windows Script Host architecture allows you to take advantage of these powerful scripting languages, although support is still provided for MS-DOS command scripts.
Windows Script Host supports scripts that are written in Visual Basic Scripting Edition (VBScript) or JScript. When a script is started from the Windows desktop or from the command prompt, the script host reads and passes the contents of the specified script file to the registered script engine. The script engine uses file name extensions (.vbs for VBScript; .js for JScript) to identify the script instead of using the SCRIPT tag (used in HTML). Because of this, you do not have to be familiar with the exact programmatic identifier (ProgID) of the script engines. The script host itself maintains a mapping of script extensions to ProgIDs, and uses the Windows association model to start the appropriate engine for a given script.
This version of WSH adds several areas of new functionality:
Improved argument handling
Handling and documenting command-line arguments is now simpler.
You can load a script onto several remote computer systems which you can then run at the same time.
A running process is an object
You can query the spawned process, sink its events, access its standard I/O streams, and share its environment variables with other processes.
The current working directory
You can determine and modify the path of the current working directory of the active process.
Script security issues
The new script security model makes it safer to distribute and run scripts.
For more information, see the Windows Script Technologies Web site at the Microsoft Web site.