Calling dll from Excel CVF/IVF

Calling dll from Excel CVF/IVF

I just recently purchased IVF 9.1 PRO and VS 2005.I have searched this forum and tried googling but I still cannot solve the following problem:I have a CVF 5 dll that is called from an Excel macro. I'm trying to port this to IVF 9.1. The dll is not that large so I simply created a new dll application in IVF and cut and pasted the source code from CVF to IVF. I created a new folder for the IVF version of this dll and changed the project name slightly to avoid confusion with names.I was able to get the build process to work without too much trouble (boy did that feel good). I then went through the Excel code and changed the paths and names in my "Declare" statements.When I run the Excel code it comes to the first Call statement that needs the dll and I geta "Run-time error53" and a file not found message.I have taken great pains to make sure the path/file namesin the Declare statements are correct. I originallyopened upthe properties window for the dll in Windows (XP SP2) andcut and pasted the path intotheExcel Declare line and then of coursetyped in the dll's name. I havecut and pasted both thepath/file name in the error message and the path/file namein my Declare statements, put them side by side in a text editor and compared them. I don't see any difference.One other thing I did which may help narrow things down. I copied the CVF dll and pasted it in the IVF debug directory and changed the name to match the one I'm using in IVF. It successfully got past the first call to the dll without complaining. It hung up on the second one; a different subroutine in the dll but I"ll deal with that later. I'd just like to get the Excel code tofind the IVF version of the dll. Seems there's something I need to do on the IVF side. I'm using the same computer for both versions.Keep in mind I'm just an engineer who knows how to program a little in FORTRAN. All this Visual Studio environment stuff is still a little fuzzy.ThanksMike

A common cause for "File not found/Runtime error 53" is that the calling application cannot find dll's on which the dll in question actually depends. IOW, it's not yourapp.dll which cannot be found, but likely libifcorert.dll. Solutions are one of:

Thanks. I actually did a more thorough search on the forums over the weekend and came across Depency Walker (probably from another post of yours!). And when I ran it on my dll it found some needed dlls that were missing.

Those dlls were not on my harddrive so I booted up the installation disk and and "re-installed" everything, including IMSL by choosing the repair option. I believe that installed the needed dlls, which I ended up putting in the same directory as the dll just to simplify things.

So I tried Dependency Walker again and two more "not found" dlls were listed, one being LIBIFCOREMDD.DLL; similar to the one you mentioned, and something called LIBMMDD.DLL Googling LIBMMDD.DLL suggests that it has something to do with Windows file security. It's a hard one to find information about. I haven't googled the other yet. Right now I'm not sure how to acquire these. I will take a look at theMicrosoftknowledge base.

You mentioned:

"You should also keep /iface:CVF for calling compatibility with Excel."

I like to use the IDE, how does one do this if you are not using the command line? In CVF(usingVisual Studio) there were places to put switches (most of which I think were put in automaticallyand most of which I didn't understand) but I can't findwhere to do this in theIDE for IVF.

LIBMMDD.DLL is the Intel math library DLL. DLLs ending in "D" are Debug versions of DLLs and you should not be redstributing these. Build your DLL as a Release configuration to get the release model DLLs.

Steve,Totally baffled and befuddled. I have absolutely no interest at the moment in redistributing anything. Actually, redistributing my code to someone else is kind of useless anyway when I can't get Excel to use the dll. :)I just "wanna" get Excel to "find" my dll (bangs head on wall!!!)!I actually found copies of these dlls on the IVF 9.1 disk with a single digit numbers appended to the end of the file name. I put these into the same directory as my dll (the same computer that IVF 9.1 is installed),had to experiment to use the 32 bit and not the 64 bit versions and then removed that last digit and I gotDependency Walker to not flag those dlls. It now says there are two other dlls that cannot be found: MSJAVA.DLL and EFSADU.DLL1) I know that what I did in the previous paragraph is rather irregular, if you will, and should not be part of the installation process. Period. But I'm just trying to get something to work.2) MSJAVA.DLL and EFSADU.DLL I'm pretty sure are probably Windows dlls as opposed to dlls created for IVF 9.1. I've googled MSJAVA.DLL and it seems to have something to do with IE and java controls. Rather strange. I may be on a wild goose chase.I suspect I may have a problem on the Windows XP side of the house. I currently am using Windows XP SP2 on a dell INSPIRON 600m. I received it with SP1. When I tried to upgrade to SP2 online a few months ago it messed things up. I then simply ordered another laptop hardrive and re-installed XP SP2 from scratch. Nice and clean and it has worked fine; until now(?).SighMike

