An essential tool of system administrators and power users has been the shell script or batch file (depending on your OS).  Unix shell scripts offer an unparalleled combination of ease of use and power.  DOS batch files were not as easy to use and were missing many of the tools available in Unix, but were still very useful for automating everyday tasks.

However, longtime Microsoft observers will note that each version of Windows has had less power available to batch files than the version before.  There is no longer even a way for the user to input a choice to a batch file.  Clearly, Microsoft has done this deliberately.  Of course, system administrators and power users still clamor for automation tools.  Microsoft has responded with the Windows Script Host, which you have on your system if you have Internet Explorer version 5.0 or later installed in Windows.  (If you have an earlier version of Internet Explorer, the Windows Script Host is available as a separate download.)  Why the transition from batch files to Windows Script Host scripts?  In my opinion, it is because Microsoft would rather have you use a technology they invented rather than a technology where they are second best to a rival OS.

The Windows Script Host was a direct result of the tremendous effort Microsoft exerted to create Internet Explorer (sometimes abbreviated IE).  One of the things IE needed was a Javascript (or, as Microsoft calls it, JScript) engine.  Microsoft also decided to use JavaScript's rival scripting language VBScript in ASP, so that engine was available also.  It was a natural progression of things to create a host executable that would enable running JScript or VBScript outside of IE or IIS (Microsoft's Internet Information Server, used to host ASP pages).  Thus the Windows Script Host was born.

Javascript and VBScript by themselves can't do much; they don't even have the power to output anything to the user!  What they can do is make use of any COM object that has an automation interface.  Microsoft for years has been creating its major applications, e.g. Word, Excel, etc., as collections of COM objects that support automation.  In addition, several objects have been created especially for the Windows Script Host or IE.  All these objects make a Windows Script Host script potentially very powerful indeed.  Such a script can have complete control over the file system, can create or modify Word or Excel documents, can send email if you use Outlook or Outlook Express, and so on.

That's the good news about the Windows Script Host.  The bad news is that all this power comes at a price.  The price is that it is quite a bit more difficult to write a Windows Script Host script than a batch file or Unix shell script.  To do just about anything worthwhile, a script must use a COM object.  While the Windows Script Host completely hides the complex nature of the COM interface so familiar to many Visual C++ programmers successfully, you still are responsible for knowing an object's properties and methods, complete with calling parameters, in order to use the object.  For example, in a batch file, to copy a file you might use the command " copy c:\articles\article.txt ..".  That was straightforward and intuitive, at least to a programmer used to such things.  With the Windows Script Host, you invoke the CopyFile method of the FileSystemObject object.  The method's first parameter is the source filename, the second is the destination filename, and the third optional parameter specifies whether an existing file shall be overwritten if found.  You must know all this to copy a file, because you don't get any hints.

This becomes rather difficult because when writing a script you must constantly have the documentation open.  But what makes it worse is that like any script, you are probably writing it in an ordinary text editor.  As far as I know, Visual Studio .NET is the only programming environment that provides specialized tools (IntelliSense, etc.) for editing Windows Script Host script files.  Since Visual Studio .NET is an expensive specialized tool for programming, many people won't have it.  If you don't have Visual Studio .NET, when you need to debug a script you will likely be forced to resort to the equivalent of putting ECHO statements into the code as a debugging aid.  Actually, it's worse than that, because with a ECHO statement, at least you could have the output from several ECHO statements on the screen at once; with the Windows Script Host you must pop up a dialog with an OK button containing your debugging text, and only one dialog can be shown at a time.

Another difficulty is that Windows Script Host scripts typically interact with users by popping up dialogs.  If the script is not designed to be run unattended, and your script does something for a long time without popping up a dialog, your users will become restless because there is no indication of anything happening -- not even an hourglass cursor.  It is possible to see that your script is still running if you are using Windows NT or a descendent because "wscript.exe" will be in the task list, however.

Once you have mastered the Windows Script Host, you will discover that your script is about 90% as complex as the equivalent C, Delphi, or Visual Basic program doing the same thing.  But those other environments are all much richer, because they include specialized editors, integrated debuggers, proper Windows forms, and so on.  If you are a typical Windows programmer, you would rather eat nothing but plain white rice the rest of your life than give up your context-sensitive editor, property and method hints, breakpoints, and variable watches.  If you have access to any modern advanced programming language with an IDE, spare yourself the trouble and use it instead of the Windows Script Host.  Or else re-engineer the old batch file commands now missing such as "choice".