Archives for the Month of November, 2006

PowerShell Prompt Here PowerToy

Today, we have a guest post from Michael Murgolo. He's developed a PowerShell Prompt Here powertoy (like the one we all know and love,) but this one doesn't suffer from the uninstall bug that the current CMD Prompt Here powertoy (or its derivatives) do. And the explanation is awesome, to boot.


An Old PowerToy is New Again

by Michael Murgolo

PowerShell PowerToys Download

One of the most popular Windows PowerToys is the venerable Command (or CMD) Prompt Here.  This PowerToy is still available as part of the Microsoft PowerToys for Windows XP or the Windows Server 2003 Resource Kit Tools.  With this PowerToy installed, you can right click on a folder or drive in Windows Explorer and select CMD Prompt Here from the context menu.  This will open a command prompt with the selected folder as the current directory.

Because this is so handy, I use this PowerToy numerous times as day.  As I was trying to learn and use Windows PowerShell, I found myself wishing for the same functionality in PowerShell.  So I grabbed the Setup Information (INF) File for CMD Prompt Here, cmdhere.inf, from the Windows Server 2003 Resource Kit Tools and modified it to create a PowerShell Prompt Here context menu.  This INF file is included in the PowerShell PowerToys Download.  To install it, right click on the INF file and select Install.

In the course of creating the PowerShell version, I discovered that the original CMD Prompt Here PowerToy had a bug that would leave behind a dead context menu entry when it was uninstalled.  I have provided an updated version of cmdhere.inf for you convenience also in the PowerShell PowerToys Download. 

How it works

Both of these PowerToys take advantage of the fact that these context menu entries are configured in the Windows Registry under keys associated with the Directory and Drive object type.  This is done in the same way that context menu actions are associated with file types.

For example, when you right click on a .txt file in Explorer, you get several actions at the top of the list like Open, Print, and Edit.  To find out how these items are configured, let’s take a short journey through the HKEY_CLASSES_ROOT Registry hive.  If you open the Registry Editor and expand the HKEY_CLASSES_ROOT branch you will see keys that are named for file types like .doc, .txt, etc.  If you click on the .txt key, you will see the (Default) value is txtfile.

This is the object type associated with a .txt file.  If you scroll down and expand the txtfile key, then expand the shell key under that, you will see keys named for some of the context menu entries for a .txt file.  (You will not see all of them because there are other methods for creating context menus.)  Under each of these is a command key.  The (Default) value under the command key is the command line that Windows executes when you select that context menu item.

The PowerToys for both the CMD prompt and PowerShell prompt use this technique to configure the CMD Prompt Here and PowerShell Prompt Here context menu entries. There are no file types associated with drives and directories, but there is a Drive and a Directory key under HKEY_CLASSES_ROOT associated with those object types.

The PowerShellHere.ps1 script (in the attached file) shows how to set the same Registry entries as PowerShellHere.inf. This can be used in the case where an entry is Add/Remove Programs to uninstall the PowerToy is not desired.

To remove these entries you can use RemovePowerShellHere.ps1, also included in the PowerShell PowerToys Download.



Michael Murgolo is a Senior Infrastructure Consultant for Microsoft Consulting Services. He is focused in the areas of operating systems, deployment, network services, active directory, systems management, automation, and patch management.

Download the Official Windows PowerShell 1.0 Release!

A few minutes ago, Bob Muglia and Jeffrey Snover at IT Forum announced something at we've long been waiting for – the official Release to Web (RTW) of Windows PowerShell v1.0!

In late December of 2002, PowerShell entered the public eye when a Slashdot reader stumbled upon a job posting for "Microsoft's Next Generation Shell". About a year later, we officially announced the project (code-named "Monad") at the 2003 Microsoft Professional Developer's Conference. Things started to really pick up steam when we released our first really public preview in September of 2004 – a fact not missed by the ever vigilant Slashdot.
Since then, we've shipped incremental previews frequently, gaining enormous benefit from all of you – a passionate and active community of devoted beta enthusiasts:

"Monad" Beta 1 - 06/17/2005
"Monad" Beta 2 - 09/13/2005
"Monad" Beta 3 - 01/10/2006
"Monad" Beta 3.1 - 03/09/2006
Windows PowerShell RC1 - 04/25/2006
Windows PowerShell RC2 - 09/27/2006
Windows PowerShell RTW – 11/14/2006

Each release added features, fixed bugs, and incorporated heaps of changes initiated by feedback from the community.

