🔒 Locked

win32 autopatching

Started by bjogio Sep 14, 2005 at 2:48 AM 5 replies 1.1k views

Original Post

Sep 14, 2005 at 2:48 AM

Hi gamedev(elopers) is there such a way to do autopatching in win32? Let's explain better: I have a standard PE exe file and I want to let the user download the "patch" from internet in a clear way. Now I already know how to download, patch, change version, server handshake, security etc. and actually I made it through a little external executable that do all the work and rewrite my main exe. But there's a way to handle this without helping from an external program? I mean: there is a way to an executable to rewrite itself according to the new data obtained from the net? Basically now I know that I cannot for several reason: 1) the file is "in use" 2) I cannot rewrite code flow without terrible consequence Windows loader open the file and keep it open during all the execution time? Am I wrong about this last sentence? If it's in this way why in hell the kernel keep it open? As far as I can see all commercial games that have autopatch use an exernal exe to update the main file (and resource files). Thanks in advance and, as usual, apologize for my orrible english.

iMalc

Sep 14, 2005 at 3:16 AM

That sounds like an excellent solution to me. I suspect that it's what a number of products do at present too.
You should get an account so I can rate you up!

bjogio

Sep 14, 2005 at 4:30 AM

uhm I didn't know the rename trick, very good indeed!
Let me understand better, your application sleep a bit in order to let the old application to quit well? what you think about using mutex? I mean (pseudo-code):

int main(){   while(open_mutex("AppName") == already_opened)   {      //do here a check for possible infinite loop      //the "brother" application can hang   }   //here the brother application is exited   if(new_version())   {      rename();      copy_file();      release_resource();      launch_application();      close_mutex(); //we communicate that we have exited      return 0;   }   do_game_stuff();   close_mutex();}

I think that it can functions. But a little sleep() in while loop can help with very fast computer. We can have a context-switch here:
close_mutex();
//here
return 0;

Seblebrox

Sep 14, 2005 at 5:53 AM

Finally I found my very old account - as you can see, I'm not a very active gamdevnet-poster.

Anyway...

I've to admit that my c/c++-experience is very rare. At the job I'm working with VB to satisfy our users and my collegues and at home my children are eating up the remaining time... I don't know very much about mutex - not to say anything.

My app is sleeping to ensure that the old instance doesn't lock any external resources (graphics, game data (or in my case, databases)) nor will modify them when the new instance begins to access them.

So if close_mutex("AppName") sets some kind of flag, indication that the app "AppName" is in it's "hot phase" and close_mutex clears that flag this should of course also work fine (and may be a little bit more elegant: not waiting some time and hoping that the old instance is ready then, but waiting for a signal from the old instance ).

Good luck,
Seblebrox

nmi

Sep 14, 2005 at 11:50 AM

Just an idea:
If the new app deletes the old apps file (the .sav), or at least tries to delete, and will only continue if the .sav does not exist anymore, this might prevent what you solved with sleep(). Just an idea, I don't know if it works.

Another thing I want to mention when using such update techniques. If you have a personal firewall installed, it will popup a warning message that your application file has changed. This can be annoying. Another technique I've seen (in Magic Online) is, that during an update a new exe is created, which is then started by the main program. In the end there will be many exes (like magic12345.exe, magic73541.exe, etc., at least in the firewall software).

Another solution to create an autopatching software:
* the main.exe loads a dll at runtime (may patch it before) via LoadLibrary and GetProcAddress
* the loaded dll contains the actual application, it may also (statically) link to other dlls

Guimo

Sep 14, 2005 at 11:56 AM

Hi,
We take a simpler approach. We have a launcher that checks the latest EXE file, if a newer version is available, it downloads it along with resources required (list is in the FTP). After that the launcher runs the EXE and ends. For security, the launcher uses a code so the EXE can't be run alone, only with the patcher. For better results we pack all using Molebox Pro.

Luck!
Guimo

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.