You can start scripts from a variety of places. Scripts permeate every part of Windows XP. For example, you’ll find scripts in your browser and most likely your word processor as well. A script can make the difference between an application that works well and one that only performs simple tasks.

Scripts use something known as the Windows Scripting Host (WSH) to run. WSH is an interpreter, something that reads human words and converts them into machine language that the computer can understand. WSH is extremely flexible. It can run a number of languages if you install the required support. Windows XP comes with support for both JavaScript (JS files) and VBScript (VBS) built in. The VBS files normally have a Visual Basic Editor (VBE) extension in Windows XP.

All of the scripts we’ll use in this section will run at the command prompt. However, it’s important to realize that the scripting skills you develop now will also work in other areas of Windows. As long as you have an interpreter that understands your script, it will run in any environment. You’ll find Command Prompt in the StartProgramsAccessories folder. Here are the two command lines you can use to start a WSH script:

CScript <Script Name> [<WSH Command Line Switches>] [<Script Arguments>]
WScript <Script Name> [<WSH Command Line Switches>] [<Script Arguments>]

As you can see, there are actually two different commands you can use to start WSH. CScript is the character mode version of WSH, and WScript provides a dialog interface. Both forms of WSH accomplish the same tasks. The only difference between the two commands is the interface.

CScript and WScript use the same command line. You must provide a script name as the first command line argument. Most scripts have a VBE or a JS file extension, but any extension is acceptable. For example, you can still use VBS files with WSH, but the icon won’t look right and you can’t double-click it to start the execution. Figure 19.1 shows the standard script icon. The icon is yellow for VBE files and blue for JS files. Other languages will potentially use other icons or other colors.

Figure 19.1. The standard script icon is blue for JS files and yellow for VBE files.

WSH provides a wealth of command line switches that you can use to modify its behavior. Table 19.1 shows a list of the command line switches that WSH provides. Notice that all of these command line switches start with two slashes like this: //. The slashes differentiate them from switches you may need for your script. WSH passes script arguments to your script for processing. Script arguments can be anything including command line switches of your own or values needed to calculate a result.

Some of the switches in Table 19.1 may not make a lot of sense right this second, but I’ll explain them as the day progresses. Let’s look at a couple of the switches right away, though, so that you’ll have some idea of how they work.

As shown in Table 19.1, you can work with WSH in either interactive or batch mode. You use batch mode when you need to perform tasks that don’t require user input. For example, you might want to run Scan Disk every evening but use different command line switches for it based on the day. You could use Task Scheduler to accomplish this task, but using it in conjunction with a WSH script will improve the flexibility you gain when running the task.

Another kind of batch processing might be to send log files to your supervisor or perhaps set up a specific set of environment variables for a character-mode application based on the current user. On the other hand, interactive mode requires user interaction. You’d use it for tasks such as creating a form letter script. Such a script could ask the user a set of general questions and then create a form letter based on the user’s input. The form letter would follow company guidelines and save the user time. All the user would need to do is tweak a few of the lines to make the letter complete.

The next set of command line switches that I’d like to talk about are //Logo and //NoLogo. There aren’t any right or wrong times to use these switches, but I usually use the //Logo switch when testing a script and the //NoLogo switch afterward. The reason is simple. During the testing process, I want to know about every potential source of problems in my script environment, including an old script engine that might cause problems. On the other hand, I don’t want to clutter my screen with useless text after I debug the script. Using the //NoLogo switch keeps screen clutter to a minimum.

You don’t have to rely exclusively on command line switches to configure WSH; you can configure two WSH options from the Windows Script Host Settings dialog box. Run WScript by itself, and you’ll see the dialog box shown in Figure 19.2.

Figure 19.2. WSH will allow you to set certain configuration options permanently without the use of command line switches.

The first check box allows you to set WSH to stop executing a script after a certain time interval has elapsed. The edit box below it contains the number of seconds to wait. Setting this option is like adding the //T:nn command line switch to every script that you run.

The second check box determines whether WSH displays WSH logo when running scripts from the DOS prompt. Normally, this option is checked, which is the same as adding the //Logo command line switch to every script that you run. Clearing this option tells WSH that you don’t want to display the logo, which is the same as using the //NoLogo command line switch.

