[Webinar] Streamline your web hosting managementRegister Today


DLL from Visual C++ in Borland C++?

Posted on 1997-05-12
Medium Priority
Last Modified: 2013-12-04
We are using Borland C++. Unfortunately, there is one DLL
created with Microsoft Visual C++ that we have to use and we
can't seem to link it into our application. We don't have the source for it. The DLL is created for use with Visual Basic. I don't know whether this makes it unusable for C++ or not, but we can't find the symbols in it. I have tried creating an import library using IMPLIB, but that library doesn't help. I get "Unresolved external" on each referenced function in the DLL, even though I link in the import library.

When I try to look at the contents of the DLL using the tool
LIB in Microsoft Visual C++ 5.0, it says that the library is
corrupted. However, the DLL works fine with both Visual Basic and PowerBuilder. I think the DLL is created using an earlier version of Visual C++, like 4.x.

I have created a dummy file with stubs of the same functions
as in the DLL and built a dummy DLL using Borland C++ 5.01.
When I use that, it works. When I compare the TDUMP output
for the two DLLs (my dummy and the original), the output
differs significantly. My DLL contains the function names
including the arguments, but the original DLL contains only
the function names. Could the original DLL have been created
using a different calling convention, like PASCAL or something? Does that make it unusable in C++? Shouldn't the arguments be there anyway?

I have also built my dummy DLL using Visual C++ 5.0, but the
resulting import library is not accepted by Borland C++. I
have seen that some people deliver two different import
libraries with their DLLs, one for Visual C++ and one for
Borland C++. The question is if it's possible to create an
acceptable import library without building the DLL in Borland C++, but instead using the existing DLL built by Visual C++.
--Ulrik Sandberg, lmiusg@eei.ericsson.se

Question by:ulsa
LVL 10

Expert Comment

ID: 1397266
There are great differences in calling conventions (and function naming) between Borland and MS.  These are bad enough when using C - but get even worse with C++ (due to name mangling etc).

I assume you do not have the source to this DLL and/or you didn't develop it yourself.

However, if you ARE writing DLL's yourself, I'd suggest you look at using COM because it is a binary standard which addresses all the parameter passing and naming problems that raw DLL's have and is portable across languages.  Don't get confused - COM itself isn't all that complicated - you don't need to write full OLE servers or custom controls - but it is a very nice way of encapsulating functionality within a DLL or EXE and is also nice in that it helps with versioning and allows you to call in-process, out-of-process or remote in exactly the same way.


Author Comment

ID: 1397267
I didn't develop it myself and I don't have the source.

What I don't understand is why Borland's IMPLIB doesn't find the relevant information for building an import library. Even if the name mangling is different, shouldn't Borland have figured it out by now? It doesn't make sense, because the DLL works for Visual Basic and PowerBuilder.

Author Comment

ID: 1397268
Adjusted points to 100
Free Tool: Site Down Detector

Helpful to verify reports of your own downtime, or to double check a downed website you are trying to access.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.


Expert Comment

ID: 1397269
You do not mention if you have a header file that was supplied with the DLL or if you created your own. What you have described sounds very much like your C++ code is looking for mangled function names, but the DLL is using the standard Windows naming conventions of just the function name.

If your link errors are looking for a function like "void fna(int)", than you need to add the following to your header file:

extern "C" {
// rest of header file, externs for DLL functions

You should also define the functions using the WINAPI type which should be defined in the windows.h file. This should define the funtions to use the pascal naming convention, and avoid the C++ style name mangling.

Author Comment

ID: 1397270
I used a header file that was delivered with the UNIX version of the library. I'm afraid I can't "define" stuff, since I don't have the source code. Let me rephrase the question somewhat:

a) If a DLL is created "for Visual Basic" (whatever that means), does that make the DLL unusable for a C++ application?

b) Can I trick the linker to find the functions in a DLL "for Visual Basic" by using 'extern "C"'?

c) Could bugs in Borland C++ 5.01 IMPLIB play a part in this problem?

Accepted Solution

y96andha earned 100 total points
ID: 1397271
Could you send me a copy of the DLL and header file so I could try and create an import library for it?

The problem with the DLL seems to be that the names in it are not mangled (does not contain function parameters). The normal solution for this is to use extern "C" before each function declaration. This will tell your C++ compiler not to expect mangled function names from the DLL, just like Visual Basic defaults to.

You could also consider using a module definition file with IMPORTS statements for all functions in the DLL. This should also be a possible solution.

If all else fails you could finally resort to loading the dll manually with LoadLibrary.

Hälsningar / y96andha@cyd.liu.se

Expert Comment

ID: 1397272
In answer to your questions:

a) Generally, such a DLL can be used with any language.

b) using extern "C" and WINAPI in the header file, like I mentioned in my previous post, should be enough to tell your compiler to generate the proper external names for the linker to connect to the DLL, as well as using the correct calling conventions to properly call those functions.

c) I do not think the problem is in the Borland IMPLIB, but in the naming conventions. You need to get Borland C++ to generate the names used by the DLL, and this requires the use of the extern "C" and either the WINAPI type or __pascal type in the extern statement for the functions.

For example, if one of the functions in the DLL is defined as:
int DllFunc1(int x);
you should change the definition in the header to:
extern "C" int WINAPI DllFunc1(int x);

This is what I meant by defining the functions before, that you may need to modify the header file you got in order to make this work.

If you still get an error from the linker saying that DllFunc1 is not found, than you need to either turn off type sensitivity in the link, or use IMPDEF to create a .DEF file form the DLL, modify it, and use IMPLIB to build the proper .LIB file. The modifications to the .DEF file would be as follows:

For each line like this:
   DLLFUNC1 @1
add a line like this:


Author Comment

ID: 1397273
lwiding's first answer wasn't clear enough for me to accept it. However, if I had requested a clarification instead of rejecting his/her answer, I would have given the answer the highest marks. The comment that followed proved to be exactly what was needed, but then another expert was already involved. I apologize for this and blame the turbulent situation I was in, together with the fact that I'm new to this forum.

The other expert's answer was also correct. I managed to solve the problem and I am very grateful for that. I don't see any other solution than to give the points to the second expert.

The correct answer is as follows:
My header file contained function declarations using the standard UNIX calling convention:

int myFunc(int myArg, char *anotherArg);

All that was needed in order to access the functions in the DLL was the following change:

extern "C" int WINAPI
myFunc(int myArg, char *anotherArg);


Featured Post

Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

zlib is a free compression library (a DLL) on which the popular gzip utility is built.  In this article, we'll see how to use the zlib functions to compress and decompress data in memory; that is, without needing to use a temporary file.  We'll be c…
A theme is a collection of property settings that allow you to define the look of pages and controls, and then apply the look consistently across pages in an application. Themes can be made up of a set of elements: skins, style sheets, images, and o…
This is Part 3 in a 3-part series on Experts Exchange to discuss error handling in VBA code written for Excel. Part 1 of this series discussed basic error handling code using VBA. http://www.experts-exchange.com/videos/1478/Excel-Error-Handlin…
Hi, this video explains a free download that you can incorporate into your Access databases, or use stand-alone for contact management. Contacts -- Names, Addresses, Phone Numbers, eMail Addresses, Websites, Lists, Projects, Notes, Attachments…

591 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question