If this is being done dynamically using Windows, you need a call to LoadLibrary followed by a call to GetProcAddress.
Only if you are dynamically linking at run time (oh actually you said that but sonce I have already typed everything below I am going to post it anyway :D )
If you are statically linking at link time, by including the *.lib file on the linker, command line then this is not required. This is how you link to the Windows kernel, user and all their other DLLs.
NOTE: statically linking to a DLL is NOT the same as linking a static library. When you create(compile and link) a DLL the output includings a <DLLName>.DLL, the dynamicly loaded code and a <DLLName>.lib. The lib file is usually fairly small because all it contains is calling vectors to the functions actually in the DLL and normally linking it does not increase the size of the executable much. If you know you are going to be using a specific DLL linking the lib does save on all the LoadLibrary/GetProcAddress but then the program will not start with the DLL being present.
Dynamically linking to a DLL can be very useful, you can use it to add extensions or to implement a form of polymorphism at program level (i.e. have a user interface that allows the user to perform set operations but then how those operations are implemented and carried out depend on which DLL you have dynamically linked to), but the program has to know what the interface to the DLL is.
There are various ways of doing this, fixing what functions the DLL has to implement is one or having a set of fixed functions in the DLL that are capable of enumerating the other functions.
Go too much further down this route and it starts to become sensible to look into COM (and DCOM) objects.
13
