The Windows Scripting Host (WSH) is the successor to the
venerable DOS batch file format. WSH will be a standard feature of all future versions of
both Windows 9x and Windows NT.
There's good news and bad news about WSH.
The good news is, WSH incorporates both the JavaScript and VBScript engines that first
appeared in Microsoft's Internet Explorer and Internet Information Server (IIS), allowing
batch files (now called scripts) to be written in either language. Instead of the familiar
BAT file extension, JavaScript filenames end in JS, while VBScript filenames end in VBS.
WSH supports all the standard features of both languages, including subroutines and
functions, variables and arrays, true if/else statements, other flow-control statements
that allow sophisticated looping and much more.
The good news doesn't stop there. WSH also provides several new functions that can be
called by scripts. These functions, implemented as methods of a special Shell object,
allow scripts to create, read, write and delete Registry entries, create and modify
Windows shortcuts, map network drives and printers, and even retrieve and modify values
stored in DOS environment variables.
Other available methods allow scripts to display small dialog boxes, containing text and
buttons, and detect which button a user clicks. As a result, scripts can be interactive,
allowing a user to make simple Yes/No or OK/Cancel choices that affect actions taken by
the script. WSH scripts can also launch other applications, scripts and traditional batch
files. They can control, via exposed methods and properties, applications that support
ActiveX Scripting (such as IE, Word and Excel).
Microsoft even provides two complete versions of WSH. One (CSCRIPT.EXE) is a command-line
utility that can run in a DOS box under either Memphis or Windows NT 5.0. The other
(WSCRIPT.EXE) is a standard 32-bit Windows application. Either can be chosen as your
default scripting host (the one that runs automatically when a user double-clicks or runs
a script file). Both versions support all JavaScript, VBScript and WSH features.
The ability of WSH-hosted scripts to work with Registry entries and shortcuts makes it
clear Microsoft designed WSH to help system administrators and software vendors write
robust, user-friendly installation and configuration scripts. It's also a great way to
integrate several applications, allowing them to automatically carry out complex tasks not
possible when applications act alone. Microsoft also hopes third parties will create WSH
script engines for languages other than JavaScript and VBScript, allowing future scripts
to be written in popular languages like REXX and Perl.
Now the bad news: WSH doesn't include functions that allow scripts to work with hard disk
files. It's hard to imagine an installation program or administration script that doesn't
need to create, read, write or delete hard disk files, scan directories or check the
version information found in most executable files. Without these functions, it's hard to
see how WSH will achieve its full potential.
For security reasons, the JavaScript and VBScript languages have always lacked disk I/O
and Registry manipulation functions, preventing a malicious Web page from destroying
information on your hard disk. That's why Microsoft implemented WSH's Registry functions
as methods embedded within WSH itself. Keeping the Registry functions inside WSH makes
them available to local scripts running under WSH on a user's computer, but deprives
Web-based scripts of this capability.
Hopefully, Microsoft will take the same approach with hard disk I/O functions, allowing
scripts to work with disk files and directories without relying on external programs. If
it does, WSH might finally let us say good-bye to DOS batch files once and for all.
|
