Larry Osterman's WebLog

Confessions of an Old Fogey
Blog - Title

So why are applets so bad, anyway?

So why are applets so bad, anyway?

  • Comments 29

There's a simple answer to that question.  As I mentioned in the first post in this series, "It's my machine dagnabbit".  The simple answer is that applets consume resources that can be better used by by the customer.

At an absolute minimum, each applet process consumes a process (no duh - that was a stupid statement, Larry).  But you need to realize that each process on Windows consumes a significant amount of system resources - you can see this in Vista's taskmgr.

There are three columns that are interesting:  Working Set, Commit Size and Memory.  Commit Size is the amount of memory reserved for the process (so can be insanely large , Working Set  is the amount of physical memory that the process is currently consuming, and Memory is the amount of working set that's not being used by DLLs.

On my machine, to pick on two applets that I have running, you find:

  • FlashUtil9d.exe consuming 4.5M of working set, 1.3M of commitment and 760K of Memory
  • FwcMgmt.exe (the ISA firewall client) consuming 4M of working set, 1.6M of commitment and 300K of Memory

That 700K is real, physical RAM that's being actively used by the process (otherwise it would have been swapped out).  With multiple applets running, it adds up FAST.  On todays big machines, this isn't a big deal, but on a machine with less memory, it can be crippling.


In my last post, I categorized applets into 4 categories (updaters, tray notification handlers, helper applications and services).  In addition to the common issues mentioned above, each of these has its own special set of issues associated with it.

Updaters often to run all the time, even though they're only actually doing work once a day (or once a month).  That means that they consume resources all the time that they're active.  Adding insult to injury, on my machine at home, I have an updater that is manifested to require elevation (which means I get the "your app requires elevation" popup whenever it tries to run). 

Tray notification handlers also run all the time, and adding insult to injury, they clutter up the notification area.  The more items in the notification area, the less useful it is.  This is actually the primary justification for the "big 4" notification area items in Vista - people kept on finding that the 3rd party notification area icons crowded out functionality they wanted to access.  In addition, notification handlers seem to love popping up toast on the desktop, which often interrupts the user.  In addition, since tray handlers often run synchronously at startup, they delay system boot time.

Helper applications don't have any specific issues, from what I've seen.  They just consume resources when they're running.

Services are both good and bad.  Each Windows service has a start type which lets the system know what to do with the service on startup.  There are 3 relevant start types for most services: AutoStart, DemandStart and Disabled.  When a service is marked as AutoStart, it starts on every boot of the system, which degrades the system startup time.  In addition, because services often run in highly privileged accounts, the author of the service needs to take a great deal of care to ensure that they don't introduce security holes into the system.  Before Vista, high privileged services were notorious for popping up UI on the user's desktop, a practice so dangerous, it justified its own category of security threat ("shatter attacks").  In Vista, changes were made to eliminate classic shatter attacks for all subsequent versions of the OS, so fortunately this issue isn't as grave as it was in the past.



Tomorrow:  So how do you mitigate the damage that applets can cause?

  • I don't agree that private working set is a very good estimation on impact. Even if a service only has a 2MB working set of a 30MB heap, it still had to have allocated and initialized that 30MB somehow, probably off disk, which costs time on startup. It then costs time again when it needs to access that memory at some point during execution and finally again to free it on shutdown. You're still paying a cost for all of those pages.

    That's precisely why I hate craplets like the ATI Control Panel -- sure, it has a working set significantly smaller than its allocated size, at some point it wakes up, such as when you click on it, and then it takes forever thrashing the disk while it swaps pages in its heap back into memory. It's worse with .NET apps that suddenly decide to do a full garbage collection and need EVERY page swapped back in. You might as well go to lunch at that point because the swap traffic kills system responsiveness.

  • "That 700K is real, physical RAM"

    Obviously I can't add up today, where does that 700K number come from?

  • Norman: You're right, I do want the firewall client.  I never said it was "so bad", it happened to be an applet on my machineat work.

    Phaeron: You're right, but private working set works quite nicely as a measure of the spot impact of a process.  It doesn't tell you history, but it does tell you how bad it is right now.

  • Paul: The 700K comes from rounding 760K down.

  • One of the other worse ones I've seen are included with HP all-in-one printers. They install a number of always-run programs and a couple of them are well known for hanging the system when you try to shut down.

    I've gotten a real education on Services reading your posts. I monitor some of the less understood startup vectors and it amazes me how may legit vendors sneak things in.

    For instance, on a brand new Dell laptop I was preparing for my daughter I found that it included an AOL file called "GW SEH Intercept" located in


    This was a clean OEM machine and AOL wasn't even in installed yet!  I'm told SEH stands for Structured encryption handling.

    Thanks again,


  • "If Vista had up/down scripts like linux, then I could just hook into those, but no hooks means one more craplet."

    Norman, check into the new Vista Task Scheduler, they finally got this right. Create a new task and select the trigger "On an event." Then select the network event you want to trigger the action. You can undoubtedly find a suitable event number by searching the event logs.

    I know that Microsoft has no interest in back-porting this to XP, but if nobody does then it will be several years before these kind of Vista features are exploited. Most app developers would prefer to avoid multiple code paths and as long as the XP-crapplet way works on Vista it will be predominant for a long time to come.

  • Bill, I think I mentioned the HP 7400 printer in one of these posts.

    I hate that stupid piece of junk - it's a nice printer, but the crap that came with their driver annoys the heck out of me.

  • Dave: Wow, I had absolutely no idea that this had been added in Vista - It works like a charm!

  • Larry:... but private working set works quite nicely as a measure of the spot impact of a process.  It doesn't tell you history, but it does tell you how bad it is right now.

    I think this isn't exact enough. You have to add also the shared pages with a refcount of one, to make a fair process comparison.

    These pages are often surprisingly huge.

  • edgar: that's essentially what Pavel mentioned above.  You're right, but it's not easy to calculate that number in a non-intrusive manner.

  • Larry: that's essentially what Pavel mentioned above.  You're right, but it's not easy to calculate that number in a non-intrusive manner.

    Sorry Pavel, I haven't read your entry. Larry’s blogs are so long. ;)

    - But it is easy and not that much much time-consuming. It is of course always a snapshot, but it's closer to the truth. Therefore it is a better system overview. We are talking about unnecessary resource overhead, not specific asynchronous test scenarios.

  • The shatter attack is the stupidest thing I have ever seen. It's too bad how much people care about backwards compatibility over security.

    Oh, right, crapplets. Do you think it would be possible to alter the registry to pop up a dialog saying "Crapplet.exe is trying to add itself to your autostart programs/services. Do you want to allow this?" every time some piece of filth tries to install one?

    Obviously it won't help OEM machines, but it still would be nice when it comes time to get a new printer ;)

  • > pop up a dialog saying "Crapplet.exe is trying to add itself to

    > your autostart programs/services. Do you want to allow this?"

    > [...] would be nice when it comes time to get a new printer ;)

    OK, users never read dialogs, but let's imagine someone reads this one when they install their new printer.  Now let's figure out the answer.  Start with the dialog buttons.

    [Yes] [No] [I don't know.  I want to answer No, but if I answer No then will I be able to print?]

    Click the obvious button.  Here comes the next dialog that no one will ever read.

    "Windows needs an internet connection in order to find out where crapplet.exe came from.  Please connect, elevate to administrator privileges, and install this ActiveX control."

    [Back] [Next] [Cancel]

    Then if crapplet.exe came from Microsoft,

    "Please visit the support page on Microsoft's web site and find out how you can pay a fee to ask your question"

    [Back] [Finish] [Cancel]

    or if it came from another company,

    "crapplet.exe came from company x so please visit company x's web site to find that there's no answer to your question"

    [Back] [Finish] [Cancel]

  • In previous articles, I've pointed out: Programmer Hubris - He's just not that into you Programmer

Page 2 of 2 (29 items) 12