[Gdal-dev] Release 1.4.0

[Simon Perkins]

On Wed, 15 Nov 2006 10:55:19 -0500, "Frank Warmerdam"
<warmerdam at pobox.com> said:

> But for windows, I can't help but think we should be doing something
> smarter. However, lacking soft links I'm not sure how to get the same
> flexiblity as we have on unix.  I'd like to have windows DLLs with
> names like GDAL140.DLL but I'd also like a way of understanding that
> applications using the GDAL C API can generally use any relatively
> recent GDAL DLL.  Is there a normal way of handling this sort of thing
> on windows?  Is it goig to be a lot of work?

Installed windows applications mostly seem to ship with their own copies
of the shared libraries that they need, and so GDAL is not usually
installed in a central location that can be picked up automatically by
other applications. Developers will likely have a GDAL directory tree
from which the applications they're working on pick up the GDAL headers
and binaries, so they will need to change the library name used in their
application whenever the GDAL version changes. But this is generally not
a huge deal. Having said that, that small deal could be avoided by not
incorporating the version in the GDAL library name.

I believe that the convention of naming windows DLLs with the version
number in the name dates back to the days when it was common for
applications to put installed DLLs into the windows system folder.
Without the version-specific naming scheme, it was possible for one
application to install an older version of a library over a newer one,
and so break any installed applications that depended on features of the
newer library. This is I think the most common version of "DLL Hell". 

Since about Windows 2000 (I think), DLLs have had version numbers
embedded in them, and installers are generally configured to not install
earlier versions of DLLs over earlier ones. This avoids the problem
above, and works fine, as long as libraries are always binary backwards
compatible with earlier versions. But it still breaks when this is not
the case, e.g. due to API changes, behavioral changes, etc). So
libraries still needed to change their names if they were going to
install in the system folder, whenever API changes occur - much as the
soname of linux libraries needs to change in this case.

With Windows XP, and particularly with Visual Studio 2005, things have
evolved a bit, and it now seems to be pretty taboo to install any DLLs
in the system folder. Instead, most apps simply keep their DLLs in their
local application folders. This solves all library compatiblity problems
and eliminates DLL Hell (at the expense of disk space, but that's
cheap), but, for instance, doesn't allow you to fix bugs in GDAL,
install it, and have any applications that depend upon it automatically
pick the new version up. 

There is in fact a way to install a shared version of GDAL in safe way,
using the notion of "shared side-by-side assemblies" and the global
cache. This basically allows multiple versions of the same library to be
installed centrally, and ties applications to specific versions,
avoiding compatibility problems. In addition, you can use "publisher
overrides" if you want to install a bug fix and redirect existing
applications to a new version. However, it's all a bit complicated. By
default different versions are presumed to be incompatible (which is
fairly sensible). You can read all about it at:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwxp/html/sidexsidewinxp.asp

Anyway, all this to say that I think most developers are happy using
private installations of GDAL, so the library name is not a big deal.
I'm happy to leave things as they are...

Sy