win32 autopatching
Author
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.
Hi,
this is the way I've solved this problem:
The first thing, my app is doing after start, is sleeping a few seconds (more on that later).
Then it checks for a new version. If there is a new version, it does the following:
- it deletes an eventually present old backup copy (delete appname.exe.sav)
- it renames it's own exe file to the backup-name (rename appname.exe to appname.exe.sav); this is possible, even when windows locks the original application-file
- it copies the new exe-file from the server (to appname.exe)
- it clears up all internal data, so that in the next step it could quit
- it launches the new copied appname.exe and quits itself immediately
Because the new app (appname.exe) starts with sleeping and the old app (appname.exe.sav after renaming) quits immediately after launching the new app, there will be no conflicts between the old and the new app. When the new app begins to do his work the old app has already gone.
Hope, this helps
Seblebrox
this is the way I've solved this problem:
The first thing, my app is doing after start, is sleeping a few seconds (more on that later).
Then it checks for a new version. If there is a new version, it does the following:
- it deletes an eventually present old backup copy (delete appname.exe.sav)
- it renames it's own exe file to the backup-name (rename appname.exe to appname.exe.sav); this is possible, even when windows locks the original application-file
- it copies the new exe-file from the server (to appname.exe)
- it clears up all internal data, so that in the next step it could quit
- it launches the new copied appname.exe and quits itself immediately
Because the new app (appname.exe) starts with sleeping and the old app (appname.exe.sav after renaming) quits immediately after launching the new app, there will be no conflicts between the old and the new app. When the new app begins to do his work the old app has already gone.
Hope, this helps
Seblebrox
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!
You should get an account so I can rate you up!
Author
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):
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;
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;
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
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
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
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
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
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
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
