Thursday, August 18, 2011

Which PowerShell?

Confused?  Good.  You're not alone.  Microsoft is a bit confused as well. 

If you happen to be running Windows 7 64-bit and you haven't looked at PowerShell yet, you may be a little surprised to see there are two sets of shortcuts on the "Start" menu.  One set for x86 and the other for x64 (unlabeled).  So, what's the difference?  Aside from how each is managed in the Windows memory and process stack environments, they do behave differently.  I haven't begun to map out all of the possible deviations betwixt the two (I never get to use the word "betwixt", but now I can!  moo-ha-ha-haaaa!), however, I have run into one in-the-face obvious difference:

ENVIRONMENT variables on 64-bit Windows

If you open each console (yes, you can run them both at the same time), and type the following statement in and hit Enter, you may notice the output results are not the same:

get-childitem env:

Here's a screen shot of each:

ps1

ps2

I highlighted the key differences in red for the visually and mentally impaired (like me).  Can you spot them?  Have you played "Where's Waldo?"  I have to pause for a second to say that "x86" is a stupid-ass name.  Why not "x32"?  The "x64" is still based in large part on the "x86" architecture, so maybe they should be "x86/32" and "x86/64"?  Whatever.  I'm on my third beer, so I really don't care.  It's all stupid.  And making two versions of the same script interpretor on the same operating system is also stupid as shit and makes no sense at all.  Why even make a 32-bit version on a 64-bit machine?  Is there a 64-bit version of VBScript?  CMD?  Explorer?  Feh.

So, basically, if you're writing PowerShell scripts that will run on 64-bit clients, be careful to test the differences before unleashing it in production.

2 comments:

Jeffery Hicks said...

Unfortunately, you need two shells because some 3rd party snapins only run in 32 bit mode so on an x64 box you'd have to run them in a 32 bit PowerShell session.

skatterbrainz said...

Ok, I'll buy that. So, once again, Microsoft customers are hamstrung by third-party concerns. Lovely. But that still doesn't absolve Microsoft of the issues incurred by having the two behave differently. When I open CMD, which is 32-bit, it reports correctly via the SET command, so something is broken in the PS interpreter.