Board index » cppbuilder » Sharing code between BC5.02 and BCB5

2004-03-04 01:15:26 AM
cppbuilder97
Hello,
I have a large number of old DLL projects that I inherited which were
written with Borland C++ 5.0, using OWL. I have converted many of those
projects to BCB 5 w/VCL. However, several of them still remain BC5 w/OWL
simply because of lack of time.
The OWL-based DLL's export functions that are callable by the other DLL's.
However, the functions are all exported as 'extern "C"', which means that
much of the C++ type-checking is eliminated. I have discovered numerous
cases in the old DLL's where the function prototypes did not match the
actual function definitions, and yet the code still compiles and runs. I
decided it would be worthwhile to remove the 'extern "C"' declarations to
take advantage of C++ type-checking for the function prototypes to hopefully
catch all such errors. However, in doing so, I have lost the ability to
link between the BCB DLL's and the BC++ DLL's.
The functions are being exported with name-mangling (which is identifiable
by each function's name and parameter types being listed in TDUMP's output,
rather than a simple fiunction name prepended by an underscore, as is the
case for a function declared with 'extern "C"'), and yet the linker's
"unresolved external" complaints exactly match the exported function names!
Has anyone an idea why, though the linker complaints match the exported
names, the linker still fails to resolve the external references?
- Dennis
 

The exported symbol name must exactly match the imported symbol name. The
designer of the linker arranged for it to show you the information for both
in the hopes that it would assist you in deciding how to proceed in
correcting the errors.
A standalone function not part of a class has the same default calling
conventions in C or C++. The only difference is the name mangling that C++
uses, a method which is used to implement the C++ ability to have overloaded
functions.
The correct way to do what you ask is to build the DLL with the BCB compiler
so that the names match and then alter the header files so that they no
longer lie.
Failing that you could use place an alias into a module definition file to
provide an alternative name for the function. For example:
----contents of DomeName.DEF -----
IMPORTS
_NameUsedByTheExeFile = DLLNAME@FuncName$qv
-----------------------------------------
You then add the module definition file to the project.
. Ed

"Ed Mulroy [TeamB]" < XXXX@XXXXX.COM >wrote in message
that's out, but I think I have found the cause of the problem:
The original code uses many, many header files to declare structures that
are passed as parameters to most of the exported functions. The newer code
also uses header files to define those same structures, but the newer header
files are in a different directory, and the structure names they declare are
different than the originals. Thus, when using 'extern "C"', the C compiler
didn't do any parameter type-checking, and because the linker doesn't care
about the arguments, it linked everything fine. And because the structure
contents always matched exactly, everything ran fine.
When I eliminated the 'extern "C"', then name-mangling began to take place,
and the differences in the structure names became apparent. Most of the old
header files have been modified to simply #include the new header files and
then use a typedef to make the names match up, but not all of the old
headers have had this done yet, and those seem to be the same structures
that are used in the functions that I am having trouble linking.
For example:
The old BCW code exports a function like this:
CoverDlg32(HWND__ *, COVLETTER *, short)
And the new BCB code is trying to link a function like this:
CoverDlg32(HWND__ *, CoverLetter_s *, short)
Even though the strcutures "COVLETTER" and "CoverLetter_s" are identical
internally, the names are different, and hence the linker error. I haven't
tried it yet, but I think by modifiying the rest of the old headers to
#include the new headers and the appropriate typedef's will resolve the
problem.
- Dennis
 

{smallsort}

"Dennis Jones" < XXXX@XXXXX.COM >wrote in message
but I still get an error:
From the exporting DLL:
Exports from maint.dll
2 exported name(s), 2 export addresse(s). Ordinal base is 1.
Sorted by Name:
RVA Ord. Hint Name
-------- ---- ---- ----
000011D2 1 0000 MaintValues(HWND__ *, MaintType_t, bool, short)
0000381C 2 0001 __De{*word*81}HookData
From the importing DLL:
Error: Unresolved external 'MaintValues(HWND__ *, MaintType_t, bool, short)'
They look identical to me.
MaintType_t is a typedef'd enum:
typedef enum
{
// blah, blah, blah
} MaintType_t;
...and both the exporting and importing DLL's #include the same header file
with the enum's typedef. Strange.
- Dennis
 

that BCB will compile OWL DLL's.
some of your projects it might be worthwhile to reconsider that decision.
I wish you luck in porting things over. It sounds as if you're facing a
good bit of work.
. Ed

Try running tdump on the dll to see if there is any clue in the exact text
of the symbol:
tdump -m -em dllname.dll
. Ed

"Ed Mulroy [TeamB]" < XXXX@XXXXX.COM >wrote in message
source, which is why OWLNext is so often recommended to BCB users.
continue to support the old OWL code any longer than I have to, as the code
is slowly being ported to BCB. Thus, porting the old code to OWLNext in the
meantime would be more wasteful than useful.
- Dennis
 

"Ed Mulroy [TeamB]" < XXXX@XXXXX.COM >wrote in message
the functions doesn't help me. And of course, I can't dump the DLL that is
importing the functions, because it won't link!
- Dennis
 

"Dennis Jones" < XXXX@XXXXX.COM >a écrit dans le message de
virtualy made no change to my code. The only real work was to setup OWLNext
itself.
--
Regis St-Gelais
 

That was a typo sorry:
change
tdump -m -em dllname.dll
to
tdump -m -ee dllname.dll
. Ed