Applet Best Practices

The first and most important thing that a person considering writing applet needs to do is to stop and consider if they really do need to write that applet.

The answer may very well be "yes", but far more often, the real answer is "no".

Once you've decided that you have no choice but to write the applet, you can still make sure that your applet doesn't interfere with the experience of your customer by following some relatively straightforward "best practices" (there may be others beyond these, but this list functions as a good start).


  1. Make sure that your customer has the ability to disable your functionality.  If your applet is a service or a scheduled task, the operating system provides a mechanism to let the disable your applet, otherwise you should provide that functionality.  And make sure that you really do disable your task when the user disables your notification handler - don't just ask the user to hide your notification area icon.
  2. Reduce the number of processes you run.  Combine functionality as often as possible.  Reduce the stack size for the threads in your processes to the absolute minimum.
  3. Windows is a multi-user system.  That means that it's entirely likely that your applet is going to be run from multiple accounts at the same time - on the machine in our kitchen, there are regularly 4 users logged on at once.
  4. Windows is a multi-user system.  That means that you never ever want to launch UI from a service - it only works for the first user logged on (and it doesn't work at all on Vista).  Instead, use COM to launch your application as the foreground user, or use the task scheduler to launch your application as the foreground user (or have an applet which communicates with your service).
  5. If your application has the ability to auto-update (which is a good thing, IMHO), try to avoid running the updater all the time.  Instead bundle the updater with your application, or if that's not possible, use the task scheduler to run your updater once a month (or once a week, or whatever - pick your frequency).  On the same note, let your customer pick the time of day your updater wakes up, and give the customer the choice of whether your updater pre-downloads the update or if you only dowload after the user requests it.
  6. When retrieving data from the internet, use BITS to retrieve the data - that way your traffic doesn't interfere with the user's traffic.  This is true for all applets, not just updaters.
  7. If you're running on Vista, use Vista's priority scheduling mechanism to reduce the priority of your threads - that way your processing doesn't interfere with the user.  This is especially true for search helper applications - they have the ability to seriously impact the user when they run.
  8. Notification area handlers should disappear unless they have something to tell the user.  So it's ok for taskmgr to show a CPU graph, or for the clock to show the time, but if your notification area icon is static, why show it (of course, the caveat is that sometimes people want you to show your icon)?
  9. If your applet is a service, use a delayed auto-start service so you don't slow down the boot process by running your code.

Anyway, that's a start to the list, there may be more that I've missed, so I may update this list as I (or you) come up with others.

Tomorrow: How do I personally feel about craplets?

Comments (8)
  1. Anonymous says:

    > you never ever want to launch UI from a service […]

    > Instead, use COM to launch your application as the foreground

    Hmmmmm.  I’ve read a lot about using CreateProcessAsUser to do it, but I could only get it working in Vista.  On XP, the exact same sequence of calls leading up to CreateProcessAsUser all succeeded and only CPAS itself failed.  Added some calls which others had suggested in various web sites and fora and newsgroup postings, and they all worked, only CPAS itself still failed.  But CPAS itself still succeeds in Vista.  Weird.  So now I should learn how to use COM to try it?

    > or use the task scheduler to launch your application as the

    > foreground user

    (Or use task scheduler to let the foreground user run as Local System, oops.)

    > or have an applet

    Or have a WHAT?  In this series of postings, an applet hater is recommending WHAT?

  2. I’d also add:

    – Support proxies.  Either use the IE proxy settings or allow the user to set their own.  If you create your own, you must support authenticated proxies, including NTLM based ones.

    This *constantly* bites us my job.

    Your suggestion on BITS is great, but you should not rely on it.  BITS doesn’t work w/in our NTLM authenciated proxy.  BITS runs under local system, and I don’t think ProxyCFG can accept a username password.

  3. Anonymous says:

    Great series of articles!

    On my ThinkPad running Windows XP the default installation with all Lenovo tools consumes ~450MB RAM right after booting (incredible, isn’t it?). By carefully weeding out unnecessary stuff I was able to drop that number to ~230MB.

  4. Anonymous says:

    The worst craplet of all time is the Automatic Updates "restart your computer" popup.  I guess maybe it’s not that bad; you can disable it by killing the Automatic Updates service.  But it pops up every 2 minutes AND steals focus.  It’s just a matter of time before you’re typing a document and hit [Enter] at a most inoportune time.

  5. John: As far as I know, the automatic updates popup is intentionally designed to be as annoying as possible.  It’s letting you know that your machine is vulnerable to known security threats and that you need to reboot it to install the fixes.

    One of the major problems we had before XP SP2 was that people would get security updates downloaded to their machines and they wouldn’t reboot the machines to accept the fixes.  They then got pissed off because they were 0wned as a result of the vulnerabilities.

  6. Anonymous says:

    Larry, since many people will actually take your advice, could you please rewrite #4 so that the COM is the last suggestion?

    Applications that use COM are on my list of serious offenders when it comes to bloat (both code and registry). Furthermore they are more prone to breaking down than the regular ones.

    Finally, COM is so hard to code properly that majority of people who take your advice on using it will most likely start producing poor code and the problem will only magnify itself.

    I agree on all other points. Funny though how I first read the title as "Apple best practices" 😉

  7. Anonymous says:


    I just booted up my computer and found myself looking at a printer driver update applet, from HP.  My demands of a printer are minimal.  If this was a security issue, I’d rather it came through Windows Update.  Here’s what I was thinking this morning.  Although I realize that this is more a marketing issue than a technical one, could the use of applets for updating an application be mitigated by a better task scheduling system?

    I regularly bit-flip between the Windows and Unix world.  I find value in both systems.  One thing that the Unix world has on Windows is the cron scheduling system.  It allows for some pretty complex schedules and is a great tool for last minute hacks (I wrote a daily email alert system from text logs using nothing more than grep, mailx, and cron.

    Perhaps a better scheduling system (or advocation of its use) could lead to less applet bloat.

Comments are closed.

Skip to main content