Building a library of reusable code is helpful because you don’t have to keep reinventing the wheel each time you automate a new task. If you want to use a scripting language to write reusable code, one option is to use Windows Script Components—WSC. (You can write reusable code several ways. To learn about the various options, see the sidebar "Is WSC Right for You?")
What Is WSC?
WSC is primarily a feature of Windows 2000 and Microsoft IIS 5.0, but you can install WSC in earlier Windows platforms as an add-on. To install WSC, you need to install either Microsoft Internet Explorer (IE) 5.0 or later or Windows Script (WS) 5.5, which contains WSC. You can download WS 5.5 from http://www.microsoft.com/msdownload/vbscript/scripting.asp. Although WSC is a native object of IE 4.0 and Windows 98, Win98’s WSC (formerly called XML Scriptlets) supports a slightly different syntax and isn’t fully compatible with Win2K’s WSC. In this article, I cover the Win2K syntax. For information about the Win98 syntax, see the Microsoft Developer Network (MSDN) article "Writing COM Objects with Scripting Languages".
A WSC object is basically a COM object made of scripting code. The WSC object works like a COM object. However, the WSC object isn’t a compiled binary file like most COM objects but rather an XML file that exposes a list of properties and methods that you implement through scripting code. You can use any scripting language to implement these methods and properties, as long as you run the code on a Windows-compliant scripting engine. IE 4.0 and later has such an engine for VBScript and JScript. Third-party engines for languages such as Perl, Rexx, and Python are available on the Internet.
To write a WSC object, you need to create an XML file that complies with a particular schema. This XML file has a .wsc extension and contains three types of information:
- The object’s description, which consists of the registration, programmatic identifier (ProgID), class identifier (CLSID), and version number
- The programming interface, which consists of the object’s methods, properties, and events
- The scripting code for each method, property, and event
A system-provided runtime engine processes the WSC object’s XML source code. You might be wondering how a COM-aware client can talk to a text-based file and treat that file like a compiled binary COM object. The executable modules (i.e., .dll or .exe files) that implement COM objects are pieces of compiled binary code that clients recognize. The executable module that implements WSC objects (i.e., the WSC runtime engine, which is a system file called scrobj.dll) is also a piece of compiled binary code that clients recognize. Clients can't perceive the difference between a WSC and COM object, but they recognize the appropriate compiled binary module when they attempt to instantiate a WSC or COM object.
When a client instantiates a WSC object, the client goes through the usual series of actions to instantiate a COM object. The client reads the path to the executable that renders the object (i.e., the WSC runtime engine) and starts talking to that engine. The engine acts like a proxy and makes the WSC object’s methods and properties available to clients. The engine resolves any method or property call in the scripting code.
Creating a WSC Object
Listing 1 presents a .wsc file that creates a simple WSC object that you can use to display a message box. The file includes XML tags that define the WSC object and its behavior. Because XML files are similar to HTML files, the XML tags are similar to HTML tags. Let's analyze the XML source code in detail.
The first line in Listing 1 declares the XML document compliant with version 1.0 of the XML standard. This directive doesn’t directly affect how the system treats the .wsc file.
As I mentioned earlier, a .wsc file contains three types of information: the WSC object’s
description, programming interface, and scripting code. You describe the object with the
Listing 1 contains the minimal content for the
If you're familiar with the COM fundamentals, you know that a generic COM object must have a 128-bit CLSID but the progID is optional. Because a WSC object is a COM object, the progID is theoretically optional. However, in practice, a progID is necessary because you’ll be using the WSC object as a COM automation object (i.e., a COM object that exposes methods and properties so that other applications can programmatically drive it). Without a progID, the WSC object is unusable because the CreateObject function needs the progID to instantiate the object for further use. Instead of omitting the progID, you can omit the CLSID in the
To expose their functionality, COM objects implement interfaces. All COM objects implement the basic IUnknown interface and make this interface available to callers. In addition, COM objects can implement and make available other interfaces. A WSC object can implement a limited number of interfaces. These interfaces fall into three groups:
- Interfaces needed for automation and event handling (i.e., automation interfaces)
- Interfaces needed for Active Server Pages (ASP)
- Interfaces needed for IE 5.0 behaviors
For now, I concentrate on how to create automation-interface WSC objects. I cover the ASP and IE interfaces later.
The WSC syntax doesn’t dictate that WSC objects implement an automation interface.
However, in practice, any WSC object must implement this interface. To declare the automation
interface, you use the
You can assign the
In addition to declaring the Title property and its privileges, the