Programming4us
         
 
 
Windows

Scripting Windows 7 with WSH : Scripts and Script Execution

5/1/2011 5:42:43 PM

Understanding Windows Script Host

As you might know, Internet Explorer is really just an empty container application that’s designed to host different data formats, including ActiveX controls, various file formats (such as Microsoft Word documents and Microsoft Excel worksheets), and several ActiveX scripting engines. A scripting engine is a dynamic link library (DLL) that provides programmatic support for a particular scripting language. Internet Explorer supports two such scripting engines: VBScript (VBScript.dll) and JavaScript (JSscript.dll). This enables web programmers to write small programs—scripts—that interact with the user, control the browser, set cookies, open and close windows, and more. Although these scripting engines don’t offer full-blown programmability (you can’t compile scripts, for example), they do offer modern programming structures such as loops, conditionals, variables, objects, and more. In other words, they’re a huge leap beyond what a mere batch file can do.

The Windows Script Host is also a container application, albeit a scaled-down application in that its only purpose in life is to host scripting engines. Right out of the box, the Windows Script Host supports both the VBScript and JavaScript engines. However, Microsoft designed the Windows Script Host to be a universal host that can support any ActiveX-based scripting engine. Therefore, there are also third-party vendors offering scripting engines for languages such as Perl, Tcl, and Rexx.

The key difference between Internet Explorer’s script hosting and the Windows Script Host is the environment in which the scripts run. Internet Explorer scripts are web page based, so they control and interact with either the web page or the web browser. The Windows Script Host runs scripts within the Windows 7 shell or from the Command Prompt, so you use these scripts to control various aspects of Windows. Here’s a sampling of the things you can do:

  • Execute Windows programs

  • Create and modify shortcuts

  • Use automation to connect and interact with automation-enabled applications, such as Microsoft Word, Outlook, and Internet Explorer

  • Read, add, and delete Registry keys and items

  • Access the VBScript and JavaScript object models, which give access to the file system, runtime error messages, and more

  • Use pop-up dialog boxes to display information to the user, and determine which button the user clicked to dismiss the dialog box

  • Read environment variables, which are system values that Windows 7 keeps in memory, such as the folder into which Windows 7 is installed—the %SystemRoot% environment variable—and the name of the computer—the %ComputerName% environment variable

  • Deal with network resources, including mapping and unmapping network drives, accessing user data (such as the username and user domain), and connecting and disconnecting network printers

  • Use the Windows Management Instrumentation service to manage applications, systems, devices, networks, and more, either locally or remotely

Clearly, we’ve gone way beyond batch files!

What about speed? After all, you wouldn’t want to load something that’s the size of Internet Explorer each time you need to run a simple script. That’s not a problem because, as I’ve said, the Windows Script Host does nothing but host scripting engines, so it has much less memory overhead than Internet Explorer. That means that your scripts run quickly. For power users looking for a Windows-based batch language, the Windows Script Host is a welcome tool.


Scripts and Script Execution

Scripts are simple text files that you create using Notepad or some other text editor. You can use a word processor such as WordPad to create scripts, but you must make sure that you save these files using the program’s Text Only document type. For VBScript, a good alternative to Notepad is the editor that comes with either Visual Basic or any program that supports VBA (such as the Office suite). Just remember that VBScript is a subset of VBA (which is, in turn, a subset of Visual Basic), so it does not support all objects and features.

In a web page, you use the <script> tag to specify the scripting language you’re using, as in this example:

<SCRIPT LANGUAGE="VBScript">

With the Windows Script Host, the script file’s extension specifies the scripting language:

  • For VBScript, save your text files using the .vbs extension (which is registered as the following file type: VBScript Script File).

  • For JavaScript, use the .js extension (which is registered as the following file type: JScript Script File).

As described in the next three sections, you have three ways to run your scripts: by launching the script files directly, by using WSscript.exe, or by using CScript.exe.

