The Scripting Guys Get Their Kix (and Python and Rexx)

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



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



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



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 ....


Comments (14)

  1. Mo says:

    It’s funny you should mention Microsoft and evilness.. I was in Austria a few months ago, and had a meeting at Kapsch (the telecoms people), who share a campus with Microsoft and various other people.

    That lunchtime, a bunch of us from Kapsch head down to the [almost] on-site pub. A few minutes after sitting down for lunch, half the pub erupts into jeering. Not speaking very much German, it took me a moment to realise what the shouting was about…

    Turns out, a small group of Microsoft Austria employees had forgotten to hide their keycards. Nothing more. Just "those guys work for Microsoft" was enough for the whole place to erupt. Very very very weird.

  2. Mo says:

    On a slightly more on-topic note, I don’t suppose you [the scripting guys] know of an implementation of the Korn shell for Win32 that’s COM-aware? You know, something like the ‘dtksh’ provided with CDE systems that had the ability to do all kinds of funky stuff…

  3. Adam Weigert says:

    Off topic sort of: I think Microsoft is an awesome company, and I do not even work for or are paid in anyway by them. I love promoting many of their products, simply because they are superior.

    *tear* as a young developer I had dreams of grandure of one day working there … but alas I am content where I am, being an (almost) evangelical Microsoft know it all programmer and technical consultant in a medium sized company.

    Those that tends to push that Microsoft is evil or trying to take over are just people that are not in the know ๐Ÿ˜‰

    Where i work the moto is, good people working towards a common goal can accomplish anything … I can see this applying to the vast people I have come in contact who do work for them …

    Thanks guys, always helpful to know more about WMI than I might want to ๐Ÿ˜€

  4. sil says:

    Cor, please write the Covertomatic. How much do I have to grovel for it to work on ASP pages?

    I think it would be partially interesting to see scripts in non-MS languages, but part of the problem is that you won’t be using *Python* (say), you’ll be using the subset of Python that works like VBS. So, if you want to send mail from a script to tell you it’s finished, then you might well invoke a COM object to send that mail. A normal Python script, on the other hand, would use the smtplib module, but then the knowledge you’re giving people with your example is Python-specific and not translatable to other languages. I’m unclear what the resolution is here…

  5. Sealeopard says:


    In Kix, you echo information to the screen using a question mark (?) rather than Wscript.Echo

    This is actually a common misconceptipn. KiXtart doesn’t have an equivalent to Wscript.Echo, as by default, strings will be written to the console. The question mark (?) only moves the cursor to a new line. A valid console output in KiXtart could for example be

    <br>&quot;This is a multi-line&quot;+@CRLF+&quot;string withut any&quot;+@CRLF+&quot;questions marks&quot;

    BTW, Perl is also worth a look, as it gives you the option to compile the script into an executable.

    Finally, maybe it would be sufficient to just post an article on how to convert scripts from VBScript to the other scripting languages.

  6. Lonkero says:

    and maybe point to couple of the kix-scripts that already do that? ๐Ÿ˜‰

  7. DJ says:

    Convertomatic sounds like a great idea to me!

  8. Sealeopard says:

    Consider it done!

    The KiXtart BBS UDF Forum, which contains over 400 user-defined functions, already features a VBScript-To-KiXtart conversion routine at the following URL:

    The only drawback I am aware of with regards to a VBScript-to-KiXtart conversion is that KiXtart does not yet support ByRef variable passing, which is required for some COM functionality and potentially for custom subroutines. However, rest assured, we are working hard on getting this functionality included into KiXtart once the pre-tokenizer has been finished.

  9. Lonkero says:

    sil, that’s true.

    VBS lacks so much in basic "core", thus it needs to go for everything to the COM.

    kixtart has it’s logonscript-based commands and functions, so yes, already there we have noted things are not different.

    you mention python, I do that for perl and tcl.

    with all those create capabilities, dude, I know what you mean.

    the languages are different.

    but, the nice thing is that scripting-dudes have chosen VBS.

    thus their code is adaptable pretty easily without knowing of any language.

    then, once you learn the language, you might realize you get done lot more easier but until that.

    now, I know that produces more VBS script-kiddies and don’t like them all but if that means we got at least some sorta service from MS, I can bare that.

    see my point? ๐Ÿ˜‰

  10. Lonkero says:

    oh, missed the solution part :@

    solution might be to hire ppl from all languages (sounds weird) to fight for their rights.

    another solution might be to trust the communities to write scripts for the dudes.

    msdn has the habit to write stuff on multiple languages, and it seems to love iframes.

    so on new goodies while the boys are writing stuff, they could ask for quickie conversion.

    that is if they don’t have the spare time to write on their own ๐Ÿ˜‰

  11. Tarjei T. Jensen says:

    An overview of how to get wsh and wmi to work with other scripting languages than vbs would be nice. But keep vbs as a lingua franca.

    If you want to do some good then

    1. get an include statement in vbs. Or get them to support some sort of library.

    2. make the vbs engine to be used a source code choice and not a command line choice.


  12. Sealeopard says:

    The VBS engine to be used should still be a command-line choice as I want to control how to execute a script not the person who wrote the script (which is not necessarily me).

Skip to main content