[Gdal-dev] Proposal for Unified Windows Binaries

[Mateusz Loskot]

Frank Warmerdam wrote:
> Tamas Szekeres wrote:
>> I also have some doubts how to create an unique compilation that is
>>  suitable for all of the applications and the various needs. Can
>> someone confirm that the usage of the different CRT heaps will not 
>> cause memory related problems when compiling the code using
>> different compiler installations. (Is the GDAL C API capable to
>> pass memory segments being allocated and released on different
>> sides?)
> 
> Generally speaking if you use the C API I *think* there should be no
> cross-heap / cross-runtime problems but I'm not 100% sure of this 
> myself.

Right, I wasn't precise in my previous reply.
As long as the user will use the API but not manually free/malloc
objects, then everything should be fine.

> I'm imagining shipping a core built with VC7.1.

Personally, I'm not sure about this choice.
Microsoft has migrated to manifest-based metadata about binary
dependencies and manifest may be required in some situations,
perhaps by .NET 2 and higher etc.

AFAIK, it's better to have manifest, even if it's not used,
than to not to have it.

>> There are some further issues should also be considered, like:
>> 
>> 1. Provide support for WIN64 images
> 
> I'd like to suggest we put off WIN64 native support binaries till we 
> have a good handle on 32bit builds, and till WIN64 is in wider use.
> 
>> 2. Possible issues related to embedding manifests in a
>> multi-compiler environment (VC2003, VC2005)
> 
> I think if we build with VC7.1 we don't need to worry about
> manifests.

If a user will use GDAL with components from Visual Studio 2005, then I
suppose we will need to provide manifest or ship CRT libraries together
with GDAL binaries.

> If we were to build the core with VC8 I think we would want to embed
> the manifests as the makefiles do now.  But I get quite confused
> about how DLL searching works with manifests in the picture.

Manifest is used by loader on Windows to locate and load appropriate
module that an application depends on.
The manifest includes version and architecture details about particular
dependency, which later is used to locate appropriate module in cache
or load it. Also, the concept of manifest is required to support so
called "isolation" of applications, private and shared dependencies, etc.

It's possible to embed manifest inside a binary in RS_MANIFEST resource
block or provide it as a separate file.
Since 2005, *all* binaries have to have manifest included (embedded or
as external file).

Here is long story about it:
http://www.grimes.demon.co.uk/workshops/fusWSThirteen.htm

Cheers
-- 
Mateusz Loskot
http://mateusz.loskot.net