[gdal-dev] GDAL 1.5.0 (RC2) Binaries

[Lucena, Ivan]

Howard,

That tool, Performance Monitor is the old File Monitor that Microsoft 
bought and is giving away for free:

"FileMon monitors and displays file system activity on a system in 
real-time. Its advanced capabilities make it a powerful tool for 
exploring the way Windows works, seeing how applications use the files 
and DLLs, or tracking down problems in system or application file 
configurations." 
[http://technet.microsoft.com/en-us/sysinternals/bb896642.aspx]

It might help...

Since any application can change the environment variables at anytime 
during the execution it is hard to know what is been loaded and from 
where. I was luck once to load the GDAL project in VC2003 and run a 
binary commercial application and track the GDAL plug-in loading process 
in debug mode.

It might work too.

Best regards,

Ivan


Howard Butler wrote:
> 
> On Dec 26, 2007, at 11:00 PM, mchapman at texelinc.com wrote:
> 
>> Howard,
>>
>> Thank you very much for that information.
>>
>> So, then I assume that a good client process of gdalxx.dll would 
>> ensure that the dependencies of the gdal plugins are correctly in the 
>> path and would resolve any issues before gdal is loaded?
>>
>>
> 
> I'm not quite sure what you mean by a good client process, but I'll 
> assume you mean an application that embeds GDAL within it.  If it were 
> possible to programatically do something like depends.exe to walk 
> everything, I guess that would be one way to do it.  Does anyone know of 
> code out there that does something like this?  It'd be handy in a number 
> of contexts...
> 
> 
>> Could this be done by removing the plugin dll from the plugin 
>> directory if the dependency path could not be validated?
> 
> Yes, if a plugin dll is not in the anointed directory, GDAL should not 
> attempt to load it.
> 
> Howard
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
> 
>