Udostępnij za pośrednictwem


Applet Mitigations

As I've mentioned, applets  can be a plague on your system.  The annoying thing is that it's possible to write applets that aren't so horrible.  And most of the mitigations are really just common sense ideas - there's nothing spectacularly complicated in any of them.

As with the earlier posts in this series, some of the mitigations are common to all types of applets (and all applications in general), and others are specific to various types of applet.

 

Let's start with the basics...

For applets that run all the time:

Do you REALLY need to have an applet running all the time?  The best applet is one that doesn't run at all.  Is it possible to bundle your applet's functionality into an application that the user invokes?  The start menu highlights newly installed applications, so your new application will be visible there, worst case there are other mechanisms for installing your application in locations that are visible to the user (the desktop is one of them (although that has its own set of issues)).

Now that you've decided you need an applet that runs all the time, please reconsider.  Seriously.  I know I just asked you to think about it, but really.  Steve Ballmer says that sometime in 2008, a billion people will be running some version of Windows, that's a LOT of people.  If your product is successful, you're likely to be selling to a couple of million of them - do you believe that your applet provides enough value to every one of those customers that you need to have it running in their face?  Really?

Once you've decided that you REALLY need to have an applet running, make sure that there's a way for the user to turn it off.  There's nothing more annoying than realizing that the software that came with some random piece of hardware that I use maybe once or twice a month is running all the time on my machine.

If you've written an applet because you want to let the user know about some cool feature, why not use the RunOnce key to let the user know about the feature, letting them know how to discover the feature later on, then shut up and never bother them again?

 

For all applets (and all applications that are expected to run all the time):

Think about how to reduce the applets impact on the user.  Reduce the DLL load in your applet whenever possible - each DLL you load consumes a minimum of 4 private pages (16K on x86) and takes between 500K and 1M cycles to load.  Anything you can do to reduce that is better. If you can get away with just loading kernel32.dll and the C runtime library, it's better.  Consider delay loading DLLs that you infrequently use.

Reduce the stack size used for the threads in your applet - by default Windows threads get a 1M commitment and 10K of reserve (which really turns into 12K of reserve due to paging).  That means that every thread is guaranteed to consume at least it's stack commitment space in virtual memory (the good news is that it's virtual memory - normally that'll just be space reserved in the paging file, not real memory).

Reduce the number of processes that your applet needs.  There's rarely a good reason for you to require more than one process to do work.  About the only one I can think of is if you split functionality to increase the amount of code you have running at a high privilege level).  As an example of this, in Windows Vista, the audio stack runs in two separate services - the AudioSrv service and the AudioEndpointBuilder service.  This is because a very small part of the functionality in the audio engine has to do some operations that require LocalSystem access, but the rest of the audio stack can run just fine as LocalService.  So the AudioEndpointBuilder service contains the high privilege code and the AudioSrv service contains the rest.  If you feel you need to have a separate process to provide reliability (you run the code out-of-proc in case it crashes), windows Vista provides a cool new feature called the "restart manager".  The restart manager allows the OS to restart your application if it crashes, reducing the need to run code out-of-proc.

Don't forget that Windows is a multi-user system.  Some of your customers won't want your applet, others will.  So make sure that the settings to enable/disable the applet are instanced on a per-user basis.  It's really annoying when you right click on a notification area icon and see that the "disable this" menu is disabled because you're running as a normal user (which is most users on Vista).  Whenever I see this, I know that the author of the applet didn't consider the normal user case.

If you can target Vista only, consider reducing your thread and I/O priority.  If your applet is performing processing that's not directly related to the user, use the new PROCESS_MODE_BACKGROUND_BEGIN option in the SetPriorityClass API to let the system know that your process should be treated as a low priority background process - that way your applet won't preempt the user's work.  You can also use the new FileIoPriorityHintInfo method of the SetFileInformationByHandle to let the OS to prioritize your I/Os to a handle below that of other user operations.

 

