ActiveX Scripting Languages

VBScript is just one of many ActiveX Scripting Languages. These languages are written to a specification developed by Microsoft, and scripts written in these languages can be executed by WSH. Each ActiveX Scripting Language is implemented by a scripting engine. Usually, this DLL file interfaces with WScript.exe to interpret scripts, one line at a time, so that WSH can execute them. Microsoft maintains two ActiveX Scripting Languages: VBScript and JScript. JScript is Microsoft's implementation of ECMAScript, which is the industry-standard version of Netscape's JavaScript scripting language.

The scripting engines are maintained separately from WSH and carry their own version numbers. However, both the latest version of VBScript and JScript are included with the basic WSH installation, so you don't need to worry about getting them individually.

Other companies have produced ActiveX Scripting Languages, too. For example, VideoScript is an independent scripting language that works with WSH (www.videoscript.com). PerlScript and LiveScript are other popular ActiveX Scripting Languages.

Scripting languages all have a few common characteristics.

• They are interpreted. That means the scripting engine reads each line of script, one at a time, and then executes it. Execution requires the WSH to translate the scripted instructions into native Windows API calls. Interpreted languages are slower than compiled languages like Visual Basic 6.0, where the compiler translates the entire program into native Windows code all at once, saving time later when the program is executed.

• They are text based. In other words, you can create scripts with a simple text editor like Notepad. The downside is that anyone can read your script with Notepad, too. Most software applications' code is compiled into a native binary format, making it very difficult for end-users to read the code. Microsoft does offer an encryption utility (discussed in Chapter 27) that allows you to protect your source code from prying eyes.

• They are native. In other words, your scripts will only execute on Windows, because WSH itself will only execute on Windows. Contrast this with languages like Java, which can be compiled and executed on any platform for which a Java Virtual Machine (JVM) is available.

• They are easy to deploy. Unlike compiled Visual Basic 6.0 applications, scripts don't usually require a bunch of DLLs and other files that you have to deploy, register, and so forth. Scripts can generally be copied from one computer to another and executed as-is.

Perhaps the most powerful feature of VBScript is its capability to interface with Microsoft's Component Object Model.

VBScript and .NET: What Does the Future Hold? I'm often asked how the release of VB.NET and the .NET Framework will affect VBScript. After all, you don't hear much mention of "VBScript.NET!" It's a complicated question. The easy answer is this: Microsoft invested a lot of time and money getting administrators to use VBScript, and administrators are using it. WSH will probably be included in new releases of Windows for some time to come, even if Microsoft doesn't do any further development. However, Microsoft did release a new version of WSH for Windows XP, when .NET was still under development, so it's quite possible that VBScript will have a parallel life with .NET. Keep in mind, though, that .NET is, in many ways, a scripting language itself. It isn't compiled in the same sense that Visual Basic 6.0 applications were compiled, and new versions of Windows-starting with Windows Server 2003-will come with the .NET Common Language Runtime (CLR), essentially .NET's version of WSH. Therefore, administrators will be able to use language like VB.NET to produce easily deployed administrative scripts. .NET makes it easier to do a lot of administrative tasks, because it exposes so much of Windows' native functionality. However, the .NET learning curve is quite a bit steeper than VBScript's, so I definitely expect administrators to stick with the easier scripting language, at least for the time being. VBScript-and JScript even more so-has a long life ahead of it in Web browsers. Web browsers, including Microsoft Internet Explorer, can't execute client-side .NET code, leaving VBScript and JScript as the only viable options for client-side Web programming. Although that type of programming isn't the focus of this book, it demonstrates that VBScript is far from obsolete and remains a powerful, viable administrative tool.