Board index » cppbuilder » Borland Builder DLL nightmare

Borland Builder DLL nightmare


2006-03-20 11:31:50 PM
cppbuilder58
know this may sound like an age old problem for some of you.
This is the problem I have a function imported from a dll into my
application. I need to use this multiple times.
Operation: Calling a C++Builder DLL in Delphi. Note I am using Delphi 2005
in Win32 mode.
<Mock Code Implementation>
C++ BUILDER used to Build DLL: ************************
__declspec(dllexport) int _stdcall funda(..)
{
.
.
return 0;
}
BOOL APIENTRY DllMain (HANDLE hModule, DWORD ul_reason_for_call, LPVOID
lpReserved) { return true; }
BORLAND DELPHI Application calls the above DLL ************************
1) When function is declared as follows in Delphi:
function funda() : integer; stdcall; external 'Fundat.dll';
Problem: The function fails on second call.
2) So my only option is to load the function from the dll and then free the
call.
LibHandle := LoadLibrary('vorutil38.dll');
try
if LibHandle <>HINSTANCE_ERROR then begin
funda := GetProcAddress(libHandle,PChar('funda')) ;
//call the function...
end;
finally
FreeLibrary(LibHandle);
end;
Problem: Works ok. BUT this ends up being too slow. Because there are
many calls to
this function!
Solution Desired: Am I missing some feature in Borland C++ Builder,when
I am creating "fundat.dll". That ensures a stable memory management for
example?
 
 

Re:Borland Builder DLL nightmare

"SM" < XXXX@XXXXX.COM >writes:
Quote
1) When function is declared as follows in Delphi:
function funda() : integer; stdcall; external 'Fundat.dll';
Problem: The function fails on second call.
Define "fails", please.
Quote
2) So my only option is to load the function from the dll and then free the
call.
LibHandle := LoadLibrary('vorutil38.dll');
try
if LibHandle <>HINSTANCE_ERROR then begin
funda := GetProcAddress(libHandle,PChar('funda')) ;
//call the function...
end;
finally
FreeLibrary(LibHandle);
end;
Problem: Works ok. BUT this ends up being too slow. Because there are
many calls to
this function!
This is not the normal approach, and if you have to do it, most likely
you're masking out a bug in your code. Try to figure out what is
actually broken, rather than trying to hide its symptoms.
If you're allocating in the dll and deallocating in your main
executable, that may cause memory problems since the application and
the dll can each have their own memory managers, and swapping
addresses between them is a bad thing. If this seems related to your
problem, try linking the borlndmm to your dll and to your
application. It'll be a common memory manager used by both and may
help.
--
Chris (TeamB);