This has been a long and adventurous journey – something that's truly been worth relishing. Whether you are an old or new participant in the PowerShell community, you should feel proud of your contributions – and for a job well done.

You can find pointers to the official release at -- so go install it, and enjoy the revolution!

A New Virtual Earth Mashup in Born

About 8 months ago, I wrote a Virtual Earth mashup to display commute times to Microsoft in and around the Seattle area. It's been very successful, and solves a big problem for many people looking to buy a house (amongst other things.)

About 3 or 4 months after posting the mashup, the Virtual Earth team changed a bunch of the APIs, which pretty much broke every existing mashup – including mine. I patched it up a bit some time later, but couldn't spend the time to fully restore its functionality. For example, the zooming controls were broken, as were the panning controls.

Neither writing the mashup (nor living through the breaking changes) were terribly pleasant experiences. The Virtual Earth map control was simply too basic. With not much effort, you get a map that scrolls, but nothing else. No UI, no support for panning, zooming, or anything else.

Want to make it interactive and snazzy? In my case, that meant copying tons of Virtual Earth infrastructure scripts, html, images, and other random junk in order to make something presentable.

However, the end result was definitely exciting despite all of that.

I checked on the APIs tonight to get a gauge on how much work was in front of me to fix it completely again, and was stunned. The Virtual Earth team has done a truly amazing job at focusing on making the job of a "masher" as easy as possible. Their programming model has matured significantly, placing a much cleaner boundary between your application and the Virtual Earth implementation details. It feels like a real API now, as opposed to forcing you into an invasive, parasitic implementation.

One innovation I'm immensely impressed with is their new interactive SDK. It takes cues from the cookbook / task-based approach to learning. First, you click on a node to say, "I want to --> Use pushpins --> Add a custom pushpin." Then, the SDK shows you – through an interactive working view, example code, and reference page -- exactly how to do it.

In the end, I didn't patch my old code back into working condition. I reused my support code, but rewrote the UI and interface to Virtual Earth again from scratch. In just a few hours I was done:

  • My index page has gone from 11k to 3k
  • My custom Javascript has gone from 6k to 5k
  • My entire project has shrunk from 391kb to 71kb
  • That furrow in my brow is gone

Kudos to the Virtual Earth team. The mashup experience is definitely a first-class citizen, and it shows.

Writing PowerShell Cmdlets vs. Writing PowerShell Providers

A question that sometimes comes up is, "When do I write a PowerShell provider instead of a cmdlet?" To explain that, it is useful to understand how PowerShell distills management concepts for administrators.

In the pre-PowerShell world, the command-line management experience is fairly fractured. You have a huge number of awkwardly named commands, with no way to quickly determine what they mean. Many of them perform nearly identical actions, but have very different names. The image above illustrates a chaotic mix of commands that work primarily on files and directories.

The first approach that PowerShell uses to distill management concepts is to name commands with a Verb-Noun (Action, Item) pattern.

To make it easier for an administrator to learn the actions available for a new noun (such as Service or Process,) we provide strong guidance that verbs come from a standard set. The image above shows how you might name the earlier commands, while paying attention to the standardized verbs.

Now, what happens if you want to make these cmdlets work on the Registry?  How would you name them in that situation? Some of them apply exactly (but operate on a RegistryKey rather than a File,) some of them may not apply (such as the content of a registry key,) and some of them definitely do not apply (such as the list of running processes.)

Notice that some of the nouns share a lot in common, and converge to a few basic concepts. From the examples given above, you can perform actions on items, content, and locations.

The first set is clearly unmanageable, and makes life difficult for administrators.

The second set provides the main benefit of cmdlets. Consistent naming, and discoverability. Administrators can say, "I have a <Noun>, so already have a pretty good idea of what I can do with it."

The third set provides the main benefits of providers. For the major noun sets that we know about (items, content, properties, and navigation,) we make it as easy as possible for you to implement all related commands for that set. When you do, Administrators can say, "This provider supports navigation and items, so I already have a pretty good idea of what commands work with it."

So, if you want to support any of the major noun sets, you should write a provider.

As PowerShell matures, so should its list of provider types. For example, the *-Process cmdlets and *-Service cmdlets are strikingly familiar, and suggest the need for a standard lifecycle set of cmdlets.  It should also be noted that you can implement any or all of the standard provider types. For any that you implement, you get all related cmdlets for free.

[Edit: Resized images]