🚀 go-pugleaf

Hi Dennis,

Thank for you advice. Like you mentioned too much of work to
do, if single DLL will do it but too many dlls.

Regards
KL Chin

"Dennis Jones" <nospam@nospam.com> wrote in message 
news:42b9b096$1@newsgroups.borland.com...
>
> "KL Chin" <klchin@1asia.com.my> wrote in message
> news:42b90da0@newsgroups.borland.com...
>> Hi,
>>
>> I used 3rd party VC++ DLL, everything were working fine with my
>> program. Until when the 3rd party DLL had an update with extra
>> funtion, after going throught the debugging/tracing, I found that the
> static
>> call/jump to the DLL function was wrong address, instead of
>> call at Function_Init it call at Function_New.
>>
>> How to overcome this problem, I know re-import lib from the DLL,
>> but this could not solve the future dll.
>
> If the DLL adds or deletes functions, it is very likely that the function
> addresses will change, so you are almost always better off re-creating the
> import library if the DLL changes.  On the other hand, if the DLL only
> changes the behavior of existing functions, chances are good that the
> function addresses will not change (I believe the function addresses will 
> be
> independent of function size in the DLL, but I am not 100% sure about 
> that).
>
> The only way to guarantee never having to re-create the import library is 
> to
> not use an import library at all.  Instead of implicitly loading the DLL,
> explicitly load it with LoadLibrary() and use GetProcAddress() to locate 
> the
> functions in the DLL.  If you do that, you will never have to worry about
> the function addresses, but it is a bit more work.
>
> - Dennis
>
>