The Resourcefulness of Annoying People
Windows isn’t as open as it used to be. In the earlier, simpler days, Windows® was designed in a more trusting manner. Internal file formats were documented, and programs could manipulate the system in a wide variety of ways. The assumption was that software developers would exercise this power responsibly and for the benefit of the user. After all, if a program abused its users, so the logic went, the company would quickly lose all of its customers. Developers, therefore, had an incentive to treat the user with respect. That was then.
The software has changed since those simpler days. There are parts of the Windows user interface that cannot be controlled programmatically—not even by policy. It’s sad but true. And it’s a lesson that was learned the hard way.
In Windows 95 we gave programmatic access to the Start menu "Fast items" list, the items that appear at the top of the Start menu above the Programs list. This area was intended for the user to customize with their favorite links. But programs quickly saw the opportunity and added themselves to it every chance they got. In Internet Explorer, we gave programmatic access to the Favorites menu and, once again, third-party programs added themselves to this menu at every opportunity.
In Windows XP, we finally learned our lesson and intentionally did not give programmatic access to the pin list, the bold list of items at the top of the Start menu. The pin list is a customizable list that gives users quick access to their favorite programs. The key here is that users decide what they want quick access to. If programs were given access to this area, far too many would decide unilaterally that they are so important that they must place themselves at the top of your Start menu without asking for user input. The pin list would quickly become meaningless.
The CD and DVD autoplay feature also adapted to the new reality. When developers included the ability to customize the autoplay feature in Windows XP, they were well aware that programs would act selfishly and attempt to set themselves as the default handler without necessarily obtaining permission from the user. Consequently, there was a conscious decision not to allow the default handler to be set programmatically. Instead, the only way to do it was to go through the settings provided in the properties of the storage device.
One cannot, however, underestimate the resourcefulness of people trying to be annoying. For example, it didn’t take very long for unscrupulous programmers to figure out where the settings were kept and to manipulate them directly. As an additional defensive measure, Windows XP SP2 introduced new behavior related to autoplay: when Windows XP sees that a new autoplay handler is available, it shows you the autoplay dialog one more time. This gives you a chance to deselect the program you just installed, if it was rude enough to set itself as the default player without checking with you first.
Furthermore, Windows XP SP2 took the battle a step further and changed the way it records the user’s autoplay preferences, in the hopes of foiling any programs that try to hack the settings. This was just another stopgap measure, of course, because we all know that security by obscurity is not really security at all. It’s merely a temporary obstacle. But the hope was that by making the autoplay settings a moving target, Windows XP would send a clear message to these programs that their manipulation of these settings is not welcome.
There are other examples of things for which Microsoft included no programmatic control out of fear that the power would be used for evil. For instance, there is no interface for manipulating the taskbar icons of another program, or for adding or removing a band in the taskbar. Imagine the havoc that would ensue if any random program were allowed to manipulate these highly sensitive components of the UI.
Unfortunately, protecting the user has negative consequences for system policies. Each system policy that controls these features becomes an attractive target for unscrupulous programs. Your typical home user does not have a domain. Without a domain policy to override local machine policy, a malicious program can set a local machine policy that promotes the program.
We’re sorry it turned out this way, but Windows must be even more guarded than ever when it comes to exposing access to highly visible elements of the UI. In the new software landscape, programs will take every opportunity to be annoying.
Raymond Chen most recently presented “Five Things Every Win32 Developer Should Know” at the 2005 PDC. His Web site blogs.msdn.com/oldnewthing deals with Windows history and being attacked by sidewalks.
© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited