Working through the details of the update mechanism.

This is one of more difficult parts of the application, even though on the surface it looks uncomplicated. If we run the installer and it detects that the app is already installed, it should just update the installation. How hard could it be?

Let's see.

If the program is not running, then it's indeed a simple matter of replacing the program file with a newer version. The fun starts if the program is running.

On Windows, running a program locks its file, preventing any changes from being made to it. This is not required per se and there are operating systems that don't do this. There are also custom PE loaders for Windows that can take an executable and create a running process out of it without any locking fuss. For example, bo2k could do that back in 1999. See its source code for details if interested.

To complicate matters, there might be more than one process running off the same executable. For example, if several users are logged into a Windows box and each runs a copy of a program.

Therefore, the first order of business for any installer is to shut down all running instances of the program. A well-behaved installer should also restart all these instances after it's done with updating.

The shutting down part is not a big deal. There's more than one way to do this and all of them are fairly straight-forward.

It's the restarting that is contrived.

Not only program instances may be running under different user accounts, they may also be running with custom command-line arguments, as Administrators or system services. Restarting this bundle of joy is not an envious task.

Here's how Bvckup works around this mess.

Every Bvckup executable has a unique Global event associated with it. The event is created by the first instance of the program when it's launched and it is opened by all other instances.

The name of the event includes the file ID of the executable file. This groups running instances by the file they are using, because, after all, the installer is interested in a specific executable and nothing else.

For example, the following is an event name used by the Bvckup installation on my development box -


With this in place, the installer starts off by signaling the event.

In response, each running instance makes a temporary copy of the executable file and starts it in a special "wait for the update to finish" mode, passing it all the context and details required to correctly restart later on.

And then it exits.

This temporary process is referred to as a relauncher and it merely spins there waiting for the Update event to become unsignaled.

Meanwhile the installer waits for the program file to become unlocked. Once all running instances replace themselves with the relaunchers, the executable frees up and the installer proceeds with the update. Then, once it's done, it clears the "update" event and exits.

This releases the relaunchers, they restart program instances (now using the actual executable), clean up after themselves and ta-da - the update is completed.

* Techincally, instead of adding a special "relauncher" mode to the program it's possible just to have a small standalone relauncher program.

It comes down to a matter of taste. Some people don't like to spawn from temporary executables, and I like to keep my file count to a bare minimum. To each his own.
Made by IO Bureau in Switzerland

Updates Newsletter
Blog & RSS
Follow Twitter
Miscellanea Press kit
Company Imprint

Legal Terms