UniObjects, VBScript and Windows 7 (64)

As some of you will know from previous articles, I'm a big fan of VBScript. Yes, I started my grown-up programming life with UNIX and have spent a good number of hours using - and teaching - various forms of shell programming as a result. But VBScript is one of the true hidden gems of Windows, a full and well designed scripting language that sits on every desktop and has just the right mixture of control and invisibility. The VB-like syntax gives you the control when you need it and by offering almost no features of its own, it lets you control your scripting environment, applications, operating system and devices by calling on other, more powerful language elements to do the dirty work by acting as a COM client.

One particularly useful application of this, is that VBScript allows you to create easily-maintained scripts to automate a whole batch of UniVerse (or UniData) operations by leveraging UniObjects. Since UniObjects is a simple class wrapper around an excellent protocol for accessing the U2 databases, it plays very nicely with VBScript as a means of executing commands, calling subroutines and all the other paraphernalia that goes along with automating otherwise tedious and long running tasks.

Like cutting releases. Since almost all my products have some degree of client/server operation this naturally means having to build setups that span client and server code, and so I keep a nice library of cutting scripts, one for each product.

These will typically perform a series of actions such as:

• requesting a product version number.
• logging in the server.
• updating the source code version stamps.
• recompiling all source code for all platforms.
• building the server side setups.
• recompiling all client side code.
• updating the version stamp on the setup (normally InstallShield).
• building the setup.
• copying and renaming the setup files into a shipping directory.
• zipping up the setup.
• updating various log files.

So being able to use VBScript to automate these actions is very, very important to me.
And suddently not being able to call UniObjects from VBScript - typically at a point of urgent need - was .. well.. a problem.

Unfortunately, my nice new sleek laptop running 64 bit windows 7 wouldn't start UniObjects. No errors or breakages in the script, just a refusal to create the UniObjects instance - or any other third party COM component I wanted to access.

The reason was, of course, obvious.

UniObjects is a 32 bit COM component and I'm now using a 64 bit version of the Windows Scripting Host (WScript or CScript). Thankfully, Microsoft has provided two versions of the scripting host, with a 32 bit version sitting in the %windir%\SysWOW64 directory. This starts up UniObjects nicely and I can get back to running my cutting scripts, backups and all the other automation scripts. So if you are having problems with your COM scripts, that is the place to turn.

But an error message might have been nice.

As would retaining the ScriptPW class that allows you to prompt for a password. Gone in Windows 7.

Incidentally VBScript is also great for automated testing. I've been developing a new version of mvQuery for Sandri Technologies, who earlier this year bought the product outright. This involves replacing all the old VB and C++ code with shiny new .NET code, upgrading the Delphi code to the latest version - which is not backwardly compatible, thanks to its new owners - and redesigning the look and feel to fit a more up to date presentation.

But one feature definitely retained is the COM interface, which may seem anacrhonistic in this age of managed code. But the COM interface was added so we could perform automated regression testing: it has the ability to call into the client and perform a suite of activities from running queries to setting filters, running reports and exports and all the result set operations - and because this is a two way interface controlled through a scripting language, not only can it call these actions but it can spot check the results against what is expected.

One more advantage of VBScript for COM automation. Whenever I create a new COM controller in Delphi, this upsets my antivirus which wipes it immediately before I can get to run it. Which is damn inconvenient. But no such problems with VBScript... so far.