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
