visual studio question, building for 32 bit and 64 bit

[Brian_Murphy]

I am calling C routines from fortran.  I have abc.LIB and abc.DLL files for building a 32 bit application, and this is working very nicely.  I also have abc_x64.LIB and abc_x64.DLL for building a 64 bit application.  Is there a sample project among included example projects that shows how to get visual studio to be able to build either flavor?

[Steve_Lionel]

Pretty much all of the sample projects include both 32 and 64 bit configurations. MixedLanguage\Fortran_Calls_C does.

[Brian_Murphy]

I actually had looked through the samples.  Where do I tell it to use 64 bit versions of abc.LIB and abc.DLL files?  I could not find a sample project that does this. 

As it is now, I have abc.LIB in the "source" list of files for the project.  I believe that is the right way to do it.  File abc.DLL not specifically named anywhere in the visual studio project, so I guess it gets that name from the LIB file.  Do I also add abc_x64.LIB to the file list along with abc.LIB?

[Steve_Lionel]

If both projects are Fortran, the better way is to have both the DLL and executable projects in the same solution. Right click on the executable, select Dependencies > Build Dependencies. Check the box for the DLL project and click OK. (You'll need to do this for both configurations.) What this does is automatically link in the output library from the DLL project - it also adds the module output folder to the INCLUDE/USE list for the executable project. Because the output folders are different for 32 and 64 bit, it will select the right one.

You will need to verify in the Configuration Manager that for the 64-bit build you have the 64-bit DLL project included.

Unfortunately... several VS versions ago, Microsoft broke this for C++ projects when the dependent project is another language. What you'll need to do here is put the proper 32 or 64-bit path to the DLL export LIB in the C++ project's additional library directories property and give the name of the library under additional dependencies. Don't use the source file method for this.

In your case, you're calling C from Fortran. Unfortunately again, Microsoft broke linking dependent projects when the C/C++ project is a DLL - static libraries still work. Use the method in the previous paragraph instead. You'll still want to use Dependent Projects to get the build order right.

One does not name dependent DLLs when building, only the export LIB. Windows finds the DLL at run-time using its search list (includes PATH, folder where the EXE is, current directory, etc.), and 64-bit Windows will skip over a wrong-architecture DLL.

[Brian_Murphy]

These other LIB and DLL files are all I have.  I did not build them.  I have the C header file for it, so that tells me it is coded in C.  I will study what you said and see if I can figure out how to make it work.  The fallback is to make two separate vfproj projects.

[Steve_Lionel]

In that case, you can either put the LIBs in different folders or name them differently. Use the Additional Dependencies/Library Folders properties to locate them. The DLLs go wherever makes sense for the executable (typically you'd put the 64-bit DLL in with the 64-bit EXE, etc.) No need for separate projects. Just make sure you have the proper configuration set as you change the project properties.

[Brian_Murphy]

The LIB's are named differently, and so are the DLL's.  So I added abc_x64.LIB to the project alongside the original, created an x64 platform, and it builds and runs!!!  I know it's using the x64 flavor of the DLL because it won't run without that DLL in the proper folder.

I am also using windows API calls to read the windows registry.  That's working fine, but is there any difference between USE DFWIN and USE IFWIN?

[Steve_Lionel]

IFWIN is preferred but DFWIN just does a USE IFWIN so it doesn't really matter.