When did you last update your Windows NT command processor or your batch-file environment? If scripting is new to you, you might not realize that maintaining a programming environment requires regular upgrades. You must periodically replace your older scripting tools with newer releases to keep your Windows Scripting Host (WSH) environment stable, consistent, and up-to-date. However, you need to be careful when you upgrade the important elements of your scripting environment.
WSH Refresher
To understand why caution is imperative when you upgrade scripting components, you need to understand how many separate elements play a part in Microsoft's scripting environment. Windows scripting involves much more than batch files and standalone executables. As COM increasingly permeates the Windows platform, applications and scripts increasingly call on the same system services to do their work.
When I first wrote about WSH ("NT Gains Scripting Muscle," April 1998), I described the three primary technologies that make up the Windows scripting architecture: WSH, the scripting engines, and the objects you access via WSH. WSH provides the script-execution environment, which includes wscript.exe, cscript.exe, wshom.ocx, and several .dlls. The WSH host provides the interface between your script's source file and the corresponding scripting engine. The host also exposes a few objects that provide basic systems administration functions. The scripting engines are the language interpreters within the Windows scripting environment. WSH comes with vbscript.dll and jscript.dll. Third parties can create other engines to plug in to the WSH environment. The objects that WSH gives you access to include ActiveX Data Object (ADO), Active Directory Service Interfaces (ADSI), Collaboration Data Object (CDO), Microsoft Office, Windows Management Instrumentation (WMI), and third-party components. These object models aren't officially part of WSH, but they are extremely important to WSH scripting.
Microsoft packages WSH and the Visual Basic Script (VBScript) and JScript engines together but distributes the ADO, ADSI, and WMI object libraries separately. Microsoft distributes some of these technologies via multiple software packages. For example, Microsoft includes the VBScript and JScript engines in Visual Studio (VS), WSH, Internet Explorer (IE), and Internet Information Server (IIS). However, you can download some scripting engine updates without downloading other software; for example, you can download the file scr50en.exe from http://msdn.microsoft.com/scripting to obtain only the beta 2 versions of VBScript 5.0 and JScript 5.0. Table 1, page 98, shows the methods for obtaining each version of VBScript.
The variety of packaging and distribution vehicles for Microsoft's scripting products offers administrators flexibility, but it also makes maintaining a WSH scripting environment more complex. The host and engines in the WSH environment are self-contained components. You can't use one component without the other, but you can use WSH with other ActiveX-compliant engines, such as a PerlScript engine. Likewise, you can plug in the VBScript and JScript engines to any ActiveX-compliant host. Because of this separation between the scripting host and the scripting engines, Microsoft can update WSH and the scripting engines independently.
For example, when Microsoft introduced WSH 1.0, WSH included the VBScript 3.0 and JScript 3.0 engines, the same engines that IE and IIS included at the time. Shortly after WSH's release, Microsoft addressed a security risk in the JScript engine by releasing the VBScript 3.1 and JScript 3.1 engines. The upgrades targeted a problem that was meaningless from a WSH perspective and didn't include any major changes or new functionality for WSH users. Therefore, new WSH users didn't need to upgrade. However, upgrading to new scripting engines is often worthwhile because many engine updates include not only fixes but also new language constructs and new automation objects.
Recent Releases
At press time, only the beta 2 releases of the VBScript 5.0 and JScript 5.0 engines are available for downloading from Microsoft's scripting Web site, but the final release of the 5.0 versions will probably be available by the time you read this article. The VBScript 5.0 and JScript 5.0 engines include significant changes and improvements to WSH. VBScript 5.0 includes support for user-defined objects via Classes, a new regular expression object, Eval and Execute functions, and enhanced distributed COM (DCOM) support. JScript 5.0 supports exception handling. Because of these upgrades, you'll want to make sure you obtain and install the updated engines.
However, when you upgrade your scripting engines, you'll need to make sure that the new engines don't break existing scripts or applications that use the engines (i.e., IE, IIS, or third-party applications). The VBScript 5.0 and JScript 5.0 engines' primary changes are enhancements to the VBScript and JScript languages and performance improvements, so they probably won't affect your existing scripts or applications. But when you upgrade a WSH scripting engine, you must understand the scope and potential effect that the change might have on your environment. You need to examine what technologies and applications the change might affect, and how those technologies and applications could affect your business if the upgrade causes unexpected problems.
Like the VBScript and JScript engines, the object models that WSH leverages come in different versions. Object models' version differences can cause you trouble if you're not careful. For example, ADSI 2.0 is the ADSI version that Microsoft currently officially supports. However, ADSI 2.0 isn't compatible with ADO 2.1. You might be tempted to upgrade to ADSI 2.5 beta 1 because the beta fixes the ADO 2.1 incompatibility, but I generally don't recommend deploying beta software in a production environment. Before you decide to upgrade, you must understand the dependencies of the different object models and the services they provide. Upgrading to ADSI 2.5 beta 1 might rectify the ADO problem, but problems with the beta might break other scripts or applications. Be sure that Microsoft supports upgrading to the beta before you update your production environment.
Microsoft's WSH scripting environment is significantly more advanced and more powerful than the batch-file environment you might be accustomed to. WSH has COM-savvy scripting hosts, scripting engines, and object models that resemble full-blown programming environments. Therefore, employing sensible software-upgrading and configuration-management practices will help you maintain a stable and consistent scripting and application environment.
Although you might be tempted to roll out every new scriptable widget that becomes available, I encourage you to test new scripting technologies in your lab before you implement them in your production environment. This advice is especially important for scripting engines and object models that multiple applications use. In addition to testing, you need to review the release notes that come with every new or updated technology. A product's release notes often warn users about potential incompatibilities. Fixing things that used to work isn't much fun. Unfortunately, some of us learn the hard way.
