Advice for Windows XP Scripting, WSH versus PowerShell

Question

After much experience scripting in the Unix/Linux open-source world, using languages such as Bourne Shell, Perl, Python, and Ruby, I now find myself needing to do some Windows XP administration scripting. It appears that the legacy environment is Windows Script Host (WSH), which can use various scripting languages, but the primary language is VBScript, and is based on COM objects. However, the future appears to be Windows PowerShell, which is based on .NET.

I haven't done Basic since Applesoft in the 1970s, so I'm not keen on learning VBScript, although I did learn enough to write a small script to mount network drives. If I'm going to spend time to really learn this, I'm leaning towards investing my time in the .NET PowerShell environment, if it truly is the future. I did some C# Windows Forms programming a couple of years ago, so I have some exposure to .NET, which also makes PowerShell attractive.

Understanding that no one has a crystal ball to predict the future of Microsoft, I would like hear from anyone who is a PowerShell user and thinks it's worthwhile, or if there is anyone that knows of serious drawbacks to PowerShell, and recommends that I stay away from it.

Update: I ended up using WSH/VBScript for a particular script that I am installing as a startup script on user's Windows XP workstations. All I have to do is copy it to their Startup folder, and I'm done. However, I only learned enough WSH to accomplish this one job. I am glad to see that PowerShell is the future, and when I have more complicated scripting tasks, I'll turn to PowerShell.

Answer 1

Is it "worthwhile"?

Absolutely. Here are number of reasons why.

1. More and more Microsoft products are based-on PowerShell - e.g. Exchange Server 2007, SQL Server 2008, etc.
   
2. PowerShell can access Microsoft .NET.
3. Easy to learn - You only need few commands to explore capabilities of PowerShell - e.g.) Get-Command, Get-Help, Get-Member, etc.
4. Most of commands are aliased and mapped in a way that they are similar to DOS or *NIX shell commands - e.g.) "ls" and "dir" are aliases for "Get-ChildItem", "cd" for "Set-Location"
5. It's a great developer's tool - Since PowerShell can access .NET library, you can prototype some of your .NET functionalities in PowerShell
6. You can navigate around Registry, Certificate, Environment Variables, etc as if they are file system - You use the same command you use in FileSystem to navigate around - e.g.) cd HKLM:\

Drawbacks:

1. PowerShell version 1.0 does not support Remoting (supported in 2.0) and creating a new thread(using System.Threading.Thread, but will support background jobs in 2.0)
   
2. Learning curve can be long if you are not used to C#/Java based language
   
3. It's hard to create generic .NET objects
   • e.g.) creating a generic List<int> collection is like following

$l = new-Object System.Collections.Generic.List``1[[System.Int32]]

Answer 2

Powershell is definitely the way to go if you tend to look forward but it has to be installed separately on Windows before 7 which might make WSH a more attractive target if you just want to deploy scripts that run without further dependencies. Also, .NET isn't included yet on ancient Windows versions like XP which further raises the bar.

If you had some exposure to .NET you should find Powershell pretty intuitive, however. And especially in Windows Server environments it seems to quickly become the default for command-line administering since nearly all newly-released server components ship with custom Powershell cmdlets. So Powershell seems to be a path for Microsoft they want to follow for a while. Heck, they didn't even bury COM so far so I'd expect Powershell to live at least a decade longer, since they position it as the automation and scripting environment for administrative tasks.

Also I found an object-based pipeline, while it took me a while to get accustomed to it, very powerful and easy to use in the end. Certainly simplifies many things that require sed/awk on *nixes.

That being said, I still use Windows batch files for many stuff that should run on Windows without any more dependencies but that's just a dirty habit of mine :)

Answer 3

The main advantage of WSH is that it's been installed by default since Windows 98, possibly even Windows 95, but as PowerShell comes with Server 2008 now, and is installable on anything after XP, it's becoming less of an issue.

If you have full control over the servers which your scripts will run on, I'd recommend going with PowerShell.

Answer 4

I have been looking for a best scripting language for Windows for quite some time (and still do). However, after seeing all variants I end up with JScript for WSH. While Powershell clearly has advantages, advantages from the first post seems non-significant (except built-in IDE). Disadvantages, however, not completly listed:

1. Before you can run the script you have to manually enable possibility to run them, which make deploying on a distributed network much harder than with WSH.
2. Naming convention for cmdlets. It is not camelCase, nor python_tail. It literally burn my eyes.
3. Variable names starts with $ (Perl-style I think? dont know exactly) - same here.
4. You can not use realative paths to run scripts.

On contrary JScript is more C-like, do not require explicit enabling of script running, accepts relative paths, case sensitive and loosely typed (both are IMHO advantages for scripting language, compared to VBScript). I don`t have much knowlege in PowerShell, just what I found on on MS Technet and around the net.

So for me two major reasons why I rejected powershell (even knowing that it probably more powerful and MS actively supporting it) were: 1) That you have to manually enable script running possibility on each machine 2) General non C-like view, to wich I used to (and not only me, I guess).

Answer 5

Use Posershell if possible and inline C#, if not - WSH, no? - msdos-batch.

Answer 6

Here we are now in 2017 and, in hindsight, it looks like Powershell was a good choice, IMHO.