[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