On Wed, Aug 26, 2009 at 10:54 AM, Matthew Toseland<toad at amphibian.dyndns.org> wrote: > On Wednesday 26 August 2009 01:27:18 Juiceman wrote: >> On Tue, Aug 25, 2009 at 7:57 PM, Matthew >> Toseland<toad at amphibian.dyndns.org> wrote: >> > On Saturday 22 August 2009 06:33:32 Juiceman wrote: >> >> On Tue, Aug 11, 2009 at 10:21 PM, Juiceman<juiceman69 at gmail.com> wrote: >> >> > On Sun, Aug 9, 2009 at 8:43 PM, Zero3<zero3 at zerosplayground.dk> >> >> > wrote: >> >> >> I just realized that we have a slight problem with offering to install >> >> >> the tray manager through update.cmd. >> >> >> >> >> >> Users who install the tray manager in this way will have problems >> >> >> uninstalling. Their uninstaller won't be aware of the tray manager, and >> >> >> will therefore not shut it down before trying to delete the >> >> >> installation >> >> >> directory. As the tray manager is executed from within that directory >> >> >> and Windows doesn't allow deletion of a running executable, the >> >> >> uninstaller will throw an "could not delete files" error. >> >> >> >> >> >> The error box will offer to retry, but the user probably won't realize >> >> >> that he needs to manually shut down the tray manager first. >> >> >> >> >> >> Possible solutions: >> >> >> >> >> >> 1) Don't install the tray manager through update.cmd. Users will have >> >> >> to >> >> >> reinstall to get the tray icon. Cons: We are leaving our current user >> >> >> base behind (IMHO: very bad idea) >> >> >> >> >> >> 2) Warn user (upon update.cmd installation) to manually close it down >> >> >> before uninstalling. Cons: The user will probably forget about it and >> >> >> be >> >> >> just as lost when he finally uninstalls. (IMHO: not a proper fix) >> >> >> >> >> >> 3) Update the uninstaller in update.cmd as well. This raises the core >> >> >> issue: That Windows installations soon will have different layout >> >> >> because of the recent change from running the service under a custom >> >> >> user to running under a standardized service user. That gives us 2 >> >> >> possibilities: >> >> >> >> >> >> 3.a) Add backward compatibility to the uninstaller. Cons: Will be a >> >> >> hell >> >> >> to maintain an uninstaller that has to support all previous >> >> >> installation >> >> >> layouts. The recent service user change has resulted in significant >> >> >> changes to it already. (IMHO: an acceptable work-around, but is a PITA >> >> >> to maintain in the long run) >> >> >> >> >> >> 3.b) Update the whole installation in update.cmd. This mainly involves >> >> >> moving current installations away from the custom user and cleaning up >> >> >> after the mess. Cons: Will require some work, and will require either >> >> >> an >> >> >> UAC escalation helper executable for update.cmd or porting update.cmd >> >> >> to >> >> >> real code that can escalate itself. (IMHO: the optimal solution >> >> >> long-term) >> >> >> >> >> >> Anyone? >> >> >> >> >> >> Juiceman, what are your thoughts on this? You are the update.cmd wiz. >> >> >> >> >> >> - Zero3 >> >> > >> >> > There is no easy answer. ?We don't want to leave users behind but we >> >> > can't maintain backwards compatibility. >> >> > 3a) ?and I can have update.cmd download a version for these older >> >> > installs. >> >> > >> >> > As far as migrating older installs, UAC does present problems. ?I >> >> > guess if you could make an UAC escalation helper to boost update.cmd >> >> > that could work. >> >> > >> >> > Regarding porting update.cmd to real code, I could try to learn AHK >> >> >> >> I have started looking into AHK, it seems fairly easy. ?I already have >> >> a UAC escalation helper figured out. >> > >> > What is the status of this? I understand it is the main thing preventing >> > us from releasing the new installer? Have you decided to go with solution >> > 3b? >> >> The sticking point is with old installations, not new. ?As far as I >> know this can be handled in the update.cmd (if we choose to offer >> freenettray.exe we need to include a modified uninstaller.) ?Just make >> sure to use the update.cmd I just pushed a few minutes ago. > > So what you want to do is have an uninstaller for old-plus-systray, and a > separate uninstaller for new-including-systray?
Yes, well I can have the update script migrate relatively recent installs (ones with start.exe and with the custom freenet user) to the current way of doing things, then either have a separate uninstaller or the latest uninstaller if it is compatible. Either way, this is resolvable and won't even apply unless the user runs the update script in which case we can do the migration. I should have the new update script using AHK finished sometime in the coming week, barring real life.
