Windows. Installing updates and VC versions

[Rod Widdowson]

This is mostly for Scott, but other may have input.

I have just been testing SSPCPP-782 in which we finally give up shipping debug versions of our executables & DLLs in our MSI file.

As it happens I did a test install on a machine which I haven't done much with save update to 2.6.1.4 (I wanted to test against
Apache for a change).  And the updated executable failed to start.

This is because the update has uninstalled the VC10 run time and installed the VC14 runtime (correctly).  But it also decided
against updating the zlib dll.  The file name is the same (zlib_1_2_11.dll) as is the version information inside the file.  So it
didn't think it needed to update the dll.

But the file has changed and hence the executable doesn't start because it cannot file the run time that zlib wants.

This of course is the same for all of our dependency DLLs.  

- With Curl we get lucky because we have decided to garnish the version with a dll name
- With OpenSSL we get lucky because the move to the latest versions of OpenSSL changes the name (plus we add garnish).
- But there are other dlls

I can think of multiple ways of skinning this cat, and none of them are nice

1) We could explicitly change the name of zlib (and any other affected DLLs) for the V3 release just as we have done curl and
OpenSSL.  I suspect that this is the easiest to do, but it is not without a fear factor: The zlib build it currently glued together
with sed and perl to do get the versioning correct and we would need to extend that, plus find some way of injecting the name we
want.  For every affected DLL.

2) We could change the sub revision of the dll and the right thing would happen.  This is the "correct" solution but it would mean
editing the rc file.  Forever.  

As an aside I looked into the windows support for zlib with a view to giving them a patch and quailed because there are 5 rc files,
all slightly different.  The one we use pulls the first three numbers (Major.Minor.Revisions) from the zlib.h file but not the
subrevision (despite there being a suitable #define) the other 4 rc files have the number hard wired and I ain't about to install
VC9 just to test a patch

3) We could change the way that the installer works to uninstall then install.  This would mean that the VC10 zlib.dll would be
uninstalled and then the new one installed.  Unless of course someone else had added a reference to that dll.  I dislike this since
it is a gratuitous change to the installer which will require extensive testing - and I dislike making installer changes at the best
of time.  Also this is a hack to get around our abuse of the version policy.

So unless anyone has a better idea I'll enter a JIRA case to do (1).

/Rod