Print Story A Day in the Life
Who's the 17?
We are trying to do a silent uninstall of the "$UninstallManager".

We can't find a way to even remove it. Could you please provide us with the necessary parameters/information to silently uninstall the "$UninstallManager" itself and not only the component that it is set to manage. We have succesfully been able to silent uninstall of components controlled by it.

What? You want to remove a base operating component? You tards.

x-posted to bog spot



The $UninstallManager is a base component designed to allow clean removal under Windows; we don't support its removal. Why would you want to remove it? If your intention is to prevent users from installing components this can be done with Windows' Group Policy Editor.
And that should've been that.

Not half an hour later came the reply:

Dear Mr Canine,

Thank you for giving us the laugh of the day - our software distribution team is just shaking their heads.

No, we are not trying to prevent the users from installing components. Our software distribution team is not very keen on installing software on laptops that can't be removed again.

Please submit a bug report to fix this in an upcoming release.

What the...?

I rang them back to confirm the problem. It seems that when you install our software on any machine, the $UninstallManager is installed as well so that we can clean up all nice and tidy like. Except that the damned thing itself can't be removed without manual deletion and Registry hacking.

They get a Root Cause: 1-Bug, I get a friendly thank-you for sorting this quickly instead of doing the Bangalore Boogie by sending one pointless mail after another, and I've decided the Eng gets a big fat 17 today for designing an uninstaller which itself can't be uninstalled. Fuckwits.

< Photo Wednesday: Sparks | BBC White season: 'Rivers of Blood' >
A Day in the Life | 14 comments (14 topical, 0 hidden) | Trackback
Although by ad hoc (4.00 / 1) #1 Wed Jun 07, 2006 at 04:45:02 AM EST
if I do uninstall the product, I'd like the uninstaller to be uninstalled as well. A certain Canadian company doesn't seem to understand this, and even though it has been uninstalled, the uninstaller is still present as is the context menu entries for the thing.
--
Close friendships and a private room can offer most of the things love does.
How does it install ? by sasquatchan (2.00 / 0) #3 Wed Jun 07, 2006 at 05:37:20 AM EST
See, this whole MSI crap is a boondoggle. There's bugs in MSI and in the various 3rd party implementations of MSI (eg: Installshield), and registry hacks involved.

The 'good' scenario is when the un-install does happen (files/services/objects/reg entries removed), and all you're left with is a bogus entry in the add/remove programs snap-in (ARP).

And trust me, multiple versions of install shield will do just that. They automate the install and uninstall.

Easy fix, in the sense of know the product code (GUI) for your program, and have the last action of your un-install remove that entry in the registry if the 'automated' uninstall part doesn't.

Keys to think about:
HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall\{Product_Code}
and the key:
HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall\InstallShield_{Product_Code}

Find the right one(s), delete 'em, they disappear from the ARP winder.

Of course, make sure you're got the right product code, if you're doing it by hand.. heh.

[ Parent ]
It's not my program by ad hoc (2.00 / 0) #8 Wed Jun 07, 2006 at 06:38:50 AM EST
It's a commercial product. It's not my uninstall, it's theirs. It doesn't work.

It was InstallShield, IIRC. It also leaves a bunch of crap in the directory structure. I'm still finding bits of it.
--
Close friendships and a private room can offer most of the things love does.

[ Parent ]
Yeah by sasquatchan (2.00 / 0) #10 Wed Jun 07, 2006 at 07:11:32 AM EST
shell extensions are a bitch. I try to avoid those.. Just asking for trouble.. heh.

