Dynamically loading non-Borland DLL's 1

[TonyGroves]

I want to write a C++Builder application that dynamically loads a certain DLL, as there are several suitable versions of the DLL available, all of which export the same functions, but at different addresses. It's not a Borland-format DLL.

It seems that if I want to use a non-Borland DLL, I have to use implib to produce a *.lib file, which must then be linked into the application; is that right? That would mean that I'm tied to the particular DLL version that I've linked.

Does anybody know of any way around this problem?

Thanks a lot.

 

[butthead]

yu could perhaps have more than one dll that is a wrapper
for the calling functions of each version.

you got

dll1.dll
dll2.dll
dll3.dll

each dll was created with each different version of the
lib file.

the function you have is foo ();

dll1.dll->foo1()->foo () from the first version of the dll

dll2.dll->foo2()->foo () from the second version of the dll

dll3.dll->foo3()->foo () from the third version of the dll

so from your program you just use some kind of test to
determine which version you got to use and call either

foo1() or foo2() or foo3()



TC

 

[TonyGroves]

Thanks for that, but (sorry, I should have been clearer) there's only one version of the DLL on-site at any one time, but which version that is is unknown (though it could be determined by examining aspects of the system configuration). The names of the different versions are identical.

Maybe a solution would be to write a C++Builder DLL which would provide access to the non-Borland DLL, compile different versions of it to match each version of the non-Borland DLL, distribute the appropriate version with the non-Borland DLL, and have applications use that instead.

Thanks again.

 

[butthead]

if each version of the dll is a different size
you could do a quick check of the file size and
use the correct call. though I can see myself
still getting things confused and send the wrong
borland dll to one or more sites. if you cant get
the other sites to use only one version i would
think that since you are already making more than
one , just do some checking and distribute all.
just eliminate one more tracking problem.

TC

 

[Totte]

As far as i understand the problem is not the version of the DLL but how to get the address of the function? And that the functions has the same name for the same function as well?

When i used the "InpOut32.DLL" i used the method described so well in the doc's for "InpOut32.DLL" found free on the net (just snipped & not polished):
// Definitions in the build of inpout32.dll are:
// short _stdcall Inp32(short PortAddress);
// void _stdcall Out32(short PortAddress, short data);
// prototype (function typedef) for DLL function Inp32:
typedef short _stdcall (*inpfuncPtr)(short portaddr);
typedef void _stdcall (*oupfuncPtr)(short portaddr, short datum);

HINSTANCE hLib;
inpfuncPtr inp32;
oupfuncPtr oup32;
const int Port = 0x378;

//---------------------------------------------------------------------------
#pragma package(smart_init)
#pragma resource "*.dfm"
TForm1 *Form1;
//---------------------------------------------------------------------------
__fastcall TForm1::TForm1(TComponent* Owner) : TForm(Owner)
{
short x;
int i;
Memo1->Clear();
// Load the library
hLib = LoadLibrary("inpout32.dll");

if(hLib == NULL)
{
Memo1->SetSelTextBuf("LoadLibrary Failed.\r\n");
}

// get the address of the function
inp32 = (inpfuncPtr) GetProcAddress(hLib, "Inp32");
if(inp32 == NULL)
{
Memo1->SetSelTextBuf("GetProcAddress for Inp32 Failed.\r\n");
}

oup32 = (oupfuncPtr) GetProcAddress(hLib, "Out32");
if(oup32 == NULL)
{
Memo1->SetSelTextBuf("GetProcAddress for Oup32 Failed.\n");
}
#if false
sprintf(Buffer,"Out: %3u\r\n %02Xh",Datas,Datas);
Memo1->SetTextBuf(Buffer);
#endif
(oup32)(Port,Datas);
}


Totte
Keep making it perfect and it will end up broken.

 

[TonyGroves]

Thanks for that. I know how to get DLL function addresses, but what I'm wondering is, is the *.lib file version-specific? The problem is, I don't really understand what *.lib files are for, and since I'm having problems with different versions of the DLL, I thought that's where the problem might lie.

 

[butthead]

someone correct me if I am wrong

the lib files contain the namemangling info
if any and the addresses of the function contained
in the dll. this info is stored in your exe when
you comile. its got to get it from somewhere. if
you dont have the lib file when you compile you can
use totte's method to get the addresses at runtime.

if you look at there size you can see that there is not
much room for any thing else. copy a lib file to another
folder, change the extension to ".txt" and open it.

probably more to it than that

TC