VBScript | Automation Dojos

How To Auto-launch VBscript with Elevated Privileges

Tushar Sharma — Thu, 15 Dec 2016 11:55:09 +0000

How To Auto-launch VBscript with Elevated Privileges | As Published On Automation Dojos

For cases when you need to execute a VBS script (*.vbs file) as admin with elevated privileges you can try the following snippet. This can be done by running ShellExecute and setting the runas flag to run an executable or to run an entire script (batch file or VBScript) with elevated permissions. You can copy/embed the following snippet into your vbscript file or batch file. This should result in executing your script as admin just by double-clicking it.

Caution: Please use this carefully. Make sure your VBScript or batch file is correct and serves the intended purpose only because whatever your script contains will be executed as ‘Admin’

The post How To Auto-launch VBscript with Elevated Privileges appeared first on Automation Dojos.

How To Write Windows Environment Variables With VBScript

Tushar Sharma — Mon, 05 Dec 2016 11:19:00 +0000

How To Write Windows Environment Variables With VBScript | As Published On Automation Dojos

This is in continuation to the last post where we saw how to read windows environment variables using VBScript. As mentioned in the last post, we can use the following preferred methods to achieve this :

Using the WSH Shell object
Using WMI’s Win32_Environment class

In the below example we would be using the WSH Shell’s Environment method.

For ‘strEnvVarType’, the valid parameters for Environment are PROCESS, SYSTEM, USER and VOLATILE.

You can additionally specify the name of a specific environment variable using ‘strEnvVarName’ for example TEMP, PATH, PATHEXT, etc.

The post How To Write Windows Environment Variables With VBScript appeared first on Automation Dojos.

How To Read Windows Environment Variables With VBScript

Tushar Sharma — Sun, 20 Nov 2016 02:09:00 +0000

How To Read Windows Environment Variables With VBScript | As Published On Automation Dojos

Reading an environment variable is simple. There are a couple of methods available to do this but the main preferred ones are the below two :

Using the WSH Shell object
Using WMI’s Win32_Environment class

In the below example we would be using the WSH Shell’s Environment method.

For ‘envVarType’, the valid parameters for Environment are PROCESS, SYSTEM, USER and VOLATILE.

You can additionally specify the name of a specific environment variable using ‘envVarName’ for example TEMP, PATH, PATHEXT, etc.

The post How To Read Windows Environment Variables With VBScript appeared first on Automation Dojos.

How To Load XML File into DOM Using MSXML

Tushar Sharma — Tue, 01 Nov 2016 13:29:00 +0000

How To Load XML File into DOM Using MSXML | As Published On Automation Dojos

Microsoft XML Core Services (MSXML) provides two methods for loading XML documents into the Document Object Model (DOM) and one method and one property for serializing that object model back into an XML stream. The load and loadXML methods parse documents into a DOM.

You can use the load method to load an XML file by pathname, URL

The post How To Load XML File into DOM Using MSXML appeared first on Automation Dojos.

Early Bound Vs Late Bound (Binding)

Tushar Sharma — Sun, 21 Apr 2013 12:14:18 +0000

Early Bound Vs Late Bound (Binding) | As Published On Automation Dojos

What is Binding

Before we dive into ‘Early’ and ‘Late’ stuff, let us discover, what the ‘Binding’ itself means?
In simple terms, the ‘Binding’ refers to the way a script or an application accesses a COM Automation object. This is manifested as the association of entities such as data, program, procedures etc. with identifiers.

It is done when the application is compiled and all functions called in code must be bound before the code can be executed. In the premise of VBScripting, when a script or application attempts to create an instance of a COM object, it inherently verifies the existence of the object in the relevant or specified namespace besides this the object’s methods and properties (called in the script) are also verified. This entire process of locating and verification while creating an instance of COM Object is called ‘Binding’.

Binding with VBScript

Here are some typical examples of binding –

Set MyObject = CreateObject ("Word.Application") 
Set MyObject = GetObject ("winmgmts:") 
Set MyObject = WScript.CreateObject ("Scripting.FileSystemObject")

In general, there are two methods to bind to a COM object using VBScript syntax as specified below (other variations exist as well depending upon the specific needs or style) –

CreateObject (“[Component or Server or Moniker][.][Object or typename]”)
GetObject (“[Component or Server or Moniker][.][Object or typename]”)

However, if you wish to use purely WSH scripts, then the syntax would slightly change to accommodate the prefix – ‘WScript’ and as in ‘WScript.CreateObject’ and ‘WScript.GetObject’.

What is the difference between the above two methods, i.e. CreateObject and GetObject again requires a good explanation which may be out of scope of this post. But in short – ‘You should use GetObject while using monikers and if the object to which you are binding exists outside the ‘File System’ namespace examples would be WMI and ADSI. For all other purposes CreateObject should do fine

Coming back to Early and Late terms, the ‘COM’ support two types of binding –

COM Binding Types Explained

1Early Binding :With this type of binding the ‘COM Object’, its methods and properties are all checked when the script or program is compiled. This has some obvious advantages. Firstly any problems with ‘COM Object’ binding if exist makes the compilation to fail and hence results in the early discovery of related issues. Secondly, this provides the advantage of early access to object model and library (COM) and hence the related information is loaded itself into the compilation or the program. Lastly, as obvious scripts or programs supporting ‘Early Bindinding’ are relatively faster.

2Late Binding : Since VBScript is a not a compiled language, natively it supports only ‘Late Binding’. Hence unlike the ‘Early Binding’, in case of VBScript the binding does not occur until the program is actually executed. In this scenario the program usually performs frequent registry or namespace lookups upon execution to access the information about the ‘COM Objects’, consequently any issues with the COM information are not discovered until the actual execution of the script/program.

The post Early Bound Vs Late Bound (Binding) appeared first on Automation Dojos.

Does VBScript Supports all COM Objects ?

Tushar Sharma — Thu, 14 Feb 2013 12:07:15 +0000

Does VBScript Supports all COM Objects ? | As Published On Automation Dojos

Well the answer in one line is – No VBScript does not supports all COM Objects or Servers!

VBScript works with only a subset of ‘Objects’ knows as ‘Automation Objects‘. As per the official literature, ‘All COM objects must support one or more interfaces, which are simply the avenues by which a COM client can access a COM server. Any object which supports IDispatch interface is known as the Automation Object. Since not all COM objects support this interface hence VBScript does not directly work with all COM objects’

For more information on COM and Automation Objects refer to earlier post on ‘In-Proc and Out-Proc‘ servers here.

The post Does VBScript Supports all COM Objects ? appeared first on Automation Dojos.

COM Components and Scripting Process

Tushar Sharma — Mon, 14 Jan 2013 12:03:25 +0000

COM Components and Scripting Process | As Published On Automation Dojos

Although this article should not concern you at all as a ‘script developer’ as long as you are aware of creating a reference to ‘Automation Objects’ but for people with an appetite to look behind the scenes, it is quite recommended! Moreover it is always useful to know what, indeed happens when you are creating an instance of any COM object in your script.

In this article, we discuss the ‘COM Object instantiation’ and ‘Binding’ process. But before we go through this article it would be a good idea to have a look at COM and Scripting Fundamentals posted earlier in this article ‘In-Proc and Out-Proc‘ or refer to ‘Glossary’ page for a quick brush-up of related terms.

The COM Registration Process

This story starts when an application or library is installed on the operating system. During the installation, this library or application ‘registers‘ itself with the operating system just like ‘regsvr32‘ command if you are aware of it. The idea behind this registration is for the system to know that

A new ‘COM Server‘ is available for use and
What ‘COM Classes’ this COM Server has to offer.

There are some keys which get added at the location – ‘HKEY_CLASSES_ROOT‘ in the registry for each new ‘Object Class’. Among these keys is present one significant key called the ‘Programmatic Identifier‘ (ProgID). This ‘ProgID‘ is the short text which identifies the name given to the respective object class and hence this is the text we use in the command (CreateObject or GetObject) for creating the instance of the COM Object. For example; for creating an instance of ‘Scripting Runtime Library‘ you may use the ‘ProgID’ syntax as –

Set MyObject = CreateObject("Scripting.FileSystemObject")

Developed for Automation Dojos Website

This ‘ProgID‘ is all the information which the system needs to locate and instantiate the COM object. The section below describes the process of locating and instantiation of COM Object.

COM Instantiation Process

Upon the execution of ‘CreateObject’ command as in above example, the ‘Script Engine’ parses the ‘ProgID’ and passes it to a ‘COM API’ which in turn is responsible for creating the object reference. The steps below explain the remaining process –

The ‘COM API‘ searches the ‘HKEY_CLASSES_ROOT‘ section of the registry for the subkey with the same name as the ProgID.
If the above subkey is located then the COM API searches for another subkey called the class ID (CLSID) in the ‘HKEY_CLASSES_ROOT’ section. This ‘CLSID‘ is a globally unique identifier (GUID) of the Automation Object.
Once the system locates the ‘GUID‘, it makes a note of it since this GUID is what the system uses in future to track and use the object.
With this GUID the system searches the following registry location – ‘HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID‘ to retrieve the necessary information like the location of the executable or library file name.
Finally, the ‘COM API’ loads the relevant application or library file name as deduced above, creates the object and returns the reference to the calling script.