Next: Mitigations for updaters (no post tomorrow since I'm moving offices).

Comments

  • Anonymous
    August 16, 2007
    The comment has been removed

  • Anonymous
    August 16, 2007
    Davidacoder: Actually it's not that horrible to build stuff for XP and then light up additional functionality on Vista - Office does this, for example.  It does mean additional work, but it's not the end of the world.

  • Anonymous
    August 16, 2007
    The comment has been removed

  • Anonymous
    August 16, 2007
    The comment has been removed

  • Anonymous
    August 16, 2007
    If audiodg is taking up that much memory, you should check to see if an updated driver is available for your audio solution (or disable all system effects).  We've had reports of buggy audio drivers that have memory leaks causing this - on most machines I've looked at, audiodg consumes around 4M of RAM.

  • Anonymous
    August 16, 2007
    But if an ISV cares about reliability, it will care about reliability on Vista AND old Windowsversions. Following your suggestion would mean that the ISV should use Vista's restart manager on Vista systems, and a homegrown solution on older versions. What is the incentive for an ISV to do that? The homegrown version has to be developed in any case, what does he gain from expending more dev time to also implement use of Vista's restart manager? Why would he use it? There is no incentive at all in such a situation.

  • Anonymous
    August 17, 2007
    davidacoder That most likely means that MS should make restart manager available downlevel (i.e. on XP, since that is the only other platforms [yes I mean plural] that matter since every thing else is more or less EOL) Now the economic question is does MS benifit enough to do that in a way that is good for customers?

  • Anonymous
    August 17, 2007
    charless, that ain't gonna happen.   There's no reason that an application can't take advantage of the restart manager when running on Vista - Office somehow manages to take advantage of the restart manager when it's running on Vista, and on previous OS versions, it doesn't. When you run on Vista, new features and functionality light up, on previous OS releases, they don't.

  • Anonymous
    August 17, 2007
    Larry, independent developers are in a different situation than Office. Unlike Microsoft, we don't common up-level bosses that say we must take advantage of the new Vista features to prevent the company from looking like hypocrites. Our bosses look at the huge XP installed base and relatively slow uptake of Vista and say, "Make sure it works on XP and Vista, but only add Vista-specific features if it buys us something." It's often easy to leverage Vista's low-priority I/O with a few lines of code, but it's another to completely retool the crapplet design and installation process to use the Vista scheduler or other functionality. That takes time, and time takes money, and time prevents shipping. I really like the Vista scheduler, it's an undiscovered gem. To be realistic it wouldn't even help if Microsoft back-ported it to XP at this point unless they also allowed third parties to ship it as a redist with their products since most systems wouldn't have it installed. By the time all that happened it will be 2011 and XP will be fading fast.

  • Anonymous
    August 17, 2007
    Dave, actually that's not <i>quite</i> the way it worked - the reality is that our "common up-level boss" was Bill Gates (Office is in Jeff Raikes org, Windows was in Jim Allchin's org, now in Kevin Johnson's org). As I understand it (obviously, I'm not on the Office team, neither am I on the restart manager team), the Office team learned about the new features we were planning on Vista (the same way that our other customers did), realized that they were specifically designed to address certain pain points that customers (including Office) were feeling, and adopted them. It didn't add a significant amount of complexity to their test matrix (they already had to test on Vista, this just meant that their Vista tests cases also included testing the restart functionality). I'm trying to be very clear about the Vista-specific functionality in these discussions.  The vast majority of the stuff I'm talking about works on OS's as far back as Windows ME (some of the advice goes way back to NT 3.1). Even if you don't adopt the Vista-specific functionality, the other recommendations are still valid.

  • Anonymous
    August 18, 2007
    Does anyone know of any important third party app that takes advantage of some new technology that is in Vista, i.e. lights it up as Office does it? Or has that happened when XP was introduced? Just curious, I honestly don't know.  But none comes to mind, right now. I no major up besides Office does it, then that would suggest to me that their using it was a incentive that came from being in the same company with Windows :)

  • Anonymous
    August 19, 2007
    Here's another rule I'd like added to your list - Be Hibernate-Aware. When I wake my notebook up from sleeping after an hour or so, there's no problem. But if it's been sleeping for a couple days, say, over the weekend, it takes a very long time to finally wake up due to all the hard drive activity. I had to disable the page file in fact to keep it from taking 3-5 minutes to wake up. I'm not 100% sure of the problem but it appears to be that every app in the system is doing its "hey, it's been a while since I've done task x" routines. So maybe, Explorer is re-checking the Start Menu to figure out what to highlight, the Recycle Bin is clearing out files, every updater type applet is busy trying to get on the network to check for their updates, Google Desktop is refreshing its Gmail index, etc. All of which starts to happen instantly as soon as the machine starts up the processes again after waking up. Which causes a huge amount of hard drive activity, not good for a 4200 rpm notebook hard drive. Especially when all you want to do is check email real quick. Disabling the page file helped quite a bit for me. I tried killing as many applets as possible, keeping my drive and pagefile defragged, but nothing solved the 3-5 minute wake-up time until I killed the page file. Simple rule to be hibernate-aware: if it's been > 60 seconds since your last update loop iteration, then the machine has probably been hibernated. Wait a random amount of time from 20 seconds to 5 minutes before doing whatever checks unless it's absolutely necessary to do it immediately (like perhaps logging into IM). Auto-updaters do not fall into this category.

  • Anonymous
    August 19, 2007
    Scott, that's an interesting point. I don't see why turning your paging file off helps the hibernate case, all you're doing is forcing the system to keep all your code in memory (which means that the stuff you're not using hurts the stuff that you are using). If you're running XP, I suspect you're seeing what we call "standby list erosion" (slava oaks talks about it here: http://blogs.msdn.com/slavao/archive/2005/01/29/363181.aspx#1730358, the good news is that Vista has logic to alleviate that problem.

  • Anonymous
    August 19, 2007
    > (no post tomorrow since I'm moving offices). (1) You mean the applets will let you move offices before they run? (2) You need to switch back from C# to C++.  Then you can just update a pointer instead of moving.

  • Anonymous
    August 19, 2007
    Norman, I wish that moving offices was as easy as redirecting a pointer.  It's a royal pain in the neck (you see, I have these extremely large and distressingly fragile lego models that have to be moved by hand)... Btw, I do all my real work in C++ :) Btw2: Daniel just opened up his new Lenovo x61 tablet (a present for taking honors algebra 2 over the summer), I was literally astonished at the amount of stuff that came preloaded on it (norton's security suite, diskkeeper, office 12 (trial edition), the list was quite long).

  • Anonymous
    August 20, 2007
    The comment has been removed

  • Anonymous
    August 20, 2007
    The comment has been removed

  • Anonymous
    August 20, 2007
    The comment has been removed

  • Anonymous
    August 20, 2007
    I can confirm Scott's problem, I am on Vista, everything up to date, with a 7200 RPM disc, Thinkpad T60. Plain and simple terrible, I NEVER get good start up times when I had the machine in hibernate for a while.

  • Anonymous
    August 21, 2007
    First off (as always), reconsider your need for a notification area handler. Seriously consider if it's

  • Anonymous
    August 21, 2007
    The comment has been removed

  • Anonymous
    August 22, 2007
    As a senior developer at Microsoft, you often find yourself participating on a number of v-teams. One

  • Anonymous
    August 22, 2007
    In previous articles, I&#39;ve pointed out: Programmer Hubris - He&#39;s just not that into you Programmer

  • Anonymous
    September 26, 2007
    Interesting that you should mention this, I've just been in a debate with a programmer whose applet displays four small icons in the notification area. It takes 15MB of memory (and a pile of other system resources) to do this, because it includes everything but the kitchen sink as part of the program, even though the only part that's actually used 99.9% of the time is the tiny fragment that handles the notification area (I would guess the working set isn't larger than a few hundred kB). The response to any requests from users for a lite version is some variant on "it's only 15MB, no-one will even notice it". Sigh.

  • Anonymous
    November 05, 2007
    After I posted my article on the SHAutoComplete , I mentioned it to one of my co-workers. His response