Installation Failure with Proj.dll entry Problem

[Jacob Delfos]

Frank,

Don't get me wrong, it wasn't my intention to make your life as a developer difficult. I was only trying to help out someone who was stuck (and I did; he mentioned to me that it worked). 

If the dll's are in the same directory as the executable, these will be used rather than those in the system directory. I normally use that approach if I need to avoid a version problem. I don't like to rely on path statements, because I have spent heaps of time on debugging path related problems. In windows, the path environment variable can be a bit unreliable. Applications can modify it when you install them, or write lines to your autoexec.bat file that will overwrite the system path variable (e.g. ultraedit, apple quicktime, etc.....). Or sometimes it downright doesn't work. I think that's why there are so many dll related posts. Whenever I do have an issue, I check whether my dll's are the same version as the original package (as I did suggest), before reporting anything.

Best regards,

Jacob


-----Original Message-----
From: Frank Warmerdam [mailto:warmerdam at pobox.com] 
Sent: 19 October 2004 23:51
To: Jacob Delfos
Cc: MAPSERVER-USERS at LISTS.UMN.EDU
Subject: Re: [UMN_MAPSERVER-USERS] Installation Failure with Proj.dll entry Problem


Jacob Delfos wrote:
> If you want to make sure it is not a problem of the file not being 
> found, then copy your proj.dll file into
> c:\windows\system32
> I always copy all DLL's there, because path statements can get a bit 
> messed up sometimes.
>  
> If the problem still occurs, then double-check you have the correct 
> version of the dll.

Jacob,

Obviously users are in charge of their own machines and can do what they
want, but I would like to go on the record as saying this practice scares
the "heck" out of me.

For instance, I package and distribute OpenEV_FW releases.  I take great care
to provide all required libraries and DLLs in the package.  I carefully set
the PATH environment variable when the package is being used, so that my
DLLs will be used to avoid conflicts.  But if you have a PROJ.DLL in
C:\windows\system32 it will be used in preference to the one I have so
carefully placed at the front of the path and I will end up getting weird
reports of problems I have no chance of being able to correct from my end.

Many DLLs, including stuff like PROJ, and GDAL do not have version
specific names (and anyways people make snapshots between releases) and
so it is very easy for the wrong version of a DLL to get used and to cause
the most annoying sorts of problems.

My point is, folks who dump stuff willy-nilly into windows\system32 should
think twice before reporting problems because it may be a configuration
issue on your side that the software developers or distributors don't
have a fair chance to have avoided.

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    | Geospatial Programmer for Rent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapserver-users/attachments/20041020/e05ed925/attachment.html