I’ve recently read several blogs about how great Windows PowerShell is, so I decided to check it out myself last night.
I didn’t get very far before I came across this on the download page:
“The .NET Framework 2.0 is required in order to install Windows PowerShell”
Ok, fair enough.
And then I proceeded to actually check out the download page, where they present no fewer than 20 different download options, including variants for “English” and “localized”, x86 and x64, plus Itanium.
First, I know from experience that it would be almost insane to suggest that small development shops try to maintain 20 different downloads of what is essentially the same product. MS can get away with this because they’ve got lots of money to throw at the problem, but is 20 different downloads of a command shell utility really justified? Ok, some of them are for some MultiLingual UI addon, so the total versions of the utility iself is fewer than that, but not by much.
The bigger issue I have here, though, is that I thought, and MS would surely have everyone believe, that the .NET runtime and the JIT compiler within should automatically be handling the differences between x86, x64 and Itanium. That’s the whole point of the JIT, right? The multilanguage versions? I can accept them, with reservations, but the different processor versions? I’m no expert on the PowerShell internals, but if it requires the .NET framework, that would seem to imply that it’s managed code, which would imply that the JIT should take care of the differences between platforms. And if it’s not managed code, why not? Is it that MS is saying that managed code is good enough for everyone else, but not good enough for them?
Reminds me of the discovery I made ages ago that Outlook communicates with Exchange via RPC, not via DCOM, even though DCOM was being pushed hard by Microsoft at the time. Another case of “good for you, not good enough for us”, perhaps?
Oh, and PowerShell looks like a very handy tool for Administrators. I’m sure I’ll find some uses for it eventually. But, get-childitems -path env: just to retrieve the current environment vars? There’s something to be said for mapping all sorts of various available info like that into a consistent interface, but my stack’s too deep as it is right now to pile this syntax on top just yet.
2 Comments
It seems like every time I post something it comes out all grizzled and curmudgeony, and I don’t want to be negative… but why powershell?
Not that the existing CMD functionality doesn’t need updating, and an object based interface would be a boon to developers. But why on earth did they go this route instead of beefing up the existing CMD component?
Assuming I understand, it sounds like it be easier and more efficient to deploy the scripting engine and use .vbs files to get the same level of functionality.
So what am I missing? What can’t-live-without features does powershell offer?
Good Question. It’s mine, too.
From what I’ve seen so far, PowerShell is really targeted at sysadmins whose main function is to automate all the various functions that happen on a typical large windows network. Things like creating/removing/disabling logins, resetting passwords, automatically installing/removing software, stuff like that, stuff that I don’t normally need to automate.
I believe VBS scripts could do everything, just not in the same, integrated manner.
But that "killer app" scenario for PowerShell? I don’t have one.
Anyone care to throw in on that?