How did that program manage to pin itself to my taskbar when I installed it?

Occasionally, somebody will notice that upon installing a program, it managed to pin itself to the taskbar. But just like there is no Pin­To­Start­Menu function, there is also no Pin­To­Taskbar function, and for the same reason: Because applications would abuse it and auto-pin themselves because they are so awesome, and so that the developer could get a nice bonus.

In spite of these roadblocks, some applications manage to pin themselves to the taskbar anyway, typically by programmatically driving the shortcut context menu. The developer then collects their bonus and goes out and gets drunk.

There is no real way of blocking this behavior other than giving guidance not to do that. Customers who complain to the vendors about their presumptiveness may help. Scornful looks and ignoring them when they walk by the lunch table looking for a place to sit may also work. (But since they're drunk, they may not care.)

Comments (27)
  1. Shawn says:

    I know of one program that does this. One I use on almost every workstation, so I witness it pin itself all the time. I'd love to call it out by name, but I know that's off-limits.

  2. Nicholas T says:

    Hi, I totally understand this but the autopinning is not in all circumstances bad, allow me to play Devils Advocate here a moment. A few years ago when Windows 7 had been released for a while I was working on moving a system from Windows XP to Windows 7. This was a traffic control system that had to be installed on hundreds of machines around the country and one of the requests was that upon installation the different programs would be available on the taskbar. We could tell we were doing something wrong when there wasn't a nice interface to do it but for the software and its purpose it was what was required.

    [This is a slightly different case, because yours is a special-purpose program running on a dedicated computer. In that case, the computer isn't really the user's for customization. The computer belongs to the traffic control system. -Raymond]
  3. Kevin A says:

    "There is no real way of blocking this behavior other than giving guidance not to do that."

    Oh yes there is: sandboxing of all programs by default. Right now any program that is run can do whatever it wants with the user's data. There are no walls and security. By default a program should not be able to touch any data belonging to other applications (and that includes start menu, taskbar etc. which belong to explorer.exe).

    It can be done, but it's complicated and would not be compatible with most existing software. So I guess you were almost right: there is no EASY way of blocking this behaviour without breaking existing programs.

  4. 12BitSlab says:

    @ Kevin A — that is what MSFT calls WinRT.

  5. Johan says:

    Kevin A, you mean like the store apps? Hopefully we'll see the number of useful apps there grow.

  6. Cesar says:

    @Kevin A: another problem with sandboxing is that it forbids programs which do unconventional things.

    For instance, most programs would be happy enough being able to tell the sandbox "give me a file open dialog" and receiving an open file descriptor (or equivalent capability) to the file chosen by the user, and having a separate save area to which they have full access for their internal files.

    However, for work I have written a program (distributed to end-users) which watches a user-specified directory, and when the user creates a file of a few specific types in that directory (it reads the file contents to make sure it's a valid file of that type), pops up a dialog where the user can choose an action to do with that file. It does nothing else: the whole point of the program is to automatically react to a file being created by another program. It would be possible to contrive a complicated sandbox which could securely allow this kind of program, but it's simpler to just forbid it. So that program has to be outside a sandbox to be useful.

    It's true that most programs can be made to run in a sandbox and keep all or almost all of their useful functionality (for instance, a popular alternative office suite is being modified to be able to run on a popular operating system's "application store" sandbox, with minimal loss of functionality). But there's all the small oddball utilities, which do helpful things with interfaces which would be problematic if abused, that are lost when you sandbox everything, since a sandbox can't distinguish useful utilities from malicious utilities using the same interface.

  7. Cesar says:

    @Johan: a sandbox tied to an "application store" has yet another problem, unrelated to sandboxing itself: application stores have gatekeepers, which can and do impose arbitrary restrictions to programs distributed through it. Things like "your application cannot contain a user-accessible scripting language (unless it's this specific scripting language implementation provided by us)", "all depictions of human-looking characters must be fully clothed", or "each new version of your application will be delayed for an arbitrary time until one of our reviewers had time to look at it, even if it's fixing an urgent bug".

    Once you have a high-quality sandbox, a curated "application store" becomes less necessary for security, but an "application store" is useful for other things than security.

    It's better if programs distributed outside the "application store" can use the sandbox (for an extra measure of trust; it's a way to enforce "my program will do nothing unusual"), and at the same time programs distributed within the "application store" can be unsandboxed (with much more stringent review, for the few cases where a program needs to do things the sandbox would ordinarily forbid). That way, you can have the best of both worlds.

  8. skSdnW says:

    Some of the apps/installers that do this only look for the English menu text (perhaps they are using the IDispatch scriptable part of the shell that does not provide the true verb name?) and fails/crashes with other languages.

  9. Sven2 says:

    But when I installed my computer, both Internet Explorer and Windows Media Player were already pinned to the task bar. How did they pin themselves? If Microsoft offers the pinning API for them but not for others, doesn't that violate some court orders they got in the EU to treat all browsers and media players equally?

  10. Harry Johnston says:

    @Cesar: assuming you're building a new operating system, it shouldn't be necessary for the vendor to vet sandboxed software.  It also shouldn't be implausible to support most or all of the unconventional things a developer might legitimately want to do.  In the specific example you gave, one approach would be virtual directories, i.e., things that look like directories but are implemented by (third-party, sandboxed) software.  (There might be other problems that are harder to solve, perhaps impossible, but we won't really know until someone makes a serious effort to develop such an OS.)

    Backporting this sort of approach to an existing OS is harder, of course.  Windows could perhaps have avoided the need to vet sandboxed apps by implementing WinRT as a separate subsystem rather than as a layer on top of Win32, but I imagine that option was discarded as too expensive; it would have been a lot more work.

  11. William says:

    An interesting point, and one I've come across from both sides of the fence. Yes there's the infamous example of the program that bundles itself with every piece of stuff and forces its way onto your computer, that's bad.

    However, when you're in say a school environment and you want to mandate something like Word being pinned to everyone's taskbar, while it's possible to do it the dirty way, it just feels wrong. Personally I'd prefer it if there was an enterprisey way to achieve this with Group Policy Preferences or something, but then I guess you run the risk of other vendors hijacking the technique to force their junk on the user's taskbar. GPP would mean it can be changed at a whim, without having to rebuild user profiles.

    I don't know any solution to this problem, I'm just putting it out there.

  12. IanBoyd says:

    I knew that Microsoft had intentionally not provided an API to do pinning. Which is why i was surprised when i saw Contoso from Grobble managed to do it.

    After reading about the the intended use of *my* Desktop, *my* Quick Launch, *my* notification area, *my* Start Menu, *my* pinned items, i have become much more protective of *my* computer. And i'm now disgusted when i see applications vomiting things outside of their assigned places.

    Not knowing that you shouldn't add a desktop icon, quick launch icon, run on startup are concepts harder to find in MSDN. I appreciate the guidance to others that there are things you should not do.

  13. Cesar says:

    @William: to prevent vendors from hijacking group policies, make it so they are only obeyed if they come from the domain controller. The only way for a vendor to hijack it then would be to convince the sysadmin to run it directly on the domain controller; good luck with that.

    (And then the vendor hotpatches the Windows system DLLs to convince it that this particular group policy came from a domain controller, even when it didn't. You just can't win…)

  14. cheong00 says:

    @Sven2: These settings are just put into default user profile (think it is like the "model" database in SQL server), no API is needed.

  15. Ben says:

    I might be wrong, but I'm reasonably sure that the Store itself pinned itself to my taskbar after certain Windows updates.

    Is that a product decision? Is someone drunk on the MS campus for that very same reason? :)

  16. Christian says:

    The problem with appstore sandboxes is that they protect the operating system very well from advanced utilities, but do nothing to protect my privacy. Why have a sandbox that protects file managers from existing, but does not protect the address book, mails, SMS, location, IP, phone number or allow tracking? The most evil things are still allowed by sandboxes.

  17. Seb says:

    I think Kevin A is on the right track. I don't want my internet explorer to be able to access my openVPN private keys to be honest, and now it can by default. this to me is bad. It's not only about things attaching to the taskbar, but there's much more aggressive and perhaps even malicious behavior which could be blocked by designing something that can facilitate these kind of ownership/permission configurations.

  18. Darran Rowe says:


    What version of Windows are you using? With 8.1, the default user profile doesn't contain WMP, and with IE, it doesn't stop you unpinning it. Windows also doesn't stop you from reassigning the specific types and protocols to another application. Also, while you can't uninstall the backend components, Windows allows you to uninstall IE and WMP.

    So remember, there is a difference between being part of a default set of applications and treating something special.

  19. Vinicius says:

    Let's talk about one of the major examples, the Vanadium browser from Grobble (any similarity with browsers using chemical elements' names is unintentional). Do they have any incentive, interest or intent to make their product play by the rules, make Windows ecosystem a better place to live? IMHO, considering that they're basically competitors that was intentional (as other design choices in the product. See how they impact SO's power comsumption).

  20. Sven2 says:

    @Darran Rowe: Windows 7. But now that I think if it, it was what is preinstalled on the laptop so maybe it's just the default set the manufacturer chose.

    Btw, this reminds me: Why am I not able to drop .bat files onto the task bar? Or shortcuts to .log files I open often?

    For log files, I can only pin e.g. notepad, then right click it and select a commonly opened file.

  21. Joshua says:

    @Sven2: Try making .bat files in a utils directory, then normal shortcuts to them and pinning those. Should work just fine. If not, AutoHotkey pins just fine.

    [This is a slightly different case, because yours is a special-purpose program running on a dedicated computer. In that case, the computer isn't really the user's for customization. The computer belongs to the traffic control system. -Raymond]

    This brings up the question, opinion on "Shortcuts on [X] Start Menu [ ] Desktop [ ] Quick Launch" when various installers run (not ours)? (We know there's no API for quick launch. I checked with strings and I'm pretty sure it fails on non-English Windows. That's not the point.)

  22. Partner says:

    >>there is no Pin­To­Start­Menu function

    IStartMenuPinnedList interface…/bb774815%28v=vs.85%29.aspx

  23. Joshua says:

    @Partner: Had you read you would have found there is only one method — unpin.

  24. mh says:

    With windows 8.1 there are Group Policies available for deploying a custom Start Screen – see…/dn467928.aspx for example.  What's there right now is actually quite good, but it probably needs another revision or two before it becomes truly awesome.

    Say what you want about touch UI vs keyboard/mouse UI (and it would probably be righteously clobbered as off-topic), the Start Screen does make an *excellent* application launcher either way.

  25. @Ben says:

    Don't you know Microsoft bends its rules as they see fit? The Store is extremely awesome according to them.

  26. Marc K says:

    I'm now looking at implementing one of those discouraged methods for pinning applications to the Start menu and taskbar.  Not because we have a super awesome product or because I want a bonus, but because we'd like to dynamically customize the environment for our corporate computers and group policy does not provide any functionality for pinning.  (Assigning desktop icons to users is so 2005.)

  27. Entegy says:

    There's a VBScript apparently written by Microsoft that will pin shortcuts to a taskbar. We deploy it via Group Policy and use that to keep corporate apps on the taskbar.

Comments are closed.

Skip to main content