[MUD-Dev] Dynamic Loading of Modules (was: Back on the list
Jon A. Lambert
jlsysinc at ix.netcom.com
Fri Mar 20 19:57:11 CET 1998
On 24 Feb 98 at 0:12, Niklas Elmqvist wrote:
>
> Now, if aClass and bClass had been part of the same binary, I would not
> have been surprised. In fact, as you probably all know, this is called
> late binding in the O-O community and is an important feature of all
> serious O-O languages. However, what surprised and delighted me is that
> late binding *still* works even though the core and shared lib described
> above are separately compiled, and the bClass is totally unknown to the
> core! In my eyes, this is the ultimate test of late binding, and G++
> pulled it off nicely! Incidentally, a friend (the one mentioned above)
> later reported that this is impossible in Windows-style DLLs.
>
Run-time binding, application-level loading and unloading of DLLs
have been around in Windows ever since it went to 32-bit. There is
also a standardized API (OLE2) to handle multi-threaded and
interprocess communications between disparate (loose/non-coupled)
modules. Reference counts are maintained on DLL modules and by
default once an application requests the services of a DLL it will
remain loaded either until the application terminates or issues an
API call to unload it. If references are held by other processes or
threads the DLL will not be unloaded until all interested parties
indicate they have no further use for it.
--
--/*\ Jon A. Lambert - TychoMUD Internet:jlsysinc at ix.netcom.com /*\--
--/*\ Mud Server Developer's Page <http://www.netcom.com/~jlsysinc> /*\--
--/*\ "Everything that deceives may be said to enchant" - Plato /*\--
More information about the mud-dev-archive
mailing list