Mixing 32 and 64 bit DLLs

[groupw_bench]

My problem is trying to run IVF-compiled 32 and 64 bit executables and/or DLLs on the same machine.

My project consists of an executable program and several DLLs, all compiled with IVF. Another 32 bit program starts the Fortran executable and calls various functions in the DLLs. The Fortran executable is compiled in 32 and 64 bit versions and the appropriate one is installed on the target machine. There's no advantage to making separate 32 and 64 bit DLLs, and in fact I've read elsewhere that problems might occur in calling functions in a 64 bit DLL from a 32 bit program. So on a 64 bit system I have a 64 bit Fortran executable and several 32 bit Fortran DLLs. The problem I'm encountering is that the required redistributable DLLs, for example mkl_rt.dll, come in 32 and 64 bit versions with the same name, and some are used by both the 32 bit DLLs and 64 bit executable. I can't figure out how to install both versions so that the executable and DLLs will call the appropriate ones. I could create subdirectories for the redistributable DLLs, but is there a way to tell the program DLLs where to find the correct redistributables? Or is it possible to rename one set of redistributable DLLs and tell the program executable and DLLs to use them instead of the defaults?

Thanks!

[Steven_L_Intel1]

Windows makes this easy. 64-bit Windows will skip over the "wrong architecture" DLLs when searching, so all you have to do is put your 32-bit and 64-bit DLLs in different directories and add both directories to PATH. (You could also put them alongside the executable if they're in different folders.)

Or you could learn about side-by-side assemblies, but that's more effort than I think it is worth here.

Note that DependencyWalker doesn't understand Windows' search rules here and it will complain about finding a wrong-architecture DLL first.

[DavidWhite]

our experience with 64-bit MS Excel is that it is unable to load 32-bit DLL's.  So where customers are using 64-bit Excel, it appears we need to develop 64-bit DLL's in addition to the 32-bit versions.

Does anyone know that this is not correct, and that the 32-bit DLL's can be loaded - is it a matter of locating them in the correct folder?

Thanks,

David

[Steven_L_Intel1]

Any 64-bit executable can load only 64-bit DLLs. My discussion of folders relates to running either a 32-bit or 64-bit version of a program and not having to use different DLL names.

Yes, if you have customers using 64-bit Excel you will need to provide 64-bit DLLs and make sure Excel loads the correct one. If you have your DLLs in PATH, then this is easy, but if Excel is specifying a fully qualified file path, then it's more complicated.

[DavidWhite]

Steve,

I currently do not specify any path in the Excel/VBA code to load the DLL's - I just use the path.

Do your comments about Windows skipping over the wrong architecture DLLs apply in the 64-bit Excel case?  Can I install both the 32-bit and 64-bit DLLs into separate folders, and add both locations to the path, or is that expecting too much?

Alternatively, for the 64-bit Excel scenario, the installer would need to be able to test which version of Excel is loaded and then install the correct DLL version.

Thanks,

David

[Steven_L_Intel1]

Yes, that should work fine. Excel isn't special.

[groupw_bench]

I apologize for the delay in responding.

Thanks very much for the information. I really dislike it when applications add to or modify my system's PATH environment variable, so I won't have my application do it to others. Because my application consists entirely of 32 bit components (executable and several DLLs it calls) except for one 64 bit executable started by the main program, I decided to put all the 32 bit components into one main directory along with mostly shared 32 bit run time DLLs, and the 64 bit executable into a subdirectory with its 64 bit run time DLLs. That's the easiest scheme for me to implement and live with, and keeps my application's run time DLLs separate from everyone else's and vice versa. It appears that the side-by-side methodology could do the same, but with a lot more effort on my part.

Thanks again.