Don’t use global state to manage a local problem

We've seen a few instances where people have used a global setting to solve a local problem. For example, people who use the LockWindowUpdate function to prevent a window from redrawing, toggle a global setting to see what its value is, or who change the system time zone as part of an internal calculation. To this, I'll add as an example a program which figures that if you don't want the program's feature, you don't want that feature in any competing products either.

The first service pack of Windows XP introduced the Set Program Access and Defaults control panel. Among other things, media players can register here to allow users to choose them as the default media player, to enable access to the media player, or to remove access. The guidelines for the use of this control panel recommend that in response to the Remove access command, media players should remove their user interface entry points (such as shortcuts on the Start menu and notification icons), disable their autoplay feature, and generally act as if they weren't there.

One media player decided that if the user instructed it to remove its access points and disable its autoplay, it would dutifully remove its user interface entry points, and it would also go into the configuration manager and disable media insertion detection on the CD drive. "If you don't want me to autoplay your CDs, then fine, and I'll make sure nobody else can autoplay your CDs either." They also disabled autorun, a related but separate feature.

This program addresses a local problem (disable autoplay for Program X) by applying a global solution (disable all media insertion detection). Whether media insertion detection is enabled or disabled, and which programs should be notified when it occurs, is the decision of the computer user. Programs should not be altering hardware configuration unless the user specifically requested it. The correct thing for Program X to do is to remove its autoplay registration, leaving intact the behavior of other programs.

It turns out that Program X was not disabling media insertion detection out of spite. The people responsible for Program X simply followed the description literally without understanding the big picture. "The documentation says that we should disable our autoplay feature. Well, I guess if we disable media insertion detection, that'll disable our autoplay feature."

I wonder if their uninstaller reformats the hard drive.

Moral of the story: Don't use global state to manage a local problem.

