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. _______________________________________________ Devl mailing list [email protected] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
