On Tue, Aug 25, 2009 at 7:57 PM, Matthew Toseland<[email protected]> wrote: > On Saturday 22 August 2009 06:33:32 Juiceman wrote: >> On Tue, Aug 11, 2009 at 10:21 PM, Juiceman<[email protected]> wrote: >> > On Sun, Aug 9, 2009 at 8:43 PM, Zero3<[email protected]> 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. _______________________________________________ Devl mailing list [email protected] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
