On 64-bit Windows, put the DLLs in c:\windows\syswow64\ (not system32)

Oh, any 32-bit program will not ever see "true" system32 anyway. :)

(Hmm, but Explorer is 64 by default, so it will see it right. Ok, you are right then.)

On 64-bit Windows, DLLs for 32-bit processes are loaded from syswow64 instead of system32; system32 is (despite the name) for 64-bit DLLs. It's confusing but considering history it makes some sense :P

Of course you can see both directories if you look via their actual paths, but that's unrelated. 32-bit processes can see true system32 too. But when linking to a DLL it's in principle Windows who finds the DLL file from a name without path.

All this applies to native C DLLs.

It's also possible to place a DLL in the same folder as the program that needs it, which also allows for different programs that use incompatible versions of the same DLL name. This applies to .NET DLLs as well as C ones, but not COM ones.

Anyway neither COM nor .NET DLLs go in the Windows system directory for global use, only C ones.

Well, this part is not right in my experience. It's limited to servers though, as my first true desktop Win64 is only one year here. :)

For servers, any 32-bit process automatically redirected to syswow64 in any case when it tried to access system32. I can _try_ to access system32, but in result will land in syswow64 silently. It was very confusing for me when I tried 32-bit file managers on win64, because I never was able to found 'hosts' (that exists only in real system32, of course).

Well you seem to be right, I've checked in my normal Windows 8.1. I never noticed because 32-bit processes can see both system32 and syswow64, and you can seem to go to system32 as well as syswow64, by those separate names; but in both cases you get the same files, from syswow64. Sneaky. I thought it was only when loading DLLs or relying on environment variables or in the registry. Thanks for the info.