Comments (36)
  1. ton says:

    Unfortunately but true there are some who shouldn’t be allowed to use computers much less program them.

    The number one question for these boneheads: Did you really test this on your own machine? In most cases the answer is no.

  2. ShimCity says:

    Reading the post regarding the change of system time (and forgive me if it’s inappropriate to post here as it was nothing to do with you), it seems that the shim put in place is just asking for trouble…

    One app hangs because it enters an infinite loop by firing an event in the handler for that event and the solution is to not fire the event for any app? What about my shiny new app that depends on this event firing when I update the TimeZone? Where is this documented?

    I know the app compatibility issue is a thorny one but hacks like this do seem extreme.

  3. ShimCity: The way I understood it they didn’t do it globally but used application compatibility functionality "which provides a way to implement per-application compatibility workarounds without polluting the core Windows code base", so the workaround is only in effect for that specific application.

  4. ShimCity says:

    Oops… yeah, I missed the per-application bit. Ok, that makes more sense.

    Don’t mind me, carry on.

  5. pablo says:

    It should be SOP that Windows Error Reporting sends an email to the app developers with a link to this blog when it detects a crash that is linked to evil programming practices.

    "Check for Problems & Solutions"

    "Send snarky email to App developers"

    "Stab developer in the eye"


  6. Duran says:

    Does UAC make this better?  Like, if the program tried to modify global hardware settings, the user would at least get a prompt?

    [Has no effect. You already said, “Let this application make global configuration changes” when you approved letting the uninstaller run. -Raymond]
  7. Mihai says:

    It is also very important that the desired task can be accomplished without changing any global setting.

    Example: formatting a date using an alternate calendar. See

  8. Dan says:

    Forgive me if this isn’t 100% accurate, I haven’t run Vista in awhile (my only computer is too slow for my favorite games on XP, never mind my favorite games on Vista) but I did a bit of research at one point in trying to make my own apps UAC-aware.

    Programs have to be UAC aware to trigger UAC prompts.  If not, the operations they are trying will simply fail as they would on a pre-Vista Limited User account.

    Unless you launch them as administrator, then they would have full access a la pre-Vista Administrator account.

    UAC is a tool meant for use in new, Limited-User-aware Vista programs.  Older programs can’t take advantage of it… although Vista will try to detect programs that are trying to use Administrator-only functionality and that are crashing or failing because of it and will offer to reexecute them elevated for you.

  9. Angry coward says:

    Actually UAC doesn’t solve any “problem” at all. If anything, things are worse than they were in XP, since you have less control over what programs can do (for example, installers can and will force you to run them as admin).

    UAC alleviates the problem of “a running app got compromised over the network”, but it’s a tossup anyway since if the limited user space is compromised it’s very easy to trick the user into elevating the malware (for example next time he requests something that does require elevation – and no, code singing won’t help you there, since “regedit /S evil.reg” displays the very same UAC prompt as just “regedit”, unless you click on “details”, and even doing that isn’t 100% safe). Low integrity processes (ala iexplore or chrome) are the right answer to this.

    The whole UAC thing is pretty much useless if you end up having to run each vendor’s installer as admin. It’s game over by then: they’ll litter the system folders, the registry, many will even install their own system service because they have some stuff that has to run elevated (and you can hope the service is secure from elevation attacks, which 99% of the times it won’t be because nobody is going to complain…)

    It’s a mess, still a mess, and will forever be a mess. You could have some kind of “managed” installer which restricts what installations can do, and as a incentive you could make its UAC prompt less menacing and annoying, but most of the big vendors would probably ignore it anyway. Sigh.

    [I admire how virtually any topic can be turned into a rant about UAC. -Raymond]
  10. Kaenneth says:

    "I wonder if their uninstaller reformats the hard drive."

    That’s virtually been done before…

    There was a game that shipped with an uninstall bug that could obliterate your OS install.

  11. Nathan Mates says:

    I play a bunch of games, but usually prefer to replace the soundtrack with my own music, played thru Winamp in the background. (Others may prefer their own music players.)

    I tried this with Game X, the original game (though w/ the expansion packs installed.) My wife didn’t like the sound effects– mainly the sound effect from Game X— and asked me to turn that down. So, I clicked on the icon to turn off sound.

    Given that I’m posting on this thread, you should be able to guess what happened. Game X turned the global volume setting to 0, killing the game’s sound efx. And my music. Not cool.

  12. Of course, you *could* make the case that the OS shouldn’t make it so easy to change global state in the first place…

    How many programs outside of the control panel really should be allowed to change system wide settings?

    (Yes, I understand the reasons why it is like it is, history and all – but this is the result of that status.)

    [You’re saying that, for example, no program should be allowed to change the time? What if you’re writing a program whose job is to synchronize the time with another source? -Raymond]
  13. Ian says:

    As a couple of people have already commented, there do seem to be a few instances in Windows where a global setting is the only way to achieve the desired end.

    I agnoised over such a problem recently. The bug report said that my application’s save dialog was overwriting files with a different extension. This has been discussed here before – it’s the in-line autocompletion feature of Explorer that is to blame (along with inattention of the user and the user not understanding that a setting in Windows Internet Settings affects my application’s save dialog).

    It is obnoxious for an application to change a global setting, but this seemed to be the only way to solve the problem.

    In the end, we modified our application to read the value of HKCUSoftwareMicrosoftWindowsCurrentVersionExplorerAutoCompleteAppend Completion and then to set it to ‘no’ immediately before showing the Save dialog, and then to restore the original value immediately after.

    It isn’t perfect – if someone leaves our save dialog up and meanwhile chooses Save in another application then they get our application’s temporary setting.

    Of course the best way to solve this problem is to educate the user, but that is easier said than done.

    Does anyone have any better ideas?

    [Um, register your own (null) autocomplete on the edit control. -Raymond]
  14. Ben Cooke says:

    A related problem is when API/Library/Application developers design the system in such a way that you *need* to use a global setting to achieve a particular result.

    (This wasn’t the cause in this case, of course. But a number of times I’ve found myself using hacks with locking and such to work around functions that use global variables for things that ought to have been arguments without breaking other callers that might depend on the setting being different. It’s one of those things that comes up with enough frequency to make me hate my job sometimes.)

  15. Dog says:

    Of course third parties aren’t the only applications that take that particular setting too far…

    If you "deny access" to Windows Media Center (at least on Vista), then it absolutely refuses to run, displaying a cryptic error message instead.

    When I said "deny access" I meant, "don’t use this application to open any documents or autoplay anything ever", not "don’t let me run this program even if I specifically ask for it".

    So I either have to put up with Media Center being offered as an option for opening any vaguely media-related file, or have no access to it at all.

  16. pingpong says:

    @Ian: so the inline autoocompletion works OK for this user in other apps, or your program is the only one [s]he is saving files from?

  17. Igor Levicki says:

    >The guidelines for the use of this control panel recommend that in response to the Remove access command, media players should remove their user interface entry points (such as shortcuts on the Start menu and notification icons), disable their autoplay feature, and generally act as if they weren’t there.<<

    Great to know the rule which WMP11 in Vista ignores and continues launching and hijacking media file types.

    I just had to delete some of its keys from registry to keep WMP11 from starting when I select Open With…->VLC Media Player from a video file context menu.

  18. Ian says:

    @pingpong: Whether or not inline autocompletion causes problems for other applications, it is not a good enough reason for my application to hijack a global setting. I think this was the point of the original article.

    As it happens, my application is more prone to this kind of problem than most because users tend to create several files with the same basename but a different extension.

  19. Personally, I think this part of the Control Panel is one of the more useless parts of Windows.

    It allows you to disable access, but doesn’t uninstall the applications – why would I want to do that? The sensible option – uninstall – is available elsewhere.

    And that applies to all the options there: they are all configurable elsewhere. Add to that that most programs don’t notify this part of the Control Panel that they’re installed and that in fact the Control Panel itself only works in a half-hearted sort of way, and the result isn’t much use. What for example happens if I switch from ‘Keep my current …’ to whatever is my current … ? Maybe nothing happens, but there’s no way to be certain, no way to ask the applet how the current is different.

    I think the applet is there solely for legal reasons. I wish I could remove it.

    [“Keep my current” = “Make no changes”; this is not the same as picking a new one if you have mixed ownership (e.g. Program A owns mp3 but Program B owns avi). There is a system policy for hiding the control panel if it so offends you. -Raymond]
  20. Alexandre Grigoriev says:

    That “program access and defaults” is half-baked stuff. Why can’t I have different defaults for different users on my computer? Why an user can’t set his/her own preference?

    [Then you’d have “I told Program X to be the default .xyz file handler, but it still opens in Program Y!” Because Program Y registered a per-user .xyz handler, and Program X was written in 2000 and doesn’t understand per-user handlers. -Raymond]

    Not to mention that every little update for MS Office considers that it’s necessary to reset the email default back to Outlook.

  21. Alexandre Grigoriev says:

    [I admire how virtually any topic can be turned into a rant about UAC. -Raymond]

    Because UAC deserves bashing. Just like you-know-which email program which is not actually email, but a database, whose every mention evokes a barrage of “sucks”. If the developers haven’t lived in ivory towers with unlimited memory, super-fast multi-proc PCs, bulletproof network isolation from the outside world, maybe they would make Windows and other apps a bit more suited to the real user needs? Then maybe this new Windows Search 4 would not cause my machine to slow down to a crawl? Maybe Windows Search 4 would actually search files instead of putting an excuse that “the folder is not indexed yet”?

    [I also admire how the topic of UAC can be injected into any topic without regard for relevance. I’m surprised you haven’t ranted about UAC in my blog entry about Dance Your PhD. -Raymond]
  22. Anonymous Coward says:

    Thanks, Raymond, will do. It’s hard to explain why it bothers me that it’s there, but I guess it’s like an itch. I take it this is the way:

    @dave: Not necessarily. You could use something similar that’s used for handles now. Programs can pass handles around, but they don’t leak beyond where programs actively leak them, so to speak. Then you could say for example: okay, the shell has handles (directly or indirectly) to everything the user is allowed to touch, but doens’t pass them on unless asked in some way or another. It would require a major re-think on how software works, but the result would be safe and intuitive, I think. (Note: I don’t claim this idea is original, I just can’t remember where I picked it up.)

  23. Another possibility is that their users kept calling them to ask why CDs kept autoplaying after they had turned autoplay off in Program X.

  24. You know, if you’re going to reply inline, threaded comments would be nice ;)

    Either way: Yes, I think no program that does not have explicit permission should allow to touch global settings.

    The vast majority of programs don’t need to. (How many time syncing apps have you written lately?)

    Anything that affects global state (or even state with a wider scope than just my application) should require special permissions. Might be that’s just my Unix upbringing talking, but that’s the way I like things.

  25. dave says:

    >Of course, you *could* make the case that

    >the OS shouldn’t make it so easy to change

    >global state in the first place…

    This is the first step on the path of ‘there is an API but only one program is allowed to use the API’.

    It’s rarely a good idea.

    Usually people describe this as letting the user do something but prohibit programs from doing the same thing. The trouble is, of course, that users don’t actually twiddle bits on disk, you need programs for that.

    I guess you could have an undocumented API, but these days you tend to end up in court when you do that.

  26. SuperKoko says:

    @Robert ‘Groby’ Blum:

    I like when people ask for features that Windows already provide.

    To modify the time zone, you need SE_TIME_ZONE_NAME privileges, which are typically provided for administrator users only.

    The Windows NT access control model is fine grained and more subtle than the typical POSIX model.

    The fact that tons of cr*ppy applications require admin privileges on Windows XP is a real problem that Windows Vista tries very hard (at the cost of backward compatibility) to solve.

  27. Yuhong Bao says:

    Another example:

    Example deleted because it violates the ground rules against identifying a specific company, program, or person. This commenter, despite his/her enthusiasm, tends to violate the ground rules and eventually I will tire of editing the comments and start deleting them.

  28. Anonymous Coward says:

    That is certainly true and it deserves more credit for that than it gets.

    However, the shell automatically passes the privilege on to the applications it spawns, which is bad. I want to be able to change the time zone, sure. But only the time and date applet should be able to do this on my behalf, so the shell should only pass the privilege on to that applet, and perhaps others that I explicitly specify.

    Also, the access control model is certainly a big improvement over POSIX, but it still leaves a lot to be desired, especially in terms of consistency and default configuration. Some things are controlled by privileges, as the time zone. Other things are controlled by passing handles around (or failing to do so). Yet other things are accessed by pathname which are then on access checked against ACLs which operate by user and group, not by application.  The default settings are almost all too permissive.

    I think the handle model is the easiest to work with and reason about, as well as the most flexible and the easiest to get watertight, so if we, theoretically speaking, were to adopt one of these models, I’d opt for that one. It also has the nice property that it would be easy (relatively speaking) to add the necessary infrastructure to make it emulate the other two if necessary.

  29. SuperKoko says:

    @Anonymous Coward:

    A per-application (application being defined by an exe path name + SHA1) access control model would be nice. That would be a generalization of network firewalls to system calls & all other privileges.

    However it wouldn’t solve the issue of trusted applications changing the global state as part of their internal calculation:

    Either applications, when installed, declare the privileges they need, in which case, the application would declare that it sets the time zone, or the user would have to configure that for every application, getting pop-ups they don’t understand as UAC does. Even if they manage to understand the pop-up, they’ll first click "No" and see that the application doesn’t work, so they’ll eventually give the privilege the application asks.

    Access control can protect against worms & trojans, but cannot automagically repair broken applications. Broken applications are broken. Only their developers, or Windows hacks as we see on The old new thing, can fix them.

    Anyway, I don’t see how the handle model can be used to implement per-application access control. Either the explorer would pass all the handles to every child process it invokes or it would use an application table to select which handles it must passes to child processes. The latter would be very weak as there’re many ways to launch applications without explorer, and every application allowing people to launch other applications would’ve to use these "firewall tables".

    The per-application model used by network firewall is much better IMO.

    There’s also the argument of backward compatibility. Handles based access control would significantly change the Windows API.

  30. Anonymous Coward says:

    @Broken applications are broken. Only their developers, or Windows hacks as we see on The old new thing, can fix them.: True, but if broken means that your application doesn’t even work in testing, hopefully devs will have some incentive to fix a bug before shipping.

    @getting pop-ups they don’t understand: Then make them get pop-ups they do understand. Frankly I don’t get what people hate about UAC. The only thing I kind of don’t like is how the pop up is too generic. The most central item in a good dialog would be what the application is actually trying to do.

    (And to add to the above two paragraphs: there are lots of things for which it doesn’t make sense to be able to ask the operating system for a privilege. The time zone only needs to be set by the time date applet, which is started by the shell, which will pass the handle on because it knows it’s starting the time date applet, or computer setup programs and administration tools, to which you could pass the handle on startup similarly to how we pass command line parameters now. Regardless, either you can change the time zone, or you can’t. No way to ask = no pop up.)

    [Q: “I need to change the time programmatically in order to perform this internal computation.” A: “Mark yourself as an administrative tool, then you will have permission to change the time.” Now you’re back where you started. Or worse, A: “Inject a thread into Explorer to change the time.” Now you have a problem worse than the original problem. -Raymond]

    @Anyway, … tables”.: Logical fallacy: false dichotomy. There could be other ways to pass to handles to programs, and if you design the system right, I think that you could get most applications working just right without requiring the user or shell to do anything specific. For example, if you open a document from an Explorer window, Explorer could pass a handle to that document to the application it starts, much like we pass filenames today. A common dialog could do the same kind of thing.

    Pure per-application instead of per process has a major deficiency, in that it would be hard to give different instances different access (which you might want sometimes) and to pass handles to running processes. It could be done, but it would be harder and less intuitive.

    Backward compatibility could be done using an emulation layer. It would for example interpret a CreateFile( <path> ) as ‘look if there’s a handle open in this process that corresponds to path’. It can be done, and it probably wouldn’t even be that difficult. You could even pass a handle to a folder to make all files in it accessible.

  31. Yuhong Bao says:

    “Example deleted because it violates the ground rules against identifying a specific company, program, or person. This commenter, despite his/her enthusiasm, tends to violate the ground rules and eventually I will tire of editing the comments and start deleting them.”

    Well, good thing that there is off-roading the old new thing. BTW, it don’t seem to be very active. Raymond: Do you read off-road? Because you don’t seem to post in it.

    [I read it but I don’t post to it because I post here. And thanks for taking this thread even further off topic. -Raymond]
  32. Yuhong Bao says:

    [I read it but I don’t post to it because I post here. And thanks for taking this thread even further off topic. -Raymond]

    Thanks for confirming, because it is hard to tell if you don’t post there.

  33. Anonymous Coward says:

    @Mark yourself as an administrative tool, then you will have permission to change the time.: I didn’t say that and I wouldn’t be in favour of that.

    @Thread injection: that opens up a whole ‘nother can o’ worms, but I think that would take this thread too far off topic.

  34. Giuseppe says:

    (back to the topic?)

    Sometimes it is difficult for the developer to follow the rule. I have seen many (most of) compression/archieving tools that become "the" global compression/archieving tool (and when one tries to uninstall them, the registry is often messed up, and the native "compressed folder" feature is lost; but this is a bug, of course). The problem is that their GUI are very different. I actually don’t know if registering the new application is  always a good thing. In my little experience, it is often a source of problems. But I also understand the "marketing": if you sell a "good archiver", you "want" to throw the native one away, right?

  35. Anonymous Coward says:

    @SuperKoko: your post is too incoherent to be really sure, but I think I have already answered most of your questions in previous posts.

  36. SuperKoko says:

    > @Mark yourself as an administrative tool, then you

    > will have permission to change the time.: I didn’t

    > say that and I wouldn’t be in favour of that.

    So, how do you let the third-party administrative tool X which does modify a system setting for a good reason, do it.

    Somehow, it has to declare it, which you don’t wish, or the user has to get a pop-up.

    "Frankly I don’t get what people hate about UAC."

    UAC is russian roulette.

    Assuming there are two kinds of applications:

    1) Normal trustable applications. Sometimes, they need high privileges to do their tasks.

    e.g. Network clock synchronization requires privileges to set the clock.

    Or, a network tool to change the time zone on a whole LAN at a time, require privileges to set the time zone.

    2) Worms, malwares, viri…

    For applications of kind #1, the "right" answer to UAC is always YES. Clicking NO will (almost) always result in malfunction of the software.

    For applications of kind #2, the "right" answer is always NO. This might not always totally stop the malware, but, clicking YES will only makes things worse.

    In BOTH cases, a message box convincing the user to click YES can trivially be written. I would even say that it’s easier for malwares as they are "free" to tell lie.

    So, the message box can be ignore, and the UAC question always comes down to:


    Hi, I’m Windows. I’m going to do perform dangerous operation, but I don’t know if the program asking for it is evil or not, so, could you tell me:

    Are you executing a malware?


    When computers have no clue what they’re doing, desperate, they ask the user.

    (I don’t know details, but UAC might also be a problem when managing hundred computers on a LAN and not wanting to click YES hundred times).

    Now, we see that there’s a third kind of application.

    3) Trusted non-malware applications, badly programmed, which modify a global setting to perform an internal calculation.

    However, the answer to the UAC should be YES there too, as the application won’t work at all if NO is answered, and, surely, the user wants the application to work. So, from a security & user point-of-view kind #3 and kind #1 are the same.

    If the declarative model is used, applications of kind #1 and #3 will properly declare that they need these privileges, while, worms will be blocked unless they manage to execute with "installer" privileges (the privileges needed to declare privileges of applications).

    This model doesn’t help bad developers to fix applications of kind #3.

    If the "pop-up" model is used, applications of kind #1 will pop out dialog boxes as part of their normal behavior, and that won’t be a bug.

    Applications of kind #3 will do the same, and these "pop-ups" won’t be reported as bugs during testing.

    This model doesn’t help bad developers to fix applications of kind #3.

    However, this model helps worms to propagate, compared to the other model.

    Proper education of *developers* is the only way to fix applications of kind #3.

    "There could be other ways to pass to handles to programs"

    Which one?

    "A common dialog could do the same kind of thing."


    So, a network clock synchronization tool would’ve to pop up the system clock? Looks weird to me.

    What dialog would you show when modifying some obscure registry setting such as obcaseinsensitive, or the user profile folder path?

    Would the admin have to close this dialog box on the hundred computers of his LAN?

    Give a concrete proposal, with an API and a description of some applications, and I’ll read it, but you’re being vague enough to make it hard to understand what you’re thinking.

Comments are closed.