Developed for Automation Dojos Website

On the last note – If you are wondering what’s the difference between ProgID and GUID? The answer is that they are more or less aliases. Since the ProgID is easier for developers to remember and use, it is used by them while the cryptic GUID is used by the system. Both of them point to the same automation object in a given scenario.

The post COM Components and Scripting Process appeared first on Automation Dojos.

VBS Part 2 – Fundamentals and Concepts

Tushar Sharma — Thu, 20 Dec 2012 12:09:34 +0000

VBS Part 2 – Fundamentals and Concepts | As Published On Automation Dojos

Having gone through the Introductory part, it is time to look at some crucial fundamentals and concepts. This article is to refresh some of the key facts and features of VBScript. In the least, you should consider the following six points for developing a fundamental understanding of VBScript.

Though we will cover these concepts in depth along with examples in the subsequent tutorials, but for now these brief points are enough for you to understand ‘what you can or should do with VBScript’. So without further ado, let’s jump on to these concepts.

VBScript is a Scripting Language

‘VBScript’ is a ‘scripting language’! What does this mean? Well, a vague difference between a programming and scripting is that a scripting language is not pre-compiled until runtime and hence while the end product of a programming language is mostly a compiled binary executable program (example; .exe), the end product of a scripting language is rather the source code itself (example; .vbs file)!
Hence unlike C++, VB or other compiled programming languages, the ‘VBScript’ is essentially an ‘interpreted language’ which is interpreted by ‘VBScript Engine’ at runtime i.e. every time the code is actually executed it is interpreted (or compiled internally).

For detailed explanation around interpreted and compiled languages, please refer to the earlier article ‘Interpreted Vs Compiled languages‘

VBScript Supports ‘Late Binding’

Since VBScript is a not a compiled language, hence natively it supports only ‘Late Binding’. Therefore unlike the ‘Early Binding’ scenario, in case of VBScript being the ‘Late Binding’ language, the binding does not occur until the program is actually executed.

In this scenario the program usually performs frequent registry or namespace lookups upon execution to access the information about the ‘COM Object’, consequently, any issues with the COM information are not discovered until actual execution. For further reading around this concept, please refer to dedicated article on ‘Early Bound Vs Late Bound‘

Loosely Typed Language

When it comes to ‘Data Types’, VBScript is a ‘loosely typed language’. What this means is that the programmer does not have to declare the ‘Data Type’ of variables in advance. Stating it the other way, VBScript does not provide any means for declaring the ‘Data Types’ for the variables and rather uses a generic or universal data type called the ‘Variant’ which can logically hold any type of value by means of its ‘Sub-Type’

Such a strategy of ‘having and not having data type’ simultaneously is manifested by the concept of ‘Variant’ and its ‘Sub-Type’. Summing-up this by means of a vague analogy, “all variables in VBScript have a default ‘data type called variant’ which is equivalent of ‘no data type’, however, each variant has an associated ‘Sub-Type’ which could be a string, integer, float” etc. Together they manifest the ‘having and not-having’ strategy. More details around this have been discussed in the below section

Single and Universal Data Type

As discussed above, VBScript has only one Data Type which is called the ‘Variant’. This ‘Variant’ is a special type of data type in the sense that it can logically hold almost any type of value e.g. String, Integer, Date, time etc. But this does not mean the VBScript is totally unaware about ‘Data Types’, in order to facilitate VBScript with the intelligence to recognize and deal with ‘Data Types’ it has a special feature known as the ‘SubType’. This ‘SubType’ is kind of ‘Data Type’ of the ‘Variant’ itself. For better understanding Imagine this :

When you declare a variable it automatically gets the ‘Variant’ data type assigned to it. But when you actually put some value in this variable then VBScript assigns the appropriate Sub Type (data type) for this value. You do have means to force the data types or query the data types from there onwards.

So in VBScript, you can solve the dilemma of Data Types by asking the ‘Variant’ that, what is it’s SubType. Now, this might complicate things further hence we will leave it here on the worth mentioning note that – the ‘Variant’ is the only data type supported by VBScript and hence it is the only data type returned by VBScript functions.

Object Model and Libraries

VBScript does not have any proprietary object model of its own! That is to say that if you want to access say for example ‘FileSystem’ or ‘Network’ objects and namespace, VBScript alone cannot help you. It has no way to directly talk to these resources.

But the best part is, that it can hook to most of the COM Components or Servers and exploit them to get the work done. Hence whether you need to play with databases (ADO) or XMLs (DOM) or HTML (DOM) or any other supported COM stuff, it’s a piece of cake for VBS!

