Creating DLLs for 32-bit system from a 64-bit system

[Bryant_Jurgens]

I'm runningIVF 11.1.051 on my 64-bitsystem with windows XP Pro 64. Like many, I've created fortran dlls for use with excel. On my systemit works great, but when Irun it on a 32-bit system and 32-bit architecture, I can't get the dll to return values to excel even though the dll was compiled as win32.

Previously I was able to create these dlls andcopy them over to 32-bit machines and everything worked as expected, but now all of a sudden I can't get excel and the dll to communicate. Between the IVF updates and Windows security and office updates, I don't know what has changed or if this is eventhe reason.Has anyone experienced this or ideas on what could be the problem?

[Greg_T_]

Hi Bryant,

A few ideas: I noticed that the IVF update has a redistributable package, w_cprof_p_11.1.051_redist_ia32.exe. Perhaps the 32 bit computer needs the updated IVF redistributable files? If you use Visual Studio, I've noticed that the system dependencies have changed from VS2005 to VS2008, for DLLs I've compiled. Maybe the 32 bit computer needs the VS reditributable update too. Do you get any error messages? Or the DLL just doesn't do anything? Could the DLL be run from an executable in a console window to see if that gives any error messages?

Regards,
Greg

[Bryant_Jurgens]

Thanks for the reply Greg. The 32-bit machines that I'm deploying the Excel with dll add-in application don't have IVF installed on them. This worked previously, but now the DLL just doesn't do anything on the 32 bit machines.

I'm planning to install IVF on a 32-bit machine and debug the DLL from there.I probably should have developed the DLL and Excel program there in the first place, buteverything I did on the 64bit system copied over and worked in the past so I didn't think I needed to.

I justwondered if there was anything I needed to includewhen compiling to ensure 32-bit compatability.Or perhaps this was the result of therather largeWindows securityand office securityupdates that occurred mid-October. The overlap in Windows and IVF updates have made it difficult to figure out what has changed.

Bryant

[Steven_L_Intel1 · Accepted solution]

If you build your DLL with the Libraries > Use Runtime Library property set to "Multithreaded" (not Multithreaded DLL), you won't have dependencies on DLLs. I strongly suggest that you write a simple jacket program that calls the DLL to see what it is doing. I can't think of anything different you would have to do.

[Bryant_Jurgens]

Quoting - Steve Lionel (Intel)

If you build your DLL with the Libraries > Use Runtime Library property set to "Multithreaded" (not Multithreaded DLL), you won't have dependencies on DLLs. I strongly suggest that you write a simple jacket program that calls the DLL to see what it is doing. I can't think of anything different you would have to do.

That did it!!!! Changed the runtime propertyfrom "Multithreaded DLL" to "Multithreaded" and everything is working properly. Thank you, thank you!!!