Registry Extension

So far, all three scripting languages have proven their general suitability in the area of infrastructure. Now I want to create a key in the registry for the local system and equip it with a pair of values. I will be creating the DATA key under HKEY_LOCAL_MACHINE\SOFTWARE and defining the Remote with a value of 1. The second task for the three scripting methods is to start the C:\tools\clean.exe file. If an error occurs, I want to inform the user that the application could not be launched.

Batch: The batch file starts with

Reg ADD HKLM\Software\Data
The third executable file requires space:
Reg ADD HKLM\Software\Data /v Remote /t REG_SZ /d 1

As simple as the statement is, the fact that a general statement cannot be made on the binary's availability in various operating systems makes the use of many binaries problematic.

VBScript: In comparison, the VBScript approach to extending the registry is as follows:

Set ObjShell = Wscript.CreateObject("Wscript.Shell")
$NewKey = ObjShell.RegWrite\
("HKLM\Software\DATA","remote","1","Reg_SZ")

For this purpose, I make use of the other large object in the Wscript run time: the Wscript.Shell object. Using the RegWrite method, the key and value are stored using just one statement.

PowerShell: How does PowerShell set the default? In principle, PowerShell uses the same commands for editing the registry as for the filesystem:

New-Item -path HKLM:\Software\DATA -itemType Directory

PowerShell considers all containers to be drives, whether it is an SQL database server, an Active Directory, a registry, or a filesystem.

New-ItemProperty -Path HKLM:\Software\DATA \
                   -Name remote -value 1 -type string

Again, the New action is linked to an element. The corresponding noun here is ItemProperty, because the value pair is a property.

Starting a Program with Feedback

The final test comparing the three candidates involves launching an application with error handling.

Batch: The veteran approaches this problem as follows:

C:\tools\clean.exe
If errorlevel 1 goto error
:error
Clean.exe could not be started

The expression errorlevel 1 checks to see whether the return value for the previous statement is equal to or greater than 1. A query if errorlevel 0 goto success would fail because the error code 1 would be included. The type of error (e.g., missing permissions or non-existent file) is not specified.

VBScript: VBScript, however, uses:

On Error Resume Next
Set ObjShell = Wscript.CreateObject("Wscript.Shell")
ObjShell.Run "C:\tools\clean.exe"
If Err.Number <> 0 THEN
Wscript.Echo "An error occurred!"
On Error Goto 0

The line On Error Resume Next hands over error handling to the script. If a statement triggers an exception, it generates an error code, which can be negative; therefore the test is "not equal to zero."

PowerShell: Finally, the Windows PowerShell command is:

$ErrorActionPreference = "stop"
Try {Invoke-item "C:\tools\clean.exe"}
Catch [System.IO.IOException]{"Error in processing, is file present?"}
Catch {"Error running clean.exe"}

PowerShell is in a different league from batch or VBScript with regard to error handling.

The construct Try … Catch allows exceptions to be caught and handled at the statement level, and you even have the possibility of responding to specific errors, such as missing permissions and the like.

Conclusions

The applications used by batch files, such as net.exe, for example, were essentially developed for Windows NT. One of the problems is its inability to adapt to the scripting needs that have arisen since it was created. Ultimately, when using batch files, you need to predict support in the future for each component, and sometimes even for current operating systems.

A consistent syntax model is not possible because of this fragmentation. Each command implements the way it transfers parameters differently. The documentation also suffers from this heterogeneous structure, with no uniform help system.

The batch file is restricted to text as a format for input/output. Native support for XML, CSV, and HTML is not known for this technology. Objects are not implemented, either. However, processing speed is a positive.

VBScript can boast the support of object models COM and WMI. As a result, the development of logon scripts is much more stringent.

You can also address installed applications such as Office via this interface, which provides flexibility in I/O routines, such as redirecting output to an Excel file. Unfortunately, the COM object model is one of the slowest in the universe. Complex tasks can thus try your patience. VBScript additionally cannot beat batch in terms of error handling. However, the documentation of the core components is well done.

The current flagship among administrative tools overcomes all the previously described shortcomings of the veterans batch and VBScript (see the "Advantages of PowerShell" box). Windows PowerShell supports all object models, its scripts have a tremendous range of functions and are assured of a good future, and the internal help is perfectly integrated (Table 1). Syntax, parameters, and examples can be accessed for each command using get-help, and a very good editor with debugging facilities, the Integrated Scripting Environment (ISE), is also available.

Error handling with the support of error types for standard language is state of the art. XML, CSV, HTML, JSON, and text are available as output and input formats. Even sending email is not problematic.