Redistribution of the shared C runtime component in Visual C++

There have been a couple of issues related to the CRT deployment with the MapServer and GDAL binary packages causing the application to fail to run properly, so you might have to keep a couple of things in mind when deploying your application on the target computer. Most of these issues are documented in the related MS articles so refer to these documents for the details.

1. Mixing dll-s compiled with different compilers/ CRT dependencies

This scenario is not supported by Microsoft and you should avoid this according to the following article: Potential Errors Passing CRT Objects Across DLL Boundaries
"When you pass C Run-time (CRT) objects such as file handles, locales, and environment variables into or out of a DLL (function calls across the DLL boundary), unexpected behavior can occur if the DLL, as well as the files calling into the DLL, use different copies of the CRT libraries.
A related problem can occur when you allocate memory (either explicitly with new or malloc, or implicitly with strdup, strstreambuf::str, and so on) and then pass a pointer across a DLL boundary to be freed. This can cause a memory access violation or heap corruption if the DLL and its users use different copies of the CRT libraries." This issue not necessarily cause problems when each dll takes the responsibility to de-allocate the memory it has been allocated within the same dll or executable. However we cannot be certain about this for each dlls deployed along with the MapServer and GDAL binary packages, but we should keep this danger out of the door as the packages have been compiled the with the same compiler and CRT setting (/MD). Just make sure you won't mix the dll-s from different packages within your deployment.

2. Expected locations of the CRT redistributables

"When you build an application in Microsoft Visual Studio, and the application uses the C run-time libraries (CRT), distribute the appropriate CRT DLL from the following list with your application:

• Msvcr100.dll/Msvcp100.dll for Microsoft Visual C++ 2010
• Msvcr90.dll/Msvcp90.dll for Microsoft Visual C++ 2008
• Msvcr80.dll/Msvcp80.dll for Microsoft Visual C++ 2005
• Msvcr71.dll/Msvcp71.dll for Microsoft Visual C++ .NET 2003 with the Microsoft .NET Framework 1.1

For Microsoft Visual C++ .NET 2003, you should install the CRT DLLs into your application program files directory. You should not install these files into the Windows system directories. For Msvcr80.dll and for Msvcr90.dll, you should install the CRT as Windows side-by-side assemblies." For more information see KB326922 and Redistributing Visual C++ Files. According to the suggestions above I've copied the msvcrt71 dll-s in the packages compiled with MSVC2003. With regards to the MSVC2005/2008 packages you should probably install the corresponding Visual C++ redistributable (vcredist_) package (or incorporate the msm module in your application installer). Make sure to install the package for your desired platform/architecture (x86 or x64)

Microsoft Visual C++ 2005 Redistributable Package (x86)

Microsoft Visual C++ 2005 Redistributable Package (x64)

Microsoft Visual C++ 2008 Redistributable Package (x86)

Microsoft Visual C++ 2008 Redistributable Package (x64)

3. Application manifests

Upon establishing the option of the side-by-side assembly cache (as of Win2003 Server and Windows XP) the binaries (dll-s or executables) should declare their (CRT) dependencies in the application manifest file. Without this declaration the application is a candidate to have the following error: C Run-Time Error R6034. "An application manifest is an XML file that describes and identifies the shared and private side-by-side assemblies that an application should bind to at run time. These should be the same assembly versions that were used to test the application. Application manifests may also describe metadata for files that are private to the application. Application manifests should be included as a resource in the application's EXE file or DLL." Fortunately the dlls and executables in the MapServer and GDAL binary packages contain these manifests embedded as a resource in the binary files (for MSVC2005/2008). This is not an issue with the packages build with MSVC2003 where the CRT implementation is located is the application directory (see #2 above) and not in the shared assembly cache.
Note: For some reason with Visual Studio 2010 Microsoft has reverted the behaviour to VS2003 and no manifests are generated by default. In these cases the CRT dll-s should be installed along with the applications.

4. Licensing issues

In general you should have a valid license for a "VC.NET 2003" product to be able to redistribute msvcr71.dll, please refer to the redist.txt file in your "Visual" product installation folder which files are allowed to be redistributed. This is not the case with the vcredist_ packages (for VS2005/2008) which are allowed to be installed on a per-user basis within the terms of the corresponding EULA.

libcurl security vulnerability is fixed in the recent release (7.20.0)

libcurl 7.20.0 is released by fixing a vulnerability described in Security Advisory February 9 2010 . Maintainers of the binary distributions are suggested to take one of the following actions as soon as possible:

A - Upgrade to curl and libcurl 7.20.0
B - Apply this patch and rebuild
C - Disable automatic content encoding decompression in your application
D - Rebuild curl without zlib support
E - change your code to use 4*CURL_MAX_WRITE_SIZE for buffer sizes

GDAL 1.7 latest fixes are available for testing

The GDAL 1.7 branch have now been added to the Windows builders providing ready to use daily stapshots of the Windows binaries for being up-to-date with all the recent changes. These packages should contain the fixes in GDAL since the latest release of 1.7.0 (2010/01/19) including the fix for the issue with the HFA driver which is considered as a blocker, and validates a new GDAL release (version 1.7.1) within a couple of days.