Those are good points.. <div><br></div><div>I should have been more clear in that I download the entire exe into memory first (because its only 3mb compressed exe) and then after a full and successful download I do the renaming etc etc :) and then save the file to disk. </div>
<div><br></div><div>Otherwise you are completely right that having a half done exe would be a bad thing :D<br><br><div class="gmail_quote">On Wed, Jan 19, 2011 at 12:23 PM, Paul Heinz <span dir="ltr"><<a href="mailto:paul@accredo.co.nz">paul@accredo.co.nz</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">Kyley wrote:<br>
<br>
> I do it almost the same way..<br>
><br>
> App.exe renames itself to App_old.exe while its running. then<br>
> it downloads app.exe each time app.exe starts it deletes any<br>
> app_old.exe that exist. This way you never need to run a<br>
> different file.. effectively its the same thing.<br>
><br>
> by doing it this way users on a network share always get the<br>
> latest copy, even if people are still running in memory the<br>
> old copy. The Old copy will be deleted as soon as all running<br>
> instances are stopped and someone runs the new version.<br>
<br>
</div>Yes, it's a neat trick. Not many people seem to know that unlike Unix,<br>
whilst you can't delete an open file in Windows (including .exe and<br>
.dll), you can _rename_ them.<br>
<br>
To do the self-update trick, I have seen developers still using .bat (or<br>
.cmd) files to launch their app since you can delete the running<br>
.bat/.cmd file since the command interpreter loads the whole file into<br>
memory and then closes it before execution begins by design. This<br>
behaviour dates to the era of .bat files on floppies which got removed<br>
from the drive.<br>
<br>
I can suggest a few nuances for robustness. We check the timestamp on<br>
startup and download the updated copy to a .new file before doing the<br>
rename process.<br>
<br>
If the download attempt fails, we just skip the update attempt (for now)<br>
and proceed as normal. The update code needs to trap all exceptions<br>
otherwise a bad update can prevent use of the application. Not good.<br>
<br>
If you don't take this precauation, an interrupted download attempt by<br>
one client leaves an unrunnable partial .exe for everyone else and a<br>
spate of support calls. Also not good :-)<br>
<br>
We then delete .old and then rename the running .exe to .old before<br>
renaming .new to .exe. You can use numbered extensions for .old to deal<br>
with the fact that you can't delete the current one since someone is<br>
still running it. This is quite common on TS servers which support lots<br>
of clients.<br>
<br>
I then execute the newly downloaded and renamed .exe which has code to<br>
silently attempt to delete .old files on startup. I also pass a command<br>
line switch to indicate that this is a downloaded respawn.<br>
<br>
I do this to handle the case where for some reason, the timestamps are<br>
misbehaving such that there always seems to be an update available.<br>
Windows networking combined with Samba versions and phase of the moon.<br>
You don't want to livelock downloading and restarting endlessly. Also<br>
not good.<br>
<br>
Finally, often, the .old file(s) are not deletable on the first run<br>
since the new process commonly starts executing and hit the delete<br>
attempt before the old process has shutdown. They're essentially racing<br>
with each other and on dual core machines, the .new process starts<br>
immediately. But there is no harm in attempting to delete the .old<br>
file(s) everytime.<br>
<br>
This is probably more detail on self-updating than anyone wanted to<br>
know, but there you go :-)<br>
<br>
Any logical holes that people can spot in the above approach I'd be very<br>
glad to hear about. Many smart eyeballs makes even nasty bugs shallow!<br>
<br>
Cheers,<br>
<font color="#888888"> Paul.<br>
</font><div><div></div><div class="h5"><br>
_______________________________________________<br>
NZ Borland Developers Group - Delphi mailing list<br>
Post: <a href="mailto:delphi@delphi.org.nz">delphi@delphi.org.nz</a><br>
Admin: <a href="http://delphi.org.nz/mailman/listinfo/delphi" target="_blank">http://delphi.org.nz/mailman/listinfo/delphi</a><br>
Unsubscribe: send an email to <a href="mailto:delphi-request@delphi.org.nz">delphi-request@delphi.org.nz</a> with Subject: unsubscribe<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Kyley Harris<br>Harris Software<br>+64-21-671-821<br>
</div>