System Tray Notification area icons

If you’re a developer writing for Windows 7, you’ll probably have noticed that icons in the System Tray aren’t shown by default. Raymond Chen blogged about this recently, here and here. Notification icons are identified by a GUID, a Globally Unique IDentifier, which is just a big number. The idea is that each application that wanted to show an icon would use a GUID that only it knows about, the user remains in control by being the only one who can move icons from the notifications fly-out thingy (the little chevron at the left of the system tray) into the system tray (this is called promoting an icon); everybody would be happy. Well, almost.

As Raymond explained it in his blog, apps want to make sure you get their notification, they’ll do anything to make sure you do! (including totally and completely unsupported hacks). Apps will even try to spoof other application’s icons, i.e. disguise themselves as a different app to “steal” that other app’s icons’ promotion state. To prevent this and keep the user in control and keep annoying apps at bay, logic was added that would register the path to the executable registering the icon the first time, and if a different executable tried registering the same icon, it would just be hidden. Sounds like a fairly straightforward approach.

The problem is, what if an app’s vendor decided to change the installation folder for their app? For example, imagine the app is installed to “C:\Program Files\MyApp 9.0” and they wanted to release version 10.0, which installs to something like “C:\Program Files\MyApp 10.0”. Since we verify that the path of the calling process’ exe is the same as the exe that registered the icon, this would cause this scenario to fail.

We decided it was probably a fair thing to do to let ISVs manage their own icons, so that they can use the same icon object from the two versions. But how would they that?

The resulting design was that, if the path check failed, we would check the signature in the exe (and store it when you first run the app). If both the old and new exes have signatures, and the Publisher field matches, then we would allow the icon to be taken over.

This new behavior is included in Windows 7 SP1/Windows Server 2008 SP1, and also in a “stability and reliability update” described here and downloadable here. The behavior is also documented as an addendum to the MSDN documentation for the NOTIFYICONDATA structure in the Troubleshooting section:

The path of the binary file is included in the registration of the icon's GUID and cannot be changed. Settings associated with the icon are preserved through an upgrade only if the file path and GUID are unchanged. If the path must be changed, the application should remove any GUID information that was added when the existing icon was registered. Once that information is removed, you can move the binary file to a new location and reregister it with a new GUID. Any settings associated with the original GUID registration will be lost.

This also occurs in the case of a side-by-side installation. When dealing with a side-by-side installation, new versions of the application should update the GUID of the binary file.

Note The only exception to a moved file occurs when both the original and moved binary files are Authenticode -signed by the same company. In that case, settings are preserved through the move.

This new design/addendum to the behavior took fairly long to implement and get right, so you can say the engineer testing this and I “grew fond” of this code  

Anyway, hope my story “infotained” you, let me know in the comments section what you’d like to hear about next!