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?
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
