Passing from old fortran compiler to a new one and DLL dependencies

[Barbara_B_]

Good afternoon.

I have a couple of DLLs developed on a Windows XP machine with an old compiler (of which I have no information).

These DLLs where then called from a VB.NET application.

From the documentation a colleague left me, I know that the only prerequisite for the right running of these DLLs is the presence of the "DFORRT.DLL" in the same folder where the DLL is.

Now we have passed to an Intel Visual Fortran Composer XE 2011 and it seems that something is changed:
- "DFORTT.DLL" is not required anymore; instead, sometimes "libmmd.dll", sometimes "msvcr80.dll" and other times "libifcoremd.dll" are required.
- the way parameters are passed to the DLLs seems different too: always from the documentation of my colleague, I have to pass every parameter "ByRef", also if it is a simple variable and not an array or a matrix.


So I have these questions:
- is there a way to determine a minimum collection of DLLs required to have our DLLs (same code, only the compiler is changed) run correctly?
- the compiler is run on a 64bit enviroment while the production environment is a 32bit and so we have set the compiler to 32bit mode; is there anything else we have to do or to pay attention to?


I have another problem too: a new DLL, written and compiled under Intel Visual Fortran Composer XE 2011 always on a 64bit PC, if called on a 32bit windows XP PC or on a 32bit windows 7 PC(whit a 64bit processor) throw a "Side-by-Side configuration information" error with code 14001.
With the same DLL and the same calling code, on another 32bit windows 7 PC, is all ok and the DLL is called correctly.

Any hint?

Many thanks

[Steven_L_Intel1]

Barbara, Welcome to the forum. Yes, lots of changes here. Your old DLL was built with Compaq (or Digital) Visual Fortran based on the use of DFORRT.DLL. As you have found, your DLL built with Intel Visual Fortran may use multiple DLLs (so could a CVF DLL, but it was less obvious.) The best way to see what the dependencies are is to run Dependency Walker - note that there are separate versions for 32-bit and 64-bit files. We provide an installer for the Intel redistributable files - it can be downloaded from http://software.intel.com/en-us/articles/redistributable-libraries-for-the-intel-c-and-visual-fortran-composer-xe-for-windows/ If your program also links to the Microsoft Visual C++ libraries, you'll need the appropriate Microsoft installer as well. For MSVCR80.DLL, that would be Visual C++ 2005. I will comment that VS2005 is no longer supported as of Intel Visual Fortran Composer XE 2013. Did you also change versions of Visual Basic? We have a couple of samples provided for calling Fortran DLLs from VB.NET. The old way of passing arrays that worked in some older versions of VB doesn't work in newer versions. Look at the VB_Calls_Fortran sample to see how this should be done. As for 32-bit vs. 64-bit - it doesn't matter that you did the development on a 64-bit system if you are using 32-bit DLLs. However, it is important that the correct redistributable DLLs be found or else you can get various errors. The .NET environment on a 64-bit system also complicates things. If you will be using a 32-bit DLL from your VB.NET code you must set the VB compile "platform" to "x86". Right click on your VB project, select Properties, Compile. Change Platform to x86 - it was probably set to "Any CPU". I hope this helps. Let us know if you need further assistance.

[Barbara_B_]

