Icon Exceptions for Taskbar Grouping

In its oldest and simplest configuration, the Windows taskbar lists the top-level windows, typically thought of as the running applications or open documents, in the order that they were opened. Windows XP introduced an option to “Group similar taskbar buttons”. Indeed, the option is already on when Windows is installed, such that your option really is about turning it off.

Taskbar buttons are regarded as similar if the windows they represent are created by the same program. If space is available on the taskbar, the buttons are merely rearranged so that buttons for the same group are placed together. For a typical example:

1. start Notepad and save the blank page as 1.txt;
2. start the Calculator;
3. start Notepad and save the blank page as 2.txt.

Instead of the buttons appearing on the taskbar in the order that you ran the programs, the two instances of Notepad are placed together:

If you have sufficiently many taskbar buttons, e.g., because you keep making more documents with Notepad, a group may get compacted to one button:

Clicking on the one button opens a floating menu from which to choose the instance that you want.

Exceptions Icons

There may be many ways to configure the grouping of taskbar buttons, and perhaps Microsoft will some day make it that users can just drag taskbar buttons around the taskbar into whatever arrangement they happen to want. This note, however, is motivated by one particular point of configurability. It’s not clear what the feature is meant to be called. There doesn’t seem to be any documentation by Microsoft. It clearly is designed for extensibility, yet only one real-world use is known of it—and a potentially controversial use it is, too.

To see the feature at work, in what appears to be the case it was designed for, try the following with Windows XP and Microsoft Office 2002:

1. Start Outlook;
2. Start any other program, e.g., a Command Prompt;
3. Start Word, automatically creating one Blank Document, and check “Windows in Taskbar” on the View tab in the Options dialog;
4. Still in Word, open the New menu and create a Blank E-mail Message;
5. Still in Word, click the New button on the toolbar to create another Blank Document;
6. Return to Outlook, clear “Use Microsoft Word to edit e-mail messages” on the Mail Format tab in the Options dialog, and create a New Mail Message.

The point to the other program at step 2 is just to separate the Outlook and Word groups. The point to the “Windows in Taskbar” option is to arrange that each Word document has its own window and its own taskbar button, such that there can be a non-trivial group of taskbar buttons for Word. Without this option, Word would use the Multiple Document Interface (MDI) and have just the one window and taskbar button no matter how many documents are open. The point to the “Use Microsoft Word to edit e-mail messages” is just to show that the effect applies even when the integration of Word and Outlook is lessened by keeping Outlook as editor of its own emails. Each step creates one toolbar button but not in the order of the steps:

Instead, the taskbar is laid out as if the steps were taken as 1, 4, 6, 2, 3, 5. What has happened here is that the taskbar buttons for email messages are brought together on the taskbar as a group with Outlook even if actually created using Word.

Configurability

The generality beneath this particular use of the feature by Microsoft is that any program’s taskbar buttons can be grouped as if they belong to any other programs.

Each exception to the ordinary arrangement of taskbar buttons is a rule with three parts: a source application, an icon and a target application. If a taskbar button for a specified source application has a specified icon, then the taskbar button gets grouped instead with the specified target application (if an instance is already on the taskbar).

Registry Details

The following details are for the EXPLORER.EXE version 6.0 from Windows Vista. The Windows XP builds of the same EXPLORER version have a slightly different implementation. A list of EXPLORER Versions is given in the separate study of the Windows Shell.

In the source application’s representation under HKEY_CLASSES_ROOT\Applications, there may be a subkey named TaskbarExceptionsIcons which in turn may have any number of subkeys. Each subkey defines a rule for the source application. The name of such a subkey is irrelevant to the code but presumably helps document the configuration for human readers. To be meaningful, each of these subkeys must have two values, IconPath and NewExeName, which specify respectively an icon and a target application.

Key:	HKEY_CLASSES_ROOT\Applications\application\TaskbarExceptionsIcons\rule
Value:	IconPath

The data for the IconPath value may be of any type but is interpreted as string data in the standard form of three elements for specifying an icon:

• pathname to a file that contains icons;
• a comma;
• a decimal index of the icon within the file’s resources.

The parsing details are those of the documented SHLWAPI function PathParseIconLocation.

Key:	HKEY_CLASSES_ROOT\Applications\application\TaskbarExceptionsIcons\rule
Value:	NewExeName

The data for the NewExeName value, again of any type but clearly intended to be string data, is interpreted as the filename of the target executable.

Use By Microsoft

Windows XP and higher (up to and including Windows Vista SP1, at least) are installed with one rule already configured:

Source Application	Name of Rule	Icon	Target Application
winword.exe	WordMail	explorer.exe,16	OUTLOOK.EXE

