Re: [GD-General] Multifile atomic updates

[Colin F. <cp...@ea...>]

I suggest the following:

MAKE YOUR "MAIN" APP A "LAUNCHER", not the 
actual application.

For example, have a root directory for your
application:

  c:\app

Such that you have your friendly app icon
and name in there:

  c:\app\happy.exe

This is the only binary in the directory, and this
executable is the one specified by any shortcuts
on the desktop and the "Start menu".

But this app is just a simple Win32 app that is
just WinMain() with a call to CreateProcess()
or system() and some extra logic.

Okay, your real application, with associated DLLs,
etc, is in a sub-directory:

  c:\app\ver2003aug

Like the following:

  c:\app\ver2003aug\happyv2003aug.exe
  c:\app\ver2003aug\happyv2003aug.dll
  c:\app\ver2003aug\ijl_v2003aug.dll
  c:\app\ver2003aug\manifest_v2003aug.bin

If you patch your application, you basically do 
whatever reckless procedure suits you, resulting
in a totally new version directory:

  c:\app\ver2004jan

Like the following:

  c:\app\ver2004jan\happyv2004jan.exe
  c:\app\ver2004jan\happyv2004jan.dll
  c:\app\ver2004jan\ijl_v2004jan.dll
  c:\app\ver2003aug\manifest_v2004jan.bin

Okay, anything bad can happen during initial
installation or patching!  If the initial installation
TOTALLY fails, the launcher app won't even be available.
If the tiny launcher app was installed, but nothing
else, this won't lead to any craziness.  And any 
additional success / corruption during the copying
or patching of files, on a continuum, will never be
 a problem.

The launcher searches all sub-directories for
manifest_*.bin files.  Any such file that is not
internally consistent (i.e., matches its own stated
hash code within the file) is rejected.  Thus,
we have a list of candidate application versions.
We can sort from newest to oldest.  We consider 
the newest manifest first.

We look at the list of all files mentioned in 
the manifest, and we verify the existence of
each file and the recorded hash code.  If all
files exist AND match all recorded hash codes,
then we execute the main application as a new
process.  The end!

The updater always creates new subdirectories,
and the main application NEVER changes.  There
are no "state" files recording the progress of
updates or installations or "latest version",
etc.  The launcher actively decides which version
among the completely correct versions is the
latest.

The beauty of this scheme, depending on how 
difficult it is to hack your manifest_*.bin 
file format, is that you get some protection
against cracks or random corruption.  Also, 
you will be 100% sure of all file versions!
All files will be consistent, otherwise you
will not run.

Furthermore, the launcher app can report 
corruption, or even do updates itself, and
make the user aware of available versions.
Perhaps it would be useful for the user to
have the ability to select versions, for
testing, etc.

You can give the user the option of removing
old versions.  But the great thing is that 
you can always insure that at least one 
working version exists (assuming the initial
install was successful).  You will never 
execute a corrupt version (of the EXE, 
associated DLLS, or even data if you choose
to verify the data, too).  Disk space may
be an issue, especially when patching huge 
files, but I think giving the user the
option of removing old versions (after both
old and new versions have been fully verified)
will conserve disk space to any desired level.

Well, this scheme seems so simple and appealing
that I'm sure it is very common!  (I can't 
possibly have an original idea...)

--- Colin

cp...@ea...