quote: Original post by Skid
"So with DLLs you never have to recompile the executables using them."
If the DLL is statically linked, then you will only have to recompile it IF the exports change. Try changing the parameters or the name of the exported function in your testDll, or adding new ones. You will have recompile the client exe since the DLLs .lib file would have changed.
If the DLL is loaded at runtime, then you dont ever have to recompile the client.
Well, may be I did not express myself correctly. The person on which I was replying said "whenever the LIB changes" (and I think someone else also said "in bug fixes"). Well, when you add new functions, for instance, the LIB changes but you do not need to recompile the EXE. When you fix bugs on the DLL you also don't need to recompile the EXE.
But now what you are talking about here is *BREAKING* the EXE file compatibility whith the DLL's interface, that is something else, which will require not just EXE recompile, but it will have to be modified as well to comply with the new DLL interface.
You are right about dynamically binding the DLL functions (using LoadLibrary/GetProcAdress) only if you use a function table and the identifier to get the table address from the DLL does not change, but that would only work in the case of function name change. (Anyway, the header used to build the executable's file calling functions one name, and the header used to build the DLL's file calling it another is not good coding practice, is it? But the point is the EXE code is not broken.)
But in *ALL* cases, changing the parameters the function uses will break the EXE, requiring EXE modification and recompile, without regard to how you bind the DLL functions to the EXE.
The point is: (as long as no code is broken) EXEs will *NEVER* have to be recompiled even if the LIB or DLL used by those EXEs change.
Topgoro
Edited by - Topgoro on 4/19/00 12:42:16 PM