DLLs with Borland
Author
I was messing around with DLLs last night for the first time using Borland BCC32. For some reason when I create a DLL (using -WD), the compiler or linker prepends an underscore to all of my exported names that I have to include in the string I pass to GetProcAddress in my calling program.
I've noticed from using IMPDEF on existing system DLLs that this is not the case with them. Does anyone know if this is normal behaviour or if there is any way of supressing it with the Borland compiler? I checked the docs and couldn't find it mentioned anywhere.
Thanks.
"To avoid the underscore in the generated symbol, add the -u- switch" How to compile the DLL from the command line
Author
Sorry to bump this but tried the old -u- last night and found a bit of a problem. Just writing some test stuff, I was exporting a function that called printf to say hello.
Trouble is, probably obviously enough, that when I use -u-, it won't link to printf since it needs _printf.
So, is there a way to export my own symbols without the underscore but still link in to other Borland libraries? Just occurred to me now that I could have called _printf instead of printf but seems like a bit of a hack. If that would work, how would namespaces be effected? If I included stdio instead of stdio.h, would I call _std::_printf? _std::printf? std::_printf? Bit confused.
Ta
Trouble is, probably obviously enough, that when I use -u-, it won't link to printf since it needs _printf.
So, is there a way to export my own symbols without the underscore but still link in to other Borland libraries? Just occurred to me now that I could have called _printf instead of printf but seems like a bit of a hack. If that would work, how would namespaces be effected? If I included stdio instead of stdio.h, would I call _std::_printf? _std::printf? std::_printf? Bit confused.
Ta
According to this how to create a plugin for their software page, Creating and using Stata plugins:
Here's the google search that led me to that: Borland+BCC32+command+line+switches+dll+underscore
Quote:
If you are using the Borland C compiler, type
$ bcc32 -u- -tWD -ehello.plugin hello.c stplugin.c
Borland uses a different linker naming convention than Visual C++ and gcc, so the -u- compiler option must be set. By default, the compiler automatically adds an underscore character (_) in front of every global identifier, which you must disable for your plugin to work with Stata. Unfortunately, using the -u- compiler option can have an unwanted side effect. When this option is used, standard C library functions, such as strcmp, are no longer correctly referenced. To correct the problem, library functions such as these will need an underscore character (_) added to the beginning of the function in your source code.
Here's the google search that led me to that: Borland+BCC32+command+line+switches+dll+underscore
As you have seen, the underscore is required to link with certain functions, so using "-u-" when trying to do this will not work. Instead, you need to create a .def file telling the linker to create an underscore-less alias for your function in the dll. One example of doing that is here.
I haven't done this, but it sounds like it should allow you to access the DLL function whilst still accessing standard C library functions with their usual names.
I haven't done this, but it sounds like it should allow you to access the DLL function whilst still accessing standard C library functions with their usual names.
Author
@LessBread - cheers. I'll have a play around with the namespace things and see what works.
@bakery21k - appreciate the link but it seems to me (I may be wrong as this is all a new area to me) that this applies to compile-time linking of dlls. I am at the moment only really interested in run-time linking through LoadLibrary etc. I'm assuming from what I read that the .def file applies if you compile-time link a dll with a .lib file. Is this correct?
To be honest, I'm starting to think it would be easier to just put up with the underscore in my own exported functions.
Just out of curiosity though, how do overloaded operator functions fit into all this, or can they not be exported from dlls?
@bakery21k - appreciate the link but it seems to me (I may be wrong as this is all a new area to me) that this applies to compile-time linking of dlls. I am at the moment only really interested in run-time linking through LoadLibrary etc. I'm assuming from what I read that the .def file applies if you compile-time link a dll with a .lib file. Is this correct?
To be honest, I'm starting to think it would be easier to just put up with the underscore in my own exported functions.
Just out of curiosity though, how do overloaded operator functions fit into all this, or can they not be exported from dlls?
Quote:Original post by EasilyConfused
@bakery2k1 - I'm assuming from what I read that the .def file applies if you compile-time link a dll with a .lib file. Is this correct?
No. The .def file takes effect when linking the object files to create the dll itself. How you use the dll is irrelevant.
Here's the method I hinted at earlier, explained properly. I've downloaded the Borland compiler myself, and have verified that this works. Using a simple source file "myfunc.c":
#include <stdio.h>__declspec(dllexport) void myfunc(void){ printf("Hello");}Compiling with:
bcc32 -tWD -e"myfunc.dll" myfunc.cAdding the -u- option causes myfunc.obj to export myfunc, but tries to link with printf, thus linking fails.
The solution is to use the former method, but add "myfunc.def" alongside "myfunc.c". The def file contains simply:
EXPORTS myfunc=_myfuncNow, myfunc.obj will export _myfunc and try to link with _printf as before. Again, as before, the linker will correctly link with _printf, and will export _myfunc. However, the .lib file will cause it to _also_ export myfunc, with the same address as _myfunc.
Quote:Just out of curiosity though, how do overloaded operator functions fit into all this, or can they not be exported from dlls?
Overloaded operator functions will be exported with name mangling, just the same as any non 'extern "C"' C++ function name.
Author
That's great. Thanks for the detailed reply.
Now, with my new DLL powers, I will be able to make my previously complex and badly designed code even harder to track and understand.
Soon, I too will be ready to design Microsoft APIs.
Now, with my new DLL powers, I will be able to make my previously complex and badly designed code even harder to track and understand.
Soon, I too will be ready to design Microsoft APIs.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