If a program named WINWORD.EXE, i.e., the word processor in Microsoft Office, creates a top-level window whose taskbar icon is , strongly suggesting that the window is for a Word document intended as email, then the taskbar button for that window is not grouped with other taskbar buttons for WINWORD.EXE such as might represent ordinary documents, but is instead grouped with taskbar buttons for a program named OUTLOOK.EXE, which is the Microsoft Office program for email.

That is the behaviour demonstrated above. However, it does not matter whether the WINWORD.EXE and OUTLOOK.EXE programs actually are from Microsoft Office, only that the one named WINWORD.EXE can make a top-level window with that particular taskbar icon.

Demonstration Tool

The very simple TBICON program creates a blank, menu-less window that does very nearly nothing except respond to WM_GETICON messages by returning a handle to whatever icon was named on the program’s command line. EXPLORER then uses this icon for the program’s taskbar button (even though it is not the icon in the window frame). The tool has its effect no matter what you rename it to, and is therefore well suited to confirming the effect of a proposed TaskbarExceptionsIcons configuration before committing to it.

To reproduce the effect for Word and Outlook, check that your Windows configuration (still) has the corresponding registry entries, then try the following in a test directory in which you place one copy of TBICON.EXE, a second copy renamed as WINWORD.EXE, and a copy of an arbitrary program, e.g., CALC.EXE, renamed to OUTLOOK.EXE:

1. Start the Windows Explorer;
2. Run the fake OUTLOOK.EXE from the Windows Explorer;
3. Start a Command Prompt;
4. From the Command Prompt, run tbicon, i.e., with no command line;
5. From the Command Prompt, run tbicon explorer.exe,16;
6. From the Command Prompt, run winword, i.e., with no command line;
7. From the Command Prompt, run winword explorer.exe,16.

The result will be something like:

This shows the Windows Explorer from step 1, the fake OUTLOOK.EXE from step 2 and then the fake WINWORD.EXE from step 7. Steps 4 to 7 are all TBICON, but only step 7 has the right name and the right icon, and only the taskbar button from step 7 is moved on the taskbar to join the fake OUTLOOK.

For distribution, the built program (x86) is supplied with source code, compressed into one zip file: download the Taskbar Icon Test program.

Anti-Competitive Practices

Note the several implications for monopolistic abuse by Microsoft. Windows is a monopoly product. It has essentially no competitors in the market for operating systems that run on the relevant hardware. Office is not a monopoly product. It has competitors in supposedly open markets: there are other word processors and email clients to run on Windows. Under American anti-trust laws, Microsoft is not supposed to use its monopoly product as leverage to favour its other products relative to their competitors. Yet here we see that an important element of Windows—indeed, the start of everyone’s experience of the look-and-feel of Windows—has an undocumented behaviour for the benefit of Microsoft Office. While the behaviour is undocumented, it cannot readily by obtained by software that competes with Office.

Note that this is not a case where Microsoft has Windows support an application for backwards compatibility. There are plenty of registry entries in a newly installed Windows that exist solely to help old applications, both from Microsoft and not. A typical case is that new behaviour in the new Windows has to be turned off for specific applications that pre-date the advance and were revealed in pre-release testing of the new Windows to be incompatible. Other cases are known where new code is written for Windows to accommodate known bugs in old applications. All this is a responsible and even admirable practice by Microsoft in the interests of its operating-system customers who happen also to be other people’s customers for applications that run on Microsoft’s operating system. Even if done to support Microsoft’s own applications, nobody has any reasonable cause for complaint, at least not if the process is open and transparent.

This case is different. Its effect is to use a newly developed feature of Windows XP so that two components of the roughly contemporaneous Microsoft Office 2002 can look to be better integrated in their handling of email than could be arranged for any competing suite of office software.

Whether this better integration brought a significant benefit to Microsoft, e.g., in terms of selling Office, I don’t know. The behaviour perhaps has never registered consciously with any user. But even a subconscious impression of better integration within an application suite and between applications and the operating system surely is commercially valuable and might well be built on an accumulation of small features. This feature evidently seemed sufficiently worthwhile to someone at Microsoft to warrant a programmer’s time both to write the code and to get the icon, and it’s not credible that this happened without it being decided on as strategy by someone with an overview both of Office and Windows.

Note also that this is not just old code, from before Microsoft’s settlement of its anti-trust troubles. Though the setup program for Office 2007 knows to delete the TaskbarExceptionsIcon key for WINWORD.EXE, versions of Windows from after Windows XP have not only continued the feature for earlier Office versions but developed it a little. The relevant code in EXPLORER was reviewed and modified for Windows Server 2003, with changes to the registry details and a corresponding change to the Windows setup. If the business and political communities think that Microsoft has given up old practices, they might do well to look more closely and think again.