[gdal-dev] The proj.dll mistery

[Frank Warmerdam]

Andrew Brooks wrote:
> On Tue, 01 Jul 2008 00:55:28 +0100, Martin Chapman <mchapman at texelinc.com> wrote:
> 
>> I apologize that VantagePoint caused a problem for you.  We will make the
>> fix to the install and get the proj.dll out of the system32 directory.
> 
> There's nothing wrong with installing a shared library into a shared
> directory.  But it's unforgivable to replace an existing shared library
> with an older version!  Is it difficult to check version numbers?

Folks,

Well, I'm not sure it is all that easy to check versions.  I don't believe
I embed version information in PROJ.DLL in a microsoft windows specific
fashion.

Also, I've been producing windows software for a decade and a half and
I still don't know how to check DLL versions and compare them.  I know
there is a way, but I've never investigated it.

I generally avoid putting stuff in \windows\system32 because it is so
hard to avoid interfering with something else, but I am also frequently
frustrated when older DLLs in \windows\system32 get picked up ahead of
the ones I provide in my custom path.  I frequently have this problem
with MrSID and ECW DLLs for instance.  There are aspects of this problem
that I blame squarely on Microsoft for their system architecture.   It is
still too hard to distribute an application and ensure it uses my own
DLLs in preference to the ones in the system directory.

For FWTools my approach was actually to build most of the DLLs I *can*
build myself, and to append _fw in the dll name to avoid conflicts.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org