When you install the compiler, there is an install screen which asks if you want to update system environment variables, with a note that if you don't do this, applications which depend on DLLs may not run. This is the problem you are having, I'm pretty sure. Right click on My Computer, select Properties, Advanced, Environment Variables and edit the system PATH environment variable to add C:Program FilesIntelCompilerFortran9.1IA32Bin

I don't know what DLLs you are finding with digits at the end of the file names.

I modified my path as you suggested. This enabled Dependency Walker to not flag LIBIFCOREMDD.DLL and LIBMMDD.DLL but it still flags MSJAVA.DLL and EFSADU.DLL.

I decided to uninstall IVF and IMSL. I re-installed IVF and let the installation wizard modify the path variable every time it wanted to. I did not re-install ISML to simplify things since I don't need it for this application.

No change. Dependency Walker still flags MSJAVA.DLL and EFSADU.DLL.

Some observations:

When I open my old CVF dll with Dependency Walker I get 11 "entries" when the list is expanded and of course nothing is flagged. When I open the IVF version I get literally hundreds; a huge dependency tree. This seems odd.

Okay. I have managed to get past the "excel recognizing the dll" problem. I'm not sure exactly but I think it had something to do with the path variable Steve alluded to.

I was under the impression that if Dependency Walker found issues with the dll that Excel would also. That is apparantly not the case. After making several attempts to resolve the missing dlls, MSJAVA.DLL and EFSADU.DLL, I decided to just try running the Excel VBA and much to my suprise I got one of those severe errors from inside the dll. The type of error that makes Excel "disappear"; first time I've actually been happy to see one of those! Somewhere between the path issue and reinstalling (without IMSL) the problem got resolved. Now onto other ones.

I am attempting to pass a filename from the Excel VBA to the dll and the complete filename is not showing up on the Fortran side. Apparantly something has changed, of IVF is simply not as forgiving, between CVF and IVF concerning strings. I'll hack away at this one for awhile before seeking assistance.

Default calling convention has changed in IVF from __stdcall to __cdecl, plus, hidden string length is passed after all arguments, rather than immediately after string arg -- the latter seems to be your problem at first sight.

If you have converted the CVF project using "Extract CVF project items" context-menu function, the converter should have set CVF defaults for you. If not, go to project/properties/External procedures and set up calling convention to "CVF" and string length argument passing to "after individual string arg". That should give you CVF-compatible calling sequence (modulo some changes in functions-returning-derived-types, but that's unlikely).

JugostavDujic,Thanks. Late last night I did find a post in this forum that explained this and hada nice example that was worth it's weight in gold. I can't find it now at work for some reason.As I stated in the first post I did not convert the project; it was too confusing at the time so I simply created a new IVF project and cut and pasted source code to try and "simplify" things. Looks like I should have tried to spend more time converting. Of course if I had done that, IVF would have changed some settings automatically and my project may have worked finewithout me ever realizing that the calling convention had changed and I would have been really messed up the first time I tried to create code from scratch. Oh well.If this is all written down somewhere, with examples showing how to pass information from a non-IVF language to IVFand vice-versa I would be one of the first in line to acquire it.Before I saw your post I was planning on going through my code and changing the order in my calls but I think I will look into your suggestion to force IVF to use the CVF convention for my CVF projects now that I know what to do when I create IVF codes from scratch.Thanks for your help. This forum is very helpful. I've solved other issues over the years by simply lurking the posts on this forum. To actally post a question is a last resort. (I hope Steve and others like yourself are my age or younger so that you don't retire before I do :)).Mike

Okay. Now I would like to put an executable (dll) on another machine. I'm not sure how to do this. With CVF you had to simply copy two or three FORTRAN dlls to the other machine along with the dll. I've searched this forum (not exhaustively) and could not find what dlls I'd need to copy over for an IVF executable.

From what I did see, it looks like I might have to build a release version. I tried to do this (and the final attempt had me going into configuration manager and making sure I was in the "Release" configuration) but still no luck; my VBA code can't find my "Release('d)" executable.

I also put a copy of "libifcorert.dll" in the same directory as the executable. No luck.

The first two end with Ds which are not allowed to be copied to other machines and I have not done so. I have also put the directory that the execcutable is in in my Path environment variable. So something else is going on. What am I not doing right?

Okay. Last night, after doing some more forum searching, I copied the dlls in the bin directory onto the other machine; same directory as the execuabel dll. Ialso had to copy a Visual Studio dll over as well. This got me past the "can't find dll" problem".

Then I had a problem with a string concatenating operation. This I think may have something to do with the debug and release versions compiling differently, which I had just learned about in my forum searching for the dll problem, so I wasn't completely suprised.

I was using a "character *(*)" statement which apparently is an "obscelesent fortran 95" statement. I made the strings a fixed length and used the TRIM statement in the concatenation operation to get the two strings put together correctly. I still can't get the release version to work on the other computer but the debug version of the executable dll now does.

There's nothing wrong with character(*), but that assumes that the caller passes the length in a separate "hidden" argument at the end of the argument list. Usually when calling from Excel you are telling Excel to pass the string by value (and no length is passed), so you should use the REFERENCE attribute on the character variable to tell the compiler not to expect a length. More so, on a STDCALL routine, the caller and callee must agree on number of arguments or else you'll get stack corruption.

The difference you are seeing is probably due to memory layout differences or perhaps optmizations that reveal a coding error that the debug version doesn't.

The main installations of IVF 9.1 and Microsoft Studio 2005(? whatever the latest one is) are on a Dell 600m laptop with Windows XP SP 2 Home Edition. Things are working okay there.

Trying to redistribute on two other machines:

1st machine: Dell Desktop with Windows 2003 Pro SP 4. I can get the debug dll version to work (and yes I had to temporarily copy those *mdd.dll files to do this, just to see if I could get something to work) but so far not the release version; something to do with concatenating strings. (Btw, the release version seems to "find" the dlls okay on this machine.)

2nd machinge: Dell Desktop with Windows XP SP 2 Pro Edition. Can't get either debug or release version to work. Keep getting a "run time error 48" message for both verstions and it says it can't find my executable (C22DATA91.DLL). After a lot of fiddling and googling and Dependancy Walker"ing" this is what I have come up with. I copied the directory that contains my debug executable dll and supporting dlls from the "1st machine"(wherethe debugversionworks) tothe "2ndmachine". When I use Dep Walker on C22DATA91.DLLI get the following message onmachine 2 but NOT on machine 1 (orthe laptop for that matter):

Error: The Side-by-Side configuration information in "c:cell22fortran91c22data91c22data91
eleaseC22DATA91.DLL" contains errors. This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem (14001)

Same thing for the release version. I do NOT have the Intel FORTRAN or Microsoft Studio 2005 installed on machines 1 or 2. I do haveCVF 6(?) installed on machine 1 though ifthat somehow might make a difference.

I had already done both. I copied the folder that contained both the executable dll and the distributed dlls from the PC on which things worked to the 2nd PC. I had also included the directory tree to this folder in the path environment variable.

Both of these PCs are in a test cell. The one on whichI got something to work is more of a stand alone. It can see and be seen by the "corporate" (I actually work at a government installation) network but is not hardwired into it like a "borg" drone if you will. The 2nd PC is part of the "borg" network entity and has network updating software, the registry is locked out to the user etc. etc. If something doesn't work you can never tell whether or not it's because of the network stuff loaded on it. My computer at my desk is also of this type; I will try to do this on that computer when I get the chance and see if I get the same results.

The main installations of IVF 9.1 and Microsoft Studio 2005(? whatever the latest one is) are on a Dell 600m laptop with Windows XP SP 2 Home Edition. Things are working okay there.

Trying to redistribute on two other machines:

1st machine: Dell Desktop with Windows 2003 Pro SP 4. I can get the debug dll version to work (and yes I had to temporarily copy those *mdd.dll files to do this, just to see if I could get something to work) but so far not the release version; something to do with concatenating strings. (Btw, the release version seems to "find" the dlls okay on this machine.)

2nd machinge: Dell Desktop with Windows XP SP 2 Pro Edition. Can't get either debug or release version to work. Keep getting a "run time error 48" message for both verstions and it says it can't find my executable (C22DATA91.DLL). After a lot of fiddling and googling and Dependancy Walker"ing" this is what I have come up with. I copied the directory that contains my debug executable dll and supporting dlls from the "1st machine"(wherethe debugversionworks) tothe "2ndmachine". When I use Dep Walker on C22DATA91.DLLI get the following message onmachine 2 but NOT on machine 1 (orthe laptop for that matter):

Error: The Side-by-Side configuration information in "c:cell22fortran91c22data91c22data91 eleaseC22DATA91.DLL" contains errors. This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem (14001)

Same thing for the release version. I do NOT have the Intel FORTRAN or Microsoft Studio 2005 installed on machines 1 or 2. I do haveCVF 6(?) installed on machine 1 though ifthat somehow might make a difference.

Sigh

Mike

Hi sabur,

I get the same problems on my DLL exactly as you explain in this thread. This specific problem you are facing now is due to the incorrect manifest in your DLL. On MSDN somebody suggested to turn off the MANIFEST. This solution did not work for me, but perhaps it will work for you. You select the DLL of your interest in IVF and go to Properties. Go to Linker and than to Manifest File. There you can switch it off. This is will stop Dependency Walker giving you the problem, but I still can not run my DLL. All of my DLLs are present in the application folder but still no luck. Let me know if you have found a workarround for your problem.

I get the same problems on my DLL exactly as you explain in this thread. This specific problem you are facing now is due to the incorrect manifest in your DLL. On MSDN somebody suggested to turn off the MANIFEST. This solution did not work for me, but perhaps it will work for you. You select the DLL of your interest in IVF and go to Properties. Go to Linker and than to Manifest File. There you can switch it off. This is will stop Dependency Walker giving you the problem, but I still can not run my DLL. All of my DLLs are present in the application folder but still no luck. Let me know if you have found a workarround for your problem.

Darko

Hi sabur,

Darko again. I think I got it, but this has nothing to do with FORTRAN. Actually if you want to use VS compiled product on a machine that does not have VS you will have to install a package called vcredist_x86.exe. Further, some machines in combination with some programs might require a .NET Framework installation. This definitly solved my issue. Hope this helps.

Quoting - Steve Lionel (Intel)I also can't figure out what is giving you a dependency on MSJAVA.DLL, etc...

Steve,

There is a flawed MSHTML.DLL which is on some systems which flags an erroneous call to MSJAVA.DLL. In some of my apps I have had to get a copy of MSJAVA.DLL to solve this problem. (even thoughMicrosofts license to use Java has expired)

Darko again. I think I got it, but this has nothing to do with FORTRAN. Actually if you want to use VS compiled product on a machine that does not have VS you will have to install a package called vcredist_x86.exe. Further, some machines in combination with some programs might require a .NET Framework installation. This definitly solved my issue. Hope this helps.

Best wishes,

Darko

Darko,

Ah yes, I was searching the forum and came across this 2006 thread of mine and was surprised to see that someone had responded to it recently.

And you'reright. A while after I "abandoned" the thread I did discovered while googling, in some faraway hidden niche of the Internet, some reference to "vcredist_x86.exe" and discovered what you did; one needs to run this file on the other machine if that machine does not have Visual Studio installed in order to run Fortran executables along with the Fortran dlls needed to run on other machines that do not have the Fortran compiler installed.

Now with the latest Intel Fortran version (10(?) on up), VS is incorporated such that one does not need to buy a separate version of VS studio to install on you development machine so I would guess that if one takes this route (buy and use latest Intel Fortran version without installing separate VS) that one would not need to use "vcredist_x86.exe".

However, the VS that comes with the latest Intel Fortran is a bit stripped down and youcan still install a full blown separate version of Visual Studio along with the latest Intel Fortran and get the full "benefits" of VS. And I have little to no idea what most of those benefits are. One that I'm pretty sure about though is that with the full-blown version of VS you can compile C/C++ codes along with other languages. Right now I'm dealing with mixed-language issues and I need to work with a small C code so I need (feel free to correct me if I'm wrong anyone) the full blown separate version of Visual Studio, whichwasn'ta problem since I already had a copy (VS ver 2005) that I needed to buywhen I bought Intel Visual Fortan ver 9.0.

You still need to install the Visual C++ resistributables on systems where you run Fortran executables or DLLs linked to the DLL libraries. You also need to provide the Fortran DLLs - we are working on a redistributable installer for those.

Quoting - Steve Lionel (Intel)You still need to install the Visual C++ resistributables on systems where you run Fortran executables or DLLs linked to the DLL libraries. You also need to provide the Fortran DLLs - we are working on a redistributable installer for those.

So, even with IVF 10/11 (for which you don't need to buy and install a separate Visual Studio package as I understand it) you still have to install Visual C++ redistributables on other non Visual Studio systems?Do thefile(s) necessary to do this come with IVF version 10 and above?

Quoting - Steve Lionel (Intel)You still need to install the Visual C++ resistributables on systems where you run Fortran executables or DLLs linked to the DLL libraries. You also need to provide the Fortran DLLs - we are working on a redistributable installer for those.

So, even with IVF 10/11 (for which you don't need to buy and install a separate Visual Studio package as I understand it) you still have to install Visual C++ redistributables on other non Visual Studio systems?Do thefile(s) necessary to do this come with IVF version 10 and above?

This is no different than if you were using Microsoft Visual C++. If your Fortran application is linked to the DLL libraries, you will need the MSVC and the Fortran DLLs on other systems. The MSVC redistributable package does not come with IVF - you download it free from Microsoft. There is a different installer depending on which Visual Studio version you're using.

Quoting - Steve Lionel (Intel)This is no different than if you were using Microsoft Visual C++. If your Fortran application is linked to the DLL libraries, you will need the MSVC and the Fortran DLLs on other systems. The MSVC redistributable package does not come with IVF - you download it free from Microsoft. There is a different installer depending on which Visual Studio version you're using.

Okay. I'll keep that in mind. BTW, I've noticed that this thread seems to have a relatively high number of views - around 9700. Any idea where this ranks in terms of "Views"? Is there a way to find thread statistics like this that I'm not seeing?

Quoting - Steve Lionel (Intel)This is no different than if you were using Microsoft Visual C++. If your Fortran application is linked to the DLL libraries, you will need the MSVC and the Fortran DLLs on other systems. The MSVC redistributable package does not come with IVF - you download it free from Microsoft. There is a different installer depending on which Visual Studio version you're using.

By using /libs:static in my compiles, I have managed to be able to distribute my Excel DLL apps without too much problems. Before I did this, I had to distribute the msvcr*.dll and associatedmanifest file. I now distribute only the DLL which is installed in the application folder, which I add to the PATH. I also put an .xla interface into the XLSTART folder. This works better than the EXcel Addins folder, which results in hardcoded paths to the users Addins folder, which fail when the spreadsheet is shared with other users.

If I get a chance, I will try to develop a simple .xla interface and associated fortan DLL project and post it here as an example. I am distrubuting 3 Excel / DLL applications to about 150 users globally within our company, and it seems to be working OK. I just hope that as we transition to Office 2007 later this year and perhaps Vista next year, I won't have a too rocky migration path.

ExcelDLL.xla needs to be installed in C:Dcocuments and settingsUSERIDApplication DataMicrosoftExcelXLSTART instead of the AddIns folder, otherwise workbooks shared with other users will have unresolved links.

Use ExcellDLL Test.xls to test the functions.

As far as I have observed, no other files need to be installed on other users machines.

I got the the run-time error 53 too. My situation is: i can debug the code from VS 2012/IVF with IMSL (e.g., F5) and my dll works fine in the case. BUT if I run the Excel VBA directly, i got "runtime error 53". Any one know why? Thanks

I am using Excel 2013 32-bit. Vs2012, intel fortran 2015 (ia32) with IMSL. I can run the code in debug mode (such as: F5 in VS 2012 by attaching Excel for debugging). But , when I run the code from Excel, i got run-time error 53 -:( Pls help

Attachments:

Can you do a File > Save in Dependency Walker and attach a ZIP of the .dwi file? The screenshot doesn't tell the whole story. I'll note that Dependency Walker doesn't understand that Windows skips over "wrong architecture" DLLs.

Attachments:

Ok. It seems that you copied some Intel DLLs to e:\mydata\programs\ior-stress-calculation-bundle\calling_fortran_vba\testdll\testdll\debug\ When you run things from VS this may be seen, but Excel won't, These are MKL DLLs. We don't put the MKL DLLs in PATH by default, but you should do so since you are using MKL indirectly through IMSL. Add C:\Program Files (x86)\Intel\Composer XE 2015\mkl\lib\ia32 to PATH.