# How to make patch-able apps



## xbonez (Feb 16, 2011)

I'm wondering, if I write a C# app, and then distribute the .exe to people, can I patch this down the line by distributing another exe that, when run, makes changes to the initial app? I'm guessing not.

What are the pre-requisites to make a program patchable?


----------



## W1zzard (Feb 16, 2011)

haven't seen anyone patch EXEs for years, just replace them.

you can patch your data files, use any method you can think of.


----------



## xbonez (Feb 16, 2011)

I guess if it a simple program its easier to replace the exe. but what about larger, more complex programs with bugs in the source code? Say, for example, a game has a bug where under certain conditions the players health counter doesn't get updated making him invincible. Something like that would require a change to the source code. How are such updates pushed?


----------



## Kreij (Feb 16, 2011)

Most game apps are not that large, it's the texture, game data, audio etc. that make the total downloads huge.
Split code off into seperate DLLs, so if something needs to be fixed in say, an AI routine, you only need to push the AI DLL.
Go into c:\Program Files\<some game> and see how some of the big game studios do it.
*Just make sure you have a good plan for regression testing.*

Years ago, lots of programs used to inject code into exe's and library files, but since users almost always have some type of broadband connection, it's a lot easier just to have them re-download a new file than to go through the trouble of writing the code to modify an existing one.


----------



## <<Onafets>> (Feb 23, 2011)

Kreij said:


> Most game apps are not that large, it's the texture, game data, audio etc. that make the total downloads huge.
> Split code off into seperate DLLs, so if something needs to be fixed in say, an AI routine, you only need to push the AI DLL.
> Go into c:\Program Files\<some game> and see how some of the big game studios do it.
> *Just make sure you have a good plan for regression testing.*
> ...



That would work alot better, but say if the update is made through the program (via a button for example) wouldn't the program need to be closed before the executable/dll could be over written?


----------



## Bundy (Feb 23, 2011)

xbonez said:


> I guess if it a simple program its easier to replace the exe. but what about larger, more complex programs with bugs in the source code? Say, for example, a game has a bug where under certain conditions the players health counter doesn't get updated making him invincible. Something like that would require a change to the source code. How are such updates pushed?



Wouldn't it seem that the patcher was behaving a lot like a virus?

I do agree with your concerns though, program updates are not getting any smaller these days and much of it is unnecessary repetition of good code.


----------



## DigitalUK (Feb 23, 2011)

most exe are encrypted these days for protection so you cant just modify without breaking the key, with the software i do i usually make a small installer with exe (files to be updated), click the update button as soon as the update installer has been downloaded and excuted i kill the app so the installer can update.


----------



## Mussels (Feb 23, 2011)

xbonez said:


> I guess if it a simple program its easier to replace the exe. but what about larger, more complex programs with bugs in the source code? Say, for example, a game has a bug where under certain conditions the players health counter doesn't get updated making him invincible. Something like that would require a change to the source code. How are such updates pushed?



because they dont do it in the exe, they use external files and merely update those.



<<Onafets>> said:


> That would work alot better, but say if the update is made through the program (via a button for example) wouldn't the program need to be closed before the executable/dll could be over written?



installer end tasks the process of the program before updating, then restarts it. easy.


----------



## <<Onafets>> (Feb 23, 2011)

But how does it update if the program is no longer running?


----------



## DigitalUK (Feb 23, 2011)

because the installer is a seperate exe.

crude way of doing it, your app checks a file online for latest version of your app and compares it to the version number running, if update is need your app downloads the update installer, once the update has finished downloading your app runs the update installer and closes your main app. update installer runs all updated restart your app.


----------



## Mussels (Feb 23, 2011)

DigitalUK said:


> because the installer is a seperate exe.
> 
> crude way of doing it, your app checks a file online for latest version of your app and compares it to the version number running, if update is need your app downloads the update installer, once the update has finished downloading your app runs the update installer and closes your main app. update installer runs all updated restart your app.



ding. pretty straightforward.

the only thing leftover there, would be the installer deleting itself when its done.


----------



## Kreij (Feb 23, 2011)

You really want to do that from an updater not an installer. Updater should not delete itself as it's soul purpose in life is to sit around and check for the availability of a new version.

So ...  
Updater downloads the installer. 
Updater terminates the app and runs the installer for the new version.
The installer does it's thing and then cleans up after itself and exits.
Updater relaunches the app, deletes the installer and goes back to sleep occasionally checking for new versions.


----------



## Mussels (Feb 23, 2011)

yeah but that adds another .exe into the mix, might as well add the update checker into the main .exe


if the main .exe checks for updates on startup or something like GPU-Z does, when one is found and the user clicks yes it triggers the download for the new installer.

new installer runs, closes original program, updates the files, restarts program and deletets itself as it was a once off updater.

new, updated .exe runs and on each consecutive startup, checks again for a new update/installer to download and repeat.


i'd find it a much cleaner setup to have just one .exe running, not the main program and a seperate updater.


(if thats even what you meant, its 2am here and i'm about to sleepy)


----------



## Kreij (Feb 23, 2011)

There are several ways of doing it, but if the installer is running as a service (or started up when the OS starts) then it will do its job whether the main app is running or not.


----------



## DigitalUK (Feb 23, 2011)

the way i did it was the main app cleans up after install, once update has been set off, leave a flag somewhere to say update just been run the app then deletes the temp files on start up, update installer etc. so everything is handled in the main app.


----------



## Mussels (Feb 23, 2011)

Kreij said:


> There are several ways of doing it, but if the installer is running as a service (or started up when the OS starts) then it will do its job whether the main app is running or not.



eh, i dont like that idea. more things running in the background means more things to break, slow down a PC, etc.


something that runs only when needed and cleans up after itself sounds nicer.


----------



## Kreij (Feb 23, 2011)

I agree with you in concept, but an updater could be very light weight and use almost no resources if coded well. 
Having an updater launch as a seperate process (with no specific owner) when the app starts *is *another way. If no updates are found it terminates and does not run again until the app is launched again.
It's really a call the developer has to make based on what the updater needs to do.


----------



## DigitalUK (Feb 23, 2011)

both ways will work fine. i just thought for myself i like to have as little overheads as possible and for the end user plus you could have problems with firewalls and stuff where the person has allowed the main exe to access the net but updater gets blocked also what happens if the updater needs updating.


----------



## Mussels (Feb 23, 2011)

mmm, its a choice between two .exe's (even temporarily) vs one.

the seperate updater that runs and closes makes the main app smaller and lighter on resources, but also means a second .exe antiviruses and firewalls have to deal with.


all this programming stuff gets complicated, doesnt it XD i cant code my way out of a DOS box, but i know the basics at least.


----------

