Hi, K.E.Jones at bton.ac.uk wrote: > Hi Folks, > > I appreciate this would be a massive "behaviour" change for WPKG but it could probably be designed to be settable via command line or config.xml as a switchable behaviour. Let's analyze the request. > Seeing as WPKG already scans the registry for Uninstall keys to make checks, would it not make sense to assume that they are used if an uninstall element isn't supplied? They are most likely to contain command lines for uninstalls. WPKG is designed to handle various types of packages. Lots of packages are not even verified using the "uninstall" type check. However you're right that in case (and just in this case) there is an uninstall check specified WPKG might eventually read these information from there. Unfortunately there are a few problems here: 1. As already mentioned not all packages are using uninstall checks and therefore WPKG does not know to which uninstall entry it should refer to. 2. In some cases I even use uninstall checks when the package is not directly related to the uninstall entry I am referring to. For example I use QuickTime Alternative. I defined two uninstall checks for "Quicktime Alternative" and "Quicktime" (the original one), both checks used within an OR logical-connection. So if a user has the "real" quicktime installed, this yields true for my "quicktime" package. In such case WPKG could not know which package (the package refers to two uninstall entries) should actually be removed. As a result I think WPKG should never use the information provided in checks. Instead the package definition could probably be enhanced to provide an attribute to specify the associated uninstall entry. 3. Given the case described in (2) above there is a further problem that future WPKG versions will support wildcard/regex matches within the uninstall string matching. In such case the reference to the uninstall entry might match multiple entries. So WPKG would have to try removing all of them which could also lead to unexpected/surprising results. 4. This is a very important point. I think the usage of such "automatic uninstall string detection" will be very very limited. The uninstall entry within the registry sometimes provides an "UninstallString" string. However it is usually NOT silent - which means it is useless for WPKG. In some rare (unfortunately very rare) cases there is a value for "QuietUninstallString" too. This command usually uninstalls the program silently. Unfortunately I already discovered some applications where even the QuietUninstallString is not silent. So anyway an administrator will have to verify the contents very carefully. 5. Some administrators (including me) are using packages where the uninstall command is not defined within the package definition on purpose. I do this sometimes because it makes no sense to remove the package later on. Even if I remove it from WPKG. So I just leave it on the system. Of course in such case one might omit the reference to the uninstall information as proposed in (2). > It would certainly simplify package definitions. See above. In most cases it will not be possible to read proper uninstall information from the registry as almost no program provides correct silent uninstall commands. However I discovered that some uninstall commands (as found within the "UninstallString" string within the registry) can be made silent when adding some parameters. Windows installer packages (msiexec) usually work silently if "/qn" is added. NSIS installers usually provide an uninstaller helper exe file stored within the install directory which can be called using the "/S" switch. But this does not always make them to work silent. So probably an implementation could look as follows: - WPKG checks if uninstall commands are provided. If yes, then it executes them and exits. If not, read on... - WPKG reads the optional attribute which specifies the associated uninstall entry. - WPKG looks up the "QuietUninstallString" entry and executes it. - If no QuietUninstallString is available WPKG stops to execute any further commands unless one more attribute like uninstallSilentSwitch="/qn" is defined within the package definition. If it is specified, then it reads the "UninstallString" string (non-silent) and adds the parameter as specified within the uninstallSilentSwitch. Hopefully this initiates a really silent uninstall. In general I have the feeling that this could be useful for a very very limited amount of packages. But nevertheless I think in some exotic cases it could be useful. Adobe Reader could be one of them I think as it uses an MSI uninstall string as follows: UninstallString="MsiExec.exe /I{AC76BA86-7AD7-1033-7B44-A90000000001}" Unfortunately the UID used changes on each release. So an administrator would have to update it each time. Given the proposal above an administrator could omit the uninstall string, define "Adobe Reader.*" as the uninstall entry reference and a uninstallSilentSwitch="/qn" switch. So on further updates there is no need to read and update the UID within the uninstall command definition on the package. As you can see Adobe Reader is also one of them NOT providing a QuietUninstallString entry within the registry. > I know I'm being naïve and missing something here ? Maybe some documented future plans or something but I've trawled through the code and can't see where the keys are used anywhere in the install/uninstall process (in 1.1.0-M6 so I thought I'd mention it). It's good to ask naive questions. This gives some hints to think about. So now I thought about and gave some hints. As you can see it is not exactly as easy as you might have thought. So you're right, the UninstallString/QuietUninstallString entries are not yet used at all. > It just seemed like a natural behaviour that might also assist zombie handling. And here I have some concerns about. I am not sure if it really helps or if it could be even more misleading. The administrator might think that he does not have to provide proper uninstall commands for each software package. Unfortunately the automatic uninstallation will probably work for 2 out of 100 packages which provide a SilentUninstallString. For all others it will fail - or require an additional switch to be specified. If the switch is wrong or simply the uninstaller does not really work silently it might lead to unexpected behavior and might be hard to debug. For example - try to create an NSIS based installer/uninstaller. The /S switch just sets a property - you have to read that property manually to act accordingly (not asking for any user interaction). If you do a mistake your installer will not be silent. A good (or in that case very bad) example is TortoiseCVS. It claims to be silent but on Vista-64 it displays a prompt to confirm that the software is not supported on this operating system - even if they claim that it is fully 64-bit compatible since a few versions. So somebody simply did not remove this check/warning. And yes, it even appears if you use the silent switch properly. > PS: I might have a few bugs to submit shortly. It's been mad here and I'm way behind all the stuff I'd *like* to do :-) Feel free to commit the bugs to bugzilla - it's easier to track them there. I try to find some spare time to continue wpkg.js development/enhancement. br, Rainer |