Tuesday, December 30, 2008

Script Code: Comparing Kix and VBScript (part 1)

Scripting languages are like tools in a toolbox.  Each has its advantages compared to others, mainly because they were conceived to accomplish a particular set of tasks or goals.  To illustrate some minor but important differences, I'm going to show how to access some very common pieces of information using KixTart and VBScript.  This is not intended to say one is superior to the other, indeed, they are each very capable tools in their own rite.

A key benefit of KixTart is that it encapsulates some useful object properties as "macro" variables which are easily accessed.  This saves you from additional lines of code in other languages.  You could do the same with PowerShell using cmdlet features, for example.

Let's look at how you can access the current username and computer name for a given login session on Windows.  In the first example, you can see one way to obtain this information using VBScript and the WshNetwork object within WSH.  This object exposes three key properties: ComputerName, DomainName and UserName.

    Set wshNetwork = WScript.CreateObject("WScript.Network")
    Wscript.Echo wshNetwork.UserName
    Wscript.Echo wshNetwork.ComputerName
    Wscript.Echo wshNetwork.DomainName

KixTart on the otherhand, provides some built-in macro variables to access these three properties with much less code.  They are, respectively: @userid, @wksta, and @domain.

    ? @userid
    ? @wksta
    ? @domain

You could also obtain these items from the WMI repository, with either language.  So to illustrate getting the domain name from WMI with VBScript:

    strComputer = "." 
    Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\CIMV2"
    Set colItems = objWMIService.ExecQuery("SELECT * FROM Win32_ComputerSystem",,48) 
    For Each objItem in colItems
        Wscript.Echo "Domain: " & objItem.Domain
    Next

The code above will return the fully-qualified domain name, or FQDN, such as "contoso.msft".

This is true for accessing WMI from KixTart as well, since it is WMI that is returning the data result.  The script language is simply the conduit for requesting and using it.

    $objWMI = "winmgmts:{impersonationlevel=impersonate}!//@WKSTA"
    $objCS = GetObject($objWMI).ExecQuery("SELECT * FROM Win32_ComputerSystem")
    For each $objItem in $objCS
        ? "Domain: "+$objItem.Domain
    Next

On first glance, they look pretty similar.  You might notice a slight difference in how the CIM repository is accessed in each example.  In the VBScript example, I first get the root\CIMV2 object, and then use the ExecQuery method to execute a WBEM query against the Win32_ComputerSystem collection.

In the KixTart example uses an inline expansion of both the CIM repository and the results of the ExecQuery return dataset (an array) from the Win32_ComputerSystem collection.

The results are the same because WMI is what is being queried, rather than fetching from an API feature in the script language of choice.

Another interesting difference is in how KixTart supports string expansion and evaluation.  If you look at the following line, you will see a KixTart macro variable used at the tail end, but within the enclosed quotes:

    $objWMI = "winmgmts:{impersonationlevel=impersonate}!//@WKSTA"

If the computer name is "sputnik", the value of $objWMI will be:

    "winmgmts:{impersonationlevel=impersonate}!//sputnik"

Very handy indeed.

There is MUCH more to KixTart than this.  Much more.  I am only picking out a very small example to make it easier to see some key features of each script language.  I do like KixTart very much, but I also use VBScript as much or oftentimes more.  It depends on the task at hand.  In many cases, a solid BAT file will do exactly what you need also.  Remember: Scripting is a toolbox.  You should learn to use each tool to experience what each is ideally suited for.  Just as you wouldn't try to do an entire project with a screwdriver, you should pick out a particular script and rebuild it in another language to see how it works.  You may find it works better, or maybe not.

No comments: