Why did the Add or Remove Programs control panel try to guess all that information?

Date:June 9, 2006 / year-entry #194
Orig Link:https://blogs.msdn.microsoft.com/oldnewthing/20060609-07/?p=30923
Comments:    38
Summary:As we saw earlier, the "Add or Remove Programs" control panel used several heuristics to attempt to determine things like program size and frequency of user. Why did it bother doing this at all? At the time the feature was added, disk space was not cheap like it is today. One of the problems users...

As we saw earlier, the "Add or Remove Programs" control panel used several heuristics to attempt to determine things like program size and frequency of user. Why did it bother doing this at all?

At the time the feature was added, disk space was not cheap like it is today. One of the problems users were having was running out of disk space and not knowing what they could safely delete. Thus was born the Disk Cleanup utility, which attempted to guide the user through various things that could be deleted in order to make disk space available.

In addition to cleaning up temporary files, you could also remove programs that weren't being used. But how do you know which programs you weren't using? (Maybe you were using a program without realizing it because it ran automatically.) And how do you know how much disk space would be recovered if you removed a program? That's where the program size and frequency of use heuristics came in. By providing this information (or at least trying to), the "Add or Remove Programs" control panel could help users decide which programs to remove.

Of course, nowadays, with hard drives in the hundreds-of-gigabytes range, disk space has become so cheap as to be nearly free. The need to remove programs to make more disk space available is largely gone, but the feature remains as a vestigial organ.

