Applet Mitigations

re: Applet Mitigations

davidacoder — Thu, 16 Aug 2007 22:22:06 GMT

On the restart manager: It is almost a no-brainer to not use it. Only Vista? Gee, I cannot imagine any ISV who could afford that...

"make sure that there's a way for the user to turn it off" That is not going to work. What incentive does a ISV have to provide that option?!? None, really. This is a classical game theory problem. There is a cost to do it the way you suggest it. The benefits of doing it properly are tiny, if you are alone doing it. Plus, any ISV doesn't really get the benefits, rather the platform as a whole gets it, IF everyone does it. Basic economic theory tells you that you will always get the non-cooperative solution in such a situation, you are fighting a battle you cannot win. The way out is to recognise that a) MS is the only party that would really benefit if all ISVs did it properly (simply because the Windows platform would hopefully be known to not have all the crappy negative side effects of applets) and that therefore you guys need to get the incentives right for ISVs. What could that be? Simple, make it even LESS costly for an ISV to provide these options than not to. How could that be achieved? Something like Vista's mobile applet window, maybe with an option to active and deactive per user services or something like that would be a good start. If you provide a prominent UI place for applets to plug into (sidebar might be another place, or even a new notification area), ISVs will want to be there. Then use that and only provide an API to get to that UI space that at the same time allows users to simple enable/disable such services. You can go on an ask ISVs forever to change their behaviour, but unless you understand the economics of this and act accordingly, nothing will change.

re: Applet Mitigations

LarryOsterman — Thu, 16 Aug 2007 23:25:51 GMT

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.

re: Applet Mitigations

Mihai — Fri, 17 Aug 2007 00:59:47 GMT

davidacoder makes a good point. It is about economics.

There are many ISVs that work hard to make something difficult to disable, kill, change.

Think all the crap^H^H^H^H applications that every time they run they hijack file formats, add themselves to autostart, to system try, to desktop, start menu, quick launch, explorer context menus, etc.

This is a lot of work. They do it because *they want* to be "in your face," not because is easy.

re: Applet Mitigations

Good Point — Fri, 17 Aug 2007 03:41:29 GMT

Speaking of the audio service, don't forget AudioDG.exe. On my system it's got a working set of 40 megs.

Honestly, if a 'craplet' is taking up 4 megs or so of memory, I think (de-sensitized by all of the components in Vista), 'Oh well'.

re: Applet Mitigations

LarryOsterman — Fri, 17 Aug 2007 06:33:19 GMT

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.

re: Applet Mitigations

davidacoder — Fri, 17 Aug 2007 14:52:40 GMT

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.

re: Applet Mitigations

charless — Fri, 17 Aug 2007 17:17:51 GMT

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?

re: Applet Mitigations

LarryOsterman — Fri, 17 Aug 2007 20:17:06 GMT

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.

re: Applet Mitigations

Dave — Fri, 17 Aug 2007 21:02:15 GMT

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.

re: Applet Mitigations

LarryOsterman — Fri, 17 Aug 2007 21:11:22 GMT

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.

re: Applet Mitigations

davidacoder — Sat, 18 Aug 2007 16:39:34 GMT

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 :)

re: Applet Mitigations

Scott Bilas — Sun, 19 Aug 2007 19:49:49 GMT

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.

re: Applet Mitigations

LarryOsterman — Sun, 19 Aug 2007 19:56:56 GMT

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.

re: Applet Mitigations

Norman Diamond — Mon, 20 Aug 2007 03:44:32 GMT

> (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.

re: Applet Mitigations

LarryOsterman — Mon, 20 Aug 2007 08:39:07 GMT

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).

re: Applet Mitigations

Leo Davidson — Tue, 21 Aug 2007 03:12:55 GMT

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.

re: Applet Mitigations

Leo Davidson — Tue, 21 Aug 2007 03:45:37 GMT

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!

Leo

re: Applet Mitigations

Scott Bilas — Tue, 21 Aug 2007 08:44:33 GMT

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..

re: Applet Mitigations

davidacoder — Tue, 21 Aug 2007 13:27:12 GMT

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.

Applet Mitigations - Notification Area Handlers

Larry Osterman's WebLog — Tue, 21 Aug 2007 23:32:25 GMT

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

re: Applet Mitigations

Mitch 74 — Wed, 22 Aug 2007 12:06:03 GMT

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.

Applet Mitigations - Services.

Larry Osterman's WebLog — Thu, 23 Aug 2007 03:27:45 GMT

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

Larry Osterman isn't that into you, either.

Tales from the Crypto — Thu, 23 Aug 2007 07:54:01 GMT

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

re: Applet Mitigations

J.Random — Wed, 26 Sep 2007 17:33:48 GMT

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.

The Shell used to get all the cool APIs :)

Larry Osterman's WebLog — Mon, 05 Nov 2007 21:43:11 GMT

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