The Windows Scripting Host

ENT, Nov 19, 1997

Microsoft is adding a scripting engine to both Windows NT and Windows 95. The scripting engine is known as the Windows Scripting Host (WSH) and is available as part of Internet Information Server 4.0 and on the Windows NT Distributed Services Preview CD.

WSH provides a command-line and Windows-based scripting environment. The WSH scripting environment can run either VBScript or JScript languages. The WSH environment is also designed to accept other script engines. For instance, someone will most likely create a REXX script engine that plugs into WSH.

The script environment is provided by two executables: Wscript.exe and Cscript.exe. Both install automatically when you install WSH. Wscript.exe enables you to provide a Windows interface for scripts, while Cscript.exe enables you to provide a character-based interface. You can usually run the same script with either engine.

To execute a script, you can double-click the script file in Windows Explorer, create a shortcut for the filename and execute the shortcut, or open a Command Prompt window and execute the file directly with one engine or the other.

The syntax you would use at the Command Prompt to execute a script file would be cscript [host options] scriptname [script options]. This translates into a command such as cscript network.vbs. This command executes the network.vbs file from the command prompt with a character-based interface. You can also execute the same file with the Windows interface by using this syntax: wscript network.vbs. This command executes the script file the same way as the first one, except that all input and output is done through the Windows interface.

Why is WSH such a big deal? For years we have been using the DOS batch language to automate tasks and build utilities for DOS and all versions of Windows. This language was OK for DOS and early versions of Windows, but ran out of gas when we started using Windows NT on the network. We needed a robust language that not only let us execute file and network commands, but also provided an interface to the Win32 API and to COM objects.

These features were required because of the multitude of tasks that are performed by the network and system administrator. Most folks who grew up on NetWare and Windows NT do not realize the power that scripting languages provide and how vital they are to successful system implementations. Those of us who grew up on mainframes and minicomputers do not see how we can survive without a good command language.

We have been spoiled with those good command languages, such as Digital's DCL, because they had so many native operating system features. We used those features to create all types of extensive utilities that could automate many different types of tasks. There are also many DCL utilities, for example, that we could create to provide management tools for the system manager.

As I mentioned in earlier columns, we can use Visual Basic to perform many of these tasks on Win32 versions of Windows. Visual Basic is great, but it requires purchasing an additional software package (Visual Basic), learning the language and the environment, and then figuring out how to use the Win32 API and other objects that provide the features you need.

WSH fills in the gap between the DOS batch language and Visual Basic. Now you can develop scripts quickly that do not need compiling. WSH also contains the Windows Scripting Host Object, which provides access to operating system features such as shortcuts, the network interface, and more. You can also use the Active Directory Services Interface (ADSI) with WSH. ADSI exposes many underlying features of Windows NT via the ADSI object model.

You can find out more information on WSH from www.microsoft.com/management/ScrptHost.htm. Information on the Windows Scripting Host Object is available from www.microsoft.com/msdn/sdk/inetsdk/help/wsh/wobj_12.htm.> --Ken Spencer is with 32X Inc. (Greensboro, N.C.). Contact him at kenspencer@32x.com or via the Web at www.32x.com.