First of all thank you for the answer. I already tried DependencyWalker (great tool!). Thanks to it I know the dependency from "libmmd.dll", "msvcr80.dll", etc. So I'll keep using it to resolve problems like these. For the last dll, the one with the "Side-by-Side configuration information" error, we have just tried on both the pc where the DLL doesn't work to install the Intel redistributable files (fixing in this way a couple of dependencies) and the the "Visual C++ Redistributable" that are present on the pc where it works. Despite of this, the dependency from MSVCR80.DLL is still unresolved and we have the Side-By-Side error on 2 of 3 pc. If I understood right, it may be fixed installing the "Visual C++ Redistributable 2005": - on the pc where the DLL works, two packages are installed (version 8.0.61001 and 8.0.56336) plus one that is a "Microsoft Visual C++ 2005 ATL Update kb973923 - x86 8.0.50727.c053" (but I don't know what is it) - on one pc where the DLL doesn't work we have two packages (version 8.0.56336 and 8.0.59193) Both have Windows 7 as operating system. Is there something else I can check?

[mecej4]

For DLLs such as MSVCR80.DLL to be located and loaded by your EXE, it is not sufficient for the DLL(s) to be present in the machine. Each DLL should be reachable by the search procedure used by Windows. Details are given at http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586%28v=vs.85%29.aspx, but often what you have to do is to check that the DLLs are either in the application directory or can be found through the PATH environment variable. Sometimes, and especially after repeated installation of development packages (such as VC, VS, Intel Fortran), if you allow the installers to modify PATH, the search PATH can become cluttered or corrupted, or an improper DLL version may be found earlier than the proper one.

[Steven_L_Intel1]

It's actually more complicated than what mecej4 describes. MSVCR80.DLL must be in a side-by-side assembly, which is a Microsoft term for a mini-package of DLLs that are installed into Windows in a specific place, NOT part of the Windows usual search order. The way that Microsoft built MSVCR80.DLL causes it to contain a "manifest", that then tells the linker to embed information about not only the DLL name, but also the platform and specific version. If you don't have the right version, or try putting the DLL in a normal search path, you'll end up with the error you're seeing. The correct solution is to install the Microsoft redistributable package on the system where the program is to be run. The latest installer includes multiple versions of the DLL to satisfy the requests.

[Barbara_B_]

Thank you mecej4. So for that one I can resolve putting MSVCR80.DLL in the folder where the DLL I want to call is. But what for the other problem? The DLL is still not invokable dut to the Side by side configuration error. Reading some post here and there, it seems it could be a problem of a 64bit DLL calling a 32bit DLL or viceversa. Where I can check if is something like that? On the compiler I have seen that who has made the DLL has set Release 32 profile, so for what I know it should be ok. But when I try to call the DLL from code (or when Dependency Walker analyzes it) I still have this Side by Side error. Thanks all

[Steven_L_Intel1]

No, you cannot resolve this by putting a copy of MSVCR80.DLL in the folder where the DLL is. That will probably have no effect whatsoever, as Windows won't even look there for it. If you put it in the folder where the EXE is, Windows will find it and then give you the same error you're already seeing. When you analyze your DLL with Dependency Walker, where does it say MSVCR80.DLL is? Even better, in DW, do a File > Save As, save the .dwi file, and attach it here.

[Barbara_B_]

Here I have attached 2 different results of DW: the first (sce_detXP.dwi) is from the PC with windows xp, while sce_det7.dwi is from the PC with windows 7.

[Steven_L_Intel1]

Do I understand correctly that on both of the systems where you provided the DWI files, the DLL fails to load? In both cases it cannot find the right MSVCR80.DLL. You should be able to fix this by installing the Visual C++ 2005 Runtime Redistributables package for X86 on these systems.

I see that DW also claims that the "side by side assembly information" for your DLL contains errors. My guess is that this would be fixed by installing the redistributable package - did you try that?

[Barbara_B_]

I just tried to install the package from the link but it's always the same.

There were already two similar packages so I uninstalled all of them, rebooted, installed only the package, rebooted and run Dependency Walker.

The result seems the same; attached here there is the dwi.

Can it be, at this point, a compiling problem.

P.S.

Today I can try only on one of two PC. Tomorrow Il'' try on the other one.

Many Thanks

[Steven_L_Intel1]

Would you please post the buildlog.htm from the Release folder after a project build? In particular I want to see the link options.

Did you try copying MSVCR80.DLL anywhere on the target system?  You should not do that.

[Barbara_B_]

Well, I have the DLL here and there on the system, but only in folders of installed programs like McAfee, etc.

Here is the log.

I want to thank you another time because you are really helping us a lot, also in understanding better how it works.

[Steven_L_Intel1]

I don't know what's causing the proiblem, but I know how to fix it in this case. In your DLL project, select Properties > Fortran > Libraries and change the setting for Runtime Libraries to "Multithread" (not Multithread DLL). Rebuild the DLL.  This will remove the dependency on any other non-system DLLs. It is safe to do if the DLL is not called from Fortran.

[Barbara_B_]

Good evening.

Checking this solution I've had a surprise: the setting was already set to "Multithread". I've also made an experiment: setting it to Multithread DLL, the build log matches perfectly with the first one. Maybe the compiler can't build the DLL "Multithread" due to other dependencies?

[Steven_L_Intel1]

I think you didn't look in the right place, as the build log you attached had the "Multithread DLL" setting enabled.

[Barbara_B_]

I'm sorry: you were right.

I was watching the right setting but for the wrong profile: "Debug" had "Multithread" while "Relase" had "Multithread DLL".

Now the DLL is working right!!

Thank you!

If I can I have one last question: can you tell me in a few words what's the difference between the two settings?

[Steven_L_Intel1]

Multithread links against the static library form of the run-time libraries, which means that all of the code used from those libraries is included in your executable or DLL. Multithread DLL means that the DLL form of the libraries is linked against, putting a "pointer" in your EXE/DLL and requiring that the correct library DLL be present when the program is run.

The default for building DLLs is to link against the DLL libraries - one reason for this is that if you use the static libraries and then your DLL is called by a Fortran program, there will be two copies of the Fortran libraries in the memory space that don't talk to each other. This can cause I/O and memory allocation errors.

When your Fortran DLL will not be called from Fortran, it is generally safe to link it against the static libraries.  This also lets you escaspe what Microsoft csalls "DLL Hell", where you have to worry about multiple versions of DLLs. Microsoft tried to fix this with their shared assembly concept, but it introduced other issues similar to what you had. Most of the time it works well. Microsoft has advised us not to move to shared assemblies, but they don't seem to have an alternative.