RegistryBooster 2010 - You no longer need to guess! This free stability scan will help you clean, repair and optimize your system in an easy way.

Using Windows Scripting Host to Modify the Registry

First introduced as an add-on in NT 4.0, WSH is now an integral part of Win2K. The idea was to take the scripting container available in Internet Explorer and make it available outside of the Web context, as a standalone, command-line or GUI-based scripting host. WSH is language-independent. That is, you can use practically any scripting engine to write WSH scripts.

WSH provides a set of COM objects that you can manipulate to perform some basic Explorer Shell and Windows API functions. In addition, it also supports other objects and methods provided by ActiveX controls that have been installed on your system (See: How to fix Active error). In Win2K, WSH comes with support for VBScript and JScript engines. Third-party vendors provide support for other engines, such as Perl and REXX. For the purposes of our discussion, I give examples only in VBScript. However, anything I show here could be done in the scripting language of your choice.



The material presented assumes that you have some knowledge of Visual Basic (VB) or VBScript (VBScript is a subset of the functionality found in the full VB language set). I don't tell you how to write VBScript, but rather explain and illustrate some of the Registry-related methods available through the WSH.

When it comes to using the WSH for Registry changes, the amount of information you need to know is pretty small. By default, the WSH offers you exactly three methods for manipulating the Registry. They are

• RegDelete
• RegRead
• RegWrite

The WSHShell object provides these three methods. Although they may not seem that significant, remember that the ability to use a scripting engine like VBScript or JScript to process your Registry changes means that you also get all of the capabilities each of these languages provides - such as conditional statements, looping, subroutines, and error handling.

WSH script files take the extension of the language they are written in and associated with. For example, VBScript files should have a .vbs extension and JScript files should have .js extension. When a WSH file has one of these extensions, you can launch it simply by double-clicking on it within the file Explorer. A third file type - .wsf or Windows Script Files - use an XML-based format and can contain either JScript or VBScript code.




The WSH provides two different interpreters from which to launch script files - wscript.exe and cscript.exe. The functional differences between the two are few. Cscript is called from a command shell, whereas wscript is usually called by file association. One significant difference is the way each presents output. If I use the Echo method in my script to echo a message to the user and I invoke the script using wscript.exe, the message is displayed in a dialog box. However, if I invoke the script using cscript from a command shell, the message is displayed to the command shell as text without any popup dialogs. Otherwise, scripts generally execute the same way using either version. In the simplest example, to launch a WSH script from the command-line, type Cscript myscript.vbs.

In a default Win2K configuration, wscript.exe is associated with .vbs, .wsf, and .js files. However, both support the same options at runtime. For example, both can take a number of command-line parameters to modify the behavior of the script. One option I find extremely useful is the //t:## option, which lets you specify the maximum time in seconds that a WSH script can run. This prevents runaway scripts from consuming all available system resources if there are bugs in the code. To use this option, you would type Cscript (or wscript) //t:10 myscript.vbs.

In this example, the WSH script called myscript.vbs would run for 10 seconds (Note that command-line options are delineated with a double slash rather than a single one). After 10 seconds, the script would terminate, regardless of whether it completed. If you type cscript (or wscript) /?, you can get a list of all of the available command-line options.

To illustrate how you can use VBScript and the WSH to manipulate the Registry, Figure 3 exercises each of the above three methods to perform Registry operations - in this case, disabling the Auto Admin Logon feature if it is enabled.

Let's examine this script. The first major thing it does, in Line 7, is instantiate the WSHShell object. This step is required in WSH scripts that intend to use the Wscript.Shell methods, such as the Registry set of methods. Line 9 uses the RegRead method to get the data contained in the AutoAdminLogon value within HKLM. Line 11 does the same thing to obtain the DefaultPassword value. Line 14 tests to see whether the variable strAutoLogon is set to 1 (meaning AutoAdminLogon is enabled). If so, the script pops up a message box indicating that it is preparing to disable this feature. Line 16 uses the RegWrite method to change the value from 1 to 0.

Line 18 checks to see whether the DefaultPassword value is nonblank. If so, Line 19 warns that the Default Password is about to be removed, then Line 20 uses the RegDelete method to remove the value from the Registry. Finally, Line 23 exits the script and returns an errorlevel of 0 to indicate that it completed successfully.

This simple example shows how you can use the WSH to script Registry changes that take advantage of the best features of your favorite scripting language. A couple things to note about the three Registry methods in WSH. First, supported Registry path abbreviations include HKLM, HKCU and HKCR. You can get to HKEY_USERS and HKEY_CURRENT_CONFIG by spelling out their names directly (e.g., RegRead("HKEY_USERS\.Default). If you enter a Registry path that does not exist, or can't be found, the WSH returns a rather confusing error namely that the "system cannot find the file specified." This simply means that the Registry key or value doesn't exist or that you entered the path incorrectly. Also, the Registry methods don't support reading a remote machine's Registry. This limitation, unfortunately, makes WSH less useful as a Registry tool.