Running Script Files Directly

The easiest way to run a script from within Windows is to launch the .vbs or .js file directly. That is, you either double-click the file in Windows Explorer or type the file’s path and name in the Run dialog box. Note, however, that this technique does not work at the Command Prompt. For that, you need to use the CScript program described a bit later.

Using WScript for Windows-Based Scripts

The .vbs and .js file types have an open method that’s associated with WScript (WScript.exe), which is the Windows-based front end for the Windows Script Host. In other words, launching a script file named MyScript.vbs is equivalent to entering the following command in the Run dialog box:

wscript myscript.vbs

The WScript host also defines several parameters that you can use to control how the script executes. Here’s the full syntax:

WSCRIPT filename arguments //B //D //E:engine //H:host //I //Job:xxxx //S //T:ss //X


filenameSpecifies the filename, including the path of the script file, if necessary.
argumentsSpecifies optional arguments required by the script. An argument is a data value that the script uses as part of its procedures or calculations.
//BRuns the script in batch mode, which means script errors and Echo method output lines are suppressed. 
//DEnables Active Debugging. If an error occurs, the script is loaded into the Microsoft Script Debugger (if it’s installed) and the offending statement is highlighted.
//E:engineExecutes the script using the specified scripting engine, which is the scripting language to use when running the script.
//H:hostSpecifies the default scripting host. For host, use either CScript or WScript.
//IRuns the script in interactive mode, which displays script errors and Echo method output lines.
//Job:xxxxIn a script file that contains multiple jobs, executes only the job with idxxxx. attribute equal to
//SSaves the specified WScript arguments as the default for the current user; uses the following Registry key to save the settings:
HKCU\Software\Microsoft\Windows Script Host\Settings

//TT:ssSpecifies the maximum time in seconds (ss) that the script can run before it shuts down automatically.
//XExecutes the entire script in the Microsoft Script Debugger (if it’s installed).

For example, the following command runs MyScript.vbs in batch mode with a 60-second maximum execution time:

wscript myscript.vbs //B //TT:60

Creating Script Jobs

A script job is a section of code that performs a specific task or set of tasks. Most script files contain a single job. However, it’s possible to create a script file with multiple jobs. To do this, first surround the code for each job with the <script> and </script> tags, and then surround those with the <job> and </job> tags. In the <job> tag, include the id attribute and set it to a unique value that identifies the job. Finally, surround all the jobs with the <package> and </package> tags. Here’s an example:

<package>
<job id="A">
<script language="VBScript">
WScript.Echo "This is Job A."
</script>
</job>


<job id="B">
<script language="VBScript">
WScript.Echo "This is Job B."
</script>
</job>
</package>

Save the file using the .wsf (Windows Script File) extension.


Note

If you write a lot of scripts, the Microsoft Script Debugger is an excellent programming tool. If there’s a problem with a script, the debugger can help you pinpoint its location. For example, the debugger enables you to step through the script’s execution one statement at a time. If you don’t have the Microsoft Script Debugger, you can download a copy from http://msdn.microsoft.com/en-us/library/ms950396.aspx.


Using CScript for Command-Line Scripts

The Windows Script Host has a second host front-end application called CScript (CScript.exe), which enables you to run scripts from the command line. In its simplest form, you launch CScript and use the name of the script file (and its path, if required) as a parameter, as in this example:

cscript myscript.vbs

The Windows Script Host displays the following banner and then executes the script:

Microsoft (R) Windows Script Host Version 5.8 for Windows
Copyright (C) Microsoft Corporation. All rights reserved.

As with WScript, the CScript host has an extensive set of parameters you can specify:

CSCRIPT filename arguments //B //D //E:engine //H:host //I //Job:xxxx //S //T:ss //X //U //LOGO //NOLOGO


This syntax is almost identical to that of WScript, but adds the following three parameters:

//LOGODisplays the Windows Script Host banner at startup
//NOLOGOHides the Windows Script Host banner at startup
//UUses Unicode for redirected input/output from the console

