A Whoa there—COM is a very loving and accepting environment. And besides, some developers like to write scripting code. In certain situations scripting is a viable way to get your computing done. Although you sacrifice some programming power when using a scripting language, there are several distinct advantages. Scripting code is usually easy to write and test. In addition, scripting provides a dynamic environment that is useful for both prototyping and making changes on the fly.
   Scripting was first introduced in Windows® with the early releases of Visual Basic®. Once Visual Basic became a compiled language, the main use for scripting became programming Web pages. Developers write scripts to respond to events on a Web page and on the server itself to generate the HTML that is sent to the browser client. And while it has been easy to use COM objects within your scripting code, those COM objects had to be written using a higher-level language like C++, Java, or Visual Basic. But remember that the main issues addressed by COM are software distribution and runtime integration. COM tries to be as language-agnostic as possible, and now you can employ scripting not only for using COM objects but for writing them as well. The Windows Script Components (WSC) let you package scripts for use as COM components.

The Big Picture
   From a high level, WSCs are simply Extensible Markup Language (XML) files containing some scripting code that exposes a COM class. I'll show you some XML that does this in a minute. XML is a markup language very much like HTML, which allows you to apply tags to a document. However, XML is a much more flexible markup language. Whereas both XML and HTML are used to describe the formatting and display characteristics of a document, XML tags can do much more, such as describe the semantic and organizational structure of a document.
   Writing a component based on scripting entails writing a bit of XML that conforms to the WSC syntax. Figure 1 shows a WSC-compliant XML file. The code in this file represents the infrastructure for a scripting component. Notice the various tag elements throughout the file.
   The statement in the first line of code in Figure 1

 <?xml version="1.0"?>

A VBScript Component
   The distance converter project will consist of two simple functions: MilesToKilometers and KilometersToMiles. The component will also have properties for holding cumulative miles and cumulative kilometers. Figure 2 shows the VBScript version of the distance converter.
   In addition to the scripting infrastructure described in Figure 1, the distance converter component in Figure 2 includes <property> and <method> tags and some code inside the <component> tag. The <property> tag indicates the properties of the object that are available to clients. There are two properties: CumeMiles and CumeKilometers. These properties are both readable and writeable because the component text describes ways to retrieve and set the properties (notice the <get/> and <put/> tags). The <method> tag describes the methods available on the object as well as their parameters (via the <PARAMETER> tag). The information included in this section of the XML is purely declarative. The actual property and method definitions occur within the scripting section.
   The actual script code begins with the <script> tag. Because the <script> tag indicates VBScript as the scripting language, variables and methods are defined using the VBScript dim statement. This is where the CumeMiles and CumeKilometers properties and the accessor and mutator functions are defined. The conversion methods are simple VBScript functions that convert from miles to kilometers and vice versa, and return the result to the client.

The JScript Version
   The script component file in JScript differs slightly from the VBScript version. Figure 3 shows the distance converter component written in JScript. Note that the infrastructure for the JScript version of the component is the same. This version defines the CumeMiles and CumeKilometers properties with read and write access. The code in Figure 3 also has MilesToKilometers and KilometersToMiles functions.
   The major differences between the VBScript and the JScript components are found within the script section of the WSC file. Note that the JScript code within the script portion of the WSC file looks much more like the Java language or C++ than VBScript. Apart from the variable declarations (which begin with a var keyword), the code uses functions, and all statements end in semicolons. The other main difference in the code is the DistanceConverterJScript constructor, which sets up the component's properties and methods.

The Runtime
   Now that you have these two files with some scripting code inside them, how do they become COM objects? That question is easy to answer by looking at the registry entries for a component written in a scripting language:

 HKCR
    CLSID
       {F3DA80D0-9B63-11D3-8069-367A6D000000}
          InprocServer32 = c:\WinNT\System32\srcobj.dll
             ThreadingModel = "Apartment"
          ProgID = "DistanceConverterJScript.WSC.1.00"
          ScriptletURL = "file://D:DistanceConverterJScript.wsc"

Registering the Script Object
   Once you have the file for the scripting object written, you need to get that information into the registry. There are several ways to make this happen. You can use regsvr32—the handy utility for registering any COM class—or use Windows Explorer.
   A new version of regsvr32 ships with the scripting components. Its command line looks like this:

 regsvr32 file:\\d:\DistanceConverterJScript.wsc

 regsvr32 scrobj.dll /n /i:file:\\d:\DistanceConverterJScript.wsc

Script Components and Type Libraries
   The beautiful thing about COM is the way components are components. The client doesn't typically care what goes on behind the veil of interfaces. Script components are simply regular COM components dressed in script clothing. Naturally, if you have a component, sooner or later you'll run into a client that wants to use a type library describing your component.
   As it turns out, you can create a type library for your script component using one of three methods. The first is to create the type library programmatically by using the script component's runtime type library generator. Within your scripting component, you can create the type library generator using the CreateObject API, which gets you a pointer to the type library generator. You then point the type library generator to your scripting file (the WSC file), give your type library a name, and ask the type library generator to write the type library. When you put the registration code in the <registration> portion of your WSC file, the type library will be created when you register the script component in the regular way.
   The second way is to ask the WSC file to generate a type library for you by using the RUNDLL32 utility. SCROBJ.DLL has an entry point named GenerateTypeLib that will generate the type library given some command-line parameters. For example, the following command line creates a type library for a scripting component:

 rundll32.exe c:\winnt\system32\scrobj.dll,GenerateTypeLib 
    -name:DistanceConverterJScriptTLib  
    -file:d:\DistanceConverterJScript.tlb 
    -doc:\"DistanceConverterJScript typelib\" 
    -guid:{6576834a-a252-11d1-9fa1-00a0c90fffc0} 
        -major:1  -minor:0 
    -URL:d:\components\MyComponent.wsc

The Windows Script Component Wizard
   As with all things COM, writing scripting components entails gobs of boilerplate code. That's a perfect reason to use a Wizard to generate scripting components. You can get a wizard that does this directly from the Microsoft Web site at http://msdn.microsoft.com/scripting.
   When you run the wizard, the first screen asks you to name your scripting component and point out a directory to dump the source code. The second screen lets you choose the scripting language to use (see Figure 4). You can pick VBScript, JScript, or another scripting language, provided you have the right scripting engine installed on your machine.