Anyway, files that aren't part of the install, but are created by the program, aren't usually removed -- thus leaving cruft. Sometimes the files are removed on reboot (a PITA MSI problem where the 'installed program' is stopped, but win32 says the files are still in use, can't delete) and sometimes the engineer was just sloppy and didn't write any custom code to remove generated files.

But shell extensions. Gah.

Anyway, maybe MSIzap might be of use to you, if you can figure out the product code (poke the registry as mentioned beforehand). It might clean up your context menu there.

Ooh. MS has a new front end UI for it. Damn. new MSI zap

[ Parent ]
I'm not an expert, by ambrosen (4.00 / 1) #2 Wed Jun 07, 2006 at 04:51:10 AM EST
but it seems that, in theory, the registry's a good thing: a database of key-value pairs that's flexible enough to keep whatever data the program needs, and formal enough to keep the stuff that's needed in its place.

On the other hand, the fact that all the classes get so interlinked and interdependent is a problem, and that there's no easy way to identify redundant ones is definitely a flaw.

I'd agree if it wasn't binary by lm (2.00 / 0) #4 Wed Jun 07, 2006 at 05:39:58 AM EST
I don't know it can still be done in 2K and Xp, but under the 9x Windows kernels, you could boot into DOS mode which enabled an undocumented flag which would enable you to run regedit and export the entire registry to a text file, fire up your favorite text editor to make changes, and then run regedit with another undocumented flag to rebuild the entire registry from the modified text file. The Windows registry, when displayed as a text file, is truly a thing of beauty. I'm not certain why they made it into a binary medium. For system configuration that can get borked and require the system to be rescued, text is where it's at.

There is no more degenerate kind of state than that in which the richest are supposed to be the best.
Cicero, The Republic
[ Parent ]
Export/Import by ReallyEvilCanine (2.00 / 0) #6 Wed Jun 07, 2006 at 05:56:26 AM EST
You can do keys and even entire hives.

Keeping it binary means no run-time compile. Run RegMon sometime and see just how many Reg accesses a second your machine pulls depending on what you're doing.

the internet: amplifier of stupidity -- discordia

[ Parent ]
Export and Import don't do what I'm talking about by lm (2.00 / 0) #7 Wed Jun 07, 2006 at 06:13:01 AM EST
Registry import makes a goat screw of a file that is difficult to read and understand. The hidden flags in the old style windows created a text file of key/value pairs. If you export an XP registry to text you get garbage that looks like this:

Key Name:         HKEY_LOCAL_MACHINEHARDWAREDESCRIPTIONSystem
Class Name:        <NO CLASS>
Last Write Time:   5/31/2006 - 9:38 AM
Value 0
  Name:            Component Information
  Type:            REG_BINARY
  Data:
00000000   00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00  ................

Value 1
  Name:            Identifier
  Type:            REG_SZ
  Data:            AT/AT COMPATIBLE

Value 2
  Name:            Configuration Data
  Type:            REG_FULL_RESOURCE_DESCRIPTOR
  Data:
                     Interface Type:    Invalid
                     Bus Number:        -1
                     Version:           0
                     Revision:          0
                     Partial Descriptor 0
                       Resource:        Device Specific
                       Disposition:     Undetermined
                       Reserved1:       0x00000000
                       Reserved2:       0x00000000
                       Data:
00000000   80 00 fe 03 00 00 3f 00 - fe 00 01 00              .....?....

Value 3
  Name:            SystemBiosDate
  Type:            REG_SZ
  Data:            02/20/06

Value 4
  Name:            SystemBiosVersion
  Type:            REG_MULTI_SZ
  Data:            DELL   - 7
                   Phoenix ROM BIOS PLUS Version 1.10 A06

In days of yore, the registry could be converted to something that looked like:

key_name0
key_name0/value0_name=value0
key_name0/value1_name=value1

Which was much easier to work with. But for all I know, those undocumented flags may still exist. Booting to DOS mode and mounting an NTFS file system, however, is problematic.

Also, bear in mind that the registry loads into memory at boot time, so your compile time hit is a one off affair that most people wouldn't notice given the length of time it takes to boot to start with. It would also help if more programmers would store pointers to binary files rather than inserting binary data into the registry itself.


There is no more degenerate kind of state than that in which the richest are supposed to be the best.
Cicero, The Republic
[ Parent ]
Troubles by ucblockhead (2.00 / 0) #11 Wed Jun 07, 2006 at 07:33:19 AM EST
One huge problem with it is that it mixes both system-wide settings and user specific settings. In Unix, a user's settings are located in their home directory so it is trivial to move a user's settings to a new machine. In Windows...every reinstall means starting from scratch.

There really should be separate registeries...in other workds, HKLM and HKCU should be in entirely different databases.

(It's also a disorganized mess, but that's an entirely different issue.)
---
[ucblockhead is] useless and subhuman

[ Parent ]
They are in different databases. by ambrosen (2.00 / 0) #12 Wed Jun 07, 2006 at 10:03:11 AM EST
System.dat and user.dat. I've had success swapping old versions of them into reinstalled OSes, although I've forgotten quite what possessed me to do so.

[ Parent ]
That works!? (nt) by ucblockhead (2.00 / 0) #13 Wed Jun 07, 2006 at 10:12:22 AM EST

---
[ucblockhead is] useless and subhuman
[ Parent ]
I think so. by ambrosen (2.00 / 0) #14 Wed Jun 07, 2006 at 10:17:03 AM EST
Fresh install, same hardware. Maybe it was only user.dat I copied across. I wanted to preserve all my directories without spaces in which I'd managed to set up.

Mind you, Windows is remarkably tolerant of just bunging any old hard drive in to some new hardware, and it detecting everything, maybe restarting a few times, then running just as it was on the old system.

This is entirely unrelated to the fact that I buggered my NTFS MFT the other day. (And I'm still working on recovering the stuff. I think it'll be OK.)

[ Parent ]
Once upon a time by komet (4.00 / 1) #5 Wed Jun 07, 2006 at 05:46:41 AM EST
you could uninstall software by removing the directory it was installed in. What happened to those halcyon days? Why have the software gods forsaken us?

--
<ni> komet: You are functionally illiterate as regards trashy erotica.
IAWTkomet by Breaker (4.00 / 1) #9 Wed Jun 07, 2006 at 07:00:20 AM EST
And plaintext INI files that you could edit easily, instead of these bloated XML files that if you add a single < wrong it blows the entire config instead of just one configuration parameter.


[ Parent ]
A Day in the Life | 14 comments (14 topical, 0 hidden) | Trackback