Re: [Firebird-devel] Firebird version and Interbase/third-party t

[David R. R. <ibi...@ma...>]

> David, is there anything other version checking other than dll
versions
> that are specifically used in the install?

The core philosophy in installation scripts is that you never replease
an existing file with a file that is older than the one that already
exists on the system.  Just about all scripts are built with this
assumption.  This is typically done by using the version resource
information in the executable or DLL file.  Sometimes it is done using
the date/time, but that method is very unreliable because people (like
the InterBase install script creators at Borland did with msvcrt.dll)
end up setting the date/time stamp of all files, including ones that
they did not create, to the current date.

Existing InterBase installations have a version of 6.x or 5.x or even
4.x, Firebird using the exact same files, but will be version 1.x.  Even
if you uninstall 6.x prior installing Firebird, there may be residual
files left behind because of the ShareDLLs registry settings for the
UseCount (i.e. uninstallers won't delete shared files unless
UseCount=1).  This means that the only way to force a Firebird 1.0
installation to work properly is to set all of the files to always
overwrite the existing file.  This means that each and every file that
is referenced in the script will need to have the file option set to
always replace the existing file.  This means that if there is a
Firebird 1.1 update, the 1.0 script will always overwrite the 1.1
patched files with 1.0.

I guess my problem is that the whole thing is counter to the basic
philosophy of never replacing a file with an older version where the
version is defined by the version resource.  With this 1.x approach for
FB, the whole version concept goes out the window.

> >It also means I'm most likely going to have to make a
> >Borland specific script and a Firebird specific script.  :(

> I think that's probably going to happen eventually anyway, the
interbase
> one will remain much the same, but if we change dll names, registry
> settings etc we will evolve and change a bit I suspect, are they
complex
> to maintain as seperate?

Obviously, this will all be a non-issue once the files are renamed and
FB and IB can coexist on the same box.  However, I was hoping to not
have to do separate scripts right now since 95% of the script is the
same (especially since the file name are all the same).

David R.