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).
Some people seem to be saying that, since "nobody wants to write Vista-only apps," Microsoft should never add another feature to the OS. That's crazy talk. In the worst case, eventually Vista will be the minimum OS that you support and you'll be glad that X years in the past some useful features were added that you can now take advantage of. In reality, people write code all the time which detects the OS and invokes new features where available, falling back on different behaviour where not.
I know I do. In fact, both things apply now. I've dropped Win95 and NT4 support from the things I write and now I can use some of the nicer APIs in Windows 2000 (and Win98 and NT4) where before I either had to use a more primative API or have conditional code which used the new API where available (via GetProcAddress, stuff copied out of header files, conditional logic and other hassles) and the old API where not. Eventually I'll be able to include the Vista APIs as standard and I'll be glad they were added to Windows back in 2007.
I bought a Microsoft LifeCam VX6000 webcam for my Vista PC. It installs one service and another application which automatically runs in the background when the user logs in. The problem isn't just that two processes are installed, nor that what they do isn't very useful. The way they are written is really, really bad.
Larry, before I continue, let me say: Feel free to moderate this post out of the blog comments. I don't mean to bring it up in public and say "hey MS are as bad as everyone else" (you said it already and it doesn't need saying; MS are a huge company with hundreds of developers of varying talent and experience and they'll make mistakes like anyone else will). I just want to mention it to you in case you can have some influence on the responsible team, even if it's just calling them names if you see them at lunch, in the hope that the shame will force them to do a better job. :-)
The service is MSCamSvc and whoever wrote it didn't even bother to give it a proper name or description. As far as I can tell the service does nothing other than launch an application when the physical "phone/globe" button on top of the webcam is pushed. At least, I have stopped the service and set it to Manual startup for the last few months and that's the only "downside" I've noticed so far. (I've never wanted to use that button anyway.)
The application is vVX6000.exe and I have used Windows Defender to block it from running at startup. The only "downside" to preventing this helper app from running is that I can no longer use the feature which overlays backgrounds and animated images on the webcam in realtime. If I do want to use that feature then I can run vVX6000.exe manually, and then kill it afterwards. The backgrounds are cute and might be worth an extra process, except for what that process does 24/7... (I'll get to that in a second.)
Apart from those two largely useless features the webcam works absolutely perfectly when both the service and the helper app are not running. In the case of the helper app I don't understand why it couldn't be started on-demand when an application starts using the webcam.
That isn't the worst of it, though. The only reason I even noticed these two programs is that they *poll* the registry and filesystem every two seconds or so. They do this whether or not the webcam is in use. This spams the hell out of ProcMon logs, as you can imagine, and it can't be good for the PC's performance to have two do-nothing processes constantly active, loaded into memory that can't be paged out, and hitting the filesystem/registry every 2 seconds. Whoever wrote them could really do with some Win32 lessons, in particular about wait handles and registry/filesystem change notification.
Again, I stress, I'm not mentioning this to say "OMG MS suck!" and I don't mind if you don't publish this comment. I just thought it was particularly badly written and gratuitous software that you might be able to bug someone about, especially if it's a pet hate of yours.
Thanks for listening!
Regarding disabling the page file, doesn't that explain exactly what I'm seeing? I've got 2 gigs of RAM on this thing, and haven't gotten close to using it up. Even with a few copies of Dev Studio running and all the other assorted tools I use, still has plenty to go. I've noticed better performance in general from this, especially when restoring minimized apps. Which reminds me..
I remember reading somewhere that when you minimize an app, the system will page it out either right away, or relatively quickly. Any memory pressure (from a hog like Outlook or Firefox) will flush read-only pages, probably most of which is code I would bet. Is that right, or at least close?
So: consider if Outlook is set to check email every 30 minutes. You minimize it, surf a little, the system pages most of Outlook out, then hibernate for the weekend. On Monday, upon waking up, Outlook figures out it needs to check email, update RSS feeds, run filters, check appointments, basically pull everything back in again that got flushed before hibernate - the PST file, the network stack, all the millions of supporting DLL's, etc. It does that the *instant* it gets any CPU time after restoring from hibernate. So it locks up the hard drive with seeks precisely when I need it to do one thing (such as do a quick Google Map search to find where the bar I'm going to in 5 minutes is). Add to that a bunch of applets and you (or at least I) have an unresponsive system because this poor little notebook hard drive just can't keep up with all these simultaneous requests.
Disabling the page file doesn't fix the cache flush issue, but it does keep all the code in memory. I have this problem on Vista. In fact, I upgraded my notebook from XP in large part because I expected Vista to fix this horrible problem, which I've seen increasingly over the years from XP. It's far worse than XP ever was, too. I never thought of disabling the page file on XP, but was forced to do it on Vista. There's a couple apps that don't work, they must use the page file (what was it...some memory mapping function that you could alloc backing store from the page file) but I'm not looking back.
Am I the only one that has noticed this situation? It drives me absolutely nuts..
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.
First off (as always), reconsider your need for a notification area handler. Seriously consider if it's
I... guess it shows that a lot of today's hardware comes loaded with crapware? I mean, when a developer is paid to output as fast as possible a useless app, it will botch it up something fierce anyway...
This may have come from a missed opportunity; for example, all those updaters would have fit much better in the Scheduled Task Manager: they wouldn't have been running when unneeded, and still accomplished what they were set up to do. However, not only did the Scheduler not work very well initially, its interface was awkward and didn't allow an installer to set it up interactively (or to prevent modification upon their updater from the user), which made it unattractive in a pure branding aspect and technically harder to support than a home-grown application.
The only solution left was to embed it into the system so tightly that it wouldn't move. And that became the norm - exit the Scheduler.
Had it not been for that, all updaters could have run under a SINGLE constant process (as soon as you get two updaters, you win)
About crappy apps hogging the tray: well, the only way to force editors to do a correct work would be to force a numeric signature of their apps - obtaining that signature would require that the app can be shut down for good. In the webcam example however, that would require signing the driver, the main manager application, and the 'eye-candy' feature app.
That's an area where I enjoy Free software: since the source code is readily available, programmers are forced by their ego to create proper code. This usually entails: reduced footprint, no more resources drawn than required, use currently installed libraries, ensure that it works solely in user space, provide correctly threaded and portable code.
Moreover, cron and anacron allow intelligent task scheduling, while the hibernation model used on, say, Linux, requires the RAM and swap partition to be cleaned up before hibernation (the swap is emptied before being reused as memory dump) - meaning that any task an app may want to run at wakeup will take place in RAM.
As a senior developer at Microsoft, you often find yourself participating on a number of v-teams. One
In previous articles, I've pointed out: Programmer Hubris - He's just not that into you Programmer
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.
After I posted my article on the SHAutoComplete , I mentioned it to one of my co-workers. His response