Comments (38)
  1. theCoach says:

    The circle turns with regard to space. Shooting RAW images with a Nikon D200 is filling up a lot of diskspace. And, when I get the 1080P video camera, coupled with Media Center, storage is getting expensive again – not nearly free.

  2. keeron says:


    you then just need another one of those "cheap" 200gb/300gb harddrives :-)

  3. Mike says:

    It’s not so much diskspace that I would care about as registry crud. If I’m not using a lot of programs then I’d like to get rid of as many possible file-handlers and other object-lichen that make a noticeable effect on day-to-day performance.

  4. BobDobbs says:

    Still, this is useful.. what would be good is if it didn’t take so long to populate on slower computers (some celerons at work)…
    Surely some information could be loaded after the list was initially populated (like last used)

    [It’s only computed once and then cached. Please read the linked article. -Raymond]
  5. You have clearly not seen the 2nd hard drive on my dev machine.  With 4 Vista enlistments, it’s a constant battle to keep it under 20G free.

  6. Stu says:

    The only problem with these huristics is that  they are calculated syncronusly, meaning it practically locks up the system while you wait (High disc usages has a much higher impact on other proccesses than high CPU usuage) and they are frequently wrong.

    Anyone using Vista know if it is any better?

  7. Adam says:

    Hopefully as Windows Installer moves towards a more declarative approach to .msi packages, it will get to the point where .msi compilers will know exactly how big applications (and application components, for if you choose to install only part of an app) are, and be able to output the code to write the registry details without app writers needing to worry about this in the slightest.

  8. Stu says:

    I quick check in my Add/Remove programs shows how wrong the information is. It seems that the usage information depends entirely on the start menu icon. Therefore, both VLC (which I used less than an hour ago to watch a DVD) and MSN Messenger, which runs on every startup and is running now, are shown as having not been used since their date of installation.

    This means that even Raymond’s example of a program you were using without realising because it runs automatically would have incorrect information (unless, I suspect, it uses to Startup group on the start menu).

  9. John Topley says:

    My recollection is that this feature was added for Windows 2000 and that the Disk Cleanup utility first appeared in Windows 98. I don’t remember disk space being that expensive in 1999. It was more expensive than it is now, but not I-got-to-delete-me-some-programs expensive. Or perhaps my memory’s all skewed!

  10. Dave says:

    It would be extremely valuable to know whether a user is using all the junk installed on their system. Disk space or registry junk is not a big issue, but other system resources and system stability are affected as well. It’s not that unusual to see a system where startup includes Adobe Gamma Loader, Quicktime, Office Startup, Realplayer, and several program registration reminders. They can add several seconds to startup time but NONE of them are needed by anyone. And if you have some crummy driver loaded that is looking for hardware that has been removed (USB perhaps) it can be even worse.

  11. Hob Gadling says:

    I wish the Add Remove Programs control panel had a way of sorting programs by install date. That would be really helpful sometimes.

  12. foxyshadis says:

    John, Win2k was designed for 2-3 year old machines being upgraded as well, in ’97 8 GB was good. Although by the time XP rolled around it had already outlived its usefulness, I still manage to find some random game or enormous video processing program when I take a look every few months.

  13. JamesW says:

    I don’t think it matters how much drive space you have. There is some rule that means content will be found to fill it. I’ve got 0.5TB of storage in my tower and still find myself managing diskspace. Having such goodies as every colour episode of Doctor Who (and a few B&W ones) might have something to do with it! It’ll soon be time to fill the final drive bay…

  14. mikeb says:

    Add/Remove Programs is so painfully slow to load up on my machine I’ve turned to a simple open source program, Safarp (Small And Fast Add/Remove Programs) to use instead:


  15. Nick says:

    I assume this is part of why the Add/Remove dialog can take so long to show the list of installed programs, especially on systems with a ton of stuff installed.

    Is it possible to disable this feature so the panel opens faster?

  16. Miles Archer says:

    There’s another reason for this mess. At the time, most programs were not "installed" per se. They were copied to a directory and you would run the executable. Even in Windows 3.1, this was what people mostly did.

    With Windows 95, you couldn’t just delete the programs directory any more because there might be files in the System directory, or some other place.

  17. Curt says:

    "Of course, nowadays, with hard drives in the hundreds-of-gigabytes range, disk space has become so cheap as to be nearly free."

    Heh. I’ve noticed that WMP11 tells me the size of every track in my library. Do I care that Getz and Byrd’s Desafinado takes 8MB (0.0126%) of my small boot drive? :-) Maybe if it listed spaced used per album it might make more sense to me, but even that won’t when I buy my next machine.

    (I know, I know, those of you with puny 128MB MP3 players care. :) )

  18. John C. Kirk says:

    Actually, I think this is a feature that’s still useful nowadays, mainly due to partitions. I often come across situations where someone has done a 4Gb partition for the C drive and put everything else onto the D drive, and then I don’t have enough space to upgrade to a new version of Windows. In a case like that, one solution is to uninstall things from the C drive and re-install them to the D drive.

  19. Reinder says:

    "Maybe you were using a program without realizing it because it ran automatically."

    Wasn’t this, specifically, one of the cases where the control panel wouldn’t notice that the application run, at all? (yep, looking back, I read "Add/Remove Programs needs to know the name of the EXE so it can ask the Start menu "Hey, how often did the user run this program, and when was the last time it happened?""; the comments seem to indicate that that, literally, is what the code does)

    I think this shows a nice anti-pattern that Microsoft is (or possibly: was. I haven’t looked closely at Vista yet, and do have high hopes for the new Office 2007 UI paradigm) guilty of more than "that other commercial desktop OS vendor":

    1) Notice a problem with the current UI (it is impossible for mortal users to determine what programs they run, or what they are called)

    2) With all the best intentions, try to improve the situation by adding complexity to the design of the system

    3) Someone discovers that this does not ‘quite’ work (in this case, it works hardly at all), quite possibly before the product ships

    4) The product is shipped, anyways (I guess because one does not want to ‘lose’ the money invested, or because having a new feature is priority #1, rather than improving the product)

    The net result is that one can nicely demo an improvement in usability ("look, we now show how much disk space you will gain by removing each component") that, in practice, does not help users much, if at all.

  20. BryanK says:

    OK, out of curiosity, how does it work?

    [Please read the linked article. -Raymond]

    For instance, I have Microsoft Visual SourceSafe 6.0 showing up in my add/remove list.  It was installed as part of VS6, then the next service pack version (still 6.0, but 6.0d or 6.0e or something like that) was installed as part of VS.net 2003.  SourceSafe also doesn’t really have its own Program Files directory.

    But the space used is showing up as 928MB.  I know that there’s no *way* it’s using that much space (its database isn’t on this machine).  I also see VS.net 2003 listed just below it, at 924MB.  The 4MB difference looks strange — is there a case where one package “depends” on another, and for some reason the size of the second package is included in the size of the first?

  21. BryanK says:

    > Please read the linked article.

    Uh… oops.  *embarrassed look*

    Thank you for the cluebat; that pretty much exactly explains what I was asking.

  22. Phil Wilson says:

    Actually MSI *does* know how big the installed app is because the MSI file table contains the size of each file. If the MSI author thinks it’s wrong, they can correct it with the ReserveCost table. So MSI installations could be more accurate, assuming the author cares about getting the size right. Having said all that, there doesn’t seem to an MSI API that returns the size of a product anyway! Apparently it’s more for use in installation dialogs, not ARP.

    It’s possible that some product usage counting is tracked through MSI shortcuts (not  the same as ordinary shortcuts) – activation of an MSI shortcut could call MsiUseFeature. Again, I have no evidence that it actually does however, and I haven’t tested anything.

  23. Vince P says:

    When it comes to knowing what to delete, I wish there was some (obvious) guidance on what to do about the C:Windows directory.

    Following is a list of the 20 largest subfolders ..

    I’d like to know (this is a rhetorical question) what I could delete should I ever get to the place where I’m out of other options. I put * before the obvious "don’t touch" folders.

    *C:WINDOWSsystem32drivers 35,095,242

    *C:WINDOWSMicrosoft.NETFrameworkv1.1.4322 35,689,304

    *C:WINDOWSMicrosoft.NETFrameworkv1.0.3705 35,969,533

    *C:WINDOWSWinFXv3.0WPF 39,181,638

    C:WINDOWS 42,693,789

    C:WINDOWSHelp 43,078,752

    C:WINDOWSInstaller$PatchCache$Managed69F14A0E13278EA46A45EE3BF43945269.0.1399 52,154,966

    *C:WINDOWSinf 58,338,154

    C:WINDOWSsystem32dllcache 64,381,344

    *C:WINDOWSFonts 77,389,800

    C:WINDOWSSymbolsdll 86,847,488

    C:WINDOWSDriver Cachei386 91,314,691

    *C:WINDOWSsystem32config 97,702,024

    *C:WINDOWSMicrosoft.NETFrameworkv2.0.50727 117,867,218

    C:WINDOWSehome 153,965,599

    C:WINDOWSInstaller$PatchCache$ManagedB29A3732C1C117E44B49C59AF769AA919.0.1399 164,519,124

    C:WINDOWSInstaller$PatchCache$ManagedDD23009EEBA4244CAE10B67DB4D3E059.0.1399 247,449,468

    *C:WINDOWSsystem32 561,230,350

    C:WINDOWSInstaller 724,433,269

    C:WINDOWSTemp 1,661,046,615

  24. "I don’t have enough space to upgrade to a new version of Windows. In a case like that, one solution is to uninstall things from the C drive and re-install them to the D drive."

    Quicker and easier to simply resize the partitions.  

    Reinstalling some programs to the D drive defeats the whole purpose of having 2 partitions in the first place, surely?

  25. Adam says:

    Open your c:windowstemp directory in explorer, sort by date, delete anything with a last modified date more than 1 week old. That folder *should* also probably be cleared out on reboot.

    The clue is in the name.

  26. PatriotB says:

    "Quicker and easier to simply resize the partitions."

    But not cheaper.  I think it’s silly that programs like PartitionMagic are sold for like $60 for someone who just wants to resize one partition one time.

    Partition resizing should definitely be part of the operating system.  Vista supposedly has a few more partition management features in it, but I think that’s what Symantec is suing them about…

  27. Michael Puff says:

    An information I can’t trust is nearly useless for me.

    I’m using Ad-Aware SE Personal. I run ist mostly under another user account. If I look it up it reads Used: seldom / frequently. (I’m using a German Windows XP, don’t know the original caption.) But what das seldom / frequently mean in this case? How often is seldom / frequently? I’m using it to see if everything is still OK with my system. I think it would be a bad idea removing it, even so Windows seems to advise me to do so.

    That’s why I think this Information is useless. Even worse: The entry reads: Last used: 2005-12-25. And that’s absolutely wrong. I ran it just yesterday under the administrator account. If I would follow Windows’ advice I could remove it because I haven’t used it for neary half a year.

  28. The calculations regarding Windows Installer are way too low, though. Because of all the caching Windows Installer does – including the addition of the MSPs in their entirety which ARP won’t take into account because it calculates once and caches – the amount of drive spaced used for an application is practically useless, especially as more and more applications switch to Windows Installer (and very many already are).

    See http://blogs.msdn.com/heaths/archive/2006/04/20/580237.aspx for details.

  29. NBC says:

    and why does C:WINDOWSInstaller msi file contains the install program ? that kind of similar to have 2 time the same program

  30. JD says:

    Another expensive feature that doesn’t even work half the time (and this passed triage?). Hopefully Vista doesn’t have too many more.

  31. Really J says:

    "But not cheaper.  I think it’s silly that programs like PartitionMagic are sold for like $60 for someone who just wants to resize one partition one time."

    If you just need to resize one partition one time, you can try a free utility.  GParted is a good one (http://gparted.sourceforge.net/) that does ntfs.

  32. DriverDude says:

    Many applications take at least twice the space reported by Add/Remove Pgms, even if Add/Remove was correct.

    Their installer copies the entire MSI into %windir%Installer. Presumably this allows the user to repair the app without the original CD.

    The user isn’t told the truth. Apps that say "require 100MB disk space" use may need 300MB for install temp files and take 200MB because of the duplicate MSI.

    Oh, and if there’s 100MB on C:, you cannot even install the app into D: because the MSI has to be copied into C:WINDOWSInstaller

    As far as I’m concerned, disk space estimates are utterly useless. I doubt the developers even know the real numbers – they blindly rely on InstallShield and MSI.

  33. Raymond, thanks for revisiting this topic.

    Here’s my findings, courtesy of my company running a mixture of old and new hard drives, with varying partitions and overall sizes:

    As long as you’ve backed up your data, you can use a Knoppix Linux boot CD or DVD to boot a PC running Windows XP into Linux, then use the "QTPartED" utility to resize the partitions on the fly, avoiding shelling out $69 for Partition Magic.  I have done this several times successfully, and it averages about 45 minutes start to finish, less on faster machines.

    Note that Windows may detect that the swap file has changed, turn it off the first time you reboot, and then you’ll have to turn it on again.  A disk check is automatically scheduled as well.  It looks scarier than it really is.

    I also recommend using the fine SysInternals tools to defragment your pagefile if you haven’t already.  It’s by the hero of the Sony rootkit saga, Mark Russinovich, and defrags XP registry sections that don’t get hit by the normal XP defrag (which is pretty weak).

    You may also like getting Diskkeeper or O&O Defrag for awesome defragging results.  There is also a free defragger located around whitneyfamily.org that is fairly opaque but seems to do a better job when combined with the regular XP defrag than just the XP defrag by itself (which is pretty weak).

    Juggling partition sizes HALVED the time it took Word, Excel, and other programs to boot on my older laptop, for instance.  Several people in my office were chagrined to discover that it wasn’t Microsoft’s fault, it was their boneheaded partitioning scheme that made programs seem slow.

    I seem to recall hearing that Microsoft is also working on a on-the-fly partition manager, logical since you can do that with some newer Macs.  This would be awesome for testing Vista, for instance, since you could partition on the fly, install it in 5 partitions, then as you eliminated the worst-performing installations, you could redistribute the space to the Vista partitions you liked.

  34. Will Alber says:

    I got so sick of the time it took Windows to populate the Add/Remove dialog that I wrote my own very-light-weight version – QuikUninstall (http://www.crazy-pug.co.uk/QUSetup.zip).  OK, so it’s not pretty nor is it polished, but it works nicely.  There’s a little bit of a hit the first time your start it (it uses the .net Framework V1.1), but on subsequent loads (I’m a programmer an leave my computer on a lot) it’ll load in less than a second.  Best thing – it’s free (so no, I’m not trying to sell anything!)  :).

  35. James says:

    Depressingly, it looks as if Windows actually ignores the EstimatedSize
    value in the Registry; from the installer forums I looked at, it seems
    you need to write your own value into SlowInfoCache instead. (Possibly
    wrong, in which case any documentation would be greatly appreciated!)

    Probably guaranteed to make Raymond’s lunch come back, given his
    “love” of ugly hacks like this – but at least it works, and DriverDude
    will be happy to know the filesize is exactly correct (calculated as
    the files are copied, taking into account compression if the target
    directory is compressed).

    [EstimatedSize is used for MSI apps. -Raymond]
  36. James says:

    [EstimatedSize being ignored for non-MSI apps]

    That was the suspicion I got, yes; I’d just been hoping for a "cleaner" way to specify application size than entering values into SlowInfoCache directly. :-(

  37. After playing around with Server Core for a while I’m beginning to wonder how to perform certain administrative

Comments are closed.

*DISCLAIMER: I DO NOT OWN THIS CONTENT. If you are the owner and would like it removed, please contact me. The content herein is an archived reproduction of entries from Raymond Chen's "Old New Thing" Blog (most recent link is here). It may have slight formatting modifications for consistency and to improve readability.

WHY DID I DUPLICATE THIS CONTENT HERE? Let me first say this site has never had anything to sell and has never shown ads of any kind. I have nothing monetarily to gain by duplicating content here. Because I had made my own local copy of this content throughout the years, for ease of using tools like grep, I decided to put it online after I discovered some of the original content previously and publicly available, had disappeared approximately early to mid 2019. At the same time, I present the content in an easily accessible theme-agnostic way.

The information provided by Raymond's blog is, for all practical purposes, more authoritative on Windows Development than Microsoft's own MSDN documentation and should be considered supplemental reading to that documentation. The wealth of missing details provided by this blog that Microsoft could not or did not document about Windows over the years is vital enough, many would agree an online "backup" of these details is a necessary endeavor. Specifics include:

<-- Back to Old New Thing Archive Index