You can get the same dialog as shown in Figure 19.2 for individual scripts. All you need to do is right-click the script file and select Properties from the context menu. Select the Script tab to see the options. Changing the WSH options when looking at a script file Properties dialog changes the options for that script, but the options for WSH in general remain the same.

Use Reset to Defaults to change all of the settings back to their Microsoft defaults. The default settings include no time out period and will always display the WSH logo.

Job files can help you create a modular script environment and yet automate tasks. Modular scripts perform a single task. You can use them alone or with other scripts to produce certain effects. Using a modular approach saves time because you only have to create and debug a script to perform a specific task one time. After that, you just add it to your application. Think of modular scripting as a way of creating applications with script Lego’s.

The script job file is a form of eXtensible Markup Language (XML), which looks similar to the code in HTML pages. The job files have a specific format. The following WSF file executes a single script named TEST1.JS:

<Job ID=MyJob>
    <Script Language="JScript" Src="TEST1.JS" />
</Job>

Every job begins with the <Job> tag. You have to assign an ID to your job to make it easy to identify. Notice that the <Script> tag includes an ending slash (/). XML requires that you include the slash so that all of the entries are symmetrical.

You can use a mix of languages within a job. Every entry identifies the language it uses so that WSH doesn’t have to guess how to run it. If the code is in a file, you add an Src attribute to the <Script> tag.

WSH also provides support for code within a job file. You can mix languages if desired. Anything you can do with a script file, you can also do with a job file. For example, the following job runs a JavaScript script and then executes some internal script (don’t worry too much about understanding the code for now):

<Job ID=MyJob>
    <Script Language="JScript" Src="TEST1.JS" />
    <Script Language="VBScript">
        WScript.Echo("Hello World")
    </Script>
</Job>

In this case, the job file outputs the results of the TEST1.JS file first and then outputs “Hello World.” If the user started the script with WScript, there would be dialog boxes for each output. CScript places all of the output on separate lines of the command window.

Let’s say you wanted to create a single file containing all your jobs. That way, all you really need to know is the name of your file and the name of your job. Everything is located in one place on the hard drive, so there’s nothing to lose. The following example shows how to create a file with multiple jobs:

<Package>
    <Job ID="MyJob1">
        <Script Language="JScript" Src="TEST1.JS" />
    </Job>

    <Job ID="MyJob2">
        <Script Language="JScript" Src="TEST1.JS" />
        <Script Language="VBScript">
            WScript.Echo("Hello World")
        </Script>
    </Job>
</Package>

Notice that we’ve added a <Package> tag to the mix. The <Package> tag serves to bundle all of the jobs together. Each job still requires an ID, but you don’t assign an ID to the package. You’ll use the //Job:<Job Name> switch as shown below to access a specific job in the package:

CSCRIPT MyJob3.WSF //Job:MyJob1

That’s all there is to job files. You’ll use a combination of XML and script to combine script files together. Using this approach enables you to create some interesting scripts for your system.

The WScript object is the main object for WSH. You’ll access every other object through this one. The following list tells you about the properties that the WScript object supports:

Remember that all of these properties tell you about the WScript object. You can also use methods to perform tasks with the WScript object. The following list provides a brief overview of the more important methods you’ll use with the WScript object. Note that most of these methods require that you pass one or more parameters as input.

Now that you have some idea of how Windows XP supports scripting, let’s look at a simple script. I’m presenting these examples in both VBScript and JavaScript so that you can see the differences between the two languages. In addition, some people prefer one scripting language to another, so this is your chance to see both in action. The following code shows a basic example in VBScript:

' Test1.VBS shows how to use functions and subprocedures
' within a WSH script.

WScript.Echo("The value returned was: " + CStr(MyFunction(1)))

function MyFunction(nSomeValue)
    WScript.Echo("Function received value of: " + CStr(nSomeValue))
    Call MySubprocedure(nSomeValue + 1)
    MyFunction = nSomeValue + 1
end function

sub MySubprocedure(nSomeValue)
    WScript.Echo("Subprocedure received value of: " + CStr(nSomeValue))
end sub

As you can see, the sample code uses the WScript object to send some information to the screen. I thought it important to introduce you to the idea of functions and subs, the two building blocks of VBScript. The following code shows a similar example for JavaScript:

// Test1.JS shows how to use functions within a WSH script.
WScript.Echo("The value returned was: " + MyFunction(1));

function MyFunction(nSomeValue)
{
   WScript.Echo("The value received was: " + nSomeValue);
   return nSomeValue + 1;
}

JavaScript only provides functions, so that’s all this example demonstrates. It’s also important to notice that VBScript requires you to convert numeric values to a string, while JavaScript performs the conversion automatically.

At this point, you know a little about scripting and a little about the WScript.Echo() method. Let’s look at some other methods that the WScript object provides. The following JavaScript code retrieves information from the command line. It also retrieves information about the application environment.

// ProgInfo.JS determines the specifics about your program and then
// displays this information on screen.

// Create some constants for display purposes (buttons and icons).
var intOK = 0;
var intOKCancel = 1;
var intAbortRetryIgnore = 2;
var intYesNoCancel = 3;
var intYesNo = 4;
var IntRetryCancel = 5;
var intStop = 16;
var intQuestion = 32;
var intExclamation = 48;
var intInformation = 64;

// Create some popup return values.
var intOK = 1;
var intCancel = 2;
var intAbort = 3;
var intRetry = 4;
var intIgnore = 5;
var intYes = 6;
var intNo = 7;
var intClose = 8;
var intHelp = 9;

// Create a popup display object.
var WshShell = WScript.CreateObject("WScript.Shell");

// Create a variable for holding a popup return value.
var intReturn;

// Get the program information and display it.
WshShell.Popup("Full Name:	" + WScript.Fullname +
        "
Interactive:	" + WScript.Interactive +
        "
Name:		" + WScript.Name +
        "
Path:		" + WScript.Path +
        "
Script Full Name:	" + WScript.ScriptFullName +
        "
Script Name:	" + WScript.ScriptName +
        "
Version:		" + WScript.Version,
        0,
        "Program Information Demonstration",
        intOK + intInformation);

// Ask if the user wants to display the argument list.
intReturn = WshShell.Popup("Do you want to display the argument list?",
            0,
            "Argument List Display",
            intYesNo + intQuestion);

// Determine if the user wants to display the argument list and
// display and appropriate message.
if (intReturn == intYes)

    // See if there are any arguments to display.
    DisplayArguments();
else
    WScript.Echo("Goodbye");

