Posted by Greg Stemp. One of the more interesting aspects about working at Microsoft is the fact that many people assume that if you work do here then you must be evil. You might think that that’s a terrible thing, and, on the whole, it probably is. On the other hand, though, it does have its advantages. For example, before I started working at Microsoft, I used to spend $150-200,000 a year on Girl Scout cookies. (I mean, they stake out all the entrances to the grocery stores these days. What chance do you have?) After I started working at Microsoft, however, things changed. Oh, sure, some of the girls might start to approach me, cookie boxes in hand, but then their mothers or their Scoutmasters or sometimes a perfect stranger would pull them back. “No, honey,” they’d say, “Not from him.” You’ve probably seen those movies where a gang of toughs starts hassling some poor guy, but then just before anything bad happens the guy pulls his coat back and reveals the handle of a gun stuffed in his pants? And then the gang members all back away saying, “Uh, look, man, we don’t want no trouble.” The same thing happens to me all the time, except that when pulling my coat back I don’t reveal the handle of a gun, I just reveal my Microsoft cardkey. Now that will empty a room in a hurry.

 

Of course, the truth is that people at Microsoft aren’t really evil. (Um, just don’t let the Girl Scouts know that, OK? I have a son I need to put through college someday.) It is true, however, that we are sometimes out of touch with what’s going on in the rest of the world. (Speaking of which, how’d the Brooklyn Dodgers do last year?) For obvious reasons, we live in a Microsoft-centered world, and we sometimes forget that most people don’t live in such a world.

 

I was reminded of this fact when reading some of the messages posted here from Kixtart fans; it was interesting to see how passionate they are about Kix. And that got me to wondering whether we Microsoft Scripting Guys have been doing a disservice to the scripting world. It’s true that we have always said that the scripting language you use is largely irrelevant; the secret to Windows scripting lies in understanding COM and in understanding how to make use of COM objects such as WMI and ADSI. We’ve always been pretty upfront about that. On the other hand, we haven’t really done much to connect to the Perl or the Python or the Kixtart communities. And that was probably a mistake. After all, at least 99% of the Script Center scripts have no dependence whatsoever on VBScript; they can just as easily be written in any scripting language that understands COM. But maybe we haven’t always done enough to make that point clear.

 

So what does that mean? Beats the heck out of me. But rather than being a typical, blinkered Microsoft employee, I decided to take a walk on the wild side and see what some of these other scripting languages are like. I downloaded a bunch of different scripting engines and what have you, and played around a little with three languages: Kixtart, Python, and Rexx. (Why those three? Well, I wanted to look at Kixtart because we’ve had a number of Kix-related posts here. As for the other two, who knows why I picked them; I just did.)

 

What I was interested in seeing was just how easy it would be to convert a typical Script Center script into one of these other languages. With that in mind, I started with this simple little WMI script, one that returns the name and state of all the services on the local computer:

 

strComputer = "."

objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")

colServices = objWMIService.ExecQuery("Select * from Win32_Service")

 

For Each objService in colServices

    Wscript.Echo objService.Name & " -- " & objService.State

Next

 

So how hard was it for me, with barely a glance at the documentation, to rewrite this script in Kixtart, Python, and Rexx? Actually, it was surprisingly easy. For example, here’s the Kixtart script I came up with:

 

$strComputer = "."

$objWMIService = GetObject("winmgmts:\\" + $strComputer + "\root\cimv2")

$colServices = $objWMIService.ExecQuery("Select * from Win32_Service")

 

For Each $objService in $colServices

    ? $objService.Name + " -- " + $objService.State

Next

 

I don’t know whether this is the way a true Kixtart aficionado would write the script, but at least this one did what I wanted it to: it returned the name and state of all the services on the local computer. What I thought was interesting was the fact that the Kix version of our WMI script and the VBScript version were remarkably similar. As near as I can tell the only differences are:

 

  • In Kix variable names are prefaced with a dollar sign ($).
  • In Kix, the plus sign (+) is used for string concatenation rather than the ampersand (&).
  • In Kix, you echo information to the screen using a question mark (?) rather than Wscript.Echo

 

