Tales From the Script
When the summer movies come to town, the script is secondary to the special effects. The same has been true for Windows, an operating system with loads of special effects, which has always lacked a built-in scripting language. In the same way an actor can demand better scripts once he proves his worth, the high-flying Windows platforms are also finally getting some decent scripts. The feel-good hit of the desktop and command line is sure to be the sleeper known as the Windows Scripting Host (WSH).
"What about the classics: DOS batch files?" DOS batch files only recently learned how to launch Windows applications. What we want is a scripting language that will let us control Windows applications. Oh yeah, and a few of the trappings of a real programming language would be nice. After all, this isn’t a no-name operating system, it’s a star. If there was an exclusive club for only high-powered scripting languages, DOS would spend its evenings on the sidewalk outside the club -- especially if the bouncer knew Perl, REXX or any UNIX shell.
Some great independent scripting languages have taken up some of the slack in Windows scripts. While an Oscar nomination may be due to stalwarts like WinBatch from Wilson WindowWare Inc. (Seattle, www.windowware.com), even a great add-on cannot take the place of an operating system’s built-in scripting language. A scripting language is truly useful only when it’s available on every box in the enterprise. With Windows 98 and Windows NT 5.0, WSH will ship with the operating system. Until then, you’ll have to download and install it from www.microsoft.com/management/wsh.htm.
As soon as you install WSH, you’ll be able to run VBScript and JScript programs directly from the desktop or command line, without a heavy-duty host program such as Internet Explorer or Internet Information Server (IIS). Both scripting languages offer a solid set of features. I was able to read a directory into an array and write a bubble-sort in a couple of minutes using VBScript. Not a monumental programming task, but one that would be a real pain in a DOS batch file.
In addition to providing two hosted scripting languages, WSH provides an ActiveX control, Wshom.ocx, which enables script access to some useful operating system resources. Network connections, environment variables, shortcuts and even the Windows Registry can be manipulated using this new control.
There are two surprising twists to WSH. The first is that the language can easily control COM objects. Any object that exposes an OLE Automation interface can now be put through its paces from a simple script. As a result, the capabilities of the WSH scripting languages are virtually unlimited. The use of COM objects for even simple tasks such as echoing a line to the terminal makes WSH scripts a little verbose. I guess it beats the Unix alternative, where every command is packed into as few characters as possible.
The second twist is that WSH isn’t really about VBScript or JScript at all. It’s about hosting any and all batch languages. Any scripting language that provides support for the COM interface IActiveScriptParse, can be hosted by WSH. If the new scripting language supports COM object creation, it will have access to the same operating system resources as the Microsoft scripting languages via the Wshom.ocx control. Windows chooses the appropriate scripting language to activate by looking at a file’s extension, using the registry to choose the appropriate script host, and then uses the appropriate host’s IActiveScriptParse interface to call the ParseScriptText method. Voila, the script is hosted. Watch for third-party WSH versions of Perl, REXX and others. With WSH, Windows scripting will come in more languages than the entries at the Cannes Film Festival.
When it comes to production values, WSH is a little uneven. Although undocumented, when I encountered an error box while running a WSH script, I was usually able to launch Visual J++ 6.0’s just-in-time debugger. Using the debugger, I could examine variables, step through code and generally find my mistakes. Pretty slick. Unfortunately, the debugger didn’t work when a script caused a GPF, and I did encounter quite a few in my testing. I found that my environment became unstable after running some scripts. Also, the WSH environment does not offer any type of mouse control or keystroke logging. If you want script control beyond launching a Windows application, the program must support an Automation interface.
Once Microsoft gets the kinks out of WSH, its going to be an important part of the Windows operating system. For now, I found writing WSH scripts a nice bit of escapism entertainment from a summer of cranking out C++ code. -- Eric Binary Anderson is a Development Manager at PeopleSoft's PeopleTools division (Pleasanton, Calif.) and has his own consulting business, Binary Solutions. Contact him at [email protected]