function DisplayArguments()
{
    // Create some variables.
    var strArguments = "Arguments:
	";    // Argument list.
    var intCount = 0;            // Loop counter.

    // See if there are any arguments, if not, display an
    // appropriate message.
    if (WScript.Arguments.Length == 0)
        WshShell.Popup("There are no arguments to display.",
            0,
            "Argument List Display",
            intOK + intInformation);

    // If there are arguments to display, then create a list
    // first and display them all at once.
    else
    {
        for (intCount = 0; intCount < WScript.Arguments.Length; intCount++)
            strArguments =
              strArguments + WScript.Arguments.Item(intCount) + "
	";
        WshShell.Popup(strArguments,
        0,
        "Argument List Display",
        intOK + intInformation);
}

When you run this script, you’ll see a dialog box containing all of the information about the script engine. When you click OK, the program will ask if you want to display the command line arguments. If you say yes, you’ll see anything you typed at the command line. Otherwise, the script displays a Goodbye message.

You should notice a few things about this example. First, I create an object in this code. You need access to the WshShell object for many of the tasks you’ll perform with scripts. The code also shows how to use the Popup() method to obtain information from the user. Finally, the code uses the Arguments object to access the command line information. Notice the object hierarchy used in this example.

The final example shows how to use VBScript to access information in the registry. You don’t want to change information unless you have to, but seeing what’s available in the registry is a good way to build your knowledge of both scripting and the registry. Note that this example uses the command line argument to determine which file extension to look for in the registry.

' RegRead.VBE will display the application extension information
' contained in the registry.

' Create an icon and button variable for Popup().
intOK = 0
intInformation = 64

' Create a popup display object.
set WshShell = WScript.CreateObject("WScript.Shell")

' Create variables to hold the information.
strExtension = ""    ' File extension that we're looking for.
strFileType = ""     ' Holds the main file type.
strFileOpen = ""     ' File open command.
strFilePrint = ""    ' File print command.
strDefaultIcon = ""  ' Default icon for file type.

' See if the user provided a file extension to look for.
' If not, assign strExtension a default file extension.
if (WScript.Arguments.Length > 0) then
    strExtension = WScript.Arguments.Item(0)
else
    strExtension = ".txt"
end if

' Get the file type.
strFileType = WshShell.RegRead("HKEY_CLASSES_ROOT\" +_
                strExtension + "\")

' Use the file type to get the file open and file print
' commands, along with the default icon.
strFileOpen = WshShell.RegRead("HKEY_CLASSES_ROOT\" +_
                strFileType +_
                "\shell\open\command\")
strFilePrint = WshShell.RegRead("HKEY_CLASSES_ROOT\" +_
                strFileType +_
                "\shell\print\command\")
strDefaultIcon = WshShell.RegRead("HKEY_CLASSES_ROOT\" +_
                strFileType +_
                "\DefaultIcon\")

' Display the results.
WshShell.Popup "File Type:" + vbTab + vbTab + vbTab + strFileType +_
        vbCrLf + "File Open Command:" + vbTab + strFileOpen +_
        vbCrLf + "File Print Command:" + vbTab + vbTab + strFilePrint +_
        vbCrLf + "Default Icon:" + vbTab + vbTab + strDefaultIcon,_
        0,_
        "RegRead Results",_
        intOK + intInformation

When you run this script, it reads the command line. If you haven’t supplied a value, the script will assign a default extension of .TXT. The script uses the extension to locate information in the registry such as the file open and print commands. Finally, the script uses the Popup() method to display the output.

You should notice several differences between this example and the JavaScript example we looked at previously. First, the method for creating an object requires the use of a “set”—you can’t simply assign the object to a variable. You’ll also notice that VBScript has access to all of the standard Visual Basic constants, such as vbTab and vbCrLf. Finally, VBScript handles many of the method calls as subs, not as functions. You need to exercise care when working in a mixed environment.

You’ll always transfer files from the old computer first. In many cases, you’ll create what amounts to a backup of your old computer on a floppy or removable media and then transfer it to the new computer. The wizard also provides an option for moving the settings using a serial cable between the old and new machines. The following steps show you how to use the wizard to save the old computer settings:

After you backup the settings from the old computer, you can transfer them to the new computer. The following steps show you how to transfer the old computer settings to the new computer:

The easiest way to learn about Task Scheduler is to start the program found in StartProgramsAccessoriesSystem Tools. You’ll see the Scheduled Tasks entry. Figure 19.4 shows what this program looks like when you first start it. As you can see, the Task Scheduler includes entries for each scheduled task. The entries include the task name, run interval, the next run time, the time the Task Scheduler last ran the task, the last result, and the task creator. Note that the Task Scheduler (using the Scheduled Tasks window) shows all of the scheduled tasks—even those of other users.

Figure 19.4. The Scheduled Tasks window shows a list of tasks for your machine and provides statistics about them.

The Task Scheduler interface is relatively easy to learn. All you need to know is how to work with the tasks and modify the behavior of Task Scheduler. The following sections tell you about both activities. We’ll start with the simple part of the interface, changing the Task Scheduler behavior.

Setting the Task Scheduler Options

Figure 19.4 shows many menu options. However, the only menu you’re interested in for Task Scheduler is the Advanced menu. The following list describes the menu entries:

• Stop Using Task Scheduler. Select this option and Windows XP will stop the Task Scheduler service on your machine. It will also prevent the Task Scheduler service from running automatically. The menu entry will change to Start Using Task Scheduler and you’ll notice that several other options are grayed out. Normally, you’ll use this option only if you decide not to use Task Scheduler at all.

• Pause Task Scheduler. Select this option if you want to temporarily stop the Task Scheduler. Windows XP will simply pause the Task Scheduler service. The menu entry will change to Continue Task Scheduler, and you can continue where you started. All of the other menu options remain enabled and Windows XP will automatically restart Task Scheduler the next time you boot the machine. You can use this feature if Task Scheduler wants to run a task at an inconvenient time. For example, Task Scheduler might decide to perform a disk defragmentation in the middle of a file download.

• Notify Me of Missed Tasks. Use this option if you want Task Scheduler to remind you of missed tasks. The notice you receive lets you run the missed task. Of course, this feature can become a nuisance if you already know that you missed the task and don’t want Task Scheduler to remind you.

• AT Service Account. The AT command line utility can add entries to the Task Scheduler. You’ll find the entries aren’t the same as those created using the GUI. We’ll discuss these differences in the “Using the AT Command Line Utility” section. The account runs separately from the user account, a necessity if you want the AT utility to add tasks to everyone’s account.

• View Log. To use this entry, you have to stop the Task Scheduler service. Otherwise, you’ll receive a message that the file is in use by another application. Use View Log to see the log entries for the Task Scheduler.

As previously mentioned, the AT service account defaults to the system account. If you select the AT Service Account option, you’ll see the AT Service Account Configuration dialog box. The dialog box contains two options: System Account and This Account. If you choose This Account, you’ll also need to enter the name and password of the account you’d like to use. Generally, you’ll never need to use this option unless you want to allow regular users access to the AT command.

The View Log option is a bit of a disappointment. This option actually opens the SCHEDLGU.TXT file found in the WINDOWS folder. The only problem is that Windows associates the TXT extension with Notepad, so you see the messy display shown in Figure 19.5. If you looked at the SCHEDLGU.TXT file with a hex editor, you’d notice that it uses Unicode characters, a format that Notepad can’t handle. While Notepad does a marvelous job with plain text, you won’t want to use it for the Task Scheduler log file.

Figure 19.5. Use the View Log option only if you want to see this messy log display.

The alternative, in this case, is to open the file with WordPad. Of course, you’ll still need to stop the Task Scheduler service before you can read the log entries. Figure 19.6 shows the readable display provided by WordPad. Notice that each task entry contains a TaskId value used to identify the task within the log. Unfortunately, unless you started the task with AT, there isn’t any way to match the TaskId with an entry in the Scheduled Tasks window (at least, not without a lot of research). The best way to use this log is to match the starting times and dates with the entries in the Scheduled Tasks window.

Figure 19.6. Using WordPad to view the SCHEDLGU.TXT file produces a neat display that you can read with ease.

Tip

You can fix the View Log problem with Task Scheduler using a simple registry change. Locate the HKEY_LOCAL_MACHINESOFTWAREMicrosoftSchedulingAgent key. This key contains a LogPath value that you can change to another extension. Instead of using SCHEDLGU.TXT, try using SCHEDLGU.DOC. You’ll find that the View Log option now works as intended. If you have Word installed on your system, you’ll find this fix even negates the need to shut down the service. Word will simply tell you that the file is in use by someone else and will ask if you want to make a copy. Click Yes and you’ll see the existing logon screen. Because you won’t make any changes to the log, this method of access is completely safe and won’t interfere with normal Task Scheduler operation. Note that the key also contains values that enable you to change the default log size, the number of minutes before the Task Scheduler goes into idle mode, and the location of the scheduled tasks folder.

Modifying Tasks

What happens if you change your mind about a scheduled task or want to refine the schedule you create for it? That’s where modifying the task comes into play. Double-click the task, and you’ll see a task properties dialog box.

The General tab of the task properties dialog box contains application specifics. You’ll note that the Scheduled Task Wizard didn’t allow you to add any command line parameters. This is where you add the parameters. Just type them into the Run field along with the application path. This dialog box also contains fields for changing the starting directory, adding some comments, and changing the username and password. Notice the Enabled option at the bottom of the dialog box. Clear this option if you want to disable the task but want to retain it for future use.

The Schedule tab shown in Figure 19.8 determines when the application will run. The figure doesn’t show the default state of the dialog box. Notice the Show Multiple Schedules option at the bottom of the dialog box. Check this option if you want to run the application on more than one scheduled time. For example, you might want to run it once a week and once a month at given times. To add a new scheduled run time, click New. You can remove scheduled run times by selecting the entry and clicking Delete.

Figure 19.8. Task Scheduler offers to run an application on as many schedules as required to meet specific needs.

Figure 19.8 shows the setup for a monthly task. However, you can change the interval using entries in the Schedule Task field. In addition to the normal entries provided by the Scheduled Task Wizard, this list also includes a When Idle option. The When Idle option is a great choice for tasks that you can perform a little at a time when the user isn’t doing anything else with the system. For example, the user might be reading a Web page. You set the time interval that Windows will wait before it begins the tasks. As soon as the user starts a new activity, the task will pause and wait for another idle period.

You’ll find some differences on the Schedule tab when compared to the Scheduled Task Wizard. For example, the Schedule tab hides more items. In Figure 19.8, you’d need to click Select Months to change the month in which the application will run. You’ll also see an Advanced button that displays the Advanced Schedule Options dialog box. Fields in this dialog box select the start date and end date. The Advanced Options dialog box also includes an option to repeat the task over a given interval.

Figure 19.9 shows the Settings tab. The options on this tab control task execution, rather than the application. Notice that you can set the task to delete itself automatically if you haven’t scheduled it to run again. This keeps your Scheduled Tasks window from filling with old information.

Figure 19.9. Use the Settings tab to change the way the task runs.

This tab also contains a idle time setting. However, this time the setting affects the task, not the application. When the application begins running, it will continue to run until it runs out of time or it completes its task. Use this option to ensure that the machine isn’t in a high state of activity when you start the application.

Finally, this tab contains power management options. You’ll use these options with laptop machines. For example, you wouldn’t want to defragment the disk while the laptop is on battery power because excessive disk use drains the battery quickly. Task Scheduler will simply wait until you connect the laptop to AC power to start the task.

As previously mentioned, the AT command line utility uses a character mode interface. You interact with it using the command prompt. The AT command use the following formats:

AT [\Computer] [[<Id>] [/DELETE] | /DELETE [/YES]]
AT [\Computer] <Time> [/INTERACTIVE] [/EVERY:<Dates> | /NEXT:<Dates>] <Command>

As you can see, the first format removes tasks, while the second adds them. Table 19.2 tells you about the switches and parameters the AT command accepts.

Creating a job with AT is relatively easy. Earlier, we used the Scheduled Task Wizard to create a defragmenter job that runs at 6 p.m. every Friday. You can create a similar job using the following command line:

AT 6pm /Every:Friday "E:WINDOWSSYSTEM32DFRG.MSC"

You don’t obtain the same level of configuration features using AT that you would using the GUI method. Many of the special configuration features we discussed in the “Modifying Tasks” section are unavailable. If you modify an AT task using the Scheduled Tasks window, AT won’t track it any longer. The second you apply the changes, AT removes the task from its list.

The Scheduled Tasks window tracks jobs created using both the GUI and the command line method. AT only tracks jobs that it creates. If you type AT at the command prompt and press Enter, all you’ll see are the AT jobs. Figure 19.10 shows a typical example of the same jobs created using the GUI and AT. Notice that the AT job name has “at” and the number of the job.

Figure 19.10. AT jobs appear in the Scheduled Tasks window as “at” jobs.

As you can see, from a Scheduled Tasks window perspective, both jobs are the same. The only two differences are the job name and the creator name. Unless you change the default setting, the system creates all AT jobs. Any job created using the Scheduled Tasks window will appear under the user’s name.

Today you’ve looked at scripting, and you’ve learned about automation. Some people never think to combine the two, but they’re a natural fit. When you create scripts that perform a common task, adding the script to the Task Scheduler is a natural way to save time. Of course, you’ll want to ensure that you debug the script fully. Otherwise, you can’t be sure what the system will end up doing in your absence.

The powerful aspect of scripts and the Task Scheduler for the average user is that you’re the one in control. You create the script and determine when it will run on your system. The combination of scripts and the Task Scheduler frees you from performing some of the mundane tasks you might otherwise perform.

Creating a task to run a script is precisely the same as creating a task for any other application. You have access to most of the settings as normal. For the most part, Task Scheduler looks at your script as an application to run and nothing else. However, Task Scheduler does appear to have a problem working with scripts that require switches or parameters. Sometimes, the job won’t run as anticipated without a lot of fiddling.

It’s also important to avoid user interaction within a script. The task will simply stop at the point of user input and wait for the user to do something. If the user is away from his desk at the time, the task could time out, and Task Scheduler will terminate it. The only thing you’ll know when you look at the script entry is that it failed. This is one of those surprise errors that occur when you mix scripting and automatic execution.