Microsoft

Uniting the VBScript and JScript scripting languages with Windows Script Files

When working with VBScript and JScript scripting languages, you now have a new tool for importing them into one file. The XML-based Windows Script Files can handle the task, as Greg Shultz explains in part one of a two-part Daily Drill Down series.


When Microsoft introduced Windows Script Host 2.0, it included a new script file format called Windows Script Files. This new script file format expands the capabilities of the Windows Script Host environment in new directions because it’s essentially an XML file format. As such, this new scripting file format brings with it several new features, such as support for type libraries and the ability to include previously written functions in a file.

One of the biggest benefits of the Windows Script File format is that it allows you to combine code from both the VBScript and JScript scripting languages in a single file. This will allow you to expand your scripting capabilities and break free of the limitations inherent in any one of the supported scripting languages.

In part one of my Daily Drill Down series on uniting the VBScript and JScript languages with Windows Script Files, I’ll show you how to combine code from both languages and explain how to take advantage of this feature when you’re creating scripts. Also, I’ll introduce you to the XML features in the new Windows Script File format. In part two, I’ll provide techniques on how to use Windows Script Files to combine sample code from VBScript and JScript languages.

Getting started with Windows Script Files
Windows Script Files have the file extension .wsf. You can create Windows Script Files in any text editor that’s capable of saving files in ASCII format, such as Notepad. You can also create Windows Script Files in any XML editor.

Windows Script Files can be run just like VBScript and JScript files—by double-clicking on the files in Windows Explorer or by running them from the command line in a DOS prompt. This is possible because the Windows Script File extension .wsf is registered as a file type to the Windows Script Host.

The Windows Script File’s XML format
Before we get started, you need to understand how a Windows Script File makes use of the XML format. To begin with, every Windows Script File you create should begin with the XML declaration
<?XML version=”1.0”?>

This declaration specifies that the file will adhere to the rules set forth in version 1.0 of the XML language. In addition, this declaration will force Windows Script Host’s script component compiler into a strict XML mode, which will ensure that all the XML tags contained in the script are properly handled. For example, this will indicate that all XML tags are case sensitive, must have closing tags, must be properly nested, and that all additional attributes must be enclosed in double quotes, among other things. If you don’t put the version declaration into your Windows Script File, the Windows Script Host’s script component compiler will accept a looser XML syntax, which could cause strange errors and send you off on debugging sessions full of wild goose chases.

The next line in a Windows Script File should be the XML processing instruction that specifies the attributes for error handling:
<?job error="true" debug="true"?>

This line makes it possible for the Windows Script Host’s script component compiler to notify you of errors that occur at compilation and run time. In this line, setting error to true allows the display of error messages, while setting debug to true allows the script debugger to process the Windows Script File.

The Windows Script File’s XML tags
Aside from the XML version declaration and the error handling, Windows Script Files support five XML elements or tags:
<job>
<package>
<script>
<object>
<reference>


Let’s take a general look at each of these XML tags. I’ll go into more detail on how each tag is used in a Windows Script File a little later on when I show you some actual scripts.

The <job> tag
The <job> tag is the central component in a Windows Script File in that this tag identifies the location in the file where the code that performs the main task in the script begins. The syntax for the <job> tag is:
<job [id=”jidentifier”]>
code…
</job>


The optional id=”jidentifier” argument can be appended to the <job> tag in order to assign the job a specific name. This comes in handy when you have more than one job in a Windows Script File. Of course, the <job> tag has a corresponding closing tag that comes after the code—</job>.

The <package> tag
The <package> tag is an optional tag that can be used to enclose the <job> and </job> tags. If the Windows Script File contains more than one job, the <package> tag is required. The syntax for the <package> tag is:
<package>
<job [id=”jidentifier”]>
code…
</job>
<job [id=”jidentifier”]>
code…
</job>
</package>


As you can see, the <package> tag has a corresponding closing tag—</package>.

Before I move on to the next XML tag, it’s important you understand that when you use more than one job in a Windows Script File, only the first job is run by default. This means that if you simply run the Windows Script File by double-clicking the file or by typing its name on the command line, the first job will run and the second job will be ignored. If you want to run the second job, you must specify the job id on the command line. I’ll cover this in more detail in a moment when we look at some examples.

The <script> tag
Since the main operation performed by a Windows Script File is going to contain either VBScript or JScript code, there needs to be an XML tag that sets this code apart from the rest of the script. To do so, you’ll use the <script> tag. The syntax for the <script> tag is:
<package>
<job [id=”jidentifier”]>
<script language="scriptlanguage" [src=”filename”]> 
code…
</script>

</job>
<job [id=”jidentifier”]>

<script language="scriptlanguage" [src=”filename”]> 
code…
</script>

</job>
</package>


