Windows Scripting Languages at the 50,000 Foot Level

I hear a lot of mindless, useless jabbering in and around the office regarding "best" this and that, when it comes to technology. A recent discussion touched on scripting tools, which is something near and dear to my heart, so I thought I'd digress a little on this subject. While I may tend to harp on one or two in particular, I strongly believe all languages have a place in our toolboxes. They each have an ideal purpose.

What are the major players in the world of scripting in a Microsoft Windows environment?

• BAT / CMD script


• Windows Scripting Host --> VBScript, JScript, ActivePerl


• KiXtart


• PowerShell

Each is worthy of strong consideration. Each offers a staggering volume of utility and flexibility. Each is "free" with some caveates (after all: nothing is ever truly "free").

How each is judged depends upon the context in which it is used. By that I mean which version of Windows is on all clients involved in the scripting task or process.

One thing that struck me as unique to KiXtart is that it is the only portable scripting engine of the four. The others must reside on the client where a task is executed. Even if you run a remote process, the engine must be installed on the client where the task is initiated. If a remote process invokes another instance which is local to the remote client (huh?) it too must have the engine installed.

KiXtart does not require this much effort.

You can put the KiXtart engein (Kix32.exe) on a server, share it out, and run all scripts on any clients by invoking the engine from the network share. There's no local installation ever required. Sure, there's a small processing burden (latency mostly) but if the script is rather linear, it typically works just fine and executes fast enough to barely notice a difference. Think "login scripts" here. The Kix32.exe engine is often copied into the NETLOGON share of the domain controller along with the scripts themselves, and any necessary support files which your scripts may rely upon or invoke. Clients simply run the scripts and script engine from the NETLOGON share.

I say this also because in the 25 or so years I've been writing program code, I've seen quite a few administrators knee-jerk and copy the Kix32.exe engine to each and every client and run it locally. This might be worthwhile on laptops which are often disconnected from the home network but completely unnecessary for desktops and servers within the home network.

BAT/CMD probably the most pervasive because they are uniquely tied to the Windows shell and therefore ubiquitous. The same is true for WSH, but only for Windows 2000 SP3 or later. Actually SP4 I believe is where WSH 5.6 becomes baked in. But PowerShell is still the odd man out, even with Windows Vista. Windows 7 finally bakes it in as part of the standard build, but that's technically in the future (right now: April 2009).

I hate to keep beating a dead horse, but KiXtart is a holistic approach to scripting in terms of the language, the toolset and the pervasiveness aspects. The language essentially combines best features of BAT with VBScript, while the engine is self-contained and entirely portable. This makes it very simple to "deploy" in any network environment. Post it into a central location and run everything from there, or run it locally by invoking it from the central location. Your choice. Pretty cool.

While PowerShell is undoubtedly more tuned to .NET interfaces and object-oriented processing and structures, it also incurs a steeper learning curve and a bit more complexity within the raw coding phase of development. The emergence of newer and more specialized cmdlets make it increasingly attractive, and for good reason. But iterative, procedural languages are NOT DEAD by any means. They're not even in decline. They continue to grow. Both of them continue to grow. There's room for both at the table. If you have time to learn both of them, then you should. But don't exclude one for the other either.