Apart from being such a COM Master, it has got some very cool good friends from the same Microsoft family; namely the ‘WSH’, ‘WMI’ and ‘Scripting Runtime Library’. You can literally get almost any scripting or automation task done on windows if you are able to make VBScript work together with these friends.

COM Enabled and COM Automation

On the last note, VBScript is a fully ‘COM-Enabled’ scripting language and hence can very well work with a variety of COM Components / Servers. The worth mentioning point is that VBScript works only with the COM Objects which implement an ‘IDispatch’ interface.

Moreover, VBScript supports COM scripting which is to say that you can create your own ‘Custom Classes’ and their methods and properties in VBScript. This gives you increased power while using VBScript. By coding ‘classes’ you can make your code more robust, modular and reusable.

The post VBS Part 2 – Fundamentals and Concepts appeared first on Automation Dojos.

What is In-Proc and Out-Proc (COM) ?

Tushar Sharma — Tue, 18 Dec 2012 12:08:21 +0000

What is In-Proc and Out-Proc (COM) ? | As Published On Automation Dojos

The terms ‘In-Proc’ and ‘Out-Proc’ are to describe the kind of implementation of COM Servers. Before we begin, for those who are not quite ‘COM’ savvy, here is a brief preface.

COM : The acronym COM stands for ‘Component Object Model‘ and it is the technology which provides a way for applications (.exe) and libraries (.dll) to make their functionality available to COM compliant applications or scripts. It helps developers to create re-usable software components as well as to link the components together to build applications.

Over a period the COM family has grown to include COM+ (MTS), Distributed COM (DCOM) and ActiveX. If you are interested in further reading refer to this official COM Page.

COM Servers and COM Clients :

Objects that make their functionality available through ‘COM’ are known as ‘COM Servers’ while the scripts or application which make use of this functionality are called ‘COM Clients’. As simple as that! As stated in the beginning of this post, ‘In-Proc’ and ‘Out-Proc’ terms describe the kind of implementation of COM Servers. Here is what they mean …

Out-Proc Servers :

These kinds of servers are generally implemented in executable files (.exe) and are characterized by being responsible for running in a different process than the script or application which called them.

This is to say that for example – if you are running a script which in the middle invokes a Microsoft Excel or Word as an object then this later object would run in a different process of its own then the script which called or invoked it. So if you observe your ‘Task Manager’ you would notice a ‘WScript.exe’ process (for the script) and another process as ‘winword.exe’ (for MSWord) object.

In-Proc Servers :

These type of servers are typically implemented in Libraries (.dll). and unlike the Out-Proc servers, they run in the same process as the script or application which called or invoked them. They do not create a separate process for themselves.

A good example would be the ‘Scrun.dll’ (Scripting Runtime Library). So if you try creating an instance of say ‘FileSystem’ Object (which exists in scrun.dll) you would not notice any separate process coming up then the already running process of the active script itself (WScript.exe).

On the last note, the worth mentioning point would be that ‘In-Proc’ servers are generally faster than the ‘Out-Proc’ servers since the operating system does not have to cross the process boundaries to interact with the object and its methods/properties.

The post What is In-Proc and Out-Proc (COM) ? appeared first on Automation Dojos.

VBS Part 1 – Introduction and Background

Tushar Sharma — Sat, 10 Nov 2012 11:09:33 +0000

VBS Part 1 – Introduction and Background | As Published On Automation Dojos

At the upfront, this theoretical article might look boring to most of us but still, it is advisable to know about our scripting friend before we start interacting and dealing with it. This is to provide a brief background of VBS, its purpose, origin etc., and if we don’t let go our patience it does turn out to be interesting! In this article, we would briefly discuss about – ‘Windows Script’, ‘Microsoft Visual Basic Family’, ‘VBScript’ background, history and versions.

To start with, the commonly referred to as ‘VB Script’ was developed by Microsoft and hence officially known as the ‘Microsoft’s Visual Basic Scripting Edition‘. It is one of the important members of the ‘Windows Script Technology’ which consists of a total of two members.

Windows Script Technology

The ‘Windows Script‘ is the technology which is the backbone of scripting on Windows platform. It has been manifested as two ‘Script Engines’. Although it is not recommended because of the resulting complexity but these two scripting languages can be included in parallel within a single project and should work perfectly fine!

Windows Script Engines

Visual Basic Scripting Edition (VBScript)
Microsoft JScript

