On Wednesday 26 August 2009 01:27:18 Juiceman wrote: > 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.
So what you want to do is have an uninstaller for old-plus-systray, and a separate uninstaller for new-including-systray?
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