As you can see, the <script> tag has two arguments—one required and the other optional. The language=”scriptlanguage” argument is required; it is used to tell the Windows Script Host which scripting language engine to load. For example, <script language=”VBScript”>.

Now, the optional src=”filename” argument is a key component in the Windows Script Host 2.0 specification. It allows you to include previously written code in your Windows Script File by providing a way for you to link an external file to the current file. This external file can be either entire VBScript or JScript scripts or files containing just the functions or subroutines that you want to be able to use in the current script without having to rewrite them. Keep in mind that when you reference an external file in this manner, what you’re actually doing is importing the contents of that file into the current file.

Another important thing to keep in mind is that the imported file must be written in the same language as specified by the corresponding language=”scriptlanguage” argument. For example, <script language=”VBScript” src=”funcfile.vbs”>. I’ll go over this in more detail when I show you some Windows Script File examples.

Looking at the character data delimiter
Before I move on to the next XML tag in the list, I need to introduce you to the character data delimiter <![CDATA[ ]]>. When you’re creating a typical Windows Script File, you’ll be combining XML with some form of scripting language. Because XML and the scripting languages can use similar code that indicates totally different operations to the language compiler, you’ll find that it’s beneficial to get into the habit of further encapsulating your scripting code in special character data delimiter tags.

For example, in XML the ampersand (&) is a reserved character, while in VBScript it is a concatenation character. If the XML compiler encounters the & character in a section of VBScript code, it will assume it is part of an XML command line, and when it doesn’t find the rest of the corresponding characters, it will generate an error.

To avoid these types of problems, you should encapsulate your scripting code in the character data delimiter tags, as shown here:
<package>
<job [id=”jidentifier”]>
<script language="scriptlanguage" [src=”filename”]>

<![CDATA[ 
code…
]]>

</script>

</job>
</package>


The <object> tag
The <object> tag allows you to enable an object in the XML section of your Windows Script File, rather than in the script section. This has the advantage of allowing you to make the object a global one that is accessible from any and all scripts sections in the Windows Script File. The syntax for the <object> tag is:
<package>
<job [id=”jidentifier”]>

<object  id=”oidentifier” [progid=”pidentifier” | classid=”cidentifier”]/>
<script language="scriptlanguage" [src=”filename”]>

<![CDATA[ 
code…
]]>

</script>

</job>
</package>


In this case, the oidentifier is like an object variable you’d create with the Set command in VBScript that you would then use to access the properties and methods that the object makes available. The pidentifier is then the ProgID or name of the object, while the cidentifier is the CLSID or class number of the object.

The <reference> tag
The <reference> tag is a useful addition to the Windows Script Host because it allows you to do something that simply isn’t possible in either VBScript or JScript: reference constants that are a part of an object’s type library. In addition to properties and methods, many objects’ type libraries have constants that can be very useful, having the ability to directly access them from within a script file can be a real time-saver. The syntax for the <reference> tag is:
<package>
<job [id=”jidentifier”]>

<reference [object=”pidentifier” | guid=”tidentifier”][version=”videntifier”]/>
<script language="scriptlanguage" [src=”filename”]>

<![CDATA[ 
code…
]]>

</script>

</job>
</package>


Here, pidentifier is the ProgID or name of the object and tidentifier is the CLSID or class number of the type library that you want to reference. In this case, videntifier is an optional attribute that specifies the version number of the type library. If it is left out, the version number of the type library is assumed to be 1.0.

The advantages of combining languages in one file
Now that you have a basic understanding of which XML tags are available and how to use them in a Windows Script File, let’s discuss a few of the main advantages of combining code from both the VBScript and JScript programming languages in Windows Script Files.

To begin with, while both VBScript and JScript have similar features, they’re not identical. For example, VBScript provides you with the MsgBox function, which allows you to display the results of a computation. However, JScript doesn’t have an equivalent function. Conversely, JScript provides you with a more extensive list of operators than VBScript does. When you are able to incorporate code from both scripting languages into one Windows Script File, you can take advantage of features from both scripting languages. In other words, this is one instance where you can have your cake and eat it, too.

Having the ability to combine scripting code from different languages also allows you to share code between languages. For example, if you have a great function that’s written in JScript but you prefer to use VBScript, you can insert the JScript function in the Windows Script File and then call it from within your VBScript code. The opposite is true, as well—you can call a VBScript function from within your JScript code. This allows you to continue scripting in the language you’re most comfortable with and will save you the time and effort that would be required to translate the function from one scripting language to another. In part two, we will take a look at five different ways that you can combine the two scripts in one Windows Script File.

About Greg Shultz

Greg Shultz is a freelance Technical Writer. Previously, he has worked as Documentation Specialist in the software industry, a Technical Support Specialist in educational industry, and a Technical Journalist in the computer publishing industry.

Editor's Picks