Does that mean we should try to convince Kixtart users to switch to VBScript? Of course not; it just means that creating Kixtart versions of our WMI scripts wouldn’t be all that hard.

 

The same thing was true of both Rexx and Python. For example, here’s the Rexx version of our WMI script:

 

strComputer = "."

objWMIService = .OLEObject~GetObject("winmgmts:\\"||strComputer||"\root\cimv2")

 

do objService over objWMIService~ExecQuery("Select * from win32_service")

  say objService~Name "  -- " objService~state

end

 

A little weirder, perhaps, at least for someone brought up on VBScript, but, still, even if you’d never seen a Rexx script before you could take a look at this and figure out what’s going on. And while the tildes (~) are a bit hard to get used to, I must admit I kind of like using say rather than Wscript.Echo. Very cool, IBM, and somewhat reminiscent of AppleScript, which I don’t know much about, but which I do know uses English-like commands similar to this:

 

count the files in the first window of application "Finder"

 

As for Python, well, I had to use the SWbemLocator object to connect to WMI (I don’t know if that’s required, that was just the only way I could get it to work), but other than that the script was pretty straightforward:

 

import win32com.client

strComputer = "."

objWMIService = win32com.client.Dispatch("WbemScripting.SWbemLocator")

objSWbemServices = objWMIService.ConnectServer(strComputer,"root\cimv2")

colServices = objSWbemServices.ExecQuery("Select * from Win32_Service")

 

for objService in colServices:

    print objService.Name, " -- ", objService.State

 

All in all an interesting experience (and I still have a few more languages, like Perl and Ruby, to try out). And it made me decide (without bothering to consult any of the other Scripting Guys) that we need to see if we can do something to support these other languages and these other scripting communities. For example, maybe we could release language-specific versions of the Scriptomatic. Believe it or not, when we first released the Scriptomatic, we had this idealized vision of some sort of –omatic Land within the Script Center, some place where people could submit their variations on the Scriptomatic (yes, exactly like the Kixomatic), So far, though, we haven’t been able to get permission to post user-submitted materials in the Script Center. That caused us to forget the idea of –omatic Land, but maybe we ought to just create our own Scriptomatics that can pump out Rexx scripts or Python scripts or whatever.

 

And what about scripts already in the Script Center? Well, there’s no chance that we’re going to rewrite all those scripts in half a dozen or more scripting languages. However, maybe we could create some sort of Convertomatic program: you load in a VBScript script from the Script Center, and the Convertomatic spits out a Python script. For some of these languages, that seems very possible. At the very least, I now believe that we really have to put together some sort of translation guide to at least show people how they can convert our scripts to the scripting language they like best. The point is not for us to try somehow take over the Kixtart community; instead, the point is that we have a huge repository of useful administration scripts, and we ought to try and make these scripts available to as many people as we can. Would we be willing to, say, do a Webcast where we showed people how to access WMI or ADSI from several different scripting languages? You bet we would, if there seems to be enough interest in such a thing.

 

I’d be interested in hearing suggestions on these somewhat vague notions. What do you say, guys? (And I now know that the Kixtart community is not afraid to voice an opinion or two.) Are there ways that we can better interact with the non-VBScript world? Or would you just as soon we Microsofties stay as far away from your communities as possible? (What if I set my cardkey on the table and keep my hands in plain sight at all times?) Let me know; I’m very interested in this. In the meantime, I’ll talk this over with the other Scripting Guys, and I’ll play around with some of these other languages I downloaded. Might we someday see Haskell scripts posted in the Script Center? Hey, who knows; maybe someday all the scripts in the Script Center will be Haskell scripts.

 

Well, OK, maybe we won't go quite that far. Still ....