Script Properties and .wsh Files

In the preceding two sections, you saw that the WScript and CScript hosts have a number of parameters you can specify when you execute a script. It’s also possible to set some of these options by using the properties associated with each script file. To see these properties, right-click a script file and then click Properties. In the properties sheet that appears, display the Script tab, shown in Figure 1. You have two options:

  • Stop Script After Specified Number of Seconds— If you activate this check box, Windows shuts down the script after it has run for the number of seconds specified in the associated spin box. This is useful for scripts that might hang during execution. For example, a script that attempts to enumerate all the mapped network drives at startup might hang if the network is unavailable.

  • Display Logo When Script Executed in Command Console— As you saw in the previous section, the CScript host displays some banner text when you run a script at the Command Prompt. If you deactivate this check box, the Windows Script Host suppresses this banner (unless you use the //LOGO parameter).

Figure 1. In a script file’s properties sheet, use the Script tab to set some default options for the script.


When you make changes to these properties, the Windows Script Host saves your settings in a new file that has the same name as the script file, except with the .wsh (Windows Script Host Settings) extension. For example, if the script file is MyScript.vbs, the settings are stored in MyScript.wsh. These .wsh files are text files organized into sections, much like .ini files. Here’s an example:

[ScriptFile]
Path=C:\Users\Paul\Documents\Scripts\Popup1.vbs
[Options]
Timeout=0
DisplayLogo=1

To use these settings when running the script, use either WScript or CScript and specify the name of the .wsh file:

wscript myscript.wsh

Note

Rather than setting properties for individual scripts, you might prefer to set global properties that apply to the WScript host itself. Those global settings then apply to every script that runs using the WScript host. To do this, run WScript.exe without any parameters. This displays the properties sheet for WScript, which contains only the Script tab shown in Figure 30.1. The settings you choose in the properties sheet are stored in the following Registry key:

HKLM\Software\Microsoft\Windows Script Host\Settings


Running a Script as the Administrator

When you run scripts in Windows 7, you may on occasion need to run those scripts under the auspices of the Administrator account.

When you need to run a script under the Administrator account, one solution is to first launch an elevated Command Prompt session. From the elevated command line, you could then use CScript to launch the script, as described earlier. That would work, but it’s a bit of a hassle. If you run a lot of administrator scripts, you’d probably prefer something a lot more direct.

I’m happy to report that a much more direct method is available. You can tweak the Windows 7 file system to display a Run as Administrator command when you right-click a VBScript file. Click that command, enter your UAC credentials, and your script runs with administrator privileges.

Here’s what you do:

Note

If you don’t feel like modifying the Registry by hand, there’s a file containing the necessary changes—VBSFile_RunAsAdminisrator.reg—on my website at http://mcfedries.com/Windows7Unleashed/.


1.
Select Start, type regedit, and press Enter. The User Account Control dialog box appears.

2.
Enter your UAC credentials to open the Registry Editor.

3.
Navigate to the following key:

HKEY_CLASSES_ROOT\VBSFile\Shell

4.
Select Edit, New, Key, type RunAs, and press Enter.

5.
With the new runas key selected, select Edit, New, Key, type Command, and press Enter.

6.
In the Command key, double-click the (Default) to open the Edit String dialog box.

7.
Type the following value and click OK (modify the Windows location if yours is installed somewhere other than C:\Windows):

"C:\Windows\System32\WScript.exe" "%1" %*

8.
Select Edit, New, String Value. The Registry Editor creates a new value in the Layers key.

9.
Type IsolatedCommand and press Enter.

10.
Double-click the entry you just created. The Edit String dialog box appears.

11.
Type the following value and click OK (again, modify the Windows location if yours is installed somewhere other than C:\Windows):

"C:\Windows\System32\WScript.exe" "%1" %*

Figure 2 shows the modified Registry. With these tweaks in place, right-click a VBScript file and you see the Run as Administrator command, as shown in Figure 3.

Figure 2. The dialog box that’s displayed when you run the script.

Figure 3. Tweaking the Windows 7 Registry to add the Run as Administrator command to the shortcut menu of any VBScript file.
Other -----------------
- Adding Macs to Your Windows 7 Network : Letting Windows Computers See Your Mac Shares
- Adding Macs to Your Windows 7 Network : Using a Mac to Make a Remote Desktop Connection to Windows 7
- Adding Macs to Your Windows 7 Network : Connecting to a Windows Shared Folder
- Adding Macs to Your Windows 7 Network : Connecting to the Windows Network
- Windows 7 : Controlling and Customizing Your Website (part 5) - Viewing the Server Logs
- Windows 7 : Controlling and Customizing Your Website (part 4) - Disabling Anonymous Access
- Windows 7 : Controlling and Customizing Your Website (part 3) - Working Without a Default Document
- Windows 7 : Controlling and Customizing Your Website (part 2) - Setting the Website’s Default Document
- Windows 7 : Controlling and Customizing Your Website (part 1)
- Windows 7 : Adding Folders and Files to the Default Website (part 3) - Adding a Folder to the Default Website
- Windows 7 : Adding Folders and Files to the Default Website (part 2) - Changing the Default Website Home Page
- Windows 7 : Adding Folders and Files to the Default Website (part 1) - Setting Permissions on the Default Website Folder
- Turning Windows 7 into a Web Server : Understanding the Default Website
- Turning Windows 7 into a Web Server : Accessing Your Website
- Windows 7 : Installing Internet Information Services
- Windows 7 : Using Virtual Private Network Connections
- Windows 7 : Using Dynamic DNS to Access Your Network & Configuring a Network Computer for Remote Administration
- Windows 7 : Connecting to a Remote Desktop via the Internet
- Windows 7 : Connecting to the Remote Desktop (part 2) - Making an Advanced Connection
- Windows 7 : Connecting to the Remote Desktop (part 1) - Making a Basic Connection
 
 
Most View
- Working with Search Page Layouts : Applying a Branded Master Page to a Search Center
- Windows Home Server 2011 : Understanding Security Groups & Adding a New User
- Programming with SQL Azure : Application Deployment Factors
- Exchange Server 2010 : Designing and Implementing Personal Archives
- Windows 7 : Specifying a New Administrative Password
- iPad SDK : New Graphics Functionality - We Are All Tool Users (part 5) - The Freehand Tool
- Developing Applications for Windows Phone 7 : Designing with Blend
- Exchange Server 2010 : Managing Address Lists
- SharePoint 2010 : Get to a Site’s Permission Management Page
- Implementing Edge Services for an Exchange Server 2007 Environment : Utilizing the Basic Sender and Recipient Connection Filters (part 2)
Top 10
- Implementing Edge Services for an Exchange Server 2007 Environment : Utilizing the Basic Sender and Recipient Connection Filters (part 3) - Configuring Recipient Filtering
- Implementing Edge Services for an Exchange Server 2007 Environment : Utilizing the Basic Sender and Recipient Connection Filters (part 2)
- Implementing Edge Services for an Exchange Server 2007 Environment : Utilizing the Basic Sender and Recipient Connection Filters (part 1)
- Implementing Edge Services for an Exchange Server 2007 Environment : Installing and Configuring the Edge Transport Server Components
- What's New in SharePoint 2013 (part 7) - BCS
- What's New in SharePoint 2013 (part 6) - SEARCH
- What's New in SharePoint 2013 (part 6) - WEB CONTENT MANAGEMENT
- What's New in SharePoint 2013 (part 5) - ENTERPRISE CONTENT MANAGEMENT
- What's New in SharePoint 2013 (part 4) - WORKFLOWS
- What's New in SharePoint 2013 (part 3) - REMOTE EVENTS