Kyley wrote: > I do it almost the same way.. > > App.exe renames itself to App_old.exe while its running. then > it downloads app.exe each time app.exe starts it deletes any > app_old.exe that exist. This way you never need to run a > different file.. effectively its the same thing. > > by doing it this way users on a network share always get the > latest copy, even if people are still running in memory the > old copy. The Old copy will be deleted as soon as all running > instances are stopped and someone runs the new version.
Yes, it's a neat trick. Not many people seem to know that unlike Unix, whilst you can't delete an open file in Windows (including .exe and .dll), you can _rename_ them. To do the self-update trick, I have seen developers still using .bat (or .cmd) files to launch their app since you can delete the running .bat/.cmd file since the command interpreter loads the whole file into memory and then closes it before execution begins by design. This behaviour dates to the era of .bat files on floppies which got removed from the drive. I can suggest a few nuances for robustness. We check the timestamp on startup and download the updated copy to a .new file before doing the rename process. If the download attempt fails, we just skip the update attempt (for now) and proceed as normal. The update code needs to trap all exceptions otherwise a bad update can prevent use of the application. Not good. If you don't take this precauation, an interrupted download attempt by one client leaves an unrunnable partial .exe for everyone else and a spate of support calls. Also not good :-) We then delete .old and then rename the running .exe to .old before renaming .new to .exe. You can use numbered extensions for .old to deal with the fact that you can't delete the current one since someone is still running it. This is quite common on TS servers which support lots of clients. I then execute the newly downloaded and renamed .exe which has code to silently attempt to delete .old files on startup. I also pass a command line switch to indicate that this is a downloaded respawn. I do this to handle the case where for some reason, the timestamps are misbehaving such that there always seems to be an update available. Windows networking combined with Samba versions and phase of the moon. You don't want to livelock downloading and restarting endlessly. Also not good. Finally, often, the .old file(s) are not deletable on the first run since the new process commonly starts executing and hit the delete attempt before the old process has shutdown. They're essentially racing with each other and on dual core machines, the .new process starts immediately. But there is no harm in attempting to delete the .old file(s) everytime. This is probably more detail on self-updating than anyone wanted to know, but there you go :-) Any logical holes that people can spot in the above approach I'd be very glad to hear about. Many smart eyeballs makes even nasty bugs shallow! Cheers, Paul. _______________________________________________ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe
