Calling dll from Excel CVF/IVF

[sabur]

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.

Thanks

Mike

[Jugoslav_Dujic]

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:

* Add "C:Program FilesIntelCompilerFortran9.1IA32Lib" to PATH
* Redistribute the libifcorert.dll along with your dll
* Link your dll with static run-time libraries (Project/Properties/Fortran/Libraries/Use run-time-library)

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

A recommended dll-inspector is
Dependency Walker.

[sabur]

Jugoslav,

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.

[Steven_L_Intel1]

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.

[sabur]

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.DLL

1) 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(?).

Sigh

Mike

[Steven_L_Intel1]

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.

[Steven_L_Intel1]

I also can't figure out what is giving you a dependency on MSJAVA.DLL, etc...

[sabur]

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.





Mike

[ggveldkamp2]

msjava.dll and efsadu.dll are probably delay-load dependencies for shell32.dll. Your program can run without them unless you call functions from these dll's.

Guido

[sabur]

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.





Thanks for your help.





(I'm having trouble with spacing between paragraphs; I don't know why it's putting extra blank lines in)

[Jugoslav_Dujic]

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).

[sabur]

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

[Steven_L_Intel1]

I suspect that Jugoslav is quite a bit younger than I am....

[sabur]

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.

Dependency walker claims that my executable depends on the missing dlls "LIBIFCOREMD.DLL", "LIBMMD.DLL" and "MSVCR80.DLL".

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?

Mike

[Steven_L_Intel1]

Those DLLs are ok to redistribute. They are NOT the debug DLLs, which would end in MDD.

[sabur]

Steve,

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.

Mike

[Steven_L_Intel1]

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.

[sabur]

Steve etal,

The saga continues

Current situation:

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

[Steven_L_Intel1]

Check that the PATH environment variable includes the path to the run-time DLLs, or have them all in the same folder as the EXE.

I have not seen that "Side-by-side" error before.

[sabur]

Steve,

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.

Mike

[sabur]

Just tried it on my desktop in my office (similar setup as the 2nd pc in the test cell; assimilated into the corporate network). Same thing, "...side by side..." error.

Mike