Visual Studio DLL and Visual Basic

Okay. I've been struggling with this for a long time. I've decided to finally ask it out here and see if I can make it work. I have code that I can successfully build on a couple of different compilers (Borland and Pelles) as a DLL and use it from a program written in Visual Basic. We are using the __stdcall for the DLL. I can also compile and produce a DLL using Visual Studio. However, the DLL produced by Visual Studio cannot be called from Visual Basic. We call it but nothing happens. We do not know why. The exports all look good, etc. None of the code is different. So, I have to assume that it is a setting or something. But, we cannot find it. Ideas? Is there an issue with Visual Studio produced DLLs and Visual Basic? Are there workarounds?

>> We call it but nothing happens.
Show the declaration for "it" (the function) in both VB and C source.

gg

Declaration of DLL from C code.

int __stdcall DLLNAME(struct bufferone far *a_one,
struct buffertwo far *b_one,
struct buffertwo far *b_two,
struct buffertwo far *b_three)

Call from Visual Basic Code

Declare Function DLLNAME Lib "dllname.dll" _
(ByRef a_one As bufferone, _
ByRef b_one As buffertwo, _
ByRef b_two As buffertwo, _
ByRef b_three As buffertwo) As Integer

Look at the DLL built by VS using Dependency Walker: Dependency Walker (depends.exe) Home Page
Do you see the expected exports?
Do they look similar to the exports produced by Borland/Pelles?

gg

It looks like the VS version is not exporting the function. The outputs from Dependency Walker are virtually identical except the VS version has MSVCR80D.DLL in the output. Also in the output pane, E, the function is not listed. In the Pelles it is listed. So, there's the trouble. What's the cure? Why isn't it being exported? Something really stupid is slipping past me here.

Since this looks like VB 6, the declarations you posted are incompatible. A VB Integer (16-bits) is not the same size as a C int (32-bits). You might want to post the makeup of your two structs, if they are similarly mismatched loading the DLL will be the least of your problems.

If this is VB.net, then ignore the above.

Code:

---

__declspec(dllexport)

---

Like on this page Building a DLL with Visual C++ - Developer Zone - National Instruments

or http://msdn.microsoft.com/en-us/library/3y1sfaz2.aspx

Tim S.

>> the VS version has MSVCR80D.DLL
Then you were looking at a debug build of your DLL. To use your VS DLL on other PC's, you'll need to use a release build and make sure the PC has had the VC++ Redistributable Package installed (or link with the CRT statically).

>> Also in the output pane, E, the function is not listed.
If you are using a .DEF file for DLL exports, make sure it's part of the VS solution/project. Using "__declspec(dllexport)" in source is an alternative to using a .DEF file.

gg

Okay, with your help (thank you, thank you), I've got a successful build that we're able to call from Visual Basic in Windows 7. We're building the DLL in Visual Studio 5 SP3 on a Windows 7 machine. We can call the DLL on a Windows 7 machine. However, when we try to call the same DLL from XP and Server 2003 machines it fails. So, we've got some type of incompatibility between included components or there are options that should be set to make this DLL callable across all platforms. What should I be looking for?

Thank you for all of the valuable assistance so far. I do appreciate it.

If you're on Windows 7 ... are you building a 64bit dll?
That's not going to work on any 32 bit operating system.

The rules for this are simple...
You cannot load a 64 bit DLL in a 32 bit OS.

On a 64 bit OS...
You cannot load a 64 bit DLL in a 32 bit process.
You cannot load a 32 bit DLL in a 64 bit process.

This leaves the rather unenviable task of having to compile everything twice with different file names.
(Typically ... dllname.dll and dllname64.dll )

Building on a 64-bit system but for Win32.

In depends.exe, we still have MSVCR80.DLL even though we have debugging off for a release build. Why is that still included? How do I remove that? Could that be our issue?

Quote:

---

Originally Posted by mathguy

Building on a 64-bit system but for Win32.

---

Understood... but this is an error I've made before... double check that you are actually building a 32 bit DLL.

Okay will check to be sure. How should I be totally sure?

Quote:

---

Originally Posted by mathguy

Okay will check to be sure. How should I be totally sure?

---

You're going to have to trust the compiler and linker settings...

You will be totally sure when it works.

Okay. Well, I'm sure that we're set for Win32. Anything else you can think of that would cause it to work in Windows 7 but not XP and Server 2003? I realize now that the MSVCR80, etc. are runtime libraries. Those shouldn't be causing us any issues.

Quote:

---

Originally Posted by mathguy

Okay. Well, I'm sure that we're set for Win32. Anything else you can think of that would cause it to work in Windows 7 but not XP and Server 2003? I realize now that the MSVCR80, etc. are runtime libraries. Those shouldn't be causing us any issues.

---

You may need to distribute the runtime with the dll, to make sure it's on the target machines.

(Which is why I gave up on MS compilers long ago... you gotta give out this, include that, share something else... what a pain!)

Quote:

---

Originally Posted by Codeplug

To use your VS DLL on other PC's, you'll need to use a release build and make sure the PC has had the VC++ Redistributable Package installed (or link with the CRT statically).

---

>> we still have MSVCR80.DLL
That's the non-debug version (no 'D' at the end), which is good, but you'll have to apply the VC++ Redistributable Package to the target machine to ensure MSVCR80.DLL is in place.

The alternative is to link with the CRT statically. From the menu:
Project -> Properties
select Configuration: "Release"
select Configuration Properties \ C/C++ \ Code Generation
set "Runtime Library" to "Multi-threaded (/MT)"
After that, depends.exe should no longer show MSVCR80.DLL as a dependency.

If the above doesn't help, we'll need a better description than "it fails".

gg

I have been meaning to get back. I've got it solved and working. It wouldn't have happened without all of your help. Thank you! I truly appreciate the time you all took responding to my questions.