Dynamic Loading of Modules

[Niklas Elmqvist]

On Fri, 20 Mar 1998, Jon A. Lambert wrote:
>
> 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.

Yes, I do know that Windows has dynamically linked libraries, just like
Sun and Linux and whatnot (I think they had that *before* it went
32-bit, however). However, I suppose you did not read the earlier
part (this may be blamed on my too-active-snippage), where I explained
about my "discovery" where a server binary with a base class called aClass
could dynamically load a module which implemented a subclass of aClass
called bClass and *still* use the bClass (as a reference to an aClass
object, of course, using polymorphism) even though the server had no idea
of its existence at compile-time. (Phew.) According to my RL friend (I
have no personal experience in this), this scheme is impossible to
implement using Windows DLLs -- I believe he tried after hearing me
explain about it.

Then again, Windows has its own bunch of abominations, COM/DCOM/COM+ being
foremost among these. Although they provide for some nice functionality,
COM objects are expected to delete themselves and call their own
destructor -- need I say more? And this is what some people want instead
of CORBA? *sigh* 

-- Niklas Elmqvist (d97elm at dtek.chalmers.se) ----------------------
"You can't trample infidels when you're a tortoise. I mean, all you 
 could do is give them a meaningful look."	 
	- Terry Pratchett, Small Gods