Under this ‘Windows Script‘ banner, Microsoft provides an array of supporting features and technologies which includes tools like – debuggers, script encoders besides the COM libraries and object models like – Runtime Library (scrrun.dll), WSH, WMI, ADSI, DOM and many more.

We will discuss more about ‘VBScript’ in this article as well as in subsequent posts, but for ‘JScript’ we will put an end by saying that it is Microsoft’s implementation of ‘ECMA Scripting Standards and Specification‘. For reference the Netscape’s ‘JavaScript’ as well is an implementation of the same ECMA specification and hence there is a common misconception that both JScript and JavaScript are same but officially it might be wrong to say that.

The Microsoft VB Family

The ‘VBScript’ belongs to the Microsoft VB family, more precisely it is a subset of the ‘Microsoft’s Visual Basic Language‘, this is quite obvious when we look at the similarties in the syntax of the both. The VB family comprises of three members –

VB Family Members

Visual Basic Language
Visual Basic for Applications (VBA) and
Visual Basic Scripting Edition (VBScript)

Unlike the rest of the two members, the VBScript is typically a ‘scripting language‘ hence it inherits all the features and constraints of a ‘scripting language’. Since the VB and VBA are not in-scope of this article hence rather than ‘muddying the water’, we would restrict ourselves to VBScript. As with any scripting language VBScript is –

Windows Script Engines

‘Interpreted at Runtime’
Requires a ‘Host‘ to run on windows and
Does not support ‘Early Binding‘

Besides the above, it is a ‘Loosely Typed Language‘ which means it uses a ‘universal data‘ type (variant) and does not constraints the programmer to specify data types for variables while scripting. You can find more details and explanation on the above in related sections.

History and Background

Historically, VBScript was probably first released (version 1.0) and shipped with Internet Explorer (MSIE 3.0) in 1996. It was intended to be used by web-developers to enhance their ‘client-side scripting’ capabilities.

Nearly a year after, VBScript (version 2.0) was released with some added ‘server-side scripting’ capabilities for Internet Information Server (IIS) which was quite well leveraged with ASP. It was since then, that VBScript quickly claimed its right place. With this success, VBScript (version 3.0) was quickly introduced in Outlook 98 and for the first time appeared with ‘Windows Script Host‘ (WSH 1.0).

Together with ‘Windows Script Host‘ (WSH) which supported any ‘ActiveX Scripting‘ languages, VBScript proved a boon to system administrators by providing the capability to manage and control system resources via VBScripts and other ‘ActiveX scripting‘ languages.

Besides all this, VBScript still lacked any native ‘Object Model‘ and hence soon after, it was supplemented with a ‘Runtime Library‘ providing some ‘Object Model‘. This ‘Script Runtime Library‘ was implemented as ‘scrrun.dll‘ which primarily introduced ‘Dictionary‘ and ‘Filesystem (FSO) object models’.

During the early launch days of VBScript, it had to face a tough competition with another scripting language that preceded it – ‘JavaScript’. Moreover unlike VBScript the ‘Netscape’s‘ support for ‘JavaScript‘ did boost the acceptance of ‘JavaScript‘ in the market rather then VBScript. But due to Microsoft’s committment towards VBScript and subsequent inclusion of VBScript in number of Microsoft products like – IIS, Internet Explorer, Outlook and WSH made VBScript to survive the competition till date.

Latest and Significant Versions

Over the years because of Microsoft’s commitment to VBScript, there have been considerable releases of VBScript each of them adding more or less to it’s feature set. You can find detailed information about VBscript versions on this page on MSDN.

The latest version of VBScript available at the time of this article (Sept 2009) is VBScript version 5.8 available with Internet Explorer v8. However if you ask me the most significant release still remains the VBScript version 5.0. Since it was this VBScript version 5.0 in which Microsoft introduced the – ‘Class Objects’, ‘Class Statement’, ‘Property Let, Get and Set’, ‘Regular Expressions’, ‘Events’, Timer‘, etc.

Applied VBScript (The Playground)

As described above VBScript was meant to be ‘client-side scripting‘ language which holds true to the good extent till date besides its capabilities and usage in ‘server-side scripting‘ in conjunction with HTML, ASP or others. The ‘.HTC’ files being the most basic example of webpage and VBScript collaboration.

Apart from this web arena, VBScript is predominantly popular in ‘system administration‘ domain and of course proves as a good aid in related ‘system side development’ wherein it fits very well along with WSH, WMI, ADSI, ADO etc.

Moreover, to add to its importance and usage – The latest playground is of course HP’s ‘Quick Test Pro‘ which has considerably raised the popularity of VBScript among the ‘Software Testing Community’.

The post VBS Part 1 – Introduction and Background appeared first on Automation Dojos.