Quote Originally Posted by Brainer
Quote Originally Posted by AthenaOfDelphi
You can dynamically load your libraries using loadLibrary (if my memory serves)
Yep, that's true. To be honest, I have never tried loading a DLL during application's execution, i.e. not at start. But AFAIK existence of external dependencies is checked before an application is actually run. I've never really met any program which thrown an error saying there's a DLL missing in the middle of its execution. But like I said, I may be wrong. If anyone can dispell the doubt, please do so.
I can dispell the doubt because I've written an application that does it. It's a fractal renderer I wrote many years ago and it stored it's equations in a DLL that is loaded dynamically at run time.

The way it works is you load a library with loadLibrary and then rather than have the compiler sort the dependencies etc. out at compile time, you use a mechanism similar to event handlers to sort them out yourself. You get the addresses of the calls using getProcAddress (IIRC).

For example (taken from my Fractal program), here is a prototype definition:-

[pascal]
TEQPConfigEQ = procedure( CurrentEQ:Integer;
var xmin:TFloaty;
var xmax:TFloaty;
var ymin:TFloaty;
var ymax:TFloaty;
var arg1:TFloaty;
var arg2:TFloaty;
var arg3:TFloaty;
var arg4:TFloaty;
var arg5:TFloaty;
var arg6:TFloaty;
var arg7:TFloaty;
var arg8:TFloaty ); stdcall;
[/pascal]

In your main code you declare a variable like this...

[pascal]
EQPConfigEQ : TEQPConfigEQ;
[/pascal]

And initialise it using getProcAddress something like this...

[pascal]
@EQPConfigEq:=GetProcAddress(EQPLibraryHandle,'EQP lug_ConfigEq');
[/pascal]

If this fails, I think (IIRC) EQPConfigEQ ends up equal to NIL. If it succeeds, you call the routines just like a normal procedure called 'EQPConfigEQ'.