On 2013-11-07 16:12, Benjamin Thaut wrote:

> Woudln't it be necessary to copy the other gtk assets there too? Like
> the fonts etc?

I have no idea. Just give it a try and copy the DLL's. In any case, wouldn't the assets be the same for 32 and 64bit if they are the same version.

-- 
/Jacob Carlborg

On 2013-11-07 21:03, Benjamin Thaut wrote:

> Well it is for me. As the dlls are named the same the 64-bit executable
> attempts to load the 32-bit dll first (because its the first one to be
> found in the PATH)

No flag available for ignoring DLL's of the wrong architecture?

-- 
/Jacob Carlborg

On 11/07/2013 09:02 PM, Benjamin Thaut wrote:
> Am 07.11.2013 20:28, schrieb Mike Wey:
>> On 11/07/2013 06:16 PM, Benjamin Thaut wrote:
>>
>> I don't know how other apps do this, but afaik giving each app there own
>> private copy can still cause problems.
>> If a dll with the same name as the one you are trying to load is already
>> in memory, Windows will use the the one already in memory.
>> When the version thats in memory is to old for the app you are starting
>> it will crash because of the version mismatch.
>>
>
> By "in memory" you mean already loaded into the memory of the currently
> running process?

I would say globally, i vaguely remember having a strange issue because of it years ago. But i can be completely wrong about that.

The MDSN docs just say: "in memory" and don't specify anything beyond that.

> Because all the process of my system use so many different versions of
> zlib1.dll that the entire thing would explode right in my face if that
> statement would apply globally.

-- 
Mike Wey